12016-08-19T00:02:46  *** fengling has quit IRC
  22016-08-19T00:07:34  *** cryptapus is now known as cryptapus_afk
  32016-08-19T00:12:03  *** Giszmo has quit IRC
  42016-08-19T00:17:07  *** [Author] has quit IRC
  52016-08-19T00:23:39  *** n3tsin has quit IRC
  62016-08-19T00:24:16  *** n3tsin has joined #bitcoin-core-dev
  72016-08-19T00:26:44  *** Giszmo has joined #bitcoin-core-dev
  82016-08-19T00:28:12  *** n3tsin has quit IRC
  92016-08-19T00:33:37  *** Alopex has quit IRC
 102016-08-19T00:34:42  *** Alopex has joined #bitcoin-core-dev
 112016-08-19T00:36:05  *** JZA has quit IRC
 122016-08-19T00:38:20  *** JZA has joined #bitcoin-core-dev
 132016-08-19T00:39:06  *** aureianimus_ has quit IRC
 142016-08-19T00:39:24  *** aureianimus has joined #bitcoin-core-dev
 152016-08-19T00:50:44  *** n3tsin has joined #bitcoin-core-dev
 162016-08-19T00:59:21  *** fengling has joined #bitcoin-core-dev
 172016-08-19T01:00:51  *** baldur has joined #bitcoin-core-dev
 182016-08-19T01:03:52  *** Kexkey has quit IRC
 192016-08-19T01:04:06  *** fengling has quit IRC
 202016-08-19T01:07:49  <jcorgan> wumpus: is there a plan for #7753?
 212016-08-19T01:13:12  *** n3tsin has quit IRC
 222016-08-19T01:17:38  *** [Author] has joined #bitcoin-core-dev
 232016-08-19T01:29:24  <jl2012> gmaxwell, luke-jr: I think we could require an extra command in debug windows to "unlock" those sensitive commands
 242016-08-19T01:32:06  <CodeShark> jl2012: good idea
 252016-08-19T01:33:08  <jl2012> which will return a page of warning, describing the risk of each unlocked command
 262016-08-19T01:35:50  <luke-jr> jl2012: hmm, that might work
 272016-08-19T01:56:01  *** fengling has joined #bitcoin-core-dev
 282016-08-19T02:04:53  *** zooko has joined #bitcoin-core-dev
 292016-08-19T02:17:32  *** molly has quit IRC
 302016-08-19T02:27:39  *** moli has joined #bitcoin-core-dev
 312016-08-19T02:43:23  *** zooko has quit IRC
 322016-08-19T02:50:11  *** Alopex has quit IRC
 332016-08-19T02:51:17  *** Alopex has joined #bitcoin-core-dev
 342016-08-19T03:18:33  *** mkarrer_ has joined #bitcoin-core-dev
 352016-08-19T03:20:47  *** mkarrer has quit IRC
 362016-08-19T03:38:53  *** justanotheruser has quit IRC
 372016-08-19T03:42:05  *** justanotheruser has joined #bitcoin-core-dev
 382016-08-19T03:54:05  *** spudowiar has quit IRC
 392016-08-19T03:54:34  *** spudowiar1 has joined #bitcoin-core-dev
 402016-08-19T03:55:42  *** spudowiar1 is now known as spudowiar
 412016-08-19T03:58:48  *** cryptapus_afk is now known as cryptapus
 422016-08-19T03:59:53  *** cryptapus is now known as cryptapus_afk
 432016-08-19T04:13:43  *** justanotheruser is now known as radiopaid
 442016-08-19T04:16:46  *** spudowiar has quit IRC
 452016-08-19T04:23:14  *** radiopaid is now known as justanotheruser
 462016-08-19T04:48:10  <GitHub144> [bitcoin] petertodd opened pull request #8543: Use ANYONECANPAY if -spendzeroconfchange=0 (master...2016-08-anyonecanpay-if-spendzeroconfchange-disabled) https://github.com/bitcoin/bitcoin/pull/8543
 472016-08-19T04:49:44  *** cheese_ has joined #bitcoin-core-dev
 482016-08-19T04:52:45  *** Cheeseo has quit IRC
 492016-08-19T05:01:11  *** Alopex has quit IRC
 502016-08-19T05:02:16  *** Alopex has joined #bitcoin-core-dev
 512016-08-19T05:11:10  *** jannes has quit IRC
 522016-08-19T05:56:46  *** Cory has quit IRC
 532016-08-19T06:19:58  *** harrymm has quit IRC
 542016-08-19T06:29:21  <GitHub95> [bitcoin] jonasschnelli closed pull request #8541: Trivial: Fix typos in various files (master...various-typos) https://github.com/bitcoin/bitcoin/pull/8541
 552016-08-19T06:31:58  *** Lysander1 has joined #bitcoin-core-dev
 562016-08-19T06:34:21  *** Lysanders has quit IRC
 572016-08-19T06:34:55  <jonasschnelli> sipa, gmaxwell: about the binary ecdsa signing. We could create a standard ecdsa sig along with the GPG assets sig. Something like bitcoin-osx-0.13-build.assert.ecsig, where we just place a 64byte compact sig.  ecdsa(sha256(sha256(<filecontent>)), P)
 582016-08-19T06:35:41  <jonasschnelli> sipa, gmaxwell: then we could have a file with [{"<devname>":"34byte pubkey"},]
 592016-08-19T06:35:49  <jonasschnelli> (a cpp header IMO)
 602016-08-19T06:38:18  <jonasschnelli> For the downloading the asset file signatures, we could use the github API (GET /repos/:owner/:repo/contents/:path)
 612016-08-19T06:38:27  *** harrymm has joined #bitcoin-core-dev
 622016-08-19T06:38:47  <jonasschnelli> Using the maybe existing local git binary seems fragile
 632016-08-19T06:40:31  <luke-jr> Seems unlikely Mac/Windows (where this will generally get used) will have a local git binary anyway
 642016-08-19T06:43:19  *** BashCo has quit IRC
 652016-08-19T06:46:48  <jonasschnelli> luke-jr: Yes. depending on git is probably a nogo on Win/OSX
 662016-08-19T06:47:14  *** kadoban has quit IRC
 672016-08-19T06:50:32  *** MarcoFalke has joined #bitcoin-core-dev
 682016-08-19T06:56:30  *** jannes has joined #bitcoin-core-dev
 692016-08-19T06:57:35  *** moli has quit IRC
 702016-08-19T07:06:37  *** Cory has joined #bitcoin-core-dev
 712016-08-19T07:18:27  *** BashCo has joined #bitcoin-core-dev
 722016-08-19T07:24:28  *** laurentmt has joined #bitcoin-core-dev
 732016-08-19T07:26:05  *** laurentmt has quit IRC
 742016-08-19T07:27:28  *** BashCo_ has joined #bitcoin-core-dev
 752016-08-19T07:30:40  *** rubensayshi has joined #bitcoin-core-dev
 762016-08-19T07:31:14  *** BashCo has quit IRC
 772016-08-19T07:35:43  *** catsAREnotSECURE has joined #bitcoin-core-dev
 782016-08-19T07:39:07  *** harrymm has quit IRC
 792016-08-19T07:39:41  <da2ce7> jonasschnelli a ecdsa binary verify client would be very useful for other projects.  It would be great to create something that could get support of a wider community.
 802016-08-19T07:40:20  <jonasschnelli> Yes. Maybe it could be coupled with gitian
 812016-08-19T07:44:29  <da2ce7> I would have something like a 'project definition' file.  that defines the fields: serial, project name, version naming rules, public keys, n of m requirements, revoked keys, revoked releases
 822016-08-19T07:45:26  <da2ce7> and a 'witness file', that has a list of sha256 hashes, and signatures.
 832016-08-19T07:46:29  <jonasschnelli> You need to make sure the "project definition" (devs pubkey) must be covered by a sha256 during previous builds...
 842016-08-19T07:47:05  <jonasschnelli> This why it might be best if compiled into a binary or if its covered in the gitian assets file
 852016-08-19T07:48:15  <da2ce7> the project definition file should come with a self-witness, except that the self-witness is signed by all of the public keys defined in the definition.
 862016-08-19T07:48:35  <da2ce7> (ignores the n-of-m requirement).
 872016-08-19T07:48:38  <catsAREnotSECURE> Is there public disclosure of  bitcoin holdings / wallets associated with specific developers?
 882016-08-19T07:48:55  <da2ce7> catsAREnotSECURE no, and off topic.
 892016-08-19T07:49:29  <catsAREnotSECURE> This question was intended for midnightmagic. The conversation began in #bitcoin, but for transparency reasons, I sought to move it to this channel.
 902016-08-19T07:51:39  <da2ce7> catsAREnotSECURE, well, I'm sorry for your mistake, please move it back to #bitcoin, or elsewhere.
 912016-08-19T07:51:52  <catsAREnotSECURE> One more comment and then that will be it.
 922016-08-19T07:52:08  <catsAREnotSECURE> midnightmagic, During the last meeting, there was discussion regarding the proposed implementation a system similar to that which Gitian is using, which features signatures of multiple developers, within the official binary / source distribution on certain operating systems. One proposal included distributing the GPG library and another used an alternate method for signature / checksum verification which would not require additional
 932016-08-19T07:52:09  <catsAREnotSECURE> libraries. The alternate proposal, determined by Wladimir van der Laan to be unworkable, intended to mitigate the requirement of an additional library by imbedding checksums within the blockchain. The alternate proposal was not included in the official meeting and was dismissed over stated concerns about existing nodes rejecting the transactions. It was acknowledged that either implementation would significantly increase client
 942016-08-19T07:52:09  <catsAREnotSECURE> security during the release cycle, affecting the majority of users, and it is speculated by my clients that either implementation would result in less (downward) price fluctuation. Right now, the security of the releases are highly dependant on admittedly vulnerable CA/TLS certificates and a single GPG signing key held by Wladimir van der Laan, with a lack of transparency regarding the level of security measures taken to secure this
 952016-08-19T07:52:14  <catsAREnotSECURE> signing key. During this "unofficial" meeting in #bitcoin, there were a minimum of 123 lines of comment from Wladimir van der Laan, all of which are not included in the "official" meeting log. Given the recent advisory on the website, regarding "state actors", there is speculation amoung my clients that conflict of interest disclosure and transparency may be insufficient amoung the Bitcoin Core developers.
 962016-08-19T07:54:07  *** ChanServ sets mode: +o sipa
 972016-08-19T07:54:16  <sipa> catsAREnotSECURE: take it elsewhere
 982016-08-19T07:54:17  *** harrymm has joined #bitcoin-core-dev
 992016-08-19T07:54:17  <luke-jr> then your clients should hire people of their own to work as Bitcoin Core developers; off-topic anyway, #bitcoin
1002016-08-19T07:55:18  <jonasschnelli> sigh
1012016-08-19T07:59:44  <da2ce7> jonasschnelli we need a constant 'Project CN', so that somebody doesn't release 'bitcotn-core' and project will ignore all the signing policies.  -  The verify app should also spit out warnings:  "bitcotn-core" is very similar to "bitcoin-core".
1022016-08-19T08:00:28  <da2ce7> maybe a simple 'release' file will suffice.  a release file has: project CN, sha256 of latest 'project definition' file, release name and version, list of sha256 of past release files, list of sha256 of binaries included in release
1032016-08-19T08:13:14  *** Evel-Knievel has quit IRC
1042016-08-19T08:16:23  *** Evel-Knievel has joined #bitcoin-core-dev
1052016-08-19T08:17:21  *** harrymm has quit IRC
1062016-08-19T08:33:57  <wumpus> gmaxwell: god damnit, can it get any more scammy
1072016-08-19T08:34:09  <MarcoFalke> ?
1082016-08-19T08:34:11  *** harrymm has joined #bitcoin-core-dev
1092016-08-19T08:34:24  <wumpus> <gmaxwell> Someone in #bitcoin had 17 BTC stolen from them today because they came for tech support (their wallet was a couple years behind and they were wondering why they hadn't seen a payment yet) and someone wumpus and I were talking to, "moldish", pulled them into PM and got them to do a dumpprivkey.  :(
1102016-08-19T08:35:01  <LeMiner> ugh...
1112016-08-19T08:35:13  <sipa> :(
1122016-08-19T08:36:10  <wumpus> fuckers
1132016-08-19T08:36:19  <sipa> do we need to put a warning in the qt console when using certain RPCs?
1142016-08-19T08:36:22  <LeMiner> could include a warning message on dumbprivkey that the outputs are private and anyone with the key can steal your coins?
1152016-08-19T08:36:24  <LeMiner> exactly
1162016-08-19T08:36:40  <wumpus> does anyone have info on that guy?
1172016-08-19T08:36:57  <sipa> of course, then people may get users to run bitcoin-qt with -server...
1182016-08-19T08:37:00  <midnightmagic> wumpus: Yes. A tenuous link.
1192016-08-19T08:37:02  *** sipa sets mode: -o sipa
1202016-08-19T08:37:07  <LeMiner> Not a bad idea
1212016-08-19T08:37:15  <luke-jr> sipa: jl2012 suggested an extra step to enable dangerous RPCs
1222016-08-19T08:37:40  <luke-jr> (which would warn)
1232016-08-19T08:37:53  <wumpus> luke-jr: +1
1242016-08-19T08:38:32  <wumpus> I think any private key leaking functions should be disabled by default
1252016-08-19T08:38:34  <LeMiner> And perhaps a topic message in #bitcoin that states to be cautious when people try to "help" you through pm's
1262016-08-19T08:38:35  <wumpus> both for the UI and RPC
1272016-08-19T08:38:50  * midnightmagic will change the topic immediately.
1282016-08-19T08:38:53  <wumpus> maybe a command line option to enable them
1292016-08-19T08:38:56  <sipa> LeMiner: nobody reada the topic message, but it can't hurt
1302016-08-19T08:39:36  *** evoskuil has quit IRC
1312016-08-19T08:40:19  *** BashCo has joined #bitcoin-core-dev
1322016-08-19T08:41:51  *** mkarrer_ has quit IRC
1332016-08-19T08:44:00  *** BashCo_ has quit IRC
1342016-08-19T08:45:13  <wumpus> jcorgan: not really, I try to get back to that at some point
1352016-08-19T08:45:20  *** mkarrer has joined #bitcoin-core-dev
1362016-08-19T08:45:21  <wumpus> jcorgan: lots of things got in between, as usual :(
1372016-08-19T08:46:00  <wumpus> aim is still 0.14 I guess
1382016-08-19T08:46:38  *** laurentmt has joined #bitcoin-core-dev
1392016-08-19T08:48:58  *** laurentmt has quit IRC
1402016-08-19T08:50:39  *** catsAREnotSECURE has quit IRC
1412016-08-19T08:54:18  <wumpus> https://github.com/bitcoin/bitcoin/issues/8544
1422016-08-19T09:00:25  <jouke> wumpus: :(
1432016-08-19T09:00:53  <wumpus> jouke: yes thsi makes me really grumpy
1442016-08-19T09:03:41  *** BashCo_ has joined #bitcoin-core-dev
1452016-08-19T09:06:32  *** BashCo has quit IRC
1462016-08-19T09:06:49  *** Lysanders has joined #bitcoin-core-dev
1472016-08-19T09:08:46  <jouke> But, literally at the same time we were helping a customer on the phone to do a dumpprivkey :x. (Someone bought bitcoins to pay for cryptolocker, but didn't realise that it would take a while for Core to be able to send bitcoins).
1482016-08-19T09:09:01  *** Lysander1 has quit IRC
1492016-08-19T09:13:13  <wumpus> "Someone bought bitcoins to pay for cryptolocker" :(
1502016-08-19T09:13:24  <wumpus> I'm going to take off today, sorry
1512016-08-19T09:13:32  <jouke> heh
1522016-08-19T09:13:58  <wumpus> stupid fuckers, sometimes I'm about to believe the story that bitcoin is just making it easy for people to be scammed out of their money
1532016-08-19T09:14:37  <jonasschnelli> Private-key-management will occupy us during the next years...
1542016-08-19T09:14:52  <jonasschnelli> But people also need to wake up...
1552016-08-19T09:15:17  <wumpus> yes, people need to take responsibility, or not use it at all
1562016-08-19T09:15:23  <jonasschnelli> Would you give someone (just met on the street), you wallet containing 10k USD to "fix an issue" with the opening zipper?
1572016-08-19T09:15:31  <wumpus> but things like cryptolocker ... bah puke
1582016-08-19T09:16:25  <jonasschnelli> Cryptolockers are evil, ... indeed.
1592016-08-19T09:16:43  <wumpus> jonasschnelli: not a random someone, but what if someone pretends to be e.g. a cop, people would be inclined to trust them
1602016-08-19T09:17:29  <jonasschnelli> maybe in Europe. :) But right,... people pretending to help on technical issues but then scam off one, thats just so bad.
1612016-08-19T09:17:32  <wumpus> but yes the threshold for trust should be even lower on the internet, you can almost never assume peopel are who them pretend they are
1622016-08-19T09:18:27  <wumpus> that's a much bigger problem than just bitcoin
1632016-08-19T09:18:47  <jouke> A lot of people are really trustful by nature.
1642016-08-19T09:19:42  <jonasschnelli> which is good IMO
1652016-08-19T09:20:19  <jouke> They should wake up indeed. But I lost a bit of confidence in "people" to be able to do so since I started with Bitcoin. On the other hand, a police officer once told me: "These people are allowed to vote".
1662016-08-19T09:20:21  <jonasschnelli> But I agree with wumpus, we should add some private key protections
1672016-08-19T09:20:49  <jonasschnelli> But the questions is then, if an attacker can manage to enable the protected features by setting a config value, etc.
1682016-08-19T09:20:57  <jonasschnelli> (if they already manage to execute dumpprivkey)
1692016-08-19T09:21:05  <jonasschnelli> Maybe warning are the better approach
1702016-08-19T09:21:13  <jonasschnelli> you need to call dumpprivkey twice...
1712016-08-19T09:21:24  <jonasschnelli> first time, it will response with a warning
1722016-08-19T09:21:42  <wumpus> a big red warning on top of the debug console
1732016-08-19T09:22:07  <jouke> Only to come to realise that people don't read :P
1742016-08-19T09:22:16  <jonasschnelli> or we could entirely disable dumpprivkey in the GUI
1752016-08-19T09:22:23  <jonasschnelli> (and dumpwallet)
1762016-08-19T09:22:43  <jonasschnelli> like most hardware wallets, there is no way to export private keys.
1772016-08-19T09:22:59  <jonasschnelli> (for core, except your using -server/d with bitcoin-cli
1782016-08-19T09:24:25  <wumpus> yes, ideally wallets wouldn't allow exporting private keys
1792016-08-19T09:25:38  <wumpus> jouke: what was the point of having the user do dumpprivkey? I hope he didn't have to give the private key over the phone?
1802016-08-19T09:26:24  <jouke> wumpus: no, we are very strict on not wanting to know the privkey (although it's quite tempting to just ask for the wallet).
1812016-08-19T09:26:55  <jouke> wumpus: to transfer it to an other "light weight" wallet.
1822016-08-19T09:27:09  <jonasschnelli> transfering keys is bad...
1832016-08-19T09:27:16  *** laurentmt has joined #bitcoin-core-dev
1842016-08-19T09:27:17  <jonasschnelli> transfering coins over on-chain transactions probably much better
1852016-08-19T09:27:29  <jonasschnelli> the fee should be worth the additional security
1862016-08-19T09:28:08  <jouke> Very often the payees of cryptolockers are businesses that are unable to work so they don't want to way for the wallet to fully synchronize.
1872016-08-19T09:28:15  <jouke> *wait
1882016-08-19T09:28:59  <jouke> Normally we tell people to just wait.
1892016-08-19T09:29:08  <wumpus> core should also warn better that it's unable to process transactions until it is synced, there's already a pull for that though
1902016-08-19T09:29:42  <wumpus> https://github.com/bitcoin/bitcoin/pull/8371
1912016-08-19T09:29:50  *** Ylbam has joined #bitcoin-core-dev
1922016-08-19T09:29:51  <jonasschnelli> Yes. Needs testing.
1932016-08-19T09:29:57  <wumpus> so that people don't get the idea that they can just make a receiving address and receive coins
1942016-08-19T09:30:09  <jonasschnelli> But what we really need is a SPV hybrid mode
1952016-08-19T09:30:14  <jonasschnelli> This would solve so much hassle.
1962016-08-19T09:30:16  <jouke> wumpus: *and send coins
1972016-08-19T09:30:34  <wumpus> jouke: well they can receive coins, but they won't see them until synced
1982016-08-19T09:30:41  <wumpus> jouke: and can't send them through either
1992016-08-19T09:30:49  <wumpus> jonasschnelli: sure, but tha's further away
2002016-08-19T09:30:55  <jonasschnelli> yes. agreed
2012016-08-19T09:31:00  <wumpus> just warning people and telling people what they're up to would already go a*long* way
2022016-08-19T09:31:04  <wumpus> we haven't been doing enough of that
2032016-08-19T09:31:13  <wumpus> always far-away technical solutions
2042016-08-19T09:32:09  <jouke> I like that pull request :)
2052016-08-19T09:33:29  <jonasschnelli> Needs testing.. will probably be in 0.14
2062016-08-19T09:33:40  <wumpus> at least it's much easier to merge than a SPV mode jonasschnelli:)
2072016-08-19T09:33:48  <GitHub82> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8250de13587e...36404aeec8c1
2082016-08-19T09:33:48  <GitHub82> bitcoin/master b4a9aa5 Wladimir J. van der Laan: qt: Fix random segfault when closing "Choose data directory" dialog...
2092016-08-19T09:33:49  <GitHub82> bitcoin/master 36404ae Wladimir J. van der Laan: Merge #8540: qt: Fix random segfault when closing "Choose data directory" dialog...
2102016-08-19T09:33:49  <jonasschnelli> heh... indeed
2112016-08-19T09:34:02  <GitHub158> [bitcoin] laanwj closed pull request #8540: qt: Fix random segfault when closing "Choose data directory" dialog (master...2016_08_qt_choosedatadir_crash) https://github.com/bitcoin/bitcoin/pull/8540
2122016-08-19T09:35:07  *** laurentmt has quit IRC
2132016-08-19T09:38:54  <wumpus> jonasschnelli: but yes we should really start merging some GUI changes for 0.14
2142016-08-19T09:38:59  <wumpus> jonasschnelli: so much open
2152016-08-19T09:39:41  <jonasschnelli> Yes. But mosts things are not ready
2162016-08-19T09:39:57  <jonasschnelli> But will have a look next week
2172016-08-19T09:39:59  <wumpus> 0.14 is still far away, so merging something not-entirely-perfect-yet that can be improved later is actually ok
2182016-08-19T09:40:10  <jonasschnelli> Yes
2192016-08-19T09:40:13  <wumpus> incremental development tends to work better for GUI
2202016-08-19T09:41:27  <wumpus> ooh https://github.com/bitcoin/bitcoin/pull/8517 is cool
2212016-08-19T09:41:30  <wumpus> I completely missed that one
2222016-08-19T09:41:33  <jonasschnelli> I'm finishing my QT Mempool stats PR, then I'll focus on getting things in
2232016-08-19T09:41:47  <jonasschnelli> 8517 is mostly ready IMO
2242016-08-19T09:41:57  <jonasschnelli> Needs some Win/Linux testing I guess
2252016-08-19T09:42:14  <jonasschnelli> And I think I need to run optimizepngs
2262016-08-19T09:43:15  <wumpus> going to test it
2272016-08-19T09:44:39  *** spudowiar has joined #bitcoin-core-dev
2282016-08-19T09:55:59  *** AaronvanW has quit IRC
2292016-08-19T09:57:53  <GitHub3> [bitcoin] MarcoFalke opened pull request #8545: [doc] Update git-subtree-check.sh README (master...Mf1608-doc) https://github.com/bitcoin/bitcoin/pull/8545
2302016-08-19T10:07:45  *** laurentmt has joined #bitcoin-core-dev
2312016-08-19T10:11:49  *** AaronvanW has joined #bitcoin-core-dev
2322016-08-19T10:15:59  *** ArthurNumbanumba has quit IRC
2332016-08-19T10:17:48  *** Megaf has joined #bitcoin-core-dev
2342016-08-19T10:19:01  <GitHub39> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/36404aeec8c1...f4e777819c54
2352016-08-19T10:19:01  <GitHub39> bitcoin/master 65f4532 Jameson Lopp: document return value of networkhashps for getmininginfo RPC endpoint
2362016-08-19T10:19:01  <GitHub39> bitcoin/master f4e7778 Wladimir J. van der Laan: Merge #8461: document return value of networkhashps for getmininginfo RPC endpoint...
2372016-08-19T10:19:11  <GitHub3> [bitcoin] laanwj closed pull request #8461: document return value of networkhashps for getmininginfo RPC endpoint (master...rpcMiningHelp) https://github.com/bitcoin/bitcoin/pull/8461
2382016-08-19T10:24:50  *** ArthurNumbanumba has joined #bitcoin-core-dev
2392016-08-19T10:31:39  *** cheese_ has quit IRC
2402016-08-19T10:34:18  <GitHub140> [bitcoin] mcccs opened pull request #8546: Remove IP transaction check [CLEAN] (master...abc123) https://github.com/bitcoin/bitcoin/pull/8546
2412016-08-19T10:34:38  <GitHub142> [bitcoin] mcccs closed pull request #8538: Remove IP transaction check (master...Ip-check) https://github.com/bitcoin/bitcoin/pull/8538
2422016-08-19T10:35:53  *** laurentmt has quit IRC
2432016-08-19T10:38:01  *** ArthurNumbanumba has quit IRC
2442016-08-19T10:40:41  *** Megaf has quit IRC
2452016-08-19T10:52:25  *** Lysander1 has joined #bitcoin-core-dev
2462016-08-19T10:54:59  *** Lysanders has quit IRC
2472016-08-19T10:56:28  *** Lysanders has joined #bitcoin-core-dev
2482016-08-19T10:58:04  *** Lysander1 has quit IRC
2492016-08-19T11:00:17  *** ArthurNumbanumba has joined #bitcoin-core-dev
2502016-08-19T11:25:54  *** laurentmt has joined #bitcoin-core-dev
2512016-08-19T11:25:55  *** laurentmt has quit IRC
2522016-08-19T11:31:33  *** Lysander1 has joined #bitcoin-core-dev
2532016-08-19T11:34:13  *** Lysanders has quit IRC
2542016-08-19T11:41:40  *** ArthurNumba2 has joined #bitcoin-core-dev
2552016-08-19T11:42:19  *** ArthurNumbanumba has quit IRC
2562016-08-19T11:42:28  *** ArthurNumba2 has quit IRC
2572016-08-19T11:42:53  *** ArthurNumbanumba has joined #bitcoin-core-dev
2582016-08-19T11:45:58  *** Lysanders has joined #bitcoin-core-dev
2592016-08-19T11:48:38  *** Lysander1 has quit IRC
2602016-08-19T11:49:33  *** Lysander1 has joined #bitcoin-core-dev
2612016-08-19T11:51:46  *** Lysanders has quit IRC
2622016-08-19T12:15:58  *** YOU-JI has joined #bitcoin-core-dev
2632016-08-19T12:19:29  *** Lysander1 has quit IRC
2642016-08-19T12:21:29  *** Lysanders has joined #bitcoin-core-dev
2652016-08-19T12:26:26  *** Lysander1 has joined #bitcoin-core-dev
2662016-08-19T12:26:32  *** owowo has quit IRC
2672016-08-19T12:28:14  *** owowo has joined #bitcoin-core-dev
2682016-08-19T12:29:43  *** Lysanders has quit IRC
2692016-08-19T12:37:39  *** Lysanders has joined #bitcoin-core-dev
2702016-08-19T12:40:50  *** Lysander1 has quit IRC
2712016-08-19T12:43:31  *** cryptapus_afk is now known as cryptapus
2722016-08-19T12:45:52  *** Ylbam has quit IRC
2732016-08-19T12:56:33  *** xiangfu has quit IRC
2742016-08-19T12:57:05  *** xiangfu has joined #bitcoin-core-dev
2752016-08-19T13:04:03  *** moli has joined #bitcoin-core-dev
2762016-08-19T13:08:22  *** YOU-JI has quit IRC
2772016-08-19T13:18:22  *** Megaf has joined #bitcoin-core-dev
2782016-08-19T13:26:00  *** MarcoFalke has left #bitcoin-core-dev
2792016-08-19T13:31:06  *** fengling has quit IRC
2802016-08-19T13:34:00  *** Lysander1 has joined #bitcoin-core-dev
2812016-08-19T13:36:25  *** Lysanders has quit IRC
2822016-08-19T13:39:07  *** Lysanders has joined #bitcoin-core-dev
2832016-08-19T13:39:48  *** Lysander1 has quit IRC
2842016-08-19T13:41:00  *** spudowiar has quit IRC
2852016-08-19T13:47:52  *** Cheeseo has joined #bitcoin-core-dev
2862016-08-19T13:57:21  *** aalex has joined #bitcoin-core-dev
2872016-08-19T14:05:23  *** Guyver2 has joined #bitcoin-core-dev
2882016-08-19T14:08:15  *** Samdney has joined #bitcoin-core-dev
2892016-08-19T14:09:33  *** Ylbam has joined #bitcoin-core-dev
2902016-08-19T14:19:49  *** Lysander1 has joined #bitcoin-core-dev
2912016-08-19T14:22:21  *** Lysanders has quit IRC
2922016-08-19T14:25:18  *** Lysanders has joined #bitcoin-core-dev
2932016-08-19T14:26:12  *** Lysander1 has quit IRC
2942016-08-19T14:27:16  *** Lysander1 has joined #bitcoin-core-dev
2952016-08-19T14:30:03  *** Lysanders has quit IRC
2962016-08-19T14:33:07  *** Megaf has quit IRC
2972016-08-19T14:33:14  *** Lysanders has joined #bitcoin-core-dev
2982016-08-19T14:35:23  *** Lysander1 has quit IRC
2992016-08-19T14:36:08  *** Lysander1 has joined #bitcoin-core-dev
3002016-08-19T14:38:46  *** Lysanders has quit IRC
3012016-08-19T14:50:05  *** molz has joined #bitcoin-core-dev
3022016-08-19T14:52:54  *** moli has quit IRC
3032016-08-19T15:13:17  <jonasschnelli> gmaxwell, sipa: what do you think about the following approach: https://bitcoin.jonasschnelli.ch/ecdsa_sig.txt
3042016-08-19T15:14:43  *** schmidty has quit IRC
3052016-08-19T15:18:24  *** Lysanders has joined #bitcoin-core-dev
3062016-08-19T15:20:20  *** Lysander1 has quit IRC
3072016-08-19T15:21:37  <gmaxwell> Requiring QT is problematic, since many (esp high security) users are headless cli users.  This sounds like it is not (many) fewer steps then verifying with gpg? it sounds like you're thinking the user will seperately download the software, but then verify it with this which will also make outbound connections?
3082016-08-19T15:21:57  *** Lysander1 has joined #bitcoin-core-dev
3092016-08-19T15:23:14  <gmaxwell> My suggestion is that we make it so there is a single download which contains all the verification information. Just one file.  And have it so the tool can either take this one file provided by the user and verify it and if it passes, unpack and install it, or it can fetch it + verify it (then unpack and install it).
3102016-08-19T15:24:30  *** cryptapus is now known as cryptapus_afk
3112016-08-19T15:25:02  <gmaxwell> it's important that its also easy to use the tool without it making network connections, so that it can be used on offline hosts, and also not "phone home" every time bitcoin is installed, which would make it easy to track who is using it. (both who is using bitcoin and who is using it with/without verifying-- we want a network attacker to not be able to tell users who verify from users who don'
3122016-08-19T15:25:08  <gmaxwell> t)
3132016-08-19T15:25:10  *** Lysanders has quit IRC
3142016-08-19T15:26:32  <jonasschnelli> gmaxwell: Good point.. make sense.
3152016-08-19T15:28:03  <jonasschnelli> gmaxwell: regarding "single download", Isn't grabbing the sources from a GPG signed github repository more secure?
3162016-08-19T15:28:21  <jonasschnelli> Hmm... no... not really
3172016-08-19T15:28:38  *** kadoban has joined #bitcoin-core-dev
3182016-08-19T15:28:41  <jonasschnelli> Agree, we could provide a single witness file along with the binaries
3192016-08-19T15:29:02  <jonasschnelli> If additional signature follow after the release, we could update the witness file.
3202016-08-19T15:29:24  <gmaxwell> then thats two files, which would be unfortunate (bad for usability)
3212016-08-19T15:29:44  <jonasschnelli> What would speak against replacing the witness file...
3222016-08-19T15:29:46  <jonasschnelli> ?
3232016-08-19T15:30:30  <jonasschnelli> gmaxwell: Or do you mean a "single download" would be the verifing tool including the witness data?
3242016-08-19T15:30:34  <gmaxwell> By two files I mean "bitcoin" and "the witness"  if there are two files someone watching the network can tell which users check and which don't,  and someone checking on an offline computer has two files to download and copy across, so they won't.
3252016-08-19T15:30:58  *** BashCo_ has quit IRC
3262016-08-19T15:31:22  *** BashCo has joined #bitcoin-core-dev
3272016-08-19T15:31:29  <gmaxwell> I mean the bitcoin core update and the signatures for it should be a single file.  The download/verifying tool can both be included in it, and available seperately (for the first time user).
3282016-08-19T15:31:42  <jonasschnelli> ah...
3292016-08-19T15:31:44  <jonasschnelli> yes..
3302016-08-19T15:32:11  <jonasschnelli> Though, there would be a file-package (including sigs) per platform I guess
3312016-08-19T15:33:08  <gmaxwell> Right, I guess I'd suggest we include in the tar a dummy file the size of the witness. And the signing tool would fill that in, and the verify tool would mask out the dummy file. Or something like that.
3322016-08-19T15:33:18  *** spudowiar has joined #bitcoin-core-dev
3332016-08-19T15:33:44  <gmaxwell> it's a little unfortunate to have to uncompress an unverified file, but I see no way around that.
3342016-08-19T15:33:47  <jonasschnelli> or just <whitnessfile>&<tar.file>
3352016-08-19T15:34:10  <gmaxwell> do you mean concatinate them?
3362016-08-19T15:34:11  <jonasschnelli> It would be a "new file format"... but I guess that doesn't matter
3372016-08-19T15:34:15  <jonasschnelli> yes
3382016-08-19T15:34:34  <jonasschnelli> also it prevents from users extracting the tar without verifing.
3392016-08-19T15:34:45  <jonasschnelli> Once it was verified, it'll copy out the "pure" tag
3402016-08-19T15:34:46  <jonasschnelli> tar
3412016-08-19T15:34:53  <gmaxwell> well that would be simpler, unfortunately it would mean a network observer could tell who was downloading those files vs the plain tar files, unless we stopped distributing plain tar files.
3422016-08-19T15:35:34  <gmaxwell> I do like that that is much easier to implement. :)
3432016-08-19T15:35:41  <jonasschnelli> stopping the plain tar files would probably good, but people will complain. :)
3442016-08-19T15:35:54  <jonasschnelli> *be good
3452016-08-19T15:36:13  *** cryptapus has joined #bitcoin-core-dev
3462016-08-19T15:36:14  *** cryptapus has joined #bitcoin-core-dev
3472016-08-19T15:36:28  <jonasschnelli> I think forcing user to verify the binaries would be good security pratice.
3482016-08-19T15:37:11  <gmaxwell> Yes, but using a web wallet because bitcoin core install required an extra, foreign, step would not be. :)
3492016-08-19T15:37:33  <jonasschnelli> indeed...
3502016-08-19T15:38:06  <gmaxwell> my expectation is that users would use a traditional, insecure method to do their first install. You really can't do better than that, since even the verify tool itself would need to be installed.
3512016-08-19T15:38:07  <jonasschnelli> Assume the signatures file is in the tar,.. I guess you can just extract a single file
3522016-08-19T15:38:42  *** Lysander1 has quit IRC
3532016-08-19T15:38:43  <gmaxwell> jonasschnelli: yes, the trickyness is with verifying you need to verify everything except that file. Which means masking it out.
3542016-08-19T15:38:46  <jonasschnelli> Yes. First install of the verify tool should be verified through gitian-verify
3552016-08-19T15:38:55  <sipa> do we need a tar parser then...?
3562016-08-19T15:39:07  *** Lysanders has joined #bitcoin-core-dev
3572016-08-19T15:39:11  <jonasschnelli> Hmm.. tar dependency would be bad I guess
3582016-08-19T15:39:38  <jonasschnelli> Can we not just append the signatures files to the tar so that the tar can still be deflated properly?
3592016-08-19T15:39:50  <jonasschnelli> hidden-append...
3602016-08-19T15:39:54  <gmaxwell> https://github.com/Gottox/sltar  200 lines of code?
3612016-08-19T15:40:09  <jonasschnelli> does that include the gzip?
3622016-08-19T15:40:45  <gmaxwell> we could start distibuing the software as shell archives, much easier to extract data from them. :P
3632016-08-19T15:41:00  *** cryptapus has quit IRC
3642016-08-19T15:41:43  <jonasschnelli> A tar.gz that includes the binary as a tar.gz and the signatures?
3652016-08-19T15:42:23  <jonasschnelli> we provide signatures only for the "inner" binary tar.gz
3662016-08-19T15:43:00  <jonasschnelli> and would also work with the OSX .dmg and window .exe
3672016-08-19T15:43:32  *** MarcoFalke has joined #bitcoin-core-dev
3682016-08-19T15:44:17  *** Giszmo has quit IRC
3692016-08-19T15:44:19  <kanzure> user can open a port on their machine, provide a login to the ripple foundation, and then the ethereum team can deliver the payload in one step
3702016-08-19T15:44:31  *** BashCo has quit IRC
3712016-08-19T15:45:11  <kanzure> sltar looks cool. this might even be human-memorizable.
3722016-08-19T15:46:05  <wumpus> why would the signature files need to be in a tar?
3732016-08-19T15:46:16  <wumpus> just go old school, concatenate binary ecdsa signatures
3742016-08-19T15:46:30  <jonasschnelli> to avoid network observers to detect who download the signatures and who not as gmaxwell mentioned
3752016-08-19T15:46:50  <wumpus> yes, well, it doesn't matter in what format it is then right?
3762016-08-19T15:46:54  <jonasschnelli> wumpus: but that would require to split of the signatures if you just want to install it without verifing
3772016-08-19T15:47:03  <wumpus> the user has to download the file with signatures anyhow
3782016-08-19T15:47:26  <kanzure> i thought the concern was re: have a single download
3792016-08-19T15:47:31  *** Lysander1 has joined #bitcoin-core-dev
3802016-08-19T15:47:35  <jonasschnelli> wumpus: not if we make the verification optional
3812016-08-19T15:47:54  <wumpus> attaching signatures to the download itself isn't really an option; this would invalidate the sha256 hashes
3822016-08-19T15:47:57  <jonasschnelli> and would you also add the signatures to the .exe NSI installer? :)
3832016-08-19T15:48:03  *** thesnark has joined #bitcoin-core-dev
3842016-08-19T15:48:09  <wumpus> no
3852016-08-19T15:48:45  <jonasschnelli> Just provide a "meta"-tar that includes the exe/dmg/tar.gz (where we provide hashes/sigs)
3862016-08-19T15:48:47  <wumpus> just a replacement/addition to sha256sums.txt, that contains ecdsa signatures connected from by all gitian builders
3872016-08-19T15:48:58  <wumpus> coLLected
3882016-08-19T15:49:01  <jonasschnelli> Also fine for me.
3892016-08-19T15:49:12  <jonasschnelli> gmaxwell said we should use just a single download
3902016-08-19T15:49:28  <wumpus> that would be one additional file in addition to the one you want
3912016-08-19T15:49:37  <jonasschnelli> to avoid network observers to detect who did download the sigs and who not
3922016-08-19T15:49:49  <wumpus> sigh
3932016-08-19T15:49:53  <jonasschnelli> hehe.. :)
3942016-08-19T15:49:54  <wumpus> I can just smell the scope creep
3952016-08-19T15:50:09  <wumpus> don't let gmaxwell get involved in this except for security review :)
3962016-08-19T15:50:18  *** Lysanders has quit IRC
3972016-08-19T15:50:30  <jonasschnelli> We could start with an additional signatures file (per release including all platforms/binaries)
3982016-08-19T15:50:36  <kanzure> re: "one additional file" -- i thought that was the point of tar? :)
3992016-08-19T15:50:41  <wumpus> otherwise we'll never have an actually deployable product, just a lot of nice theory
4002016-08-19T15:50:42  <wumpus> :P
4012016-08-19T15:50:55  <jonasschnelli> though, that signature file may be changed after a release if we get additional signatures
4022016-08-19T15:51:04  <wumpus> yes, additional signatures could be added to that file
4032016-08-19T15:51:18  <jonasschnelli> But its a manual process I guess... which sucks
4042016-08-19T15:51:21  <wumpus> it's just a concatentation of people's signatures of the same thing
4052016-08-19T15:51:28  <jonasschnelli> The gitian.sig repo would probably be simpler
4062016-08-19T15:51:29  <wumpus> could be fully automated
4072016-08-19T15:51:36  <wumpus> python scirpt that pulls stuff from git
4082016-08-19T15:51:40  <wumpus> concatenates it
4092016-08-19T15:51:42  <jonasschnelli> Yes. Why not
4102016-08-19T15:51:42  <wumpus> drops it on the site
4112016-08-19T15:51:46  <wumpus> voila
4122016-08-19T15:52:05  <jonasschnelli> But not sure if the site is protected with some non-automatable 2FA technique or so.
4132016-08-19T15:52:06  <wumpus> could run in a crontab such
4142016-08-19T15:52:15  <wumpus> it could be any site
4152016-08-19T15:52:20  <jonasschnelli> crontab means the credentials must be available on that machine
4162016-08-19T15:52:24  <wumpus> where to drop the signatures? that's a good question
4172016-08-19T15:52:27  <jonasschnelli> yes. Could be a different site
4182016-08-19T15:52:33  <wumpus> heck, it could be a githib statically hosted site
4192016-08-19T15:52:38  <jonasschnelli> indeed
4202016-08-19T15:52:40  <wumpus> laanwj.github.com/bla
4212016-08-19T15:52:54  <jonasschnelli> Even simpler... it could be in gitian.sigs
4222016-08-19T15:53:13  <jonasschnelli> or yes... on a static site
4232016-08-19T15:53:18  <wumpus> could be, but rememer it needs to be a static http site
4242016-08-19T15:53:24  <wumpus> putting it on github has the https probem again
4252016-08-19T15:53:37  <wumpus> well, I mean as a git-based on github
4262016-08-19T15:53:42  <wumpus> github static sites are http
4272016-08-19T15:53:44  <jonasschnelli> We could add libcurl to our dependencies... *duck*
4282016-08-19T15:53:51  <wumpus> :-(
4292016-08-19T15:53:57  <jonasschnelli> But wait!
4302016-08-19T15:54:01  <jonasschnelli> We could use Qt headless
4312016-08-19T15:54:10  <jonasschnelli> no need to build windows.
4322016-08-19T15:54:12  <wumpus> the point would be to make the user download it themselves I think
4332016-08-19T15:54:26  <wumpus> if it needs to work without network conenction
4342016-08-19T15:54:47  <jonasschnelli> both could be possible...
4352016-08-19T15:54:50  <wumpus> or just use libevent's http client?
4362016-08-19T15:54:55  <wumpus> we already have that
4372016-08-19T15:55:02  <jonasschnelli> Yes. Why not...
4382016-08-19T15:55:13  <wumpus> it's super-simple, but good enough to fetch a simple small binary or text file, if you really want
4392016-08-19T15:55:24  <wumpus> (over http though, forget https)
4402016-08-19T15:56:31  <wumpus> we have secp256k1 for signature verification, we have sha256 hashing, and we can fetch files over http through evhttp. I think all the components are there
4412016-08-19T15:56:51  <jonasschnelli> Yes
4422016-08-19T15:57:06  <wumpus> (that doesn't mean the implementation is trivial! but let's not talk about adding dependencies :-)
4432016-08-19T15:57:59  <jonasschnelli> On OSX and Windows, the verify tool should probably have a GUI
4442016-08-19T15:58:01  <wumpus> it also doesn't need to rely on qt, although for end-users a qt user interface for it would be nice
4452016-08-19T15:58:20  <wumpus> ye
4462016-08-19T15:58:29  <jonasschnelli> We could detect the platform (or maybe if a WM is attached on Linux) and create a UI in that case
4472016-08-19T15:58:41  <jonasschnelli> Or..
4482016-08-19T15:58:58  <jonasschnelli> we provide the verification-feature in Bitcoin-Qt and in the new cli only verify tool
4492016-08-19T15:58:59  <wumpus> yea, or have separate verification-cli and verification-gui executables
4502016-08-19T15:59:18  <jonasschnelli> or that. yes
4512016-08-19T15:59:20  <wumpus> right, that is possible too
4522016-08-19T15:59:49  <jonasschnelli> But another GUI tool would require some tweaks in the EXE/DMG deployment
4532016-08-19T15:59:52  <wumpus> it has the advantage of not having to package qt twice, as long as we still statically lnk
4542016-08-19T15:59:57  <wumpus> right, and that
4552016-08-19T16:00:11  <wumpus> so having only one GUI executable which has it as extra menu option would be better probably
4562016-08-19T16:00:12  <jonasschnelli> Ah. Yes
4572016-08-19T16:00:21  <jonasschnelli> Indeed
4582016-08-19T16:00:56  <wumpus> then have a seprrate cli verification executable
4592016-08-19T16:00:56  <jonasschnelli> Okay... will try to work out something...
4602016-08-19T16:01:02  <wumpus> thanks!
4612016-08-19T16:01:37  <jonasschnelli> For creating the signatures, I guess it can be a third party tool.. don't need to be part of Bitcoin-Core
4622016-08-19T16:02:01  <wumpus> certainly not
4632016-08-19T16:02:15  <wumpus> I'll just roll some script for that, don't worry about that side :)
4642016-08-19T16:03:37  *** Kexkey has joined #bitcoin-core-dev
4652016-08-19T16:05:28  <wumpus> I'll have a try at the gitian builder side
4662016-08-19T16:06:35  <wumpus> (I wasn't serious about gmaxwell, to be clear)
4672016-08-19T16:07:00  <gmaxwell> Why would we create a shitty NIH version of the openbsd signify tool?
4682016-08-19T16:07:13  <gmaxwell> There is no security advantage from just changing the underlying cryptosystem.
4692016-08-19T16:07:34  <wumpus> it's just easier to integrate in our software than using gpg
4702016-08-19T16:08:40  *** BashCo has joined #bitcoin-core-dev
4712016-08-19T16:09:08  <wumpus> if we could integrate a gpg lib and fetch the signatures from gitian.sigs repository and verify directly (like gitian-downloader) it'd be much more straightforward, but we need something that can be integrated into our software release right?
4722016-08-19T16:09:25  <jonasschnelli> Yes
4732016-08-19T16:10:33  <GitHub20> [bitcoin] btcdrak opened pull request #8547: Update btcdrak key with new expiry dates (master...btcdrak-key) https://github.com/bitcoin/bitcoin/pull/8547
4742016-08-19T16:32:28  <GitHub196> [bitcoin] MarcoFalke opened pull request #8548: [wallet]  Use __func__ to get function name for output printing (master...Mf1608-walletFunc) https://github.com/bitcoin/bitcoin/pull/8548
4752016-08-19T16:36:15  *** Chris_Stewart_5 has quit IRC
4762016-08-19T16:39:49  <GitHub187> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f4e777819c54...56ac0469609a
4772016-08-19T16:39:49  <GitHub187> bitcoin/master 7e5d94d Jonas Schnelli: [Wallet] Trivial cleanup of HD wallet changes
4782016-08-19T16:39:50  <GitHub187> bitcoin/master 56ac046 Jonas Schnelli: Merge #8443: [Wallet] Trivial cleanup of HD wallet changes...
4792016-08-19T16:39:59  <GitHub184> [bitcoin] jonasschnelli closed pull request #8443: [Wallet] Trivial cleanup of HD wallet changes (master...2016/08/hd_fixes) https://github.com/bitcoin/bitcoin/pull/8443
4802016-08-19T16:48:07  <GitHub136> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/56ac0469609a...2468292a0353
4812016-08-19T16:48:07  <GitHub136> bitcoin/master 914154f Jonas Schnelli: [Qt] add HD enabled/disabled icon to the status bar
4822016-08-19T16:48:08  <GitHub136> bitcoin/master 2468292 Jonas Schnelli: Merge #8517: [Qt] show wallet HD state in statusbar...
4832016-08-19T16:48:17  <GitHub179> [bitcoin] jonasschnelli closed pull request #8517: [Qt] show wallet HD state in statusbar (master...2016/08/hd_gui) https://github.com/bitcoin/bitcoin/pull/8517
4842016-08-19T16:59:07  *** cryptapus_afk is now known as cryptapus
4852016-08-19T17:06:12  *** Guest79951 has joined #bitcoin-core-dev
4862016-08-19T17:07:08  *** zooko has joined #bitcoin-core-dev
4872016-08-19T17:08:08  <GitHub42> [bitcoin] jmcorgan opened pull request #8549: zmq: mempool notifications (master...zmq_mempool) https://github.com/bitcoin/bitcoin/pull/8549
4882016-08-19T17:11:21  *** zooko` has joined #bitcoin-core-dev
4892016-08-19T17:11:24  *** Kexkey has quit IRC
4902016-08-19T17:13:26  *** zooko has quit IRC
4912016-08-19T17:21:04  *** zooko` has quit IRC
4922016-08-19T17:47:41  *** rubensayshi has quit IRC
4932016-08-19T18:08:12  *** Guyver2_ has joined #bitcoin-core-dev
4942016-08-19T18:10:58  *** Guyver2 has quit IRC
4952016-08-19T18:11:05  *** Guyver2_ is now known as Guyver2
4962016-08-19T18:33:06  *** laurentmt has joined #bitcoin-core-dev
4972016-08-19T18:46:05  *** laurentmt has quit IRC
4982016-08-19T18:47:13  *** laurentmt has joined #bitcoin-core-dev
4992016-08-19T18:49:40  *** spudowiar has quit IRC
5002016-08-19T18:55:53  *** laurentmt has quit IRC
5012016-08-19T18:58:08  *** kadoban has quit IRC
5022016-08-19T19:11:06  *** JZA has quit IRC
5032016-08-19T19:11:20  *** JZA has joined #bitcoin-core-dev
5042016-08-19T19:23:45  *** Giszmo has joined #bitcoin-core-dev
5052016-08-19T19:31:07  <GitHub95> [bitcoin] jonasschnelli opened pull request #8550: [Qt] Add interactive mempool graph (master...2016/08/stats_qt) https://github.com/bitcoin/bitcoin/pull/8550
5062016-08-19T19:54:54  *** eragmus has quit IRC
5072016-08-19T19:55:33  *** eragmus has joined #bitcoin-core-dev
5082016-08-19T20:07:46  *** LeMiner has quit IRC
5092016-08-19T20:07:58  *** LeMiner has joined #bitcoin-core-dev
5102016-08-19T20:22:05  *** MarcoFalke has left #bitcoin-core-dev
5112016-08-19T20:34:01  *** whphhg has quit IRC
5122016-08-19T20:34:15  *** whphhg has joined #bitcoin-core-dev
5132016-08-19T20:45:38  *** MarcoFalke has joined #bitcoin-core-dev
5142016-08-19T20:45:40  <GitHub4> [bitcoin] MarcoFalke opened pull request #8551: [qa] Remove unused code (master...Mf1608-qaUnused) https://github.com/bitcoin/bitcoin/pull/8551
5152016-08-19T21:02:37  *** Guyver2 has quit IRC
5162016-08-19T21:04:49  *** zooko has joined #bitcoin-core-dev
5172016-08-19T21:06:58  *** mman454 has joined #bitcoin-core-dev
5182016-08-19T21:09:20  *** JZA has joined #bitcoin-core-dev
5192016-08-19T21:12:25  *** laurentmt has joined #bitcoin-core-dev
5202016-08-19T21:12:51  *** pmienk has joined #bitcoin-core-dev
5212016-08-19T21:14:51  *** mman454 has quit IRC
5222016-08-19T21:18:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5232016-08-19T21:19:41  *** laurentmt has quit IRC
5242016-08-19T21:38:37  *** Chris_Stewart_5 has quit IRC
5252016-08-19T21:39:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5262016-08-19T21:42:28  *** skyraider has quit IRC
5272016-08-19T21:47:20  *** dstadulis has joined #bitcoin-core-dev
5282016-08-19T21:55:31  *** Cheeseo has quit IRC
5292016-08-19T21:59:31  *** laurentmt has joined #bitcoin-core-dev
5302016-08-19T22:00:15  *** laurentmt has quit IRC
5312016-08-19T22:01:26  *** Chris_Stewart_5 has quit IRC
5322016-08-19T22:15:12  *** cryptapus is now known as cryptapus_afk
5332016-08-19T22:27:03  *** zooko has quit IRC
5342016-08-19T22:37:10  *** jannes has quit IRC
5352016-08-19T23:04:04  *** Giszmo1 has joined #bitcoin-core-dev
5362016-08-19T23:06:32  *** Giszmo has quit IRC
5372016-08-19T23:32:05  *** spudowiar has joined #bitcoin-core-dev
5382016-08-19T23:37:38  *** AureliusM has quit IRC
5392016-08-19T23:52:54  *** spudowiar has quit IRC
5402016-08-19T23:55:01  *** JZA has quit IRC
5412016-08-19T23:55:42  *** spudowiar has joined #bitcoin-core-dev