erik-etsuji-kato has quit [Ping timeout: 240 seconds]
vasild has quit [Ping timeout: 240 seconds]
vasild has joined #bitcoin-core-dev
hashfunc41a has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Guest337 has joined #bitcoin-core-dev
vysn has joined #bitcoin-core-dev
Guest337 has quit [Client Quit]
brunoerg has joined #bitcoin-core-dev
greypw25460 has quit [Quit: I'll be back!]
greypw25460 has joined #bitcoin-core-dev
greypw25460 has quit [Remote host closed the connection]
greypw25460 has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
hashfunc41a has quit [Remote host closed the connection]
vysn has quit [Ping timeout: 244 seconds]
ronoaldo has quit [Ping timeout: 255 seconds]
evanlinjin has joined #bitcoin-core-dev
z9z0b3t1c has joined #bitcoin-core-dev
z9z0b3t1_ has quit [Ping timeout: 246 seconds]
brunoerg has quit [Ping timeout: 244 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 258 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
ronoaldo has joined #bitcoin-core-dev
evanlinjin has quit [Ping timeout: 240 seconds]
bitdex has joined #bitcoin-core-dev
bitdex has quit [Ping timeout: 240 seconds]
bitdex has joined #bitcoin-core-dev
bitdex has quit [Client Quit]
bitdex has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
greypw25460 has quit [Remote host closed the connection]
greypw25460 has joined #bitcoin-core-dev
greypw25460 has quit [Remote host closed the connection]
greypw25460 has joined #bitcoin-core-dev
evanlinjin has joined #bitcoin-core-dev
jarthur has quit [Quit: jarthur]
hashfunc1df8 has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
evanlinjin has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
<DavidBakin>
I'm trying to understand BIPS-341 and -342 - why is the sig sometimes 64 bytes and sometimes 65 byte? I infer from BIP-341 note 21 that the 64-byte sig is with hash_type == 0 (i.e., SIGHASH_DEFAULT) and that the 65-byte sigs are for the other hash_types which are _appended_ to the sig - but where is this actually specified (besides this note 21)?
ethan has joined #bitcoin-core-dev
<DavidBakin>
2nd question is: is the tapscript extension the annex or not? if not, where is it put?
ethan has quit [Client Quit]
sudoforge has quit [Ping timeout: 246 seconds]
saluvoy has joined #bitcoin-core-dev
<DavidBakin>
3rd question is when computing the leaf version from the first byte of the control block the low bit is masked off - is that low bit used for anything? if not, is it reserved for something?
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
<DavidBakin>
P.S. for the 64-byte vs 65-byte signature I also see the hash_type in src/script/interpreter.cpp@1687 but still don't know where that shows up in the BIPs
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
hashfunc1df8 has quit [Remote host closed the connection]
brunoerg has quit [Ping timeout: 246 seconds]
hashfunc1bb has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<laanwj>
davidbakin: if you don't get an answer here, you might want to ask in #bitcoin-wizards
<DavidBakin>
good idea but first i'll give it a few hours for the world to spin and people to show up here
<laanwj>
sure!
vasild has quit [Ping timeout: 240 seconds]
vasild has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
sipsorcery has joined #bitcoin-core-dev
z9z0b3t1_ has joined #bitcoin-core-dev
z9z0b3t1c has quit [Ping timeout: 246 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
vysn has joined #bitcoin-core-dev
S3RK has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 258 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 244 seconds]
brunoerg has joined #bitcoin-core-dev
chinggg has joined #bitcoin-core-dev
dongcarl has quit [Read error: Connection reset by peer]
chinggg has quit [Ping timeout: 252 seconds]
dongcarl has joined #bitcoin-core-dev
hashfunc1bb has quit [Remote host closed the connection]
chinggg has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 260 seconds]
chinggg has quit [Ping timeout: 252 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
<sipa>
@davidbakin The annex is completely different from the tapscript extension. Annex is defined in BIP341, and is a way to add extra fields to txins generically. The tapscript extension is what is added to the common sighash computation from BIP341 in BIP342 with the tapscript-specific fields.
<sipa>
@davidbakin Yes, that low bit is used to communicate the sign of the tweaking equation (Q = P+H(...)G or Q = -(P+H(...)G).
AaronvanW has quit [Remote host closed the connection]
<jamesob>
Oh, may be silent merge conflict... Is the prev-release CI job the only one that rebases branch on top of current master?
<laanwj>
afaik all the CI jobs rebase on top of current master
<sipa>
merge, not rebase, i assume
<laanwj>
merge, yes
<jamesob>
Well a rebase revealed the source of the error - but I find it odd that other jobs didn't fail similarly
<bitcoin-git>
[bitcoin] furszy opened pull request #25269: wallet: re-activate the not triggered "AmountWithFeeExceedsBalance" (master...2022_wallet_fix_missing_AmountWithFeeExceedsBalance) https://github.com/bitcoin/bitcoin/pull/25269
<lightlike>
jamesob: the other jobs ran 10 days ago, probably before the conflicting PR was merged. The failed one was apparently restarted only 2 days ago.
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
belcher has quit [Quit: Leaving]
bairen has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
furszy has quit [Quit: Ping timeout (120 seconds)]
furszy has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 240 seconds]
AaronvanW has joined #bitcoin-core-dev
furszy has quit [Quit: Client closed]
Guest8765 has joined #bitcoin-core-dev
Guest8765 has quit [Client Quit]
klement has joined #bitcoin-core-dev
<DavidBakin>
ok, so the extension is just something that's appended to the SigMsg before it is hashed - it doesn't actually exist as a field in a serialized transaction; but w.r.t. the 64vs65 byte signature - I have seen how you treat them differently in BIP-341 "taproot key path spending sig validation" but I don't see where there or in BIP-340 an explanation of what that 65th byte is when it
<DavidBakin>
exists - BIP-340 is totally about 64 byte signatures and doesn't know from hash types, so the only thing that I see describes it is the implication from that note 21
<sipa>
BIP340 describes a digital signature scheme, it has no notion of sighash types or even anything related to Bitcoin at all.
<DavidBakin>
oh wait! I see it in the CODE of taproot_sign_key in BIP-341! Not in descriptive text!
jonatack has joined #bitcoin-core-dev
<sipa>
The rules for verifying signatures in the context of taproot key path spends are specified in BIP341. The rules for verifying signatures in the context of tapscript script path spends are in BIP342.
<DavidBakin>
yes sipa I get that! tells you what to DO with a 65 byte one - doesn't tell you the circumstance when you CREATE one OR that the 65'th byte is the hash type (if non zero). I hope I'm not being really stupid.
<DavidBakin>
but I _did_ find it in the CODE of taproot_sign_key not in the descriptive text
<sipa>
Oh, the BIPs don't really describe the creation. They're specifying the validation rules, not construction.
<sipa>
There is some context that explains common usage, but that's not really the full description of everything one could do with these BIPs... that'd be unbounded.
<sipa>
But fair enough, how to sign with specified sighash type might be worth including.
<DavidBakin>
i do get that but I nevertheless submit that somewhere there could be a little sentence that said in English "signatures are 65 bytes - the 64 bytes from BIP-340 plus the hash-type, unless the hash type is 0 in which case it is elided" - but that's ok it is in the code
<sipa>
Agreed.
<DavidBakin>
however, something NOT in the code, or, AFAICT, in the text, is that the low order bit of the leaf version byte is the parity bit. Becuase in the code taproot_tweak_pubkey returns it as a multi-valued return (it's the first element of a pair) but in taproot_output_script where that function is _used_ (only place I can see it used) that first element of the pair is thrown away
<sipa>
If q ≠ x(Q) or c[0] & 1 ≠ y(Q) mod 2, fail[10].
<sipa>
That's where it is used in the specification text.
<sipa>
"c[0] & 1" is the parity bit.
<sipa>
In the text about construction below it says.
<sipa>
To spend this output using script D, the control block would contain the following data in this order:
<sipa>
<control byte with leaf version and parity bit> <internal key p> <C> <E> <AB>
<DavidBakin>
well yes I see that but it's the same issue with obscurity - you've got to really know what's going on before you know what's going on ... for example, right after the line "let v = c[0]&0xfe" and call it the _leaf version_" there could be a line "let pubpar = c[0]&0x1 and call it the _public key parity" - that would sort of help
<sipa>
In any case, if you feel there is text that would have made this more clear to you, feel free to open a PR against the BIP.
<DavidBakin>
ah! didn't know you could do that with PRs that were already accepted - OH WAIT these Taproot PRs are still Draft. ok, i'll do that and see what the reviewers say (such as you I suppose, eh?)
<sipa>
They probably should be moved off being Draft at this point.
klement has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sipa>
But even then, clarifications may be accepted if they don't change the specification.
<sipa>
BIP changes are approved by the authors of the BIP (and the editor who decides if procedure is followed).
<DavidBakin>
eeh, I jumped right over that <control byte ... and parity bit> - ok, i'm clear now (at least on this stuff) thank you all!
<DavidBakin>
(i will do a PR though)
<sipa>
Cool, thanks!
furszy has joined #bitcoin-core-dev
klement has joined #bitcoin-core-dev
realies has joined #bitcoin-core-dev
vysn has quit [Ping timeout: 244 seconds]
<sipa>
davidbakin: The parity bit is mentioned in the signing code section too, actually:
<bitcoin-git>
bitcoin/master a4741bd Cory Fields: kernel: pass params to BlockManager rather than using a global
<bitcoin-git>
bitcoin/master 636991d laanwj: Merge bitcoin/bitcoin#25264: kernel: pass params to BlockManager rather th...
<bitcoin-git>
[bitcoin] laanwj merged pull request #25264: kernel: pass params to BlockManager rather than using a global (master...no-kernel-global-params) https://github.com/bitcoin/bitcoin/pull/25264
<laanwj>
is there anything else that people would like to discuss?
<_aj_>
would it be good to add a "what people are working on" section to the meeting every now and then?
<dongcarl>
ACK
<laanwj>
sure, if you'd like that
vysn has joined #bitcoin-core-dev
<laanwj>
#topic What are people working on
<sipa>
ACK topic :)
<_aj_>
we had the lightnign summit the past few days; which will presumably have the notes published sometime. seems like there'll be progress getting funding txs moved to taproot / musig2; also a bunch of discussions about rbf and package relay ideas
<laanwj>
oh, neat!
<_aj_>
instagibbs in particular is working on actually implementing eltoo as his job(!) so working on getting an anyprevout testbed for him to build that on
<dongcarl>
woah that's awesome if he can pull it off
<sipa>
I've been working on writing a "production" codebase in Python for working with asmap on https://github.com/sipa/asmap/commits/nextgen. It currently has a module that can decode/encode/diff binary asmap files, tests, command-line tools for interfacing with that, plus gathering/collecting/processing BGP dump files into asmap.
<sipa>
It still needs some polishing, but it's getting there, at which points I'll be pinging some people for review.
<laanwj>
we've already been using the new Python asmap module in #24864, to replace the DNS based ASN lookup for the hardcoded seeds
<sipa>
Also continued review of the PRs darosior has been working on to get Miniscript integrated into Bitcoin Core.
<sipa>
Also, spec work on BIP324 (v2 p2p transport) with dhruv and real_or_random, hopefully public soon.
<sipa>
Oh, and I did a writeup on optional, private, authentication protocols like Countersign: https://github.com/sipa/writeups/tree/main/private-authentication-protocols. Actually proposing something like that is a way off, as I think it needs more academic rigour first (but that's being worked on too).
<laanwj>
speaking of that i've reviewed one of the BIP324 PRs today (#20962)
<gribble>
https://github.com/bitcoin/bitcoin/issues/20962 | Alter the ChaCha20Poly1305@Bitcoin AEAD to the new specification by jonasschnelli · Pull Request #20962 · bitcoin/bitcoin · GitHub
<laanwj>
interesting, good to hear the authentication side is also still being worked on
Talkless has quit [Quit: Konversation terminated!]
<laanwj>
thanks for the updates _aj_ dongcarl and sipa
<laanwj>
anyone else that'd like to discuss what they're working on? any other topics?
<dongcarl>
I think we can probably have these "what are people working on" things as a convention for after the meeting? Don't want it to impose a burden on laanwj.
<jeremyrubin>
i think it would be good to have regular updates from each maintainer on how they are prioritizing their time / what PRs they are focused on merging?
<laanwj>
it doesn't burden me to discuss it during the meeting really, also we have very few topics lately
<dongcarl>
laanwj: Okay cool!
<_aj_>
i'd love to hear what fanquake/laanqj/marco are prioritising (assumign it's something specific not just highpri and things people say are rfm of course)
<_aj_>
laanwj
<laanwj>
i've been looking into BIP324, and catching up with the libbitcoin kernel stuff
<_aj_>
(the qml gui stuff seems interesting and i hadn't been aware of it at all)
<hebasto>
_aj_: thanks!
<dongcarl>
hebasto: you think it's possible we'll use qt6 some day?
<laanwj>
i've also tried to review #22702 but it scared me a bit
<hebasto>
dongcarl: maybe switching to cmake will help a lot
realies has quit [Quit: ~]
<hebasto>
as cmake is "native" for Qt 6, besides other benefits, of course
<jonatack>
laanwj: read your feedback, i've been remiss in not re-reviewing that one yet but it seems like a valuable performance improvement. Do you think it's too dangerous, or it needs more testing and eyes?
<_aj_>
is switching to cmake likely or pie-in-the-sky? if likely, is there a gentle introduction to cmake somewhere? :)
<laanwj>
jonatack: the performance improvement is very nice but it's so tricky
<sipa>
@laanwj I need to look at the latest code changes again, but I'm very concept ACK on that allocator.
<jonatack>
laanwj: (have been running it without issues as well)
<sipa>
IIRC my biggest gripes with it were code organization related things.
<_aj_>
hebasto: oh, if dlls "just work" that is a big side benefit
<hebasto>
_aj_: indeed :)
<laanwj>
i'm just afraid that we'll mess up somewhere with this kind of low level allocation handling, to be clear i'm not against it, but we need to be really sure it gets enough review, that we even have enough developers that can review code like that
<_aj_>
laanwj: maybe we should do an advanced version of the pr review club on it?
<laanwj>
_aj_: yeah maybe!
<jonatack>
sipa: thanks, good to know. Last time I looked it appeared to have been reworked to an extent that a diff review wasn't too feasible, needed a full re-review for me
<laanwj>
dlls don't 'just work' i dont believe u!
<sipa>
haha
<hebasto>
laanwj: feedback is always welcome :)
<laanwj>
speaking of dlls, i wonder if we can stop exporting unnecessary symbols from libbitcoin_consensus, it exports all kinds of c++ library symbols at the moment
<luke-jr>
"fully static DLLs" is not a normal thing
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<laanwj>
ideally we'd only export bitcoinconsensus_*, _init and _fini, nothing more
<laanwj>
i guess that concludes the meeting, thanks for attending everyone
<laanwj>
#endmeeting
Guest38 has joined #bitcoin-core-dev
Guest38 has quit [Client Quit]
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
<jarolrod>
seems like my bouncer wasn't working before
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<jarolrod>
_aj_: thanks! we took a little break in the middle, but we've picked up steam on the qml gui again, and hope to have something to showcase to the community fairly soon