--- Log opened Wed Aug 04 00:00:28 2021
00:53 -!- b10c [uid500648@id-500648.charlton.irccloud.com] has joined #bitcoin-core-builds
01:02 -!- belcher [~belcher@user/belcher] has quit [Remote host closed the connection]
01:06 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-builds
01:18 -!- belcher [~belcher@user/belcher] has quit [Read error: Connection reset by peer]
01:25 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-builds
02:47 < jonasschnelli> still having troubles with my guix build
02:47 < jonasschnelli> can someone provide me: b0f7f7efaca2c888f4ce68bb455e2bd895c1d019fe435a14f70d9221107c3d5b  x86_64-apple-darwin18/bitcoin-22.0rc2-osx-unsigned.tar.gz?
02:47 < jonasschnelli> (fanquake, achow101, hebasto). Thankx
02:50 < hebasto> jonasschnelli: sure, uploading
02:51 < jonasschnelli> thanks hebasto 
02:52 < hebasto> jonasschnelli: https://drive.google.com/file/d/1Y0kJ2X7z9Co4eFpgBnq0d-5NzjRxN-Fq/view?usp=sharing
02:53 < jonasschnelli> hebasto: google denies the link... 
02:54 < jonasschnelli> (against the terms)
02:58 < hebasto> jonasschnelli: https://github.com/hebasto/artefacts/blob/master/bitcoin-22.0rc2-osx-unsigned.tar.gz
03:07 < hebasto> jonasschnelli: does it work for you?
03:07 < jonasschnelli> works yes. Thanks hebasto 
03:07 < hebasto> yw
03:33 < jonasschnelli> achow101: I pushed the 22.0rc2 macOS signature (not made a tag yet). For the first time, I have signed on an ARM64 mac. Can you (or someone else) test the signature before tagging? Thanks
03:53 < hebasto> jonasschnelli: I've applied signature with `./contrib/guix/guix-codesign`, and checked resulted `bitcoin-22.0rc2-osx-signed.dmg` on macOS 11.5.1
03:53 < hebasto> also verified with `codesign --verify -v /Applications/Bitcoin-Qt.app`
03:54 < hebasto> everything looks green
04:01 < jonasschnelli> hebasto: thanks for testing!
04:01 < jonasschnelli> tag has been created: https://github.com/bitcoin-core/bitcoin-detached-sigs/tree/v22.0rc2
04:01 < jonasschnelli> happy building
04:01 < hebasto> \o/
04:10 < hebasto> dongcarl: does `guix-attest` re-apply signature to the previous `noncodesigned.SHA256SUMS`? if so how to avoid it?
04:10 < hebasto> context -- conflict in https://github.com/bitcoin-core/guix.sigs/pull/69
04:28 < hebasto> dongcarl: nm, I've sorted it out, it was my mistake
04:35 < hebasto> the simple guide for guix builders has just been updated -- https://gist.github.com/hebasto/7293726cbfcd0b58e1cfd5418316cee3
05:14 < laanwj> just committed my all.SHA256SUMS, looks like they match up to now
05:14 < laanwj> all three
05:15 < laanwj> four!
05:15 < fanquake> yes I just merged my own heh
05:16 < fanquake> Looks like we are on track to get an rc2 out the door, and hopefully, get some people testing
05:19 < laanwj> let's see if i can get the SHA256SUMS.asc concatentation to work
05:19 < hebasto> sipa: where I can download your public key `3EB0DEE6004A13BE5A0CC758BF2978B068054311` from? (this key was used for guix builds)
05:21 < laanwj> how do i combine all signers signatures into one?
05:21 < laanwj> release-process.md only mentions one SHA256SUMS.asc
05:22 < laanwj> and a "filename.txt.asc"
05:34 < laanwj> would it make sense to move from a in-line signature to shipping a SHA256SUMS and a SHASUMS.asc which is "cat 22.0rc2/*/all.SHA256SUMS.asc > SHA256SUMS.asc"
05:35 < laanwj> this would change the verification instructions, but it's much easier to combine all the attestations and being able to verify them at once with "gpg --verify SHA256SUMS.asc SHA256SUMS" and no packet surgery
05:35 < laanwj> but maybe i'm missing something
05:40 < laanwj> (i've also had comments in the past that distributing SHA256SUMS with detached signature might be less error-prone for gpg validation, as it doesn't allow for adding any additional stuff outside the ==SIGNED MESSAGE== delimiters, but otoh it involves downloading two instead of one file so might reduce the number of people who verify in the first place—)
05:44 < sipa> hebasto: http://bitcoin.sipa.he/pieterwuille.asc
05:47 < hebasto> sipa: thanks
05:51 < laanwj> this doesn't seem to work:  echo -e "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\n$(cat 22.0rc2/laanwj/all.SHA256SUMS)\n$(cat 22.0rc2/*/all.SHA256SUMS.asc)" > SHA256SUMS.asc     it gives a "signature digest conflict in message"
05:52 < laanwj> i guess because of the Hash: SHA256 in the first line, all following signatures need to use that
05:52 < hebasto> sipa: s/sipa.he/sipa.be/ :)
05:52 < laanwj> which is pretty absurd, i'll just ship a separate file with signatures for now
06:55 < laanwj> ahhhhh, but to verify the bare SHA256SUMS it needs to be piped through dos2unix otherwise sha256sums -c will get confused
07:49 < laanwj> rc2 binaries up https://bitcoincore.org/bin/bitcoin-core-22.0/test.rc2/
07:49 < sipa> laanwj: do you have risc-v hardware that you can benchmark things on?
07:50 < laanwj> sipa: yes!
07:54 < sipa> laanwj: https://github.com/sipa/secp256k1/commits/5x64, could you try ./configure;make;./bench_verify, on the tip of that branch, the commit before it, and upstream master?
07:55 < laanwj> for rv64 i have a sifive unleashed, sifive unmatched, and can spin up 32-bit risc-v cores on FPGA but that's somewhat more involved
07:55 < laanwj> sipa: sure
07:57 < sipa> laanwj: context is a different representation for (64 bit) field elememts
07:57 < sipa> which seems to be a loss on x86 for pure C code, but a win when comparing optimized asm code
07:57 < sipa> and a win overall (even just C) on aarch64
07:58 < sipa> but a huge slowdown (1.5x-2x) on ppwer9
07:59 < sipa> so we may need either asm optimization to not cause a slowdown there, or keep multiple field representations around...
08:00 < sipa> laanwj: this is just for platforms that have a __int128, which afaik is just 64-bit ones
08:33 < laanwj> sipa: are you also interested in ecdsa_verify_openssl? (this takes *a long time* on this platform)
08:34 < sipa> voh, no!
08:34 < sipa> --disable-openssl-tests will avoid that, iirc
08:35 < laanwj> will do
09:16 < laanwj> 5x64: ecdsa_verify: min 321us / avg 321us / max 321us
09:16 < laanwj> 5x64~1: ecdsa_verify: min 298us / avg 299us / max 299us
09:16 < laanwj> master: ecdsa_verify: min 326us / avg 326us / max 326us
09:17 < sipa> interesting!
09:17 < sipa> thank you
09:18 < sipa> so of all platforms tested, only power9 and x86_64 slow down with the new code (ignoring asm optimizations)
09:23 < laanwj> interesting to see so much platform difference in how code gets compiled
09:25 < sipa> it's very dramatic; on x86_64 it's a 20% slowdown, on aarch64 a 20% win, in riscv it seems here like a 10% win; on power9 it's almost a 100% slowdown
09:25 < sipa> that may be more a case of different amounts of efforts put into platform-specific compiler optimization than actual platform differences of course
09:26 < laanwj> riscv32 doesn't have __int128 (as expected)
13:26 < dongcarl> laanwj: Hmmm thinking about your "would it make sense to move from a in-line signature..." comment. I actually think it's a great idea since we can get rid of the EOL "hacks" and combine signatures easily...
13:27 < dongcarl> The concern about less people doing verification can be mitigated by adding a little snippet on the website similar to how there's a snippet for: " Refresh expired keys using:"
14:55 < harding> You already have to download two files (the binaries and the shasums), so downloading three files doesn't seem like a big ask.
14:59 < harding> Actually, it might be kind of nice if each binary was signed directly, that way verifiers could skip the shasum step.  You'd just do gpg --verify bitcoin-22.0rc2-x86_64-linux-gnu.tar.gz.asc bitcoin-22.0rc2-x86_64-linux-gnu.tar.gz
16:08 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 244 seconds]
17:35 < luke-jr> dongcarl: eh? isn't EOL just as much a problem without the sigs being inline?
17:37 < luke-jr> one file or two, they still need to match
17:38 < luke-jr> harding: without the SHA256SUMS stage, it's more of a nuisance to sign offline I think?
17:39 < harding> luke-jr: I dunno.  Do you hand transcribe the shasums file?  If not, copying 10 files ain't much different to my mind than copying 1 file.
17:41 < luke-jr> 10 very huge files ;)
17:41 < harding> That said, if someone is signing with a yubikey or one of those ancient PGP card reader things, it would be good to test if the entire binary needs to be copied to the reader and so maybe I/O bandwidth is a deal.
17:42 < luke-jr> I wonder if GPG can generate some kind of minimal half-signature
17:42 < luke-jr> though I suspect it would make more sense for GPG to just integrate the SHA256 summing
18:58 -!- b10c [uid500648@id-500648.charlton.irccloud.com] has quit [Quit: Connection closed for inactivity]
19:25 -!- belcher_ [~belcher@user/belcher] has joined #bitcoin-core-builds
19:28 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 240 seconds]
--- Log closed Thu Aug 05 00:00:29 2021