1 2016-03-23T00:30:53 *** justanotheruser has quit IRC 2 2016-03-23T00:35:41 *** justanotheruser has joined #bitcoin-core-dev 3 2016-03-23T00:49:23 *** laurentmt has joined #bitcoin-core-dev 4 2016-03-23T01:07:26 *** Chris_Stewart_5 has joined #bitcoin-core-dev 5 2016-03-23T01:09:22 *** randy-waterhouse has joined #bitcoin-core-dev 6 2016-03-23T01:19:09 *** belcher has quit IRC 7 2016-03-23T01:19:18 *** fengling has joined #bitcoin-core-dev 8 2016-03-23T01:19:25 *** go1111111 has quit IRC 9 2016-03-23T01:19:54 *** go1111111 has joined #bitcoin-core-dev 10 2016-03-23T01:28:25 *** laurentmt has quit IRC 11 2016-03-23T01:31:00 *** Ylbam has quit IRC 12 2016-03-23T01:46:36 *** fengling has quit IRC 13 2016-03-23T01:49:51 *** AaronvanW has quit IRC 14 2016-03-23T01:54:14 *** fengling has joined #bitcoin-core-dev 15 2016-03-23T02:30:59 *** mrkent has quit IRC 16 2016-03-23T02:37:36 *** [Author] has joined #bitcoin-core-dev 17 2016-03-23T02:40:53 *** Chris_Stewart_5 has quit IRC 18 2016-03-23T02:45:56 *** [Author] has quit IRC 19 2016-03-23T02:48:24 *** [Author] has joined #bitcoin-core-dev 20 2016-03-23T02:52:15 *** Don_John has quit IRC 21 2016-03-23T02:59:01 *** Alopex has quit IRC 22 2016-03-23T03:00:06 *** Alopex has joined #bitcoin-core-dev 23 2016-03-23T03:27:04 *** PRab has quit IRC 24 2016-03-23T03:27:51 *** PRab has joined #bitcoin-core-dev 25 2016-03-23T03:30:35 *** achow101 has quit IRC 26 2016-03-23T03:58:58 *** wallet42 has joined #bitcoin-core-dev 27 2016-03-23T04:14:49 *** wallet42 has quit IRC 28 2016-03-23T04:15:20 *** wallet42 has joined #bitcoin-core-dev 29 2016-03-23T04:23:01 *** Alopex has quit IRC 30 2016-03-23T04:24:06 *** Alopex has joined #bitcoin-core-dev 31 2016-03-23T04:29:55 *** jtimon has quit IRC 32 2016-03-23T05:18:03 *** xiangfu has joined #bitcoin-core-dev 33 2016-03-23T05:20:17 *** wallet42 has quit IRC 34 2016-03-23T05:25:53 *** supasonic has joined #bitcoin-core-dev 35 2016-03-23T06:00:20 *** dermoth has quit IRC 36 2016-03-23T06:00:52 *** dermoth has joined #bitcoin-core-dev 37 2016-03-23T06:16:01 *** Alopex has quit IRC 38 2016-03-23T06:17:06 *** Alopex has joined #bitcoin-core-dev 39 2016-03-23T06:35:00 *** Thireus has joined #bitcoin-core-dev 40 2016-03-23T06:38:36 *** fanatid has joined #bitcoin-core-dev 41 2016-03-23T06:42:14 <fanatid> Hey to all, can somebody explain, why BIP66 not checks that R or S more than 33 bytes (but checks that total length can't be more than 73 bytes) 42 2016-03-23T06:42:44 <fanatid> for example this (in hex) will be valid for BIP66: 3044021458a2f39bd87f0000000506030000000000050603022c402dde9afe7f0000010000000100000004000000040000000000000000000000000000000a00000000000000 but invalid for secp256k1 43 2016-03-23T06:43:03 <fanatid> question on github: https://github.com/bitcoin/bitcoin/pull/5713#issuecomment-197715788 44 2016-03-23T06:49:42 *** supasonic has quit IRC 45 2016-03-23T06:54:01 *** Alopex has quit IRC 46 2016-03-23T06:54:55 *** ajweutr has joined #bitcoin-core-dev 47 2016-03-23T06:55:06 *** Alopex has joined #bitcoin-core-dev 48 2016-03-23T06:56:35 <sipa> fanatid: it's just a minimal subset of rules that are sufficient to make parsing easy, but don't guarantee that it's valid 49 2016-03-23T06:56:57 <sipa> fanatid: there are more arbitrary restrictions that could have been included 50 2016-03-23T06:57:40 *** paveljanik has quit IRC 51 2016-03-23T06:57:50 <sipa> fanatid: for example, checking that the R or S integer is less than the secp256k1 curve order (which would rule out some 33-byte values) 52 2016-03-23T06:58:12 <fanatid> I understand that there are not all restrictions, it's just very strange to see that BIP66 checks total length, but not checks r|s length 53 2016-03-23T06:58:30 <sipa> fanatid: or you could go as far as checking that R is a valid secp256k1 X coordinate mod the order 54 2016-03-23T06:59:35 <sipa> fanatid: adding that would not have added anything; the total length check is included because otherwise the rest of the bip66 code would have needed to be able to deal with >1-byte length descriptors 55 2016-03-23T07:02:28 <sipa> in retrospect, maybe we could have added length restrictions 56 2016-03-23T07:02:47 <sipa> but it doesn't matter much, and the rules are as they are 57 2016-03-23T07:02:54 <fanatid> sipa: thank you, can you paste answer in github issue? (or I can do this, if you busy) 58 2016-03-23T07:03:33 <sipa> if we'd change it again, i would argue that signatures have to be valid, or ""; anything else results in a failed script execution 59 2016-03-23T07:07:08 <sipa> and i do plan to propose a 64-byte Schnorr signature based scheme after segwit at some point, but that doesn't affect existing signature parsing of course 60 2016-03-23T07:07:36 <sipa> fanatid: there was some discussion about this precise issue before, i think 61 2016-03-23T07:07:52 <sipa> fanatid: probably on the ML or the BIP pr itself 62 2016-03-23T07:22:18 *** Ylbam has joined #bitcoin-core-dev 63 2016-03-23T07:48:33 *** GreenIsMyPepper has quit IRC 64 2016-03-23T08:02:00 <GitHub82> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c946a15075ba...490064111f86 65 2016-03-23T08:02:00 <GitHub82> bitcoin/master bb16c88 JoÃ£o Barbosa: Prevent multiple calls to CWallet::AvailableCoins 66 2016-03-23T08:02:01 <GitHub82> bitcoin/master 4900641 Wladimir J. van der Laan: Merge #7649: Prevent multiple calls to CWallet::AvailableCoins... 67 2016-03-23T08:02:08 <GitHub173> [bitcoin] laanwj closed pull request #7649: Prevent multiple calls to CWallet::AvailableCoins (master...enhancement/prevent-multiple-calls-availablecoins) https://github.com/bitcoin/bitcoin/pull/7649 68 2016-03-23T08:03:56 *** frankenmint has quit IRC 69 2016-03-23T08:04:31 *** frankenmint has joined #bitcoin-core-dev 70 2016-03-23T08:09:14 *** frankenmint has quit IRC 71 2016-03-23T08:15:01 *** Alopex has quit IRC 72 2016-03-23T08:16:06 *** Alopex has joined #bitcoin-core-dev 73 2016-03-23T08:41:01 *** Alopex has quit IRC 74 2016-03-23T08:42:07 *** Alopex has joined #bitcoin-core-dev 75 2016-03-23T08:58:37 *** laurentmt has joined #bitcoin-core-dev 76 2016-03-23T08:58:51 *** randy-waterhouse has quit IRC 77 2016-03-23T09:09:02 *** Guyver2 has joined #bitcoin-core-dev 78 2016-03-23T09:41:08 *** laurentmt has quit IRC 79 2016-03-23T09:59:35 *** AaronvanW has joined #bitcoin-core-dev 80 2016-03-23T10:09:15 *** xiangfu has quit IRC 81 2016-03-23T10:28:43 <wumpus> I'm shocked how many people still use windows xp, and even run bitcoin nodes on it 82 2016-03-23T10:29:16 *** fengling has quit IRC 83 2016-03-23T10:30:17 *** laurentmt has joined #bitcoin-core-dev 84 2016-03-23T10:32:36 <ajweutr> I'm shocked how many people still use windows. 85 2016-03-23T10:33:14 <wumpus> well okay but how can you rationalize running internet-connected software on something that will get no security updates anymore 86 2016-03-23T10:36:20 <sipa> running internet-connected *wallet* software 87 2016-03-23T10:36:25 <wumpus> it's like signing a general 'yes I want to be part of your botnet' waiver 88 2016-03-23T10:36:31 <wumpus> well they claim not to use the wallet 89 2016-03-23T10:38:46 *** fengling has joined #bitcoin-core-dev 90 2016-03-23T10:43:12 <btcdrak> wumpus: there are hundreds of thousands of ATMs around the world still running Windows XP... 91 2016-03-23T10:44:44 <wumpus> absurd 92 2016-03-23T10:50:53 *** Guyver2 has quit IRC 93 2016-03-23T10:57:06 <Luke-Jr> wumpus: as if a node has any value besides security 94 2016-03-23T11:06:21 <wumpus> the thing is, the last thing I want is to discourage people from running a node, but they should also understand that we can't devote much time to supporting a 15 year old OS that was abandoned by the vendor 95 2016-03-23T11:08:54 <sipa> in other news: i now run bitcoin core on my phonr 96 2016-03-23T11:08:59 <sipa> *phone 97 2016-03-23T11:15:32 <btcdrak> wumpus: given that XP has been EOL for years now, should we be supporting it at all? Basically, the OS is insecure. 98 2016-03-23T11:15:56 <btcdrak> sipa: are you using Abcore? 99 2016-03-23T11:17:11 <sipa> btcdrak: yeah 100 2016-03-23T11:20:25 *** gevs has quit IRC 101 2016-03-23T11:32:51 *** btcdrak is now known as intdrak 102 2016-03-23T11:33:58 *** gevs has joined #bitcoin-core-dev 103 2016-03-23T11:41:06 <wumpus> sipa: cool :) 104 2016-03-23T11:41:35 <wumpus> intdrak: I'd expected so, but see the response to the issue where I dare proposing dropping support for windows xp and older: https://github.com/bitcoin/bitcoin/issues/7681 105 2016-03-23T11:42:48 <wumpus> apparently release 0.12.0 is already unstable on wxp, it appears due to some msvcrt.dll issue. If that doesn't get resolved, we have to make it official and drop support for it. 106 2016-03-23T11:47:03 *** dermoth has quit IRC 107 2016-03-23T11:47:34 <GitHub103> [bitcoin] laanwj opened pull request #7737: devtools: make github-merge.py use py3 (master...2016_03_python_3_github_merge) https://github.com/bitcoin/bitcoin/pull/7737 108 2016-03-23T11:47:48 *** dermoth has joined #bitcoin-core-dev 109 2016-03-23T11:59:00 <intdrak> wumpus: I dont think the comment in #7681 is true. There is _unofficial support_ from a 3rd party dev called "harkaz". There is no official support for XP, it's EOL. 110 2016-03-23T11:59:31 <intdrak> wumpus: sauce http://www.ryanvm.net/forum/viewtopic.php?t=10321 111 2016-03-23T12:02:51 <wumpus> in any case I didn't even give a date or milestone, and still people reply like that 112 2016-03-23T12:03:16 <wumpus> a third party releasing a service pack? seems legit... 113 2016-03-23T12:03:17 <sipa> wumpus: it's two people... 114 2016-03-23T12:03:46 *** fanatid has quit IRC 115 2016-03-23T12:06:11 <wumpus> yeah... 116 2016-03-23T12:07:14 <wumpus> maybe I'm unduly worried, it was more about the speed at which those replies came in, apparently it's another useless thing people feel very strongly about 117 2016-03-23T12:09:51 <wumpus> in any case if anyone actually wants to support bitcoin core on XP, be my guest, you're welcome, but don't simply expect it from others 118 2016-03-23T12:12:53 <intdrak> wumpus: I think your response is reasonable: try to fix it now, and remove support from 0.13 in any case. 119 2016-03-23T12:13:06 <intdrak> and if it cant be fixed, too bad. 120 2016-03-23T12:14:46 <GitHub138> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/490064111f86...909b72b10b4d 121 2016-03-23T12:14:47 <GitHub138> bitcoin/master 5fd2318 fanquake: [Depends] Miniupnpc 1.9.20160209... 122 2016-03-23T12:14:47 <GitHub138> bitcoin/master c85f475 fanquake: [Depends] Latest config.guess & config.sub 123 2016-03-23T12:14:48 <GitHub138> bitcoin/master 909b72b Wladimir J. van der Laan: Merge #7710: [Depends] Bump miniupnpc and config.guess+sub... 124 2016-03-23T12:14:56 <GitHub55> [bitcoin] laanwj closed pull request #7710: [Depends] Bump miniupnpc and config.guess+sub (master...depends-02) https://github.com/bitcoin/bitcoin/pull/7710 125 2016-03-23T12:17:20 <wumpus> right 126 2016-03-23T12:25:10 <GitHub116> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/909b72b10b4d...e2ebd259fbe8 127 2016-03-23T12:25:11 <GitHub116> bitcoin/master fe00ca7 Andrew C: Create generatetoaddress rpc... 128 2016-03-23T12:25:11 <GitHub116> bitcoin/master d5c5c71 Andrew C: RPC tests for generatetoaddress... 129 2016-03-23T12:25:12 <GitHub116> bitcoin/master e2ebd25 Wladimir J. van der Laan: Merge #7671: [RPC] Add generatetoaddress rpc to mine to an address... 130 2016-03-23T12:25:17 <GitHub149> [bitcoin] laanwj closed pull request #7671: [RPC] Add generatetoaddress rpc to mine to an address (master...generate-to-addr) https://github.com/bitcoin/bitcoin/pull/7671 131 2016-03-23T12:25:57 *** Guyver2 has joined #bitcoin-core-dev 132 2016-03-23T12:29:00 <Luke-Jr> intdrak: is "3rd party unofficial support" significantly different from a Linux distro fork in this regard? 133 2016-03-23T12:29:19 <Luke-Jr> (not that I think we need to support XP. if nobody cares enough to fix it, it can go bye-bye) 134 2016-03-23T12:29:53 <sipa> Luke-Jr: that's a good point 135 2016-03-23T12:30:14 *** Chris_Stewart_5 has joined #bitcoin-core-dev 136 2016-03-23T12:30:15 <wumpus> did they legally take over the support from microsoft? 137 2016-03-23T12:30:37 <wumpus> if so, I suppose it's comparable, if not, it's something completely different 138 2016-03-23T12:30:43 <sipa> Luke-Jr: i think that the fact that most of the code is closed source does make a quantitave different, but it's fuzzy 139 2016-03-23T12:30:59 <wumpus> in any case it isn't any reason to influence our decision about supporting it or not 140 2016-03-23T12:31:19 <wumpus> someone needs to step up to support it, if not, it's done 141 2016-03-23T12:31:19 <Luke-Jr> sipa: they can't identify unfixed bugs maybe, but they could in theory backport or identify unbackportable stuff 142 2016-03-23T12:32:30 <Luke-Jr> wumpus: from a security perspective, I don't know why the legalities would matter. but I agree it isn't very relevant. 143 2016-03-23T12:33:03 <wumpus> Luke-Jr: well I think from a security perspective, for a closed source OS, microsoft's blessing is very imporant. 144 2016-03-23T12:34:28 <wumpus> and you can't support a closed source OS if you don't know what is going on behind the scenes, if you don't have access to internal documents and source code etc 145 2016-03-23T12:35:17 <wumpus> you were comparing it to a linux distro fork where everything happens in the open - taking over support for a close source product is very different 146 2016-03-23T12:36:11 <sipa> yeah, i think that in theory you can say that a linux distro without any official support is not different from an unofficially supported windows os 147 2016-03-23T12:36:38 <sipa> but in practice, it's a huge difference; closed source is one, but also the fact that linux distros do more just packaging of work done by other projects 148 2016-03-23T12:37:07 <wumpus> you can't really continue someone elses' development with closed source software... or what, reverse engineer, use a hex editor? 149 2016-03-23T12:37:09 <sipa> windows unsupported probably means that there are components in the OS on which _nobody_ is even working anymore 150 2016-03-23T12:38:01 <wumpus> would you claim that makes *no* difference from a security perspective? 151 2016-03-23T12:54:38 *** paveljanik has joined #bitcoin-core-dev 152 2016-03-23T13:15:17 *** Guyver2 has quit IRC 153 2016-03-23T13:31:23 *** jtimon has joined #bitcoin-core-dev 154 2016-03-23T13:35:32 <morcos> wumpus: i'm not going to be around for the meeting tomorrow. but would have been nice if we'd made more progress on our action items for last week. 155 2016-03-23T13:35:54 <morcos> whats the best way to get a few volunteers to review these backports so we can start RC's for the CSV soft fork? 156 2016-03-23T13:36:47 <wumpus> I don't have an answer to that, unfortunately 157 2016-03-23T13:36:57 <wumpus> getting people to review things is very hard 158 2016-03-23T13:37:17 <wumpus> you could try spamming it here a few times, or on twitter, or wherever 159 2016-03-23T13:38:38 <wumpus> ideally, people that care about backports at all would spend work reviewing what is backported to their favorite version 160 2016-03-23T13:38:56 <morcos> i think we should be a bit more willing to ask specific contributors (who would be appropriate for the PR) when its something high priority like this that we all agree is holding up progress (to some degree) 161 2016-03-23T13:39:19 <wumpus> sure, you can always @ people and ping them in the PR 162 2016-03-23T13:42:52 <wumpus> it tends to work 163 2016-03-23T13:43:20 <instagibbs> morcos, asking *specific* people probably works better 164 2016-03-23T13:43:41 <instagibbs> "Someone call 911" vs "You call 911" 165 2016-03-23T13:44:01 <instagibbs> (911 being US emergency number) 166 2016-03-23T13:50:16 *** Chris_Stewart_5 has quit IRC 167 2016-03-23T13:50:35 *** d_t has joined #bitcoin-core-dev 168 2016-03-23T13:54:09 <intdrak> luke-jr: sipa: I think it's completely different. MS Windows is closed source, so I'm not sure how he can be providing reliable support - certainly no way to audit it. 169 2016-03-23T13:54:38 <sipa> yes, i agree that in practice is completely different 170 2016-03-23T13:55:10 *** d_t has quit IRC 171 2016-03-23T13:55:53 <sipa> but the criterion is not whether or not there is a official support (because many linux distros have no official support whatsoever), but whether the available support is sufficient 172 2016-03-23T13:56:45 <wumpus> any linux distribution worth its salt at least has security upgrades 173 2016-03-23T13:57:59 <sipa> yes, agree completely - i was just arguing semantics 174 2016-03-23T13:58:02 <sipa> sorry :) 175 2016-03-23T13:58:07 <intdrak> morcos: I have been hassling people in private to do reviews. I'll go bang on a few more doors 176 2016-03-23T14:00:51 <wumpus> as for official support, yea, for Ubuntu, Redhat, etc you can get some kind of support contract, doubt that's possible for the smaller ones 177 2016-03-23T14:04:27 *** Chris_Stewart_5 has joined #bitcoin-core-dev 178 2016-03-23T14:06:44 *** alexuy has joined #bitcoin-core-dev 179 2016-03-23T14:08:09 *** musalbas has quit IRC 180 2016-03-23T14:08:09 *** lysobit has quit IRC 181 2016-03-23T14:08:56 *** Taek42 has joined #bitcoin-core-dev 182 2016-03-23T14:09:01 *** lesderid has quit IRC 183 2016-03-23T14:09:20 <GitHub144> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e2ebd259fbe8...3bdc583b3f07 184 2016-03-23T14:09:21 <GitHub144> bitcoin/master 68d4282 Alex Morcos: Fix calculation of balances and available coins.... 185 2016-03-23T14:09:21 <GitHub144> bitcoin/master 3bdc583 Wladimir J. van der Laan: Merge #7715: Fix calculation of balances and available coins.... 186 2016-03-23T14:09:27 *** sipa has quit IRC 187 2016-03-23T14:09:30 <GitHub191> [bitcoin] laanwj closed pull request #7715: Fix calculation of balances and available coins. (master...fixconflicts_take2) https://github.com/bitcoin/bitcoin/pull/7715 188 2016-03-23T14:09:52 <wumpus> morcos: the other option, of course, is to just start merging stuff :) 189 2016-03-23T14:09:53 *** Taek has quit IRC 190 2016-03-23T14:12:14 <GitHub160> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/19866c1ffcb860bc2980e00e956685b9a8f96529 191 2016-03-23T14:12:14 <GitHub160> bitcoin/0.12 19866c1 Alex Morcos: Fix calculation of balances and available coins.... 192 2016-03-23T14:12:28 <intdrak> I would assume the backports are relatively straightforward to review. 193 2016-03-23T14:12:42 *** achow101 has joined #bitcoin-core-dev 194 2016-03-23T14:13:08 *** intdrak is now known as btcdrak 195 2016-03-23T14:13:37 *** fengling has quit IRC 196 2016-03-23T14:13:38 *** AdrianG_ has joined #bitcoin-core-dev 197 2016-03-23T14:16:14 <wumpus> if there are to be any bounties in the bitcoin core project ever it'd be for reviewing code, that's by far the most difficult thing to motivate people to do 198 2016-03-23T14:18:34 *** sipa_ has joined #bitcoin-core-dev 199 2016-03-23T14:18:34 *** Aleph0 has quit IRC 200 2016-03-23T14:18:35 *** lesderid_ has joined #bitcoin-core-dev 201 2016-03-23T14:19:39 <btcdrak> Well the PRs people need to review are #7648, #7543 and #7716 202 2016-03-23T14:21:12 <wumpus> some projects have a bot that automatically picks a random reviewer from some list for a PR when it's finished, is that maybe an idea? :p https://github.com/maidsafe/safe_ffi/pull/45 203 2016-03-23T14:22:04 <sipa_> at google there was a policy that you pick an appropriate reviewer yourself 204 2016-03-23T14:22:15 <btcdrak> hrm. offer a bounty and the winner is decided by the the merge commit hash :-P 205 2016-03-23T14:22:28 <sipa_> btcdrak: you can grind commit hashes :p 206 2016-03-23T14:23:07 <wumpus> well for some PRs it's pretty straightforward who should review it, e.g. cfields for build system changes, for others not so much 207 2016-03-23T14:24:29 <wumpus> another option would be to put some time pressure behind it, post a date in the PR, if no comments by then it will be merged as-is 208 2016-03-23T14:24:37 <btcdrak> #7648 is pretty straight forward and it's got lots of RPC tests to verify behaviour. 209 2016-03-23T14:24:43 <sipa_> wumpus: ouch! 210 2016-03-23T14:25:27 <sipa_> (i generally agree that trying to provide fast feedback on PRs is something to aim for... but automatic merging may be a bridge too far) 211 2016-03-23T14:25:30 <wumpus> sipa_: just throwing out ideas I've seen in other projects, not saying it's a good idea :) 212 2016-03-23T14:26:39 <wumpus> it also depends on the kind of change, I tend to merge pure tests changes semi-automatically, obviously we don't want that for consensus changes 213 2016-03-23T14:27:56 <btcdrak> I think the only solution is more staff. 214 2016-03-23T14:28:39 <jonasschnelli> we could incentives reviews by adding btc-micropayment to contributors that commented a tested ACK (<githash> of later merged PR ... :) *duck* 215 2016-03-23T14:29:02 <jonasschnelli> I'm pretty sure we would get a lot of (untested) tested ACKs 216 2016-03-23T14:29:43 <btcdrak> yeah ^ 217 2016-03-23T14:29:45 <wumpus> jonasschnelli: yea you'd have to require an extensive testing report in that case, to be sure someone actually did the work 218 2016-03-23T14:30:01 <btcdrak> need some kind of "proof of review, proof of test" 219 2016-03-23T14:30:03 <wumpus> jonasschnelli: and that's probably not as far as people are willing to go for a micropayment :) 220 2016-03-23T14:30:34 <jonasschnelli> wumpus: Right. He needs to calculate a sha256 of the random chosen words of the change source-code. :) 221 2016-03-23T14:30:43 <sipa_> or you could encourage PRs to have a hash of a message that reveals something the author believes a reviewer should notice, and you can get a bounty for correctly finding it 222 2016-03-23T14:30:47 *** sipa_ is now known as sipa 223 2016-03-23T14:30:49 <btcdrak> you'd have to introduce a couple of bugs on purpose to see if people picked up on it to know if they really looked properly 224 2016-03-23T14:31:17 *** sipa is now known as Guest7455 225 2016-03-23T14:31:37 *** Guest7455 is now known as sipax 226 2016-03-23T14:31:46 *** sipax has quit IRC 227 2016-03-23T14:31:46 *** sipax has joined #bitcoin-core-dev 228 2016-03-23T14:33:47 <morcos> i think we should not treat all PR's equally 229 2016-03-23T14:34:00 <morcos> for some PR's the lack of reviewers is the signal as to whether or not its somethign we want to merge 230 2016-03-23T14:34:15 *** lesderid_ is now known as lesderid 231 2016-03-23T14:34:27 <morcos> but for other PR's we've agreed a priori that we want the functionality or fix and its just a matter of ensuring the code has been reviewed 232 2016-03-23T14:34:35 <morcos> its the second case that i think we need to work on 233 2016-03-23T14:34:36 <wumpus> and on the other side, some people actually do get review comments but then delay indefinitely in taking them into account *cough* rebroad *cough* 234 2016-03-23T14:34:53 <sipax> maybe we should try to have a deadline on concept ack/nacks 235 2016-03-23T14:35:00 <morcos> i know for example that i'll sometimes get caught up in a streak of coding and not doing enough reviewing 236 2016-03-23T14:35:16 <morcos> and i certainly wouldn't mind if there were PR's that were in the second category that i got pinged on if they were in my wheelhouse 237 2016-03-23T14:35:30 <morcos> but what i don't want is every random PR for someone to assign it to me to review 238 2016-03-23T14:36:10 <wumpus> absolutely not all PRs should be treated equally, that's also certainly not what is happening, things that garner no interest are closed after a while 239 2016-03-23T14:36:31 <morcos> so i think putting it entirely in the hands of the PR author isn't maybe right... but perhaps some of the senior project people could say to the author, hey, please ping a few reviewers for this code, we'd like to get it merged 240 2016-03-23T14:36:35 <morcos> i dont know 241 2016-03-23T14:37:27 <btcdrak> for #7648 how many reviewers do we need? 242 2016-03-23T14:37:48 <wumpus> well as said, for some PRs it's clear who should be pinged for them, e.g. if there is some complicated mempool change I'll be sure to ping you morcos 243 2016-03-23T14:38:22 <wumpus> but for a backport it's not nearly as clear cut 244 2016-03-23T14:39:06 <morcos> 7648 looks good at this point, and 7543 is fairly trivial if you trust 7648. 245 2016-03-23T14:39:21 <morcos> 7716 on the other hand is a problem. the 0.11 backport. 246 2016-03-23T14:39:45 <morcos> i think thats always going to be a problem going back a version, i mean who is the poor sap who is going to review the segwit backport 247 2016-03-23T14:39:47 <wumpus> yes #7648 looks good 248 2016-03-23T14:40:01 *** laurentmt has quit IRC 249 2016-03-23T14:40:52 <wumpus> btcdrak: you've introduced a new blockchain historical video media extension in #7648? *ducks* "BIP113 Media Time Past." 250 2016-03-23T14:41:27 <morcos> my favorite is btcdrak's insistence on the acronym TDB 251 2016-03-23T14:42:41 <helo> soon we will communicate using only acronyms <3 252 2016-03-23T14:43:29 <sipax> ACK OR GTFO! 253 2016-03-23T14:43:53 <wumpus> lol 254 2016-03-23T14:45:14 <morcos> wumpus: would be nice to add first commit from https://github.com/bitcoin/bitcoin/pull/7707 as well, just commented on PR 255 2016-03-23T14:46:26 <wumpus> morcos: sure, though usually we merge the master pull first before backporting anything 256 2016-03-23T14:47:08 <btcdrak> wumpus: ahahaha 257 2016-03-23T14:47:15 <wumpus> in this case, that it's a combination of a GUI change and a non-GUI change (which should be backported) complicates the process, otoh it's just one line so here goes.. 258 2016-03-23T14:47:17 <morcos> wumpus: yeah, thats why i didn't ACK that commit earlier, i was going to review the whole PR, but i've run out of time to do that (going out of town). but you could merge that commit into master and just make jonas rebase 259 2016-03-23T14:47:50 <wumpus> yes good idea, I'll do that 260 2016-03-23T14:47:55 <jonasschnelli> morcos, wumpus: should I open a PR with the non-gui oneliner against master and 0.12? 261 2016-03-23T14:48:35 <wumpus> jonasschnelli: I was just going to do that, but sure go ahead :) 262 2016-03-23T14:48:45 <jonasschnelli> okay... give me couple of minutes 263 2016-03-23T14:50:27 *** fengling has joined #bitcoin-core-dev 264 2016-03-23T14:51:08 <GitHub38> [bitcoin] jonasschnelli opened pull request #7739: [Wallet][RPC] add abandoned status to listtransactions (master...2016/03/aba_rpc) https://github.com/bitcoin/bitcoin/pull/7739 265 2016-03-23T14:51:43 <GitHub56> [bitcoin] jonasschnelli opened pull request #7740: [0.12 BP] [Wallet][RPC] add abandoned status to listtransactions (0.12...2016/03/aba_rpc_012) https://github.com/bitcoin/bitcoin/pull/7740 266 2016-03-23T14:51:44 <jonasschnelli> wumpus: done https://github.com/bitcoin/bitcoin/pull/7739 and https://github.com/bitcoin/bitcoin/pull/7740 267 2016-03-23T14:58:51 *** supasonic has joined #bitcoin-core-dev 268 2016-03-23T14:59:11 <jonasschnelli> Anyone interested in reviewing my p2p-authentication and encryption BIP before submitting to the ML? 269 2016-03-23T14:59:38 <jonasschnelli> https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/03/auth_enc?expand=1 270 2016-03-23T15:21:55 *** sipax is now known as sipa 271 2016-03-23T15:22:17 *** wallet42 has joined #bitcoin-core-dev 272 2016-03-23T15:25:06 *** Guyver2 has joined #bitcoin-core-dev 273 2016-03-23T15:30:46 <GitHub102> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3bdc583b3f07...09a079e6484a 274 2016-03-23T15:30:47 <GitHub102> bitcoin/master 263de3d Jonas Schnelli: [Wallet][RPC] add abandoned status to listtransactions 275 2016-03-23T15:30:47 <GitHub102> bitcoin/master 09a079e Wladimir J. van der Laan: Merge #7739: [Wallet][RPC] add abandoned status to listtransactions... 276 2016-03-23T15:30:51 <GitHub61> [bitcoin] laanwj closed pull request #7739: [Wallet][RPC] add abandoned status to listtransactions (master...2016/03/aba_rpc) https://github.com/bitcoin/bitcoin/pull/7739 277 2016-03-23T15:31:35 <GitHub170> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/7ffc2bd9439b2ad4da653583f7e57915980522a3 278 2016-03-23T15:31:35 <GitHub170> bitcoin/0.12 7ffc2bd Jonas Schnelli: [Wallet][RPC] add abandoned status to listtransactions... 279 2016-03-23T15:32:57 <GitHub140> [bitcoin] laanwj closed pull request #7740: [0.12 BP] [Wallet][RPC] add abandoned status to listtransactions (0.12...2016/03/aba_rpc_012) https://github.com/bitcoin/bitcoin/pull/7740 280 2016-03-23T15:34:30 <wumpus> jonasschnelli: sure 281 2016-03-23T15:38:18 *** alexuy_ has joined #bitcoin-core-dev 282 2016-03-23T15:38:18 *** alexuy has quit IRC 283 2016-03-23T15:38:18 *** alexuy_ is now known as alexuy 284 2016-03-23T15:41:27 <wumpus> jonasschnelli: you should also approach warren about this ,he was very interested in this, maybe he can drum op some more reviewers 285 2016-03-23T15:42:17 <jonasschnelli> wumpus: Yes. He show interest at the conference in Cambridge. Ping warren. 286 2016-03-23T15:44:10 *** supasonic has quit IRC 287 2016-03-23T15:47:17 <wumpus> jonasschnelli: btw I didn't discover yet what the proposed layering is, but you should always encrypt-then-mac (verify mac before decryptiong), not mac-then-encrypt (eg have the message autehntication behind/inside the encryption) 288 2016-03-23T15:48:20 <jonasschnelli> wumpus: Yes. I agree. But the authentication scheme is ECDSA bases. IMO the auth itself is encrypted. 289 2016-03-23T15:48:56 *** fengling has quit IRC 290 2016-03-23T15:49:35 <jonasschnelli> wumpus: and the proposed Auth does what "certificates" do in SSH. They ensure that the remote party sill possesses the private key (=identity). 291 2016-03-23T15:49:42 <wumpus> jonasschnelli: ok, but I suppose you never have enc(auth( 292 2016-03-23T15:49:57 <wumpus> jonasschnelli: then it's good 293 2016-03-23T15:50:02 *** wallet42 has quit IRC 294 2016-03-23T15:50:13 *** wallet42 has joined #bitcoin-core-dev 295 2016-03-23T15:50:16 <jonasschnelli> Yes. No enc(auth()). Enc itself has no MITM protection. 296 2016-03-23T15:54:56 <wumpus> jonasschnelli: so encryption and authentication is optional per message? I think the latter is risky, can't a MITMer insert a non-authenticated message inside the stream? 297 2016-03-23T15:55:17 <wumpus> I think once authentication is initiated, every message should be authenticated 298 2016-03-23T15:55:22 <sipa> agree 299 2016-03-23T15:55:55 <wumpus> I'm not sure that should hold for encryption, though there is a point to do so: it makes traffic analysis harder, more haystack to search for needles in 300 2016-03-23T15:55:57 <jonasschnelli> wumpus: I'm not sure if it would make sense to encrypt blocks. Why would it be risky? 301 2016-03-23T15:56:15 <wumpus> jonasschnelli: yeah agreed 302 2016-03-23T15:56:58 <wumpus> jonasschnelli: but why would you not encrypt everything? 303 2016-03-23T15:57:05 <sipa> (i have not looked at your bips) i think it should be a single authentication+encryption extension that is either off or on; if the identity of the peer is not known, a randomly generated key is used, otherwise a known key is used 304 2016-03-23T15:57:24 <wumpus> jonasschnelli: (once encryption is established, I mean) 305 2016-03-23T15:57:33 <jonasschnelli> You could encrypt everything. Its just not a requirement in the BIP. It depends on the resources you have. 306 2016-03-23T15:57:54 <wumpus> resources for encryption decryption are neglible compared to block processing, even deserialization 307 2016-03-23T15:58:07 <jonasschnelli> Yes. I agree. 308 2016-03-23T15:58:36 <wumpus> and if you don't want to encrypt, fine, don't establish it, it's an optional extension :) 309 2016-03-23T15:58:50 <jonasschnelli> sipa: I have wrote two separate BIPs because auth could also make sense for non-encrypted coms. 310 2016-03-23T15:59:59 <sipa> jonasschnelli: if i would redesign bitcoin p2p it would always be authenticated and always encrypted 311 2016-03-23T16:00:07 <jonasschnelli> wumpus: Yes. It is probably bad if partial traffic will be unencrypted after enc-init. 312 2016-03-23T16:00:20 <sipa> yes, authentication without encryption is iseful 313 2016-03-23T16:00:25 *** supasonic has joined #bitcoin-core-dev 314 2016-03-23T16:00:41 <sipa> but if you're going through the trouble of proposing a change, i think you should immediately go all the way 315 2016-03-23T16:00:52 <jonasschnelli> sipa: Agree. But there is a problem with the identity management (MITM). 316 2016-03-23T16:01:23 <jonasschnelli> First time you connect to a trusted node, you might want to ensure it is the correct identity (preshared key over a different chan). 317 2016-03-23T16:01:39 <sipa> that problem always exists for authentivation 318 2016-03-23T16:01:46 <wumpus> jonasschnelli: yes, the same problem as ssh basically, you may want to verify the remote fingerprint 319 2016-03-23T16:01:53 <sipa> whether or not you make encryption mandatory is indepebdent 320 2016-03-23T16:02:08 <wumpus> right 321 2016-03-23T16:02:20 <jonasschnelli> wumpus: Yes. The enc BIP i wrote does verify the fingerprint (base58c(ripemd160(sha256(pubkey))). 322 2016-03-23T16:03:13 <jonasschnelli> Okay. I might want to add that to the BIP: once encryption is initialized, unencrypted traffic would lead to a disconnect and lost of the enc session. 323 2016-03-23T16:03:14 <wumpus> jonasschnelli: but that's somewhat of a UI issue, how to show the fingerprint and make the user verify it, before storing it 324 2016-03-23T16:03:32 <sipa> i'll read it later... the hardest problem imho is how do you not reveal your identity to those who do nkt already know it 325 2016-03-23T16:03:38 <sipa> *not 326 2016-03-23T16:03:50 <jonasschnelli> wumpus: Yes. I left that open in the BIP. Most easiest solution would be to just NOT connect if the fingerprint not matches the prev./prestored once 327 2016-03-23T16:03:51 *** wallet42 has quit IRC 328 2016-03-23T16:03:52 <wumpus> yes I think that makes sense: once the connection chooses encryption or authentication, all traffic from then on should stick to it 329 2016-03-23T16:04:02 *** wallet42 has joined #bitcoin-core-dev 330 2016-03-23T16:04:06 *** paveljanik has quit IRC 331 2016-03-23T16:04:10 <jonasschnelli> sipa: Yes. That is a different problem not addresses in the BIP(s) 332 2016-03-23T16:04:52 <jonasschnelli> sipa: You might also like the idea of the SHA256 context that hashes all the comms to identify missing ENC messages. 333 2016-03-23T16:04:52 <gmaxwell> jonasschnelli: I don't think it's a different problem, in that the wrong crypto design makes it impossible to avoid having both sides broadcasting a persistant identity. 334 2016-03-23T16:05:12 <wumpus> in any case props to jonasschnelli for starting work on this, I'm sure this won't be finalized in one day, but initiative matters 335 2016-03-23T16:06:16 <jonasschnelli> gmaxwell: I mean you could do the same as SSH does. Ask the user if when he first connect to a unknown node (fingerprint), store the fingerprint and warn/reject connecting to changed fingerprints. 336 2016-03-23T16:06:18 <sipa> yeah, i think we need this 337 2016-03-23T16:06:28 <sipa> jonasschnelli: that means a node must reveal its fingerprint 338 2016-03-23T16:06:34 <gmaxwell> jonasschnelli: that is the opposite of what we want. 339 2016-03-23T16:06:37 <sipa> that would lead to a trivial... eh... fingerprinting attack 340 2016-03-23T16:06:43 <jonasschnelli> But maybe there is some clever method to spread identities over Addrman? Not sure although. 341 2016-03-23T16:07:15 *** wallet42 has quit IRC 342 2016-03-23T16:07:18 <gmaxwell> jonasschnelli: what sipa and I are referring to is that we don't want bitcoin nodes sending data that distinguishes them (esp passively) from other nodes. 343 2016-03-23T16:07:19 <sipa> that's something i've suggested in the past, but i'm not sure anymore that's a good idea 344 2016-03-23T16:07:59 *** wallet42 has joined #bitcoin-core-dev 345 2016-03-23T16:08:04 <jonasschnelli> gmaxwell: right. Thats why I proposed only fingerprint possibilities to connecting node AFTER they have successfully authed. 346 2016-03-23T16:08:27 <sipa> how can you authenticate without knowing who you're authenticating to? 347 2016-03-23T16:08:41 <sipa> (i should shut up and read the bip) 348 2016-03-23T16:09:01 <jonasschnelli> sipa: the remote node would only reveal its identity if it accepts the auth (already know the pubkey / preshared). 349 2016-03-23T16:09:34 <jonasschnelli> sipa: remote node checks pubkey (might ask the node op. to allow access), then reveal its pubkey, etc. 350 2016-03-23T16:10:04 <jonasschnelli> Fingerprinting would only be possible for "authorized_peers". 351 2016-03-23T16:10:31 <jonasschnelli> BIP is here if you want to read it: https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/03/auth_enc?expand=1 352 2016-03-23T16:10:54 *** wallet42 has quit IRC 353 2016-03-23T16:17:57 *** fengling has joined #bitcoin-core-dev 354 2016-03-23T16:18:29 *** wallet42 has joined #bitcoin-core-dev 355 2016-03-23T16:18:39 *** wallet42 has joined #bitcoin-core-dev 356 2016-03-23T16:22:56 *** fengling has quit IRC 357 2016-03-23T16:25:15 *** wallet42 has quit IRC 358 2016-03-23T16:25:25 *** wallet42 has joined #bitcoin-core-dev 359 2016-03-23T16:27:04 *** wallet42 has quit IRC 360 2016-03-23T16:27:31 *** wallet42 has joined #bitcoin-core-dev 361 2016-03-23T16:31:14 *** alexuy has quit IRC 362 2016-03-23T16:31:16 *** wallet42 has quit IRC 363 2016-03-23T16:42:35 <GitHub198> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/09a079e6484a...e5c35119e967 364 2016-03-23T16:42:36 <GitHub198> bitcoin/master df9e923 JoÃ£o Barbosa: Fix lockunspents help message 365 2016-03-23T16:42:36 <GitHub198> bitcoin/master e5c3511 Wladimir J. van der Laan: Merge #7646: Fix lockunspent help message... 366 2016-03-23T16:42:40 <GitHub139> [bitcoin] laanwj closed pull request #7646: Fix lockunspent help message (master...support/fix-lockunspent-help-message) https://github.com/bitcoin/bitcoin/pull/7646 367 2016-03-23T16:50:16 *** fengling has joined #bitcoin-core-dev 368 2016-03-23T16:51:25 *** alexuy has joined #bitcoin-core-dev 369 2016-03-23T16:59:02 *** wallet42 has joined #bitcoin-core-dev 370 2016-03-23T17:00:06 <cfields> jonasschnelli: not sure i discussed in the conversation above, but it's not clear from your BIP if the auth message carries the typical message header as well 371 2016-03-23T17:00:47 <cfields> (as a prefix i mean, in addition to the wrapped one) 372 2016-03-23T17:06:49 *** wallet42 has quit IRC 373 2016-03-23T17:07:39 *** Chris_Stewart_5 has quit IRC 374 2016-03-23T17:10:18 *** Tasoshi has joined #bitcoin-core-dev 375 2016-03-23T17:27:43 *** murch has joined #bitcoin-core-dev 376 2016-03-23T17:29:29 *** Chris_Stewart_5 has joined #bitcoin-core-dev 377 2016-03-23T18:02:54 *** Don_John has joined #bitcoin-core-dev 378 2016-03-23T18:04:38 *** mrkent has joined #bitcoin-core-dev 379 2016-03-23T18:04:41 *** Don_John has quit IRC 380 2016-03-23T18:12:33 *** jannes has quit IRC 381 2016-03-23T18:22:53 *** jtimon has quit IRC 382 2016-03-23T18:22:56 *** fengling has quit IRC 383 2016-03-23T18:27:32 <gmaxwell> jonasschnelli: I would normally expect this to work so that evey (supporting) conenction was mac/encrypted with ephemeral keys; and then inside that channel, varrious bits of authentiction may or may not happen. This way that even if the auth is deanonymizing it would only be so for an acive attacker; also all communication then ends up private from a global passive observer, even if there are n 384 2016-03-23T18:27:38 <gmaxwell> o auth credientials available. 385 2016-03-23T18:30:45 <gmaxwell> as far as the auth goes, I think for bitcoin symmetric mutual auth is not really a perfect fit; -- often the connection-accepting side wants to know that their resources are not being wasted by sybils, but don't really care who it is otherwise... and clients want to know they're talking to the host they expect, but really don't want it to know who they are. The exception is basically when you 386 2016-03-23T18:30:51 <gmaxwell> have your own trusted peers, in which case symmetric auth is probably fine. 387 2016-03-23T18:33:35 *** frankenmint has joined #bitcoin-core-dev 388 2016-03-23T18:42:35 *** frankenmint has quit IRC 389 2016-03-23T18:45:12 *** asdfdsas has joined #bitcoin-core-dev 390 2016-03-23T18:45:15 <jonasschnelli> cfields: hmm... IIRC I wrote in both bips that the wrapped messages also contains the HDR. 391 2016-03-23T18:45:53 *** alexuy has quit IRC 392 2016-03-23T18:46:00 <cfields> jonasschnelli: yes, but it's not clear if that's in addition to, or instead of, the normal header 393 2016-03-23T18:46:14 * jonasschnelli is processing gmaxwell answer (takes couple of minutes) 394 2016-03-23T18:46:39 <jonasschnelli> cfields: thanks... will clarify that in the BIP. 395 2016-03-23T18:46:43 *** fanatid has joined #bitcoin-core-dev 396 2016-03-23T18:47:24 <cfields> jonasschnelli: note that imo if the answer is "instead of", that would likely be an issue 397 2016-03-23T18:47:53 *** frankenmint has joined #bitcoin-core-dev 398 2016-03-23T18:49:11 <jonasschnelli> cfields: both messages (container and the wrapped message) would have valid message headers. This would make sense I guess? 399 2016-03-23T18:49:32 <cfields> jonasschnelli: perfect, thanks for clarifying :) 400 2016-03-23T18:49:46 *** frankenmint has quit IRC 401 2016-03-23T18:50:15 *** laurentmt has joined #bitcoin-core-dev 402 2016-03-23T18:51:58 <sipa> jonasschnelli: i would expect any authentication information to be sent instead of the 4-byte checksum there is now 403 2016-03-23T18:52:44 <jonasschnelli> sipa: Yes. But IMO its most straightforward to wrap an existing command. No changes in the message / header processing would be required. 404 2016-03-23T18:53:08 <jonasschnelli> The "enc" message wrapper would provide the encryption checksum (for AES IV). 405 2016-03-23T18:54:08 <sipa> that's oretty inefficient 406 2016-03-23T18:54:52 <jonasschnelli> sipa: You mean the message wrapper approach? Its basically a "header" for the message-with-a-header... 407 2016-03-23T18:54:55 <cfields> sipa: i was thinking the same thing 408 2016-03-23T18:55:24 <jonasschnelli> I kinda like the wrapping approach. It reflects and optional encryption layer. 409 2016-03-23T18:55:49 <sipa> and it's abit naive to think you don't need tovchange existing procesng; you're not going to implement encryptiin for every command separately anyway, so you'll want to do it generically 410 2016-03-23T18:55:53 *** dgenr8 has quit IRC 411 2016-03-23T18:55:53 <jonasschnelli> And does resect an easy implementation (not sure if this is an argument though) 412 2016-03-23T18:56:01 <gmaxwell> it results in lots of digital signatures, which is very slow. 413 2016-03-23T18:56:07 <sipa> (sorry for typing, edge) 414 2016-03-23T18:56:15 *** achow101 has quit IRC 415 2016-03-23T18:56:16 <cfields> sipa: hmm actually though, that means 2 possible header sizes. that's kinda nasty for parsing 416 2016-03-23T18:56:25 *** dgenr8 has joined #bitcoin-core-dev 417 2016-03-23T18:56:28 <jonasschnelli> No... 418 2016-03-23T18:56:48 <jonasschnelli> You have a message type "enc" that has a data set that contain a "normal" message (lets say a "version" message). 419 2016-03-23T18:56:57 <sipa> cfields: implement it as a layer in between tcp and messages 420 2016-03-23T18:57:00 <sipa> ? 421 2016-03-23T18:57:34 <jonasschnelli> The "enc" message has its own normal message p2p header, then some encryption relevant data (hash / iv, maybe the same), then the wrappen "version" message header&data. 422 2016-03-23T18:57:36 <cfields> sipa: could do, sure, but i'm not sure it's worth the added complexity? 423 2016-03-23T18:58:13 <jonasschnelli> So you could pare the enc message with the standard process message function, then decrypt, and process the wrapped command with the same logic. 424 2016-03-23T18:58:23 <gmaxwell> cfields: what sipa suggests seems most natural to me, you could think of it is a secure socket layer. 425 2016-03-23T18:59:31 <sipa> jonasschnelli: so an inv becomes goes from 60 bytes to 112 bytes? 426 2016-03-23T18:59:38 *** fengling has joined #bitcoin-core-dev 427 2016-03-23T18:59:54 <jonasschnelli> I have also though about adding the encryption on a different layer But, because I also want to do the implementation, I was looking for something that can be implemented easily. 428 2016-03-23T19:00:00 <sipa> or if you add a digital signature, 33 even more 429 2016-03-23T19:00:15 <jonasschnelli> sipa: Yes. That's why I though enc should be optional by message. 430 2016-03-23T19:00:30 <jonasschnelli> We could remove the message header from the submessage though. 431 2016-03-23T19:00:47 <sipa> jonasschnelli: as i said, i disagree with that- ideally we move to a form where everything is just encrypted imho 432 2016-03-23T19:00:49 <jonasschnelli> sipa: enc does not use DSA. Auth does. 433 2016-03-23T19:01:02 <sipa> well yes, but you shoukd have both 434 2016-03-23T19:01:06 <sipa> *should 435 2016-03-23T19:01:21 <jonasschnelli> You mean signing the encrypted message? 436 2016-03-23T19:01:41 <gmaxwell> jonasschnelli: the way you're doing authentication provides both authentication and non-repudiation. The latter is sometimes useful, but usually not--- the cost of it though is a really massive overhead compared to plain authentication. 437 2016-03-23T19:01:43 <cfields> gmaxwell: hmm, seems jonasschnelli and I are thinking in terms of individual opt-in messages, and you and sipa are thinking in terms of the entire stream. 438 2016-03-23T19:01:59 <sipa> i'm fine with doing it per message 439 2016-03-23T19:02:04 <sipa> that's certainly easier 440 2016-03-23T19:02:11 <sipa> but it shouldn't have such high overhead 441 2016-03-23T19:02:42 <gmaxwell> cfields: working with the entire stream makes it easier to avoid attacks from selective dropping and replay. 442 2016-03-23T19:02:49 <jonasschnelli> sipa: I agree. We might want to optimize the overhead. 443 2016-03-23T19:03:47 <gmaxwell> and doing a dsa verify per message would be a noticible CPU load... and provides no particular value over a more traditional authentication scheme. 444 2016-03-23T19:03:50 <jonasschnelli> Somehow i kinda likes to dual approach (encrypted and unencrypted messages) because of its CPU and bandwidth optimizations. I don't see a big value in encrypting blocks. 445 2016-03-23T19:04:09 <jonasschnelli> gmaxwell: Right. I only proposes DSA for a one-time-auth to initiate the enc. 446 2016-03-23T19:04:22 <sipa> jonasschnelli: using the more private approach shouldn't be more expensive :) 447 2016-03-23T19:04:28 <jonasschnelli> auth is stateless (no session), enc initiate a session. 448 2016-03-23T19:04:39 <sipa> jonasschnelli: encryption does not provide authenticity 449 2016-03-23T19:04:46 <gmaxwell> Also one gain of an encrypted transport would be being able to reduce network attack surface to just 'trusted' peers, which mixing things cannot achieve. 450 2016-03-23T19:04:53 <sipa> you *need* authentication for all data sent 451 2016-03-23T19:05:12 <sipa> otherwise there may he attacks where an attacker modifies the stream 452 2016-03-23T19:05:24 <jonasschnelli> sipa: For that purpose i have added the SHA256 context that starts with the authentication response. 453 2016-03-23T19:05:47 * jonasschnelli needs to go afk soon. 454 2016-03-23T19:05:54 <gmaxwell> jonasschnelli: standard encrypted transport, if done with a fast cipher/authentication can run with near memcpy speeds, it wouldn't necessarily make more than a negligible performance impact. And eventually there should be no whole 'blocks' sent except for history catchup. 455 2016-03-23T19:06:20 <jonasschnelli> gmaxwell: +1 agree. 456 2016-03-23T19:06:45 <jonasschnelli> Well,.. right. Once encryption is initiated it should cover everything. Agree. 457 2016-03-23T19:07:00 <jonasschnelli> I try to find a more optimized message format (wrapper) 458 2016-03-23T19:07:36 <jonasschnelli> but mind sipas contant time AES pr. :) 459 2016-03-23T19:09:12 <gmaxwell> so, e.g. if we had something that initilized at handshake with ephemeral keys, then inside that identity-auth may or may not happen.-- so then a passive observer wouldn't even learn if you were using auth or not. (esp if where auth isn't used if we insert a dummy message of the same size) 460 2016-03-23T19:11:16 <jonasschnelli> gmaxwell: my enc proposal uses ephemeral keys (ECDH) and right, with preshared key, an observer would not notice the auth (only the enc). 461 2016-03-23T19:11:29 <gmaxwell> I'm not sure that we'd want to use AES for the normal connections; just because without hardware support, timing attack immune AES is not very fast. This is why chacha20-poly1305 is now in TLS and SSH; to be used on the many hosts where AES-GCM is slow. 462 2016-03-23T19:12:36 <sipa> typical advice to encrypt first, and then put a mac on the encrypted form 463 2016-03-23T19:12:46 <jonasschnelli> I need to go afk. Happy to discuss that more in detail later. Thanks for the feedback, also happy to get feedback on the bitcoin-dev mail. 464 2016-03-23T19:15:02 <gmaxwell> The encrypted structure you have is not MACed, so junk can be injected into the stream. Internally authed messages wouldn't suffer from that becuase they're signed... but this kind of structure ends up with attacks where you corrupt some data and then learn something about the content based on if the far end changes its behavior or not. 465 2016-03-23T19:20:52 <gmaxwell> One thing to keep in mind is that the word 'authenticate' has an overloaded meaning. It can mean the function of a keyed mac to make sure that the data is data created by someone knowing a particular secret. Or it can mean to establish that the party you are communicating with is the party you think you are (that there is no MITM). Sometimes we use some of the same tools for these things, usua 466 2016-03-23T19:20:52 <gmaxwell> lly not. 467 2016-03-23T19:20:52 <gmaxwell> so regardless of what is done with identity-authentication; the outer transport should be using authenticated-encryption, so that any corruption is immediately rejected before any further application processing which might reveal information about the state of the encrypted stream. 468 2016-03-23T19:20:52 <gmaxwell> amusingly, since we already use this sha256 based "checksum", a switch to an authenticated/encrypted transport might actually make the network communications faster. 469 2016-03-23T19:20:52 <gmaxwell> (if it were faster than the sha256) 470 2016-03-23T19:22:04 *** go1111111 has quit IRC 471 2016-03-23T19:32:29 *** fanatid has quit IRC 472 2016-03-23T19:33:03 <cfields> gmaxwell: heh, good point 473 2016-03-23T19:33:51 *** go1111111 has joined #bitcoin-core-dev 474 2016-03-23T19:34:56 *** fengling has quit IRC 475 2016-03-23T19:51:39 *** frankenmint has joined #bitcoin-core-dev 476 2016-03-23T19:52:01 *** Thireus has quit IRC 477 2016-03-23T19:52:38 *** Thireus has joined #bitcoin-core-dev 478 2016-03-23T19:56:43 *** frankenmint has quit IRC 479 2016-03-23T20:02:40 *** gevs has quit IRC 480 2016-03-23T20:03:17 *** fengling has joined #bitcoin-core-dev 481 2016-03-23T20:19:07 *** laurentmt has quit IRC 482 2016-03-23T20:28:46 *** achow101 has joined #bitcoin-core-dev 483 2016-03-23T20:35:39 *** d_t has joined #bitcoin-core-dev 484 2016-03-23T20:41:22 *** PRab has quit IRC 485 2016-03-23T20:42:58 *** PRab has joined #bitcoin-core-dev 486 2016-03-23T20:53:08 *** frankenmint has joined #bitcoin-core-dev 487 2016-03-23T20:58:39 *** frankenmint has quit IRC 488 2016-03-23T22:08:08 *** Guyver2 has quit IRC 489 2016-03-23T22:25:06 *** rubensayshi has quit IRC 490 2016-03-23T22:27:04 *** rubensayshi has joined #bitcoin-core-dev 491 2016-03-23T22:31:17 *** droark has joined #bitcoin-core-dev 492 2016-03-23T22:32:03 *** d_t has quit IRC 493 2016-03-23T22:41:36 *** fengling has quit IRC 494 2016-03-23T22:42:58 *** paveljanik has joined #bitcoin-core-dev 495 2016-03-23T23:01:13 *** shesek has quit IRC 496 2016-03-23T23:04:22 *** Don_John has joined #bitcoin-core-dev 497 2016-03-23T23:05:18 *** zooko has joined #bitcoin-core-dev 498 2016-03-23T23:05:37 *** sipa has quit IRC 499 2016-03-23T23:05:44 *** sipa has joined #bitcoin-core-dev 500 2016-03-23T23:06:08 *** sipa is now known as Guest93735 501 2016-03-23T23:06:12 *** Guest93735 has joined #bitcoin-core-dev 502 2016-03-23T23:06:24 *** Guest93735 is now known as sipax 503 2016-03-23T23:10:45 *** fengling has joined #bitcoin-core-dev 504 2016-03-23T23:14:06 *** zooko has quit IRC 505 2016-03-23T23:16:37 *** BCB has joined #bitcoin-core-dev 506 2016-03-23T23:17:59 <BCB> Any idea why bitcoin 0.12 would be disconnection from an ipv6 addy with "socket recv error Connection reset by peer (104)" after receiving pong message 507 2016-03-23T23:20:10 *** AaronvanW has quit IRC 508 2016-03-23T23:22:40 <sipax> BCB: the only reason can be that the network layer actually returned a "Connection reset by peer" error... 509 2016-03-23T23:23:06 <sipax> the most likely reason for which is that the remote side actually disconnected 510 2016-03-23T23:23:40 <BCB> sipax: what is the x in your nic? 511 2016-03-23T23:24:17 <BCB> sipax so the remote side will just reconnect? 512 2016-03-23T23:24:57 <sipax> i don't know whether it will; only that based on the information you've given me, it seems that it does 513 2016-03-23T23:26:15 *** paveljanik has quit IRC 514 2016-03-23T23:27:09 *** frankenmint has joined #bitcoin-core-dev 515 2016-03-23T23:28:21 <gmaxwell> hm. so I have a node that was offline for a week throwing "Bitcoin is downloading blocks" -- it's not caught up, and yet it shows no blocks inflight on any peers 516 2016-03-23T23:28:28 <BCB> * looks at logs 517 2016-03-23T23:28:50 <gmaxwell> and synced_blocks/synced_headers is -1 on every peer. 518 2016-03-23T23:29:00 <sipax> gmaxwell: how long has the node been up? 519 2016-03-23T23:29:18 <gmaxwell> 45 minutes. 520 2016-03-23T23:29:31 <gmaxwell> oh sorry 15 minutes 521 2016-03-23T23:30:12 <sipax> i've seen that before, but it always resolved itself 522 2016-03-23T23:30:24 <gmaxwell> first connection was 23:15:25. 523 2016-03-23T23:31:08 <gmaxwell> and this is a checkout of 0.12 from a few minutes before it started. 524 2016-03-23T23:31:24 <sipax> wait until there's been a new block 525 2016-03-23T23:31:53 <sipax> (we should still investigate, but if it resolves on itself on the first block, i'm not so worried) 526 2016-03-23T23:31:56 <gmaxwell> sure, I don't care if this particular host is delayed.. but what data would be useful to resolve the bug? 527 2016-03-23T23:32:17 <gmaxwell> I think I've been block inved while this was up. 528 2016-03-23T23:32:48 <sipax> was this after ending a reindex? 529 2016-03-23T23:32:59 <sipax> or maybe a lengthy activating best chain? 530 2016-03-23T23:33:10 <gmaxwell> no. host cleanly shut itself down a week ago due to out of space (my debug lot made it to >100GB) 531 2016-03-23T23:33:24 <gmaxwell> it came up, connected two block, 532 2016-03-23T23:34:04 <gmaxwell> (402971 and 402972) and then hasn't made progress. 533 2016-03-23T23:34:19 <gmaxwell> 2016-03-23 23:20:48 got inv: block 000000000000000000342cb0954d2b28c5c41fe0d1afa6a262ac0cef29394c28 new peer=21 534 2016-03-23T23:34:22 <gmaxwell> 2016-03-23 23:20:48 sending: getheaders (997 bytes) peer=21 535 2016-03-23T23:34:25 <gmaxwell> 2016-03-23 23:20:48 getheaders (402972) 000000000000000000342cb0954d2b28c5c41fe0d1afa6a262ac0cef29394c28 to peer=21 536 2016-03-23T23:35:44 <gmaxwell> looks like that peer may have not responded to that getheaders. 537 2016-03-23T23:36:22 <gmaxwell> that peer claims 538 2016-03-23T23:36:26 <gmaxwell> "subver": "/Satoshi:0.11.2/", 539 2016-03-23T23:36:30 <gmaxwell> "startingheight": 402972, 540 2016-03-23T23:36:55 <gmaxwell> which is my height, my guess is that it's a fake node that just reflects whatever my starting height is. 541 2016-03-23T23:38:36 *** fengling has quit IRC 542 2016-03-23T23:39:08 <gmaxwell> and just ignored the getheaders request. 543 2016-03-23T23:40:47 *** gevs has joined #bitcoin-core-dev 544 2016-03-23T23:41:21 <BCB> gmaxwell: won't a misbehaving node be disconnected? 545 2016-03-23T23:42:22 <sipax> BCB: in some cases where it's detectable... 546 2016-03-23T23:42:30 <gmaxwell> BCB: impossible. _some_ kinds of very specific, detectable misbehavior will get things disconnected; but other kinds cannot be reliably detected. 547 2016-03-23T23:43:11 <BCB> what's the ip 548 2016-03-23T23:44:10 <gmaxwell> sipax: okay the initial wedge is because the first thing to connect to my node was my local p2pool daemon, which can't usefully reply 549 2016-03-23T23:44:13 <gmaxwell> 2016-03-23 23:15:25 initial getheaders (402971) to peer=1 (startheight:0) 550 2016-03-23T23:44:55 <gmaxwell> the wedge would have resolved when peer=21 offered me that block, but peer=21 didn't reply to the getheaders (as I'm in IBD, and so headers fetched instead of pulling it) 551 2016-03-23T23:45:44 <gmaxwell> so someone with a fake node that relays blocks but doesn't conform to the protocol more generally seems to be unintentionally prolonging the wedge. I expect it will resolve when another peer offers me a block first. 552 2016-03-23T23:59:17 <gmaxwell> as predicted, it unwedged.