--- Day changed Thu Aug 18 2016 00:00 < jonasschnelli> And store ECDSA pubkeys of each gitian builder in our bitcoin/bitcoin git 00:00 < wumpus> the idea with adding ecdsa signatures in addition to gpg signatures, which can be easier to verify by an external program that doesn't want to embed the entire gpg shebang 00:00 < wumpus> yes 00:01 < wumpus> a user friendly gitian verifyer could be useful 00:01 < jonasschnelli> Built into an already verified binary would be nice 00:02 < wumpus> well it doesn't so much need to be part of the binary, could be a separate tool part of the distribution 00:02 < jonasschnelli> Once you have verified with the gitian-verifier, you have a trusted chain of updates 00:02 < jonasschnelli> Yes. Could be seperated... 00:02 < jcorgan> it would also be useful to have the current release signature depend on the previous one, to form a hash chain of sorts 00:02 < jonasschnelli> but should be built from the git repo where the ECDSA pubkeys are and also built over gitian 00:03 < wumpus> jonasschnelli: agreed 00:03 < wumpus> jcorgan: does that improve security? attackers can just as easily include a link to the previous signature 00:04 < GitHub31> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a78f95a976de...671fdae5f5b3 00:04 < GitHub31> bitcoin/master fa0afde MarcoFalke: [travis] Drop java 00:04 < GitHub31> bitcoin/master 671fdae Wladimir J. van der Laan: Merge #8534: [travis] Drop java... 00:04 < GitHub13> [bitcoin] laanwj closed pull request #8534: [travis] Drop java (master...Mf1608-qaJava) https://github.com/bitcoin/bitcoin/pull/8534 00:05 < jcorgan> sure. it would just demonstrate an unbroken chain of release binaries, for those willing to verify current vs. prior. 00:06 < jcorgan> admittedly, that seems like a very few people nowadays. 00:06 < wumpus> right, although otoh people may be better off looking for the prior release themselves, then blindly trusting the (potentially faked) link 00:11 < jcorgan> hard to ensure other's choices, only possible to give them the information needed to make good ones 00:13 < wumpus> the segwit.py test is very broken in travis 00:13 < wumpus> somehow not locally though 00:15 < btcdrak> wumpus: travis randomly fails tests atm 00:15 < wumpus> random tests? 00:16 < btcdrak> look at jl2012 PR yesterday https://travis-ci.org/bitcoin/bitcoin/builds/153047455 00:16 < wumpus> that's also segwit.py failing 00:16 < btcdrak> the same build fails different tests 00:16 < wumpus> and txn_doublespend 00:17 < wumpus> looks like I reported the issue correct then here https://github.com/bitcoin/bitcoin/issues/8532 00:17 < jl2012> I suspect that's related to the low s patch by sipa 00:17 < wumpus> "Looks like with the reduced delay from fa2d68f, the nodes sync up before the txns all make it into the wallet" 00:17 < wumpus> according to cfields 00:17 < sipa> that failing segwit test was introduced in #8489 iirc 00:18 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:18 < btcdrak> i think Cory nailed it 00:18 < jl2012> Without his patch, bip164-p2p.py will fail 00:19 < sipa> btcdrak, wumpus: but if shorter delays trigger errors, the tests are wrong 00:19 < sipa> they shouldn't rely on timings 00:19 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 00:20 < wumpus> that's a good point, but we need to do something to make the travis failures go away, that could be fixing the tests, but reverting the timeout change may be quicker 00:20 < wumpus> if fixing the tests is straightforward (it's always those two) then I'm all for fixing them immediately, of course 00:21 < wumpus> the alternative would be temporarily disabling them in travis 00:21 < jl2012> By the way, they never fail on my mac 00:21 < wumpus> but I prefer reverting the timeout change to that, as at least something gets tested then 00:22 < wumpus> jl2012: I can't reproduce it locally either 00:22 < MarcoFalke> wumpus: Agree on temp. revert. I will try to look into this now but there is no eta for tha acutal fix 00:22 -!- Lysanders [~Lysanders@unaffiliated/lysanders] has joined #bitcoin-core-dev 00:23 < GitHub68> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/35f64e45c207960078eef58ccc50d91e4abc2c55 00:23 < GitHub68> bitcoin/master 35f64e4 Wladimir J. van der Laan: Revert "[qa] Adjust timeouts for micro-optimization of run time"... 00:29 < MarcoFalke> Thanks 00:33 < GitHub32> [bitcoin] MarcoFalke opened pull request #8536: [WIP] [qa] Adjust timeouts for micro-optimization of run time (master...Mf1608-qaOptSync) https://github.com/bitcoin/bitcoin/pull/8536 00:45 -!- arowser [~quassel@106.120.101.38] has quit [Remote host closed the connection] 01:08 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-waddqysdrbltxirq] has joined #bitcoin-core-dev 01:16 -!- Giszmo [~leo@2001:a61:32f6:9901:a4ce:f633:9464:fc9e] has joined #bitcoin-core-dev 01:31 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 02:25 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 02:28 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 252 seconds] 02:29 -!- Guyver2_ is now known as Guyver2 02:30 -!- JZA [JZA@gateway/shell/elitebnc/x-hntxrhbikwqnmkrt] has quit [Excess Flood] 02:47 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-core-dev 03:20 -!- laurentmt [~Thunderbi@80.215.138.171] has joined #bitcoin-core-dev 03:21 -!- laurentmt [~Thunderbi@80.215.138.171] has quit [Client Quit] 03:26 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds] 03:41 -!- harrymm [~wayne@46.165.228.92] has quit [Ping timeout: 265 seconds] 03:50 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 03:57 -!- harrymm [~wayne@223.204.247.35] has joined #bitcoin-core-dev 04:13 -!- harrymm [~wayne@223.204.247.35] has quit [Ping timeout: 250 seconds] 04:24 < GitHub88> [bitcoin] mcccs opened pull request #8537: Trivial: little typos (master...litttle-typos) https://github.com/bitcoin/bitcoin/pull/8537 04:29 -!- harrymm [~wayne@178.162.199.240] has joined #bitcoin-core-dev 04:42 -!- harrymm [~wayne@178.162.199.240] has quit [Ping timeout: 240 seconds] 04:54 < GitHub188> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/35f64e45c207...8250de13587e 04:54 < GitHub188> bitcoin/master b213535 Wladimir J. van der Laan: Squashed 'src/secp256k1/' changes from 6c527ec..7a49cac... 04:54 < GitHub188> bitcoin/master 0237096 Wladimir J. van der Laan: Merge commit 'b2135359b3ad37cf2ac09b008079ddb237eff2c9' 04:54 < GitHub188> bitcoin/master 8250de1 Pieter Wuille: Merge #8453: Bring secp256k1 subtree up to date with master... 04:54 < GitHub62> [bitcoin] sipa closed pull request #8453: Bring secp256k1 subtree up to date with master (master...2016_08_update_secp256k1) https://github.com/bitcoin/bitcoin/pull/8453 05:01 -!- harrymm [~wayne@178.162.214.34] has joined #bitcoin-core-dev 05:06 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer] 05:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:25 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-waddqysdrbltxirq] has quit [Quit: Connection closed for inactivity] 05:33 -!- YOU-JI [~youyouyou@y195128.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-core-dev 05:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 05:46 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 05:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:58 -!- YOU-JI_ [~youyouyou@FL1-119-243-250-95.chb.mesh.ad.jp] has joined #bitcoin-core-dev 05:58 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 05:59 -!- YOU-JI [~youyouyou@y195128.dynamic.ppp.asahi-net.or.jp] has quit [Ping timeout: 264 seconds] 06:03 -!- YOU-JI_ [~youyouyou@FL1-119-243-250-95.chb.mesh.ad.jp] has quit [Ping timeout: 260 seconds] 06:04 < GitHub101> [bitcoin] mcccs opened pull request #8538: Remove IP transaction check (master...Ip-check) https://github.com/bitcoin/bitcoin/pull/8538 06:06 -!- AaronvanW [~ewout@198pc231.sshunet.nl] has joined #bitcoin-core-dev 06:06 -!- AaronvanW [~ewout@198pc231.sshunet.nl] has quit [Changing host] 06:06 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:10 -!- JZA [JZA@gateway/shell/elitebnc/x-vevdlozdgxpjqcxp] has joined #bitcoin-core-dev 06:14 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-qhrexphgbbezbutv] has joined #bitcoin-core-dev 06:22 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 06:43 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 06:47 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 07:07 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 260 seconds] 07:09 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 07:23 -!- laurentmt [~Thunderbi@80.215.178.40] has joined #bitcoin-core-dev 07:24 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 07:25 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 07:25 -!- laurentmt [~Thunderbi@80.215.178.40] has quit [Client Quit] 07:31 < GitHub121> [bitcoin] mcccs closed pull request #8537: Trivial: little typos (master...litttle-typos) https://github.com/bitcoin/bitcoin/pull/8537 07:32 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 07:32 -!- rubensayshi [~ruben@82.201.93.169] has quit [Remote host closed the connection] 07:42 < jl2012> sipa: the rpc-test for https://github.com/bitcoin/bitcoin/pull/8533 seems ok now. I replaced you low_s signature hack with actually transforming the S value 07:43 < jl2012> probably because your patch takes longer to sign and it timeouts? 07:44 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 07:49 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 07:50 < jl2012> i think your patch double the signing time on average; and could take much longer with bad luck 07:54 < GitHub165> [bitcoin] crowning- opened pull request #8539: CDB: fix debug output (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8539 08:02 < GitHub103> [bitcoin] laanwj opened pull request #8540: qt: Fix random segfault when closing "Choose data directory" dialog (master...2016_08_qt_choosedatadir_crash) https://github.com/bitcoin/bitcoin/pull/8540 08:03 -!- Kexkey [~kexkey@184.75.213.131] has joined #bitcoin-core-dev 08:07 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-core-dev 08:20 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 08:22 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has quit [Read error: Connection reset by peer] 08:29 -!- mkarrer [~mkarrer@249.red-83-38-154.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 08:36 -!- zerobit [~nobits@rrmmtl.ca] has joined #bitcoin-core-dev 08:40 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:45 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 08:47 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 240 seconds] 08:48 -!- billotronic [~billotron@unaffiliated/billotronic] has joined #bitcoin-core-dev 08:50 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 08:58 -!- jujumax [~jujumax@host75.190-224-145.telecom.net.ar] has joined #bitcoin-core-dev 09:06 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 240 seconds] 09:09 -!- zooko [~user@50.246.213.170] has joined #bitcoin-core-dev 09:19 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev 09:20 -!- JZA [JZA@gateway/shell/elitebnc/x-vevdlozdgxpjqcxp] has quit [Excess Flood] 09:29 < cfields> jonasschnelli: ping. what's the easiest way to atomically retrieve the NodeId for the selected row in the peertable? 09:30 < cfields> jonasschnelli: for context, I'm moving the ban functionality around a bit, and to prevent ambiguity, i'd like to ban based on NodeId rather than address 09:32 < cfields> as a quick hack, I impelemented it by adding the NodeId as the first column in the table, so there's a quick path for lookup. But I'm not sure everyone would agree with the usefulness there. 09:41 -!- rubensayshi [~ruben@82.201.93.169] has quit [Remote host closed the connection] 09:42 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 09:46 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 09:47 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 09:52 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 09:56 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has quit [Ping timeout: 250 seconds] 09:56 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has joined #bitcoin-core-dev 10:02 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 10:08 < btcdrak> Regarding MS/APPL codesigning certificates. What about getting one issued in the name of MIT DCI? 10:14 < GitHub128> [bitcoin] leijurv opened pull request #8541: Trivial: Fix typos in various files (master...various-typos) https://github.com/bitcoin/bitcoin/pull/8541 10:22 -!- jujumax [~jujumax@host75.190-224-145.telecom.net.ar] has quit [Remote host closed the connection] 10:31 -!- adiabat [~adiabat@159.203.193.74] has quit [Remote host closed the connection] 10:31 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 10:34 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 10:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:40 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds] 10:40 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 10:48 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 10:53 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 11:02 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 11:02 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 11:05 < Chris_Stewart_5> In a merkle block it says we should never have two nodes with the same child hashes, however in a merkle tree if we have a an odd amount of txs we duplicate the last txid 11:06 < Chris_Stewart_5> isn't this conflicting? 11:07 < Chris_Stewart_5> 'However, if you find a node whose left and right children both have the same hash, fail. This is related to CVE-2012-2459.' wrt to Merkle blocks 11:10 < sipa> Chris_Stewart_5: if you have *two* subnodes, their hashes should be different 11:11 < sipa> because if that was the case, it would be indistinguishable from the case where there was only one subnode 11:21 -!- aalex [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer] 11:27 < jonasschnelli> cfields: could you solve the Qt table nodeid problem? 11:38 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 11:41 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 11:41 < cfields> jonasschnelli: no further along, wanted to get your preferred approach first 11:41 < jonasschnelli> okay... let me have a loog 11:41 < jonasschnelli> look 11:42 < cfields> jonasschnelli: great, thanks 11:42 < cfields> jonasschnelli: i can point you to my changes, if you'll promise to ignore the stuff happening around it :) 11:43 < cfields> (i'm trying to break out this part for its own PR) 11:43 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 11:44 < cfields> jonasschnelli: my attempt: https://github.com/theuni/bitcoin/commit/cfc8f2b6533e241258167af0da966cbe2e5e4d10#diff-a9100e8bfc1122159ae47eb2d2f3e6cf 11:44 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 11:45 < jonasschnelli> cfields: I like your approach,.. I just wanted to propose the same thing. 11:46 < jonasschnelli> maybe rename PeerTableModel::Id to PeerTableModel::NodeId 11:46 < cfields> jonasschnelli: ah, great. I'll break it out and PR then. Thanks! 11:46 < jonasschnelli> Id seems to generic (could imply a table row id or somethig) 11:46 < cfields> sure 11:46 < cfields> yes, makes sense 11:47 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 276 seconds] 11:50 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 11:50 -!- JackH [~Jack@79-73-188-45.dynamic.dsl.as9105.com] has quit [Remote host closed the connection] 11:52 < cfields> jonasschnelli: hmm, is there still a need for mapNodeRows, then? 11:52 < cfields> (I have no clue how fast searching rows is) 11:52 < jonasschnelli> depends if you still call int detailNodeRow = clientModel->getPeerTableModel()->getRowByNodeId(cachedNodeid); 11:53 < jonasschnelli> which is the "invers" function of row->nodeId 11:53 < jonasschnelli> it's nodeid->row 11:54 < cfields> jonasschnelli: right. Any reason not to just iterate all rows and look for the id rather than keeping a parallel map? 11:55 < jonasschnelli> Not sure how performant a iteration over all rows could be in a 128 connection situation 11:55 < cfields> or am i oversimplifying that? 11:55 < jonasschnelli> Maybe keep the map for now. 11:55 < cfields> ok, np. will keep it 11:55 < jonasschnelli> Can be evicted later 11:55 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 11:56 < sipa> connection count can go up to 900 or so if you raise maxconnections 11:57 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 276 seconds] 11:57 < jonasschnelli> Indeed... 11:57 -!- JZA [JZA@gateway/shell/elitebnc/x-bdjpkptyvaeumhxz] has joined #bitcoin-core-dev 11:58 < jonasschnelli> removing the map would probably require someone to test the performance in a 900connection environment... 11:58 < sipa> i expect it to still be perfectly fine 11:58 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 11:59 < btcdrak> meeting time 11:59 < jonasschnelli> Yes. Me 2. But I mostly follow the pradigm, only change what's necessary (especially if the diff is already large enought) 12:00 < MarcoFalke> meeting time! 12:00 < sipa> *ding* 12:00 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier 12:00 < wumpus> #meetingstart 12:00 < kanzure> how do i know the ping is the real ping? 12:00 < wumpus> #startmeeting 12:00 < lightningbot> Meeting started Thu Aug 18 19:00:19 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:00 < jonasschnelli> proposed topic: core internal binary signing and verification tool 12:00 < sipa> kanzure: its twitter handle is therealping 12:00 < wumpus> kanzure: it comes from gmaxwell, who the offical meeting-pinger, and he is authenticated with freenode 12:01 < btcdrak> how do we know freenode is still free? 12:01 < wumpus> because otherwise it would be renamed to restrictednode 12:01 < luke-jr> jonasschnelli: a tool would be nice, but there is no reason for it to be internal 12:01 < jonasschnelli> there are 12:01 < jonasschnelli> (to be covered under gitian) 12:01 < wumpus> #topic core internal binary signing and verification tool 12:02 < luke-jr> you can gitian-build things besides Bitcoin 12:02 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev 12:02 < jonasschnelli> I propose to add to cli tools to the bitcoin-core package 12:02 < kanzure> off-topic, but does anyone know the status of deterministic debian efforts? 12:02 < jonasschnelli> bitcoin-core-verify and bitcoin-core-sign 12:02 < jonasschnelli> The later will not be shipped 12:02 < jonasschnelli> bitcoin-core-verify -> 1) hashes file(s) 2) download gitian assets files together with ECDSA sigs 3) verify hashed against downloaded assets files 4) verify assets ECDSA sigs against in-binary-pubkeys (dev-name/pubkey) 12:02 < jonasschnelli> bitcoin-core-verify will list valid signatues of devs by listing devs name. 12:02 < wumpus> I suppose it will be a separate executable within the bitcoin core distribution, other software can also include it if they want, but that's not initially very important 12:02 < btcdrak> jonasschnelli I think it needs to be GUI for wider adoption. 12:03 < jonasschnelli> Yes. It would be a Qt tool for one major reason 12:03 < gmaxwell> Please don't do design in the meeting. 12:03 < jonasschnelli> https downloads 12:03 -!- harrymm [~wayne@178.162.214.34] has quit [Ping timeout: 265 seconds] 12:03 < jonasschnelli> gmaxwell: okay. fair enought... 12:03 < gmaxwell> I'm planning on having someone work on that. 12:03 < btcdrak> jonas is already building something afaik 12:03 < wumpus> yes it needs https support to get at the signatures from github 12:03 < jonasschnelli> Yes. But happy to pause. 12:04 < gmaxwell> If it does https I will nak it so hard keys will fall of the keyboard. 12:04 < jonasschnelli> Qt would have https support built in 12:04 < jonasschnelli> the gitian sigs come over https 12:04 < gmaxwell> We _cannot_ ship some downloading tool that is going to require frequent CVEs itself. 12:04 < wumpus> it's not a downloading tool 12:04 < jonasschnelli> either with git or with https 12:04 < MarcoFalke> So how do you verify bitcoin-core-verify? 12:04 < wumpus> just a verification tool 12:04 < wumpus> MarcoFalke: it'd be part of the distribution 12:04 < btcdrak> no need for https when you have cryptographic verification 12:04 < gmaxwell> What btcdrak said. 12:04 < jonasschnelli> I guess even if https is broken, nobody can upload valid EC sigs 12:05 < btcdrak> https _is_ broken 12:05 < jonasschnelli> https is required to download from github I guess 12:05 < wumpus> well if you can get information from github through http that would work too 12:05 < jonasschnelli> Yes. TLS is not required for security. 12:05 < luke-jr> the git protocol isn't encrypted I think 12:05 < btcdrak> actually I think it's impossible to fetch from github without https, you'd have to use the git:// ptrotocol 12:05 < wumpus> you seriously wouldn't want to implement the git protocol 12:06 < cfields> wumpus: distribution == our release? Or OS? 12:06 < jonasschnelli> he. yes. no git:// please 12:06 < wumpus> cfields: yes, our releases 12:06 < jonasschnelli> The only concern is – and this is why i borugh it up – the ec-pubkeys together with dev-name should be placed in bitcoin/bitcoin 12:06 < wumpus> otherwise you'd have to host the signatures somewhere else than github, which is possible of course, but is a change in the release process 12:06 < jonasschnelli> somewhere where it could be used in cpp source code (probably in a header) 12:07 < wumpus> well the gpg keys are already in the respository 12:07 < jonasschnelli> this would allow to build a "trusted-chain" of bitcoin-core binaries 12:07 < cfields> mm. Can we back up then and address what this is aiming to solve? What protects against someone re-packaging a malicious release along with a clone "verification tool" that always passes? 12:07 < kanzure> an email to the mailing list about verification procedures seems prudent at some point, as a general reminder. i'm sure there's existing content somewhere that can be copied for these purposes. 12:07 < jonasschnelli> cfields: Sure. Thats always possible 12:07 < btcdrak> just confirmed github forces https redirection 12:07 < MarcoFalke> So bitcoin-core-verify checks the release, but is part of the release... Isn't this circular? 12:07 < wumpus> cfields: yes, it only works for chaining, if the first link in the chain is broken it solves nothing... 12:08 < jonasschnelli> But not if you have verified the first download (assume with gitian verify), then verify with the new tool 12:08 < gmaxwell> cfields: well if something competent were being done, the setup would be the last version you got provides a tool to get/verify the next version. 12:08 < wumpus> MarcoFalke: it'd be used to check the *next* release downloaded 12:08 < kanzure> bikeshedding for a sec, but "next" seems important enough to be part of the name ;) 12:08 < jonasschnelli> people could still gitian-verify our new verification tool 12:08 < wumpus> MarcoFalke: having it verify itself would be sillly 12:08 < cfields> right. 12:08 < gmaxwell> cfields: so if you previously got a good release, then you'll have good releases foreverafter (or at least until the signing keys were compromised :) ) 12:08 < MarcoFalke> ok, I see 12:08 < kanzure> s/compromised/revoked? 12:09 < kanzure> +revoked, at least? 12:09 < cfields> kanzure: +1. that wasn't clear to me until now :) 12:09 < jonasschnelli> key revoking is possible over our release-management 12:09 < wumpus> kanzure: well it be N-out-of-M ,so could tolerate some revoked or compromised keys Iguess.. 12:09 < gmaxwell> kanzure: without an uncensorable communications medium or expiration there is no sense for revocation. 12:09 < kanzure> hm. 12:09 < wumpus> then they'd just be removed in the next release 12:09 < jonasschnelli> I just wanted to hear if it's ackable to continue to work on this... if so, I'll come up with something for 0.14. 12:10 < gmaxwell> n of m is close to an uncensorable communicatoins medium subject to an honest threshold assumption. 12:10 < luke-jr> gmaxwell: well, if you're looking at the list of people/keys who *didn't* sign, it might help to know they revoked their key rater than simply didn't-sign 12:10 < btcdrak> gmaxwell: what if you got a good release, but were later infected with malware which changed the verifier tool? 12:10 < gmaxwell> btcdrak: oh well. 12:10 < wumpus> btcdrak: if you are infected, it's end of story really 12:10 -!- skyraider [uid41097@gateway/web/irccloud.com/x-zluyziecqrwbkwrt] has joined #bitcoin-core-dev 12:10 < wumpus> btcdrak: it can already steal your coins 12:10 < jonasschnelli> indeed 12:10 < gmaxwell> btcdrak: if you're infected with malware you're hosed at that point. 12:10 < sipa> btcdrak: you are eaten by a frue 12:11 < sipa> *grue 12:11 < jonasschnelli> you can't protect from malware on that layer 12:11 < kanzure> perhaps the malware would be kind enough to at least inform you of your infection 12:11 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 12:11 < wumpus> that's another story entirely (hardaware wallets / security modules) 12:11 < jonasschnelli> impossible 12:11 < jonasschnelli> At least, the EC binary sig tool would allow hardware wallets to sign the binaries 12:11 -!- anchow101 [~achow101@mobile-166-176-248-195.mycingular.net] has joined #bitcoin-core-dev 12:11 < wumpus> that's an interesting idea 12:12 < jonasschnelli> (though you can do this with GPG smartcard) 12:12 < wumpus> there are smartcards running GPG? 12:12 < jonasschnelli> Yes. 12:12 < wumpus> is there some micro-gpg implementation? 12:12 < btcdrak> yes 12:12 < jonasschnelli> but a big mess 12:12 < gmaxwell> A number of people around here use gpg via yubikey3. 12:12 < wumpus> yeah... 12:12 < btcdrak> petertodd has one with pin entry. sounds like he's at the cash register when sending emails 12:12 < gmaxwell> wumpus: it's not really gpg on the smartcard, it's a rsa signer on a stick. :) 12:13 < btcdrak> Ledger Nano S could be programmed to do signing. It also has a GPG module coming. It uses an ST31 secure element afaik 12:13 < wumpus> gmaxwell: oh right, just the rsa signing, the ugly thing about gpg is all the packet parsing and interpretation etc 12:13 < instagibbs> btcdrak, I have a pgp key from mine 12:14 < instagibbs> (just playing around with it) 12:14 < gmaxwell> There is a terrible complex standard for supporting it. In any case, it's a good thing to have. 12:14 -!- yep444 [4e30e544@gateway/web/freenode/ip.78.48.229.68] has joined #bitcoin-core-dev 12:14 < wumpus> same problem as TLS really, the crypto algorithms themselves are reasonably elegant and bug-free, but all the parsing mess around it... 12:14 < kanzure> should we move on? 12:14 < wumpus> anyhow, I think we agree that we'd want to use secp256k1 signatures 12:14 < wumpus> if we can agree on one thing 12:15 < btcdrak> Just a separate note, I think everyone here should be using some kind of smartcard/hardware device for GPG signing. There are plenty inexpensive options like Yubikeys and etc. 12:15 < jonasschnelli> Okay. I'll work on a short design and post it to bitcoin-core-dev ML 12:15 < wumpus> btcdrak: I just use old computers, but I agree that's the more practical option :-) 12:15 < kanzure> should we be complaining about hkp to the bitcoin.org people? 12:15 < gmaxwell> jonasschnelli: can you spend some time and talk to mr or sipa before you post? 12:16 < jonasschnelli> gmaxwell: Yes. Will do... thanks for offering that. 12:16 < wumpus> kanzure: hkp? 12:17 < kanzure> HPKP 12:17 < kanzure> public key pinning 12:17 -!- harrymm [~wayne@178.162.209.68] has joined #bitcoin-core-dev 12:18 < btcdrak> they also dont enforce HSTS 12:18 < kanzure> does bitcoincore.org? 12:18 < btcdrak> yes 12:18 < kanzure> both? 12:18 < jonasschnelli> Another short topic proposal that is near to the signing: code-signing (OSX/WIN). 12:18 < wumpus> sure, why not, if anything can be done to improve site security we should encourag that 12:19 < btcdrak> no, just HSTS and certificate origin 12:19 < gmaxwell> HPKP is pretty easy to mess up. TBH it's a lot more useful for parties that are their own CA. 12:20 < btcdrak> sorry, i mean authenticated origin pulls 12:20 < btcdrak> HSTS is important to prevent https downgrade attacks imo 12:20 < kanzure> okay well i'm eagerly awaiting for the delivery of the complimentary ips containers 12:20 < wumpus> yes, HSTS is important, and trivial to implement 12:20 < wumpus> never even heard of HPKP before 12:21 < kanzure> jonasschnelli: iirc there was some detail about code signing and windows - something about a buggy state? 12:21 < kadoban> HPKP is key-pinning. It's to prevent attacks like rogue CAs 12:21 < wumpus> #topic code-signing (OSX/WIN) 12:21 < jonasschnelli> We still sign with "Bitcoin Foundation" 12:21 < btcdrak> while we are on the topic of releases and so on, wumpus could you please start posting the hashes with the release announcement too. that will ensure wide distribution of the hashes. 12:21 < jonasschnelli> On OSX, its not very visible... on Windows I guess a bit more. 12:21 < wumpus> kadoban: then gmaxwell's comment makes sense - sounds like a risky thing to do if you're depenent on someone else's CA 12:22 < jonasschnelli> Question: we should try to get new certificates for OSX/Win in the name of "Bitcoin Core". 12:22 < gmaxwell> (I'm not saying that it shouldn't be done for that site, just that it's not a no brainer.) 12:22 < jonasschnelli> The question is, if we should. :) 12:22 < instagibbs> jonasschnelli, that's a statement :P 12:22 < btcdrak> jonaschnelli: that would be great. do you have a company that can do it? 12:22 < kadoban> wumpus: It's a little risky. You can pin any piece of the chain, like you can pin *your* private key(s). But then if you do it and screw it up ... you're *really* screwed. 12:22 < kanzure> re: posting hashes, i also suggest we consider posting hashes and maybe sigs on bitcoincore.org -- we can also ask bitcoin.org to do the same if they feel up to that 12:22 < wumpus> btcdrak: sure, I could paste sha256sums.asc into the announcement email 12:22 < luke-jr> jonasschnelli: cfields was looking into this, but I am not sure his status 12:22 < kadoban> Like, your website is unusable for 6 months screwed. 12:22 < btcdrak> wumpus: thank you. 12:22 < wumpus> kadoban: right - what if you want to switch CAs for some reason 12:23 < wumpus> #action sha256sums in release email 12:23 < jonasschnelli> btcdrak: I have serval code signing certificates.. but we don't want to use these company names... 12:23 < gmaxwell> kanzure: I think thats not going in a useful direction. Posting hashes and stuff is fine, if people want to do it-- but its mostly security theater because virutally no one will check, and you can tell they don't check. 12:23 < kadoban> wumpus: You can, if you do it right. You can reuse the same private keys with a different CA (and you can set multiple possible pins, so you can have backups) 12:23 < cfields> luke-jr: didn't get anywhere with it. My best suggestion was to see if MIT would be interested in helping with a cert 12:23 < wumpus> (do note that release emails are signed with *my* key, not the release signing key) 12:23 < sipa> sorry i fell asleep 12:24 < gmaxwell> Thats a sign to move on. :) 12:24 < btcdrak> wumpus: We should also publish the hashes on bitcoincore.org with the release announcements there. Tempted to suggest we aim at mirroring downloads somewhere as well, like the github repo which supports release binaries and maybe bitcoincore.org 12:25 < instagibbs> brainstorming can continue later imo 12:25 < kanzure> wasn't github sunsetting hosted release binaries? 12:25 < luke-jr> is there some organization name that people would be comfortable having sign both Core and Knots releases? would be nice to consolidate in that regard 12:25 < wumpus> btcdrak: we already provide torrents for people that don't want to download from bitcoin.org - it solves nothing of the verification problems ofc 12:25 < luke-jr> kanzure: I think they re-introduced them 12:25 < kanzure> yes it makes sense to not use "Bitcoin Foundation" -- perhaps chaincode would be a good org to blame instead? :D (kidding- let's be nice) 12:25 < wumpus> yes, github has the option to host release binaries 12:25 < kanzure> luke-jr: got it 12:26 < wumpus> but having the binaries in more places means more places to check wether they are compromised too 12:26 < anchow101> Why not host binaries on GitHub and move completely off of bitcoin.orgs system 12:26 < btcdrak> wumpus: we should do it there as a mirror at least. 12:26 < wumpus> also it gives another reason to want to compromise our github 12:26 * jonasschnelli is not sure if we should place the binaries on the same host at the source code 12:27 < wumpus> I'm not comfortable with everyting in one place 12:27 < sipa> let's use sourceforge *ducks* 12:27 < wumpus> yea, exactly, feels like putting a lot of eggs inone basket 12:27 < wumpus> hah 12:27 * jonasschnelli stabs sipa 12:27 < warren> The more mirrors, the better. Although the value of mirroring for diversity is wiped out by automated rsync which is how most people demand to keep mirrors updated. 12:27 < gmaxwell> you don't think github isn't fully compromised already, come one? :) 12:27 < gmaxwell> er come on 12:27 < btcdrak> regarding bitcoincore.org I have a promising offer of sponsorship for around 5 years of hosting/infrastructure from Pindar, so we could setup a download server for example. 12:27 < wumpus> well at least sudden code changes are fairly detectable 12:28 < wumpus> (and we sign all top-level commits) 12:28 < gmaxwell> please can we move on? 12:28 < anchow101> What about Amazon s3 for binary hosting? 12:28 < wumpus> so there is very little gain in compromising our github right now 12:28 < btcdrak> The issue is less about being compromised and more about early warning. 12:28 < wumpus> any other topics? 12:28 < instagibbs> 0.13.0 final? 12:28 < sipa> 0.13.0? 12:28 < btcdrak> having multiple places makes it more likely a compromise would be spotted earlier 12:29 < wumpus> btcdrak: I disagree; it doesn't solve the problem of peopel not verifying at all 12:29 < wumpus> #topic 0.13.0 12:29 < kanzure> does anyone have details about the large quantity of revoked 'malicious' (fake) gpg short id matching keys from the other day? i saw this somewhere but didn't keep a reference. 12:29 < instagibbs> kanzure, greg told me it was some academic paper's work 12:29 < wumpus> I have only one thing to say on this topic: there have been no critical reported issues with rc3, in principle it could be tagged final at any time 12:29 < MarcoFalke> I think the last doc change was merged. We can start gitian after the meeting? 12:29 < kanzure> instagibbs: well i didn't hear it from greg. i did hear somewhere that it was a 'researcher'. but i have no idea where i saw this. 12:29 < MarcoFalke> Or did anyone hear of critical problems? 12:30 < btcdrak> MarcoFalke: it's all good from what I can see. 12:30 < gmaxwell> kanzure: I'll provide citations after the meeting. 12:30 < instagibbs> there was one report of stalled segwit ibd on testnet 12:30 < sipa> kanzure: https://twitter.com/bcrypt/status/765615853488316416 12:30 < wumpus> however the announcement of cobra this morning felt like someone dropped a bomb on the release process, and 'infected' 0.13.0 in people's minds before it is even released, so I feel really grumpy about this topic right now 12:30 < instagibbs> but not sure if that's one-off or what 12:30 < gmaxwell> instagibbs: I've been trying to reproduce marco's stalls with testnet. synced and caught up a few hosts.. so far nothing. 12:31 < jonasschnelli> wumpus: agree, that was a imprudent move.. 12:31 < sipa> gmaxwell: do you have multiple header chains extending your active branch? 12:31 < btcdrak> wumpus: maybe tag on Friday evening, let the gitian builders process over the weekend and we can release on Monday/tues/ 12:31 < MarcoFalke> I can upload my 8.5 gig datadir *ducks* 12:31 < cfields> wumpus: tag it as 0.13.0.1 :) 12:31 < gmaxwell> sipa: no I've just tried varrious things. I thought we already fixed the big with multiple header chains? 12:31 < wumpus> cfields: lol :) 12:31 < sipa> gmaxwell: i thought so too 12:31 < btcdrak> cfields: lol 12:32 < instagibbs> gmaxwell, me neither *shrug* 12:32 < MarcoFalke> Able to reproduce consistently here, but this is something for 13.1 12:32 < sipa> gmaxwell: but that was something i noticed in MarcoFalke's roc output 12:32 < sipa> rpc 12:32 < gmaxwell> MarcoFalke: if you have a sync failure that is reproducably consistently it may be a release blocker. 12:32 < btcdrak> you mean 0.13.1 12:32 < kanzure> wumpus: yeah, there should be a peer review process for posts to bitcoincore.org -- and bitcoin.org would be wise to adopt a similar practice. 12:33 < gmaxwell> Please can we stop with the prior topic? 12:33 < kanzure> okay. 12:33 < btcdrak> last calls for review of the 0.13.0 blog post https://github.com/bitcoin-core/bitcoincore.org/pull/199 12:33 * btcdrak has been asking for two weeks.... 12:33 < sipa> btcdrak: i reviewed! 12:33 < wumpus> yes we're slipping incredibly, for no really good reason, I know 12:33 < wumpus> I feel bad about it too 12:34 * btcdrak gives sipa a gold star! 12:34 < wumpus> oh you mean the blog post, I'll take a look at it 12:34 < gmaxwell> btcdrak: sorry, I missed that completely, will look. 12:34 < wumpus> #action review https://github.com/bitcoin-core/bitcoincore.org/pull/199 12:34 < instagibbs> I'll review today 12:35 < btcdrak> wumpus: so tag friday evening, and release ~monday? 12:35 < sipa> sounds fine be me 12:35 < wumpus> any rationale for friday evening, and not, right now? 12:35 < sipa> also fine by me 12:35 < sdaftuar> sipa: is marco's issue that the stalling detection doesn't make sense if there are some outbound NODE_NETWORK peers you don't download blocks from? 12:35 < gmaxwell> I am concerned that we have a reproducable candidate release blocker. 12:35 < gmaxwell> we should become confident that it's segwit only. 12:36 < wumpus> bah 12:36 < btcdrak> wumpus: to give time for the cobra announcement to fade 12:36 < gmaxwell> perhaps by having marco backup his state, and then disable segwit. 12:36 < wumpus> I'm about to give up on 0.13 completely :p 12:36 < wumpus> and focus on 0.14 from now on 12:36 < sipa> wumpus: what, and release 0 12:36 < btcdrak> 13 is unlucky number! 12:36 < sipa> qe.1 instead? 12:36 < wumpus> btcdrak: yes. exactly. 12:36 < kanzure> one rationale for not right now is to give time for review on bitcoincore.org pull 199 12:36 < btcdrak> ^ 12:36 < kanzure> so maybe like... whatever average review time is. heh. 12:36 < wumpus> gitian building takes time too 12:37 < gmaxwell> If the issue is segwit only-- and only rarely triggered, then I'm fine with it being 0.13.1, but I don't know if we know that. 12:37 < instagibbs> wumpus, skip 0.12.1, go straight to 1.0, come on 12:37 < wumpus> we can delay the uploading until your blog post is finished, sure 12:37 < wumpus> instagibbs: skipping numbers doesn't work if we don't feel confident about the code, though 12:37 < gmaxwell> I don't think there is a reason to hold off from what wumpus was suggesting, but we do need to make a determination on marco's sync bug. 12:37 < sipa> gmaxwell: ok, i will prioritize reviewing marco's situation 12:38 < wumpus> no one else reported it though 12:38 < wumpus> I've done tons of syncs with this code 12:38 < gmaxwell> I reported a similar one in the past, but we thought we fixed it. 12:38 < kanzure> is it reproducible? 12:38 < MarcoFalke> locally 12:38 < gmaxwell> and at the time that was hit by a number of people. some of those reports might have been people actually hitting what marco is hitting now. 12:39 < wumpus> but ok,anyhow, I guess we'll talk about this topic again next week 12:39 < gmaxwell> pft. 12:39 < wumpus> I've given uptrying to push for a release soon 12:39 < warren> MarcoFalke: are you able to reproduce it on other platforms? what kind of build are you using (gitian vs local on fedora?) 12:39 < sipa> i hope 0.13.0 is released next week 12:39 < sipa> wumpus: ok, i'll push 12:39 < MarcoFalke> local on fedora 12:39 < gmaxwell> wumpus: don't be fatalistic, in the next day or so we'll determine if marco's issue is segwit only. If it is, then continue as you suggested. 12:39 < jonasschnelli> Do we delay then the final 0.13.0 only because of cobras post? 12:39 < MarcoFalke> Can we do this trouble shooting after the meeting? 12:39 < wumpus> sipa: thanks. I'm done being the person chasing people peonting at his watch for one 12:40 < sipa> wumpus: ok 12:40 < MarcoFalke> gmaxwell: I never saw it on main 12:40 < wumpus> so should this delay setting up the release schedule for 0.14? 12:40 < wumpus> that's kind of in limbo now, too 12:40 < MarcoFalke> imo no. 0.14 can be less features. less rcs 12:41 < gmaxwell> MarcoFalke: yes, but in three tries so far on rc3 I have not been able to reproduce your condition. So just because you didn't hit it on mainnet doesn't mean it isn't an issue there. 12:41 < gmaxwell> Keep in mind the behavior you're seeing would potentially cause a consensus divergence if it happened to miners. It is a high criticality issue unless we know conditions that reduce its risk. 12:41 < MarcoFalke> wumpus: There is some value in doing releases regular (c.f. firefox) 12:42 < anchow101> Can someone link me to the issue? 12:42 < wumpus> we have toruble doing the releases in the currently planne dschedule 12:42 < wumpus> I don't even want to think about more regular releases 12:42 < jonasschnelli> https://github.com/bitcoin/bitcoin/issues/8518 12:42 < sipa> wumpus: i disagree, your pushing to stick to a schedule was very valuable 12:42 < wumpus> firefox has a completely different situation 12:42 < gmaxwell> My impression is that we haven't really suffered any delay for 0.13 related to the general size. The rcs have not been horribly buggy or anything. 12:43 < sipa> wumpus: i understand if you're worn out about it, but that does not make it a bad idea 12:43 < sipa> we are still very close to on schedule for 0.13 12:43 < jonasschnelli> Yes. Thanks to wumpus'es RC buffer 12:43 < wumpus> sipa: sure! I'm still okay with the current release schedule (try to do a release every 6 months), but not in releases more often 12:43 < sipa> so i would vote we schedule 0.14 as soon as 0.13.0 is out 12:43 < jonasschnelli> I'm normally used to delay of *1.5 in software projects 12:44 < wumpus> jonasschnelli: agree, it could be much worse :) 12:44 < sipa> wumpus: it *used to be* much worse 12:44 < sipa> for us. 12:44 < jonasschnelli> 6 month seems to be perfectly fine. Just +6 month after the (possible) delayed last release 12:44 < wumpus> jonasschnelli: then again, we have time-based releases, we don't wait for any feature, just for bug fixes 12:45 < jonasschnelli> Yes. This seems to follow most agile development practices. 12:45 < wumpus> in any case, any other topics? 12:46 < zooko> Do y'all know about "binary transparency"? 12:46 < jonasschnelli> tell us 12:46 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: gtg] 12:46 < btcdrak> zooko: please explain 12:46 < zooko> https://groups.google.com/forum/#!forum/binary-transparency 12:46 < zooko> It's a project from Ben Laurie, as a follow-on to "certificate transparency". 12:47 < zooko> There is a redundant set of servers which are claiming to do append-only logging of things published to them. 12:47 < zooko> When you publish a binary, you submit its hash to these servers. 12:48 < zooko> Clients should refrain from running a binary if the hash of that binary hasn't been broadcast by those servers. 12:48 < jl2012> proposed topic: BIP146. 12:48 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has left #bitcoin-core-dev [] 12:48 < zooko> This is a detection technique, more than a prevention technique, for people distributing different binaries to different users. 12:49 < jonasschnelli> example: https://github.com/FreeBSDFoundation/binary-transparency-notes 12:49 < jl2012> It is proposed to do the LOW_S and NULLDUMMY softfork at the same time as segwit 12:50 < jonasschnelli> thanks zooko! I think we should take a closer look at the binary-transparency project. 12:50 < wumpus> thanks zooko, it sounds interesting, although I'm not sure it is on topic for anything in the meeting. I don't think it can solve the concrete problem of people running binaries without verifying anything at all, unless OSes would build in support for that 12:50 < wumpus> #topic BIP146 12:50 < btcdrak> #link https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki 12:50 < warren> (OSX does prevent running unsigned binaries unless the user disables a default option.) 12:51 < zooko> wumpus: good point. I think of it as primarily for detecting if someone is replacing binaries with alternate binaries, thinking that nobody will notice. 12:51 < wumpus> warren: yes, but that only checks whether the binary is signed, not by whom, and not whether it's the same file other people gt 12:51 < btcdrak> warren: but anyone can sign. 12:51 < zooko> But not for preventing people from running the alternate binaries so much, because like you say… 12:51 < wumpus> (the latter being the point of the binary transparency) 12:51 < btcdrak> jl2012: speak up 12:51 < warren> btcdrak: true 12:51 < jonasschnelli> warren: In which case you fully have to trust apple 12:51 < sipa> idea: LOW_S and NULLDUMMY have been nonstandard on the network for a long time, and do not appear on the chain (did anyone check they really do not appear?) 12:51 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 12:52 < sipa> together they would make *normal* transactions free from known malleability in segwit 12:53 < jl2012> NULLDUMMY is a bigger problem than LOW_S, as an attacker may put anything as the dummy value 12:53 < sipa> and they are both trivial 12:54 < adam3us> zooko i was thinking another way to do this is by committing to a sequence of R=kG values.in the public key, so P=H(R1,R2,...,Q) and define a mapping from version numbers to R value. now signing two different binaries for the same version will likely leak your private key. 12:54 < sipa> adam3us, zooko: can you wait until the meeting is ove 12:54 < kanzure> is the request re: bip146 for more review? 12:54 < btcdrak> for the record there was some discussion on the ML https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013006.html 12:54 < kanzure> what is the request about bip146 about? 12:54 < sipa> please discuss :) 12:55 < jonasschnelli> jl2012: Would the NULLDUMMY affect current mainnet transaction 12:55 < jl2012> LOW_S was discussed in last meeting but not NULLDUMMY 12:55 < btcdrak> ha! I think we discussed LowS already, it's just the addition of NULLDUMMY that is new. 12:55 < sipa> do we think it is doable in 0.13.1 / together with segwit 12:55 < jl2012> jonasschnelli: yes in the current BIP146 12:55 < btcdrak> sipa: I agree. it is a trivial addition. 12:56 -!- anchow101 [~achow101@mobile-166-176-248-195.mycingular.net] has quit [Quit: Bye] 12:56 < wumpus> yes, ack on LowS already, I don't know enough about NULLDUMMY to usefully comment 12:56 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 12:56 < btcdrak> 4 minute bell 12:57 < luke-jr> wumpus: NULLDUMMY is just "the ignored value popped by CHECKMULTISIG must be zero" 12:57 < sipa> nulldummy is liteeally: the ignored input to checkmultisig has to be the eempty vector 12:57 < jonasschnelli> So, worst case, there are some non-NULLDUMMY producers/miners out there that would need to adjust to the new rule? 12:57 < sipa> we should check if they are being included in the chain 12:57 < wumpus> okay that seems harmless and easy to check 12:57 < luke-jr> jonasschnelli: nobody sends these, so it's hard to know if anyone mines them 12:57 < btcdrak> it's already nonstandard 12:58 < wumpus> makes sense to include that with the LOWS cleanup then 12:58 < luke-jr> oh, and since all miners MUST be on 0.12.1 now, nobody should mine these 12:58 < sipa> why must they be on 0 12:58 < sipa> why must they be on 0.12.1? 12:58 < luke-jr> sipa: CSV? 12:58 < btcdrak> last softfork 12:59 < sipa> ah. 12:59 < btcdrak> since we didnt release a 0.11.x they upgraded to 0.12.1 12:59 < jonasschnelli> LOW_S & NULLDUMMY seems to make sense to include in the SW SF. 12:59 < btcdrak> I think luke-jr's grammar has a bug or two :-p 12:59 < wumpus> let's not have a new thing creep into SW every week though :p 12:59 < BlueMatt> I'm not a huge fan of bundling them :/ 12:59 < luke-jr> btcdrak: ? 12:59 < BlueMatt> though not against a separate sf that is also in 0.13.1, though thats also gross 13:00 < btcdrak> BlueMatt: it's a trivial one liner (modulo tests) 13:00 < luke-jr> the only reason to bundle IMO is if we want to add new non-VERIFY opcodes to segwit. 13:00 < BlueMatt> btcdrak: I'm aware, doesnt mean I like it 13:00 < wumpus> we discussed that last week BlueMatt, the disadvantage of not bundling is that no one would care about a separete softfork for them 13:00 < wumpus> they're just a cleanup 13:00 < luke-jr> but LOWS/NULLDUMMY are just softforks, so no need to bundle IMO 13:00 < luke-jr> (no harm either) 13:00 < BlueMatt> wumpus: ok, fair enough, though in same version...anyway, I'll hold my tounge 13:01 < wumpus> #endmeeting 13:01 < lightningbot> Meeting ended Thu Aug 18 20:01:00 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:01 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-18-19.00.html 13:01 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-18-19.00.txt 13:01 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-18-19.00.log.html 13:01 < btcdrak> fwiw, miners dont like to have to upgrade so frequently. 13:01 < BlueMatt> btcdrak: yes, also if we had mempool-on-disk they'd care marginally less 13:01 < BlueMatt> but still not fans 13:01 < jonasschnelli> Removing all known sources of malleability in the initial SW SF should be achievable? 13:01 < btcdrak> BlueMatt: there is a PR for that 13:01 < BlueMatt> I'm aware 13:01 < wumpus> there's a pull open to persist mempool to disk right? 13:01 < BlueMatt> yes 13:02 < sipa> yes, it's buggy thougg 13:02 < sipa> i'll work on it again 13:02 < btcdrak> is there an echo in here? 13:02 < wumpus> that's 0.14 at first though 13:02 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8448 13:02 < jl2012> jonasschnelli: OP_IF/NOTIF is still a problem 13:02 < btcdrak> jl2012: you were going to make that nonstandard for now iirc? 13:03 < BlueMatt> re: re: low-s: I still run a node which malleates automatically and it still gets a lot of high-s txn 13:03 < sipa> BlueMatt: wow, really :( 13:03 < jl2012> btcdrak: yes 13:04 < BlueMatt> sipa: I mean its not unlikely someone is malleating originally-low-s txn, though 13:04 < sipa> BlueMatt: even while no recent releases relay high-s... 13:04 < BlueMatt> sipa: I checked a month or so ago and it was like 1 per hour 13:04 < btcdrak> they cant be getting mined though... all the miners are on 0.12.1 13:05 < warren> maybe they are getting mined thanks to BlueMatt? =) 13:06 < BlueMatt> btcdrak: the malleated versions can, though 13:06 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev 13:06 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 250 seconds] 13:07 < kanzure> gmaxwell: btw i found what i think is sufficient reference to my request about gpg short id happenings https://news.ycombinator.com/item?id=12298230 -- so nevermind 13:09 < luke-jr> wumpus: minor detail, but I noticed the RCs were "0.13.0" internally; was the previous 0.12.99-ish scheme abandoned intentionally? 13:09 < wumpus> luke-jr: IIRC rcs have always been the version internally 13:09 < wumpus> rcs have never been 0.X.99 13:09 < warren> luke-jr: IIRC rc's always were internally the version with "rcX" appended 13:10 < wumpus> yes 13:10 < sipa> long ago rcs were literally release candidates: the latest rc binary literally became the final binary 13:10 < wumpus> right 13:11 < sipa> though we'vdle gone through so many schemes that i can't say i'm sure anymore :) 13:11 < wumpus> I've been entirely consistent the last few major releases 13:11 * luke-jr questions his memory 13:11 < warren> I joined around 0.8 and it was consistent since then at least. 13:12 < sipa> the last release i did was 0.3.23 13:15 < gmaxwell> So part of why I was deflecting on the endless rathole of the bitcoin.org stuff is because I had more to say that that I didn't fit in the scope of the meeting, and we had other things to accomplish that unfortunately we didn't have time for. :( 13:15 < gmaxwell> Among the other things I wanted to say was this: 13:15 < gmaxwell> Kanzure, achow101. Regarding your public comments on the bitcoin.org notice. 13:15 < gmaxwell> https://www.reddit.com/r/btc/comments/4y8sk7/0130_binary_safety_warning_bitcoinorg/d6m1oqu 13:15 < gmaxwell> https://www.reddit.com/r/Bitcoin/comments/4y8m76/0130_binary_safety_warning_bitcoinorg/d6luukw 13:15 < gmaxwell> I think you've taken the wrong position, by pounding on process. 13:15 < gmaxwell> If someone with privleged access is aware of a serious concern and believes 13:15 < gmaxwell> they urgently need to tkae unilateral action to make a minimal statement 13:15 < gmaxwell> simply to _notify_ people of the risk and encourage following an existing 13:15 < gmaxwell> process to mitigate, they should do so. Pounding on procedure comes across 13:15 < gmaxwell> as a denial which I don't believe you had the information to make. 13:15 < gmaxwell> (and in fact, since achow101 did not talk to all the major developers, I 13:15 < gmaxwell> _know_ you didn't have the information needed to make the claim you made.) 13:15 < gmaxwell> And yes, someone doing something like that unilaterally is going to cause 13:15 < gmaxwell> some pain. But that is okay, the security process should favor risk 13:15 < gmaxwell> reduction, over creating a bit of pain here and there. 13:15 < gmaxwell> [In fact, both of your messages could come across as expressing the view 13:15 < gmaxwell> that we are skeptical that HTTPS MITM attacks are even a risk, when in fact 13:15 < gmaxwell> we _know_ they are well documented to happen with some regularity.] 13:15 < gmaxwell> We are at no real risk of tiring people out with a flood of false positives, 13:16 < gmaxwell> otherwise I would take a different position, perhaps. 13:16 < gmaxwell> Cobra isn't great at public relations, sure, but I notice none of the people 13:16 < gmaxwell> complaining opened PRs to improve the language. His notice states the 13:16 < gmaxwell> concern, the believed targets, and contains specific, conservative, 13:16 < gmaxwell> mitigation instructions, it could be a lot worse. 13:24 < kanzure> i hadn't considered some of that perspective, in particular that there is a benefit to being quick to make alerts. and downplaying alerts is probably not healthy either because it to some extent discourages others from making them in the future a little bit more. 13:25 < kanzure> also, it's possible that achow101 was reading into my overly strong language. his comment was made after mine by a bit, after all. 13:26 < gmaxwell> I don't think it's a big deal, but just like I'd encourage cobra to be more careful with presentation, I'd like to also ask y'all to try for a different handling here. :) 13:31 < kanzure> yeah, got it.. plus, in rtrospect, it does seem a little silly that my first concern in that comment text is about process concerns... which is trivial for others to mistakenly read as "security concern denial". during incident response some other topics should probably be higher priority than that. 13:46 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 250 seconds] 13:53 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 13:57 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 13:58 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 14:01 -!- cryptapus_afk is now known as cryptapus 14:05 < achow101> gmaxwell: sorry about that. I was mostly reacting against the conspiracy theories and other idiotic claims that r/btc'ers make 14:06 < gmaxwell> yea, that stuff was halarious. 14:07 < kanzure> this seems like a good opportunity to show off a favorite tool of mine, https://mitmproxy.org/ 14:09 * luke-jr ponders hacking his email client to refuse to send to the old MLs :| 14:09 < kanzure> send to both 14:10 < luke-jr> kanzure: if I knew it was to the old ML, I'd just change it to the new one :P 14:20 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 250 seconds] 14:20 < cfields> jonasschnelli: i think i've decided against banning by id, as it introduces a possible failure if a node manages to disconnect just after you click "ban". 14:20 < cfields> jonasschnelli: i can still PR the id addition to the table though, if you'd like 14:25 -!- zooko [~user@50.246.213.170] has quit [Ping timeout: 264 seconds] 14:25 -!- billotronic [~billotron@unaffiliated/billotronic] has quit [Read error: Connection reset by peer] 14:27 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 14:34 -!- TomMc [~tom@gateway/vpn/privateinternetaccess/tommc] has joined #bitcoin-core-dev 14:46 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 14:53 -!- zooko [~user@sta-207-174-117-102.rockynet.com] has joined #bitcoin-core-dev 14:54 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 14:57 -!- yep444 [4e30e544@gateway/web/freenode/ip.78.48.229.68] has quit [Quit: Page closed] 14:59 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 15:00 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 15:06 < midnightmagic> achow101: :-) 15:32 -!- JackH [~Jack@79-73-188-45.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 15:38 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev 15:45 -!- TomMc [~tom@gateway/vpn/privateinternetaccess/tommc] has quit [Ping timeout: 240 seconds] 15:49 -!- JZA [JZA@gateway/shell/elitebnc/x-bdjpkptyvaeumhxz] has quit [Excess Flood] 15:51 -!- zooko [~user@sta-207-174-117-102.rockynet.com] has quit [Ping timeout: 244 seconds] 15:52 < BashCo> fwiw, I've attempted a PR to improve the language of the binary safety alert. https://github.com/bitcoin-dot-org/bitcoin.org/pull/1344 15:54 < BashCo> mostly focused on encouraging cross referencing keys from multiple sources, as well as signatures from multiple developers. 15:55 -!- netzin [~netsin@unaffiliated/jiggalator] has joined #bitcoin-core-dev 15:56 -!- netzin is now known as n3tsin 15:56 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 15:58 -!- JZA [JZA@gateway/shell/elitebnc/x-guteovclszuuhbrj] has joined #bitcoin-core-dev 16:00 < GitHub168> [bitcoin] theuni opened pull request #8542: RFC: net: Pass best block known height into net (master...pass-in-height) https://github.com/bitcoin/bitcoin/pull/8542 16:01 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 16:25 < gmaxwell> Someone in #bitcoin had 17 BTC stolen from them today because they came for tech support (their wallet was a couple years behind and they were wondering why they hadn't seen a payment yet) and someone wumpus and I were talking to, "moldish", pulled them into PM and got them to do a dumpprivkey. :( 16:26 < midnightmagic> Is the money actually stolen? 16:27 < gmaxwell> I believe there address was 1K35Q6BEkCvhE2k7SUeZXKDFTtZACEfNcn and its been cleaned out. 16:28 < BlueMatt> ouch 16:29 < BlueMatt> thats a bunch of cash, too 16:34 < luke-jr> ugh, maybe we need more red lights on the debug window? :/ 16:35 < gmaxwell> We could make the dumpprivkey response include a # This is secret data which will allow anyone who knows it to steal your coins. 16:36 < Lauda> +1 16:37 < luke-jr> sounds easier than it probably is. stupid JSON has no comments 16:41 < gmaxwell> I think that RPC doesn't return json? 16:41 < gmaxwell> wait thats dumb, I guess it does. 16:41 < gmaxwell> :-/ 16:43 < luke-jr> I suppose we could add some non-standard stuff to UniValue and strip it over real RPC (but not debug console) 16:43 < gmaxwell> ugh. or make the debug console do something special. 16:44 < luke-jr> but there's other unsafe things too - like importprivkey.. 16:44 < luke-jr> and a comment couldn't work for that case 16:44 < gmaxwell> Yes, and I've seen someone robbed via that too. But it's less unsafe, I think. 16:45 < luke-jr> is there anything not-unsafe normal users would ever use the debug window for? what's the downside of a generic red-flag in the initial message we have? 16:46 < gmaxwell> lots of pure status things. 16:47 < gmaxwell> getinfo/getchaintips/getmempoolinfo 16:47 < gmaxwell> the only export/import privatekey and signraw transaction and sigmessage are really signficantly unsafe... and sigmessage is pretty hard to abuse, presuming the thing you have to sign is sensibly constructed. 16:48 < luke-jr> signmessage has a proper GUI at least 16:55 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-qhrexphgbbezbutv] has quit [Quit: Connection closed for inactivity] 16:57 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 17:02 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 17:07 -!- cryptapus is now known as cryptapus_afk 17:12 -!- Giszmo [~leo@2001:a61:32f6:9901:a4ce:f633:9464:fc9e] has quit [Ping timeout: 250 seconds] 17:17 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has quit [Ping timeout: 250 seconds] 17:23 -!- n3tsin [~netsin@unaffiliated/jiggalator] has quit [Remote host closed the connection] 17:24 -!- n3tsin [~netsin@unaffiliated/jiggalator] has joined #bitcoin-core-dev 17:26 -!- Giszmo [~leo@2001:a61:3288:fe01:a4ce:f633:9464:fc9e] has joined #bitcoin-core-dev 17:28 -!- n3tsin [~netsin@unaffiliated/jiggalator] has quit [Ping timeout: 240 seconds] 17:33 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 17:34 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 17:36 -!- JZA [JZA@gateway/shell/elitebnc/x-guteovclszuuhbrj] has quit [Excess Flood] 17:38 -!- JZA [JZA@gateway/shell/elitebnc/x-wavsileelsvwmtlm] has joined #bitcoin-core-dev 17:39 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Quit: No Ping reply in 180 seconds.] 17:39 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev 17:50 -!- n3tsin [~netsin@unaffiliated/jiggalator] has joined #bitcoin-core-dev 17:59 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 18:00 -!- baldur [~baldur@209.95.50.144] has joined #bitcoin-core-dev 18:03 -!- Kexkey [~kexkey@184.75.213.131] has quit [Ping timeout: 240 seconds] 18:04 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 18:07 < jcorgan> wumpus: is there a plan for #7753? 18:13 -!- n3tsin [~netsin@unaffiliated/jiggalator] has quit [] 18:17 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has joined #bitcoin-core-dev 18:29 < jl2012> gmaxwell, luke-jr: I think we could require an extra command in debug windows to "unlock" those sensitive commands 18:32 < CodeShark> jl2012: good idea 18:33 < jl2012> which will return a page of warning, describing the risk of each unlocked command 18:35 < luke-jr> jl2012: hmm, that might work 18:56 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 19:04 -!- zooko [~user@2601:281:8500:fc65:f0a:33e8:fd71:e637] has joined #bitcoin-core-dev 19:17 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 19:27 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 19:43 -!- zooko [~user@2601:281:8500:fc65:f0a:33e8:fd71:e637] has quit [Remote host closed the connection] 19:50 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 19:51 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 20:18 -!- mkarrer_ [~mkarrer@91.red-83-37-157.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 20:20 -!- mkarrer [~mkarrer@249.red-83-38-154.dynamicip.rima-tde.net] has quit [Ping timeout: 244 seconds] 20:38 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Lost terminal] 20:42 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 20:54 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Read error: Connection reset by peer] 20:54 -!- spudowiar1 [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev 20:55 -!- spudowiar1 is now known as spudowiar 20:58 -!- cryptapus_afk is now known as cryptapus 20:59 -!- cryptapus is now known as cryptapus_afk 21:13 -!- justanotheruser is now known as radiopaid 21:16 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.] 21:23 -!- radiopaid is now known as justanotheruser 21:48 < GitHub144> [bitcoin] petertodd opened pull request #8543: Use ANYONECANPAY if -spendzeroconfchange=0 (master...2016-08-anyonecanpay-if-spendzeroconfchange-disabled) https://github.com/bitcoin/bitcoin/pull/8543 21:49 -!- cheese_ [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 21:52 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 244 seconds] 22:01 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:02 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 22:11 -!- jannes [~jannes@178.132.211.90] has quit [Ping timeout: 244 seconds] 22:56 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 265 seconds] 23:19 -!- harrymm [~wayne@178.162.209.68] has quit [Ping timeout: 258 seconds] 23:29 < GitHub95> [bitcoin] jonasschnelli closed pull request #8541: Trivial: Fix typos in various files (master...various-typos) https://github.com/bitcoin/bitcoin/pull/8541 23:31 -!- Lysander1 [~Lysanders@unaffiliated/lysanders] has joined #bitcoin-core-dev 23:34 -!- Lysanders [~Lysanders@unaffiliated/lysanders] has quit [Ping timeout: 244 seconds] 23:34 < jonasschnelli> sipa, gmaxwell: about the binary ecdsa signing. We could create a standard ecdsa sig along with the GPG assets sig. Something like bitcoin-osx-0.13-build.assert.ecsig, where we just place a 64byte compact sig. ecdsa(sha256(sha256()), P) 23:35 < jonasschnelli> sipa, gmaxwell: then we could have a file with [{"":"34byte pubkey"},] 23:35 < jonasschnelli> (a cpp header IMO) 23:38 < jonasschnelli> For the downloading the asset file signatures, we could use the github API (GET /repos/:owner/:repo/contents/:path) 23:38 -!- harrymm [~wayne@223.204.246.193] has joined #bitcoin-core-dev 23:38 < jonasschnelli> Using the maybe existing local git binary seems fragile 23:40 < luke-jr> Seems unlikely Mac/Windows (where this will generally get used) will have a local git binary anyway 23:43 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 23:46 < jonasschnelli> luke-jr: Yes. depending on git is probably a nogo on Win/OSX 23:47 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 23:50 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 23:56 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 23:57 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 258 seconds]