1 2018-08-13T00:04:27  *** bytting has quit IRC
  2 2018-08-13T00:43:02  *** d9b4bef9 has quit IRC
  3 2018-08-13T00:44:09  *** d9b4bef9 has joined #bitcoin-core-dev
  4 2018-08-13T01:01:54  *** promag has quit IRC
  5 2018-08-13T01:21:27  *** Rootsudo has joined #bitcoin-core-dev
  6 2018-08-13T01:36:25  *** phwalkr has joined #bitcoin-core-dev
  7 2018-08-13T01:46:05  *** Rootsudo has quit IRC
  8 2018-08-13T01:50:04  *** Krellan has quit IRC
  9 2018-08-13T01:59:08  *** ken2812221 has joined #bitcoin-core-dev
 10 2018-08-13T02:13:35  *** Aaronvan_ has quit IRC
 11 2018-08-13T02:13:49  *** bitcoinvolumetra has joined #bitcoin-core-dev
 12 2018-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.
 13 2018-08-13T02:18:04  <sipa> bitcoinvolumetra: go away
 14 2018-08-13T02:18:39  *** ChanServ sets mode: +o sipa
 15 2018-08-13T02:23:54  *** goatpig has quit IRC
 16 2018-08-13T02:24:18  *** AaronvanW has joined #bitcoin-core-dev
 17 2018-08-13T02:28:27  *** AaronvanW has quit IRC
 18 2018-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
 19 2018-08-13T02:57:33  *** Rootsudo has joined #bitcoin-core-dev
 20 2018-08-13T03:11:54  *** bitcoinvolumetra has quit IRC
 21 2018-08-13T03:13:44  <midnightmagic> he ain't got no time for your logic
 22 2018-08-13T03:15:18  <gmaxwell> Full Billionare mode.
 23 2018-08-13T03:17:24  <sipa> *double* billionaire mode
 24 2018-08-13T03:24:54  <luke-jr> XD
 25 2018-08-13T03:25:06  *** AaronvanW has joined #bitcoin-core-dev
 26 2018-08-13T03:25:12  <luke-jr> sipa: maybe it is at such a large discount that it isn't $2B? :P
 27 2018-08-13T03:25:21  * midnightmagic makes head-exploding motions with hands but nothing happens
 28 2018-08-13T03:26:56  *** Krellan has joined #bitcoin-core-dev
 29 2018-08-13T03:30:33  *** AaronvanW has quit IRC
 30 2018-08-13T03:43:10  *** zivl has quit IRC
 31 2018-08-13T03:43:59  *** zivl has joined #bitcoin-core-dev
 32 2018-08-13T03:53:01  *** d9b4bef9 has quit IRC
 33 2018-08-13T03:54:14  *** d9b4bef9 has joined #bitcoin-core-dev
 34 2018-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
 35 2018-08-13T03:57:01  <gmaxwell> spys.. they'll probably stop doing that once 0.17 is widely deployed.
 36 2018-08-13T03:57:16  <gmaxwell> since it defeats what they're trying to accomplish.
 37 2018-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)
 38 2018-08-13T03:59:22  <ossifrage> One has 6 connections, whois says it belongs to chinamobile
 39 2018-08-13T03:59:51  <ossifrage> I wonder if that is actually legit traffic from heavily NATed users?
 40 2018-08-13T04:00:14  <gmaxwell> could be, in some cases.. reasons like that are why we don't outright limit.
 41 2018-08-13T04:08:34  *** Rootsudo has quit IRC
 42 2018-08-13T05:27:02  *** AaronvanW has joined #bitcoin-core-dev
 43 2018-08-13T05:27:15  *** plankers has quit IRC
 44 2018-08-13T05:31:21  *** AaronvanW has quit IRC
 45 2018-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
 46 2018-08-13T05:49:51  <wumpus> two of them, okay, but six?
 47 2018-08-13T05:58:59  <wumpus> especially if they connected aruond the same time, too, and have the same agent string, it's clear
 48 2018-08-13T06:13:28  <wumpus> did I mention I miss the github merge bot here already
 49 2018-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
 50 2018-08-13T06:28:13  <wumpus> luke-jr: that's a fair point, so indeed, I don't see it as impossible just unlikely
 51 2018-08-13T06:34:51  *** phwalkr has quit IRC
 52 2018-08-13T06:34:53  *** vexbuy has joined #bitcoin-core-dev
 53 2018-08-13T06:36:21  *** phwalkr has joined #bitcoin-core-dev
 54 2018-08-13T06:42:40  *** Victorsueca has quit IRC
 55 2018-08-13T06:43:54  *** Victorsueca has joined #bitcoin-core-dev
 56 2018-08-13T06:44:05  *** Emcy_ has quit IRC
 57 2018-08-13T06:53:32  <gmaxwell> sipa: skip RW locks and go straight to URCU https://lwn.net/Articles/573424/  ? :P
 58 2018-08-13T07:01:27  *** vexbuy has quit IRC
 59 2018-08-13T07:07:26  *** timothy has joined #bitcoin-core-dev
 60 2018-08-13T07:18:11  *** Emcy has joined #bitcoin-core-dev
 61 2018-08-13T07:19:32  *** IGHOR has quit IRC
 62 2018-08-13T07:27:47  *** AaronvanW has joined #bitcoin-core-dev
 63 2018-08-13T07:28:48  *** phwalkr has joined #bitcoin-core-dev
 64 2018-08-13T07:32:55  *** AaronvanW has quit IRC
 65 2018-08-13T07:33:21  *** phwalkr has quit IRC
 66 2018-08-13T07:39:59  *** SopaXorzTaker has joined #bitcoin-core-dev
 67 2018-08-13T07:40:43  *** jb55 has quit IRC
 68 2018-08-13T07:44:24  *** jb55 has joined #bitcoin-core-dev
 69 2018-08-13T07:55:02  *** d9b4bef9 has quit IRC
 70 2018-08-13T07:56:09  *** d9b4bef9 has joined #bitcoin-core-dev
 71 2018-08-13T08:02:15  *** IGHOR has joined #bitcoin-core-dev
 72 2018-08-13T08:07:16  *** csknk has joined #bitcoin-core-dev
 73 2018-08-13T08:09:37  *** IGHOR has quit IRC
 74 2018-08-13T08:30:30  *** vexbuy has joined #bitcoin-core-dev
 75 2018-08-13T08:38:32  *** IGHOR has joined #bitcoin-core-dev
 76 2018-08-13T08:38:58  <wumpus> so according to #12624 it's time to split off the 0.17 branch today
 77 2018-08-13T08:38:59  <gribble> https://github.com/bitcoin/bitcoin/issues/12624 | Release schedule for 0.17.0 · Issue #12624 · bitcoin/bitcoin · GitHub
 78 2018-08-13T08:39:21  *** vexbuy_ has joined #bitcoin-core-dev
 79 2018-08-13T08:41:11  <wumpus> let's see how far we get...
 80 2018-08-13T08:42:35  *** vexbuy has quit IRC
 81 2018-08-13T08:44:02  *** vexbuy has joined #bitcoin-core-dev
 82 2018-08-13T08:44:45  *** ken2812221_ has joined #bitcoin-core-dev
 83 2018-08-13T08:47:53  *** vexbuy_ has quit IRC
 84 2018-08-13T08:48:43  *** vexbuy_ has joined #bitcoin-core-dev
 85 2018-08-13T08:52:42  *** vexbuy has quit IRC
 86 2018-08-13T08:53:04  <kallewoof> wumpus: I think I've reviewed all the 0.17 PR's that I feel comfy reviewing
 87 2018-08-13T08:53:12  *** vexbuy has joined #bitcoin-core-dev
 88 2018-08-13T08:54:25  <kallewoof> is there anything else that needs doing besides review?
 89 2018-08-13T08:55:43  <wumpus> we'll probably want to put up the release notes in the wiki
 90 2018-08-13T08:55:49  *** nodweber has quit IRC
 91 2018-08-13T08:55:51  *** vexbuy_ has quit IRC
 92 2018-08-13T08:56:16  <wumpus> so that people can work on the remaining items in #12391
 93 2018-08-13T08:56:17  <gribble> https://github.com/bitcoin/bitcoin/issues/12391 | TODO for release notes 0.17.0 · Issue #12391 · bitcoin/bitcoin · GitHub
 94 2018-08-13T08:56:40  <wumpus> I'm also working on doing a final translations update before the branch-off
 95 2018-08-13T08:57:46  *** vexbuy_ has joined #bitcoin-core-dev
 96 2018-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
 97 2018-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
 98 2018-08-13T08:59:08  <kallewoof> got it. I'll double check if anything was updated and re-review.
 99 2018-08-13T09:00:17  *** vexbuy has quit IRC
100 2018-08-13T09:00:39  <kallewoof> even better is to actually try the code and not just stop at utACKing...
101 2018-08-13T09:02:16  *** vexbuy has joined #bitcoin-core-dev
102 2018-08-13T09:03:30  <wumpus> as for wiki link: https://github.com/bitcoin-core/bitcoin-devwiki/wiki
103 2018-08-13T09:05:58  *** vexbuy_ has quit IRC
104 2018-08-13T09:06:36  *** itaseski has joined #bitcoin-core-dev
105 2018-08-13T09:06:45  *** vexbuy_ has joined #bitcoin-core-dev
106 2018-08-13T09:06:55  <kallewoof> Ohh... no wonder i couldn't find it
107 2018-08-13T09:06:59  <kallewoof> Thanks
108 2018-08-13T09:08:14  *** fanquake has joined #bitcoin-core-dev
109 2018-08-13T09:09:27  *** vexbuy has quit IRC
110 2018-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?
111 2018-08-13T09:11:14  <kallewoof> Huh... https://pastebin.com/cC29k9Sz
112 2018-08-13T09:11:24  *** vexbuy has joined #bitcoin-core-dev
113 2018-08-13T09:12:13  <kallewoof> I tried [ createpsbt "[]" "[{\"$(./bitcoin-cli getnewaddress)\":0.01}]" ], which worked fine. But decodepsbt errors for the result.
114 2018-08-13T09:12:39  * kallewoof should probably read up on how these commands work
115 2018-08-13T09:15:18  *** vexbuy_ has quit IRC
116 2018-08-13T09:15:57  *** vexbuy_ has joined #bitcoin-core-dev
117 2018-08-13T09:17:27  *** plankers has joined #bitcoin-core-dev
118 2018-08-13T09:18:35  *** vexbuy has quit IRC
119 2018-08-13T09:20:32  *** vexbuy has joined #bitcoin-core-dev
120 2018-08-13T09:24:27  *** vexbuy_ has quit IRC
121 2018-08-13T09:25:11  *** vexbuy_ has joined #bitcoin-core-dev
122 2018-08-13T09:25:34  *** AaronvanW has joined #bitcoin-core-dev
123 2018-08-13T09:29:26  *** vexbuy has quit IRC
124 2018-08-13T09:29:44  *** vexbuy__ has joined #bitcoin-core-dev
125 2018-08-13T09:32:27  *** vexbuy_ has quit IRC
126 2018-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
127 2018-08-13T09:34:02  <gribble> https://github.com/bitcoin/bitcoin/issues/13938 | refactoring: Cleanup StartRest() by DesWurstes · Pull Request #13938 · bitcoin/bitcoin · GitHub
128 2018-08-13T09:34:09  *** vexbuy has joined #bitcoin-core-dev
129 2018-08-13T09:34:53  <wumpus> really tired of these twiddle-the-code-a-bit-without-really-doing-anything
130 2018-08-13T09:35:08  <wumpus> agree 13808 is ready
131 2018-08-13T09:35:35  <wumpus> thanks everyone for reviewing that one it was needed !
132 2018-08-13T09:37:50  *** vexbuy__ has quit IRC
133 2018-08-13T09:37:56  <fanquake> Plenty more refactoring type PRs to review heh
134 2018-08-13T09:38:34  *** vexbuy_ has joined #bitcoin-core-dev
135 2018-08-13T09:39:16  <fanquake> 13899 maybe ready, but probably needs at least one tested ACK from someone using GCC
136 2018-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
137 2018-08-13T09:40:48  <wumpus> so I'd say we close that kind
138 2018-08-13T09:41:21  *** vexbuy has quit IRC
139 2018-08-13T09:42:24  <wumpus> redundant declarations meh
140 2018-08-13T09:42:45  <fanquake> wumpus I feel a lot of closed PRs in the near hours
141 2018-08-13T09:43:09  *** vexbuy has joined #bitcoin-core-dev
142 2018-08-13T09:43:26  <wumpus> fanquake: haha if it was only up to me
143 2018-08-13T09:44:00  <wumpus> no, removing redundant declarations is okay, but I don't see it as a focus point for 0.17
144 2018-08-13T09:47:07  *** vexbuy_ has quit IRC
145 2018-08-13T09:47:26  <fanquake> Seems like there is "some" agreement around #13666 ? Still tagged for 0.17.
146 2018-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
147 2018-08-13T09:47:37  *** vexbuy_ has joined #bitcoin-core-dev
148 2018-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.
149 2018-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
150 2018-08-13T09:49:06  <wumpus> fanquake: I'm somewhat reluctant on that one
151 2018-08-13T09:49:32  <wumpus> maybe someone can convince me why it's important to merge that last minute before 0.17
152 2018-08-13T09:50:30  *** vexbuy has quit IRC
153 2018-08-13T09:52:16  *** vexbuy has joined #bitcoin-core-dev
154 2018-08-13T09:53:06  <wumpus> ah the signature size counting issue for feerate was resolved
155 2018-08-13T09:53:32  <wumpus> and it has plenty of utACKs
156 2018-08-13T09:53:43  <wumpus> so I think it should just go in
157 2018-08-13T09:55:16  <wumpus> fanquake: reducing the entropy of the nonce was the biggest concern it seems
158 2018-08-13T09:56:32  <fanquake> wumpus thanks, just merging/running tests etc
159 2018-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
160 2018-08-13T09:56:41  *** vexbuy_ has quit IRC
161 2018-08-13T09:56:54  *** vexbuy_ has joined #bitcoin-core-dev
162 2018-08-13T09:59:38  *** vexbuy_ has quit IRC
163 2018-08-13T10:01:07  *** vexbuy has quit IRC
164 2018-08-13T10:07:48  *** plankers has quit IRC
165 2018-08-13T10:22:03  *** plankers has joined #bitcoin-core-dev
166 2018-08-13T10:31:31  *** Guyver2 has joined #bitcoin-core-dev
167 2018-08-13T10:40:22  *** no_input_found has joined #bitcoin-core-dev
168 2018-08-13T10:55:55  *** vexbuy has joined #bitcoin-core-dev
169 2018-08-13T10:56:13  *** ken2812221_ has quit IRC
170 2018-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)
171 2018-08-13T11:07:43  <MarcoFalke> manpages need to be regenerated anyway
172 2018-08-13T11:07:50  <MarcoFalke> (after the version bump)
173 2018-08-13T11:13:40  <MarcoFalke> lol, why do we have appveryor as ci check?
174 2018-08-13T11:14:37  <fanquake> MarcoFalke appveryor?
175 2018-08-13T11:14:47  <MarcoFalke> https://github.com/bitcoin/bitcoin/pull/13939#ref-commit-ef86f26
176 2018-08-13T11:14:58  <MarcoFalke> Oh well, only on this commit
177 2018-08-13T11:15:29  <MarcoFalke> because it was also pushed to some other remote (with appveyor)
178 2018-08-13T11:16:09  <fanquake> huh ok
179 2018-08-13T11:23:26  <MarcoFalke> Going to merge #13905 as well.
180 2018-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
181 2018-08-13T11:23:34  <MarcoFalke> I think after that we are good to branch off
182 2018-08-13T11:23:53  <MarcoFalke> (and backport any remaining bugfixes)
183 2018-08-13T11:23:58  <MarcoFalke> later on
184 2018-08-13T11:32:26  <wumpus> yay
185 2018-08-13T11:32:50  <MarcoFalke> Oh wait, we should merge the loose release notes file into the master doc
186 2018-08-13T11:33:14  <MarcoFalke> Otherwise they will be sitting  around forever
187 2018-08-13T11:33:38  <wumpus> I've already put the release notes in the wiki, probably want to do that there
188 2018-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
189 2018-08-13T11:37:37  <fanquake> So backport 13917 and 13788 after branch off?
190 2018-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
191 2018-08-13T11:38:13  <wumpus> backporting post-branch is for things we don't know about yet
192 2018-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
193 2018-08-13T11:38:35  <fanquake> One needs a rebase, the -disable-asm changes I'm not sure about.
194 2018-08-13T11:38:55  <MarcoFalke> Yeah, needs a rebase and re-ACK. That might take some days
195 2018-08-13T11:38:59  <wumpus> yes the latter seems to be controversial
196 2018-08-13T11:39:20  <wumpus> ok agreed, probably makes no sense to hold up rc1 for a few days for that
197 2018-08-13T11:39:33  <wumpus> might even postpone it to 0.17.1
198 2018-08-13T11:39:58  <fanquake> Sounds like it's time to branch then
199 2018-08-13T11:40:36  <wumpus> might want to do a hardcoded seed update first
200 2018-08-13T11:40:49  <wumpus> BLOCK_CHAIN_SIZE was recently adapted afaik
201 2018-08-13T11:41:02  <wumpus> the chainparams stats too
202 2018-08-13T11:41:05  <fanquake> Yes, to 220 I think.
203 2018-08-13T11:42:03  <wumpus> last hardcoded seeds update was in januari, so I'm going to do that
204 2018-08-13T11:42:09  <MarcoFalke> sounds good
205 2018-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])
206 2018-08-13T11:47:15  <fanquake> I guess 0.13 has reached its "end of life"
207 2018-08-13T11:47:26  <fanquake> Or did, at the start of the month https://bitcoincore.org/en/lifecycle/
208 2018-08-13T11:48:15  <fanquake> Does that warrant removal?
209 2018-08-13T11:48:19  <wumpus> it did, is that enough reason, or does it need any specific reason to exclude it based on compatiblity?
210 2018-08-13T11:49:02  *** wxss has joined #bitcoin-core-dev
211 2018-08-13T11:49:12  <wumpus> I don't think it matters much, there shouldn't be many 0.13.x nodes around anymore
212 2018-08-13T11:50:04  <fanquake> I guess it's just 0.13.1 + that have segwit support
213 2018-08-13T11:50:34  <wumpus> I'll just remove it
214 2018-08-13T11:55:53  *** vexbuy_ has joined #bitcoin-core-dev
215 2018-08-13T11:57:02  *** d9b4bef9 has quit IRC
216 2018-08-13T11:57:15  *** vexbuy has quit IRC
217 2018-08-13T11:58:08  *** d9b4bef9 has joined #bitcoin-core-dev
218 2018-08-13T12:00:51  <wumpus> #13951
219 2018-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
220 2018-08-13T12:14:32  *** wxss has quit IRC
221 2018-08-13T12:23:00  *** wxss has joined #bitcoin-core-dev
222 2018-08-13T12:34:05  *** plankers has quit IRC
223 2018-08-13T12:46:05  <wumpus> I'll wait for some acks on that
224 2018-08-13T12:55:15  *** goatpig has joined #bitcoin-core-dev
225 2018-08-13T13:17:09  <MarcoFalke> The default for GetDesirableServiceFlags didn't change, so looks correct
226 2018-08-13T13:17:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
227 2018-08-13T13:28:40  <wumpus> so I think it's ready for branch?
228 2018-08-13T13:29:19  <fanquake> It would seem that way
229 2018-08-13T13:29:46  <fanquake> manpages? Or they can be done later on
230 2018-08-13T13:30:25  <wumpus> that needs to be done after upping the versions
231 2018-08-13T13:32:09  <MarcoFalke> lets do it!
232 2018-08-13T13:33:21  <fanquake> on time!
233 2018-08-13T13:35:12  <wumpus> https://github.com/bitcoin/bitcoin/tree/0.17 !
234 2018-08-13T13:35:23  *** vexbuy_ has quit IRC
235 2018-08-13T13:35:36  <wumpus> yes this is fantastic, we didn't have to postpone it this time :)
236 2018-08-13T13:38:58  <wumpus> versions bumped, if you want to do an update-manpages PR go ahead
237 2018-08-13T13:39:11  <wumpus> (need a seperate one for master and 0.17)
238 2018-08-13T13:39:42  <TheHoliestRoger> thank you for your hard work all
239 2018-08-13T13:41:36  <MarcoFalke> no pressing need to bump on master for now
240 2018-08-13T13:41:54  <MarcoFalke> Probably enough to do it twice a year or so
241 2018-08-13T13:42:06  <MarcoFalke> But the gitian-descriptor would need to be bumped on master?
242 2018-08-13T13:42:22  <TheHoliestRoger> you got 3 gitian sigs yet?
243 2018-08-13T13:42:46  <wumpus> MarcoFalke: yes, good point, the gitian descriptor needs to be bumped there to avoid overlapping caches
244 2018-08-13T13:42:57  <wumpus> TheHoliestRoger: lol :)
245 2018-08-13T13:43:09  <TheHoliestRoger> what you lolling at me for? :)
246 2018-08-13T13:43:30  <TheHoliestRoger> the thank you was serious
247 2018-08-13T13:43:32  <MarcoFalke> Its been like 6 minutes after the branch
248 2018-08-13T13:43:39  <TheHoliestRoger> was waiting to merge 0.17 into my altcoin
249 2018-08-13T13:43:57  <MarcoFalke> TheHoliestRoger: There is altcoin-dev on irc
250 2018-08-13T13:44:00  <MarcoFalke> not here please
251 2018-08-13T13:44:04  <TheHoliestRoger> eh?
252 2018-08-13T13:44:14  <MarcoFalke> This is bitcoin-core-dev
253 2018-08-13T13:44:27  <TheHoliestRoger> I know, that's why I just thanked you guys for your hard work...
254 2018-08-13T13:45:29  *** Victorsueca has quit IRC
255 2018-08-13T13:45:30  <fanquake> I opened a PR for the descriptors
256 2018-08-13T13:45:44  <fanquake> Can do the 0.17 manpages as well
257 2018-08-13T13:46:09  <TheHoliestRoger> MarcoFalke: are we not supposed to talk in here or somethnig?
258 2018-08-13T13:46:39  *** Victorsueca has joined #bitcoin-core-dev
259 2018-08-13T13:49:56  *** drexl has joined #bitcoin-core-dev
260 2018-08-13T13:57:11  *** vexbuy has joined #bitcoin-core-dev
261 2018-08-13T14:00:11  *** timothy has quit IRC
262 2018-08-13T14:05:08  *** vexbuy has quit IRC
263 2018-08-13T14:22:05  *** SopaXorzTaker has quit IRC
264 2018-08-13T14:22:38  *** rafalcpp has quit IRC
265 2018-08-13T14:23:27  *** rafalcpp has joined #bitcoin-core-dev
266 2018-08-13T14:26:12  *** vexbuy has joined #bitcoin-core-dev
267 2018-08-13T14:26:15  *** intcat has quit IRC
268 2018-08-13T14:26:40  *** D00M has joined #bitcoin-core-dev
269 2018-08-13T14:29:01  *** intcat has joined #bitcoin-core-dev
270 2018-08-13T14:29:56  *** fanquake has quit IRC
271 2018-08-13T14:30:50  *** rafalcpp has quit IRC
272 2018-08-13T14:31:32  *** rafalcpp has joined #bitcoin-core-dev
273 2018-08-13T14:38:01  *** rafalcpp has quit IRC
274 2018-08-13T14:38:46  *** rafalcpp has joined #bitcoin-core-dev
275 2018-08-13T14:44:41  *** michaelsdunn1 has joined #bitcoin-core-dev
276 2018-08-13T14:50:40  <jonasschnelli> Can I safely assume that the first socket read is always > 32 bytes (connecting a new peer)?
277 2018-08-13T14:51:07  <jonasschnelli> Or should the encryption handshake be splittable in socket reads (makes implementation a bit more complex)?
278 2018-08-13T14:53:14  <sipa> you cannot make such an assumptiom
279 2018-08-13T14:53:19  *** sipa sets mode: -o sipa
280 2018-08-13T14:54:25  <wumpus> you always need to handle smaller reads
281 2018-08-13T14:55:11  <wumpus> it's possible worst-cast for it to get fragmented into 32 1-byte reads
282 2018-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
283 2018-08-13T14:55:26  <wumpus> yes
284 2018-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
285 2018-08-13T15:02:50  <jonasschnelli> But yeah... shouldn't be a problem
286 2018-08-13T15:03:34  <jonasschnelli> I guess I'm getting lazy and should take a rest. :)
287 2018-08-13T15:08:42  *** Dizzle has joined #bitcoin-core-dev
288 2018-08-13T15:12:15  *** SopaXorzTaker has joined #bitcoin-core-dev
289 2018-08-13T15:16:01  *** vexbuy has quit IRC
290 2018-08-13T15:16:39  *** vexbuy has joined #bitcoin-core-dev
291 2018-08-13T15:24:35  <wumpus> we can all use a rest :)
292 2018-08-13T15:25:38  *** viaj3ro has joined #bitcoin-core-dev
293 2018-08-13T15:28:34  <sipa> ooh, a branch
294 2018-08-13T15:28:39  *** SopaXorzTaker has quit IRC
295 2018-08-13T15:31:22  <instagibbs> !!!
296 2018-08-13T15:31:22  <lightningbot> instagibbs: Error: "!" is not a valid command.
297 2018-08-13T15:31:22  *** Victorsueca has quit IRC
298 2018-08-13T15:31:22  <gribble> Error: "!!" is not a valid command.
299 2018-08-13T15:32:38  *** Victorsueca has joined #bitcoin-core-dev
300 2018-08-13T15:33:35  *** DougieBot5000 has quit IRC
301 2018-08-13T15:34:03  *** wxss has quit IRC
302 2018-08-13T15:36:04  *** DougieBot5000 has joined #bitcoin-core-dev
303 2018-08-13T15:42:46  *** D00M has quit IRC
304 2018-08-13T15:45:02  *** d9b4bef9 has quit IRC
305 2018-08-13T15:45:20  *** vexbuy_ has joined #bitcoin-core-dev
306 2018-08-13T15:46:08  *** d9b4bef9 has joined #bitcoin-core-dev
307 2018-08-13T15:49:21  *** vexbuy has quit IRC
308 2018-08-13T15:50:33  <sipa> MarcoFalke, gmaxwell: about the problem of having interdependent dandelion transactions... i think there is no issue
309 2018-08-13T15:50:46  <sipa> thanks to orphan handling
310 2018-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
311 2018-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)
312 2018-08-13T15:52:25  <sipa> if the parent fluffs first, no change in behaviour
313 2018-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...
314 2018-08-13T15:55:32  <sipa> well in this case there would just not be someone to send the inv to
315 2018-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.
316 2018-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
317 2018-08-13T15:58:10  <gmaxwell> yes, but perhaps we should do that explicitly rather than depending on the rather lossy orphan handling.
318 2018-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
319 2018-08-13T15:58:49  <sipa> ok, that's fair
320 2018-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.
321 2018-08-13T15:59:31  <sipa> right
322 2018-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.
323 2018-08-13T15:59:52  *** cornfeedhobo has quit IRC
324 2018-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
325 2018-08-13T16:02:05  <gmaxwell> I think thats right and fine.
326 2018-08-13T16:02:29  <gmaxwell> basically for every txn compute an exp time and take the max of its own and its maximum parent.
327 2018-08-13T16:03:28  <gmaxwell> and make the expire time processing obey the order by using depth as a tiebreaker or similar.
328 2018-08-13T16:04:21  *** Krellan has quit IRC
329 2018-08-13T16:07:33  *** bytting has joined #bitcoin-core-dev
330 2018-08-13T16:08:52  *** cornfeedhobo has joined #bitcoin-core-dev
331 2018-08-13T16:21:27  *** justanotheruser has quit IRC
332 2018-08-13T16:25:35  *** DougieBot5000 has quit IRC
333 2018-08-13T16:27:37  *** DougieBot5000 has joined #bitcoin-core-dev
334 2018-08-13T16:33:24  *** Krellan has joined #bitcoin-core-dev
335 2018-08-13T16:33:27  *** Victorsueca has quit IRC
336 2018-08-13T16:34:38  *** Victorsueca has joined #bitcoin-core-dev
337 2018-08-13T16:38:35  *** jhfrontz has quit IRC
338 2018-08-13T16:42:01  *** drexl has quit IRC
339 2018-08-13T16:42:20  *** drexl has joined #bitcoin-core-dev
340 2018-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
341 2018-08-13T17:07:52  <sipa> sdaftuar: that wasn't what the discussion was about, though
342 2018-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
343 2018-08-13T17:08:53  <sdaftuar> sipa: oh maybe i misunderstood your earlier discussion
344 2018-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)
345 2018-08-13T17:10:18  <sipa> *before that
346 2018-08-13T17:10:23  <sdaftuar> sorry. yes, i undetstood that's what you were just talking about
347 2018-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
348 2018-08-13T17:10:59  <sdaftuar> (i think in the normal dandelion case)
349 2018-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"
350 2018-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
351 2018-08-13T17:13:20  <sdaftuar> and hence won't be spendable
352 2018-08-13T17:13:43  <sipa> ugh, yes - that's an extra complication
353 2018-08-13T17:13:44  <sdaftuar> that something can be looking into our own wallet's set of stem transactions, for instance
354 2018-08-13T17:13:59  *** aggieben has joined #bitcoin-core-dev
355 2018-08-13T17:14:01  <sdaftuar> but we can still slow down relay of children without totally breaking our wallet
356 2018-08-13T17:14:12  <sdaftuar> (if we need to)
357 2018-08-13T17:16:47  <sdaftuar> my first thought is that t
358 2018-08-13T17:16:50  <sdaftuar> oops
359 2018-08-13T17:18:38  *** bytting has quit IRC
360 2018-08-13T17:18:47  <instagibbs> also comes into consideration with checking balance, yes?
361 2018-08-13T17:18:56  <instagibbs> (with current code)
362 2018-08-13T17:28:35  *** bytting has joined #bitcoin-core-dev
363 2018-08-13T17:39:20  *** rafalcpp_ has joined #bitcoin-core-dev
364 2018-08-13T17:39:26  *** vexbuy_ has quit IRC
365 2018-08-13T17:39:36  *** Randolf has quit IRC
366 2018-08-13T17:39:36  *** no_input_found has quit IRC
367 2018-08-13T17:39:36  *** drexl has quit IRC
368 2018-08-13T17:39:36  *** rafalcpp has quit IRC
369 2018-08-13T17:39:56  *** Randolf has joined #bitcoin-core-dev
370 2018-08-13T17:40:04  *** Victorsueca has quit IRC
371 2018-08-13T17:40:18  *** no_input_found has joined #bitcoin-core-dev
372 2018-08-13T17:41:25  *** Victorsueca has joined #bitcoin-core-dev
373 2018-08-13T17:45:51  *** vexbuy has joined #bitcoin-core-dev
374 2018-08-13T17:50:11  *** str4d has joined #bitcoin-core-dev
375 2018-08-13T18:00:18  *** DougieBot5000 has quit IRC
376 2018-08-13T18:02:26  *** Krellan has quit IRC
377 2018-08-13T18:02:46  *** DougieBot5000 has joined #bitcoin-core-dev
378 2018-08-13T18:06:45  <gmaxwell> sdaftuar: I think we can slow the relay down, we just can't _drop_ the transaction.
379 2018-08-13T18:07:07  <gmaxwell> which is what I thought was being previously proposed.
380 2018-08-13T18:07:09  <sdaftuar> ah okay
381 2018-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.
382 2018-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?
383 2018-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
384 2018-08-13T18:08:31  <sdaftuar> but now i am coming up with new dos attacks that don't even rely on that
385 2018-08-13T18:08:57  <sdaftuar> say you have 1 mempool trnasaction with thousands of outputs
386 2018-08-13T18:09:10  <sdaftuar> i send you 1000 child transactions, each spending a different output
387 2018-08-13T18:09:16  <sdaftuar> only the first 25 or so will be accepted
388 2018-08-13T18:09:21  <sdaftuar> due to chain limits
389 2018-08-13T18:09:57  <sdaftuar> but how does a dandelion relayer avoid relaying all?  i think you would need a stempool
390 2018-08-13T18:11:51  <sdaftuar> but then a global stempool seems like it might introduce information leakage about routes
391 2018-08-13T18:12:11  <sdaftuar> while per-peer stempools seem like unacceptably awful overhead
392 2018-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.
393 2018-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
394 2018-08-13T18:44:17  *** csknk has quit IRC
395 2018-08-13T18:44:45  *** csknk has joined #bitcoin-core-dev
396 2018-08-13T18:46:10  *** justanotheruser has joined #bitcoin-core-dev
397 2018-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.
398 2018-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?
399 2018-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.
400 2018-08-13T18:54:56  <sdaftuar> yeah that too.  i think marco's PR doesn't have one (yet?)
401 2018-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)*
402 2018-08-13T18:56:53  <gmaxwell> why is whitelisted making a difference in your example?
403 2018-08-13T18:57:01  <sipa> i think we should ignore the whitelist status for dandelion
404 2018-08-13T18:57:11  <sipa> its scope shouldn't be extended further
405 2018-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.
406 2018-08-13T18:58:29  *** eslider has quit IRC
407 2018-08-13T18:58:41  <gmaxwell> it's really a weird and specialized thing.
408 2018-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
409 2018-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.
410 2018-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.
411 2018-08-13T19:07:12  *** vexbuy has quit IRC
412 2018-08-13T19:08:45  *** vexbuy has joined #bitcoin-core-dev
413 2018-08-13T19:14:10  *** michaelsdunn1 has quit IRC
414 2018-08-13T19:15:05  *** JackH has joined #bitcoin-core-dev
415 2018-08-13T19:16:11  *** michaelsdunn1 has joined #bitcoin-core-dev
416 2018-08-13T19:16:44  *** owowo has quit IRC
417 2018-08-13T19:21:00  *** cfields_ has joined #bitcoin-core-dev
418 2018-08-13T19:21:48  *** owowo has joined #bitcoin-core-dev
419 2018-08-13T19:23:46  *** thaumavorio_ has joined #bitcoin-core-dev
420 2018-08-13T19:23:57  *** intcat has quit IRC
421 2018-08-13T19:25:18  *** nmnkgl has quit IRC
422 2018-08-13T19:25:18  *** harding has quit IRC
423 2018-08-13T19:25:18  *** stepa[m] has quit IRC
424 2018-08-13T19:25:19  *** herzmeister[m] has quit IRC
425 2018-08-13T19:25:19  *** mappum__ has quit IRC
426 2018-08-13T19:25:19  *** rodarmor has quit IRC
427 2018-08-13T19:25:19  *** Nebraskka has quit IRC
428 2018-08-13T19:25:19  *** robby938_ has quit IRC
429 2018-08-13T19:25:19  *** jonasschnelli has quit IRC
430 2018-08-13T19:25:19  *** gaf_ has quit IRC
431 2018-08-13T19:25:19  *** thaumavorio has quit IRC
432 2018-08-13T19:25:19  *** cfields has quit IRC
433 2018-08-13T19:25:19  *** qinfengling has quit IRC
434 2018-08-13T19:26:04  *** plankers has joined #bitcoin-core-dev
435 2018-08-13T19:29:40  *** intcat has joined #bitcoin-core-dev
436 2018-08-13T19:31:18  *** ghost43 has quit IRC
437 2018-08-13T19:32:02  *** qinfengling has joined #bitcoin-core-dev
438 2018-08-13T19:32:05  *** ghost43 has joined #bitcoin-core-dev
439 2018-08-13T19:38:21  *** csknk has quit IRC
440 2018-08-13T19:38:54  *** dqx has quit IRC
441 2018-08-13T19:59:35  *** Pasha has quit IRC
442 2018-08-13T20:06:38  *** Pasha has joined #bitcoin-core-dev
443 2018-08-13T20:22:16  *** Rootsudo has joined #bitcoin-core-dev
444 2018-08-13T20:24:05  *** Dizzle has quit IRC
445 2018-08-13T20:27:52  *** Dizzle has joined #bitcoin-core-dev
446 2018-08-13T20:32:37  *** jonasschnelli_ has joined #bitcoin-core-dev
447 2018-08-13T20:35:13  *** DougieBot5000 has quit IRC
448 2018-08-13T20:35:18  *** luke-jr has quit IRC
449 2018-08-13T20:35:41  *** luke-jr has joined #bitcoin-core-dev
450 2018-08-13T20:37:01  *** DougieBot5000 has joined #bitcoin-core-dev
451 2018-08-13T20:38:18  *** nmnkgl has joined #bitcoin-core-dev
452 2018-08-13T20:42:30  *** Randolf has quit IRC
453 2018-08-13T20:47:21  *** Dizzle has quit IRC
454 2018-08-13T20:48:14  *** Dizzle has joined #bitcoin-core-dev
455 2018-08-13T20:52:49  *** promag has joined #bitcoin-core-dev
456 2018-08-13T21:28:21  *** jeremyrubin has joined #bitcoin-core-dev
457 2018-08-13T21:29:24  <jeremyrubin> Was discussing with wumpus the viability of timing attacks on PR 13666, he suggested I ask here.
458 2018-08-13T21:29:59  <jeremyrubin> Essentially additional bits leak out if the signature takes longer to generate.
459 2018-08-13T21:30:37  <sipa> jeremyrubin: you're right, but i believe it doesn't matter
460 2018-08-13T21:30:56  <sipa> how much does it help you to know (e.g.) that something took 10 tries to generate?
461 2018-08-13T21:30:58  <jeremyrubin> Was going to paste in your response
462 2018-08-13T21:31:02  <jeremyrubin> 1 sec...
463 2018-08-13T21:31:04  <sipa> ah
464 2018-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."
465 2018-08-13T21:31:27  <sipa> ah, seems i commented on this before :)
466 2018-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
467 2018-08-13T21:32:42  *** Chris_Stewart_5 has quit IRC
468 2018-08-13T21:33:35  <jeremyrubin> But as only an armchair cryptographer I don't feel comfortable asserting that this information is entirely useless
469 2018-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
470 2018-08-13T21:38:41  <jeremyrubin> Correct.
471 2018-08-13T21:46:10  *** promag has quit IRC
472 2018-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.
473 2018-08-13T21:49:56  <sipa> right, but that test requires an EC multiplication
474 2018-08-13T21:50:26  <jeremyrubin> So here's my question
475 2018-08-13T21:50:44  <jeremyrubin> Let's say I have another test I've observed to be 2 signatures
476 2018-08-13T21:51:13  <jeremyrubin> that is k1 and k2 such that serializesize(k{1,2}XG) = 71
477 2018-08-13T21:51:21  <jeremyrubin> err
478 2018-08-13T21:51:37  <jeremyrubin> ignore 14:51
479 2018-08-13T21:51:59  <jeremyrubin> Another signature I've observed to be 2 signing periods
480 2018-08-13T21:52:10  <jeremyrubin> that bit of information should be independent, right?
481 2018-08-13T21:52:20  <jeremyrubin> It still requires an ec mul to test directly
482 2018-08-13T21:52:36  <sipa> right
483 2018-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
484 2018-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
485 2018-08-13T21:53:36  <sipa> no, they're independent outputs of a hash function with different inputs
486 2018-08-13T21:53:39  <jeremyrubin> it would allow me to more efficiently test (k1 + k2) x G = 71
487 2018-08-13T21:53:43  <sipa> if there is such a correlation, sha256 is broken
488 2018-08-13T21:53:56  <jeremyrubin> I guess I'm asking about ec addition
489 2018-08-13T21:54:06  <jeremyrubin> like if k1 G is sersize 71
490 2018-08-13T21:54:13  <jeremyrubin> and k2 G is sersize 71
491 2018-08-13T21:54:24  <jeremyrubin> do we know anything about k1+k2?
492 2018-08-13T21:54:31  <sipa> ah; i believe these is no such test, but no proof that there isn't
493 2018-08-13T21:54:33  <jeremyrubin> (nothing to do with sha256)
494 2018-08-13T21:54:42  <jeremyrubin> If such a test did exist
495 2018-08-13T21:54:51  <jeremyrubin> Then you could use this timing attack
496 2018-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
497 2018-08-13T21:55:29  <sipa> which is far slower than a direct 2^128 EC DLP attack
498 2018-08-13T21:56:14  <sipa> but this is a good point
499 2018-08-13T21:56:33  <jeremyrubin> Ah also
500 2018-08-13T21:56:48  <jeremyrubin> I have the bit that k1_0 is 72 sersize
501 2018-08-13T21:56:57  <jeremyrubin> and k2_0 is 72 sersize
502 2018-08-13T21:57:12  <jeremyrubin> I think that's the bit that gets leaked that's more interesting
503 2018-08-13T21:57:25  <sipa> perhaps - but it also requires hashes to discover
504 2018-08-13T21:57:26  *** Krellan has joined #bitcoin-core-dev
505 2018-08-13T21:57:29  <jeremyrubin> Yeah
506 2018-08-13T21:57:48  *** Victorsueca has quit IRC
507 2018-08-13T21:59:09  *** Victorsueca has joined #bitcoin-core-dev
508 2018-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
509 2018-08-13T22:00:27  <sipa> yes, a writeup of the concerns and reasoning would be useful
510 2018-08-13T22:00:56  <jeremyrubin> I'm interested to work on it, but it's a bit beyond my depth as a cryptographer
511 2018-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.
512 2018-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)
513 2018-08-13T22:10:14  <sipa> that too results in a bias
514 2018-08-13T22:10:31  <jeremyrubin> What's the bias there?
515 2018-08-13T22:10:32  <sipa> (an equally harmless one, imho, though)
516 2018-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
517 2018-08-13T22:11:19  <sipa> (in their set of 256)
518 2018-08-13T22:11:54  <jeremyrubin> How is this leaked? we reveal 1 at random out of the low-R set?
519 2018-08-13T22:12:15  <jeremyrubin> Ah can't be random, right
520 2018-08-13T22:12:18  <sipa> yes, but it's biased
521 2018-08-13T22:12:25  <sipa> again, i don't thin this would be a concern
522 2018-08-13T22:12:40  <jeremyrubin> so would have to be with some deterministic sort, pick 1
523 2018-08-13T22:12:42  <sipa> but if leaks of any kind are a concern, this is one too
524 2018-08-13T22:12:48  <sipa> nope; still biased
525 2018-08-13T22:13:07  <jeremyrubin> (yep, just making the correction that made my algo non-det)
526 2018-08-13T22:13:19  <jeremyrubin> Trying to understand the bias
527 2018-08-13T22:13:30  <sipa> a correct solution would be to introduce a small amount of true randomness in the hash :)
528 2018-08-13T22:13:39  <sipa> as that's unobservable to an attacker
529 2018-08-13T22:14:05  <jeremyrubin> then no longer deterministic ;)
530 2018-08-13T22:14:21  <sipa> precisely.
531 2018-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?
532 2018-08-13T22:15:13  <sipa> but some R values have higher probability than others
533 2018-08-13T22:15:25  <jeremyrubin> Interesting... didn't know that
534 2018-08-13T22:15:31  <jeremyrubin> I thought it's supposed to be uniform
535 2018-08-13T22:15:46  <sipa> the message is public
536 2018-08-13T22:15:50  <sipa> so we assume m is fixed
537 2018-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)
538 2018-08-13T22:16:33  <sipa> agree with me so far?
539 2018-08-13T22:16:56  <jeremyrubin> yes
540 2018-08-13T22:17:14  <sipa> then map those 256 hash outputs to points, and look at their lowrness (i love that word)
541 2018-08-13T22:17:28  <jeremyrubin> haha, yep
542 2018-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)
543 2018-08-13T22:18:34  <jeremyrubin> * deterministically
544 2018-08-13T22:18:39  <sipa> oh, deterministically!
545 2018-08-13T22:18:43  <sipa> then it's even easier
546 2018-08-13T22:19:08  <sipa> your entire construct is a deterministic function from private key to point
547 2018-08-13T22:19:20  <sipa> which you can test for by iterating
548 2018-08-13T22:19:20  <jeremyrubin> No? The message is included.
549 2018-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
550 2018-08-13T22:19:40  <jeremyrubin> fair
551 2018-08-13T22:19:44  <sipa> *attacker
552 2018-08-13T22:20:10  <jeremyrubin> So how is a bit leaked?
553 2018-08-13T22:20:17  <jeremyrubin> (or a < bit)
554 2018-08-13T22:20:25  <sipa> the entire private key is leaked :)
555 2018-08-13T22:20:32  <sipa> information theoretically
556 2018-08-13T22:20:54  *** michaelsdunn1 has quit IRC
557 2018-08-13T22:21:06  <jeremyrubin> really? Now I'm lost..
558 2018-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.
559 2018-08-13T22:21:20  <gmaxwell> (or just publishing the pubkey leaks the key)
560 2018-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
561 2018-08-13T22:21:55  <sipa> jeremyrubin: that leaks the entire private key :)
562 2018-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)
563 2018-08-13T22:22:18  <gmaxwell> also, as an asside your conjectural 'weakness' goes away if we provide use the extra random input.
564 2018-08-13T22:22:45  * jeremyrubin sighs
565 2018-08-13T22:22:51  <gmaxwell> Which I suppose we should just do regardless, unless configured otherwise.
566 2018-08-13T22:22:55  <sipa> if you care about _computational_ security, a bias only matters if it lets you meaningully speed up the attack
567 2018-08-13T22:22:55  <jeremyrubin> I'm just talking about the timing attack
568 2018-08-13T22:23:00  <sipa> so am i
569 2018-08-13T22:23:22  <gmaxwell> jeremyrubin: also RFC6979 _inherently_ has this kind of timing attack because of the restriction into the scalar range.
570 2018-08-13T22:23:39  <jeremyrubin> Yes, the above potential attack about correlation in serializable size under addition
571 2018-08-13T22:23:48  <gmaxwell> If the HMAC_DRBG result is larger than N it tries again.
572 2018-08-13T22:23:58  <jeremyrubin> Interesting.
573 2018-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
574 2018-08-13T22:24:47  <sipa> the problem is leaking information that leads to a faster attack
575 2018-08-13T22:25:07  <sipa> because every deterministic algorithm leaks *all* the bits already, but not in a usable way
576 2018-08-13T22:26:12  <jeremyrubin> Well, is secp256k1 bijective ;)
577 2018-08-13T22:26:35  *** Guyver2 has quit IRC
578 2018-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.
579 2018-08-13T22:27:28  <gmaxwell> If your attacker has unbounded computing time, however, he could compute it both ways.
580 2018-08-13T22:27:43  <gmaxwell> Which is why it has only computational security.
581 2018-08-13T22:28:16  <sipa> yes, informational theoretically ECDSA is trivial to break overall
582 2018-08-13T22:28:28  <sipa> again my point: leaking a bit isn't what matters
583 2018-08-13T22:31:28  *** Rootsudo has quit IRC
584 2018-08-13T22:31:34  <jeremyrubin> be back in a... bit
585 2018-08-13T22:36:27  *** promag has joined #bitcoin-core-dev
586 2018-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.
587 2018-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
588 2018-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
589 2018-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)
590 2018-08-13T22:38:18  <sipa> (possibly, to a timing attacker)
591 2018-08-13T22:38:42  <gmaxwell> e.g. it's isomorpic to looking at R and counting how many leading 0s it has.
592 2018-08-13T22:38:50  <sipa> to a non-timing attacker the new algorithm actually leaks less
593 2018-08-13T22:42:42  *** Krellan_ has joined #bitcoin-core-dev
594 2018-08-13T22:44:17  *** Krellan has quit IRC
595 2018-08-13T22:46:26  *** jb55 has quit IRC
596 2018-08-13T22:51:15  *** itaseski has quit IRC
597 2018-08-13T22:52:05  *** str4d has quit IRC
598 2018-08-13T22:58:40  *** pluit has quit IRC
599 2018-08-13T23:08:23  *** promag has quit IRC
600 2018-08-13T23:33:04  *** bytting has quit IRC
601 2018-08-13T23:35:35  *** justanotheruser has quit IRC
602 2018-08-13T23:41:27  *** promag has joined #bitcoin-core-dev
603 2018-08-13T23:51:00  *** vexbuy has quit IRC
604 2018-08-13T23:52:35  *** Dizzle has quit IRC
605 2018-08-13T23:52:46  *** Victorsueca has quit IRC
606 2018-08-13T23:53:55  *** Victorsueca has joined #bitcoin-core-dev