Enforce OP_RETURN standardness - #1726
Conversation
|
Should we use a default max size of 83 as shown here? |
9404ad7 to
0d7b650
Compare
notmandatory
added
audit
0d7b650 to
ef28e9a
Compare
ef28e9a to
f7d6dcf
Compare
| /// Miniscript PSBT error | ||
| MiniscriptPsbt(MiniscriptPsbtError), | ||
| /// Multiple recipients are OP_RETURN outputs | ||
| MultipleOpReturn, |
There was a problem hiding this comment.
Why are we disallowing multiple OP_RETURN outputs?
There was a problem hiding this comment.
For the same reason as the byte limitation, it would be non-standard
There was a problem hiding this comment.
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.
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 |
5 participants
Closes bitcoindevkit/bdk-tx#49
All Submissions:
cargo fmtandcargo clippybefore committingNew Features:
Bugfixes: