-
Notifications
You must be signed in to change notification settings - Fork 11
Add support for psetv2 #189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| var script, blindingKey []byte | ||
| if len(a.Address) > 0 { | ||
| script, _ = address.ToOutputScript(a.Address) | ||
| script = []byte{txscript.OP_RETURN} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OP_RETURN can be confidential too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes indeed.
OutputArgs is a user-friendly type without a raw field like BlindingPubKey []byte. It instead has a Address string field that can be confidential or unconfidential, and in the first case is used to set also the partial output blinding pubkey.
If the OutputArgs has a confidential address and a 0 amount, it means it's dummy confidential output, therefore only the blinding pubkey extracted from the confidential address is passed to the partial output, while the actual script is OP_RETURN.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mmm seems not straightforward and doing a lot of implicit things, also how to embed actual data in the OP_RETURN or what if you want to burn funds ie. amount > 0?
I would take advantage of generics type here, to pass both Script && Blinding Key OR Address, to accommodate both situations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bump @altafan
tiero
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tiero
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add the BIP371 Taproot fields
This contribs to the initial effort of @sekulicd in #184 and takes the psetv2 package to a ready-to-use version.
I made a huge refactor regarding named variables, errors messages, and, more importantly, the business logic.
In particular, the blinder role has been basically split into 2 fundamental parts:
psetv2.Blinderis the role in charge of adding blinding data to pset's input issuances or outputs. It makes sure that everything's correct and updates also the global scalars of the partial transactionconfidential.zkpGeneratorandconfidential.zkpValidatorare the implementations ofpsetv2.BlindingGeneratorandpsetv2.BlindingValidator, in charge of handling private keys to unblind inputs and public keys to generate blinding data, ie. blinders, commitments, and proofsThe package already contains some tests showing how to use psetv2 to:
Please @tiero @sekulicd @louisinger review this.
This closes #167
This closes #189