12018-08-13T00:04:27  *** bytting has quit IRC
  22018-08-13T00:43:02  *** d9b4bef9 has quit IRC
  32018-08-13T00:44:09  *** d9b4bef9 has joined #bitcoin-core-dev
  42018-08-13T01:01:54  *** promag has quit IRC
  52018-08-13T01:21:27  *** Rootsudo has joined #bitcoin-core-dev
  62018-08-13T01:36:25  *** phwalkr has joined #bitcoin-core-dev
  72018-08-13T01:46:05  *** Rootsudo has quit IRC
  82018-08-13T01:50:04  *** Krellan has quit IRC
  92018-08-13T01:59:08  *** ken2812221 has joined #bitcoin-core-dev
 102018-08-13T02:13:35  *** Aaronvan_ has quit IRC
 112018-08-13T02:13:49  *** bitcoinvolumetra has joined #bitcoin-core-dev
 122018-08-13T02:15:51  <bitcoinvolumetra> hey guys have 305,000 coins to liquidate at a discount. satoshi test will be supplied to a wallet of your choice on the grounds the buyer can provide validation of funds. preferably mt199/799 supplied to the sellers bank by the buyers bank. any questions please pm me.
 132018-08-13T02:18:04  <sipa> bitcoinvolumetra: go away
 142018-08-13T02:18:39  *** ChanServ sets mode: +o sipa
 152018-08-13T02:23:54  *** goatpig has quit IRC
 162018-08-13T02:24:18  *** AaronvanW has joined #bitcoin-core-dev
 172018-08-13T02:28:27  *** AaronvanW has quit IRC
 182018-08-13T02:38:41  <sipa> bitcoinvolumetra: this is a development channel, not a marketplace. Also, if you were really selling 2 billion dollars worth of BTC, you wouldn't be ramdomly asking strangers on irc
 192018-08-13T02:57:33  *** Rootsudo has joined #bitcoin-core-dev
 202018-08-13T03:11:54  *** bitcoinvolumetra has quit IRC
 212018-08-13T03:13:44  <midnightmagic> he ain't got no time for your logic
 222018-08-13T03:15:18  <gmaxwell> Full Billionare mode.
 232018-08-13T03:17:24  <sipa> *double* billionaire mode
 242018-08-13T03:24:54  <luke-jr> XD
 252018-08-13T03:25:06  *** AaronvanW has joined #bitcoin-core-dev
 262018-08-13T03:25:12  <luke-jr> sipa: maybe it is at such a large discount that it isn't $2B? :P
 272018-08-13T03:25:21  * midnightmagic makes head-exploding motions with hands but nothing happens
 282018-08-13T03:26:56  *** Krellan has joined #bitcoin-core-dev
 292018-08-13T03:30:33  *** AaronvanW has quit IRC
 302018-08-13T03:43:10  *** zivl has quit IRC
 312018-08-13T03:43:59  *** zivl has joined #bitcoin-core-dev
 322018-08-13T03:53:01  *** d9b4bef9 has quit IRC
 332018-08-13T03:54:14  *** d9b4bef9 has joined #bitcoin-core-dev
 342018-08-13T03:56:11  <ossifrage> Now that I'm not running out of file descriptors for sockets, I've been auditing my connections and was suprised how many IPs have multiple connections to my node
 352018-08-13T03:57:01  <gmaxwell> spys.. they'll probably stop doing that once 0.17 is widely deployed.
 362018-08-13T03:57:16  <gmaxwell> since it defeats what they're trying to accomplish.
 372018-08-13T03:58:59  <gmaxwell> (by connecting multiple times they effectively speed up how fast transactions are relayed to them, making it easier to determine origins)
 382018-08-13T03:59:22  <ossifrage> One 111.6.90.203 has 6 connections, whois says it belongs to chinamobile
 392018-08-13T03:59:51  <ossifrage> I wonder if that is actually legit traffic from heavily NATed users?
 402018-08-13T04:00:14  <gmaxwell> could be, in some cases.. reasons like that are why we don't outright limit.
 412018-08-13T04:08:34  *** Rootsudo has quit IRC
 422018-08-13T05:27:02  *** AaronvanW has joined #bitcoin-core-dev
 432018-08-13T05:27:15  *** plankers has quit IRC
 442018-08-13T05:31:21  *** AaronvanW has quit IRC
 452018-08-13T05:47:40  <wumpus> it's possible though the I'd expect the chance is very low that a bunch of NATed users would connect to your node, of all things, all the same time
 462018-08-13T05:49:51  <wumpus> two of them, okay, but six?
 472018-08-13T05:58:59  <wumpus> especially if they connected aruond the same time, too, and have the same agent string, it's clear
 482018-08-13T06:13:28  <wumpus> did I mention I miss the github merge bot here already
 492018-08-13T06:15:54  <luke-jr> wumpus: DNS seeds and how light wallets use them can result in a lot of nodes connecting to a small set of listening nodes sometimes
 502018-08-13T06:28:13  <wumpus> luke-jr: that's a fair point, so indeed, I don't see it as impossible just unlikely
 512018-08-13T06:34:51  *** phwalkr has quit IRC
 522018-08-13T06:34:53  *** vexbuy has joined #bitcoin-core-dev
 532018-08-13T06:36:21  *** phwalkr has joined #bitcoin-core-dev
 542018-08-13T06:42:40  *** Victorsueca has quit IRC
 552018-08-13T06:43:54  *** Victorsueca has joined #bitcoin-core-dev
 562018-08-13T06:44:05  *** Emcy_ has quit IRC
 572018-08-13T06:53:32  <gmaxwell> sipa: skip RW locks and go straight to URCU https://lwn.net/Articles/573424/  ? :P
 582018-08-13T07:01:27  *** vexbuy has quit IRC
 592018-08-13T07:07:26  *** timothy has joined #bitcoin-core-dev
 602018-08-13T07:18:11  *** Emcy has joined #bitcoin-core-dev
 612018-08-13T07:19:32  *** IGHOR has quit IRC
 622018-08-13T07:27:47  *** AaronvanW has joined #bitcoin-core-dev
 632018-08-13T07:28:48  *** phwalkr has joined #bitcoin-core-dev
 642018-08-13T07:32:55  *** AaronvanW has quit IRC
 652018-08-13T07:33:21  *** phwalkr has quit IRC
 662018-08-13T07:39:59  *** SopaXorzTaker has joined #bitcoin-core-dev
 672018-08-13T07:40:43  *** jb55 has quit IRC
 682018-08-13T07:44:24  *** jb55 has joined #bitcoin-core-dev
 692018-08-13T07:55:02  *** d9b4bef9 has quit IRC
 702018-08-13T07:56:09  *** d9b4bef9 has joined #bitcoin-core-dev
 712018-08-13T08:02:15  *** IGHOR has joined #bitcoin-core-dev
 722018-08-13T08:07:16  *** csknk has joined #bitcoin-core-dev
 732018-08-13T08:09:37  *** IGHOR has quit IRC
 742018-08-13T08:30:30  *** vexbuy has joined #bitcoin-core-dev
 752018-08-13T08:38:32  *** IGHOR has joined #bitcoin-core-dev
 762018-08-13T08:38:58  <wumpus> so according to #12624 it's time to split off the 0.17 branch today
 772018-08-13T08:38:59  <gribble> https://github.com/bitcoin/bitcoin/issues/12624 | Release schedule for 0.17.0 · Issue #12624 · bitcoin/bitcoin · GitHub
 782018-08-13T08:39:21  *** vexbuy_ has joined #bitcoin-core-dev
 792018-08-13T08:41:11  <wumpus> let's see how far we get...
 802018-08-13T08:42:35  *** vexbuy has quit IRC
 812018-08-13T08:44:02  *** vexbuy has joined #bitcoin-core-dev
 822018-08-13T08:44:45  *** ken2812221_ has joined #bitcoin-core-dev
 832018-08-13T08:47:53  *** vexbuy_ has quit IRC
 842018-08-13T08:48:43  *** vexbuy_ has joined #bitcoin-core-dev
 852018-08-13T08:52:42  *** vexbuy has quit IRC
 862018-08-13T08:53:04  <kallewoof> wumpus: I think I've reviewed all the 0.17 PR's that I feel comfy reviewing
 872018-08-13T08:53:12  *** vexbuy has joined #bitcoin-core-dev
 882018-08-13T08:54:25  <kallewoof> is there anything else that needs doing besides review?
 892018-08-13T08:55:43  <wumpus> we'll probably want to put up the release notes in the wiki
 902018-08-13T08:55:49  *** nodweber has quit IRC
 912018-08-13T08:55:51  *** vexbuy_ has quit IRC
 922018-08-13T08:56:16  <wumpus> so that people can work on the remaining items in #12391
 932018-08-13T08:56:17  <gribble> https://github.com/bitcoin/bitcoin/issues/12391 | TODO for release notes 0.17.0 · Issue #12391 · bitcoin/bitcoin · GitHub
 942018-08-13T08:56:40  <wumpus> I'm also working on doing a final translations update before the branch-off
 952018-08-13T08:57:46  *** vexbuy_ has joined #bitcoin-core-dev
 962018-08-13T08:58:38  <wumpus> but as for things holding back the branch, yes I think reviewing the ones tagged 0.17 is most important now
 972018-08-13T08:58:41  * kallewoof can't even find the wiki link from github, so going to leave that one for someone who's not clueless :P
 982018-08-13T08:59:08  <kallewoof> got it. I'll double check if anything was updated and re-review.
 992018-08-13T09:00:17  *** vexbuy has quit IRC
1002018-08-13T09:00:39  <kallewoof> even better is to actually try the code and not just stop at utACKing...
1012018-08-13T09:02:16  *** vexbuy has joined #bitcoin-core-dev
1022018-08-13T09:03:30  <wumpus> as for wiki link: https://github.com/bitcoin-core/bitcoin-devwiki/wiki
1032018-08-13T09:05:58  *** vexbuy_ has quit IRC
1042018-08-13T09:06:36  *** itaseski has joined #bitcoin-core-dev
1052018-08-13T09:06:45  *** vexbuy_ has joined #bitcoin-core-dev
1062018-08-13T09:06:55  <kallewoof> Ohh... no wonder i couldn't find it
1072018-08-13T09:06:59  <kallewoof> Thanks
1082018-08-13T09:08:14  *** fanquake has joined #bitcoin-core-dev
1092018-08-13T09:09:27  *** vexbuy has quit IRC
1102018-08-13T09:11:03  <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?
1112018-08-13T09:11:14  <kallewoof> Huh... https://pastebin.com/cC29k9Sz
1122018-08-13T09:11:24  *** vexbuy has joined #bitcoin-core-dev
1132018-08-13T09:12:13  <kallewoof> I tried [ createpsbt "[]" "[{\"$(./bitcoin-cli getnewaddress)\":0.01}]" ], which worked fine. But decodepsbt errors for the result.
1142018-08-13T09:12:39  * kallewoof should probably read up on how these commands work
1152018-08-13T09:15:18  *** vexbuy_ has quit IRC
1162018-08-13T09:15:57  *** vexbuy_ has joined #bitcoin-core-dev
1172018-08-13T09:17:27  *** plankers has joined #bitcoin-core-dev
1182018-08-13T09:18:35  *** vexbuy has quit IRC
1192018-08-13T09:20:32  *** vexbuy has joined #bitcoin-core-dev
1202018-08-13T09:24:27  *** vexbuy_ has quit IRC
1212018-08-13T09:25:11  *** vexbuy_ has joined #bitcoin-core-dev
1222018-08-13T09:25:34  *** AaronvanW has joined #bitcoin-core-dev
1232018-08-13T09:29:26  *** vexbuy has quit IRC
1242018-08-13T09:29:44  *** vexbuy__ has joined #bitcoin-core-dev
1252018-08-13T09:32:27  *** vexbuy_ has quit IRC
1262018-08-13T09:34:00  <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
1272018-08-13T09:34:02  <gribble> https://github.com/bitcoin/bitcoin/issues/13938 | refactoring: Cleanup StartRest() by DesWurstes · Pull Request #13938 · bitcoin/bitcoin · GitHub
1282018-08-13T09:34:09  *** vexbuy has joined #bitcoin-core-dev
1292018-08-13T09:34:53  <wumpus> really tired of these twiddle-the-code-a-bit-without-really-doing-anything
1302018-08-13T09:35:08  <wumpus> agree 13808 is ready
1312018-08-13T09:35:35  <wumpus> thanks everyone for reviewing that one it was needed !
1322018-08-13T09:37:50  *** vexbuy__ has quit IRC
1332018-08-13T09:37:56  <fanquake> Plenty more refactoring type PRs to review heh
1342018-08-13T09:38:34  *** vexbuy_ has joined #bitcoin-core-dev
1352018-08-13T09:39:16  <fanquake> 13899 maybe ready, but probably needs at least one tested ACK from someone using GCC
1362018-08-13T09:40:01  <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
1372018-08-13T09:40:48  <wumpus> so I'd say we close that kind
1382018-08-13T09:41:21  *** vexbuy has quit IRC
1392018-08-13T09:42:24  <wumpus> redundant declarations meh
1402018-08-13T09:42:45  <fanquake> wumpus I feel a lot of closed PRs in the near hours
1412018-08-13T09:43:09  *** vexbuy has joined #bitcoin-core-dev
1422018-08-13T09:43:26  <wumpus> fanquake: haha if it was only up to me
1432018-08-13T09:44:00  <wumpus> no, removing redundant declarations is okay, but I don't see it as a focus point for 0.17
1442018-08-13T09:47:07  *** vexbuy_ has quit IRC
1452018-08-13T09:47:26  <fanquake> Seems like there is "some" agreement around #13666 ? Still tagged for 0.17.
1462018-08-13T09:47:28  <gribble> https://github.com/bitcoin/bitcoin/issues/13666 | Always create signatures with Low R values by achow101 · Pull Request #13666 · bitcoin/bitcoin · GitHub
1472018-08-13T09:47:37  *** vexbuy_ has joined #bitcoin-core-dev
1482018-08-13T09:47:54  <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.
1492018-08-13T09:48:45  <wumpus> 0.17 release notes are on the wiki https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes
1502018-08-13T09:49:06  <wumpus> fanquake: I'm somewhat reluctant on that one
1512018-08-13T09:49:32  <wumpus> maybe someone can convince me why it's important to merge that last minute before 0.17
1522018-08-13T09:50:30  *** vexbuy has quit IRC
1532018-08-13T09:52:16  *** vexbuy has joined #bitcoin-core-dev
1542018-08-13T09:53:06  <wumpus> ah the signature size counting issue for feerate was resolved
1552018-08-13T09:53:32  <wumpus> and it has plenty of utACKs
1562018-08-13T09:53:43  <wumpus> so I think it should just go in
1572018-08-13T09:55:16  <wumpus> fanquake: reducing the entropy of the nonce was the biggest concern it seems
1582018-08-13T09:56:32  <fanquake> wumpus thanks, just merging/running tests etc
1592018-08-13T09:56:40  <wumpus> and making signing time double--but that seems unimportant and nneglible in comparison to utxo selection and such when sending a transaction
1602018-08-13T09:56:41  *** vexbuy_ has quit IRC
1612018-08-13T09:56:54  *** vexbuy_ has joined #bitcoin-core-dev
1622018-08-13T09:59:38  *** vexbuy_ has quit IRC
1632018-08-13T10:01:07  *** vexbuy has quit IRC
1642018-08-13T10:07:48  *** plankers has quit IRC
1652018-08-13T10:22:03  *** plankers has joined #bitcoin-core-dev
1662018-08-13T10:31:31  *** Guyver2 has joined #bitcoin-core-dev
1672018-08-13T10:40:22  *** no_input_found has joined #bitcoin-core-dev
1682018-08-13T10:55:55  *** vexbuy has joined #bitcoin-core-dev
1692018-08-13T10:56:13  *** ken2812221_ has quit IRC
1702018-08-13T11:06:56  <MarcoFalke> wumpus: I think https://github.com/bitcoin/bitcoin/pull/13905 can go in to 0.17 as doc bug fix (tiny one)
1712018-08-13T11:07:43  <MarcoFalke> manpages need to be regenerated anyway
1722018-08-13T11:07:50  <MarcoFalke> (after the version bump)
1732018-08-13T11:13:40  <MarcoFalke> lol, why do we have appveryor as ci check?
1742018-08-13T11:14:37  <fanquake> MarcoFalke appveryor?
1752018-08-13T11:14:47  <MarcoFalke> https://github.com/bitcoin/bitcoin/pull/13939#ref-commit-ef86f26
1762018-08-13T11:14:58  <MarcoFalke> Oh well, only on this commit
1772018-08-13T11:15:29  <MarcoFalke> because it was also pushed to some other remote (with appveyor)
1782018-08-13T11:16:09  <fanquake> huh ok
1792018-08-13T11:23:26  <MarcoFalke> Going to merge #13905 as well.
1802018-08-13T11:23:28  <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
1812018-08-13T11:23:34  <MarcoFalke> I think after that we are good to branch off
1822018-08-13T11:23:53  <MarcoFalke> (and backport any remaining bugfixes)
1832018-08-13T11:23:58  <MarcoFalke> later on
1842018-08-13T11:32:26  <wumpus> yay
1852018-08-13T11:32:50  <MarcoFalke> Oh wait, we should merge the loose release notes file into the master doc
1862018-08-13T11:33:14  <MarcoFalke> Otherwise they will be sitting  around forever
1872018-08-13T11:33:38  <wumpus> I've already put the release notes in the wiki, probably want to do that there
1882018-08-13T11:34:20  <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
1892018-08-13T11:37:37  <fanquake> So backport 13917 and 13788 after branch off?
1902018-08-13T11:38:05  <wumpus> if there is anything we *know* that should be backported and is open now, I say we should merge it right now
1912018-08-13T11:38:13  <wumpus> backporting post-branch is for things we don't know about yet
1922018-08-13T11:38:25  <fanquake> I'm just looking at https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.17.0
1932018-08-13T11:38:35  <fanquake> One needs a rebase, the -disable-asm changes I'm not sure about.
1942018-08-13T11:38:55  <MarcoFalke> Yeah, needs a rebase and re-ACK. That might take some days
1952018-08-13T11:38:59  <wumpus> yes the latter seems to be controversial
1962018-08-13T11:39:20  <wumpus> ok agreed, probably makes no sense to hold up rc1 for a few days for that
1972018-08-13T11:39:33  <wumpus> might even postpone it to 0.17.1
1982018-08-13T11:39:58  <fanquake> Sounds like it's time to branch then
1992018-08-13T11:40:36  <wumpus> might want to do a hardcoded seed update first
2002018-08-13T11:40:49  <wumpus> BLOCK_CHAIN_SIZE was recently adapted afaik
2012018-08-13T11:41:02  <wumpus> the chainparams stats too
2022018-08-13T11:41:05  <fanquake> Yes, to 220 I think.
2032018-08-13T11:42:03  <wumpus> last hardcoded seeds update was in januari, so I'm going to do that
2042018-08-13T11:42:09  <MarcoFalke> sounds good
2052018-08-13T11:46:25  <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])
2062018-08-13T11:47:15  <fanquake> I guess 0.13 has reached its "end of life"
2072018-08-13T11:47:26  <fanquake> Or did, at the start of the month https://bitcoincore.org/en/lifecycle/
2082018-08-13T11:48:15  <fanquake> Does that warrant removal?
2092018-08-13T11:48:19  <wumpus> it did, is that enough reason, or does it need any specific reason to exclude it based on compatiblity?
2102018-08-13T11:49:02  *** wxss has joined #bitcoin-core-dev
2112018-08-13T11:49:12  <wumpus> I don't think it matters much, there shouldn't be many 0.13.x nodes around anymore
2122018-08-13T11:50:04  <fanquake> I guess it's just 0.13.1 + that have segwit support
2132018-08-13T11:50:34  <wumpus> I'll just remove it
2142018-08-13T11:55:53  *** vexbuy_ has joined #bitcoin-core-dev
2152018-08-13T11:57:02  *** d9b4bef9 has quit IRC
2162018-08-13T11:57:15  *** vexbuy has quit IRC
2172018-08-13T11:58:08  *** d9b4bef9 has joined #bitcoin-core-dev
2182018-08-13T12:00:51  <wumpus> #13951
2192018-08-13T12:00:52  <gribble> https://github.com/bitcoin/bitcoin/issues/13951 | Hardcoded seeds update pre-0.17 branch by laanwj · Pull Request #13951 · bitcoin/bitcoin · GitHub
2202018-08-13T12:14:32  *** wxss has quit IRC
2212018-08-13T12:23:00  *** wxss has joined #bitcoin-core-dev
2222018-08-13T12:34:05  *** plankers has quit IRC
2232018-08-13T12:46:05  <wumpus> I'll wait for some acks on that
2242018-08-13T12:55:15  *** goatpig has joined #bitcoin-core-dev
2252018-08-13T13:17:09  <MarcoFalke> The default for GetDesirableServiceFlags didn't change, so looks correct
2262018-08-13T13:17:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2272018-08-13T13:28:40  <wumpus> so I think it's ready for branch?
2282018-08-13T13:29:19  <fanquake> It would seem that way
2292018-08-13T13:29:46  <fanquake> manpages? Or they can be done later on
2302018-08-13T13:30:25  <wumpus> that needs to be done after upping the versions
2312018-08-13T13:32:09  <MarcoFalke> lets do it!
2322018-08-13T13:33:21  <fanquake> on time!
2332018-08-13T13:35:12  <wumpus> https://github.com/bitcoin/bitcoin/tree/0.17 !
2342018-08-13T13:35:23  *** vexbuy_ has quit IRC
2352018-08-13T13:35:36  <wumpus> yes this is fantastic, we didn't have to postpone it this time :)
2362018-08-13T13:38:58  <wumpus> versions bumped, if you want to do an update-manpages PR go ahead
2372018-08-13T13:39:11  <wumpus> (need a seperate one for master and 0.17)
2382018-08-13T13:39:42  <TheHoliestRoger> thank you for your hard work all
2392018-08-13T13:41:36  <MarcoFalke> no pressing need to bump on master for now
2402018-08-13T13:41:54  <MarcoFalke> Probably enough to do it twice a year or so
2412018-08-13T13:42:06  <MarcoFalke> But the gitian-descriptor would need to be bumped on master?
2422018-08-13T13:42:22  <TheHoliestRoger> you got 3 gitian sigs yet?
2432018-08-13T13:42:46  <wumpus> MarcoFalke: yes, good point, the gitian descriptor needs to be bumped there to avoid overlapping caches
2442018-08-13T13:42:57  <wumpus> TheHoliestRoger: lol :)
2452018-08-13T13:43:09  <TheHoliestRoger> what you lolling at me for? :)
2462018-08-13T13:43:30  <TheHoliestRoger> the thank you was serious
2472018-08-13T13:43:32  <MarcoFalke> Its been like 6 minutes after the branch
2482018-08-13T13:43:39  <TheHoliestRoger> was waiting to merge 0.17 into my altcoin
2492018-08-13T13:43:57  <MarcoFalke> TheHoliestRoger: There is altcoin-dev on irc
2502018-08-13T13:44:00  <MarcoFalke> not here please
2512018-08-13T13:44:04  <TheHoliestRoger> eh?
2522018-08-13T13:44:14  <MarcoFalke> This is bitcoin-core-dev
2532018-08-13T13:44:27  <TheHoliestRoger> I know, that's why I just thanked you guys for your hard work...
2542018-08-13T13:45:29  *** Victorsueca has quit IRC
2552018-08-13T13:45:30  <fanquake> I opened a PR for the descriptors
2562018-08-13T13:45:44  <fanquake> Can do the 0.17 manpages as well
2572018-08-13T13:46:09  <TheHoliestRoger> MarcoFalke: are we not supposed to talk in here or somethnig?
2582018-08-13T13:46:39  *** Victorsueca has joined #bitcoin-core-dev
2592018-08-13T13:49:56  *** drexl has joined #bitcoin-core-dev
2602018-08-13T13:57:11  *** vexbuy has joined #bitcoin-core-dev
2612018-08-13T14:00:11  *** timothy has quit IRC
2622018-08-13T14:05:08  *** vexbuy has quit IRC
2632018-08-13T14:22:05  *** SopaXorzTaker has quit IRC
2642018-08-13T14:22:38  *** rafalcpp has quit IRC
2652018-08-13T14:23:27  *** rafalcpp has joined #bitcoin-core-dev
2662018-08-13T14:26:12  *** vexbuy has joined #bitcoin-core-dev
2672018-08-13T14:26:15  *** intcat has quit IRC
2682018-08-13T14:26:40  *** D00M has joined #bitcoin-core-dev
2692018-08-13T14:29:01  *** intcat has joined #bitcoin-core-dev
2702018-08-13T14:29:56  *** fanquake has quit IRC
2712018-08-13T14:30:50  *** rafalcpp has quit IRC
2722018-08-13T14:31:32  *** rafalcpp has joined #bitcoin-core-dev
2732018-08-13T14:38:01  *** rafalcpp has quit IRC
2742018-08-13T14:38:46  *** rafalcpp has joined #bitcoin-core-dev
2752018-08-13T14:44:41  *** michaelsdunn1 has joined #bitcoin-core-dev
2762018-08-13T14:50:40  <jonasschnelli> Can I safely assume that the first socket read is always > 32 bytes (connecting a new peer)?
2772018-08-13T14:51:07  <jonasschnelli> Or should the encryption handshake be splittable in socket reads (makes implementation a bit more complex)?
2782018-08-13T14:53:14  <sipa> you cannot make such an assumptiom
2792018-08-13T14:53:19  *** sipa sets mode: -o sipa
2802018-08-13T14:54:25  <wumpus> you always need to handle smaller reads
2812018-08-13T14:55:11  <wumpus> it's possible worst-cast for it to get fragmented into 32 1-byte reads
2822018-08-13T14:55:19  <sipa> also, is that really a problem? there is already code for reading data into buffers; you shouldn't need to rewrite it
2832018-08-13T14:55:26  <wumpus> yes
2842018-08-13T15:02:33  <jonasschnelli> Yes. Your right... but since the message can also be a standard-version message, the in-code handling is quite ugly
2852018-08-13T15:02:50  <jonasschnelli> But yeah... shouldn't be a problem
2862018-08-13T15:03:34  <jonasschnelli> I guess I'm getting lazy and should take a rest. :)
2872018-08-13T15:08:42  *** Dizzle has joined #bitcoin-core-dev
2882018-08-13T15:12:15  *** SopaXorzTaker has joined #bitcoin-core-dev
2892018-08-13T15:16:01  *** vexbuy has quit IRC
2902018-08-13T15:16:39  *** vexbuy has joined #bitcoin-core-dev
2912018-08-13T15:24:35  <wumpus> we can all use a rest :)
2922018-08-13T15:25:38  *** viaj3ro has joined #bitcoin-core-dev
2932018-08-13T15:28:34  <sipa> ooh, a branch
2942018-08-13T15:28:39  *** SopaXorzTaker has quit IRC
2952018-08-13T15:31:22  <instagibbs> !!!
2962018-08-13T15:31:22  <lightningbot> instagibbs: Error: "!" is not a valid command.
2972018-08-13T15:31:22  *** Victorsueca has quit IRC
2982018-08-13T15:31:22  <gribble> Error: "!!" is not a valid command.
2992018-08-13T15:32:38  *** Victorsueca has joined #bitcoin-core-dev
3002018-08-13T15:33:35  *** DougieBot5000 has quit IRC
3012018-08-13T15:34:03  *** wxss has quit IRC
3022018-08-13T15:36:04  *** DougieBot5000 has joined #bitcoin-core-dev
3032018-08-13T15:42:46  *** D00M has quit IRC
3042018-08-13T15:45:02  *** d9b4bef9 has quit IRC
3052018-08-13T15:45:20  *** vexbuy_ has joined #bitcoin-core-dev
3062018-08-13T15:46:08  *** d9b4bef9 has joined #bitcoin-core-dev
3072018-08-13T15:49:21  *** vexbuy has quit IRC
3082018-08-13T15:50:33  <sipa> MarcoFalke, gmaxwell: about the problem of having interdependent dandelion transactions... i think there is no issue
3092018-08-13T15:50:46  <sipa> thanks to orphan handling
3102018-08-13T15:51:33  <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
3112018-08-13T15:52:12  <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)
3122018-08-13T15:52:25  <sipa> if the parent fluffs first, no change in behaviour
3132018-08-13T15:54:48  <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...
3142018-08-13T15:55:32  <sipa> well in this case there would just not be someone to send the inv to
3152018-08-13T15:55:33  <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.
3162018-08-13T15:57:22  <sipa> this approach will cause parent and child to be effectively fluffed at the same time, in case the parent would be longer
3172018-08-13T15:58:10  <gmaxwell> yes, but perhaps we should do that explicitly rather than depending on the rather lossy orphan handling.
3182018-08-13T15:58:23  <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
3192018-08-13T15:58:49  <sipa> ok, that's fair
3202018-08-13T15:59:10  <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.
3212018-08-13T15:59:31  <sipa> right
3222018-08-13T15:59:42  <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.
3232018-08-13T15:59:52  *** cornfeedhobo has quit IRC
3242018-08-13T16:00:29  <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
3252018-08-13T16:02:05  <gmaxwell> I think thats right and fine.
3262018-08-13T16:02:29  <gmaxwell> basically for every txn compute an exp time and take the max of its own and its maximum parent.
3272018-08-13T16:03:28  <gmaxwell> and make the expire time processing obey the order by using depth as a tiebreaker or similar.
3282018-08-13T16:04:21  *** Krellan has quit IRC
3292018-08-13T16:07:33  *** bytting has joined #bitcoin-core-dev
3302018-08-13T16:08:52  *** cornfeedhobo has joined #bitcoin-core-dev
3312018-08-13T16:21:27  *** justanotheruser has quit IRC
3322018-08-13T16:25:35  *** DougieBot5000 has quit IRC
3332018-08-13T16:27:37  *** DougieBot5000 has joined #bitcoin-core-dev
3342018-08-13T16:33:24  *** Krellan has joined #bitcoin-core-dev
3352018-08-13T16:33:27  *** Victorsueca has quit IRC
3362018-08-13T16:34:38  *** Victorsueca has joined #bitcoin-core-dev
3372018-08-13T16:38:35  *** jhfrontz has quit IRC
3382018-08-13T16:42:01  *** drexl has quit IRC
3392018-08-13T16:42:20  *** drexl has joined #bitcoin-core-dev
3402018-08-13T17:07:24  <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
3412018-08-13T17:07:52  <sipa> sdaftuar: that wasn't what the discussion was about, though
3422018-08-13T17:07:56  <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
3432018-08-13T17:08:53  <sdaftuar> sipa: oh maybe i misunderstood your earlier discussion
3442018-08-13T17:09:56  <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)
3452018-08-13T17:10:18  <sipa> *before that
3462018-08-13T17:10:23  <sdaftuar> sorry. yes, i undetstood that's what you were just talking about
3472018-08-13T17:10:37  <sdaftuar> i thought greg said earlier that it was a non-starter to delay relay of a child transaction until the parent fluffed
3482018-08-13T17:10:59  <sdaftuar> (i think in the normal dandelion case)
3492018-08-13T17:12:53  <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"
3502018-08-13T17:13:12  <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
3512018-08-13T17:13:20  <sdaftuar> and hence won't be spendable
3522018-08-13T17:13:43  <sipa> ugh, yes - that's an extra complication
3532018-08-13T17:13:44  <sdaftuar> that something can be looking into our own wallet's set of stem transactions, for instance
3542018-08-13T17:13:59  *** aggieben has joined #bitcoin-core-dev
3552018-08-13T17:14:01  <sdaftuar> but we can still slow down relay of children without totally breaking our wallet
3562018-08-13T17:14:12  <sdaftuar> (if we need to)
3572018-08-13T17:16:47  <sdaftuar> my first thought is that t
3582018-08-13T17:16:50  <sdaftuar> oops
3592018-08-13T17:18:38  *** bytting has quit IRC
3602018-08-13T17:18:47  <instagibbs> also comes into consideration with checking balance, yes?
3612018-08-13T17:18:56  <instagibbs> (with current code)
3622018-08-13T17:28:35  *** bytting has joined #bitcoin-core-dev
3632018-08-13T17:39:20  *** rafalcpp_ has joined #bitcoin-core-dev
3642018-08-13T17:39:26  *** vexbuy_ has quit IRC
3652018-08-13T17:39:36  *** Randolf has quit IRC
3662018-08-13T17:39:36  *** no_input_found has quit IRC
3672018-08-13T17:39:36  *** drexl has quit IRC
3682018-08-13T17:39:36  *** rafalcpp has quit IRC
3692018-08-13T17:39:56  *** Randolf has joined #bitcoin-core-dev
3702018-08-13T17:40:04  *** Victorsueca has quit IRC
3712018-08-13T17:40:18  *** no_input_found has joined #bitcoin-core-dev
3722018-08-13T17:41:25  *** Victorsueca has joined #bitcoin-core-dev
3732018-08-13T17:45:51  *** vexbuy has joined #bitcoin-core-dev
3742018-08-13T17:50:11  *** str4d has joined #bitcoin-core-dev
3752018-08-13T18:00:18  *** DougieBot5000 has quit IRC
3762018-08-13T18:02:26  *** Krellan has quit IRC
3772018-08-13T18:02:46  *** DougieBot5000 has joined #bitcoin-core-dev
3782018-08-13T18:06:45  <gmaxwell> sdaftuar: I think we can slow the relay down, we just can't _drop_ the transaction.
3792018-08-13T18:07:07  <gmaxwell> which is what I thought was being previously proposed.
3802018-08-13T18:07:09  <sdaftuar> ah okay
3812018-08-13T18:07:40  <gmaxwell> though slowing it might also turn out to be not great, I don't think it's a non-starter.
3822018-08-13T18:07:59  <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?
3832018-08-13T18:08:22  <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
3842018-08-13T18:08:31  <sdaftuar> but now i am coming up with new dos attacks that don't even rely on that
3852018-08-13T18:08:57  <sdaftuar> say you have 1 mempool trnasaction with thousands of outputs
3862018-08-13T18:09:10  <sdaftuar> i send you 1000 child transactions, each spending a different output
3872018-08-13T18:09:16  <sdaftuar> only the first 25 or so will be accepted
3882018-08-13T18:09:21  <sdaftuar> due to chain limits
3892018-08-13T18:09:57  <sdaftuar> but how does a dandelion relayer avoid relaying all?  i think you would need a stempool
3902018-08-13T18:11:51  <sdaftuar> but then a global stempool seems like it might introduce information leakage about routes
3912018-08-13T18:12:11  <sdaftuar> while per-peer stempools seem like unacceptably awful overhead
3922018-08-13T18:18:46  <gmaxwell> well a "per peer stempool" is really needs to be per output peer, I believe. Also the transactions could be shared between them.
3932018-08-13T18:25:34  <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
3942018-08-13T18:44:17  *** csknk has quit IRC
3952018-08-13T18:44:45  *** csknk has joined #bitcoin-core-dev
3962018-08-13T18:46:10  *** justanotheruser has joined #bitcoin-core-dev
3972018-08-13T18:46:23  <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.
3982018-08-13T18:47:37  <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?
3992018-08-13T18:54:19  <gmaxwell> Hm? well dandelion as was proposed on the list has a stempool, so you'll never stem relay the same transaction twice.
4002018-08-13T18:54:56  <sdaftuar> yeah that too.  i think marco's PR doesn't have one (yet?)
4012018-08-13T18:55:24  <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)*
4022018-08-13T18:56:53  <gmaxwell> why is whitelisted making a difference in your example?
4032018-08-13T18:57:01  <sipa> i think we should ignore the whitelist status for dandelion
4042018-08-13T18:57:11  <sipa> its scope shouldn't be extended further
4052018-08-13T18:58:16  <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.
4062018-08-13T18:58:29  *** eslider has quit IRC
4072018-08-13T18:58:41  <gmaxwell> it's really a weird and specialized thing.
4082018-08-13T18:59:22  <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
4092018-08-13T19:00:10  <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.
4102018-08-13T19:01:17  <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.
4112018-08-13T19:07:12  *** vexbuy has quit IRC
4122018-08-13T19:08:45  *** vexbuy has joined #bitcoin-core-dev
4132018-08-13T19:14:10  *** michaelsdunn1 has quit IRC
4142018-08-13T19:15:05  *** JackH has joined #bitcoin-core-dev
4152018-08-13T19:16:11  *** michaelsdunn1 has joined #bitcoin-core-dev
4162018-08-13T19:16:44  *** owowo has quit IRC
4172018-08-13T19:21:00  *** cfields_ has joined #bitcoin-core-dev
4182018-08-13T19:21:48  *** owowo has joined #bitcoin-core-dev
4192018-08-13T19:23:46  *** thaumavorio_ has joined #bitcoin-core-dev
4202018-08-13T19:23:57  *** intcat has quit IRC
4212018-08-13T19:25:18  *** nmnkgl has quit IRC
4222018-08-13T19:25:18  *** harding has quit IRC
4232018-08-13T19:25:18  *** stepa[m] has quit IRC
4242018-08-13T19:25:19  *** herzmeister[m] has quit IRC
4252018-08-13T19:25:19  *** mappum__ has quit IRC
4262018-08-13T19:25:19  *** rodarmor has quit IRC
4272018-08-13T19:25:19  *** Nebraskka has quit IRC
4282018-08-13T19:25:19  *** robby938_ has quit IRC
4292018-08-13T19:25:19  *** jonasschnelli has quit IRC
4302018-08-13T19:25:19  *** gaf_ has quit IRC
4312018-08-13T19:25:19  *** thaumavorio has quit IRC
4322018-08-13T19:25:19  *** cfields has quit IRC
4332018-08-13T19:25:19  *** qinfengling has quit IRC
4342018-08-13T19:26:04  *** plankers has joined #bitcoin-core-dev
4352018-08-13T19:29:40  *** intcat has joined #bitcoin-core-dev
4362018-08-13T19:31:18  *** ghost43 has quit IRC
4372018-08-13T19:32:02  *** qinfengling has joined #bitcoin-core-dev
4382018-08-13T19:32:05  *** ghost43 has joined #bitcoin-core-dev
4392018-08-13T19:38:21  *** csknk has quit IRC
4402018-08-13T19:38:54  *** dqx has quit IRC
4412018-08-13T19:59:35  *** Pasha has quit IRC
4422018-08-13T20:06:38  *** Pasha has joined #bitcoin-core-dev
4432018-08-13T20:22:16  *** Rootsudo has joined #bitcoin-core-dev
4442018-08-13T20:24:05  *** Dizzle has quit IRC
4452018-08-13T20:27:52  *** Dizzle has joined #bitcoin-core-dev
4462018-08-13T20:32:37  *** jonasschnelli_ has joined #bitcoin-core-dev
4472018-08-13T20:35:13  *** DougieBot5000 has quit IRC
4482018-08-13T20:35:18  *** luke-jr has quit IRC
4492018-08-13T20:35:41  *** luke-jr has joined #bitcoin-core-dev
4502018-08-13T20:37:01  *** DougieBot5000 has joined #bitcoin-core-dev
4512018-08-13T20:38:18  *** nmnkgl has joined #bitcoin-core-dev
4522018-08-13T20:42:30  *** Randolf has quit IRC
4532018-08-13T20:47:21  *** Dizzle has quit IRC
4542018-08-13T20:48:14  *** Dizzle has joined #bitcoin-core-dev
4552018-08-13T20:52:49  *** promag has joined #bitcoin-core-dev
4562018-08-13T21:28:21  *** jeremyrubin has joined #bitcoin-core-dev
4572018-08-13T21:29:24  <jeremyrubin> Was discussing with wumpus the viability of timing attacks on PR 13666, he suggested I ask here.
4582018-08-13T21:29:59  <jeremyrubin> Essentially additional bits leak out if the signature takes longer to generate.
4592018-08-13T21:30:37  <sipa> jeremyrubin: you're right, but i believe it doesn't matter
4602018-08-13T21:30:56  <sipa> how much does it help you to know (e.g.) that something took 10 tries to generate?
4612018-08-13T21:30:58  <jeremyrubin> Was going to paste in your response
4622018-08-13T21:31:02  <jeremyrubin> 1 sec...
4632018-08-13T21:31:04  <sipa> ah
4642018-08-13T21:31:06  <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."
4652018-08-13T21:31:27  <sipa> ah, seems i commented on this before :)
4662018-08-13T21:32:21  <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
4672018-08-13T21:32:42  *** Chris_Stewart_5 has quit IRC
4682018-08-13T21:33:35  <jeremyrubin> But as only an armchair cryptographer I don't feel comfortable asserting that this information is entirely useless
4692018-08-13T21:34:44  <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
4702018-08-13T21:38:41  <jeremyrubin> Correct.
4712018-08-13T21:46:10  *** promag has quit IRC
4722018-08-13T21:49:15  <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.
4732018-08-13T21:49:56  <sipa> right, but that test requires an EC multiplication
4742018-08-13T21:50:26  <jeremyrubin> So here's my question
4752018-08-13T21:50:44  <jeremyrubin> Let's say I have another test I've observed to be 2 signatures
4762018-08-13T21:51:13  <jeremyrubin> that is k1 and k2 such that serializesize(k{1,2}XG) = 71
4772018-08-13T21:51:21  <jeremyrubin> err
4782018-08-13T21:51:37  <jeremyrubin> ignore 14:51
4792018-08-13T21:51:59  <jeremyrubin> Another signature I've observed to be 2 signing periods
4802018-08-13T21:52:10  <jeremyrubin> that bit of information should be independent, right?
4812018-08-13T21:52:20  <jeremyrubin> It still requires an ec mul to test directly
4822018-08-13T21:52:36  <sipa> right
4832018-08-13T21:53:00  <sipa> i believe the best this can do is reduce the keyspace by N by doing N EC multiplications, with different messages
4842018-08-13T21:53:21  <jeremyrubin> but is there any correlation such that if I know sersize(k1 x G) = 71 and sersize(k2 x G) =71
4852018-08-13T21:53:36  <sipa> no, they're independent outputs of a hash function with different inputs
4862018-08-13T21:53:39  <jeremyrubin> it would allow me to more efficiently test (k1 + k2) x G = 71
4872018-08-13T21:53:43  <sipa> if there is such a correlation, sha256 is broken
4882018-08-13T21:53:56  <jeremyrubin> I guess I'm asking about ec addition
4892018-08-13T21:54:06  <jeremyrubin> like if k1 G is sersize 71
4902018-08-13T21:54:13  <jeremyrubin> and k2 G is sersize 71
4912018-08-13T21:54:24  <jeremyrubin> do we know anything about k1+k2?
4922018-08-13T21:54:31  <sipa> ah; i believe these is no such test, but no proof that there isn't
4932018-08-13T21:54:33  <jeremyrubin> (nothing to do with sha256)
4942018-08-13T21:54:42  <jeremyrubin> If such a test did exist
4952018-08-13T21:54:51  <jeremyrubin> Then you could use this timing attack
4962018-08-13T21:55:14  <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
4972018-08-13T21:55:29  <sipa> which is far slower than a direct 2^128 EC DLP attack
4982018-08-13T21:56:14  <sipa> but this is a good point
4992018-08-13T21:56:33  <jeremyrubin> Ah also
5002018-08-13T21:56:48  <jeremyrubin> I have the bit that k1_0 is 72 sersize
5012018-08-13T21:56:57  <jeremyrubin> and k2_0 is 72 sersize
5022018-08-13T21:57:12  <jeremyrubin> I think that's the bit that gets leaked that's more interesting
5032018-08-13T21:57:25  <sipa> perhaps - but it also requires hashes to discover
5042018-08-13T21:57:26  *** Krellan has joined #bitcoin-core-dev
5052018-08-13T21:57:29  <jeremyrubin> Yeah
5062018-08-13T21:57:48  *** Victorsueca has quit IRC
5072018-08-13T21:59:09  *** Victorsueca has joined #bitcoin-core-dev
5082018-08-13T21:59:45  <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
5092018-08-13T22:00:27  <sipa> yes, a writeup of the concerns and reasoning would be useful
5102018-08-13T22:00:56  <jeremyrubin> I'm interested to work on it, but it's a bit beyond my depth as a cryptographer
5112018-08-13T22:08:19  <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.
5122018-08-13T22:09:27  <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)
5132018-08-13T22:10:14  <sipa> that too results in a bias
5142018-08-13T22:10:31  <jeremyrubin> What's the bias there?
5152018-08-13T22:10:32  <sipa> (an equally harmless one, imho, though)
5162018-08-13T22:11:14  <sipa> lower probability for R values that are the outcome of key/msg that have higher than average number of low-R results
5172018-08-13T22:11:19  <sipa> (in their set of 256)
5182018-08-13T22:11:54  <jeremyrubin> How is this leaked? we reveal 1 at random out of the low-R set?
5192018-08-13T22:12:15  <jeremyrubin> Ah can't be random, right
5202018-08-13T22:12:18  <sipa> yes, but it's biased
5212018-08-13T22:12:25  <sipa> again, i don't thin this would be a concern
5222018-08-13T22:12:40  <jeremyrubin> so would have to be with some deterministic sort, pick 1
5232018-08-13T22:12:42  <sipa> but if leaks of any kind are a concern, this is one too
5242018-08-13T22:12:48  <sipa> nope; still biased
5252018-08-13T22:13:07  <jeremyrubin> (yep, just making the correction that made my algo non-det)
5262018-08-13T22:13:19  <jeremyrubin> Trying to understand the bias
5272018-08-13T22:13:30  <sipa> a correct solution would be to introduce a small amount of true randomness in the hash :)
5282018-08-13T22:13:39  <sipa> as that's unobservable to an attacker
5292018-08-13T22:14:05  <jeremyrubin> then no longer deterministic ;)
5302018-08-13T22:14:21  <sipa> precisely.
5312018-08-13T22:15:01  <jeremyrubin> I still don't quite get the bias being leaked.... it's just the original 1 bit of low-R/high-R?
5322018-08-13T22:15:13  <sipa> but some R values have higher probability than others
5332018-08-13T22:15:25  <jeremyrubin> Interesting... didn't know that
5342018-08-13T22:15:31  <jeremyrubin> I thought it's supposed to be uniform
5352018-08-13T22:15:46  <sipa> the message is public
5362018-08-13T22:15:50  <sipa> so we assume m is fixed
5372018-08-13T22:16:29  <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)
5382018-08-13T22:16:33  <sipa> agree with me so far?
5392018-08-13T22:16:56  <jeremyrubin> yes
5402018-08-13T22:17:14  <sipa> then map those 256 hash outputs to points, and look at their lowrness (i love that word)
5412018-08-13T22:17:28  <jeremyrubin> haha, yep
5422018-08-13T22:17:54  <sipa> and then pick randomly one of the lowr ones (which will approximately be 128, but could be more or less)
5432018-08-13T22:18:34  <jeremyrubin> * deterministically
5442018-08-13T22:18:39  <sipa> oh, deterministically!
5452018-08-13T22:18:43  <sipa> then it's even easier
5462018-08-13T22:19:08  <sipa> your entire construct is a deterministic function from private key to point
5472018-08-13T22:19:20  <sipa> which you can test for by iterating
5482018-08-13T22:19:20  <jeremyrubin> No? The message is included.
5492018-08-13T22:19:35  <sipa> the message is known to the attack, which we can treat as part of the definition of the hash function
5502018-08-13T22:19:40  <jeremyrubin> fair
5512018-08-13T22:19:44  <sipa> *attacker
5522018-08-13T22:20:10  <jeremyrubin> So how is a bit leaked?
5532018-08-13T22:20:17  <jeremyrubin> (or a < bit)
5542018-08-13T22:20:25  <sipa> the entire private key is leaked :)
5552018-08-13T22:20:32  <sipa> information theoretically
5562018-08-13T22:20:54  *** michaelsdunn1 has quit IRC
5572018-08-13T22:21:06  <jeremyrubin> really? Now I'm lost..
5582018-08-13T22:21:12  <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.
5592018-08-13T22:21:20  <gmaxwell> (or just publishing the pubkey leaks the key)
5602018-08-13T22:21:48  <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
5612018-08-13T22:21:55  <sipa> jeremyrubin: that leaks the entire private key :)
5622018-08-13T22:22:18  <sipa> (this is a problem that every deterministic algorithm has, and it's not interesting because we don't care about information theoretical security)
5632018-08-13T22:22:18  <gmaxwell> also, as an asside your conjectural 'weakness' goes away if we provide use the extra random input.
5642018-08-13T22:22:45  * jeremyrubin sighs
5652018-08-13T22:22:51  <gmaxwell> Which I suppose we should just do regardless, unless configured otherwise.
5662018-08-13T22:22:55  <sipa> if you care about _computational_ security, a bias only matters if it lets you meaningully speed up the attack
5672018-08-13T22:22:55  <jeremyrubin> I'm just talking about the timing attack
5682018-08-13T22:23:00  <sipa> so am i
5692018-08-13T22:23:22  <gmaxwell> jeremyrubin: also RFC6979 _inherently_ has this kind of timing attack because of the restriction into the scalar range.
5702018-08-13T22:23:39  <jeremyrubin> Yes, the above potential attack about correlation in serializable size under addition
5712018-08-13T22:23:48  <gmaxwell> If the HMAC_DRBG result is larger than N it tries again.
5722018-08-13T22:23:58  <jeremyrubin> Interesting.
5732018-08-13T22:24:35  <sipa> jeremyrubin: sorry for bringing up information theoretical security; i just want to point out that "leaking a bit" inherently isn't a proble
5742018-08-13T22:24:47  <sipa> the problem is leaking information that leads to a faster attack
5752018-08-13T22:25:07  <sipa> because every deterministic algorithm leaks *all* the bits already, but not in a usable way
5762018-08-13T22:26:12  <jeremyrubin> Well, is secp256k1 bijective ;)
5772018-08-13T22:26:35  *** Guyver2 has quit IRC
5782018-08-13T22:27:13  <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.
5792018-08-13T22:27:28  <gmaxwell> If your attacker has unbounded computing time, however, he could compute it both ways.
5802018-08-13T22:27:43  <gmaxwell> Which is why it has only computational security.
5812018-08-13T22:28:16  <sipa> yes, informational theoretically ECDSA is trivial to break overall
5822018-08-13T22:28:28  <sipa> again my point: leaking a bit isn't what matters
5832018-08-13T22:31:28  *** Rootsudo has quit IRC
5842018-08-13T22:31:34  <jeremyrubin> be back in a... bit
5852018-08-13T22:36:27  *** promag has joined #bitcoin-core-dev
5862018-08-13T22:36:44  <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.
5872018-08-13T22:37:47  <sipa> right; the legacy signer already leaks the 'bit' of information whether or not the first was low R or not
5882018-08-13T22:38:10  <sipa> the only thing added is that it's the total number of attempts, and not just whether it was 0 or nonzero
5892018-08-13T22:38:17  <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)
5902018-08-13T22:38:18  <sipa> (possibly, to a timing attacker)
5912018-08-13T22:38:42  <gmaxwell> e.g. it's isomorpic to looking at R and counting how many leading 0s it has.
5922018-08-13T22:38:50  <sipa> to a non-timing attacker the new algorithm actually leaks less
5932018-08-13T22:42:42  *** Krellan_ has joined #bitcoin-core-dev
5942018-08-13T22:44:17  *** Krellan has quit IRC
5952018-08-13T22:46:26  *** jb55 has quit IRC
5962018-08-13T22:51:15  *** itaseski has quit IRC
5972018-08-13T22:52:05  *** str4d has quit IRC
5982018-08-13T22:58:40  *** pluit has quit IRC
5992018-08-13T23:08:23  *** promag has quit IRC
6002018-08-13T23:33:04  *** bytting has quit IRC
6012018-08-13T23:35:35  *** justanotheruser has quit IRC
6022018-08-13T23:41:27  *** promag has joined #bitcoin-core-dev
6032018-08-13T23:51:00  *** vexbuy has quit IRC
6042018-08-13T23:52:35  *** Dizzle has quit IRC
6052018-08-13T23:52:46  *** Victorsueca has quit IRC
6062018-08-13T23:53:55  *** Victorsueca has joined #bitcoin-core-dev