<laanwj>
hebasto: now we only have to find an interested translator ! :D
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 260 seconds]
kevkevin has joined #bitcoin-core-dev
salvatoshi has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 240 seconds]
kevkevin has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 268 seconds]
Earnestly has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 260 seconds]
<bitcoin-git>
[bitcoin] dergoegge opened pull request #29869: rpc, bugfix: Enforce maximum value for setmocktime (master...2024-04-fuzz-smt) https://github.com/bitcoin/bitcoin/pull/29869
<Chris_Stewart_5>
my understanding is xonly keys are allowed in tapscript, however this seems to be a legacy pubkey? `pk(02df12b7035bdac8e3bab862a3a83d06ea6b17b6753d52edecba9be46f5d09e076)`
<Chris_Stewart_5>
From a quick search, it seems this test case isn't in descriptor_tests.cpp. If I remove the parity byte the test case does seem to pass so I assume typo?
<sipa>
Chris_Stewart_5: KEY expressions in tr() allow everything normal KEY expressions allow, plus a new 64-character hex
<darosior>
Chris_Stewart_5: compressed pubkeys are accepted as key expressions
<sipa>
the serialization to script just drops the Y coordinate
<sipa>
think of it this way: xpub > regular pubkey > xonly-key, each provides a superset of the information the next one contains, so you can go from left to right while just dropping the part that doesn't matter
<sipa>
tr() scripts/keypaths happen to only need the X coordinate, but there is nothing wrong with specifying keys that contain more information
<Chris_Stewart_5>
Definitely confusing, but I understand from a compatability POV I guess. I presume if someone actually committed to a 33byte pubkey the branch would be unspendable?
<sipa>
Chris_Stewart_5: well you can use an xpub as a KEY expression, which also contains a Y coordinate... clearly we can't outlaw that
<Chris_Stewart_5>
Sure... but you could outlaw 33/65 keys to avoid more footguns. I guess i don't find the argument compelling that "its possible to footgun, so lets just allow all footguns!" Any way, my question is answered thank you.
<sipa>
Chris_Stewart_5: you mean in an actual taproot script? as internal key you just can't use anything but an x-only key; inside a tapscript using a 33-byte key would be treated as an unknown key type
<Chris_Stewart_5>
Hmm, ok. I didn't think about it from that perspective
<sipa>
Chris_Stewart_5: no, it would be ignored (so, anyone can spend)
<Chris_Stewart_5>
Also why isn't the leaf version somehow put in the tr() descriptor? I assumed that would be necessary as we roll out future leaf verisons? Or did it get left on the cutting board to just get something out there?
<sipa>
Chris_Stewart_5: it's implicitly 0xc0 for now
<sipa>
if new leaf versions are introduced, we'll need extensions to the descriptor language anyway
<Chris_Stewart_5>
:+1: that was what i was assuming. Perhaps in the future the tr() identifier could be modified to be tr_{leaf_version} or something. My understanding of tapscript is the leaf version is a "global variable" for all tapscript branch spends?
<sipa>
no, each leaf can have a different leaf version
<sipa>
that's why it's called the leaf version... as opposed to the witness version which is global
<Chris_Stewart_5>
ah, yes that makes sense :face_palm:. That complicates things. Any way, thanks for the extremely helpful insight/answers!
kevkevin has quit [Ping timeout: 260 seconds]
<sipa>
np
<sipa>
if a future leaf version is called fancyscript, i could imagine a descriptor fragment fancy() that wraps around the script, and goes into tr
<Chris_Stewart_5>
64BIT_MAXI() ;)
<sipa>
so e.g. tr(KEY,[multi_a(...),fancy(multi_a(...))]) would then specify a 2-leaf taproot script where one branch is 0xc0, and the other is a fancyscript with whatever leaf version fancyscript uses
<sipa>
assuming multi_a even makes sense within fancyscript of course
<laanwj>
crc32c-subtree and leveldb-subtree have been added to receive notifications here
<fanquake>
thanks
puchka has quit [Read error: Connection reset by peer]
VonNaturAustreVe has joined #bitcoin-core-dev
puchka has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] instagibbs opened pull request #29879: fuzz: explicitly cap the vsize of RBFs for diagram checks (master...2024-04-package-rbf-overflow) https://github.com/bitcoin/bitcoin/pull/29879
brunoerg has quit [Remote host closed the connection]
AaronvanW has quit [Quit: Leaving...]
AaronvanW has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
bugs_ has joined #bitcoin-core-dev
<Chris_Stewart_5>
sipa: I do suspect that this test vector is still wrong, but I don't see an easy way to implement it in bitcoin core. The reason I suspect its wrong is because if I omit the parity byte i get the "correct" script (according to BIP386). If I add the parity byte I get something else ('5120756a5aace335408f938e4e032d56e3bbdfb9833520e3041a3518c89b3f21949b').
brunoerg has quit [Read error: Connection reset by peer]
<sipa>
Chris_Stewart_5: i'm confused; the 02 or 03 in the descriptor shouldn't affect the produced scripts
<sipa>
are you saying that's not what is implemented?
achow101 has quit [Remote host closed the connection]
achow101 has joined #bitcoin-core-dev
<Chris_Stewart_5>
Hmm, perhaps i'm confused. My understanding is the merkle root should commit to the 33 byte public key. That merkle root computation affects the serialized script in the test vector.
achow101 has quit [Remote host closed the connection]
brunoerg_ has quit [Ping timeout: 240 seconds]
<darosior>
Chris_Stewart_5: re your question about the test framework: no it does not require all-private strings for the private descriptor.
<sipa>
in a tapscript public keys are _always_ serialized as x-only
achow101 has joined #bitcoin-core-dev
<sipa>
regardless of how they are described in the descriptor
brunoerg has joined #bitcoin-core-dev
<Chris_Stewart_5>
darosior: Thank you I didn't realize that.
<Chris_Stewart_5>
sipa: Then I think I misunderstood you wrt to 'SCRIPT_ERR_DISCOURAGE_UPGRADABLE_PUBKEYTYPE'. My understanding was that you _do_ allow non xonly public keys in tapscript to take advantage of this upgrade capability
<sipa>
Chris_Stewart_5: they're allowed, but meaningless... they're anyonecanspend
<instagibbs>
descriptors aren't trying to support anyonecanspend type commitments, I suspect
<Chris_Stewart_5>
so now it seems i've argued in a circle and were back to xonly keys! :P
<sipa>
descriptors only support well-defined features
brunoerg_ has joined #bitcoin-core-dev
<sipa>
they describe intent
<sipa>
"pk(...)" means "check a signature with this public key!", not "emit this public key in the script"
<sipa>
you can use the 66-hex format for public keys, or the xpub format in descriptors... it still means checking with the corresponding public key; in tapscript that means emitting a check with the corresponding xonly key, in p2wsh that means emitted a check with the corresponding compressed pubkey
brunoerg has quit [Ping timeout: 256 seconds]
salvatoshi has quit [Ping timeout: 264 seconds]
zeropoint has joined #bitcoin-core-dev
salvatoshi has joined #bitcoin-core-dev
<sipa>
i guess this can be clearer in BIP386, it's a bit ambiguous in "Modified Key Expression" section which phrasings are about the descriptor notation, and which about the emitted keys in scripts
zeropoint has quit [Client Quit]
<sipa>
but in short, there is an *additional* allowed KEY expression inside tr(), the 64-char hex notation; all previously existing KEY expressions remain support (xpubs, xprvs, derivation paths, origins, WIF, hex 66-char pubkeys, ...)
zeropoint has joined #bitcoin-core-dev
<sipa>
but _all_ of them are in the emitted script expanded to the corresponding 32-byte xonly key, because that's the only thing that has meaning as of BIP342
<Chris_Stewart_5>
I agree it coudld be clarified
<sipa>
in theory, it is legal to have 33-byte public keys in BIP342, but that's just a future extension mechanism, it has no semantics associated with it
<sipa>
so it'd be a huge footgun to have descriptor expressions be mapped to that, as it's effectively an anyonecanspend
brunoerg_ has quit [Remote host closed the connection]