new account regn protocol: preregister/payfee #1017
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WARNING: The scope of this PR is extensive. There are a number of TODOs, but it is functional on the positive paths and most of the easy-to-hit edge cases. Ignore the unit tests (for the most part) as there is a lot of updating to do. Account import/export is presently broken because of client DB changes. And generally it is fairly rough.
The primary goal of this PR is to replace the current registration protocol (
register
/notifyfee
) with a new one that involves transmitting the raw fee payment transaction to the server, and only then creating an account. This involves the following new routes:'preregister'
client-originating request to obtain fee payment details given an (optional) specified asset,'payfee'
client-originating request to provide the fee payment transaction, and'feepaid'
(optional) server-originating notification to inform the connected client that the fee txn is confirmed and their account is thus "confirmed". The'connect'
response is also modified to convey "confirmed" status as well.A secondary goal of this work is to design for fee payments with various assets configurable by the server operator.
Presently I am able to complete registration in the most likely scenarios: no connection or process interruptions, restart dexc and then mine the fee txn, and shutdown dexc and restart it after confirming the fee txn. Each scenario has a different path for ensuring completion of the account confirmation process. There is work toward allowing recovery of failed
'payfee'
request that may or may not have created an account server-side, but this is untested. Also, the server needs work to reattempt account confirmation for pending fee transactions on restart; presently it forgets to check the confirmations of pending fee txns.How to review this PR in it's current state:
'preregister'
and'payfee'
are meant to work. The'preregister'
response from the server is signed so that the fee address, amount, and asset details are provably assigned by the server. A successful'payfee'
request creates the account when the txn is validated and accepted by the network. Importantly, this means that "account found" actually means "paid" now, unlike when the legacy'register'
request merely associated an account ID with a fee address to be used. However, the account is not "confirmed" until the tx reaches the required number of confirmations.ParseFeeTx
in server/asset/dcr/dcr.go for details on what constitutes a valid fee payment transaction. Note that a fee transaction commits to a specific account ID, and as such the "fee address" need not be unique to the account. This commitment also prevents others from claiming the fee payment as their own if it is broadcasted before the'payfee'
request.(*ExchangeWallet).MakeRegFeeTx
in client/asset/dcr/dcr.go for how the client constructs a Decred fee payment transaction to satisfyParseFeeTx
given the instructions from the'preregister'
response.'preregister'
requests not yet met with'payfee'
requests. Possibility for address reuse is in the design.(*Core).Register
method in client/core/core.go. Skip the "account already exists" handling at first and note the beginnings of support for fee payment in multiple assets as specified by the server's config (feeAsset
). Note that the new account data including the raw fee tx is stored in the client's DB after'preregister'
and generation of the fee transaction, but before'payfee'
and broadcasting of the transaction.PayFeeSig
is stored after successful'payfee'
request viac.db.AccountPaid
, whileConfirmed
is stored viac.db.ConfirmAccount
after required confirmations are reached and a'feepaid'
notification is received or the server's'connect'
response indicates the account is confirmed.'payfee'
request but before reaching "confirmed" status, the account ID may'connect'
(authDEX
), but not trade, similar to suspended accounts.Side note about account ID commitment in fee transaction: In a mesh configuration, this may be helpful to tie a transaction to a certain account, although the consensus for defining acceptable amount and payment address is still unclear. I can imagine including the server's
'preregister'
signature, but in a mesh anyone can run a server so what exactly does that prove to the other nodes in the mesh? This needs more thought, but the general approach of providing the raw transaction via'payfee'
to actually create an account entry is the goal of this work.