-
Notifications
You must be signed in to change notification settings - Fork 322
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
Enforce OP_RETURN standardness #1726
Conversation
Should we use a default max size of 83 as shown here? |
9404ad7
to
0d7b650
Compare
0d7b650
to
ef28e9a
Compare
ef28e9a
to
f7d6dcf
Compare
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.
utACK f7d6dcf
@@ -104,6 +104,10 @@ pub enum CreateTxError { | |||
MissingNonWitnessUtxo(OutPoint), | |||
/// Miniscript PSBT error | |||
MiniscriptPsbt(MiniscriptPsbtError), | |||
/// Multiple recipients are OP_RETURN outputs | |||
MultipleOpReturn, |
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.
Why are we disallowing multiple OP_RETURN
outputs?
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.
For the same reason as the byte limitation, it would be non-standard
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.
Fair, I didn't know this was a policy. I think it's best to document this and include a 🔗 to the code enforcing the policy.
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.
Although OP_RETURN
outputs larger than 83 are non-standard, they are still considered to be valid transactions. I think we should still allow building non-standard txs in build_tx
.
I think the better approach would be to have TxBuilder::add_data
return an error. This provides instant-feedback for the caller and we can document the restriction on the method.
I think this is best put off for 2.0.0. The functionality to build OP_RETURN transactions is present and this is really a matter of standardness, which is up for debate |
This will likely be resolved with a new |
Closes #1718
All Submissions:
cargo fmt
andcargo clippy
before committingNew Features:
Bugfixes: