--- Day changed Wed Mar 23 2016
00:02 < sipa> in retrospect, maybe we could have added length restrictions
00:02 < sipa> but it doesn't matter much, and the rules are as they are
00:02 < fanatid> sipa: thank you, can you paste answer in github issue? (or I can do this, if you busy)
00:03 < 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
00:07 < 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
00:07 < sipa> fanatid: there was some discussion about this precise issue before, i think
00:07 < sipa> fanatid: probably on the ML or the BIP pr itself
00:22 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ugudpesafeyuugnw] has joined #bitcoin-core-dev
00:48 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has quit [Ping timeout: 250 seconds]
01:02 < GitHub82> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c946a15075ba...490064111f86
01:02 < GitHub82> bitcoin/master bb16c88 João Barbosa: Prevent multiple calls to CWallet::AvailableCoins
01:02 < GitHub82> bitcoin/master 4900641 Wladimir J. van der Laan: Merge #7649: Prevent multiple calls to CWallet::AvailableCoins...
01:02 < 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
01:03 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
01:04 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
01:09 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 260 seconds]
01:15 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
01:16 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
01:41 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
01:42 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
01:58 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
01:58 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
02:09 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:41 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
02:59 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:09 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Remote host closed the connection]
03:28 < wumpus> I'm shocked how many people still use windows xp, and even run bitcoin nodes on it
03:29 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
03:30 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
03:32 < ajweutr> I'm shocked how many people still use windows.
03:33 < wumpus> well okay but how can you rationalize running internet-connected software on something that will get no security updates anymore
03:36 < sipa> running internet-connected *wallet* software
03:36 < wumpus> it's like signing a general 'yes I want to be part of your botnet' waiver
03:36 < wumpus> well they claim not to use the wallet
03:38 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
03:43 < btcdrak> wumpus: there are hundreds of thousands of ATMs around the world still running Windows XP...
03:44 < wumpus> absurd
03:50 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
03:57 < Luke-Jr> wumpus: as if a node has any value besides security
04:06 < 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
04:08 < sipa> in other news: i now run bitcoin core on my phonr
04:09 < sipa> *phone
04:15 < btcdrak> wumpus: given that XP has been EOL for years now, should we be supporting it at all? Basically, the OS is insecure.
04:15 < btcdrak> sipa: are you using Abcore?
04:17 < sipa> btcdrak: yeah
04:20 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 244 seconds]
04:32 -!- btcdrak is now known as intdrak
04:33 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
04:41 < wumpus> sipa: cool :)
04:41 < 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
04:42 < 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.
04:47 -!- dermoth [~thomas@dsl-216-221-53-213.mtl.contact.net] has quit [Read error: Connection reset by peer]
04:47 < 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
04:47 -!- dermoth [~thomas@dsl-216-221-53-213.mtl.contact.net] has joined #bitcoin-core-dev
04:59 < 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.
04:59 < intdrak> wumpus: sauce http://www.ryanvm.net/forum/viewtopic.php?t=10321
05:02 < wumpus> in any case I didn't even give a date or milestone, and still people reply like that
05:03 < wumpus> a third party releasing a service pack? seems legit...
05:03 < sipa> wumpus: it's two people...
05:03 -!- fanatid [~fanatid@ppp85-140-2-95.pppoe.mtu-net.ru] has quit [Quit: Leaving.]
05:06 < wumpus> yeah...
05:07 < 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
05:09 < 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
05:12 < intdrak> wumpus: I think your response is reasonable: try to fix it now, and remove support from 0.13 in any case.
05:13 < intdrak> and if it cant be fixed, too bad.
05:14 < GitHub138> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/490064111f86...909b72b10b4d
05:14 < GitHub138> bitcoin/master 5fd2318 fanquake: [Depends] Miniupnpc 1.9.20160209...
05:14 < GitHub138> bitcoin/master c85f475 fanquake: [Depends] Latest config.guess & config.sub
05:14 < GitHub138> bitcoin/master 909b72b Wladimir J. van der Laan: Merge #7710: [Depends] Bump miniupnpc and config.guess+sub...
05:14 < GitHub55> [bitcoin] laanwj closed pull request #7710: [Depends] Bump miniupnpc and config.guess+sub (master...depends-02) https://github.com/bitcoin/bitcoin/pull/7710
05:17 < wumpus> right
05:25 < GitHub116> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/909b72b10b4d...e2ebd259fbe8
05:25 < GitHub116> bitcoin/master fe00ca7 Andrew C: Create generatetoaddress rpc...
05:25 < GitHub116> bitcoin/master d5c5c71 Andrew C: RPC tests for generatetoaddress...
05:25 < GitHub116> bitcoin/master e2ebd25 Wladimir J. van der Laan: Merge #7671: [RPC] Add generatetoaddress rpc to mine to an address...
05:25 < 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
05:25 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
05:29 < Luke-Jr> intdrak: is "3rd party unofficial support" significantly different from a Linux distro fork in this regard?
05:29 < Luke-Jr> (not that I think we need to support XP. if nobody cares enough to fix it, it can go bye-bye)
05:29 < sipa> Luke-Jr: that's a good point
05:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:30 < wumpus> did they legally take over the support from microsoft?
05:30 < wumpus> if so, I suppose it's comparable, if not, it's something completely different
05:30 < 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
05:31 < wumpus> in any case it isn't any reason to influence our decision about supporting it or not
05:31 < wumpus> someone needs to step up to support it, if not, it's done
05:31 < Luke-Jr> sipa: they can't identify unfixed bugs maybe, but they could in theory backport or identify unbackportable stuff
05:32 < Luke-Jr> wumpus: from a security perspective, I don't know why the legalities would matter. but I agree it isn't very relevant.
05:33 < wumpus> Luke-Jr: well I think from a security perspective, for a closed source OS, microsoft's blessing is very imporant. 
05:34 < 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
05:35 < 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
05:36 < 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
05:36 < 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
05:37 < wumpus> you can't really continue someone elses' development with closed source software... or what, reverse engineer, use a hex editor?
05:37 < sipa> windows unsupported probably means that there are components in the OS on which _nobody_ is even working anymore
05:38 < wumpus> would you claim that makes *no* difference from a security perspective?
05:54 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
06:15 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
06:31 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
06:35 < 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.
06:35 < 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?
06:36 < wumpus> I don't have an answer to that, unfortunately
06:36 < wumpus> getting people to review things is very hard
06:37 < wumpus> you could try spamming it here a few times, or on twitter, or wherever
06:38 < wumpus> ideally, people that care about backports at all would spend work reviewing what is backported to their favorite version
06:38 < 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)
06:39 < wumpus> sure, you can always @ people and ping them in the PR
06:42 < wumpus> it tends to work
06:43 < instagibbs> morcos, asking *specific* people probably works better
06:43 < instagibbs> "Someone call 911" vs "You call 911"
06:44 < instagibbs> (911 being US emergency number)
06:50 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
06:50 -!- d_t [~textual@212.144.253.35] has joined #bitcoin-core-dev
06:54 < 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.
06:54 < sipa> yes, i agree that in practice is completely different
06:55 -!- d_t [~textual@212.144.253.35] has quit [Ping timeout: 248 seconds]
06:55 < 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
06:56 < wumpus> any linux distribution worth its salt at least has security upgrades
06:58 < sipa> yes, agree completely - i was just arguing semantics
06:58 < sipa> sorry :)
06:58 < intdrak> morcos: I have been hassling people in private to do reviews. I'll go bang on a few more doors
07:00 < 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
07:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:06 -!- alexuy [~alexuy@r167-61-93-173.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
07:08 -!- musalbas [~musalbas@2001:bc8:30c2::] has quit [Ping timeout: 250 seconds]
07:08 -!- lysobit [~musalbas@2001:bc8:30c2::] has quit [Ping timeout: 250 seconds]
07:08 -!- Taek42 [~quassel@2001:41d0:1:472e::] has joined #bitcoin-core-dev
07:09 -!- lesderid [~lesderid@anna.lesderid.net] has quit [Ping timeout: 250 seconds]
07:09 < GitHub144> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e2ebd259fbe8...3bdc583b3f07
07:09 < GitHub144> bitcoin/master 68d4282 Alex Morcos: Fix calculation of balances and available coins....
07:09 < GitHub144> bitcoin/master 3bdc583 Wladimir J. van der Laan: Merge #7715: Fix calculation of balances and available coins....
07:09 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Ping timeout: 250 seconds]
07:09 < GitHub191> [bitcoin] laanwj closed pull request #7715: Fix calculation of balances and available coins. (master...fixconflicts_take2) https://github.com/bitcoin/bitcoin/pull/7715
07:09 < wumpus> morcos: the other option, of course, is to just start merging stuff :)
07:09 -!- Taek [~quassel@2001:41d0:1:472e::] has quit [Ping timeout: 250 seconds]
07:12 < GitHub160> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/19866c1ffcb860bc2980e00e956685b9a8f96529
07:12 < GitHub160> bitcoin/0.12 19866c1 Alex Morcos: Fix calculation of balances and available coins....
07:12 < intdrak> I would assume the backports are relatively straightforward to review.
07:12 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
07:13 -!- intdrak is now known as btcdrak
07:13 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
07:13 -!- AdrianG_ [~User@107.170.31.78] has joined #bitcoin-core-dev
07:16 < 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
07:18 -!- sipa_ [~pw@2a02:348:86:3011::1] has joined #bitcoin-core-dev
07:18 -!- Aleph0 [~User@unaffiliated/amphetamine] has quit [Ping timeout: 240 seconds]
07:18 -!- lesderid_ [~lesderid@anna.lesderid.net] has joined #bitcoin-core-dev
07:19 < btcdrak> Well the PRs people need to review are #7648, #7543 and #7716
07:21 < 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
07:22 < sipa_> at google there was a policy that you pick an appropriate reviewer yourself
07:22 < btcdrak> hrm. offer a bounty and the winner is decided by the the merge commit hash :-P
07:22 < sipa_> btcdrak: you can grind commit hashes :p
07:23 < 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
07:24 < 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
07:24 < btcdrak> #7648 is pretty straight forward and it's got lots of RPC tests to verify behaviour.
07:24 < sipa_> wumpus: ouch!
07:25 < 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)
07:25 < wumpus> sipa_: just throwing out ideas I've seen in other projects, not saying it's a good idea :)
07:26 < 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
07:27 < btcdrak> I think the only solution is more staff.
07:28 < jonasschnelli> we could incentives reviews by adding btc-micropayment to contributors that commented a tested ACK (<githash> of later merged PR ... :) *duck*
07:29 < jonasschnelli> I'm pretty sure we would get a lot of (untested) tested ACKs
07:29 < btcdrak> yeah ^
07:29 < wumpus> jonasschnelli: yea you'd have to require an extensive testing report in that case, to be sure someone actually did the work
07:30 < btcdrak> need some kind of "proof of review, proof of test"
07:30 < wumpus> jonasschnelli: and that's probably not as far as people are willing to go for a micropayment :)
07:30 < jonasschnelli> wumpus: Right. He needs to calculate a sha256 of the random chosen words of the change source-code. :)
07:30 < 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
07:30 -!- sipa_ is now known as sipa
07:30 < 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
07:31 -!- sipa is now known as Guest7455
07:31 -!- Guest7455 is now known as sipax
07:31 -!- sipax [~pw@2a02:348:86:3011::1] has quit [Changing host]
07:31 -!- sipax [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev
07:33 < morcos> i think we should not treat all PR's equally
07:34 < morcos> for some PR's the lack of reviewers is the signal as to whether or not its somethign we want to merge
07:34 -!- lesderid_ is now known as lesderid
07:34 < 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
07:34 < morcos> its the second case that i think we need to work on
07:34 < 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*
07:34 < sipax> maybe we should try to have a deadline on concept ack/nacks
07:35 < morcos> i know for example that i'll sometimes get caught up in a streak of coding and not doing enough reviewing
07:35 < 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
07:35 < morcos> but what i don't want is every random PR for someone to assign it to me to review
07:36 < 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
07:36 < 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
07:36 < morcos> i dont know
07:37 < btcdrak> for #7648 how many reviewers do we need?
07:37 < 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
07:38 < wumpus> but for a backport it's not nearly as clear cut
07:39 < morcos> 7648 looks good at this point, and 7543 is fairly trivial if you trust 7648.  
07:39 < morcos> 7716 on the other hand is a problem.  the 0.11 backport.
07:39 < 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
07:39 < wumpus> yes #7648 looks good
07:40 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
07:40 < wumpus> btcdrak: you've introduced a new blockchain historical video media extension in #7648? *ducks* "BIP113 Media Time Past."
07:41 < morcos> my favorite is btcdrak's insistence on the acronym TDB
07:42 < helo> soon we will communicate using only acronyms <3
07:43 < sipax> ACK OR GTFO!
07:43 < wumpus> lol
07:45 < morcos> wumpus: would be nice to add first commit from https://github.com/bitcoin/bitcoin/pull/7707 as well, just commented on PR
07:46 < wumpus> morcos: sure, though usually we merge the master pull first before backporting anything
07:47 < btcdrak> wumpus: ahahaha
07:47 < 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..
07:47 < 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
07:47 < wumpus> yes good idea, I'll do that
07:47 < jonasschnelli> morcos, wumpus: should I open a PR with the non-gui oneliner against master and 0.12?
07:48 < wumpus> jonasschnelli: I was just going to do that, but sure go ahead :)
07:48 < jonasschnelli> okay... give me couple of minutes
07:50 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
07:51 < 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
07:51 < 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
07:51 < jonasschnelli> wumpus: done https://github.com/bitcoin/bitcoin/pull/7739 and https://github.com/bitcoin/bitcoin/pull/7740
07:58 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
07:59 < jonasschnelli> Anyone interested in reviewing my p2p-authentication and encryption BIP before submitting to the ML?
07:59 < jonasschnelli> https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/03/auth_enc?expand=1
08:21 -!- sipax is now known as sipa
08:22 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
08:25 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
08:30 < GitHub102> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3bdc583b3f07...09a079e6484a
08:30 < GitHub102> bitcoin/master 263de3d Jonas Schnelli: [Wallet][RPC] add abandoned status to listtransactions
08:30 < GitHub102> bitcoin/master 09a079e Wladimir J. van der Laan: Merge #7739: [Wallet][RPC] add abandoned status to listtransactions...
08:30 < 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
08:31 < GitHub170> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/7ffc2bd9439b2ad4da653583f7e57915980522a3
08:31 < GitHub170> bitcoin/0.12 7ffc2bd Jonas Schnelli: [Wallet][RPC] add abandoned status to listtransactions...
08:32 < 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
08:34 < wumpus> jonasschnelli: sure
08:38 -!- alexuy_ [~alexuy@r167-61-3-97.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
08:38 -!- alexuy [~alexuy@r167-61-93-173.dialup.adsl.anteldata.net.uy] has quit [Read error: Connection reset by peer]
08:38 -!- alexuy_ is now known as alexuy
08:41 < wumpus> jonasschnelli: you should also approach warren about this ,he was very interested in this, maybe he can drum op some more reviewers
08:42 < jonasschnelli> wumpus: Yes. He show interest at the conference in Cambridge. Ping warren.
08:44 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Read error: Connection reset by peer]
08:47 < 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)
08:48 < jonasschnelli> wumpus: Yes. I agree. But the authentication scheme is ECDSA bases. IMO the auth itself is encrypted.
08:48 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
08:49 < jonasschnelli> wumpus: and the proposed Auth does what "certificates" do in SSH. They ensure that the remote party sill possesses the private key (=identity).
08:49 < wumpus> jonasschnelli: ok, but I suppose you never have enc(auth( 
08:49 < wumpus> jonasschnelli: then it's good
08:50 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Remote host closed the connection]
08:50 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
08:50 < jonasschnelli> Yes. No enc(auth()). Enc itself has no MITM protection.
08:54 < 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?
08:55 < wumpus> I think once authentication is initiated, every message should be authenticated
08:55 < sipa> agree
08: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
08:55 < jonasschnelli> wumpus: I'm not sure if it would make sense to encrypt blocks. Why would it be risky?
08:56 < wumpus> jonasschnelli: yeah agreed
08:56 < wumpus> jonasschnelli: but why would you not encrypt everything?
08:57 < 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
08:57 < wumpus> jonasschnelli: (once encryption is established, I mean)
08:57 < jonasschnelli> You could encrypt everything. Its just not a requirement in the BIP. It depends on the resources you have.
08:57 < wumpus> resources for encryption decryption are neglible compared to block processing, even deserialization
08:58 < jonasschnelli> Yes. I agree.
08:58 < wumpus> and if you don't want to encrypt, fine, don't establish it, it's an optional extension :)
08:58 < jonasschnelli> sipa: I have wrote two separate BIPs because auth could also make sense for non-encrypted coms.
09:00 < sipa> jonasschnelli: if i would redesign bitcoin p2p it would always be authenticated and always encrypted
09:00 < jonasschnelli> wumpus: Yes. It is probably bad if partial traffic will be unencrypted after enc-init.
09:00 < sipa> yes, authentication without encryption is iseful
09:00 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
09:00 < sipa> but if you're going through the trouble of proposing a change, i think you should immediately go all the way
09:00 < jonasschnelli> sipa: Agree. But there is a problem with the identity management (MITM).
09:01 < 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).
09:01 < sipa> that problem always exists for authentivation
09:01 < wumpus> jonasschnelli: yes, the same problem as ssh basically, you may want to verify the remote fingerprint
09:01 < sipa> whether or not you make encryption mandatory is indepebdent
09:02 < wumpus> right
09:02 < jonasschnelli> wumpus: Yes. The enc BIP i wrote does verify the fingerprint (base58c(ripemd160(sha256(pubkey))).
09:03 < 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.
09:03 < wumpus> jonasschnelli: but that's somewhat of a UI issue, how to show the fingerprint and make the user verify it, before storing it
09:03 < 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
09:03 < sipa> *not
09:03 < 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
09:03 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Remote host closed the connection]
09:03 < wumpus> yes I think that makes sense: once the connection chooses encryption or authentication, all traffic from then on should stick to it
09:04 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
09:04 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
09:04 < jonasschnelli> sipa: Yes. That is a different problem not addresses in the BIP(s)
09:04 < jonasschnelli> sipa: You might also like the idea of the SHA256 context that hashes all the comms to identify missing ENC messages. 
09:04 < 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.
09:05 < 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
09:06 < 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.
09:06 < sipa> yeah, i think we need this
09:06 < sipa> jonasschnelli: that means a node must reveal its fingerprint
09:06 < gmaxwell> jonasschnelli: that is the opposite of what we want.
09:06 < sipa> that would lead to a trivial... eh... fingerprinting attack
09:06 < jonasschnelli> But maybe there is some clever method to spread identities over Addrman? Not sure although.
09:07 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Remote host closed the connection]
09:07 < 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.
09:07 < sipa> that's something i've suggested in the past, but i'm not sure anymore that's a good idea
09:08 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
09:08 < jonasschnelli> gmaxwell: right. Thats why I proposed only fingerprint possibilities to connecting node AFTER they have successfully authed.
09:08 < sipa> how can you authenticate without knowing who you're authenticating to?
09:08 < sipa> (i should shut up and read the bip)
09:09 < jonasschnelli> sipa: the remote node would only reveal its identity if it accepts the auth (already know the pubkey / preshared).
09:09 < jonasschnelli> sipa: remote node checks pubkey (might ask the node op. to allow access), then reveal its pubkey, etc.
09:10 < jonasschnelli> Fingerprinting would only be possible for "authorized_peers".
09:10 < jonasschnelli> BIP is here if you want to read it: https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/03/auth_enc?expand=1
09:10 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Remote host closed the connection]
09:17 -!- fengling [~fengling@2002:6fc6:1d35:0:7138:dd06:6349:cf79] has joined #bitcoin-core-dev
09:18 -!- wallet42 [~wallet42@5.9.25.103] has joined #bitcoin-core-dev
09:18 -!- wallet42 [~wallet42@5.9.25.103] has quit [Changing host]
09:18 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
09:22 -!- fengling [~fengling@2002:6fc6:1d35:0:7138:dd06:6349:cf79] has quit [Ping timeout: 240 seconds]
09:25 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Remote host closed the connection]
09:25 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
09:27 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Remote host closed the connection]
09:27 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
09:31 -!- alexuy [~alexuy@r167-61-3-97.dialup.adsl.anteldata.net.uy] has quit [Quit: alexuy]
09:31 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Remote host closed the connection]
09:42 < GitHub198> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/09a079e6484a...e5c35119e967
09:42 < GitHub198> bitcoin/master df9e923 João Barbosa: Fix lockunspents help message
09:42 < GitHub198> bitcoin/master e5c3511 Wladimir J. van der Laan: Merge #7646: Fix lockunspent help message...
09:42 < GitHub139> [bitcoin] laanwj closed pull request #7646: Fix lockunspent help message (master...support/fix-lockunspent-help-message) https://github.com/bitcoin/bitcoin/pull/7646
09:50 -!- fengling [~fengling@2002:6fc6:1d35:0:7138:dd06:6349:cf79] has joined #bitcoin-core-dev
09:51 -!- alexuy [~alexuy@r167-61-3-97.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
09:59 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
10:00 < 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
10:00 < cfields> (as a prefix i mean, in addition to the wrapped one)
10:06 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Ping timeout: 240 seconds]
10:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
10:10 -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has joined #bitcoin-core-dev
10:27 -!- murch [~murch@p4FE39D4F.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
10:29 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev
11:02 -!- Don_John [~Don@249-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev
11:04 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
11:04 -!- Don_John [~Don@249-223-114-134.nat.resnet.nau.edu] has quit [Read error: Connection reset by peer]
11:12 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
11:22 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection]
11:22 -!- fengling [~fengling@2002:6fc6:1d35:0:7138:dd06:6349:cf79] has quit [Ping timeout: 240 seconds]
11:27 < 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
11:27 < gmaxwell> o auth credientials available.
11:30 < 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 
11:30 < gmaxwell> have your own trusted peers, in which case symmetric auth is probably fine. 
11:33 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
11:42 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
11:45 -!- asdfdsas [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev
11:45 < jonasschnelli> cfields: hmm... IIRC I wrote in both bips that the wrapped messages also contains the HDR.
11:45 -!- alexuy [~alexuy@r167-61-3-97.dialup.adsl.anteldata.net.uy] has quit [Quit: alexuy]
11:46 < cfields> jonasschnelli: yes, but it's not clear if that's in addition to, or instead of, the normal header
11:46  * jonasschnelli is processing gmaxwell answer (takes couple of minutes)
11:46 < jonasschnelli> cfields: thanks... will clarify that in the BIP.
11:46 -!- fanatid [~fanatid@ppp85-140-2-63.pppoe.mtu-net.ru] has joined #bitcoin-core-dev
11:47 < cfields> jonasschnelli: note that imo if the answer is "instead of", that would likely be an issue
11:47 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
11:49 < jonasschnelli> cfields: both messages (container and the wrapped message) would have valid message headers. This would make sense I guess?
11:49 < cfields> jonasschnelli: perfect, thanks for clarifying :)
11:49 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
11:50 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
11:51 < sipa> jonasschnelli: i would expect any authentication information to be sent instead of the 4-byte checksum there is now
11:52 < jonasschnelli> sipa: Yes. But IMO its most straightforward to wrap an existing command. No changes in the message / header processing would be required.
11:53 < jonasschnelli> The "enc" message wrapper would provide the encryption checksum (for AES IV).
11:54 < sipa> that's oretty inefficient
11:54 < jonasschnelli> sipa: You mean the message wrapper approach? Its basically a "header" for the message-with-a-header... 
11:54 < cfields> sipa: i was thinking the same thing
11:55 < jonasschnelli> I kinda like the wrapping approach. It reflects and optional encryption layer.
11:55 < 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
11:55 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 250 seconds]
11:55 < jonasschnelli> And does resect an easy implementation (not sure if this is an argument though)
11:56 < gmaxwell> it results in lots of digital signatures, which is very slow. 
11:56 < sipa> (sorry for typing, edge)
11:56 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Ping timeout: 244 seconds]
11:56 < cfields> sipa: hmm actually though, that means 2 possible header sizes. that's kinda nasty for parsing
11:56 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
11:56 < jonasschnelli> No...
11:56 < jonasschnelli> You have a message type "enc" that has a data set that contain a "normal" message (lets say a "version" message).
11:56 < sipa> cfields: implement it as a layer in between tcp and messages
11:57 < sipa> ?
11:57 < 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.
11:57 < cfields> sipa: could do, sure, but i'm not sure it's worth the added complexity?
11:58 < 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.
11:58 < gmaxwell> cfields: what sipa suggests seems most natural to me, you could think of it is a secure socket layer.
11:59 < sipa> jonasschnelli: so an inv becomes goes from 60 bytes to 112 bytes?
11:59 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
11:59 < 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. 
12:00 < sipa> or if you add a digital signature, 33 even more
12:00 < jonasschnelli> sipa: Yes. That's why I though enc should be optional by message.
12:00 < jonasschnelli> We could remove the message header from the submessage though.
12:00 < sipa> jonasschnelli: as i said, i disagree with that- ideally we move to a form where everything is just encrypted imho
12:00 < jonasschnelli> sipa: enc does not use DSA. Auth does.
12:01 < sipa> well yes, but you shoukd have both
12:01 < sipa> *should
12:01 < jonasschnelli> You mean signing the encrypted message?
12:01 < 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.
12:01 < 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.
12:02 < sipa> i'm fine with doing it per message
12:02 < sipa> that's certainly easier
12:02 < sipa> but it shouldn't have such high overhead
12:02 < gmaxwell> cfields: working with the entire stream makes it easier to avoid attacks from selective dropping and replay. 
12:02 < jonasschnelli> sipa: I agree. We might want to optimize the overhead.
12:03 < 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.
12:03 < 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.
12:04 < jonasschnelli> gmaxwell: Right. I only proposes DSA for a one-time-auth to initiate the enc.
12:04 < sipa> jonasschnelli: using the more private approach shouldn't be more expensive :)
12:04 < jonasschnelli> auth is stateless (no session), enc initiate a session.
12:04 < sipa> jonasschnelli: encryption does not provide authenticity
12:04 < 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.
12:04 < sipa> you *need* authentication for all data sent
12:05 < sipa> otherwise there may he attacks where an attacker modifies the stream
12:05 < jonasschnelli> sipa: For that purpose i have added the SHA256 context that starts with the authentication response.
12:05  * jonasschnelli needs to go afk soon.
12:05 < 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.
12:06 < jonasschnelli> gmaxwell: +1 agree.
12:06 < jonasschnelli> Well,.. right. Once encryption is initiated it should cover everything. Agree.
12:07 < jonasschnelli> I try to find a more optimized message format (wrapper)
12:07 < jonasschnelli> but mind sipas contant time AES pr. :)
12:09 < 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)
12:11 < jonasschnelli> gmaxwell: my enc proposal uses ephemeral keys (ECDH) and right, with preshared key, an observer would not notice the auth (only the enc).
12:11 < 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.
12:12 < sipa> typical advice to encrypt first, and then put a mac on the encrypted form
12:12 < 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.
12:15 < 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.
12:16 < 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
12:16 < gmaxwell> lly not.
12:17 < 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.
12:18 < gmaxwell> amusingly, since we already use this sha256 based "checksum", a switch to an authenticated/encrypted transport might actually make the network communications faster.
12:18 < gmaxwell> (if it were faster than the sha256)
12:22 -!- go1111111 [~go1111111@104.232.116.217] has quit [Ping timeout: 264 seconds]
12:32 -!- fanatid [~fanatid@ppp85-140-2-63.pppoe.mtu-net.ru] has quit [Quit: Leaving.]
12:33 < cfields> gmaxwell: heh, good point
12:33 -!- go1111111 [~go1111111@104.200.154.72] has joined #bitcoin-core-dev
12:34 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
12:51 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
12:52 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
12:52 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
12:56 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 252 seconds]
13:02 -!- gevs [~greg@unaffiliated/gevs] has quit [Remote host closed the connection]
13:03 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
13:19 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
13:28 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
13:35 -!- d_t [~textual@212.144.253.35] has joined #bitcoin-core-dev
13:41 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Ping timeout: 260 seconds]
13:42 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
13:53 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
13:58 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 268 seconds]
15:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:25 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has quit [Ping timeout: 246 seconds]
15:27 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has joined #bitcoin-core-dev
15:31 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev
15:32 -!- d_t [~textual@212.144.253.35] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:41 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
15:43 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
16:01 -!- shesek [~shesek@bzq-84-110-33-184.cablep.bezeqint.net] has quit [Ping timeout: 240 seconds]
16:04 -!- Don_John [~Don@134.114.223.249] has joined #bitcoin-core-dev
16:05 -!- zooko [~user@2601:281:8001:26aa:bd9f:ffdd:1cad:8f0f] has joined #bitcoin-core-dev
16:05 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Ping timeout: 240 seconds]
16:05 -!- sipa [~pw@2a02:348:86:3011::1] has joined #bitcoin-core-dev
16:06 -!- sipa is now known as Guest93735
16:06 -!- Guest93735 [~pw@2a02:348:86:3011::1] has quit [Changing host]
16:06 -!- Guest93735 [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev
16:06 -!- Guest93735 is now known as sipax
16:10 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
16:14 -!- zooko [~user@2601:281:8001:26aa:bd9f:ffdd:1cad:8f0f] has quit [Ping timeout: 248 seconds]
16:16 -!- BCB [4241870d@gateway/web/freenode/ip.66.65.135.13] has joined #bitcoin-core-dev
16:18 < 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
16:20 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]
16:22 < sipax> BCB: the only reason can be that the network layer actually returned a "Connection reset by peer" error...
16:23 < sipax> the most likely reason for which is that the remote side actually disconnected
16:23 < BCB> sipax: what is the x in your nic?
16:24 < BCB> sipax so the remote side will just reconnect?
16:24 < sipax> i don't know whether it will; only that based on the information you've given me, it seems that it does
16:26 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
16:27 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
16:28 < 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
16:28 < BCB> * looks at logs
16:28 < gmaxwell> and synced_blocks/synced_headers is -1 on every peer.
16:29 < sipax> gmaxwell: how long has the node been up?
16:29 < gmaxwell> 45 minutes.
16:29 < gmaxwell> oh sorry 15 minutes
16:30 < sipax> i've seen that before, but it always resolved itself
16:30 < gmaxwell> first connection was 23:15:25.
16:31 < gmaxwell> and this is a checkout of 0.12 from a few minutes before it started.
16:31 < sipax> wait until there's been a new block
16:31 < sipax> (we should still investigate, but if it resolves on itself on the first block, i'm not so worried)
16:31 < gmaxwell> sure, I don't care if this particular host is delayed.. but what data would be useful to resolve the bug?
16:32 < gmaxwell> I think I've been block inved while this was up.
16:32 < sipax> was this after ending a reindex?
16:33 < sipax> or maybe a lengthy activating best chain?
16:33 < gmaxwell> no. host cleanly shut itself down a week ago due to out of space (my debug lot made it to >100GB)
16:33 < gmaxwell> it came up, connected two block,
16:34 < gmaxwell> (402971 and 402972) and then hasn't made progress.
16:34 < gmaxwell> 2016-03-23 23:20:48 got inv: block 000000000000000000342cb0954d2b28c5c41fe0d1afa6a262ac0cef29394c28  new peer=21
16:34 < gmaxwell> 2016-03-23 23:20:48 sending: getheaders (997 bytes) peer=21
16:34 < gmaxwell> 2016-03-23 23:20:48 getheaders (402972) 000000000000000000342cb0954d2b28c5c41fe0d1afa6a262ac0cef29394c28 to peer=21
16:35 < gmaxwell> looks like that peer may have not responded to that getheaders.
16:36 < gmaxwell> that peer claims 
16:36 < gmaxwell>     "subver": "/Satoshi:0.11.2/",
16:36 < gmaxwell>     "startingheight": 402972,
16:36 < gmaxwell> which is my height, my guess is that it's a fake node that just reflects whatever my starting height is.
16:38 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
16:39 < gmaxwell> and just ignored the getheaders request.
16:40 -!- gevs [~greg@ip-80-236-217-159.dsl.scarlet.be] has joined #bitcoin-core-dev
16:40 -!- gevs [~greg@ip-80-236-217-159.dsl.scarlet.be] has quit [Changing host]
16:40 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
16:41 < BCB> gmaxwell: won't a misbehaving node be disconnected?
16:42 < sipax> BCB: in some cases where it's detectable...
16:42 < gmaxwell> BCB: impossible.  _some_ kinds of very specific, detectable misbehavior will get things disconnected; but other kinds cannot be reliably detected.
16:43 < BCB> what's the ip
16:44 < 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
16:44 < gmaxwell> 2016-03-23 23:15:25 initial getheaders (402971) to peer=1 (startheight:0)
16:44 < 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)
16:45 < 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.
16:59 < gmaxwell> as predicted, it unwedged.
17:00 < gmaxwell> oh hmph. made some pgoress but stuck again. :(
17:01 < gmaxwell> now this looks like local corruption from running out of space. 2016-03-24 00:00:19 ERROR: ReadBlockFromDisk: OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)
17:01 < sipax> ugh!
17:02 < sipax> that means the block data wasn't written but the index entry for it was
17:02 < sipax> remind me to investigate the write order during flush in such a case
17:02  * sipax goes into standby mode
17:03 < gmaxwell> well it may have been out of space and the write could have failed. Our out of space handling is not so great always.
17:03 < sipax> it should not go write a database entry for a file it failed to create
17:03 < sipax> is it a pruned node?
17:03 < gmaxwell> no.
17:03 < sipax> in that case, certainly not
17:04 < gmaxwell> what the heck, even after logging that a bunch of times it's making progress again.
17:06 < gmaxwell> okay, actually the readblockfromdisk is being triggered by getblock rpcs being called by p2pool
17:06 < gmaxwell> so this might just be an artifact of running getblock on a block we have headers for but no data.
17:07 < sipax> gmaxwell: no, it shouldn't
17:07 < sipax> getblock RPC checks whether the BLOCK_HAVE_DATA flag is present for that block index entry
17:14 < gmaxwell> well my log is full of 
17:14 < gmaxwell> 2016-03-23 23:58:18 Received a POST request for / from 127.0.0.1:51001
17:14 < gmaxwell> 2016-03-23 23:58:18 ERROR: ReadBlockFromDisk: OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)
17:14 < gmaxwell> 2016-03-23 23:58:18 ThreadRPCServer method=getblock
17:32 < gmaxwell> and now that it's caught up, no more..
17:34 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 244 seconds]
17:37 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
18:09 -!- murch [~murch@p4FE39D4F.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
18:11 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ugudpesafeyuugnw] has quit [Quit: Connection closed for inactivity]
18:12 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
18:56 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 244 seconds]
18:57 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
19:09 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:10 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:19 < morcos> gmaxwell: sipax: looks like thats just the error that happens, the RPC only checks the BLOCK_HAVE_DATA flag if you're pruning.  Ha!
19:20 -!- baldur [~baldur@pool-72-69-12-130.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
19:20 -!- baldur [~baldur@pool-72-69-12-130.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
19:21 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 268 seconds]
19:24 -!- zooko [~user@2601:281:8001:26aa:bd9f:ffdd:1cad:8f0f] has joined #bitcoin-core-dev
19:28 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
19:52 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds]
19:54 -!- AdrianG_ is now known as AdrianG
19:54 -!- AdrianG is now known as Guest82537
19:54 -!- Guest82537 is now known as AdrianG_
20:01 -!- AdrianG_ [~User@107.170.31.78] has quit [Changing host]
20:01 -!- AdrianG_ [~User@unaffiliated/amphetamine] has joined #bitcoin-core-dev
20:01 -!- AdrianG_ is now known as Aleph0
20:08 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 240 seconds]
20:16 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Remote host closed the connection]
20:17 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
20:22 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
20:26 -!- zooko [~user@2601:281:8001:26aa:bd9f:ffdd:1cad:8f0f] has quit [Remote host closed the connection]
20:29 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
20:31 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
20:34 -!- mrkent [~textual@unaffiliated/mrkent] has quit []
20:34 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
20:37 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
20:39 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer]
20:41 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 244 seconds]
20:54 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
20:56 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
21:49 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:50 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:51 -!- frankenmint [~frankenmi@174.25.22.102] has joined #bitcoin-core-dev
21:55 -!- BCB [4241870d@gateway/web/freenode/ip.66.65.135.13] has quit [Quit: Page closed]
22:09 -!- mrkent [~textual@unaffiliated/mrkent] has quit []
22:11 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
22:21 -!- Don_John [~Don@134.114.223.249] has quit [Read error: Connection reset by peer]
22:23 -!- mrkent [~textual@unaffiliated/mrkent] has quit []
22:24 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
22:44 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 276 seconds]
22:48 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:49 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:51 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 244 seconds]
22:52 -!- d_t [~textual@212.144.253.35] has joined #bitcoin-core-dev
22:55 -!- d_t [~textual@212.144.253.35] has quit [Client Quit]
22:56 -!- mrkent [~textual@unaffiliated/mrkent] has quit []
22:59 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
23:00 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 248 seconds]
23:00 -!- dermoth [~thomas@dsl-216-221-53-213.mtl.contact.net] has quit [Read error: Connection reset by peer]
23:00 -!- dermoth [~thomas@dsl-216-221-53-213.mtl.contact.net] has joined #bitcoin-core-dev
23:02 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
23:04 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:07 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
23:08 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
23:17 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
23:20 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
23:45 < jonasschnelli> encryption: would it be stupid to use the identity keypair (used for Auth / MITM protection) in a ECDH scheme to encrypt a dh key-exchange for further encryption?
23:45 < jonasschnelli> I think we should not use the "static" identity key for encryption.
23:46 < jonasschnelli> It would expose the shared ecdh secred (AES256key) to known-plaintext-attacks.
23:47 < jonasschnelli> But not sure if using the identity key for a quick ECDH keyexchange (known-plaintext-attacks are pretty impossible) would make sense.
23:51 < gmaxwell> It would be stupid beyond all comprehension.
23:52 < gmaxwell> The encryption should be ephemerally keyed. There is no need for the key to outlive the session.
23:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-bmenxcebohaiamfr] has joined #bitcoin-core-dev
23:57 < gmaxwell> What I suggested earlier-- which is a pretty standard and well studied architecture is to use randomly generated keys to establish a secure channel (with authenticated encryption like AES-GCM or chacha20-poly1305); then inside if-- if some identity is in use-- you use that identity to authenticate the secure session you just established. E.g. by signing the hash of the shared session key.