<Guest25>
hi, im on Mac attempting to verify 22.0. is the walkthrough information correct? I'm getting Primary key fingerprint: 74E2 DEF5 D772 60B9 8BC1 9438 099B AD16 3C70 FBFA
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
earnestly has quit [Ping timeout: 268 seconds]
mersible has quit [Quit: Leaving]
bitdex has joined #bitcoin-core-dev
saranshsharma has joined #bitcoin-core-dev
saranshsharma has quit [Ping timeout: 268 seconds]
<harding>
Re: verification instructions, I just opened a PR to temporarily hide them until they can be updated. If I can get a couple approach ACKs from established contributors in the next hour or two, I'll merge tonight. https://github.com/bitcoin-core/bitcoincore.org/pull/796
<harding>
FWIW, I don't know when I'll have time to update the instructions. I'm happy to do the GNU/Linux instructions, but the Windows and Mac instructions are a PITA for me and my enthusiasm for supporting people who choose to use those systems is pretty low at the moment.
<sipa>
harding: thanks for being on top of it, and can't blame you
<harding>
sipa: well, if I was on top of it, I would've addressed this a month ago when the Guix building change was made. :-) But thanks for the concept ACK!
<prayank>
harding: I can do for Windows if I know instructions for Linux. Not because I love Windows or want people to use it, but it's used by lot of people so maybe it helps few.
<harding>
prayank: great, thank! I'll give you ping when I have Linux instructions.
<prayank>
Okay
<luke-jr>
shouldn't the old instructions work better now?
<luke-jr>
hmm, the file is missing the actual content for 22.0
<harding>
luke-jr: what old instructions?
<luke-jr>
is that intentional?
<luke-jr>
the ones being hidden
<harding>
luke-jr: for 0.21.1, they worked. For 22.0, they don't work. How can that be working better?
<luke-jr>
they should work, but the file is wrong
<harding>
luke-jr: yep, that sounds like not working to me.
<luke-jr>
it's not the instructions that are the issue though
<harding>
luke-jr: yeah, ok, somebody moved the cheese.
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] jarolrod opened pull request #22966: doc: Improve documentation around the ACK statement (master...ack-documentation) https://github.com/bitcoin/bitcoin/pull/22966
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
cdecker has joined #bitcoin-core-dev
<sipa>
luke-jr: for better or worse, and intentionally or not, the build artefects now have a SHA256SUMS and .asc file, where the .asc file is a detached signature rather than clearsigned data. The instructions should explain how those artefacts can be verified
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
setuix has quit [Quit: rm -rf]
earnestly has joined #bitcoin-core-dev
babasancheti has joined #bitcoin-core-dev
vysn has joined #bitcoin-core-dev
tla2k21 has quit [Remote host closed the connection]
tla2k21 has joined #bitcoin-core-dev
prayank has quit [Read error: Connection reset by peer]
sipsorcery has joined #bitcoin-core-dev
<laanwj>
a single clearsigned-file solution prohibited merging multiple independent signatures into one file, because it forces everyone to use the same signature algorithm (which is specified at the top, e.g. Hash: SHA512), whereas in this case they can simply be cat'ed
<laanwj>
also detached signatures have some advantages with regard to security: everyone signs *the entire file*, there's no "outside the boundaries of the ======== area" where arbitrary information can be added
<laanwj>
so yes, the change is intentional
<laanwj>
we've combined all kinds of changes in the process in one go (with the gitian->guix build switch) to avoid repeated disruption
saranshsharma has joined #bitcoin-core-dev
<laanwj>
of course, updating the documentation and verification instructions is still important, but it should be a one-time thing. I did have a note on verifying the binaries in the testing instructions here: https://github.com/bitcoin/bitcoin/issues/22634
saranshsharma has quit [Ping timeout: 268 seconds]
<fanquake>
In regards to other in-progress releases: we should get some binaries out for 0.20.2rc3. Have got a 5 gitian builders for that tag so far.
<fanquake>
For 0.21.2. I think it's a question of whether we want to add the backports in #22858 (mentioned in #22720), and do an rc3?
<lucaferr>
What is required to submit taproot/P2TR transactions on testnet? I'm probably posting invalid data but getting rejects from neigbouring nodes. Does a particular node flag need to be enabled or anything else I may be missing?
sipsorcery has quit [Ping timeout: 268 seconds]
Guyver2 has joined #bitcoin-core-dev
goatpig has joined #bitcoin-core-dev
<_aj_>
lucaferr: you need neighbouring nodes that have upgraded to support taproot; "bitcoin-cli getpeerinfo | grep subver" -> look for 0.21.1 or 0.21.99 or 22.0.0 or 22.99.0
<lucaferr>
_aj_: ah, ok. thank you!
<_aj_>
lucaferr: alternatively, use signet instead of testnet
<laanwj>
i have trouble keeping track tbh we have to many releases in process at once
<laanwj>
i'll look into uploading the binaries for 0.20.2rc3 (first need to build them, i don't think i have them)
<fanquake>
laanwj: thanks. Yea it just happened that we ended up with 3 in parallel
lkqwejhhgasdjhgn has joined #bitcoin-core-dev
vysn has quit [Quit: WeeChat 3.2]
vysn has joined #bitcoin-core-dev
babasancheti has quit [Quit: Client closed]
<laanwj>
fanquake: thanks for keeping track of them anyhow :)
vnogueira has quit [Remote host closed the connection]
<bitcoin-git>
bitcoin/master b5ede2a Hennadii Stepanov: Merge bitcoin-core/gui#418: fix bitcoin-qt app categorization on apple sil...
<bitcoin-git>
bitcoin/master 3765c48 Jarol Rodriguez: qt: fix bitcoin-qt app categorization on apple silicon
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
midnight has quit [Ping timeout: 240 seconds]
cold has quit [Ping timeout: 250 seconds]
cold has joined #bitcoin-core-dev
midnight has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #22970: doc: Update snap release process for new versioning scheme (master...2109-docSnapRel) https://github.com/bitcoin/bitcoin/pull/22970
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Henrik has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
<laanwj>
doesn't look like v0.20.2rc3 has detached sigs yet? wasn't able to build codesigned mac+win
<fanquake>
Guess we need to ping achow101 and jonasschnelli
<hebasto>
achow101 already pushed signatures
sipsorcery has quit [Remote host closed the connection]
sipsorcery has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Henrik has joined #bitcoin-core-dev
goatpig has quit [Quit: Konversation terminated!]
Guest4838 has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] theStack opened pull request #22972: test: fix misleading fee unit in mempool_limit.py (master...202109-test-fix_confusing_fee_calculation_in_mempool_limit) https://github.com/bitcoin/bitcoin/pull/22972
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Guest4838 has quit [Client Quit]
common has quit [Ping timeout: 265 seconds]
Guyver2 has joined #bitcoin-core-dev
kexkey has quit [Ping timeout: 265 seconds]
kexkey has joined #bitcoin-core-dev
<lucaferr>
for schnorr signatures, how does libsecp256k1 deal with the zero k' case. I see some conditional moves which I cannot make sense of in the source code. Does it mean it will make a different random value to avoid the zero case?
<sipa>
lucaferr: yes, it replaces k=0 with k=1, but honestly - it doesn't actually need to
<lucaferr>
you mean the statistics of it?
<sipa>
at least with the BIP340 default nonce function, k=0 will +-never be reached
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
prayank has joined #bitcoin-core-dev
prayank has quit [Ping timeout: 268 seconds]
sipsorcery has quit [Ping timeout: 268 seconds]
sipsorcery has joined #bitcoin-core-dev
vysn has quit [Quit: WeeChat 3.2]
yanmaani1 has quit [Remote host closed the connection]
yanmaani1 has joined #bitcoin-core-dev
roconnor has joined #bitcoin-core-dev
Victorsueca has quit [Read error: Connection reset by peer]
<roconnor>
Let me know if this is the wrong place for this question, but what's up with the new SHA256SUMS.asc which ... doesn't appear to be sha256sums?
<roconnor>
Are there new verification instructions?
<sipa>
also, see backlog here with comments by laanwj, around just under 12 hours ago
<roconnor>
I see. And if I understand the Binary Release signing key isn't amoung the signature and won't be used going forward, and I could, for example purposes only, delete it.
Talkless has quit [Quit: Konversation terminated!]
<achow101>
roconnor: the release key should be used for 0.20.2 and 0.21.2 since those will use the old release process
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] div72 opened pull request #22975: scripted-diff: update license URLs to https (master...https-copyright-header) https://github.com/bitcoin/bitcoin/pull/22975
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<roconnor>
achow101: oh that's what this "new major releases" wording is refering to. I get it now.
<andytoshi>
if anyone here is an op on #bitcoin-wizards (i'm a little concerned that nobody is since the libera move..) there is a troll
<andytoshi>
and also could i pls be put back on the op list
first_mersible has joined #bitcoin-core-dev
second_mersible has joined #bitcoin-core-dev
mersible has quit [Ping timeout: 268 seconds]
first_mersible has quit [Ping timeout: 240 seconds]
first_mersible has joined #bitcoin-core-dev
Guyver2 has quit [Ping timeout: 268 seconds]
second_mersible has quit [Ping timeout: 240 seconds]
second_mersible has joined #bitcoin-core-dev
first_mersible has quit [Ping timeout: 252 seconds]
AaronvanW has quit [Remote host closed the connection]
<BlueMatt>
with the multi-signature stuff there really needs to be a decent script to fetch the relevant pgp keys, ensure that N-of-M of them have signed, and some kind of way to verify the trust of at least some of those keys.
<BlueMatt>
imo
<BlueMatt>
its kinda hard to verify this release, mostly because pgp is completely and totally hosed cause all the keyservers now strip signatures :(
<BlueMatt>
so I cant manage to find signatures for any of these keys :'(
<sipa>
yeah
<BlueMatt>
not that that's core's problem so much, but at least wkd support for the keys that sign releases with sigs in the wkd versions would be nice
<BlueMatt>
so that there's *some* way to download them with sigs
<BlueMatt>
or maybe just put them all in repo or on bitcoincore.org (iirc there's already keys in repo, or used to be)
<BlueMatt>
so that at least you have a trust path from eg one of the signers to the rest
bomb-on has joined #bitcoin-core-dev
<BlueMatt>
eg I only have a trust path to like 2 or three of the keys that signed 22, I'd be ok with that if the script just told me "Verified with 2 of the N keys which signed the release, the two you verified are A and B"
<achow101>
perhaps it would be reasonable for the previous release key to sign several guix builder keys?
<BlueMatt>
that would be nice too, but i think we need to work around the broken keyservers as step 1
<roconnor>
(I don't even want to know how that is possible)
<achow101>
we used to have keys in the repo, but I think we kept running into expiry problems
<BlueMatt>
achow101: the nice bit of using a custom verify script is you can treat expired-key-sigs as valid :p
<BlueMatt>
which iirc verify-commits does
<BlueMatt>
in some form or another
bomb-on has quit [Client Quit]
mersible has joined #bitcoin-core-dev
second_mersible has quit [Ping timeout: 240 seconds]
<roconnor>
having the old build signing key somehow in the chain of custody of this release, e.g. what achow101 suggests, would certainly bring me some comfort in this transition.