--- Log opened Mon Aug 13 00:00:39 2018 00:01 -!- vexbuy [~vexbuy@89.39.107.201] has quit [Remote host closed the connection] 00:07 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 00:18 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 00:19 -!- IGHOR [~quassel@93.178.216.72] has quit [Ping timeout: 244 seconds] 00:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 00:28 -!- phwalkr [~phwalkr@2001:1284:f013:7ef3:81ba:fed4:64d:744] has joined #bitcoin-core-dev 00:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds] 00:33 -!- phwalkr [~phwalkr@2001:1284:f013:7ef3:81ba:fed4:64d:744] has quit [Ping timeout: 240 seconds] 00:39 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 00:40 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Ping timeout: 244 seconds] 00:44 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-dev 00:55 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 00:56 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 01:02 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev 01:07 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev 01:09 -!- IGHOR [~quassel@93.178.216.72] has quit [Ping timeout: 248 seconds] 01:30 -!- vexbuy [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 01:38 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev 01:38 < wumpus> so according to #12624 it's time to split off the 0.17 branch today 01:38 < gribble> https://github.com/bitcoin/bitcoin/issues/12624 | Release schedule for 0.17.0 · Issue #12624 · bitcoin/bitcoin · GitHub 01:39 -!- vexbuy_ [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 01:41 < wumpus> let's see how far we get... 01:42 -!- vexbuy [~vexbuy@217.23.3.171] has quit [Ping timeout: 240 seconds] 01:44 -!- vexbuy [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 01:44 -!- ken2812221_ [~ken281222@1-160-141-92.dynamic-ip.hinet.net] has joined #bitcoin-core-dev 01:47 -!- vexbuy_ [~vexbuy@217.23.3.171] has quit [Ping timeout: 260 seconds] 01:48 -!- vexbuy_ [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 01:52 -!- vexbuy [~vexbuy@217.23.3.171] has quit [Ping timeout: 272 seconds] 01:53 < kallewoof> wumpus: I think I've reviewed all the 0.17 PR's that I feel comfy reviewing 01:53 -!- vexbuy [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 01:54 < kallewoof> is there anything else that needs doing besides review? 01:55 < wumpus> we'll probably want to put up the release notes in the wiki 01:55 -!- nodweber [~nodweber@unaffiliated/nodweber] has quit [Quit: WeeChat 2.2] 01:55 -!- vexbuy_ [~vexbuy@217.23.3.171] has quit [Ping timeout: 240 seconds] 01:56 < wumpus> so that people can work on the remaining items in #12391 01:56 < gribble> https://github.com/bitcoin/bitcoin/issues/12391 | TODO for release notes 0.17.0 · Issue #12391 · bitcoin/bitcoin · GitHub 01:56 < wumpus> I'm also working on doing a final translations update before the branch-off 01:57 -!- vexbuy_ [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 01:58 < wumpus> but as for things holding back the branch, yes I think reviewing the ones tagged 0.17 is most important now 01:58 * kallewoof can't even find the wiki link from github, so going to leave that one for someone who's not clueless :P 01:59 < kallewoof> got it. I'll double check if anything was updated and re-review. 02:00 -!- vexbuy [~vexbuy@217.23.3.171] has quit [Ping timeout: 248 seconds] 02:00 < kallewoof> even better is to actually try the code and not just stop at utACKing... 02:02 -!- vexbuy [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 02:03 < wumpus> as for wiki link: https://github.com/bitcoin-core/bitcoin-devwiki/wiki 02:05 -!- vexbuy_ [~vexbuy@217.23.3.171] has quit [Ping timeout: 244 seconds] 02:06 -!- itaseski [~itaseski@213.135.176.242] has joined #bitcoin-core-dev 02:06 -!- vexbuy_ [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 02:06 < kallewoof> Ohh... no wonder i couldn't find it 02:06 < kallewoof> Thanks 02:08 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 02:09 -!- vexbuy [~vexbuy@217.23.3.171] has quit [Ping timeout: 240 seconds] 02:11 < fanquake> wumpus I think 13808 is ready. Also 13938, but I assume it must break something for 0.17, if it's been tagged with 0.18? 02:11 < kallewoof> Huh... https://pastebin.com/cC29k9Sz 02:11 -!- vexbuy [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 02:12 < kallewoof> I tried [ createpsbt "[]" "[{\"$(./bitcoin-cli getnewaddress)\":0.01}]" ], which worked fine. But decodepsbt errors for the result. 02:12 * kallewoof should probably read up on how these commands work 02:15 -!- vexbuy_ [~vexbuy@217.23.3.171] has quit [Ping timeout: 260 seconds] 02:15 -!- vexbuy_ [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 02:17 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 02:18 -!- vexbuy [~vexbuy@217.23.3.171] has quit [Ping timeout: 240 seconds] 02:20 -!- vexbuy [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 02:24 -!- vexbuy_ [~vexbuy@217.23.3.171] has quit [Ping timeout: 255 seconds] 02:25 -!- vexbuy_ [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 02:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:29 -!- vexbuy [~vexbuy@217.23.3.171] has quit [Ping timeout: 272 seconds] 02:29 -!- vexbuy__ [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 02:32 -!- vexbuy_ [~vexbuy@217.23.3.171] has quit [Ping timeout: 240 seconds] 02:34 < wumpus> I don't get why #13938 is labeled 0.18, but I don't realy like it either so I'll leave it like this 02:34 < gribble> https://github.com/bitcoin/bitcoin/issues/13938 | refactoring: Cleanup StartRest() by DesWurstes · Pull Request #13938 · bitcoin/bitcoin · GitHub 02:34 -!- vexbuy [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 02:34 < wumpus> really tired of these twiddle-the-code-a-bit-without-really-doing-anything 02:35 < wumpus> agree 13808 is ready 02:35 < wumpus> thanks everyone for reviewing that one it was needed ! 02:37 -!- vexbuy__ [~vexbuy@217.23.3.171] has quit [Ping timeout: 276 seconds] 02:37 < fanquake> Plenty more refactoring type PRs to review heh 02:38 -!- vexbuy_ [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 02:39 < fanquake> 13899 maybe ready, but probably needs at least one tested ACK from someone using GCC 02:40 < wumpus> nothing wrong with refactoring, but man, 'this functiona cannot fail at the moment' so we have to propagate this through the entire call chain upwards!!! seems somewhat self-defeatng 02:40 < wumpus> so I'd say we close that kind 02:41 -!- vexbuy [~vexbuy@217.23.3.171] has quit [Ping timeout: 240 seconds] 02:42 < wumpus> redundant declarations meh 02:42 < fanquake> wumpus I feel a lot of closed PRs in the near hours 02:43 -!- vexbuy [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 02:43 < wumpus> fanquake: haha if it was only up to me 02:44 < wumpus> no, removing redundant declarations is okay, but I don't see it as a focus point for 0.17 02:47 -!- vexbuy_ [~vexbuy@217.23.3.171] has quit [Ping timeout: 265 seconds] 02:47 < fanquake> Seems like there is "some" agreement around #13666 ? Still tagged for 0.17. 02:47 < gribble> https://github.com/bitcoin/bitcoin/issues/13666 | Always create signatures with Low R values by achow101 · Pull Request #13666 · bitcoin/bitcoin · GitHub 02:47 -!- vexbuy_ [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 02:47 < fanquake> I'm re-reading the thread, as I remember there were some concerns about it early on, but don't feel overly confident reviewing the changes there. 02:48 < wumpus> 0.17 release notes are on the wiki https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes 02:49 < wumpus> fanquake: I'm somewhat reluctant on that one 02:49 < wumpus> maybe someone can convince me why it's important to merge that last minute before 0.17 02:50 -!- vexbuy [~vexbuy@217.23.3.171] has quit [Ping timeout: 260 seconds] 02:52 -!- vexbuy [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 02:53 < wumpus> ah the signature size counting issue for feerate was resolved 02:53 < wumpus> and it has plenty of utACKs 02:53 < wumpus> so I think it should just go in 02:55 < wumpus> fanquake: reducing the entropy of the nonce was the biggest concern it seems 02:56 < fanquake> wumpus thanks, just merging/running tests etc 02:56 < wumpus> and making signing time double--but that seems unimportant and nneglible in comparison to utxo selection and such when sending a transaction 02:56 -!- vexbuy_ [~vexbuy@217.23.3.171] has quit [Ping timeout: 272 seconds] 02:56 -!- vexbuy_ [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 02:59 -!- vexbuy_ [~vexbuy@217.23.3.171] has quit [Remote host closed the connection] 03:01 -!- vexbuy [~vexbuy@217.23.3.171] has quit [Ping timeout: 272 seconds] 03:07 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds] 03:22 -!- plankers [~plank@38.87.81.82] has joined #bitcoin-core-dev 03:31 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 03:40 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has joined #bitcoin-core-dev 03:55 -!- vexbuy [~vexbuy@217.23.3.171] has joined #bitcoin-core-dev 03:56 -!- ken2812221_ [~ken281222@1-160-141-92.dynamic-ip.hinet.net] has quit [Ping timeout: 260 seconds] 04:06 < MarcoFalke> wumpus: I think https://github.com/bitcoin/bitcoin/pull/13905 can go in to 0.17 as doc bug fix (tiny one) 04:07 < MarcoFalke> manpages need to be regenerated anyway 04:07 < MarcoFalke> (after the version bump) 04:13 < MarcoFalke> lol, why do we have appveryor as ci check? 04:14 < fanquake> MarcoFalke appveryor? 04:14 < MarcoFalke> https://github.com/bitcoin/bitcoin/pull/13939#ref-commit-ef86f26 04:14 < MarcoFalke> Oh well, only on this commit 04:15 < MarcoFalke> because it was also pushed to some other remote (with appveyor) 04:16 < fanquake> huh ok 04:23 < MarcoFalke> Going to merge #13905 as well. 04:23 < gribble> https://github.com/bitcoin/bitcoin/issues/13905 | docs: fixed bitcoin-cli -help output for help2man by hebasto · Pull Request #13905 · bitcoin/bitcoin · GitHubAsset 1Asset 1 04:23 < MarcoFalke> I think after that we are good to branch off 04:23 < MarcoFalke> (and backport any remaining bugfixes) 04:23 < MarcoFalke> later on 04:32 < wumpus> yay 04:32 < MarcoFalke> Oh wait, we should merge the loose release notes file into the master doc 04:33 < MarcoFalke> Otherwise they will be sitting around forever 04:33 < wumpus> I've already put the release notes in the wiki, probably want to do that there 04:34 < wumpus> there's no need to do this before the branch, after the branch I'm going to remove all release notes (including the loose ones) on the master branch 04:37 < fanquake> So backport 13917 and 13788 after branch off? 04:38 < wumpus> if there is anything we *know* that should be backported and is open now, I say we should merge it right now 04:38 < wumpus> backporting post-branch is for things we don't know about yet 04:38 < fanquake> I'm just looking at https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.17.0 04:38 < fanquake> One needs a rebase, the -disable-asm changes I'm not sure about. 04:38 < MarcoFalke> Yeah, needs a rebase and re-ACK. That might take some days 04:38 < wumpus> yes the latter seems to be controversial 04:39 < wumpus> ok agreed, probably makes no sense to hold up rc1 for a few days for that 04:39 < wumpus> might even postpone it to 0.17.1 04:39 < fanquake> Sounds like it's time to branch then 04:40 < wumpus> might want to do a hardcoded seed update first 04:40 < wumpus> BLOCK_CHAIN_SIZE was recently adapted afaik 04:41 < wumpus> the chainparams stats too 04:41 < fanquake> Yes, to 220 I think. 04:42 < wumpus> last hardcoded seeds update was in januari, so I'm going to do that 04:42 < MarcoFalke> sounds good 04:46 < wumpus> any versions that should be removed from PATTERN_AGENT while building the list? (it has 0.13.0 and up after adding 0.16.[012]) 04:47 < fanquake> I guess 0.13 has reached its "end of life" 04:47 < fanquake> Or did, at the start of the month https://bitcoincore.org/en/lifecycle/ 04:48 < fanquake> Does that warrant removal? 04:48 < wumpus> it did, is that enough reason, or does it need any specific reason to exclude it based on compatiblity? 04:49 -!- wxss [~user@185.145.156.45] has joined #bitcoin-core-dev 04:49 < wumpus> I don't think it matters much, there shouldn't be many 0.13.x nodes around anymore 04:50 < fanquake> I guess it's just 0.13.1 + that have segwit support 04:50 < wumpus> I'll just remove it 04:55 -!- vexbuy_ [~vexbuy@46.166.142.217] has joined #bitcoin-core-dev 04:57 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 04:57 -!- vexbuy [~vexbuy@217.23.3.171] has quit [Read error: Connection reset by peer] 04:58 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 05:00 < wumpus> #13951 05:00 < gribble> https://github.com/bitcoin/bitcoin/issues/13951 | Hardcoded seeds update pre-0.17 branch by laanwj · Pull Request #13951 · bitcoin/bitcoin · GitHub 05:14 -!- wxss [~user@185.145.156.45] has quit [Ping timeout: 255 seconds] 05:23 -!- wxss [~user@95.143.192.22] has joined #bitcoin-core-dev 05:34 -!- plankers [~plank@38.87.81.82] has quit [Ping timeout: 240 seconds] 05:46 < wumpus> I'll wait for some acks on that 05:55 -!- goatpig [56eece80@gateway/web/freenode/ip.86.238.206.128] has joined #bitcoin-core-dev 06:17 < MarcoFalke> The default for GetDesirableServiceFlags didn't change, so looks correct 06:17 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:28 < wumpus> so I think it's ready for branch? 06:29 < fanquake> It would seem that way 06:29 < fanquake> manpages? Or they can be done later on 06:30 < wumpus> that needs to be done after upping the versions 06:32 < MarcoFalke> lets do it! 06:33 < fanquake> on time! 06:35 < wumpus> https://github.com/bitcoin/bitcoin/tree/0.17 ! 06:35 -!- vexbuy_ [~vexbuy@46.166.142.217] has quit [Remote host closed the connection] 06:35 < wumpus> yes this is fantastic, we didn't have to postpone it this time :) 06:38 < wumpus> versions bumped, if you want to do an update-manpages PR go ahead 06:39 < wumpus> (need a seperate one for master and 0.17) 06:39 < TheHoliestRoger> thank you for your hard work all 06:41 < MarcoFalke> no pressing need to bump on master for now 06:41 < MarcoFalke> Probably enough to do it twice a year or so 06:42 < MarcoFalke> But the gitian-descriptor would need to be bumped on master? 06:42 < TheHoliestRoger> you got 3 gitian sigs yet? 06:42 < wumpus> MarcoFalke: yes, good point, the gitian descriptor needs to be bumped there to avoid overlapping caches 06:42 < wumpus> TheHoliestRoger: lol :) 06:43 < TheHoliestRoger> what you lolling at me for? :) 06:43 < TheHoliestRoger> the thank you was serious 06:43 < MarcoFalke> Its been like 6 minutes after the branch 06:43 < TheHoliestRoger> was waiting to merge 0.17 into my altcoin 06:43 < MarcoFalke> TheHoliestRoger: There is altcoin-dev on irc 06:44 < MarcoFalke> not here please 06:44 < TheHoliestRoger> eh? 06:44 < MarcoFalke> This is bitcoin-core-dev 06:44 < TheHoliestRoger> I know, that's why I just thanked you guys for your hard work... 06:45 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 06:45 < fanquake> I opened a PR for the descriptors 06:45 < fanquake> Can do the 0.17 manpages as well 06:46 < TheHoliestRoger> MarcoFalke: are we not supposed to talk in here or somethnig? 06:46 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 06:49 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 06:57 -!- vexbuy [~vexbuy@46.166.142.217] has joined #bitcoin-core-dev 07:00 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 07:05 -!- vexbuy [~vexbuy@46.166.142.217] has quit [Remote host closed the connection] 07:22 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 07:22 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Excess Flood] 07:23 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 07:26 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 07:26 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 250 seconds] 07:26 -!- D00M [~doom@49.146.41.106] has joined #bitcoin-core-dev 07:29 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev 07:29 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [] 07:30 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Excess Flood] 07:31 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 07:38 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Excess Flood] 07:38 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 07:44 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has joined #bitcoin-core-dev 07:50 < jonasschnelli> Can I safely assume that the first socket read is always > 32 bytes (connecting a new peer)? 07:51 < jonasschnelli> Or should the encryption handshake be splittable in socket reads (makes implementation a bit more complex)? 07:53 <@sipa> you cannot make such an assumptiom 07:53 -!- mode/#bitcoin-core-dev [-o sipa] by sipa 07:54 < wumpus> you always need to handle smaller reads 07:55 < wumpus> it's possible worst-cast for it to get fragmented into 32 1-byte reads 07:55 < sipa> also, is that really a problem? there is already code for reading data into buffers; you shouldn't need to rewrite it 07:55 < wumpus> yes 08:02 < jonasschnelli> Yes. Your right... but since the message can also be a standard-version message, the in-code handling is quite ugly 08:02 < jonasschnelli> But yeah... shouldn't be a problem 08:03 < jonasschnelli> I guess I'm getting lazy and should take a rest. :) 08:08 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev 08:12 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 08:16 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 08:16 -!- vexbuy [~vexbuy@217.23.3.91] has joined #bitcoin-core-dev 08:24 < wumpus> we can all use a rest :) 08:25 -!- viaj3ro [AdiIRC@ip1f1076dd.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev 08:28 < sipa> ooh, a branch 08:28 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 08:31 < instagibbs> !!! 08:31 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 08:31 < gribble> Error: "!!" is not a valid command. 08:31 < lightningbot> instagibbs: Error: "!" is not a valid command. 08:32 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 08:33 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 240 seconds] 08:34 -!- wxss [~user@95.143.192.22] has quit [Quit: leaving] 08:36 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev 08:42 -!- D00M [~doom@49.146.41.106] has quit [Ping timeout: 244 seconds] 08:45 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 08:45 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 08:46 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 08:49 -!- vexbuy [~vexbuy@217.23.3.91] has quit [Ping timeout: 268 seconds] 08:50 < sipa> MarcoFalke, gmaxwell: about the problem of having interdependent dandelion transactions... i think there is no issue 08:50 < sipa> thanks to orphan handling 08:51 < sipa> when a dandelion tx progresses to a normal tx (either because the random percentage change triggered, or because the timeout passed), it is simply processed as if it were received at that time as a normal tx 08:52 < sipa> that means if a child fluffs before its parent, it will simply become an orphan (which is processed later when the parent fluffs, or is received from the network) 08:52 < sipa> if the parent fluffs first, no change in behaviour 08:54 < gmaxwell> well I think that isn't really quite right. Because in the protocol now if someone hands you an orphan thats also an implicit INV for the parents... 08:55 < sipa> well in this case there would just not be someone to send the inv to 08:55 < gmaxwell> I think it's silly to have parents with longer fluff time than children, any increase in privacy is imaginary, because you know a parent was created before the child, so once you see the child you have a maximum timestamp for the parent. 08:57 < sipa> this approach will cause parent and child to be effectively fluffed at the same time, in case the parent would be longer 08:58 < gmaxwell> yes, but perhaps we should do that explicitly rather than depending on the rather lossy orphan handling. 08:58 < sipa> the alternative is to reduce the parent's fluff time in case a child is present... but that sounds like a possibly observable bias 08:58 < sipa> ok, that's fair 08:59 < gmaxwell> but if thats an observable bias, so is the send the child first, since from a "knoweldge about tx times" perspective, they're the same. 08:59 < sipa> right 08:59 < gmaxwell> The only difference is that sending the child first makes us rely on orphan processing, even worse because we'll ignore the getdata for the parent. 08:59 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has quit [Quit: ZNC - http://znc.in] 09:00 < sipa> but i think it's semantically the right (and simplest) thing to do: in case a child expires before its parent, delay it until the parent expires 09:02 < gmaxwell> I think thats right and fine. 09:02 < gmaxwell> basically for every txn compute an exp time and take the max of its own and its maximum parent. 09:03 < gmaxwell> and make the expire time processing obey the order by using depth as a tiebreaker or similar. 09:04 -!- Krellan [~Krellan@2601:640:4000:9258:c037:fba4:6791:e519] has quit [Ping timeout: 240 seconds] 09:07 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has joined #bitcoin-core-dev 09:08 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has joined #bitcoin-core-dev 09:21 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 09:25 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 240 seconds] 09:27 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev 09:33 -!- Krellan [~Krellan@2601:640:4000:9258:5c07:de05:8fcf:774e] has joined #bitcoin-core-dev 09:33 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 09:34 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 09:38 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has quit [Ping timeout: 240 seconds] 09:42 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Read error: Connection reset by peer] 09:42 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 10:07 < sdaftuar> gmaxwell: sipa: in the case of receiving a dandelion child tranaction prior to the (dandelion-)parent transaction having made it to the mempool -- it seems to me like it would be simpler to just delay (dandelion-)relay of the child until the parent is in the mempool 10:07 < sipa> sdaftuar: that wasn't what the discussion was about, though 10:07 < sdaftuar> the concern about breaking one's wallet (not being able to transact for some window) doesn't seem to apply, in that we need to solve that anyway 10:08 < sdaftuar> sipa: oh maybe i misunderstood your earlier discussion 10:09 < sipa> sdaftuar: it's about the case where the timer for a parent transaction goes off because that of a child (both of which are dandelion transactions, which were received in order) 10:10 < sipa> *before that 10:10 < sdaftuar> sorry. yes, i undetstood that's what you were just talking about 10:10 < sdaftuar> i thought greg said earlier that it was a non-starter to delay relay of a child transaction until the parent fluffed 10:10 < sdaftuar> (i think in the normal dandelion case) 10:12 < sdaftuar> greg said yesterday "if someone pays you 1 BTC, you spend 0.1... now your wallet interface needs to randomly fail and tell you that you can't spend again until a fluff has happened" 10:13 < sdaftuar> we already need to do something for our wallet because until the fluff as happened, the change output won't be in your own mempool 10:13 < sdaftuar> and hence won't be spendable 10:13 < sipa> ugh, yes - that's an extra complication 10:13 < sdaftuar> that something can be looking into our own wallet's set of stem transactions, for instance 10:13 -!- aggieben [~aggieben@cpeb7-162.geusnet.com] has joined #bitcoin-core-dev 10:14 < sdaftuar> but we can still slow down relay of children without totally breaking our wallet 10:14 < sdaftuar> (if we need to) 10:16 < sdaftuar> my first thought is that t 10:16 < sdaftuar> oops 10:18 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has quit [Quit: WeeChat 2.2] 10:18 < instagibbs> also comes into consideration with checking balance, yes? 10:18 < instagibbs> (with current code) 10:28 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has joined #bitcoin-core-dev 10:39 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 10:39 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 10:39 -!- Randolf [~randolf@96.53.47.42] has quit [Read error: Connection reset by peer] 10:39 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has quit [Read error: Connection reset by peer] 10:39 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Read error: Connection reset by peer] 10:39 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Excess Flood] 10:39 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev 10:40 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 10:40 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has joined #bitcoin-core-dev 10:41 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 10:45 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 10:50 -!- str4d [~str4d@27.37.99.195.dyn.plus.net] has joined #bitcoin-core-dev 11:00 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 256 seconds] 11:02 -!- Krellan [~Krellan@2601:640:4000:9258:5c07:de05:8fcf:774e] has quit [Remote host closed the connection] 11:02 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev 11:06 < gmaxwell> sdaftuar: I think we can slow the relay down, we just can't _drop_ the transaction. 11:07 < gmaxwell> which is what I thought was being previously proposed. 11:07 < sdaftuar> ah okay 11:07 < gmaxwell> though slowing it might also turn out to be not great, I don't think it's a non-starter. 11:07 < gmaxwell> e.g. you make a chain of 6 transactions... and you're waiting minutes for the last to be broadcast even though you made them all within seconds? 11:08 < sdaftuar> well i was thinknig that delaying transactions whose parents aren't all available as either confirmed inputs or in the memmpool might prevent some dos attacks 11:08 < sdaftuar> but now i am coming up with new dos attacks that don't even rely on that 11:08 < sdaftuar> say you have 1 mempool trnasaction with thousands of outputs 11:09 < sdaftuar> i send you 1000 child transactions, each spending a different output 11:09 < sdaftuar> only the first 25 or so will be accepted 11:09 < sdaftuar> due to chain limits 11:09 < sdaftuar> but how does a dandelion relayer avoid relaying all? i think you would need a stempool 11:11 < sdaftuar> but then a global stempool seems like it might introduce information leakage about routes 11:12 < sdaftuar> while per-peer stempools seem like unacceptably awful overhead 11:18 < gmaxwell> well a "per peer stempool" is really needs to be per output peer, I believe. Also the transactions could be shared between them. 11:25 < sdaftuar> i think if you have any stempool sharing between peers you could start to infer whether a pair of target nodes are dandelion routing to each other 11:44 -!- csknk [~csknk@unaffiliated/csknk] has quit [Read error: Connection reset by peer] 11:44 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev 11:46 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 11:46 < nmnkgl> MarcoFalke: Could you point me to anything would prevent bitcoin core nodes from having crazy everlasting loops in case when there is a ring of whitelisted peers? In regular mode the loop will break at least because of using INVs. That may be very unlikely case though. 11:47 < sdaftuar> nmnkgl: are you referring to a dandelion routing loop? that sounds unfortunate but seems like it's mitigated with a 10% chance of fluffing on every hop, no? 11:54 < gmaxwell> Hm? well dandelion as was proposed on the list has a stempool, so you'll never stem relay the same transaction twice. 11:54 < sdaftuar> yeah that too. i think marco's PR doesn't have one (yet?) 11:55 < nmnkgl> Yes, Dandelion. For non-whitelisted peer loops the solution is just "do nothing once I hear it second time, and eventually fluff". For whitelisted peer loops it would be *send transaction back and forth (statistically not more than 10 times I guess)* 11:56 < gmaxwell> why is whitelisted making a difference in your example? 11:57 < sipa> i think we should ignore the whitelist status for dandelion 11:57 < sipa> its scope shouldn't be extended further 11:58 < gmaxwell> We should change DEFAULT_WHITELISTFORCERELAY to off in any case. Armory said they don't need or want it anymore when we last asked IIRC. 11:58 -!- eslider [~eslider@104.red-83-37-229.dynamicip.rima-tde.net] has quit [Quit: Leaving] 11:58 < gmaxwell> it's really a weird and specialized thing. 11:59 < nmnkgl> gmaxwell: because in the implementation we will relay from whitelisted even if we hear it second time. That's not an issue in regular protocol cause we relay it through INV-GETDATA, and it will go out very fast 12:00 < gmaxwell> nmnkgl: only if WHITELISTFORCERELAY is on, which we should turn off because it's a disaster that screws up the usefulness of whitelisting in the first place. 12:01 < gmaxwell> the only reason I didn't rip that out eons ago was because there was a belief that some parties depended on it, but the only evidence we have for that has since (I think) been invalidated. 12:07 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 12:08 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 12:14 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has quit [Remote host closed the connection] 12:15 -!- JackH [~laptop@host86-174-212-180.range86-174.btcentralplus.com] has joined #bitcoin-core-dev 12:16 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has joined #bitcoin-core-dev 12:16 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 260 seconds] 12:21 -!- cfields_ [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev 12:21 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 12:23 -!- thaumavorio_ [~thaumavor@thaumavor.io] has joined #bitcoin-core-dev 12:23 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 250 seconds] 12:25 -!- Netsplit *.net <-> *.split quits: cfields, jonasschnelli, harding, mappum__, rodarmor, Nebraskka, nmnkgl, gaf_, thaumavorio, herzmeister[m], (+3 more, use /NETSPLIT to show all of them) 12:26 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 12:29 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev 12:31 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 12:32 -!- qinfengling [~qinfengli@45.32.53.207] has joined #bitcoin-core-dev 12:32 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 12:38 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving] 12:38 -!- dqx [~dqx@unaffiliated/dqx] has quit [Ping timeout: 256 seconds] 12:59 -!- Pasha [~Cory@unaffiliated/cory] has quit [Ping timeout: 240 seconds] 13:06 -!- Pasha [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev 13:22 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev 13:24 -!- Dizzle [~dizzle@108.171.182.16] has quit [Remote host closed the connection] 13:27 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev 13:32 -!- jonasschnelli_ [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev 13:35 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 248 seconds] 13:35 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 13:35 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 13:37 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev 13:38 -!- nmnkgl [sid306870@gateway/web/irccloud.com/x-jdkbgodsabpcnsbx] has joined #bitcoin-core-dev 13:42 -!- Randolf [~randolf@96.53.47.42] has quit [Quit: Leaving] 13:47 -!- Dizzle [~dizzle@108.171.182.16] has quit [Remote host closed the connection] 13:48 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev 13:52 -!- promag [~promag@83.223.235.205] has joined #bitcoin-core-dev 14:28 -!- jeremyrubin [~jr@2601:645:4201:6086:6928:3a9a:99af:4891] has joined #bitcoin-core-dev 14:29 < jeremyrubin> Was discussing with wumpus the viability of timing attacks on PR 13666, he suggested I ask here. 14:29 < jeremyrubin> Essentially additional bits leak out if the signature takes longer to generate. 14:30 < sipa> jeremyrubin: you're right, but i believe it doesn't matter 14:30 < sipa> how much does it help you to know (e.g.) that something took 10 tries to generate? 14:30 < jeremyrubin> Was going to paste in your response 14:31 < jeremyrubin> 1 sec... 14:31 < sipa> ah 14:31 < jeremyrubin> sipa: "Yes, indeed. Information theoretically this is a leak. But the only way an attacker can find out whether a particular nonce is in that subset of 1/1024 is by doing 10 EC multiplications on the preceeding nonces... the exact operation we're trying to make expensive." 14:31 < sipa> ah, seems i commented on this before :) 14:32 < jeremyrubin> Yeah -- I somewhat agree, I can't think of a use for this information off the top of my head, especially since the nonces are uncorrolated because of the hash in their generation 14:32 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds] 14:33 < jeremyrubin> But as only an armchair cryptographer I don't feel comfortable asserting that this information is entirely useless 14:34 < sipa> especially since the hash also includes the message, even a precomputed table (assuming there was space to store it) wouldn't help you reduce the search spac 14:38 < jeremyrubin> Correct. 14:46 -!- promag [~promag@83.223.235.205] has quit [Remote host closed the connection] 14:49 < jeremyrubin> I guess here's an example: Let's say we have a signature we observed to take 2 signing periods. Now, in order to grind the key out, we can filter the keyspace based on guessing keys for that specific message and aborting if the determinic nonce takes only 1 to generate. 14:49 < sipa> right, but that test requires an EC multiplication 14:50 < jeremyrubin> So here's my question 14:50 < jeremyrubin> Let's say I have another test I've observed to be 2 signatures 14:51 < jeremyrubin> that is k1 and k2 such that serializesize(k{1,2}XG) = 71 14:51 < jeremyrubin> err 14:51 < jeremyrubin> ignore 14:51 14:51 < jeremyrubin> Another signature I've observed to be 2 signing periods 14:52 < jeremyrubin> that bit of information should be independent, right? 14:52 < jeremyrubin> It still requires an ec mul to test directly 14:52 < sipa> right 14:53 < sipa> i believe the best this can do is reduce the keyspace by N by doing N EC multiplications, with different messages 14:53 < jeremyrubin> but is there any correlation such that if I know sersize(k1 x G) = 71 and sersize(k2 x G) =71 14:53 < sipa> no, they're independent outputs of a hash function with different inputs 14:53 < jeremyrubin> it would allow me to more efficiently test (k1 + k2) x G = 71 14:53 < sipa> if there is such a correlation, sha256 is broken 14:53 < jeremyrubin> I guess I'm asking about ec addition 14:54 < jeremyrubin> like if k1 G is sersize 71 14:54 < jeremyrubin> and k2 G is sersize 71 14:54 < jeremyrubin> do we know anything about k1+k2? 14:54 < sipa> ah; i believe these is no such test, but no proof that there isn't 14:54 < jeremyrubin> (nothing to do with sha256) 14:54 < jeremyrubin> If such a test did exist 14:54 < jeremyrubin> Then you could use this timing attack 14:55 < sipa> i think we may reasonable weaken the statement that it would require an attacker to perform 2^256 sha256 hashes to meaningfully reduce the keyspace 14:55 < sipa> which is far slower than a direct 2^128 EC DLP attack 14:56 < sipa> but this is a good point 14:56 < jeremyrubin> Ah also 14:56 < jeremyrubin> I have the bit that k1_0 is 72 sersize 14:56 < jeremyrubin> and k2_0 is 72 sersize 14:57 < jeremyrubin> I think that's the bit that gets leaked that's more interesting 14:57 < sipa> perhaps - but it also requires hashes to discover 14:57 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 14:57 < jeremyrubin> Yeah 14:57 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 14:59 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 14:59 < jeremyrubin> Anyways, it's far from a practical attack... I just would prefer that we draft exactlty what the attack is/impact could it be rolled out before releasing 13666 15:00 < sipa> yes, a writeup of the concerns and reasoning would be useful 15:00 < jeremyrubin> I'm interested to work on it, but it's a bit beyond my depth as a cryptographer 15:08 < jeremyrubin> Incidentally, the timing attack can be addressed by generating 256 signatures always, partitioning on serialized size, and then picking a random one from the small size partition. 15:09 < jeremyrubin> 256x signing time might be not worth it, but I think this should basically work ;) (and if none are 71 bytes in 256, then re-do -- I think we're good leaking bits 1/2^256 times) 15:10 < sipa> that too results in a bias 15:10 < jeremyrubin> What's the bias there? 15:10 < sipa> (an equally harmless one, imho, though) 15:11 < sipa> lower probability for R values that are the outcome of key/msg that have higher than average number of low-R results 15:11 < sipa> (in their set of 256) 15:11 < jeremyrubin> How is this leaked? we reveal 1 at random out of the low-R set? 15:12 < jeremyrubin> Ah can't be random, right 15:12 < sipa> yes, but it's biased 15:12 < sipa> again, i don't thin this would be a concern 15:12 < jeremyrubin> so would have to be with some deterministic sort, pick 1 15:12 < sipa> but if leaks of any kind are a concern, this is one too 15:12 < sipa> nope; still biased 15:13 < jeremyrubin> (yep, just making the correction that made my algo non-det) 15:13 < jeremyrubin> Trying to understand the bias 15:13 < sipa> a correct solution would be to introduce a small amount of true randomness in the hash :) 15:13 < sipa> as that's unobservable to an attacker 15:14 < jeremyrubin> then no longer deterministic ;) 15:14 < sipa> precisely. 15:15 < jeremyrubin> I still don't quite get the bias being leaked.... it's just the original 1 bit of low-R/high-R? 15:15 < sipa> but some R values have higher probability than others 15:15 < jeremyrubin> Interesting... didn't know that 15:15 < jeremyrubin> I thought it's supposed to be uniform 15:15 < sipa> the message is public 15:15 < sipa> so we assume m is fixed 15:16 < sipa> your algorithm is to take the secret private key, and feed it through 256 different hash functions (essentially; in practice they also take the msg as input, but we treat that as fixed part of the hash functions) 15:16 < sipa> agree with me so far? 15:16 < jeremyrubin> yes 15:17 < sipa> then map those 256 hash outputs to points, and look at their lowrness (i love that word) 15:17 < jeremyrubin> haha, yep 15:17 < sipa> and then pick randomly one of the lowr ones (which will approximately be 128, but could be more or less) 15:18 < jeremyrubin> * deterministically 15:18 < sipa> oh, deterministically! 15:18 < sipa> then it's even easier 15:19 < sipa> your entire construct is a deterministic function from private key to point 15:19 < sipa> which you can test for by iterating 15:19 < jeremyrubin> No? The message is included. 15:19 < sipa> the message is known to the attack, which we can treat as part of the definition of the hash function 15:19 < jeremyrubin> fair 15:19 < sipa> *attacker 15:20 < jeremyrubin> So how is a bit leaked? 15:20 < jeremyrubin> (or a < bit) 15:20 < sipa> the entire private key is leaked :) 15:20 < sipa> information theoretically 15:20 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has quit [Remote host closed the connection] 15:21 < jeremyrubin> really? Now I'm lost.. 15:21 < gmaxwell> jeremyrubin: "grind against the key" is an uninteresting attack. oh I was just about to point out what sipa did, that if you assume a computationally unbounded attacker every signature leaks the key. 15:21 < gmaxwell> (or just publishing the pubkey leaks the key) 15:21 < sipa> jeremyrubin: information theoretically the attacker can try every private key, and look at which R point comes out of each, and compare it with the R you produced 15:21 < sipa> jeremyrubin: that leaks the entire private key :) 15:22 < sipa> (this is a problem that every deterministic algorithm has, and it's not interesting because we don't care about information theoretical security) 15:22 < gmaxwell> also, as an asside your conjectural 'weakness' goes away if we provide use the extra random input. 15:22 * jeremyrubin sighs 15:22 < gmaxwell> Which I suppose we should just do regardless, unless configured otherwise. 15:22 < sipa> if you care about _computational_ security, a bias only matters if it lets you meaningully speed up the attack 15:22 < jeremyrubin> I'm just talking about the timing attack 15:22 < sipa> so am i 15:23 < gmaxwell> jeremyrubin: also RFC6979 _inherently_ has this kind of timing attack because of the restriction into the scalar range. 15:23 < jeremyrubin> Yes, the above potential attack about correlation in serializable size under addition 15:23 < gmaxwell> If the HMAC_DRBG result is larger than N it tries again. 15:23 < jeremyrubin> Interesting. 15:24 < sipa> jeremyrubin: sorry for bringing up information theoretical security; i just want to point out that "leaking a bit" inherently isn't a proble 15:24 < sipa> the problem is leaking information that leads to a faster attack 15:25 < sipa> because every deterministic algorithm leaks *all* the bits already, but not in a usable way 15:26 < jeremyrubin> Well, is secp256k1 bijective ;) 15:26 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Remote host closed the connection] 15:27 < gmaxwell> do you mean is the scalar range mappable onto points sG both directions? of course. But the mapping is (we hope!) only efficiently computable one way. 15:27 < gmaxwell> If your attacker has unbounded computing time, however, he could compute it both ways. 15:27 < gmaxwell> Which is why it has only computational security. 15:28 < sipa> yes, informational theoretically ECDSA is trivial to break overall 15:28 < sipa> again my point: leaking a bit isn't what matters 15:31 -!- Rootsudo [~textual@112.205.33.21] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 15:31 < jeremyrubin> be back in a... bit 15:36 -!- promag [~promag@83.223.235.205] has joined #bitcoin-core-dev 15:36 < gmaxwell> jeremyrubin: Consider the legacy signer. You produce a stream of signatures. Roughly half are low R, roughtly half are high R. The low R ones are ones where the selected K got the low R on the first try, and the ones with a high R are ones where it was high on the first try. Every determinstic algorithim always 'leaks' all the data, but the 'leak' is not useful. 15:37 < sipa> right; the legacy signer already leaks the 'bit' of information whether or not the first was low R or not 15:38 < sipa> the only thing added is that it's the total number of attempts, and not just whether it was 0 or nonzero 15:38 < gmaxwell> It's essentially the same 'leak' as you're talking about with timing. (technically timing is more than 1 bit, but you can get that by not just looking at low vs high R) 15:38 < sipa> (possibly, to a timing attacker) 15:38 < gmaxwell> e.g. it's isomorpic to looking at R and counting how many leading 0s it has. 15:38 < sipa> to a non-timing attacker the new algorithm actually leaks less 15:42 -!- Krellan_ [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 15:44 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 248 seconds] 15:46 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.1] 15:51 -!- itaseski [~itaseski@213.135.176.242] has quit [Ping timeout: 272 seconds] 15:52 -!- str4d [~str4d@27.37.99.195.dyn.plus.net] has quit [Ping timeout: 240 seconds] 15:58 -!- pluit [~pluit@gateway/tor-sasl/pluit] has quit [Quit: pöes] 16:08 -!- promag [~promag@83.223.235.205] has quit [Remote host closed the connection] 16:33 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has quit [Remote host closed the connection] 16:35 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 16:41 -!- promag [~promag@83.223.235.205] has joined #bitcoin-core-dev 16:51 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [] 16:52 -!- Dizzle [~dizzle@108.171.182.16] has quit [Ping timeout: 240 seconds] 16:52 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 16:53 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 17:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 17:12 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 17:15 -!- promag [~promag@83.223.235.205] has quit [Remote host closed the connection] 17:16 -!- miknotauro_ [~miknotaur@187.207.33.20] has joined #bitcoin-core-dev 17:25 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds] 17:33 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 17:43 -!- viaj3ro [AdiIRC@ip1f1076dd.dynamic.kabel-deutschland.de] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 17:48 -!- ken2812221_ [~ken281222@1.200.219.221] has joined #bitcoin-core-dev 17:50 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 17:57 -!- Netsplit *.net <-> *.split quits: Emcy, IGHOR, AaronvanW, ken2812221, Giszmo 17:57 -!- Netsplit *.net <-> *.split quits: musalbas, petertodd, davex__, xHire, games_, booyah, murr4y, chjj, ryanofsky 18:00 -!- Netsplit over, joins: Emcy 18:04 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev 18:04 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has joined #bitcoin-core-dev 18:04 -!- xHire [~xHire@kos.paskuli.cz] has joined #bitcoin-core-dev 18:04 -!- musalbas [~musalbas@algebra.musalbas.com] has joined #bitcoin-core-dev 18:04 -!- ryanofsky [russ@jumpy.yanofsky.org] has joined #bitcoin-core-dev 18:04 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev 18:04 -!- 18WAA5MDD [~user@97-119-117-177.omah.qwest.net] has joined #bitcoin-core-dev 18:04 -!- games_ [sid99242@gateway/web/irccloud.com/x-kclqcugjzthfflay] has joined #bitcoin-core-dev 18:04 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 18:04 -!- murr4y [ali@11.0.196.35.bc.googleusercontent.com] has joined #bitcoin-core-dev 18:04 -!- petertodd [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has joined #bitcoin-core-dev 18:04 -!- murr4y [ali@11.0.196.35.bc.googleusercontent.com] has quit [Max SendQ exceeded] 18:04 -!- 18WAA5MDD [~user@97-119-117-177.omah.qwest.net] has quit [Remote host closed the connection] 18:04 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 263 seconds] 18:20 -!- brunner_mobile [~Android@pdpc/supporter/gold/brunner] has joined #bitcoin-core-dev 18:22 -!- brunner_mobile [~Android@pdpc/supporter/gold/brunner] has quit [Quit: -a- IRC for Android 2.1.40] 18:30 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds] 18:54 -!- D00M [~doom@49.146.41.106] has joined #bitcoin-core-dev 19:04 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 19:06 -!- Krellan_ [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 244 seconds] 19:15 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Read error: No route to host] 19:20 -!- Pasha [~Cory@unaffiliated/cory] has quit [Ping timeout: 260 seconds] 19:22 -!- goatpig [56eece80@gateway/web/freenode/ip.86.238.206.128] has quit [Ping timeout: 252 seconds] 19:26 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev 19:26 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 19:37 -!- waiting2compile [43aef314@gateway/web/freenode/ip.67.174.243.20] has joined #bitcoin-core-dev 19:52 < waiting2compile> hi, could someone walk me a bit through running Bitcoin's tests? I tried following the instructions in the README.md, though I suspect there's some extra setup that needs to be done that's missing, since running the command just gives make errors and the like (pardon me, I'm new to this and am trying to fix one of the good first bugs :)) 19:57 < sipa> have you looked at build-unix.md (or windows/osx, based on your environement) 19:57 < sipa> ? 20:01 < waiting2compile> Ah I had not, I'll try following the instructions there and see if I have any luck 20:05 -!- thaumavorio_ is now known as thaumavorio 20:18 -!- D00M [~doom@49.146.41.106] has quit [Quit: Leaving] 20:19 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 276 seconds] 20:19 -!- Cory [~Cory@unaffiliated/cory] has quit [] 20:26 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev 20:33 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 20:46 -!- unholymachine [~quassel@2601:8c:c003:9f16:28cf:9ccf:ebef:3576] has quit [Remote host closed the connection] 21:01 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 21:02 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 21:18 -!- unholymachine [~quassel@2601:8c:c003:9f16:6c76:f163:bba:9166] has joined #bitcoin-core-dev 21:32 < ken2812221_> Fetching qtbase-opensource-src-5.9.6.tar.xz from https://download.qt.io/official_releases/qt/5.9/5.9.6/submodules 21:32 < ken2812221_> % Total % Received % Xferd Average Speed Time Time Time Current 21:32 < ken2812221_> Dload Upload Total Spent Left Speed 21:32 < ken2812221_> 0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0curl: (7) Failed to connect to download.qt.io port 443: No route to host 21:32 < ken2812221_> Fetching qtbase-opensource-src-5.9.6.tar.xz from https://bitcoincore.org/depends-sources 21:32 < ken2812221_> % Total % Received % Xferd Average Speed Time Time Time Current 21:32 < ken2812221_> Dload Upload Total Spent Left Speed 21:32 < ken2812221_> 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0 21:32 < ken2812221_> curl: (22) The requested URL returned error: 404 Not Found 21:33 < ken2812221_> download.qt.io is down, also there is no backup at bitcoincore.org 21:35 < luke-jr> not sure who maintains the bitcoincore.org mirrors 21:36 < luke-jr> fwiw there's a mirror here http://distfiles.gentoo.org/distfiles/qtbase-opensource-src-5.9.6.tar.xz 21:38 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.] 21:39 -!- Krellan [~Krellan@50-203-21-10-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 21:44 -!- jamesob [~james@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds] 21:44 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 268 seconds] 21:44 -!- prod_ [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 256 seconds] 21:44 -!- marcinja [~marcin@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds] 22:05 -!- waiting2compile [43aef314@gateway/web/freenode/ip.67.174.243.20] has quit [Quit: Page closed] 22:10 < ken2812221_> luke-jr: thanks, that works 22:12 < ken2812221_> But I think I'll need to rebuild qt once I change back to download.qt.io site site 22:13 < luke-jr> why? 22:37 < ken2812221_> luke-jr: Since I changed the link in .mk file 22:38 < ken2812221_> hash does not match the previous built one. 23:21 -!- baldur [~baldur@pool-100-2-154-254.nycmny.btas.verizon.net] has quit [Ping timeout: 260 seconds] 23:24 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 23:25 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 23:52 -!- hashrate [~root@li1803-11.members.linode.com] has joined #bitcoin-core-dev 23:58 -!- baldur [~baldur@pool-72-69-77-244.nycmny.fios.verizon.net] has joined #bitcoin-core-dev --- Log closed Tue Aug 14 00:00:39 2018