* [bitcoin-dev] BIP-118 / SigHash "what's covered" Cheatsheet
@ 2021-07-10 0:11 Jeremy
0 siblings, 0 replies; only message in thread
From: Jeremy @ 2021-07-10 0:11 UTC (permalink / raw)
To: Bitcoin development mailing list, lightning-dev
[-- Attachment #1.1: Type: text/plain, Size: 2484 bytes --]
As a part of my ongoing review of BIP-118 I put together the following
chart.
Source:
https://docs.google.com/spreadsheets/d/1KeWJ_cly9zoRX5_h70RTniRT2m8_iaVceK_aF6obWeM
Not tightly checked to be free of errors, but I figured such a chart would
be helpful for folks evaluating BIP-118.
Perhaps the BIPs (generally, incl 34x) could be updated to present the
information in such a chart -- at least for me it's much clearer than
following a bunch of conditional logic (maybe if there's ever desire for
some consensus refactoring this could be a table in the code replacing the
cond logic).
[image: image.png]
A few highlighted nuances:
- input index is never signed (i previously thought one mode signed it).
Key reuse under APOAS|Default and APOAS|All is a bit extra unsafe given
susceptibility to the "half-spend" problem. This limits usability of APO
for covenants a-la CTV because you can't stop someone from adding inputs to
your contract nor can you prevent half-spend problems when reusing
addresses.
- APO signs the Amounts, APOAS never does.
- APO signs both the SPK and the Tapleaf hash, meaning that APO binds
itself to the entire script rather than just it's fragment. There's no
setting which is "just this fragment"
- APO's signature binds it to a specific script fragment *within* a taproot
key, but not a specific script path
- the flag "default" is not really a flag at all -- when default is used
(as a or'd byte) there are different results than when default is inferred
(by absence of a byte) (this is maybe a bitcoin core specific quirk).
- There are 16 different possible modes total, so all combinations of flags
mean *something* (advisable or not as with ACP | None)
- | Default and | All overlap, so there's an opportunity to either reserve
or assign 4 additional sighash modes if desired. These could cover some of
the gaps above, or be saved for future purposes rather than be wasted now.
Another point of interest is -- not to rock the boat -- but because BIP-118
is defining a new key type we could do away with the notion that sighash
flags are "flags" and convert to an enum (e.g., numbered 0-256 for whatever
combination of fields each would incur) and give each signature type a
sensible name, rather than thinking of things as a combo of flags (e.g.,
APOAS is not some intersection of what APO and ACP do independently).
Hopefully this helps!
Cheers,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
[-- Attachment #1.2: Type: text/html, Size: 5734 bytes --]
[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 1104237 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2021-07-10 0:12 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-10 0:11 [bitcoin-dev] BIP-118 / SigHash "what's covered" Cheatsheet Jeremy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox