12016-11-17T00:37:58  *** adiabat has joined #bitcoin-core-dev
  22016-11-17T00:39:26  <jtimon> petertodd: regarding your last comment on the removign ISM thread...do you mean restoring ISM and then adding your new rule as a SF?
  32016-11-17T00:40:43  <jtimon> is the point to remove ISM later with a coordinated HF?
  42016-11-17T00:44:34  <BlueMatt> -rw------- 1 matt matt 1.7T Nov 16 16:44 /home/matt/.bitcoin/debug.log
  52016-11-17T00:44:36  <BlueMatt> lol
  62016-11-17T01:31:38  *** shangzhou has quit IRC
  72016-11-17T01:42:38  *** Ylbam has quit IRC
  82016-11-17T01:44:11  *** shangzhou has joined #bitcoin-core-dev
  92016-11-17T01:46:17  *** ybit has joined #bitcoin-core-dev
 102016-11-17T01:49:14  *** abpa has quit IRC
 112016-11-17T01:49:46  *** abpa has joined #bitcoin-core-dev
 122016-11-17T01:52:12  <shangzhou> gmaxwell: i did some search this morning at baidu. Searched "c1726ccc50635795c942c7d7e51d979c4f83a3d17f8982e9d02a114a15fef419" only one result (a thread http://8btc.com/thread-41510-1-5.html) someone use Avast complain that bitcoin 0.13.1 win exe downloaded from bitcoin.org was blocked by the avast. Search something like "bitcoin 0.13.1 win exe" top one is
 132016-11-17T01:52:12  <shangzhou> bitcoin.org's download link.
 142016-11-17T01:54:01  *** abpa has quit IRC
 152016-11-17T02:22:16  <bitcoin-git> [bitcoin] Christewart opened pull request #9174: Modifying incorrect comments from BIP66 -> BIP62 (master...master) https://github.com/bitcoin/bitcoin/pull/9174
 162016-11-17T02:59:52  *** DigiByteDev has joined #bitcoin-core-dev
 172016-11-17T03:00:53  *** Giszmo has quit IRC
 182016-11-17T03:14:39  *** veleiro has joined #bitcoin-core-dev
 192016-11-17T03:17:20  <veleiro> herro, tag release 13.1 on debian stretch 'make' gives me this: https://paste.debian.net/plain/896347 wat wrong :(
 202016-11-17T03:28:51  *** btcdrak has joined #bitcoin-core-dev
 212016-11-17T03:47:42  *** Chris_Stewart_5 has quit IRC
 222016-11-17T03:56:37  *** DigiByteDev has quit IRC
 232016-11-17T04:01:38  *** shangzhou has quit IRC
 242016-11-17T04:07:40  *** nickler has quit IRC
 252016-11-17T04:11:46  <sipa> veleiro: my guess is that you have too little memory
 262016-11-17T04:28:28  <veleiro> sipa: youre probably right. i'm so sure to doing make -j4? it uses too many resources is my guess
 272016-11-17T04:28:45  <veleiro> i just did a normal 'make' and it was a success..
 282016-11-17T04:29:12  <veleiro> s/i'm so sure/i'm so use
 292016-11-17T04:29:28  <veleiro> thanks~
 302016-11-17T04:39:40  <luke-jr> #bitcoin is the support channel btw
 312016-11-17T04:44:30  <veleiro> sorry luke-jr, its a big community now days. i didnt mean to bloat this chan
 322016-11-17T04:45:37  <luke-jr> np, just clarifying for next time
 332016-11-17T04:46:44  *** nickler has joined #bitcoin-core-dev
 342016-11-17T04:47:54  *** PaulCapestany has quit IRC
 352016-11-17T04:49:41  <bitcoin-git> [bitcoin] mruddy opened pull request #9175: remove script checking dependency on checkpoints (master...script_check) https://github.com/bitcoin/bitcoin/pull/9175
 362016-11-17T04:49:46  *** PaulCapestany has joined #bitcoin-core-dev
 372016-11-17T05:08:25  *** aalex has joined #bitcoin-core-dev
 382016-11-17T05:12:34  *** DigiByteDev has joined #bitcoin-core-dev
 392016-11-17T05:15:04  *** aalex has quit IRC
 402016-11-17T06:25:19  *** rabidus has quit IRC
 412016-11-17T06:32:56  *** dgenr8 has joined #bitcoin-core-dev
 422016-11-17T06:45:46  <bitcoin-git> [bitcoin] jtimon opened pull request #9176: Globals: Pass Consensus::Params through CBlockTreeDB::LoadBlockIndexGuts() (master...0.13-chainparams-loadblockindexguts) https://github.com/bitcoin/bitcoin/pull/9176
 432016-11-17T06:57:48  *** Ylbam has joined #bitcoin-core-dev
 442016-11-17T07:01:07  <bitcoin-git> [bitcoin] jtimon opened pull request #9177: NOMERGE: WIP: Support block signed custom testchains (master...0.13-blocksign) https://github.com/bitcoin/bitcoin/pull/9177
 452016-11-17T07:01:36  *** rabidus has joined #bitcoin-core-dev
 462016-11-17T07:12:14  *** aalex has joined #bitcoin-core-dev
 472016-11-17T07:12:14  *** tunafizz has quit IRC
 482016-11-17T07:19:43  *** aalex has quit IRC
 492016-11-17T07:21:44  *** tunafizz has joined #bitcoin-core-dev
 502016-11-17T07:24:20  *** tunafizz has quit IRC
 512016-11-17T07:26:53  *** roidster has quit IRC
 522016-11-17T07:28:37  *** tunafizz has joined #bitcoin-core-dev
 532016-11-17T07:32:37  *** tunafizz has quit IRC
 542016-11-17T07:38:42  *** MarcoFalke has joined #bitcoin-core-dev
 552016-11-17T07:43:18  *** tunafizz has joined #bitcoin-core-dev
 562016-11-17T07:48:12  *** tunafizz has quit IRC
 572016-11-17T07:49:11  *** tunafizz has joined #bitcoin-core-dev
 582016-11-17T08:16:06  *** droark has quit IRC
 592016-11-17T08:16:38  *** tunafizz has quit IRC
 602016-11-17T08:17:33  *** tunafizz has joined #bitcoin-core-dev
 612016-11-17T08:18:28  *** MarcoFalke has quit IRC
 622016-11-17T08:27:49  *** tunafizz has quit IRC
 632016-11-17T08:28:11  *** tunafizz has joined #bitcoin-core-dev
 642016-11-17T08:30:42  *** rubensayshi has joined #bitcoin-core-dev
 652016-11-17T08:32:34  *** tunafizz has quit IRC
 662016-11-17T08:34:57  *** tunafizz has joined #bitcoin-core-dev
 672016-11-17T08:39:37  *** tunafizz has quit IRC
 682016-11-17T08:40:51  *** tunafizz has joined #bitcoin-core-dev
 692016-11-17T09:04:24  *** tunafizz has quit IRC
 702016-11-17T09:09:11  *** Guyver2 has joined #bitcoin-core-dev
 712016-11-17T09:11:14  *** tunafizz has joined #bitcoin-core-dev
 722016-11-17T09:19:30  *** tunafizz has quit IRC
 732016-11-17T09:20:58  *** tunafizz has joined #bitcoin-core-dev
 742016-11-17T09:26:00  *** AaronvanW has quit IRC
 752016-11-17T09:29:22  <petertodd> jtimon: no, I mean, making chains other than the existing one invalid unless they follow the new rules
 762016-11-17T09:29:33  *** AaronvanW has joined #bitcoin-core-dev
 772016-11-17T09:29:33  *** AaronvanW has quit IRC
 782016-11-17T09:29:33  *** AaronvanW has joined #bitcoin-core-dev
 792016-11-17T09:29:52  <petertodd> jtimon: that still allows reorgs - it's not a checkpoint - but allows you to remove all the ISM logic.
 802016-11-17T09:30:37  <petertodd> jtimon: of course, by "allows reorgs" - it mainly only allows truly massive reorgs, but I think that's sufficient to keep this from being a checkpoint
 812016-11-17T09:33:18  *** tunafizz has quit IRC
 822016-11-17T09:33:36  *** tunafizz has joined #bitcoin-core-dev
 832016-11-17T09:38:19  *** JackH has joined #bitcoin-core-dev
 842016-11-17T09:43:29  *** laurentmt has joined #bitcoin-core-dev
 852016-11-17T09:43:50  *** laurentmt has quit IRC
 862016-11-17T09:47:39  *** DigiByteDev has quit IRC
 872016-11-17T09:57:39  *** tunafizz has quit IRC
 882016-11-17T10:00:48  *** tunafizz has joined #bitcoin-core-dev
 892016-11-17T10:07:54  *** aalex has joined #bitcoin-core-dev
 902016-11-17T10:07:56  *** tunafizz has quit IRC
 912016-11-17T10:08:35  *** tunafizz has joined #bitcoin-core-dev
 922016-11-17T10:14:34  *** aalex has quit IRC
 932016-11-17T10:24:55  *** arowser has quit IRC
 942016-11-17T10:26:29  *** arowser has joined #bitcoin-core-dev
 952016-11-17T10:29:25  *** jtimon has quit IRC
 962016-11-17T10:34:45  *** MarcoFalke_web has joined #bitcoin-core-dev
 972016-11-17T10:43:27  *** sanada has quit IRC
 982016-11-17T10:44:04  *** sanada has joined #bitcoin-core-dev
 992016-11-17T10:47:18  *** tunafizz has quit IRC
1002016-11-17T10:48:53  *** tunafizz has joined #bitcoin-core-dev
1012016-11-17T10:53:11  *** DigiByteDev has joined #bitcoin-core-dev
1022016-11-17T10:53:15  *** tunafizz has quit IRC
1032016-11-17T10:54:16  *** tunafizz has joined #bitcoin-core-dev
1042016-11-17T10:56:04  *** DigiByteDev has quit IRC
1052016-11-17T11:07:48  *** tunafizz has quit IRC
1062016-11-17T11:09:41  *** tunafizz has joined #bitcoin-core-dev
1072016-11-17T11:27:52  *** tunafizz has quit IRC
1082016-11-17T11:28:21  *** tunafizz has joined #bitcoin-core-dev
1092016-11-17T11:49:43  *** DigiByteDev has joined #bitcoin-core-dev
1102016-11-17T11:49:46  <morcos> petertodd: yes that is what i was saying as well, i just don't know how to do that efficiently
1112016-11-17T11:50:50  *** DigiByteDev has quit IRC
1122016-11-17T11:56:22  *** tunafizz has quit IRC
1132016-11-17T11:57:14  *** tunafizz has joined #bitcoin-core-dev
1142016-11-17T12:23:43  *** Guyver2__ has joined #bitcoin-core-dev
1152016-11-17T12:26:26  *** Guyver2 has quit IRC
1162016-11-17T12:26:27  *** Guyver2__ is now known as Guyver2
1172016-11-17T12:41:09  *** shesek has quit IRC
1182016-11-17T12:41:35  *** Guyver2__ has joined #bitcoin-core-dev
1192016-11-17T12:45:02  *** Guyver2 has quit IRC
1202016-11-17T12:45:09  *** Guyver2__ is now known as Guyver2
1212016-11-17T12:54:55  *** shesek has joined #bitcoin-core-dev
1222016-11-17T12:58:05  <wumpus> what is the proper way to pass arguments to the secp256k1 configure script that is invoked by bitcoin's?
1232016-11-17T13:01:48  *** windsok has quit IRC
1242016-11-17T13:03:16  <wumpus> oh nm I can just pass "--with-asm=arm --enable-experimental" to the outer configure and it works. doh
1252016-11-17T13:04:11  <wumpus> ... I'd been manually patching configure.ac all that time :-)
1262016-11-17T13:06:46  *** cryptapus has joined #bitcoin-core-dev
1272016-11-17T13:06:46  *** cryptapus has joined #bitcoin-core-dev
1282016-11-17T13:07:50  <luke-jr> hehe
1292016-11-17T13:09:02  <wumpus> never tried as I expected it to croak on unknown arguments
1302016-11-17T13:10:00  <luke-jr> there's an argument to make it not even warn :D
1312016-11-17T13:10:24  *** windsok has joined #bitcoin-core-dev
1322016-11-17T13:11:04  *** tunafizz has quit IRC
1332016-11-17T13:11:25  *** tunafizz has joined #bitcoin-core-dev
1342016-11-17T13:15:30  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cb2ed300a89e...f6db48ad1c8f
1352016-11-17T13:15:31  <bitcoin-git> bitcoin/master 5f274a1 jnewbery: log block size and weight correctly.
1362016-11-17T13:15:31  <bitcoin-git> bitcoin/master f6db48a Wladimir J. van der Laan: Merge #8838: Calculate size and weight of block correctly in CreateNewBlock()...
1372016-11-17T13:19:18  <bitcoin-git> [bitcoin] Christewart closed pull request #9174: Modifying incorrect comments from BIP66 -> BIP62 (master...master) https://github.com/bitcoin/bitcoin/pull/9174
1382016-11-17T13:25:57  *** aalex has joined #bitcoin-core-dev
1392016-11-17T13:26:24  *** tunafizz has quit IRC
1402016-11-17T13:27:33  *** tunafizz has joined #bitcoin-core-dev
1412016-11-17T13:32:21  *** tunafizz has quit IRC
1422016-11-17T13:33:25  *** aalex has quit IRC
1432016-11-17T13:34:23  *** tunafizz has joined #bitcoin-core-dev
1442016-11-17T13:35:45  *** MarcoFalke has joined #bitcoin-core-dev
1452016-11-17T13:39:29  *** roidster has joined #bitcoin-core-dev
1462016-11-17T13:39:38  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #9178: Doxygen: Set PROJECT_NAME = "Bitcoin Core" (master...Mf1611-doc) https://github.com/bitcoin/bitcoin/pull/9178
1472016-11-17T13:40:32  *** cryptapus_afk has quit IRC
1482016-11-17T13:49:57  *** MarcoFalke has quit IRC
1492016-11-17T13:51:15  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1502016-11-17T13:51:59  *** cryptapus_afk has joined #bitcoin-core-dev
1512016-11-17T13:51:59  *** cryptapus_afk has joined #bitcoin-core-dev
1522016-11-17T14:10:21  *** DigiByteDev has joined #bitcoin-core-dev
1532016-11-17T14:20:38  *** Chris_Stewart_5 has quit IRC
1542016-11-17T14:24:47  *** shesek has quit IRC
1552016-11-17T14:29:26  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f6db48ad1c8f...aaca05c0dabd
1562016-11-17T14:29:26  <bitcoin-git> bitcoin/master fa63ee8 MarcoFalke: Doxygen: Set PROJECT_NAME = "Bitcoin Core"
1572016-11-17T14:29:26  <bitcoin-git> bitcoin/master aaca05c Wladimir J. van der Laan: Merge #9178: Doxygen: Set PROJECT_NAME = "Bitcoin Core"...
1582016-11-17T14:29:41  <bitcoin-git> [bitcoin] laanwj closed pull request #9178: Doxygen: Set PROJECT_NAME = "Bitcoin Core" (master...Mf1611-doc) https://github.com/bitcoin/bitcoin/pull/9178
1592016-11-17T14:30:46  *** MarcoFalke_web has quit IRC
1602016-11-17T14:32:39  *** MarcoFalke_web has joined #bitcoin-core-dev
1612016-11-17T14:35:12  *** harrymm has quit IRC
1622016-11-17T14:38:06  *** harrymm has joined #bitcoin-core-dev
1632016-11-17T14:38:22  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1642016-11-17T14:44:37  *** shesek has joined #bitcoin-core-dev
1652016-11-17T14:45:21  *** veleiro has quit IRC
1662016-11-17T14:48:41  *** aalex has joined #bitcoin-core-dev
1672016-11-17T14:50:52  <instagibbs> Chris_Stewart_5, so malleability in this context is not txid malleability
1682016-11-17T14:51:12  <instagibbs> rather witness malleability. Some joker relayer could stuff transactions with junk data and the transaction is still valid
1692016-11-17T14:51:48  *** Giszmo has joined #bitcoin-core-dev
1702016-11-17T14:53:48  *** To7 has quit IRC
1712016-11-17T14:54:52  <Chris_Stewart_5> instagibbs: I still don't understand the 'empty byte array' thing, and I also can't seem to find where this empty byte array is pushed onto the stack in the codebase
1722016-11-17T14:55:12  <Chris_Stewart_5> I get why we have all the other checks inside of CheckSignatureEncoding: https://github.com/bitcoin/bitcoin/blob/35fe0393f216aa6020fc929272118eade5628636/src/script/interpreter.cpp#L185
1732016-11-17T14:56:24  <Chris_Stewart_5> The way I read BIP146, it's almost saying that you cannot place a OP_FALSE onto the stack unless OP_CHECKSIG had as input an empty byte array as a signature, but of course that doesn't make sense
1742016-11-17T14:56:42  <Chris_Stewart_5> https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki#nullfail
1752016-11-17T14:58:37  *** cannon-c has joined #bitcoin-core-dev
1762016-11-17T14:58:56  *** cannon-c has left #bitcoin-core-dev
1772016-11-17T15:06:28  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/aaca05c0dabd...a8b2a82618be
1782016-11-17T15:06:28  <bitcoin-git> bitcoin/master d8274bc Jonas Schnelli: Add compile and link options echo to configure
1792016-11-17T15:06:29  <bitcoin-git> bitcoin/master a8b2a82 Wladimir J. van der Laan: Merge #9156: Add compile and link options echo to configure...
1802016-11-17T15:06:43  <bitcoin-git> [bitcoin] laanwj closed pull request #9156: Add compile and link options echo to configure (master...2016/11/configure) https://github.com/bitcoin/bitcoin/pull/9156
1812016-11-17T15:14:10  *** Chris_Stewart_5 has quit IRC
1822016-11-17T15:18:20  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1832016-11-17T15:24:00  *** dgenr8 has quit IRC
1842016-11-17T15:24:02  *** laurentmt has joined #bitcoin-core-dev
1852016-11-17T15:26:22  *** laurentmt has quit IRC
1862016-11-17T15:56:00  <instagibbs> Chris_Stewart_5, not sure how you are confused here: "If an OP_CHECKSIG is trying to return a FALSE value to the stack, we require that the relevant signature must be an empty byte array."
1872016-11-17T15:56:18  <instagibbs> if a checksig is to fail, signatures must be false as well
1882016-11-17T15:57:02  <instagibbs> false aka ""
1892016-11-17T16:00:18  *** Chris_Stewart_5 has quit IRC
1902016-11-17T16:15:25  *** laurentmt has joined #bitcoin-core-dev
1912016-11-17T16:16:07  *** laurentmt has quit IRC
1922016-11-17T16:18:05  *** DigiByteDev has quit IRC
1932016-11-17T16:22:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1942016-11-17T16:28:25  <sipa> Chris_Stewart_5: it is not talking about OP_FALSE, but about a FALSE returned by checksig
1952016-11-17T16:32:59  *** MarcoFalke_web has quit IRC
1962016-11-17T16:45:08  <morcos> cfields: yeah i ran a longer test and your new branch doesn't really provide any benefit but the old one still provides a significant improvement
1972016-11-17T16:45:38  <Chris_Stewart_5> sipa: "any BIP66-compliant non-empty byte array but not a valid signature" - this means that it is not a valid signature wrt to the public key in the script, right?
1982016-11-17T16:47:37  <Chris_Stewart_5> and if so, how can this fail immediately without checking the signature: https://github.com/bitcoin/bitcoin/blob/35fe0393f216aa6020fc929272118eade5628636/src/script/interpreter.cpp#L880
1992016-11-17T16:54:17  <sipa> Chris_Stewart_5: see 4 lines up
2002016-11-17T17:01:45  *** Sosumi has joined #bitcoin-core-dev
2012016-11-17T17:02:45  <Chris_Stewart_5> Is the only difference between CheckSignatureEncoding & IsValidSignatureEncoding the LOW_S check & trivially passes the empty byte array as a sig
2022016-11-17T17:10:28  <Chris_Stewart_5> I guess my real question is could 'F' in the examples be a LOW_S sig https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki#examples
2032016-11-17T17:10:59  <Chris_Stewart_5> sorry HIGH_S I guess
2042016-11-17T17:12:10  *** Victorsueca has quit IRC
2052016-11-17T17:23:51  *** rubensayshi has quit IRC
2062016-11-17T17:31:18  *** abpa has joined #bitcoin-core-dev
2072016-11-17T17:35:37  *** Sosumi has quit IRC
2082016-11-17T17:36:46  *** Chris_Stewart_5 has quit IRC
2092016-11-17T17:51:42  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2102016-11-17T17:53:34  *** sdaftuar has quit IRC
2112016-11-17T17:57:42  *** MarcoFalke has joined #bitcoin-core-dev
2122016-11-17T18:05:45  *** MarcoFalke has left #bitcoin-core-dev
2132016-11-17T18:07:18  *** Chris_Stewart_5 has quit IRC
2142016-11-17T18:07:44  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2152016-11-17T18:10:23  *** jtimon has joined #bitcoin-core-dev
2162016-11-17T18:48:36  *** BonyM1 has quit IRC
2172016-11-17T18:50:56  *** jcorgan has joined #bitcoin-core-dev
2182016-11-17T18:56:28  *** MarcoFalke_web has joined #bitcoin-core-dev
2192016-11-17T19:01:13  <achow101> meeting?
2202016-11-17T19:01:13  <CodeShark> Meeting time?
2212016-11-17T19:01:44  <jcorgan> whew, though i borked up the time zone again
2222016-11-17T19:01:50  <jcorgan> *thought
2232016-11-17T19:01:57  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
2242016-11-17T19:02:01  <jonasschnelli> here
2252016-11-17T19:02:05  <kanzure> hi.
2262016-11-17T19:02:07  <BlueMatt> oh, hey
2272016-11-17T19:02:10  <instagibbs> hello
2282016-11-17T19:02:21  <petertodd> hi
2292016-11-17T19:03:13  <michagogo> o/
2302016-11-17T19:03:14  <cfields> grr, flaky inet. here now.
2312016-11-17T19:03:22  <michagogo> Wait, isn't it in an hour?
2322016-11-17T19:03:30  <michagogo> Or is the time defined in UTC?
2332016-11-17T19:03:37  <achow101> michagogo: UTC
2342016-11-17T19:03:48  *** BonyM1 has joined #bitcoin-core-dev
2352016-11-17T19:03:55  <jtimon> hi
2362016-11-17T19:04:09  <michagogo> Ah. I guess I've just missed them all since we switched off of DST
2372016-11-17T19:04:10  <jtimon> proposed topics?
2382016-11-17T19:04:21  <jonasschnelli> #startmeeting
2392016-11-17T19:04:21  <lightningbot> Meeting started Thu Nov 17 19:04:21 2016 UTC.  The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot.
2402016-11-17T19:04:21  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2412016-11-17T19:04:27  <wumpus> hello
2422016-11-17T19:05:09  <sipa> present
2432016-11-17T19:05:31  * michagogo looks at wumpus's @
2442016-11-17T19:05:34  <CodeShark> Hi
2452016-11-17T19:05:37  <jonasschnelli> No topic proposals?
2462016-11-17T19:05:50  <MarcoFalke_web> Short meeting, then :P
2472016-11-17T19:06:02  <instagibbs> ideas for account removal/replacement? I'm getting annoyed at account code :)
2482016-11-17T19:06:02  <sipa> can i ask a bit about shared_ptr changes?
2492016-11-17T19:06:32  <jonasschnelli> #topic shared_ptr
2502016-11-17T19:06:41  *** ChanServ sets mode: -o wumpus
2512016-11-17T19:06:42  <morcos> i have a topic, i'd like tot alk about priority
2522016-11-17T19:07:01  <sipa> the #topic is only recognized when said by the chair, i think
2532016-11-17T19:07:06  <morcos> also +1 instagibbs
2542016-11-17T19:07:14  <jonasschnelli> I'm the chair
2552016-11-17T19:07:19  <sipa> oh!
2562016-11-17T19:07:28  <instagibbs> sipa, better watch yourself ;)
2572016-11-17T19:07:37  * sipa will go stand in the corner
2582016-11-17T19:07:44  <sipa> so, i have a series of 3 PRs to introduce shared_ptr in more places
2592016-11-17T19:08:14  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/9125
2602016-11-17T19:08:20  <sipa> #9125, #8580, #8589
2612016-11-17T19:08:22  <gribble> https://github.com/bitcoin/bitcoin/issues/9125 | Make CBlock a vector of shared_ptr of CTransactions by sipa · Pull Request #9125 · bitcoin/bitcoin · GitHub
2622016-11-17T19:08:24  <gribble> https://github.com/bitcoin/bitcoin/issues/8580 | Make CTransaction actually immutable by sipa · Pull Request #8580 · bitcoin/bitcoin · GitHub
2632016-11-17T19:08:25  <gribble> https://github.com/bitcoin/bitcoin/issues/8589 | Inline CTxInWitness inside CTxIn (on top of #8580) by sipa · Pull Request #8589 · bitcoin/bitcoin · GitHub
2642016-11-17T19:09:05  <wumpus> I'm testing #9125
2652016-11-17T19:09:05  <sipa> the first i hope is a clear improvement and necessary refactor for the ones that follow (and it's 3-4% reindex performance improvement)
2662016-11-17T19:09:06  <gribble> https://github.com/bitcoin/bitcoin/issues/9125 | Make CBlock a vector of shared_ptr of CTransactions by sipa · Pull Request #9125 · bitcoin/bitcoin · GitHub
2672016-11-17T19:09:29  <jonasschnelli> Do I understand it right that one of the key benefits of the shared_ptr transition are the concurrency benefits with less locking?
2682016-11-17T19:09:43  <sipa> that is a potential future advantage
2692016-11-17T19:09:44  <BlueMatt> sipa: concept ack+1000
2702016-11-17T19:09:45  <wumpus> also less copying
2712016-11-17T19:09:45  <gmaxwell> No.
2722016-11-17T19:09:46  <jonasschnelli> and less copis
2732016-11-17T19:09:47  <BlueMatt> to all of them
2742016-11-17T19:09:54  <sipa> but less copying is the immediate reason
2752016-11-17T19:09:58  <gmaxwell> Thats an abstract advantage of shared pointers.
2762016-11-17T19:10:01  <jonasschnelli> Okay.
2772016-11-17T19:10:16  <gmaxwell> But right avoiding copies is that it accomplishes here.
2782016-11-17T19:10:17  *** aalex_ has joined #bitcoin-core-dev
2792016-11-17T19:10:27  <jonasschnelli> So performance and memory? Right?
2802016-11-17T19:10:28  <sipa> the second one may be more controversial, as it affects the wallet code significantly, making CWalletTx not inherit from CTransaction anymore, and move it to a field
2812016-11-17T19:10:32  <cfields> sipa: is there any specific part of the first that you think needs extra scrutiny/testing?
2822016-11-17T19:10:38  <wumpus> sipa: YES
2832016-11-17T19:10:59  <sipa> wumpus: YES as in "do it" or YES as in "it's more controversial"
2842016-11-17T19:11:03  <wumpus> CWalleTx is pretty much the example of an abuse of inheritance
2852016-11-17T19:11:05  <wumpus> in OOP
2862016-11-17T19:11:11  <gmaxwell> wumpus: that was exactly my response.
2872016-11-17T19:11:12  <sipa> ok, glad you agree on that
2882016-11-17T19:11:38  <jonasschnelli> Yes. Also, is there a reason for the extra CMerkleTx inheritance?
2892016-11-17T19:11:46  <sipa> jonasschnelli: abuse of C++
2902016-11-17T19:11:49  <wumpus> wallettx should *contain* a line-level tx, plus metadata
2912016-11-17T19:11:50  <jonasschnelli> heh
2922016-11-17T19:12:02  <sipa> jonasschnelli: meaning you don't need to copy the interface
2932016-11-17T19:12:46  <sipa> and then inlining CTxInWitness is to just simplify the code
2942016-11-17T19:13:03  <sipa> (which is likely a small performance regression for non-witness txn, but an improvement for witness txn)
2952016-11-17T19:13:45  <sipa> if no further comments on that, i'm done with the topic
2962016-11-17T19:13:51  <jonasschnelli> While were at it, we should also remove "main.h" and "txmempool.h" from wallet.c (slightly OT) to avoid the circular dependency.
2972016-11-17T19:13:53  <wumpus> no comments, i think it's the way forward
2982016-11-17T19:14:11  <sipa> jonasschnelli: why is that a circular dependency?
2992016-11-17T19:14:11  <jonasschnelli> sipa: ack
3002016-11-17T19:14:12  <gmaxwell> why isn't it all done and merged yet? :P
3012016-11-17T19:14:12  *** aalex has quit IRC
3022016-11-17T19:14:23  <sipa> jonasschnelli: main and txmempool should not depend on wallet
3032016-11-17T19:14:32  <sipa> but wallet depending on main seems perfectly expected for me
3042016-11-17T19:14:34  <wumpus> wallet is allowed to depend on stuff in libbitcoin_server
3052016-11-17T19:14:42  <wumpus> just not the other way around
3062016-11-17T19:14:44  <jonasschnelli> sipa: have a look at https://github.com/bitcoin/bitcoin/pull/8745
3072016-11-17T19:15:24  <sipa> what should i see there?
3082016-11-17T19:15:37  <wumpus> I think we can discuss this outside the meeting? other more urgent topics?
3092016-11-17T19:15:45  <sipa> ah, i understnad
3102016-11-17T19:15:51  <jonasschnelli> Yes. Outside the meeting.
3112016-11-17T19:15:51  <sipa> yes, let's discuss design at another time
3122016-11-17T19:16:10  <jonasschnelli> morcos had the topic proposal "priority"
3132016-11-17T19:16:16  <morcos> Lets talk about potential for account or priority removal (2 separate topics)
3142016-11-17T19:16:27  <sipa> agree on topic
3152016-11-17T19:16:31  <jonasschnelli> #action account or priority removal
3162016-11-17T19:16:36  <jonasschnelli> #topic account or priority removal
3172016-11-17T19:16:36  <gmaxwell> lol
3182016-11-17T19:16:40  <jonasschnelli> :/
3192016-11-17T19:16:53  <morcos> I think luke-jr was the main proponent of keeping priority around, so if he's not here, maybe we need to postpone further discussion
3202016-11-17T19:17:08  <morcos> but it was my hope that we could all be in agreeement that it serves not much of a function any more
3212016-11-17T19:17:32  <morcos> Perhaps we can set a target for 0.15 if 0.14 is too close, but it would be nice to remove ALL of the priority code
3222016-11-17T19:17:46  <morcos> it would clean a lot of things up
3232016-11-17T19:17:49  <wumpus> I think that ship has already sailed?
3242016-11-17T19:17:54  <BlueMatt> morcos: ACK, but maybe 0.15
3252016-11-17T19:17:59  <BlueMatt> deprecate more formally in 0.14
3262016-11-17T19:18:09  <wumpus> I mean, we merged some stuff on the way for priority removal already
3272016-11-17T19:18:09  <morcos> BlueMatt: that makes sense to me
3282016-11-17T19:18:14  <BlueMatt> wumpus: not even eligius is doing any priority selection now...at the time maybe luke could have argued for it, but now.....
3292016-11-17T19:18:21  <sipa> we removed priority estimation
3302016-11-17T19:18:38  <jcorgan> is there any empirical data on miner behavior?
3312016-11-17T19:18:40  <morcos> wumpus: i mostly agree, but the removal of priority estimation was because it wasn't functional any more, so it was an easier decision
3322016-11-17T19:18:42  <sipa> all that is left is priority based mining, i think
3332016-11-17T19:19:04  <sipa> if it serves no function (and maybe we need a bit more data on that), it should be equally easy imho
3342016-11-17T19:19:13  <gmaxwell> I agree, I think any desire to keep it around could be answered by intelligent automatic use of fee delta. But this is going to get rehashed with luke later anyways. I think it's likely that everyone who regularly attends the meetings except luke agrees.
3352016-11-17T19:19:26  <morcos> there is also the free transactoin and rate limiting code
3362016-11-17T19:19:28  <wumpus> users can still set prioritizetransaction
3372016-11-17T19:20:09  <achow101> does priority estimation even work? estimatepriority just gives me -1 regardless
3382016-11-17T19:20:18  <sipa> achow101: priority estimation is removed
3392016-11-17T19:20:19  <morcos> achow101: thats why it is removed for 0.14
3402016-11-17T19:20:29  <sipa> achow101: the RPC remains for backward compatibility, but is a stub
3412016-11-17T19:20:30  <gmaxwell> jcorgan: some had been collected in the past when it was defaulted to off.  general result is that its not used ~anywhere anymore.
3422016-11-17T19:20:33  <wumpus> so if prioritization on some criterion that is not fee it can still be implemented outside of bitcoind
3432016-11-17T19:20:44  <morcos> it works, its just correctly telling you that no priority is high enough to get you mined quickluy
3442016-11-17T19:20:50  <achow101> ah, i see
3452016-11-17T19:21:01  <wumpus> heh
3462016-11-17T19:22:00  <morcos> back in a couple min
3472016-11-17T19:22:10  <jtimon> so I thought we were waiting on 0.14 for removing the priority, now we wait for 0.15?
3482016-11-17T19:22:47  <wumpus> is there any reason to hurry?
3492016-11-17T19:22:54  <sipa> jtimon: there seem to be at least 4 components to "removing the priority", i'm not sure they all need to happen simultaneously
3502016-11-17T19:23:10  <sipa> (rpc, estimation, mining, relay)
3512016-11-17T19:23:29  <jtimon> wumpus: no, any reason to wait ?
3522016-11-17T19:23:35  <wumpus> I'm sure no one is really waiting for it to be removed, it can be removed part by part and 0.15 is a fine target
3532016-11-17T19:23:40  <gmaxwell> relay is the only one I really care much about, because it currently causes bandwidth wasting relaying around junk that won't get mined.
3542016-11-17T19:23:50  <jtimon> if people want to work on that, I don't see why they should wait
3552016-11-17T19:23:53  <wumpus> jtimon: there are always other "priorities"
3562016-11-17T19:24:09  <MarcoFalke_web> Can we disable relay by default for .14?
3572016-11-17T19:24:46  <jonasschnelli> ack on DEFAULT_RELAYPRIORITY = false; for 0.14
3582016-11-17T19:25:05  <gmaxwell> I'd support that, if we don't go further.
3592016-11-17T19:25:23  <sipa> agree
3602016-11-17T19:25:25  <MarcoFalke_web> What do you mean with "go further"?
3612016-11-17T19:25:32  <wumpus> disabling by default always makes sense as a first step
3622016-11-17T19:25:36  <gmaxwell> MarcoFalke_web: remove the code entirely.
3632016-11-17T19:25:47  <MarcoFalke_web> #action DEFAULT_RELAYPRIORITY = false; for 0.14
3642016-11-17T19:25:59  <wumpus> even if you rip out the code two days later...
3652016-11-17T19:26:13  <jtimon> ok, I see, disable for 0.14 first what you want to remove for 0.15, that makes sense
3662016-11-17T19:26:34  <sipa> ok, account removal?
3672016-11-17T19:26:42  <MarcoFalke_web> next topic
3682016-11-17T19:26:50  *** cannon-c has joined #bitcoin-core-dev
3692016-11-17T19:26:55  <morcos> wait i'm confused
3702016-11-17T19:27:03  <gmaxwell> uh oh.
3712016-11-17T19:27:08  <morcos> what are the proposed changes to relay
3722016-11-17T19:27:22  <morcos> that priority doesn't let you skip the rate limiting
3732016-11-17T19:28:17  <morcos> ok nm, ignore me.  we are proposing that you always have to have minrelaytxfee
3742016-11-17T19:28:22  <gmaxwell> Yes.
3752016-11-17T19:28:29  <jonasschnelli> #topic "account removal"
3762016-11-17T19:28:39  <morcos> i don't think thats going to help too much with junk, but agree it would be good change
3772016-11-17T19:28:40  <gmaxwell> also, the help text for relaypriority is wrong/confusing. :P
3782016-11-17T19:28:56  *** sdaftuar has joined #bitcoin-core-dev
3792016-11-17T19:29:13  <MarcoFalke_web> I think we already have a pull open for this #7729
3802016-11-17T19:29:14  <morcos> account removal is more tricky
3812016-11-17T19:29:16  <wumpus> so I proposed a label API to replace accounts at the start of this year, it still hasn't had much review yet: https://github.com/bitcoin/bitcoin/pull/7729
3822016-11-17T19:29:17  <jonasschnelli> There is sill an open PR from wumpus to #7729 which is a step towards account removal
3832016-11-17T19:29:20  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
3842016-11-17T19:29:21  <jonasschnelli> heh
3852016-11-17T19:29:22  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
3862016-11-17T19:29:24  <wumpus> not sure there's anything new to discuss there
3872016-11-17T19:29:33  <gmaxwell> "Bitcoin developers oppose accountability."
3882016-11-17T19:30:04  <morcos> so the idea would be we have to have labels first
3892016-11-17T19:30:08  <morcos> maybe for a release or two
3902016-11-17T19:30:09  <jonasschnelli> morcos: what would be your approach for the removal-transition?
3912016-11-17T19:30:15  <morcos> and then we coudl remove accounts?
3922016-11-17T19:30:18  <wumpus> if people are ok with that proposal I'll go forward with it, but there's always so little attention on wallet related changes, let alone deprecating features
3932016-11-17T19:30:24  <wumpus> morcos: yes
3942016-11-17T19:30:26  <instagibbs> yes labels would have to come first
3952016-11-17T19:30:32  <morcos> i mean i wish we could just rip them out, they're terrible.  but it seems like people still depend on them
3962016-11-17T19:30:32  <gmaxwell> I think I had just managed to miss 7729.
3972016-11-17T19:30:43  <gmaxwell> Doing both lavels and accounts means more breaking API changes, no?
3982016-11-17T19:30:55  <MarcoFalke_web> wumpus: You mentioned that this may cause problems when people use the account AND label api?
3992016-11-17T19:31:09  <wumpus> MarcoFalke_web: there may need to be protection against that, yes
4002016-11-17T19:31:20  <gmaxwell> morcos: most of the time I see them mentioned, they are being used as labels.
4012016-11-17T19:31:21  <wumpus> MarcoFalke_web: though the same already happens if you use accounts and the GUI
4022016-11-17T19:31:32  <wumpus> MarcoFalke_web: and there is no protection against that either
4032016-11-17T19:31:33  <jtimon> can't we replace accounts with labels all at once?
4042016-11-17T19:32:04  <gmaxwell> morcos: and people are confused when the accounts centric behavior shows up...  or, alternatively, they're confused when they don't control "from" addresses (that they're not seperate wallets).
4052016-11-17T19:32:04  <jtimon> it's not like we haven't been warning against the use of accounts for ages
4062016-11-17T19:32:06  <wumpus> can we first *agree* on the label api?
4072016-11-17T19:32:19  <instagibbs> jtimon, at some point I don't think people believe the deprecated warning
4082016-11-17T19:32:22  <sipa> jtimon: go review 7729 (and i should do the same)
4092016-11-17T19:32:25  <instagibbs> we should put scary ascii art :)
4102016-11-17T19:32:26  <gmaxwell> so proposed action: everyone go comment on 7729.
4112016-11-17T19:32:30  <instagibbs> action yes
4122016-11-17T19:32:32  <morcos> ok, lets all read 7729 again and discuss on there
4132016-11-17T19:32:35  <instagibbs> ack
4142016-11-17T19:32:37  <morcos> damn i type too slow
4152016-11-17T19:32:38  <jtimon> sipa: right
4162016-11-17T19:32:39  <gmaxwell> yea, it sounds great.
4172016-11-17T19:32:53  <instagibbs> also who uses labels that we talk to? dooglus?
4182016-11-17T19:32:55  <MarcoFalke_web> #action look at https://github.com/bitcoin/bitcoin/pull/7729
4192016-11-17T19:33:15  <jonasschnelli> Removing the accounting system entirely will be difficult (especially old wallet migration)
4202016-11-17T19:33:29  <wumpus> whether to rip accounts at the same time as introducing labels is for later discussion, none of this is hard to implement, but deciding what API we want is more difficult
4212016-11-17T19:33:36  <wumpus> jonasschnelli: no, it's not difficult at all
4222016-11-17T19:34:14  <wumpus> jonasschnelli: you could even keep the accounting records around and just ignore them and treat previous accounts as labels instead
4232016-11-17T19:34:22  <gmaxwell> ^ is what I expected.
4242016-11-17T19:34:23  <sipa> just the concept of 'balance of a label/account' disappears, not the ability to selectively list transactions affecting labels/accounts
4252016-11-17T19:34:25  <jonasschnelli> I once did it in a test branch and it took me a long time to get it right... but maybe I was overcomplicating stuff there
4262016-11-17T19:34:38  <MarcoFalke_web> I think dooglus use case would be covered by the new label api, but better someone ping him on the pr
4272016-11-17T19:34:41  <wumpus> jonasschnelli: it's mainly a matter of deleting code
4282016-11-17T19:34:56  <jonasschnelli> Right. I removed it with no labels migration
4292016-11-17T19:35:07  <gmaxwell> I expected the account->label change would mostly be a matter of getting rid of balance related functionality. And otherwise not much perhaps beyond some new label centric features.
4302016-11-17T19:35:11  <sipa> jonasschnelli: i think you're overcomplicating
4312016-11-17T19:35:16  <wumpus> gmaxwell: yes
4322016-11-17T19:35:34  <wumpus> gmaxwell: and just to be claear *account* RPCs are renamed to *label*, basically
4332016-11-17T19:35:36  <sipa> jonasschnelli: it's literally just removing the balance RPCs, and then dropping the 'from account' field in send RPC, and renaming the rest account->label
4342016-11-17T19:35:44  <wumpus> yes
4352016-11-17T19:35:48  <gmaxwell> (e.g. of 'obvious' additional features: multiple labels on items, being able to label a single transaction without labling any involved addresses)
4362016-11-17T19:36:23  <wumpus> well at first it just implements the GUI label API, which doesn't allow labeling transactions either
4372016-11-17T19:36:30  <wumpus> I think that's a whole different thing
4382016-11-17T19:36:31  <gmaxwell> yep. makes sense.
4392016-11-17T19:36:59  <jonasschnelli> you can label addresses but not transactions, right?
4402016-11-17T19:37:03  <wumpus> right
4412016-11-17T19:37:04  <jonasschnelli> We have a comment feature for transaction
4422016-11-17T19:37:07  <jtimon> isn't the move call also affected (if we still have that)?
4432016-11-17T19:37:13  <morcos> perhaps as an immediate step, we could more forcefully declare accounts unsupported and deprecated for 0.14
4442016-11-17T19:37:13  <jonasschnelli> (which is sadly not really used and exposed)
4452016-11-17T19:37:17  <wumpus> move will disappear jtimon
4462016-11-17T19:37:25  <wumpus> please actually read #7729 :(
4472016-11-17T19:37:26  <jtimon> wumpus: k
4482016-11-17T19:37:27  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
4492016-11-17T19:37:31  <morcos> so that in the course of adding labels, we don't have to worry about any edge case mixing of the 2
4502016-11-17T19:37:36  <gmaxwell> morcos: that would be negative for the many people who use accounts as labels today, however.
4512016-11-17T19:38:11  <wumpus> first introduce labels
4522016-11-17T19:38:14  <morcos> gmaxwell: yeah but i don't mean we're actually going to change it,  i just worry that in the course of adding labels around accounts we'll give ourselves extra work, but maybe not.
4532016-11-17T19:38:21  <wumpus> only then I'll agree on doing anything more to deprecate accounts
4542016-11-17T19:38:34  <wumpus> if we don't move forward for labels, we'll stay in this state forever
4552016-11-17T19:38:42  <gmaxwell> I need to read the PR to comment more!
4562016-11-17T19:38:47  <instagibbs> 2 spooky
4572016-11-17T19:38:52  *** Chris_Stewart_5 has quit IRC
4582016-11-17T19:40:03  <instagibbs> any other topics?
4592016-11-17T19:40:04  <wumpus> making more noise about removing accounts before we have a labels API will just make people (such as dooglus) panicked
4602016-11-17T19:40:33  * gmaxwell looks at btcdrak pining #joinmarket and contemplates ^ :P
4612016-11-17T19:41:10  <gmaxwell> okay, I think we should take the proposed action of everyone reading and commenting on 7729 and move to another subject.
4622016-11-17T19:41:11  <jonasschnelli> I guess he's afk
4632016-11-17T19:41:18  <wumpus> yes
4642016-11-17T19:41:55  <gmaxwell> Or otherwise, we could instead engage in the age old art of completely uninformed combat.
4652016-11-17T19:42:16  <morcos> you want to talk about block size?
4662016-11-17T19:42:18  <jtimon> morcos: are you saying remove accounts before labels or just do both at the same time (to not worry about incompatibilities between the 2)?
4672016-11-17T19:42:24  <gmaxwell> "I haven't read 7729 but I oppose any change that causes blindness in small children!"
4682016-11-17T19:42:34  <petertodd> gmaxwell: I didn't read your last comment, but ACK
4692016-11-17T19:42:53  <jtimon> other topics?
4702016-11-17T19:42:54  <jonasschnelli> If there are no other topic, we could talk about "auxiliary block requests" if some are interested in it?
4712016-11-17T19:43:08  <jtimon> what is that?
4722016-11-17T19:43:14  <jonasschnelli> #9171
4732016-11-17T19:43:15  <gribble> https://github.com/bitcoin/bitcoin/issues/9171 | Introduce auxiliary block requests by jonasschnelli · Pull Request #9171 · bitcoin/bitcoin · GitHub
4742016-11-17T19:43:20  <gmaxwell> jonasschnelli: will that cause blindness in small children?
4752016-11-17T19:43:24  * BlueMatt petitions for one more review on #9075
4762016-11-17T19:43:26  <gribble> https://github.com/bitcoin/bitcoin/issues/9075 | Decouple peer-processing-logic from block-connection-logic (#3) by TheBlueMatt · Pull Request #9075 · bitcoin/bitcoin · GitHub
4772016-11-17T19:43:44  <gmaxwell> jtimon: it provides hot and cold running blocks.
4782016-11-17T19:43:45  <sipa> gmaxwell: yes, through xkcd 378
4792016-11-17T19:43:46  <jonasschnelli> jtimon "auxiliary block requests" is a requirement for SPV
4802016-11-17T19:43:48  <instagibbs> BlueMatt, thanks, added to queue
4812016-11-17T19:44:01  <jonasschnelli> It allows you to request blocks during IBD... which not getting validated
4822016-11-17T19:44:18  <morcos> jonasschnelli: is there some more general description of how all that would work.  i started to look at it, but i wasn't sure what the high level design was
4832016-11-17T19:44:30  <instagibbs> ACK morcos I couldn't grasp immediately
4842016-11-17T19:44:39  <jonasschnelli> Hmm... I can write a paper?
4852016-11-17T19:45:03  <morcos> it doesn't have to be formal
4862016-11-17T19:45:23  <jonasschnelli> It's simple: you ask your node, "giveme blocks D, F, G", node downloads blocks "D, F, G" and pass it though the signals with validate=fale"
4872016-11-17T19:45:27  <BlueMatt> jonasschnelli: note that I'm working to remove fForceProcessing/etc from ProcessNewBlock...please do not pass the blockRequest object all the way in...
4882016-11-17T19:45:38  <gmaxwell> I have to admit I expirenced some groan related to "oh no, yet another block fetching modality" -- but the application of being able to on demand randomly request blocks is perfectly reasonsable.  More description would be helpful.
4892016-11-17T19:45:54  <jonasschnelli> It uses all the available mechanisms.
4902016-11-17T19:46:04  <BlueMatt> jonasschnelli: I'd kinda prefer this not call AcceptBlock at all...do we need to store the block or can we just pass to wallet?
4912016-11-17T19:46:10  <jonasschnelli> It just "prioritize the requested blocks"
4922016-11-17T19:46:14  <sipa> overall concept ack, but i think the implementation will need to change with the ongoing network processing refactors
4932016-11-17T19:46:51  <gmaxwell> BlueMatt: seems foolish to download blocks twice... which would happen if we didn't store them.
4942016-11-17T19:46:57  <BlueMatt> hum, true
4952016-11-17T19:46:57  <jonasschnelli> BlueMatt: Right. We could factor out the on-disk-storing part
4962016-11-17T19:47:08  <BlueMatt> still, would be nice to not store unless we need to
4972016-11-17T19:47:15  <wumpus> it needs to get the chance to store it, atl east
4982016-11-17T19:47:20  <gmaxwell> ^ yep.
4992016-11-17T19:47:23  <sipa> BlueMatt: it would integrate into some callback for downloaded blocks, i would guess
5002016-11-17T19:47:23  <BlueMatt> gmaxwell: we could also use the needs-download logic in the p2p logic to dedup download
5012016-11-17T19:47:31  <gmaxwell> Interaction with pruning seems somewhat complicated.
5022016-11-17T19:47:40  <BlueMatt> that way the p2p logic could decide to hand to ProcessNewBlock...or not
5032016-11-17T19:47:43  <wumpus> there may be further policy not to store it, e.g. based on pruning and such
5042016-11-17T19:47:45  <BlueMatt> gmaxwell: thats part of my concern
5052016-11-17T19:47:56  <wumpus> but for a full IBD you'd really want to pre-fill blocks
5062016-11-17T19:48:02  <BlueMatt> just seems kinda broken to have the block-processing logic process a block which it explicitly doesnt want
5072016-11-17T19:48:15  <gmaxwell> BlueMatt: but the main application now is a node that starts off with a spv mode wallet while it syncs up in the background.  Such nodes will likely also be pruned.
5082016-11-17T19:48:18  <wumpus> it will likely want it later
5092016-11-17T19:48:27  <sipa> i guess there should be a separation of "which blocks to download" and "which blocks to process" logic
5102016-11-17T19:48:32  <sipa> where the second can ask the first
5112016-11-17T19:48:38  <jonasschnelli> I think to make it work with pruning is not very hard... just step after step
5122016-11-17T19:48:57  <BlueMatt> wumpus: yes, I'm saying if we have a full-spv mode then the p2p logic should be able to not pass it to ProcessNewBlock....alternatively it can choose to do so if it thinks block-logic needs it
5132016-11-17T19:48:58  <wumpus> could e.g. store it for later processing
5142016-11-17T19:49:02  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5152016-11-17T19:49:16  <wumpus> discarding by default would be stupid, at least
5162016-11-17T19:49:28  <BlueMatt> wumpus: sure, but we have logic to figure out if we want a block or not, already
5172016-11-17T19:49:36  <BlueMatt> jonasschnelli: note that I have a pr to change the stuff there to deserialize blocks into shared_ptrs, so passing it over to wallet should use that
5182016-11-17T19:50:02  <BlueMatt> #9014, though its blocked on #9075
5192016-11-17T19:50:02  <gmaxwell> blocks as sharedptr, hurrah
5202016-11-17T19:50:02  <jonasschnelli> BlueMatt: okay. Though #9171 aims to be a wallet free PR
5212016-11-17T19:50:06  <gribble> https://github.com/bitcoin/bitcoin/issues/9014 | Fix block-connection performance regression by TheBlueMatt · Pull Request #9014 · bitcoin/bitcoin · GitHub
5222016-11-17T19:50:07  <gribble> https://github.com/bitcoin/bitcoin/issues/9075 | Decouple peer-processing-logic from block-connection-logic (#3) by TheBlueMatt · Pull Request #9075 · bitcoin/bitcoin · GitHub
5232016-11-17T19:50:09  <gribble> https://github.com/bitcoin/bitcoin/issues/9171 | Introduce auxiliary block requests by jonasschnelli · Pull Request #9171 · bitcoin/bitcoin · GitHub
5242016-11-17T19:50:32  <sipa> BlueMatt: note that after 9125, deserializing into a share_ptr is literally just "std::shared_ptr<const CBlock> ptr; ss >> ptr; "
5252016-11-17T19:50:40  <BlueMatt> sipa: cool
5262016-11-17T19:52:53  <jonasschnelli> more topics? 8m to go.
5272016-11-17T19:53:27  <wumpus> *crickets*
5282016-11-17T19:53:27  <Chris_Stewart_5> jonasschnelli: What is the use case for that? Why request the full block if we aren't validating?
5292016-11-17T19:53:39  <sipa> Chris_Stewart_5: light wallet support
5302016-11-17T19:53:49  <gmaxwell> Chris_Stewart_5: so we can scan it for wallet transactions.
5312016-11-17T19:53:50  <instagibbs> Chris_Stewart_5, you download blocks based on age of your wallet
5322016-11-17T19:53:55  <jonasschnelli> Chris_Stewart_5: allow receiving and sending transactions in "client" mode
5332016-11-17T19:54:00  <sipa> Chris_Stewart_5: the ability to use the wallet before you're fully synced
5342016-11-17T19:54:11  <instagibbs> "Where did my money go" <---
5352016-11-17T19:54:14  <wumpus> let's take basic questions to outside the meeting
5362016-11-17T19:54:31  <Chris_Stewart_5> This is alt solution to BIP37 then, or complementary?
5372016-11-17T19:54:44  <gmaxwell> Chris_Stewart_5: bip37 _utterly_ destroys privacy, and would waste bandwidth if you're later going to need the block for verification anyways.
5382016-11-17T19:54:56  <jonasschnelli> Chris_Stewart_5: its a safer solution then BIP37...
5392016-11-17T19:55:38  <gmaxwell> (BIP37 is also vulnerable to txn being hidden from you)
5402016-11-17T19:55:55  <wumpus> yes, BIP37 is a bad idea, we're not going to use it in core
5412016-11-17T19:56:37  <Chris_Stewart_5> Yes I understand that part, I'm trying to piece together how new spv mode will function i guess.
5422016-11-17T19:56:39  <wumpus> (bad idea with untrusted peers at least, and that's the use case here)
5432016-11-17T19:56:52  <jonasschnelli> I think it could have it's reason when connected to a BIP150 authed trusted peer. But only then.
5442016-11-17T19:56:53  <wumpus> any other topics?
5452016-11-17T19:56:57  <wumpus> the meeting is derailed
5462016-11-17T19:57:13  <wumpus> otherwise better to close it
5472016-11-17T19:57:15  <instagibbs> 3 minutes, no topics, bound to
5482016-11-17T19:57:17  <MarcoFalke_web> #endsmeeting
5492016-11-17T19:57:22  <jonasschnelli> #endmeeting
5502016-11-17T19:57:22  <lightningbot> Meeting ended Thu Nov 17 19:57:22 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5512016-11-17T19:57:22  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-17-19.04.html
5522016-11-17T19:57:22  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-17-19.04.txt
5532016-11-17T19:57:22  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-17-19.04.log.html
5542016-11-17T19:57:27  <gmaxwell> If you end the meeting will it be classified as back on track or forever derailed?
5552016-11-17T19:57:32  <sipa> Chris_Stewart_5: it will just download full blocks
5562016-11-17T19:57:42  <achow101> will we have a meeting next week? It's a holiday in the US
5572016-11-17T19:57:43  <sipa> Chris_Stewart_5: and possibly remember them for validation later
5582016-11-17T19:57:46  <jonasschnelli> sipa: \o/ new navigation on http://bitcoin.sipa.be
5592016-11-17T19:57:49  <jonasschnelli> hurra
5602016-11-17T19:57:57  <sipa> jonasschnelli: yes, thanks to jameson lopp
5612016-11-17T19:58:10  <jonasschnelli> achow101: US? is that the place where they just abandoned politics?
5622016-11-17T19:58:13  <instagibbs> Chris_Stewart_5, I'm a new full node, wallet is a week or two old. Then you can grab the last two weeks of blocks and find payments
5632016-11-17T19:58:21  <achow101> jonasschnelli: yeah, that one
5642016-11-17T19:58:22  <instagibbs> meanwhile background you're still validating
5652016-11-17T19:58:29  <gmaxwell> jonasschnelli: political discussion to ##bitcoin.
5662016-11-17T19:58:45  <Chris_Stewart_5> What about bandwidth usage? Doesn't this require much more bandwidth? Not a concern?
5672016-11-17T19:58:47  <gmaxwell> achow101: the meetings stop for nothing except almost everyone being gone at once. :P
5682016-11-17T19:58:49  <wumpus> gmaxwell: well I think this meeting will stay derailed no matter waht, there's no way to un-log what is logged :)
5692016-11-17T19:59:02  <jonasschnelli> Chris_Stewart_5: if you want to do a full validation, you need to block anyways.
5702016-11-17T19:59:14  <jonasschnelli> So you have some already downloaded blocks around the tip
5712016-11-17T19:59:18  <Chris_Stewart_5> and if you don't?
5722016-11-17T19:59:39  <jonasschnelli> You waste bandwidth
5732016-11-17T19:59:43  <jonasschnelli> which can be okay.
5742016-11-17T19:59:45  <wumpus> Chris_Stewart_5: it's just a different compromise
5752016-11-17T19:59:50  <gmaxwell> Chris_Stewart_5: besides, fetching blocks is 14kb/s ongoing (28kb/s perhaps soon)-- most people running bitcoin core can handle that without batting an eye.
5762016-11-17T19:59:58  <jonasschnelli> either you waste pricavy or bandwidth... you can choose.
5772016-11-17T20:00:05  <wumpus> right
5782016-11-17T20:00:08  <instagibbs> even if you don't want to catch up, it's still better than bloom filters or centralized nodes
5792016-11-17T20:00:14  <Chris_Stewart_5> jonasschnelli: If we are removing BIP37 there isn't a choice.
5802016-11-17T20:00:20  <gmaxwell> STOP
5812016-11-17T20:00:21  <gmaxwell> die
5822016-11-17T20:00:28  <gmaxwell> okay, now that you are all dead...
5832016-11-17T20:00:28  <wumpus> no one is *removing* BIP37
5842016-11-17T20:00:32  <gmaxwell> ^ that.
5852016-11-17T20:00:35  <jonasschnelli> heh
5862016-11-17T20:00:42  <jonasschnelli> (rofl)
5872016-11-17T20:00:43  <wumpus> can people stop FUDing and panicking about everything we do?
5882016-11-17T20:00:45  <wumpus> thank you
5892016-11-17T20:00:51  <achow101> panic panic
5902016-11-17T20:01:21  <gmaxwell> When in danger or in doubt run in terror, scream and shout.
5912016-11-17T20:01:22  <wumpus> we're just nopt using BIP37 for the light wallet mode in bitcoin core. If you want to use it in your wallet go ahead.
5922016-11-17T20:01:40  <wumpus> it's a big internet and you don't need to do what we do
5932016-11-17T20:01:52  <jonasschnelli> Chris_Stewart_5: </panic mode> you can use BIP37 with plenty of other wallets, but when using Core, we don't want scarifies privacy over because of some GB bandwidth
5942016-11-17T20:01:58  <bsm1175321> I'm interested in making an update to BIP37 to improve light wallet security...
5952016-11-17T20:02:08  <gmaxwell> Maybe someday BIP37 goes away, but only if it were replaced with something better for the things that use it now. There are proposals but at the moment no one is actively working on them.
5962016-11-17T20:02:10  <jonasschnelli> That's IMO impossible..
5972016-11-17T20:02:15  <wumpus> many people only use their bitcoin wallet with wifi so could care less about bandwidth usage
5982016-11-17T20:02:18  <jonasschnelli> Maybe Bloom Filter Commitments
5992016-11-17T20:02:22  <wumpus> they care about privacy, though
6002016-11-17T20:02:50  <jonasschnelli> People are downloading a 10GB movie just to rent it for 24h... why would they not be willing to download 10GB to get financial privacy?
6012016-11-17T20:03:14  <sipa> bsm1175321: the only proposal i know that improves it is pretty radically different (bloom filter commitments)
6022016-11-17T20:03:16  <wumpus> yeah, it's simply a choice/compromise, I don't understand what is so difficult about understanding that
6032016-11-17T20:03:41  <jcorgan> why interpret ambiguity in a way that gives the speaker the benefit of the doubt when you can construe anything they say in the worst possible way to reinforce your pre-existing conclusions?
6042016-11-17T20:03:43  <gmaxwell> jonasschnelli: the filter commitment scheme can also be done without the commitments. (just loses the censorship resistance).
6052016-11-17T20:03:54  <bsm1175321> sipa: I'll read up.  Any links?  I'm also interested in UTXO set commitments.
6062016-11-17T20:04:20  <bsm1175321> Also perfectly happy with something pretty radically different.
6072016-11-17T20:04:33  <jonasschnelli> gmaxwell: do you have a post or paper about this?
6082016-11-17T20:04:46  <sipa> bsm1175321: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html
6092016-11-17T20:05:25  <gmaxwell> jonasschnelli: the post describing the commited filters mentions that it can be done without the commitment. The only thing the commitment adds is the inability for nodes to lie about the filter content. Which is good, but it doesn't have to be delivered right away.
6102016-11-17T20:05:39  <bsm1175321> sipa: thanks!
6112016-11-17T20:05:46  <jonasschnelli> Okay. Thanks for the link sipa
6122016-11-17T20:05:51  <gmaxwell> My view is that it would best be accomplished by implementing it without the commitment but in a way that would be sutiable for commitment later.
6132016-11-17T20:06:46  <gmaxwell> also, as an aside, cuckoo filters are likely a better data structure for this than bloom filters... but there is a big area for research here.
6142016-11-17T20:07:57  <bsm1175321> +1 on cuckoo filters.  Waaaay faster and the performance characteristics are more understandable (one fewer parameter)
6152016-11-17T20:08:22  <gmaxwell> segwit also opens up a new option, which is just fetching full blocks without witnesses.
6162016-11-17T20:09:34  <gmaxwell> If segwit were used exclusively the size of a full block without the witness would be about 500k... not exactly as small as a filter, but still perfectly private.
6172016-11-17T20:10:29  <sipa> jcorgan: what was that a response to?
6182016-11-17T20:10:59  <bsm1175321> I wonder if some kind of oblivious transfer protocol would be practical for light wallet privacy?
6192016-11-17T20:11:12  <jcorgan> ?
6202016-11-17T20:12:14  <jcorgan> oh, earlier, that was about Chris_Stewart_5 comment
6212016-11-17T20:13:07  <jcorgan> a snark that lost its context when too many other comments flew by while i was typing
6222016-11-17T20:14:21  *** cannon-c has quit IRC
6232016-11-17T20:14:25  <bitcoin-git> [bitcoin] mruddy closed pull request #9175: WIP: remove script checking dependency on checkpoints (master...script_check) https://github.com/bitcoin/bitcoin/pull/9175
6242016-11-17T20:15:03  <Chris_Stewart_5> jcorgan: I misinterpreted wumpus comment about 'not using' BIP37 in core as 'removing' it and apparently that triggered everyone ;). Thanks for the support though, some one has to ask the dumb questions :-)
6252016-11-17T20:15:30  <bsm1175321> e.g. http://percy.sourceforge.net/
6262016-11-17T20:21:57  *** tunafizz has quit IRC
6272016-11-17T20:28:20  *** jtimon has quit IRC
6282016-11-17T20:30:06  *** meownow has joined #bitcoin-core-dev
6292016-11-17T20:30:13  <meownow> hi all
6302016-11-17T21:02:26  *** cryptapus has quit IRC
6312016-11-17T21:02:56  *** meownow has quit IRC
6322016-11-17T21:18:40  *** Chris_Stewart_5 has quit IRC
6332016-11-17T21:24:12  <bitcoin-git> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/a8b2a82618be...9346f8429957
6342016-11-17T21:24:12  <bitcoin-git> bitcoin/master e2e069d Matt Corallo: Revert "RPC: Give more details when "generate" fails"...
6352016-11-17T21:24:13  <bitcoin-git> bitcoin/master 7c98ce5 Matt Corallo: Remove pfrom parameter from ProcessNewBlock...
6362016-11-17T21:24:14  <bitcoin-git> bitcoin/master ae22357 Matt Corallo: Replace CValidationState param in ProcessNewBlock with BlockChecked
6372016-11-17T21:24:26  <bitcoin-git> [bitcoin] sipa closed pull request #9075: Decouple peer-processing-logic from block-connection-logic (#3) (master...net_processing_4) https://github.com/bitcoin/bitcoin/pull/9075
6382016-11-17T21:33:58  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6392016-11-17T21:59:01  *** Victorsueca has joined #bitcoin-core-dev
6402016-11-17T22:03:29  *** meownow has joined #bitcoin-core-dev
6412016-11-17T22:09:25  <meownow> main.cpp is the best place to start in terms of trying to understand the source code, correct?
6422016-11-17T22:10:24  *** jtimon has joined #bitcoin-core-dev
6432016-11-17T22:11:10  <MarcoFalke_web> Carefully reviewing pull requests is the best place to start in terms of trying to understand the source code :P
6442016-11-17T22:14:22  <meownow> ok, will do that then!
6452016-11-17T22:15:15  <MarcoFalke_web> #9142 looks ready for merge.
6462016-11-17T22:15:16  <gribble> https://github.com/bitcoin/bitcoin/issues/9142 | Move -salvagewallet, -zap(wtx) to where they belong by jonasschnelli · Pull Request #9142 · bitcoin/bitcoin · GitHub
6472016-11-17T22:23:31  *** Chris_Stewart_5 has quit IRC
6482016-11-17T22:38:06  <meownow> could someone do an ELI5 for the debate that occurs RE this pull request? i kind of get it but at the same time am a bit confused
6492016-11-17T22:38:44  <meownow> oops, this pull request: https://github.com/bitcoin/bitcoin/pull/63
6502016-11-17T22:39:39  *** MarcoFalke has joined #bitcoin-core-dev
6512016-11-17T22:39:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6522016-11-17T22:41:17  <sipa> meownow: it was later proposed as a BIP, and implemented in #707
6532016-11-17T22:41:19  <gribble> https://github.com/bitcoin/bitcoin/issues/707 | Implement BIP 14 : separate protocol version from client version by gavinandresen · Pull Request #707 · bitcoin/bitcoin · GitHub
6542016-11-17T22:46:13  <meownow> ty will check that out
6552016-11-17T23:12:59  <jtimon> sipa: another related question why is https://github.com/bitcoin/bitcoin/pull/9125/files#diff-5cb8d9decaa15620a8f98b0c6c44da9bR382 necessary?
6562016-11-17T23:13:05  <BlueMatt> jtimon/sipa do we care about https://github.com/bitcoin/bitcoin/pull/9075/files#r88568772 ?
6572016-11-17T23:13:37  *** achow101 has left #bitcoin-core-dev
6582016-11-17T23:18:51  *** meownow has quit IRC
6592016-11-17T23:19:29  <jtimon> BlueMatt: I guess if we can maintain the printing of the error without much disruption that would be nice, but I don't really know how important this is for bip22, maybe luke-jr has an opinion on this?
6602016-11-17T23:23:42  <jtimon> sipa: never mind, read more about move
6612016-11-17T23:24:00  *** Alina-malina has quit IRC
6622016-11-17T23:28:03  <bitcoin-git> [bitcoin] TheBlueMatt reopened pull request #9014: Fix block-connection performance regression (master...2016-10-fix-tx-regression) https://github.com/bitcoin/bitcoin/pull/9014
6632016-11-17T23:28:40  <BlueMatt> sipa: do you want me to go ahead and rebase ^ on the shared_ptr serialization from 9125?
6642016-11-17T23:31:42  *** Alina-malina has joined #bitcoin-core-dev
6652016-11-17T23:32:39  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #9179: Set DEFAULT_LIMITFREERELAY = 0 kB/minute (master...Mf1611-blockFreeTxs) https://github.com/bitcoin/bitcoin/pull/9179
6662016-11-17T23:34:46  *** MarcoFalke_web has quit IRC
6672016-11-17T23:43:09  <bitcoin-git> [bitcoin] mruddy opened pull request #9180: WIP: remove script checking dependency on checkpoints v2 (master...isburied) https://github.com/bitcoin/bitcoin/pull/9180
6682016-11-17T23:53:04  *** MarcoFalke has left #bitcoin-core-dev
6692016-11-17T23:54:04  *** Guyver2 has quit IRC