12017-08-10T00:00:11  *** promag has quit IRC
  22017-08-10T00:00:53  *** Aaronvan_ has joined #bitcoin-core-dev
  32017-08-10T00:04:06  *** AaronvanW has quit IRC
  42017-08-10T00:08:01  *** owowo has quit IRC
  52017-08-10T00:12:19  *** promag has joined #bitcoin-core-dev
  62017-08-10T00:12:35  *** promag has quit IRC
  72017-08-10T00:12:55  *** owowo has joined #bitcoin-core-dev
  82017-08-10T00:12:55  *** owowo has joined #bitcoin-core-dev
  92017-08-10T00:15:43  *** Aaronvan_ has quit IRC
 102017-08-10T00:16:18  *** AaronvanW has joined #bitcoin-core-dev
 112017-08-10T00:20:49  *** AaronvanW has quit IRC
 122017-08-10T00:25:06  *** promag has joined #bitcoin-core-dev
 132017-08-10T00:38:00  *** promag has quit IRC
 142017-08-10T01:03:09  *** LampTreadStone07 has quit IRC
 152017-08-10T01:05:05  *** dcousens has joined #bitcoin-core-dev
 162017-08-10T01:21:17  *** d_t has quit IRC
 172017-08-10T01:27:42  *** promag has joined #bitcoin-core-dev
 182017-08-10T01:38:07  *** d_t has joined #bitcoin-core-dev
 192017-08-10T01:52:52  *** dabura667_ has joined #bitcoin-core-dev
 202017-08-10T01:53:01  *** dabura667_ has quit IRC
 212017-08-10T01:56:41  *** promag has quit IRC
 222017-08-10T02:25:55  *** neha has quit IRC
 232017-08-10T02:26:16  *** neha has joined #bitcoin-core-dev
 242017-08-10T02:26:23  *** moctos has joined #bitcoin-core-dev
 252017-08-10T02:51:27  *** d_t has quit IRC
 262017-08-10T02:52:49  *** chjj has quit IRC
 272017-08-10T03:12:49  *** jimpo has joined #bitcoin-core-dev
 282017-08-10T03:13:31  <jimpo> What does fOneShot mean in the net code? Seems to be set for connections to seed nodes?
 292017-08-10T03:22:21  <jimpo> Ah, is the idea that we only use seed nodes to get addresses then disconnect?
 302017-08-10T04:11:30  *** Cory has quit IRC
 312017-08-10T04:18:28  *** Cory has joined #bitcoin-core-dev
 322017-08-10T04:18:50  <venzen> The fact SegWit activation comes with a 4x blocksize limit increase is reason for concern
 332017-08-10T04:19:33  <venzen> My bad for not comprehending this sooner - I was somehow understanding "effective" block size limit increase from BIP141 and related explanations
 342017-08-10T04:20:14  <sipa> venzen: it does not come with a 4x validation cost increase, however
 352017-08-10T04:20:23  <venzen> since there is no longer a "big block" contingent to appease, would a 2x increase perhaps be more appropriate and safe?
 362017-08-10T04:20:24  <sipa> nor a 4x utxo growth
 372017-08-10T04:21:17  <venzen> sipa: true, i have read aantonop's explanation of the incentive to reduce UTXO set growth and your BIP makes that clear
 382017-08-10T04:21:23  <gmaxwell> venzen: segwit eliminates the block size limit, replaces it with a block weight limit. Weight is designed to better reflect the cost of transactions to the network.
 392017-08-10T04:21:56  <gmaxwell> because weight is limited instead of size, the maximum amount of size is variable depending on the content.
 402017-08-10T04:22:16  <venzen> gmaxwell: sipa: apologies for my confusion but I am receiving mixed messages - some are saying that real 4MB blocks are possible, is this true?
 412017-08-10T04:22:25  <gmaxwell> Similar to how the number of 1 bits in a block varry.
 422017-08-10T04:22:33  <venzen> ok
 432017-08-10T04:22:41  <sipa> venzen: in theory, yes
 442017-08-10T04:22:50  <gmaxwell> venzen: sure, if you construct transactions that have low weight you can put more of them in a block.
 452017-08-10T04:23:45  <venzen> gmaxwell: sipa: are there substantive reasons why it should be 4MB and not a more concervative 2MB limit?
 462017-08-10T04:23:48  <gmaxwell> Similar to how normally a block has only about 500,000 1 bits, but you could construct a block with nearly 1,000,000 one bits, if you constructed the transactions right.. because (pre segwit) the system limits the size not the number of 1 bits.
 472017-08-10T04:24:02  <sipa> venzen: the size of blocks is not that relevant
 482017-08-10T04:24:10  <sipa> their validation cost is
 492017-08-10T04:24:38  <venzen> sipa: validation as in CPU resources across the network?
 502017-08-10T04:24:38  <gmaxwell> venzen: because limiting weight increases capacity and dampens attacks. Size of some particular serialization is not a good measure of the resource usage of a block.
 512017-08-10T04:25:44  <venzen> gmaxwell: sipa: ok, i guess i'm stil stuck in the induced demand paradigm, let me do some reading and thinking - thanks for your explanations
 522017-08-10T04:26:29  <gmaxwell> venzen: you are making a reasoning error in privledging size.
 532017-08-10T04:27:31  <gmaxwell> Size doesn't necessairly have a strong relationship to anything that matters... blocks are sent a the tip with compact blocks.
 542017-08-10T04:28:01  <gmaxwell> In the future historical blocks may be sent with compact seralization (which is 25%) smaller and compression, or not sent at all.
 552017-08-10T04:28:48  <gmaxwell> Size ignores the impact on the UTXO set.. so as time goes on size increasingly has little to do with anything that matters.
 562017-08-10T04:33:12  *** jimpo has quit IRC
 572017-08-10T04:35:49  <venzen> gmaxwell: ok, i will process the information, i'm obviously failing to grasp a fundamental concept and will find it
 582017-08-10T04:37:21  <venzen> if the devs unanimously agree that a 4MB blocksize limit is ok with a block weight decider then I believe that
 592017-08-10T04:38:19  <sipa> venzen: see it this way, segwit does not at all increase the maximum number of outputs or inputs can have
 602017-08-10T04:38:25  <sipa> *a block
 612017-08-10T04:39:35  <sipa> yes, the number of bytes on disk may increase faster but 1) since compact blocks, latency is no longer impacted by the number of bytes in a block 2) with pruning, storage of old blocks doesn't matter
 622017-08-10T04:40:31  <sipa> so the only real increase is the cost of transaction relay, which is in the order of kilobytes/sec
 632017-08-10T04:43:34  <venzen> sipa: i'm assuming that the primary consideration is at the UTXO level, so number of txns per block is the wrong way to think about this? Even so, we can expect an increase in the number of "traditional" P2PKH txns per block after activation?
 642017-08-10T04:47:22  *** miknotauro has joined #bitcoin-core-dev
 652017-08-10T04:58:01  *** miknotauro has quit IRC
 662017-08-10T05:05:44  <venzen> sipa: i assume you're not responding because the answers are already contained in your and gmaxwell 's responses above. I will meditate upon those. Thank you very much for taking the time to explain to a layman - you guys are international treasures and history will acknowledge you.
 672017-08-10T05:10:12  *** chjj has joined #bitcoin-core-dev
 682017-08-10T05:24:02  <sipa> venzen: number of transactions never matters... inputs and outputs do, the conplexity of their scripts, database growth, ...
 692017-08-10T05:24:30  <sipa> but many transactions with few in/out, or few transactions with many in/out can be equivalent
 702017-08-10T05:48:34  <bitcoin-git> [bitcoin] kallewoof opened pull request #11019: [wallet] Abandon transactions that fail to go into the mempool (master...abandon-longchain-failed-tx) https://github.com/bitcoin/bitcoin/pull/11019
 712017-08-10T06:16:56  *** Victorsueca has quit IRC
 722017-08-10T06:18:05  *** Victorsueca has joined #bitcoin-core-dev
 732017-08-10T06:46:42  *** BashCo has quit IRC
 742017-08-10T07:05:30  <wumpus> aj: sorry but bad time to ask now, I don't have much time to look at features, trying to focus on the 0.15 branch-off and 0.15.0rc1 release
 752017-08-10T07:06:06  *** BashCo has joined #bitcoin-core-dev
 762017-08-10T07:06:39  <wumpus> aj: the includeconf stuff looks good at a high level but haven't looked in detail, eg. whether it doesn't make the initialization and config reading code even less understandable
 772017-08-10T07:32:59  *** d_t has joined #bitcoin-core-dev
 782017-08-10T07:36:58  <aj> wumpus: yup figured, no worries
 792017-08-10T07:39:01  <wumpus> aj: I promise to look at it as one of the first things after the branch
 802017-08-10T07:40:15  <aj> wumpus: post celebratory beverage or similar i trust!
 812017-08-10T07:42:11  <wumpus> aj: the thing I'm most worried with regard to risk of changes in that area of the code is that a) the qt/bitcoind initialization sequences start to diverge or b) the precedence of options between commandline/configuration file/qt settings becomes different. There's a lot that can go wrong there and we don't have tests for that :(
 822017-08-10T07:45:54  *** timothy has joined #bitcoin-core-dev
 832017-08-10T07:45:57  <kallewoof> Why would includeconf PR cause divergence with QT? It feels like QT-side could have the same feature. (If not, I can look into that.) Maybe I misunderstand the point.
 842017-08-10T07:47:50  <jonasschnelli> BIP151 encryption question: the current definition says, that encryption negotiation has to be done before the version handshake (I guess it makes sense to have the enc.negotiation first). But how should a peer know if the other peer supports BIP151. Try and reconnect? Service bit fetch-able via relay, seeds (meh!)?
 852017-08-10T07:48:22  <aj> wumpus: yeah, i was a bit surprised to see the init code was duplicated there, rather than just a common function of some sort
 862017-08-10T07:49:05  <aj> wumpus: (the error reporting makes that not a trivial fix though)
 872017-08-10T07:49:06  <wumpus> kallewoof: yes, the qt-side should have the same feature, that's exactly "why", but it might conflict with other things there as there's an extra settings source
 882017-08-10T07:49:31  <wumpus> aj: yes, error reporting as well as qsettings, translations handling, etc makes that different and hard to unify
 892017-08-10T07:49:47  <wumpus> aj: the qt setup sequence is much more complex
 902017-08-10T07:49:55  <wumpus> aj: ideally we'd have tests, that'd be much more reassuring
 912017-08-10T07:50:33  <wumpus> pretty much a preconditioning for refactoring there
 922017-08-10T07:52:24  <aj> wumpus: hmm, can travis start qt/bitcoin, or would local-only tests be sufficient at least to start?
 932017-08-10T07:54:11  <wumpus>  if the test is not interested in windowed output w/ QT_QPA_PLATFORM=minimal you can avoid the X dependency, this is what the bitcoin-qt unit-tests in src/qt/test do
 942017-08-10T07:54:56  <wumpus> also in principle you can run all the functional tests with bitcoin-qt instead of bitcoind (but that's not useful for travis :-)
 952017-08-10T07:55:33  <wumpus> in any case even locla-only tests are an improvement to having nothing
 962017-08-10T07:55:51  <wumpus> travis/build support can be sorted out later
 972017-08-10T08:07:06  <bitcoin-git> [bitcoin] kallewoof opened pull request #11020: [wallet] getbalance: Add option to include non-mempool UTXOs (master...unspendable-utxo-handling) https://github.com/bitcoin/bitcoin/pull/11020
 982017-08-10T08:10:47  *** d_t has quit IRC
 992017-08-10T08:14:54  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10442: add a -bip148 option (master...master) https://github.com/bitcoin/bitcoin/pull/10442
1002017-08-10T08:17:04  *** BashCo_ has joined #bitcoin-core-dev
1012017-08-10T08:19:05  *** BashCo has quit IRC
1022017-08-10T08:27:06  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10532: -bip148 option (master...bip148) https://github.com/bitcoin/bitcoin/pull/10532
1032017-08-10T08:33:32  *** BashCo_ has quit IRC
1042017-08-10T08:41:30  *** SopaXorzTaker has joined #bitcoin-core-dev
1052017-08-10T09:15:14  *** Yogaqueef has joined #bitcoin-core-dev
1062017-08-10T09:41:55  <bitcoin-git> [bitcoin] AkioNak opened pull request #11021: fix getchaintxstats() (master...fix_getchaintxstats) https://github.com/bitcoin/bitcoin/pull/11021
1072017-08-10T09:56:51  *** Guyver2 has joined #bitcoin-core-dev
1082017-08-10T09:57:05  *** elkalamar has quit IRC
1092017-08-10T10:04:48  *** BashCo has joined #bitcoin-core-dev
1102017-08-10T10:56:20  *** timothy has quit IRC
1112017-08-10T10:57:46  *** JackH has joined #bitcoin-core-dev
1122017-08-10T11:01:30  *** AaronvanW has joined #bitcoin-core-dev
1132017-08-10T12:30:14  *** timothy has joined #bitcoin-core-dev
1142017-08-10T12:38:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1152017-08-10T12:43:34  *** Chris_Stewart_5 has quit IRC
1162017-08-10T12:47:04  *** Mattie161 has joined #bitcoin-core-dev
1172017-08-10T12:49:49  *** sam_c has quit IRC
1182017-08-10T12:51:52  *** sam_c has joined #bitcoin-core-dev
1192017-08-10T12:59:29  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1202017-08-10T13:26:17  <venzen> sipa: gmaxwell: thanks, i'm processing, your explanations helped a great deal
1212017-08-10T13:36:27  *** rgrant has joined #bitcoin-core-dev
1222017-08-10T13:54:51  <sdaftuar> jtimon: this is incorrect - https://twitter.com/timoncc/status/895559780231593984
1232017-08-10T13:55:05  *** moctos has quit IRC
1242017-08-10T13:55:10  <sdaftuar> 0.14.2 certainly can sign segwit transactions
1252017-08-10T13:56:08  <sdaftuar> the wallet doesn't use segwit by default though, and only lets you (easily) create p2sh-wrapped segwit addresses after segwit activates.
1262017-08-10T14:00:57  *** dcousens has quit IRC
1272017-08-10T14:03:01  *** dcousens has joined #bitcoin-core-dev
1282017-08-10T14:05:27  *** justan0theruser has quit IRC
1292017-08-10T14:16:08  *** rockhouse has joined #bitcoin-core-dev
1302017-08-10T14:18:39  *** Guyver2 has quit IRC
1312017-08-10T14:26:10  <bitcoin-git> [bitcoin] jnewbery opened pull request #11022: Basic keypool topup (master...basic_keypool_topup) https://github.com/bitcoin/bitcoin/pull/11022
1322017-08-10T14:28:41  *** goldstar has joined #bitcoin-core-dev
1332017-08-10T14:47:48  *** goldstar has quit IRC
1342017-08-10T14:58:04  *** rgrant has left #bitcoin-core-dev
1352017-08-10T15:03:03  *** Aaronva__ has joined #bitcoin-core-dev
1362017-08-10T15:06:05  *** AaronvanW has quit IRC
1372017-08-10T15:10:07  *** alreadylate has joined #bitcoin-core-dev
1382017-08-10T15:12:19  *** Murch has joined #bitcoin-core-dev
1392017-08-10T15:14:08  *** dcousens has quit IRC
1402017-08-10T15:20:33  *** dgenr8 has joined #bitcoin-core-dev
1412017-08-10T15:40:49  *** Aaronva__ is now known as AaronvanW
1422017-08-10T15:44:42  *** alreadylate has quit IRC
1432017-08-10T16:05:31  *** elkalamar has joined #bitcoin-core-dev
1442017-08-10T16:21:14  *** smill has joined #bitcoin-core-dev
1452017-08-10T16:33:54  *** BashCo has quit IRC
1462017-08-10T16:34:46  *** BashCo has joined #bitcoin-core-dev
1472017-08-10T16:38:57  *** BashCo has quit IRC
1482017-08-10T16:46:48  *** timothy has quit IRC
1492017-08-10T16:53:24  <bitcoin-git> [bitcoin] jnewbery opened pull request #11023: [tests] Add option to attach a python debugger if functional test fails (master...func_test_pdb) https://github.com/bitcoin/bitcoin/pull/11023
1502017-08-10T16:57:00  *** sanada` has joined #bitcoin-core-dev
1512017-08-10T16:58:28  *** sanada has quit IRC
1522017-08-10T17:02:37  *** abpa has joined #bitcoin-core-dev
1532017-08-10T17:08:49  *** chjj has quit IRC
1542017-08-10T17:09:56  *** jimpo has joined #bitcoin-core-dev
1552017-08-10T17:10:13  <bitcoin-git> [bitcoin] practicalswift opened pull request #11024: tests: Free the OpenSSL error queue as part of the wallet_crypto/OldDecrypt test cleanup (master...OldDecrypt-cleanup) https://github.com/bitcoin/bitcoin/pull/11024
1562017-08-10T17:10:46  *** BashCo has joined #bitcoin-core-dev
1572017-08-10T17:16:38  *** RoyceX has joined #bitcoin-core-dev
1582017-08-10T17:21:36  *** miknotauro has joined #bitcoin-core-dev
1592017-08-10T17:29:11  *** amosbird has quit IRC
1602017-08-10T17:32:47  *** amosbird has joined #bitcoin-core-dev
1612017-08-10T17:38:50  *** d_t has joined #bitcoin-core-dev
1622017-08-10T17:49:23  *** THoVer has joined #bitcoin-core-dev
1632017-08-10T17:54:49  *** chjj has joined #bitcoin-core-dev
1642017-08-10T17:57:58  *** THoVer has quit IRC
1652017-08-10T18:03:14  <earlz> I'm trying to setup a new Gitian VM and I can't remember what I did to fix this error "failed to mound /dev/shm" using LXC
1662017-08-10T18:26:02  <wumpus> no google hits either?
1672017-08-10T18:26:11  *** corinrose_ has joined #bitcoin-core-dev
1682017-08-10T18:27:43  <wumpus> it sounds like a common lxc/vm issue, not specific to gitian
1692017-08-10T18:28:50  <earlz> Everything I've tried has been nothing so far
1702017-08-10T18:29:02  <earlz> just following exact directions as in the gitian-building.md doc
1712017-08-10T18:29:14  <earlz> lxc-execute: Mount of 'shm' onto '/usr/lib/x86_64-linux-gnu/lxc/rootfs/dev/shm' was onto a symlink!
1722017-08-10T18:29:17  <earlz> lxc-execute: File exists - failed to mount 'shm' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs/dev/shm'
1732017-08-10T18:29:42  <wumpus> might be that some steps code-rotted, due to debian version drift
1742017-08-10T18:30:19  <wumpus> ideally someone would try to follow it every so often, from scratch, and make corrections where needed
1752017-08-10T18:30:26  <earlz> I did this same process a week ago and ran into 2 completely different problems, 1 where I just needed to reboot, and 1 where I ahd to do something to make network connections work
1762017-08-10T18:30:46  <achow101> earlz: that should have been fixed by https://github.com/devrandom/gitian-builder/pull/150
1772017-08-10T18:31:11  <achow101> did you pull in the latest version of gitian-builder?
1782017-08-10T18:32:31  <earlz> I just cloned it today, so yes. I'm using debian 8.5 as used in the walkthrough also, so I don't think it's the same issue
1792017-08-10T18:33:42  <earlz> Might try rolling back that commit and seeing what happens
1802017-08-10T18:35:00  <earlz> yep, rolling back the bit for shm fixed the initial problem at least. I'll report a bug there
1812017-08-10T18:35:37  <wumpus> so another source of drift would be gitian-builder updates :)
1822017-08-10T18:40:56  *** Dizzle has joined #bitcoin-core-dev
1832017-08-10T18:42:05  *** arowser has quit IRC
1842017-08-10T18:51:18  *** laurentmt has joined #bitcoin-core-dev
1852017-08-10T18:53:18  *** laurentmt has quit IRC
1862017-08-10T18:54:04  *** frogstar has joined #bitcoin-core-dev
1872017-08-10T18:55:06  *** arowser has joined #bitcoin-core-dev
1882017-08-10T18:56:19  *** clarkmoody has joined #bitcoin-core-dev
1892017-08-10T18:58:08  <frogstar> clarkmoody!
1902017-08-10T18:58:13  <frogstar> I love your charts!
1912017-08-10T18:58:52  <kanzure> wrong channel
1922017-08-10T18:59:06  *** alreadylate has joined #bitcoin-core-dev
1932017-08-10T19:00:10  <achow101> meeting?
1942017-08-10T19:00:16  <wumpus> #startmeeting
1952017-08-10T19:00:16  <lightningbot> Meeting started Thu Aug 10 19:00:16 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
1962017-08-10T19:00:16  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
1972017-08-10T19:00:20  <jonasschnelli> hi
1982017-08-10T19:00:22  <achow101> hi
1992017-08-10T19:00:24  <Chris_Stewart_5> ello
2002017-08-10T19:00:26  <sdaftuar> hey
2012017-08-10T19:00:45  <instagibbs> hi
2022017-08-10T19:00:59  <wumpus> any topics?
2032017-08-10T19:01:18  <jnewbery> #10882 please
2042017-08-10T19:01:22  <gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Stop advancing best block and shutdown node if keypool drops below critical threshold by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
2052017-08-10T19:01:42  <wumpus> good idea
2062017-08-10T19:01:43  <wumpus> #topic Stop advancing best block and shutdown node if keypool drops below critical threshold
2072017-08-10T19:02:08  <cfields> hi
2082017-08-10T19:02:20  <jonasschnelli> jnewbery: is that the alternative for keypool topup for 0.15?
2092017-08-10T19:02:23  <kanzure> hi.
2102017-08-10T19:02:27  <wumpus> that replaced #11022 for 015.0?
2112017-08-10T19:02:29  <gribble> https://github.com/bitcoin/bitcoin/issues/11022 | Basic keypool topup by jnewbery · Pull Request #11022 · bitcoin/bitcoin · GitHub
2122017-08-10T19:02:55  <jonasschnelli> What was/is wrong with 11022?
2132017-08-10T19:03:11  <achow101> jonasschnelli: 11022 is part of 10882 split into a separate pr
2142017-08-10T19:03:16  <luke-jr> if the node shuts down, how can users recover? O.o
2152017-08-10T19:03:18  <wumpus> it was getting too large IIRC
2162017-08-10T19:03:29  <jnewbery> #10882 is the same as it has been for the last few days (mark-used if later key from keypool used, try to topup, stop node if can't, etc)
2172017-08-10T19:03:32  <gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Stop advancing best block and shutdown node if keypool drops below critical threshold by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
2182017-08-10T19:03:41  <jonasschnelli> Ah. Same problem I had with my original PR. :/
2192017-08-10T19:03:48  <jnewbery> I split #11022 off as the (hopefully) uncontroversial changes
2202017-08-10T19:03:50  <gribble> https://github.com/bitcoin/bitcoin/issues/11022 | Basic keypool topup by jnewbery · Pull Request #11022 · bitcoin/bitcoin · GitHub
2212017-08-10T19:04:12  <jnewbery> it just marks keys as used and tops up the keypool. No stop node/don't advance best block
2222017-08-10T19:04:20  <gmaxwell> I was making the recommendation that we split out the part that marks used and refills the pool and get that merged. It is a strict improvement with no downsides or extra considerations.
2232017-08-10T19:04:29  <gmaxwell> that one!
2242017-08-10T19:04:42  <kanzure> (nick ping)
2252017-08-10T19:04:55  <cfields> gmaxwell: can you do your hilite reminder? almost missed this
2262017-08-10T19:04:58  <cfields> yes, that :)
2272017-08-10T19:05:35  <wumpus> sounds like a good idea to factor out the critical, lower-risk changes so that it can still make 0.15.0rc1
2282017-08-10T19:05:52  *** andytoshi has joined #bitcoin-core-dev
2292017-08-10T19:05:53  <wumpus> though this does mean it needs a new review round
2302017-08-10T19:06:00  <gmaxwell> I believe all the shutdown ones have unanswered questions.
2312017-08-10T19:06:07  <wumpus> #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 jl2012 achow101
2322017-08-10T19:06:21  <gmaxwell> cfields: mine seems to be broken. Thanks wumpus.
2332017-08-10T19:06:25  <cfields> thanks
2342017-08-10T19:06:31  <sipa> present
2352017-08-10T19:06:36  <CodeShark> hello all
2362017-08-10T19:06:42  <paveljanik> here
2372017-08-10T19:06:55  <luke-jr> the startmeeting command should do it <.<
2382017-08-10T19:06:58  <Murch> hullo
2392017-08-10T19:07:04  <sipa> wumpus: the initial commits are the same
2402017-08-10T19:07:06  <jnewbery> I thought we were very close with 10882, with ACKs from several people. Greg - could you ask your unanswered questions in the PR? Your comments have mostly been in IRC and it's difficult to keep track of what your current concerns are
2412017-08-10T19:07:33  <wumpus> sipa: yes
2422017-08-10T19:09:09  <wumpus> 10882 was kind of a miscommunication, I almost merged than when it turned out that there were still critical concerns with it
2432017-08-10T19:09:21  *** sanada` has quit IRC
2442017-08-10T19:09:40  <gmaxwell> jnewbery: it's not with your implementation specifically, but the correct behavior.  Shutting down on never-behind wallets who just drained their keypools (or never had a big keypool) is undesirable, but it doesn't appear to be possible to detect if a wallet had potentially been behind or not. (e.g. the only during rescan hurestic will fail in some places where the node and the wallet were both
2452017-08-10T19:09:46  <gmaxwell> behind; as a simple example: backup your whole .bitcoin directory and later restor the backup)
2462017-08-10T19:10:07  *** arowser has quit IRC
2472017-08-10T19:10:18  <MarcoFalke> so 11022 is for 0.15 and 10882 should be removed from the milestone?
2482017-08-10T19:10:20  <gmaxwell> restore*
2492017-08-10T19:11:03  <wumpus> MarcoFalke: huh
2502017-08-10T19:11:19  <luke-jr> IMO the correct behaviour would be an interface for pruning locks in general (usable by external wallets too), and track the best chain independently from where the UTXO set is. but this is way too complicated IMO. :/
2512017-08-10T19:11:21  <wumpus> wasn't it the other way around?
2522017-08-10T19:11:27  *** arowser has joined #bitcoin-core-dev
2532017-08-10T19:11:39  <gmaxwell> MarcoFalke: that was my suggestion: merge the part we know is done. I don't think we can make a 10882 right now that won't result in strange behavior in some corner cases.
2542017-08-10T19:11:40  <sipa> luke-jr: yes, that's the eventual goal - agree, but we don't have to go there in one step
2552017-08-10T19:11:51  <jnewbery> wumpus : MarcoFalke has it right. 11022 is the simple subset
2562017-08-10T19:11:53  <achow101> wumpus: 11022 is newer than 10882
2572017-08-10T19:11:53  <wumpus> 11022 was removed from 0.15, and 10882 replaced it
2582017-08-10T19:12:00  <gmaxwell> (at least not in short order)
2592017-08-10T19:12:03  <wumpus> why and who did that then?
2602017-08-10T19:12:07  * wumpus is really confused
2612017-08-10T19:12:17  <gmaxwell> 11022 is a massive improvement and safty increase.
2622017-08-10T19:12:26  <achow101> wumpus: 10882 was created, 11022 was split out from 10882
2632017-08-10T19:12:27  <sipa> 11022 is 10882 without the shutdown logic
2642017-08-10T19:12:30  <wumpus> what can we realistically finish in say, a week?
2652017-08-10T19:12:47  <gmaxwell> wumpus: there was a thid PR you're thinking of 11022 is new, as of a few hours ago.
2662017-08-10T19:12:58  <luke-jr> what if we just stop pruning, and let the normal low-disk-space shutdown do the job? ;)
2672017-08-10T19:13:06  <sipa> luke-jr: die
2682017-08-10T19:13:11  <luke-jr> :|
2692017-08-10T19:13:13  <gmaxwell> luke-jr: pruning is also not the only issue.
2702017-08-10T19:13:14  <wumpus> we can't continue adding things for 0.15 as that fix grows in scope more and more
2712017-08-10T19:13:23  <sipa> wumpus: 11022 is a reduction in scope
2722017-08-10T19:13:35  <sipa> i think 11022 can be ready to merge today or so
2732017-08-10T19:13:38  <wumpus> as this all deals with something that is not a regression in 0.15, I'm starting to be really doubtful about this
2742017-08-10T19:13:44  <gmaxwell> wumpus: that new PR radically reduced the scope, to the core part that has been in every PR so far.
2752017-08-10T19:13:45  <luke-jr> gmaxwell: what am I missing?
2762017-08-10T19:14:00  <sipa> *today
2772017-08-10T19:14:12  <jnewbery> 11022 is ready now. It needs rereview by people, but it should be uncontroversial as it's a subset of what's already been ACKed
2782017-08-10T19:14:57  <wumpus> ah yes I was confused with the other 'keypool topup' PR
2792017-08-10T19:15:05  *** harrymm has quit IRC
2802017-08-10T19:15:43  <MarcoFalke> ok, changed the milestones.
2812017-08-10T19:15:54  <wumpus> thanks
2822017-08-10T19:16:04  <gmaxwell> luke-jr: you could start by already reading the comments that are there.  Each version has failed in different corner cases.  I'll go update the PR with a longer list but after spending an hour talking to Pieter about it I'm just dispondent that it's all a mess that we won't fix quickly (again, not due to the code; but due to what behavior would actually be acceptable.)
2832017-08-10T19:16:09  <jnewbery> full history: Jonas's PR was 10240. I rebased and cleaned that up as 10830. I then reduced the scope and incorporated a bunch of feedback in 10882. I've now reduced the scope again in 11022
2842017-08-10T19:16:40  <wumpus> jnewbery: that's a painful history, thanks for sticking with it
2852017-08-10T19:16:42  *** arowser has quit IRC
2862017-08-10T19:17:12  <jnewbery> painful is a pretty accurate description!
2872017-08-10T19:17:34  <jonasschnelli> ;-)
2882017-08-10T19:17:43  <gmaxwell> luke-jr: but in general, versions that shutdown based on low keypool have a problem with existing wallets failing to work when users upgrade, and efforts to avoid that can create cases where we'll fail to force a shutdown when we should. (for example if the user backed up and restored a whole .bitcoin directory).
2892017-08-10T19:17:56  <jnewbery> but let's try to get 11022 reviewed, and if gmaxwell could leave a nice long comment on 10882 about edge cases perhaps we can try again after 0.15
2902017-08-10T19:18:05  *** arowser has joined #bitcoin-core-dev
2912017-08-10T19:18:21  <gmaxwell> luke-jr: and I think now that a whole subfamily of suggestions I was making are just impossible to actually make work right, for which I am very sorry.
2922017-08-10T19:18:35  <gmaxwell> jnewbery: will do
2932017-08-10T19:18:46  <jnewbery> gmaxwell thanks
2942017-08-10T19:19:32  <jnewbery> sipa ryanofsky morcos bluematt instagibbs reviewed 10882. Should be a straightforward task for them to rereview 11022
2952017-08-10T19:19:39  <sipa> jnewbery: on it
2962017-08-10T19:19:44  <instagibbs> gotcha
2972017-08-10T19:19:45  <sipa> (right now)
2982017-08-10T19:19:47  <wumpus> We can't rule all out edge cases. Tthe most important thing is that people upgrading won't automatically run into the issue because 0.15 sets a larger keypool default.
2992017-08-10T19:20:10  <jnewbery> upgrade isn't an issue in 11022
3002017-08-10T19:20:21  <wumpus> good!
3012017-08-10T19:20:25  <instagibbs> will review today
3022017-08-10T19:20:31  <jnewbery> (and actually isn't in 10882 as it's now implemented, but let's not get into that)
3032017-08-10T19:20:47  <wumpus> do we have a test for that? :)
3042017-08-10T19:21:11  <jnewbery> no, as far as I'm aware we have no upgrade tests. It'd be nice to have them
3052017-08-10T19:21:41  <sipa> (gmaxwell went offline)
3062017-08-10T19:21:57  <wumpus> no, we don't have any upgrade tests
3072017-08-10T19:22:11  <instagibbs> jnewbery, to refresh memory: "Notably, it does not stop the node or prevent the best block from advancing if the keypool drops below a threshold" this is only in case of crypted?
3082017-08-10T19:22:49  <sipa> instagibbs: my belief is that it'll just succesfully top up when unlocked
3092017-08-10T19:23:24  <jnewbery> instagibbs, in 10882 we would only ever prevent best block advancing/stop node when top up was unsuccessful (ie encrypted locked wallet)
3102017-08-10T19:23:39  <sipa> jnewbery: great
3112017-08-10T19:23:39  <jnewbery> 11022 removes all prevent best block advancing/stop node behaviour
3122017-08-10T19:23:57  <instagibbs> got it
3132017-08-10T19:24:16  <wumpus> even better would it be if we had test cases for all of gmaxwell's edge cases
3142017-08-10T19:24:18  <sipa> <gmaxwell> we can now have rescan instructions in our relwase notes: unlock the wallet and run rescan rpc
3152017-08-10T19:24:19  <jnewbery> 11022 is really very simple. It has a bunch of refactor commits, but the functional change is fairly small
3162017-08-10T19:24:54  * gmaxwell back
3172017-08-10T19:25:20  <jnewbery> if we can get bitcoin-wallet-tool and offline topup into v0.16 we have a very nice way of sidestepping most of the problems I believe
3182017-08-10T19:25:24  *** RoyceX has quit IRC
3192017-08-10T19:25:44  <gmaxwell> jnewbery: sipa was just saying something like that to me.
3202017-08-10T19:25:54  <sipa> jnewbery: alternatively, make the dynamic-load-wallet RPC fail in case of too low keypool, and make it take an optional passphrase
3212017-08-10T19:25:55  <luke-jr> at least GUI can block on a passphrase
3222017-08-10T19:26:00  <sipa> luke-jr: that too
3232017-08-10T19:26:03  <jnewbery> yes!
3242017-08-10T19:26:08  <luke-jr> sipa: oooh, that's an excellent approach for bitcoind
3252017-08-10T19:26:23  <gmaxwell> but all to much for 0.15 now.  But at least 11022 massively narrows the window and creates a workaround.
3262017-08-10T19:26:26  <sipa> agree
3272017-08-10T19:27:19  <sipa> any other 0.15-related topics?
3282017-08-10T19:27:44  <wumpus> although harder to implement there's no reason bitcoind couldn't block on a passphrase, justblock everything until a walletpassphrase command
3292017-08-10T19:27:55  <jnewbery> yuck
3302017-08-10T19:28:04  <luke-jr> if I prioritise rebasing the optional default-wallet, would it be considered for inclusion?
3312017-08-10T19:28:05  <jnewbery> multiwallet?
3322017-08-10T19:28:50  <luke-jr> wumpus: can RPC run without the node running?
3332017-08-10T19:29:36  *** gribble has quit IRC
3342017-08-10T19:29:53  <wumpus> luke-jr: in the same way the GUI can I guess
3352017-08-10T19:30:09  <gmaxwell> jnewbery: I think that is less yuck than some other options.  Though really it's block until passphrase or the critical key level is changed.
3362017-08-10T19:30:34  <wumpus> holding up RPC commands for a long time is bound to run into timeouts though
3372017-08-10T19:30:53  <luke-jr> wumpus: we already throw exceptions during init
3382017-08-10T19:31:04  <luke-jr> so we'd just need to make an exception for walletpassphrase
3392017-08-10T19:31:13  <wumpus> yes it's kind of yuck, it's opposite from anything we want to do, with the wallet being able to block the node
3402017-08-10T19:31:18  <luke-jr> the catch to this (and GUI prompting I guess) is that we need to load the wallet earlier
3412017-08-10T19:32:17  <gmaxwell> longer term we'll need ways to rescan wallets when there is pruning.  E.g. PIR wallet queries. But that is a research project with a 1yr horizon or so.
3422017-08-10T19:32:41  <gmaxwell> once we have something like this I think much of this mess goes away.
3432017-08-10T19:32:50  <jnewbery> Are there any other circumstances where bitcoind waits for stdin? I think it might inadvertently break peoples assumptions
3442017-08-10T19:32:52  <jonasschnelli> pir?
3452017-08-10T19:33:07  <sipa> jonasschnelli: https://en.wikipedia.org/wiki/Private_information_retrieval
3462017-08-10T19:33:08  <jnewbery> also it's messy if multiwallets are prompting for passphrases
3472017-08-10T19:33:20  <jonasschnelli> thy
3482017-08-10T19:33:32  <gmaxwell> jnewbery: not stdin, but accepting rpc connections and throwing the not ready yet error for all but walletpassphrase.
3492017-08-10T19:33:45  <gmaxwell> (like we do when loading the block index)
3502017-08-10T19:34:16  <jnewbery> oh ok, yeah that's not so bad
3512017-08-10T19:34:27  <gmaxwell> now I understand the yuck better. :)
3522017-08-10T19:34:27  <jnewbery> but to be clear, not for 0.15 :)
3532017-08-10T19:34:31  <gmaxwell> yes.
3542017-08-10T19:34:32  <wumpus> luke-jr: you mean going back into warmup mode? hmm then all clients would have to handle that
3552017-08-10T19:34:43  *** alreadylate has quit IRC
3562017-08-10T19:35:03  <wumpus> oh certainly not stdin
3572017-08-10T19:35:03  <luke-jr> wumpus: I mean never leaving warmup mode :p
3582017-08-10T19:35:12  <wumpus> luke-jr: that'd make sense
3592017-08-10T19:35:42  <wumpus> luke-jr: I somehow assumed it was something that could happen at runtime
3602017-08-10T19:35:54  <wumpus> anyhow, yes not for 0.15
3612017-08-10T19:36:06  <luke-jr> it probably can
3622017-08-10T19:36:08  *** gribble has joined #bitcoin-core-dev
3632017-08-10T19:36:17  <luke-jr> keypool size is still configurable I assume
3642017-08-10T19:36:29  <wumpus> but for dynamic wallet loading optionally passing the passphrase on load makes sense
3652017-08-10T19:37:23  <wumpus> ok - any other topics?
3662017-08-10T19:37:25  <jnewbery> Being able to run commands on load was my main motivation for #10740 . Unlocking and topping-up keypool fits well with that
3672017-08-10T19:38:09  <gmaxwell> I'd like to remind people that we all need to be testing on master hard right now. :)
3682017-08-10T19:38:12  <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [WIP] [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
3692017-08-10T19:38:45  <wumpus> if only we had rc1 out everyone could be testing on rc1 :)
3702017-08-10T19:40:10  <sdaftuar> where are we on the segwit address format?
3712017-08-10T19:40:21  <wumpus> #topic segwit address format
3722017-08-10T19:41:02  <sipa> sdaftuar: https://github.com/sipa/bech32/pull/21
3732017-08-10T19:41:19  <sipa> almost done with a C++ reference version (though gmaxwell keeps finding untested cases)
3742017-08-10T19:41:29  *** JackH has quit IRC
3752017-08-10T19:41:30  <sipa> when that's done, i'll submit a PR to core to integrate it
3762017-08-10T19:41:34  <sdaftuar> great!
3772017-08-10T19:41:39  <jonasschnelli> nice
3782017-08-10T19:41:39  <cfields> sipa: great. will review that.
3792017-08-10T19:42:02  <sipa> which will need some refactor to get rid of CBitcoinAddress (i'm sorry for ever introducing that... there is no point for that to be a separate class...)
3802017-08-10T19:42:25  <Chris_Stewart_5> Is this going to be in 0.15.0 or 0.15.1?
3812017-08-10T19:42:35  <cfields> sipa: maybe best to just cram it into CBitcoinAddress first for easy 0.15 backport ?
3822017-08-10T19:42:40  <sdaftuar> not 0.15.0
3832017-08-10T19:42:43  <wumpus> certainly not 0.15.0
3842017-08-10T19:42:44  <Chris_Stewart_5> ok good
3852017-08-10T19:42:49  <jonasschnelli> Chris_Stewart_5: not in 0.15.0 maybe in 0.15.SW
3862017-08-10T19:42:59  <sipa> cfields: i'll see what i can do
3872017-08-10T19:43:44  <cfields> ok
3882017-08-10T19:44:22  <wumpus> any other topics?
3892017-08-10T19:44:25  <CodeShark> I have a quick one
3902017-08-10T19:44:45  <luke-jr> the hardest topics to discuss are the ones that are not disclosed. :P
3912017-08-10T19:45:04  <CodeShark> I would need to rebase, but now that SegWit is activating I'd really like to merge https://github.com/bitcoin/bitcoin/pull/10350
3922017-08-10T19:46:03  <wumpus> #topic Added support for MSG_FILTERED_WITNESS_BLOCK messages
3932017-08-10T19:47:00  <jonasschnelli> Wound't that require a bip first?
3942017-08-10T19:47:13  *** jimpo has quit IRC
3952017-08-10T19:47:17  <CodeShark> is it really worth the effort?
3962017-08-10T19:47:23  <CodeShark> it's getting deprecated eventually
3972017-08-10T19:47:26  <CodeShark> probably pretty soon
3982017-08-10T19:47:33  <gmaxwell> well obviously not merged now, but perhaps in the .SW release. It needs a bip. unconditionally but it would be a trivial spec.
3992017-08-10T19:47:41  <CodeShark> ok
4002017-08-10T19:47:45  <gmaxwell> I can help with the bip.
4012017-08-10T19:47:53  <sipa> it doesn't look like it's too much work to add a witness proof
4022017-08-10T19:47:54  <wumpus> yeah it's a network protocol change so it needs some kind of BIP
4032017-08-10T19:47:55  <gmaxwell> (show of good will, since I really dislike the feature. :) )
4042017-08-10T19:48:00  <CodeShark> thanks, gmaxwell
4052017-08-10T19:48:20  <wumpus> if only to be able to refer to it in bips.md and such
4062017-08-10T19:48:26  <gmaxwell> (not due to it itself, but due to increasing the scope of BIP37)
4072017-08-10T19:48:33  <jonasschnelli> CodeShark: why would it get deprecated (you mean dep. bip37 in favor of client side filtering)?
4082017-08-10T19:48:39  <CodeShark> jonasschnelli: yes
4092017-08-10T19:48:43  <luke-jr> if it's literally only for short-term use by mSIGNA, I'm not sure it strictly NEEDS a BIP.
4102017-08-10T19:48:54  <gmaxwell> luke-jr: it's trivial to specify however.
4112017-08-10T19:48:56  <luke-jr> sure
4122017-08-10T19:49:05  <CodeShark> yeah, probably should stick to process
4132017-08-10T19:49:08  <wumpus> why not? it's good to have some kind of documentation
4142017-08-10T19:49:18  <gmaxwell> and the spec can also do things like tell people it is intended to be short lived.
4152017-08-10T19:49:20  <jonasschnelli> I guess there are still usecases for BIP37 once BIP150 is life (trusted peers)
4162017-08-10T19:49:21  <wumpus> others might want to use it too
4172017-08-10T19:49:46  <luke-jr> CodeShark: if you can rebase it quickly, maybe we can throw it in Knots until it's ready for Core
4182017-08-10T19:49:58  <CodeShark> sure :)
4192017-08-10T19:49:59  <jonasschnelli> I'm strongly advice for a BIP. Other may be interested and we don't want more specification within the code.
4202017-08-10T19:50:07  <gmaxwell> jonasschnelli: you can still do better things for that case, like send them the addresses explicitly.
4212017-08-10T19:50:25  <jonasschnelli> gmaxwell: Yes. But would require more work to do. :)
4222017-08-10T19:50:27  <sipa> i'd really like to see the addition of witness proofs, though - i understand that for your exact use case (which implies a trusted full node) that's unnecessary, but i don't think we should go that route in protocol extensions
4232017-08-10T19:50:42  <wumpus> gmaxwell: heh yes, if the connection is encrypted and the peer is trusted, why not, why even bother with a bloom filter
4242017-08-10T19:50:56  <gmaxwell> in any case basically any argument against doing a BIP is an argument for one too... it's trivial.  it's intended to be short lived (BIP would tell people that).
4252017-08-10T19:50:58  *** Cory has quit IRC
4262017-08-10T19:51:10  <gmaxwell> sipa: it would be a trivial change to make it do the witness proofs, no? just root on the other tree.
4272017-08-10T19:51:29  <sipa> gmaxwell: and give the coinbase, and normal merkle proof for the coinbase
4282017-08-10T19:51:36  <CodeShark> sipa: I am still not convinced it's worth the effort to add the witness proof
4292017-08-10T19:51:42  <wumpus> then again BIP37 works now, that's a point, step-by-step evolution usually means that things keep moving instead of being blocked by big moves
4302017-08-10T19:51:52  <CodeShark> the coinbase issue means we need an entire new data structure
4312017-08-10T19:51:53  <sipa> CodeShark: then i would be opposed to supporting it
4322017-08-10T19:52:06  <sipa> CodeShark: use RPC instead
4332017-08-10T19:52:11  <CodeShark> huh?!
4342017-08-10T19:52:14  <gmaxwell> CodeShark: it's just a existing thing for the coinbase, and then one more rooted in it.
4352017-08-10T19:52:54  <CodeShark> it already takes me hours to sync back just a few weeks
4362017-08-10T19:53:00  <CodeShark> RPC would mean it takes forever
4372017-08-10T19:53:03  <sipa> CodeShark: you're asking to add a feature, available to every P2P client, which can only be safely used in a trusted setting
4382017-08-10T19:53:03  <luke-jr> why would you need a witness proof in this case anyway?
4392017-08-10T19:53:11  *** SkynetS has joined #bitcoin-core-dev
4402017-08-10T19:53:14  <CodeShark> sipa: ah, I see your point
4412017-08-10T19:53:15  <sipa> luke-jr: because the full node can lie
4422017-08-10T19:53:37  <luke-jr> sipa: about what? these peers don't have any need for the witness data at all
4432017-08-10T19:53:38  <CodeShark> agree that the trusted mode is distinct from p2p, but the HTTP server approach just won't do ;)
4442017-08-10T19:53:45  <sipa> luke-jr: read the PR
4452017-08-10T19:53:55  <wumpus> sipa has a good point, if it's to be on the P2P network, it has to be possible to use it untrusted
4462017-08-10T19:53:57  <sipa> luke-jr: CodeShark needs it to determine which subset of multisig signers spent the coins
4472017-08-10T19:54:11  <luke-jr> oh!
4482017-08-10T19:54:11  *** jimmysong has joined #bitcoin-core-dev
4492017-08-10T19:54:11  *** SopaXorzTaker has quit IRC
4502017-08-10T19:54:13  <wumpus> if not you'd have to wait for BIP150 (authentication)
4512017-08-10T19:54:26  <wumpus> and allow it to authenticated peers only
4522017-08-10T19:54:42  <sipa> yes, that would be private extensions easier
4532017-08-10T19:55:14  <sipa> CodeShark: but honestly, i don't think adding a proof for the witnesses is that hard; just send two structures (one with normal proof for coinbase, one with witness proof for the rest)
4542017-08-10T19:55:37  <CodeShark> it requires a lot of additional clientside modifications as well, I'd rather focus on clientside filtering
4552017-08-10T19:55:44  <gmaxwell> yea, if we had BIP150 I wouldn't mind random extensions there even without bips. if you're only using it between trusted adjcencies the criteria is different.
4562017-08-10T19:56:49  *** Pasha has joined #bitcoin-core-dev
4572017-08-10T19:57:13  <CodeShark> not saying it's hard - just time I think would be better invested elsewhere
4582017-08-10T19:57:26  <sipa> yes, like helping with client side filtering :)
4592017-08-10T19:57:31  <CodeShark> indeed
4602017-08-10T19:57:35  *** chjj has quit IRC
4612017-08-10T19:57:39  <sdaftuar> also though, if you intend to only use something on trusted nodes you could just carry a custom patch, no?  i mean, if there's not much other demand for this extension.
4622017-08-10T19:57:50  <achow101> does client side filtering have a bip?
4632017-08-10T19:57:55  <jonasschnelli> Could you not impelement directly the client side filtering?
4642017-08-10T19:58:07  <sipa> jonasschnelli: it's a nontrivial effort
4652017-08-10T19:58:11  <jonasschnelli> achow101: roasbeef hasn't opened the PR (last state is the ML post)
4662017-08-10T19:58:14  <sipa> needs stored bloom filters for all blocks on disk etc
4672017-08-10T19:58:33  <wumpus> achow101: not afaik
4682017-08-10T19:59:00  <jonasschnelli> sipa: Yes. But a long term strategy and there are a couple of people willing to contribute
4692017-08-10T19:59:05  <sipa> sure
4702017-08-10T19:59:05  <luke-jr> I assumed jonasschnelli meant implement BIP37 client-side
4712017-08-10T19:59:20  <jonasschnelli> not bip37
4722017-08-10T19:59:20  <CodeShark> lol, BIP37 needs to eventually die
4732017-08-10T19:59:24  <gmaxwell> I don't thin the spec has been updated to eliminate the divisions yet.
4742017-08-10T20:00:00  *** Pasha is now known as Cory
4752017-08-10T20:00:10  <wumpus> meeting time is over
4762017-08-10T20:00:18  *** chjj has joined #bitcoin-core-dev
4772017-08-10T20:00:19  <wumpus> #endmeeting
4782017-08-10T20:00:19  <lightningbot> Meeting ended Thu Aug 10 20:00:18 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
4792017-08-10T20:00:19  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-10-19.00.html
4802017-08-10T20:00:19  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-10-19.00.txt
4812017-08-10T20:00:19  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-10-19.00.log.html
4822017-08-10T20:00:22  <luke-jr> but I just pinged roasbeef for the meeting :P
4832017-08-10T20:00:36  <wumpus> :P
4842017-08-10T20:00:36  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #11025: qa: Fix inv race in example_test (master...Mf1708-qaInvExampleTest) https://github.com/bitcoin/bitcoin/pull/11025
4852017-08-10T20:00:40  <roasbeef> achow101: there's a BIP draft, but I've been side tracked on another project. I need to incorporate suggestions for optimizations, then wrap up some TODO's and i'll officially request a #
4862017-08-10T20:00:54  <roasbeef> will be able to finish it up in a week or two
4872017-08-10T20:01:04  <jonasschnelli> roasbeef: Thanks for working on this!
4882017-08-10T20:01:18  <achow101> roasbeef: cool
4892017-08-10T20:01:18  <CodeShark> yes, roasbeef  +1
4902017-08-10T20:01:37  *** andytoshi has left #bitcoin-core-dev
4912017-08-10T20:05:54  *** alreadylate has joined #bitcoin-core-dev
4922017-08-10T20:06:26  *** alreadylate has quit IRC
4932017-08-10T20:07:28  <instagibbs> roasbeef, does the other project rhyme with brightening
4942017-08-10T20:09:02  <roasbeef> something that just occured to me is also that it would be possible for pruned nodes to still serve light clients, assuming they still keep the filters on disk
4952017-08-10T20:09:03  <sipa> instagibbs: not in my understanding of english pronounciation
4962017-08-10T20:09:11  <roasbeef> instagibbs: maaaybe
4972017-08-10T20:10:28  *** chjj has quit IRC
4982017-08-10T20:11:40  *** chjj has joined #bitcoin-core-dev
4992017-08-10T20:26:27  *** chjj has quit IRC
5002017-08-10T20:29:27  *** chjj has joined #bitcoin-core-dev
5012017-08-10T20:44:59  <bitcoin-git> [bitcoin] luke-jr opened pull request #11026: Bugfix: Use testnet RequireStandard for -acceptnonstdtxn default (master...bugfix_acceptnonstd_def) https://github.com/bitcoin/bitcoin/pull/11026
5022017-08-10T20:55:10  *** Dyaheon has quit IRC
5032017-08-10T20:56:29  *** Dyaheon has joined #bitcoin-core-dev
5042017-08-10T20:58:07  *** rjak2 has joined #bitcoin-core-dev
5052017-08-10T20:58:07  *** rjak has quit IRC
5062017-08-10T20:58:20  *** rjak2 is now known as rjak
5072017-08-10T21:32:33  *** jimpo has joined #bitcoin-core-dev
5082017-08-10T21:35:17  *** corinrose_ has quit IRC
5092017-08-10T21:53:37  *** Yogaqueef has quit IRC
5102017-08-10T22:07:13  *** arubi has quit IRC
5112017-08-10T22:09:02  *** Chris_Stewart_5 has quit IRC
5122017-08-10T22:28:16  *** chjj has quit IRC
5132017-08-10T22:30:23  *** chjj has joined #bitcoin-core-dev
5142017-08-10T22:33:48  *** justanotheruser has joined #bitcoin-core-dev
5152017-08-10T22:34:33  *** chjj has quit IRC
5162017-08-10T22:34:55  *** chjj has joined #bitcoin-core-dev
5172017-08-10T22:36:36  *** Dizzle has quit IRC
5182017-08-10T22:41:37  *** jimpo has quit IRC
5192017-08-10T22:42:48  *** jimpo has joined #bitcoin-core-dev
5202017-08-10T22:49:05  *** vicenteH has quit IRC
5212017-08-10T22:56:10  *** jimmysong has quit IRC
5222017-08-10T22:57:31  *** smill has quit IRC
5232017-08-10T23:01:27  *** echonaut has quit IRC
5242017-08-10T23:01:37  *** echonaut has joined #bitcoin-core-dev
5252017-08-10T23:02:26  *** abpa has quit IRC
5262017-08-10T23:09:03  <bitcoin-git> [bitcoin] achow101 opened pull request #11027: [RPC] Only return hex field once in getrawtransaction (master...fix-getrawtx) https://github.com/bitcoin/bitcoin/pull/11027
5272017-08-10T23:26:45  *** goldstar has joined #bitcoin-core-dev
5282017-08-10T23:27:12  *** LeMiner has quit IRC
5292017-08-10T23:28:33  *** LeMiner has joined #bitcoin-core-dev
5302017-08-10T23:29:04  *** justanotheruser has quit IRC
5312017-08-10T23:29:59  *** RoyceX has joined #bitcoin-core-dev
5322017-08-10T23:31:46  *** Aaronvan_ has joined #bitcoin-core-dev
5332017-08-10T23:33:24  <sipa> happy block 0x75300 everyone
5342017-08-10T23:34:01  <sipa> it doesn't look at good in hex :(
5352017-08-10T23:35:05  *** AaronvanW has quit IRC
5362017-08-10T23:40:19  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5372017-08-10T23:40:26  *** miknotauro has quit IRC
5382017-08-10T23:50:19  *** Chris_Stewart_5 has quit IRC
5392017-08-10T23:54:04  *** RoyceX has quit IRC
5402017-08-10T23:58:50  <luke-jr> XD