BIP-341: explicitly allow softforks with future leaf versions #1230

pull dr-orlovsky wants to merge 1 commits into bitcoin:master from dr-orlovsky:patch-9 changing 1 files +1 −1
  1. dr-orlovsky commented at 9:45 am on November 7, 2021: contributor
    Currently the BIP-341 and BIP-342 leave the question of how to verify signature for non-0xC0 leaf version scripts undefined. I haven’t checked the Bitcoin Core code for that matter yet, but (1) I think we need to cover signature validation of non-0xC0 leaf version scripts in this standard and (2) the only way of doing that is “always succeed” rule for the future leaf version values (otherwise we will need a hard fork to introduce them).
  2. sipa commented at 5:53 pm on November 7, 2021: member
    I think this is covered already, by saying evaluation happens according to applicable rules. Without applicable rules, there is nothing to execute, and thus no way execution could fail. I don’t object to clarifying this, but (a) I’d do it in the existing section on validation and (b) I don’t understand what signature validation has to do with this; validation rules for future leaf versions is entirely up to the definition of those leaf versions if and when they get defined. Hypothetically speaking, a future leaf version may have “scripts” that are completely distinct from what we think of as scripts today - they could feasibly not involve anything resembling a signature at all.
  3. dr-orlovsky commented at 1:06 pm on November 8, 2021: contributor

    Ok, I see your point on signature term and I will change this PR to add the statement to the existing section. I do think that this clarification is needed, since it is not obvious for the reader (at least was not obvious for me).

    Can you please confirm that it is the way it is currently implemented in Bitcoin Core? I was digging the source code but was not able to find the exact place where the 0xC0 version is checked and the rest is ignored (simple search for 0xC0 nor TAPROOT_LEAF_TAPSCRIPT didn’t reveal anything in that regard).

  4. BIP-341: allow future softforks for leaf version signature verification
    Currently the BIP-341 and BIP-342 leave the question of how to verify signature for non-`0xC0` leaf version scripts undefined. I haven't checked the Bitcoin Core code for that matter yet, but (1) I think we need to cover signature validation of non-`0xC0` leaf version scripts in this standard and (2) the only way of doing that is "always succeed" rule for the future leaf version values (otherwise we will need a hard fork to introduce them).
    592cb6fa0c
  5. dr-orlovsky commented at 9:08 pm on November 8, 2021: contributor

    @sipa thank you very much, do not know how I missed that part. May be GitHub search algorithms are not that good and I should have searched locally…

    Anyway, thank you for the clarification. I have updated wording for this PR according to your suggestions

  6. dr-orlovsky force-pushed on Nov 8, 2021
  7. dr-orlovsky renamed this:
    BIP-341: allow future softforks for leaf version signature verification
    BIP-341: explicitly allow softforks with future leaf versions
    on Nov 9, 2021
  8. luke-jr added the label Proposed BIP modification on Dec 15, 2021
  9. luke-jr assigned sipa on Dec 15, 2021
  10. sipa commented at 5:47 pm on December 20, 2021: member
    ACK 592cb6fa0c8e1484488cfc4e43fe1e4825c17132
  11. dr-orlovsky commented at 11:49 am on January 6, 2022: contributor
    @kallewoof I assume this can be merged with an ACK from the BIP author?
  12. kallewoof merged this on Jan 7, 2022
  13. kallewoof closed this on Jan 7, 2022


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-30 01:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me