PoW Account Creation

[mvandeberg]

PoW for account creation is done entirely via soft fork.

Because of this I don't want to make PoW part of a consensus op. However, the architecture for the modular blockchain requires that ops in separate modules do not belong in a transaction together.

I see two potential solutions to this problem:

1. Include a non-consensus PoW field in a new account create operation.
2. Require inclusion of custom JSON op containing the PoW and allow custom JSON to exist in the same transaction as another op. (This would be an exception to the rule stated above specifically for non-consensus ops)

If we go with 2, then for the sake of determinism in non-consensus plugins, there needs to be an ordering in all plugins that determines the order that non-consensus ops are applied. We probably need this any way so that modules can listen to ops from other modules and apply changes deterministically.

[theoreticalbts]

The egg proposal

I was thinking about how this extension to the account creation system should work, and it occurs to me that there are several non-obvious requirements and subtle issues:

• (a) The account_create_operation does not support extensions.
• (b) It should be possible to create an account anonymously using only a PoW and no fee.
• (c) An arbitrary amount of time should be able to lapse between successful submission of PoW and account creation.
• (d) The account creation system should be non-consensus to the greatest extent possible.
• (e) The account creation system should be compatible with the planned parallelization effort.

OP does not satisfy requirement (c), so the proposal in this post represents a somewhat different vision of what the new HF20 system should be (compared to OP).

First, let's establish some terminology. The term "discounted account creation token" is long, and calling this concept a token is misleading since AFAIK there is no plan to make these tokens transferable, or integrate them with the SMT framework in any way. So let's call it an "egg" instead, and use the metaphor of "hatching" for the process of transforming a discounted account creation token an egg into an account.

By submitting a PoW, a user creates an egg object with an authority egg_auth. The egg object may be hatched into an account at any time by the authority specified in egg_auth.

The hatching has the following requirements:

• (f) The hatching transaction must be signed by the authority in egg_auth

To implement this requirement we add two new consensus rules:

• (CR1) An account_create_operation issued by the temp account must be signed by the active authority of the new account.
• (CR2) Every account_create_operation within a block must have a distinct active authority.

And add some soft consensus rules:

• (SNCR1) Any account can create an egg with a create_egg_operation which contains a PoW. This operation requires
  no bandwidth and can be issued by the temp account.
• (SNCR2) When an account_create_operation issued by the temp account occurs, any egg which exists with the same active authority as the newly created account is hatched, and the account creation fee is waived.

Consensus semantics

I am very uneasy about allowing a full soft consensus. If witnesses unconditionally accept any egg creation accepted by any other witness, then a single rogue witness would be able to create an arbitrary number of eggs for their personal use, and raise PoW difficulty arbitrarily high for those who don't run a witness. Likewise, if witnesses unconditionally accept any fee on account creation by any other witness, then a single rogue witness would be able to create an arbitrary number of accounts for their personal use without paying a fee.

So therefore I propose a hard-consensus limit on the rate at which each witness is allowed to create eggs and accounts:

• (CR3) There is a hard-consensus witness parameter for maximum account growth rate.

• (CR4) Each witness's blocks are only allotted to contain account creation operations corresponding to 10% of the maximum account growth rate.

• (CR5) Any unused account creation allotment from (CR4) is saved in a burst buffer with a capacity of one day's worth of account creations.

• (HNCR3) The maximum egg growth rate is equal to the maximum account growth rate.

• (HNCR4) Each witness's blocks are only allotted to contain egg creation operations corresponding to 10% of the maximum egg growth rate.

• (HNCR5) Any unused egg creation allotment from (NCR4) is saved in a burst buffer with a capacity of one day's worth of egg creations.

The egg rules (HNCR3) (HNCR4) (HNCR5) cannot be consensus, since eggs are non-consensus. However, these rules should be "hard non-consensus," meaning any node running the witness plugin will reject a block produced by another witness that violates the rules. This hard non-consensus
behavior is necessary to place limits on the abuse a witness will be able to do before being voted out.

Related issue: #1765

Requirements review

Now let's review how this proposal satisfies the requirements:

• (a) Since we use create by temp account, it's backward compatible with the old operation data structures and does not require new fields.
• (b) To create an account anonymously with only a PoW and no fee, create an egg using PoW and a simple authority (containing a single key). Then hatch the egg with the temp account.
• (c) Eggs do not expire.
• (d) It is not possible to have a completely non-consensus system because of requirement (b), since the authority operation must be extended or redefined in order to require the transaction to be signed by an additional key that wouldn't normally be needed. Therefore (CR1) is necessary.
• (e) Due to the planned parallelization, any update to egg state is not guaranteed to be visible until the next block. Therefore (CR2) is necessary to prevent an egg from being reused.
• (f) By (SNCR2), creation by the temp account causes the egg to hatch meaning the fee is waived. By (CR1), the egg's owner must sign the transaction.

[theoreticalbts]

I spent a little time last night refining the above ideas and writing a little code to explore the possibilities. I have code that compiles and begins to implement some of the needed data structures. That code is here.

I don't plan to develop it further, but I think it's a good starting point to anchor the discussion of what the new account creation system should look like.

[sneak]

I am very uneasy about allowing a full soft consensus. If witnesses unconditionally accept any egg creation accepted by any other witness, then a single rogue witness would be able to create an arbitrary number of eggs for their personal use, and raise PoW difficulty arbitrarily high for those who don't run a witness.

🎯

[theoreticalbts]

As an alternative to rejecting a block that contains an illegal egg, one alternative would be to say that any custom op which would create an egg in violation of NCR3-NCR5 is a no-op.

But this changes the validity of a transaction based on which witness includes it, which means that if one witness uses up all their eggs, then legitimate users whose egg creation transactions happen to be included by that witness will be left high and dry.

This is actually not too much of a problem though, since the op can be re-submitted in a new transaction as many times as necessary by the user wallet as long as the proof-of-work is not expired. Unless the majority of the witnesses are regularly filling up their egg allotment creating private eggs, it should be high probability (>50%) that it will be included by a properly functioning witness.

So to summarize: This post is about whether rules NCR3-NCR5 should be hard (blocks that violate the rules are rejected) or soft (blocks that violate the rules are accepted but the violating operations become no-ops). Soft is simpler to implement since it is more in line with how the existing code works, and more conservative/defensive programming because that any bugs in the code would be less likely to take down the network. But making these rules soft also opens up a denial-of-service issue against egg creators that allows valid PoW's to be locked out, and can be triggered by a single witness that is malicious, or simply malfunctioning. User wallet software can workaround such a lockout by resubmitting the egg creation transaction as necessary.

[mvandeberg]

First of all, while I think the delayed account creation through PoW is a nice feature, I do not believe it is a necessary feature. It complicates the implementation significantly and because of that, I think we should scrap that aspect of account creation.

With regard to the rogue witness using all available "eggs" (I'm not a fan of the terminology, but the metaphor works), the HF 20 proposal includes a section on what I have called "non-production soft forks". https://steemit.com/steemit/@steemitblog/proposing-hardfork-0-20-0-velocity

The basics being that all of our soft forks are inherently accepted by all witnesses. It is an endpoint filter. The non-production soft fork is a way for a witnesses to choose to produce on a minority fork based on their preference of the truth. We don't want to immediately reject a block that breaks some soft rule, but having the option to fork out the block if the witnesses choose to is important in a system like this.

(CR1) requires changes to our authority verification logic if we use the account_create_operation because it will include a signature that is not required. Unnecessary signatures fail auth checks.

(CR2) is possible with an additional data structure. I view this is a deterrent against a rogue witness spam creating accounts for free. It is an ineffective deterrent so I don't believe it is needed.

(CR3) is already proposed in issue 1765

(CR4) is reasonable.

(CR5) The proposal for the "eggs" creates them at a fixed rate and allows accumulation up to 48 hours worth of tokens. That caps the long term growth rate and CR4 caps the per block burst.

If we do not allow storing of PoW for later use then we can create a new account creation op with the following consensus rules:

There is an extensions field which defines the PoW. Consensus rules are never concerned with the contents of the proof, but only its existence.

If the PoW exists and the creating account is temp then the signature must match the active key of the new account.

All other creations are linked to other accounts and we do not want to require sharing your active key when an account is mined on behalf of another.

When the PoW does not exist, the op behaves identically to the existing account_create_operation.

[theoreticalbts]

So something that's glossed over in the above proposal is that we need logic preventing any PoW from being reused. In traditional use of PoW for block production, this is trivially achieved since the input of each PoW must include the last PoW. But AFAICT the current proof-of-concept code would allow a user to create an egg, use the egg, then recycle the same PoW used to create the first egg to create another egg.

Obviously, PoW replay must be prevented, regardless of what algorithm is chosen.