12017-04-13T00:00:57  *** abpa has quit IRC
  22017-04-13T00:04:14  *** AaronvanW has quit IRC
  32017-04-13T00:11:32  *** chjj has joined #bitcoin-core-dev
  42017-04-13T00:14:10  *** Ylbam has quit IRC
  52017-04-13T00:17:44  <jtimon> sipa: I'm getting some errors related to prevector templating, perhaps you can help with https://github.com/bitcoin/bitcoin/pull/10193#issuecomment-293742166
  62017-04-13T00:22:50  *** Giszmo has joined #bitcoin-core-dev
  72017-04-13T00:32:33  <sdaftuar> gmaxwell: is this what you have in mind? https://github.com/sdaftuar/bitcoin/tree/2017-04-braindead-simple-mining
  82017-04-13T00:32:59  <sdaftuar> i'm happy to simulate it for you on the same data set i've been using, just tell me what parameters you'd like to see
  92017-04-13T00:33:27  <sdaftuar> i'm not a fan of the model though
 102017-04-13T00:35:48  *** midnightmagic has quit IRC
 112017-04-13T00:41:53  *** midnightmagic has joined #bitcoin-core-dev
 122017-04-13T01:10:11  *** d_t has joined #bitcoin-core-dev
 132017-04-13T01:11:52  *** d_t has joined #bitcoin-core-dev
 142017-04-13T01:19:07  <gmaxwell> sdaftuar: 10 seconds and .0005 BTC should be fine for a test run.
 152017-04-13T01:22:46  <gmaxwell> sdaftuar: I would gladly agree that it's a hack. But -- it's surely a simple one, if there is nothing else that could be said about it..  CreateNewBlock performance and simplicity counts for a lot.
 162017-04-13T01:24:55  <gmaxwell> sdaftuar: also because of how BIP152 works it is still preferable to have less new data. E.g. having a binary "contains new stuff" vs "not" isn't ideal--- because once prefilling is in use up to 10kb will be prefilled and if there is more than that, we're likely to prefill noting (under the assumption that the block is too inconsistent to be salvagable)
 172017-04-13T01:25:05  *** isle2983 has quit IRC
 182017-04-13T01:25:20  <sdaftuar> gmaxwell: that seems gameable though?  if i just rbf a transaction every 10 seconds with fee 50000, 50000+incremental_relay_fee, ... you'll always produce a block with a recent transaction, and i'll give up a negligible amount of money?
 192017-04-13T01:26:53  <gmaxwell> sdaftuar: 10 seconds is a non-trivial amount of time to allow propagation however.
 202017-04-13T01:27:27  <sdaftuar> gmaxwell: i agree about the prefilling concern... that was part of the reason i was skeptical of this approach at all, but i figured that for now, "needs a roundtrip" is pretty different from not needing a roundtrip, so might as well capture that.
 212017-04-13T01:28:10  <sdaftuar> even if i rbf every 5 seconds, its a trivial amount of money
 222017-04-13T01:28:26  *** Guest76166 has quit IRC
 232017-04-13T01:29:43  <gmaxwell> I did calculations before that were hand-wave-handwave about the cost of orphaning relative to the subsidy based on block propagation observations and concluded a pretty low fee pays for the risk.
 242017-04-13T01:30:09  <gmaxwell> (mentioned somewhere in the logs here)
 252017-04-13T01:31:16  <sdaftuar> yeah i have no idea what the actual stale rates people see are
 262017-04-13T01:32:08  <sdaftuar> (and really, my model requires converting two numbers into 1 -- stale rate without recent txs/stale rate with recent txs -> my parameter.  not a difficult calculation, but requires understanding
 272017-04-13T01:32:46  <sdaftuar> for clarity:  that "/" above is not meant to be division
 282017-04-13T01:34:06  <gmaxwell> well my figuring didn't use stale rates but measurements of delays between stratum updates at pools as a function of blocksize, so I was able to come up with a constant + factor*size model for orphaning risk.  This was before BIP152-- and I think we can't really measure it anymore, but I figure the before bip152 figures give a baseline for the marginal impact. my model basically assumed the comp
 292017-04-13T01:34:12  <gmaxwell> etition was sending an empty block.
 302017-04-13T01:34:53  *** btcdrak has quit IRC
 312017-04-13T01:51:13  <sdaftuar> gmaxwell: for the 0.14.1 release notes, did you want to specifically mention that the 0.14.0 defaults could result in the utxo cache using 1.2GB of memory due to mempool sharing?
 322017-04-13T01:52:13  <sdaftuar> i just pushed an update to #10185 but didn't call out that fact specifically, let me know if you'd like me to add it
 332017-04-13T01:52:14  <gribble> https://github.com/bitcoin/bitcoin/issues/10185 | [0.14] Mention dbcache memory changes in release notes by sdaftuar · Pull Request #10185 · bitcoin/bitcoin · GitHub
 342017-04-13T01:52:39  <gmaxwell> sdaftuar: I don't remember now, I don't think I wanted to do that. did I?  uh. I don't think we should bother mentioning the 0.14.0 usage. Did you mention it before but only say it could use 600 or something?
 352017-04-13T01:53:15  <sdaftuar> gmaxwell: i just explained that the 300MiB default could result in 600MiB of usage, so that people would know to double their values if they wanted to, say, keep the whole thing cached still
 362017-04-13T01:53:41  <sdaftuar> ah, i guess my language is potentially confusing
 372017-04-13T01:55:06  <gmaxwell> sdaftuar: but with the mempool the defaults could be 1200 which is what I was trying to express.. the dbcache just get doubled, the mempool did too.
 382017-04-13T01:55:12  <sdaftuar> right
 392017-04-13T01:55:21  <sdaftuar> all i wanted to explain was "multiply by 2!"
 402017-04-13T01:55:28  <sdaftuar> maybe just delete my parenthetical?
 412017-04-13T01:58:48  <sdaftuar> ok, got rid of it -- hopefully the sentence about only accounting for half the peak utilization will be enough for people to figure out what they want to do.
 422017-04-13T02:00:06  *** dermoth has quit IRC
 432017-04-13T02:00:48  *** dermoth has joined #bitcoin-core-dev
 442017-04-13T02:04:10  *** AaronvanW has joined #bitcoin-core-dev
 452017-04-13T02:05:49  *** Samdney has quit IRC
 462017-04-13T02:07:40  *** jtimon has quit IRC
 472017-04-13T02:09:00  *** Chris_Stewart_5 has quit IRC
 482017-04-13T02:15:45  *** Giszmo has quit IRC
 492017-04-13T02:17:24  *** AaronvanW has quit IRC
 502017-04-13T02:21:45  *** AaronvanW has joined #bitcoin-core-dev
 512017-04-13T02:26:47  *** d_t has quit IRC
 522017-04-13T02:29:04  *** talmai has joined #bitcoin-core-dev
 532017-04-13T03:01:20  *** AaronvanW has quit IRC
 542017-04-13T03:06:05  *** AaronvanW has joined #bitcoin-core-dev
 552017-04-13T03:12:21  *** arowser has quit IRC
 562017-04-13T03:13:48  *** arowser has joined #bitcoin-core-dev
 572017-04-13T03:30:57  *** AaronvanW has quit IRC
 582017-04-13T03:33:27  *** AaronvanW has joined #bitcoin-core-dev
 592017-04-13T03:46:06  *** dodomojo has joined #bitcoin-core-dev
 602017-04-13T03:50:56  *** d_t has joined #bitcoin-core-dev
 612017-04-13T03:51:05  *** AaronvanW has quit IRC
 622017-04-13T03:53:38  *** AaronvanW has joined #bitcoin-core-dev
 632017-04-13T04:13:21  *** AaronvanW has quit IRC
 642017-04-13T04:14:42  *** AaronvanW has joined #bitcoin-core-dev
 652017-04-13T04:27:10  *** AaronvanW has quit IRC
 662017-04-13T04:30:51  *** AaronvanW has joined #bitcoin-core-dev
 672017-04-13T04:44:11  *** AaronvanW has quit IRC
 682017-04-13T04:47:36  *** Cheeseo has quit IRC
 692017-04-13T04:49:25  *** AaronvanW has joined #bitcoin-core-dev
 702017-04-13T04:51:49  *** justan0theruser has joined #bitcoin-core-dev
 712017-04-13T04:54:12  *** justanotheruser has quit IRC
 722017-04-13T05:05:05  *** n1ce has quit IRC
 732017-04-13T05:17:01  *** AaronvanW has quit IRC
 742017-04-13T05:18:13  *** AaronvanW has joined #bitcoin-core-dev
 752017-04-13T05:19:27  *** dodomojo has quit IRC
 762017-04-13T05:42:10  *** btcdrak has joined #bitcoin-core-dev
 772017-04-13T05:57:33  *** talmai has quit IRC
 782017-04-13T06:05:49  *** AaronvanW has quit IRC
 792017-04-13T06:07:50  *** AaronvanW has joined #bitcoin-core-dev
 802017-04-13T06:10:16  *** goksinen has joined #bitcoin-core-dev
 812017-04-13T06:15:07  *** Ylbam has joined #bitcoin-core-dev
 822017-04-13T06:15:12  *** goksinen has quit IRC
 832017-04-13T06:16:16  *** AaronvanW has quit IRC
 842017-04-13T06:25:03  *** AaronvanW has joined #bitcoin-core-dev
 852017-04-13T06:31:13  *** AaronvanW has quit IRC
 862017-04-13T06:33:45  *** AaronvanW has joined #bitcoin-core-dev
 872017-04-13T06:47:19  *** AaronvanW has quit IRC
 882017-04-13T06:49:18  *** AaronvanW has joined #bitcoin-core-dev
 892017-04-13T06:49:34  *** vFSgrcFGBJHg has joined #bitcoin-core-dev
 902017-04-13T07:04:05  *** kexkey has quit IRC
 912017-04-13T07:05:20  *** AaronvanW has quit IRC
 922017-04-13T07:08:10  *** AaronvanW has joined #bitcoin-core-dev
 932017-04-13T07:28:09  *** AaronvanW has quit IRC
 942017-04-13T07:30:46  *** CubicEarth has joined #bitcoin-core-dev
 952017-04-13T07:31:14  *** To7 has quit IRC
 962017-04-13T07:43:10  *** Guyver2 has joined #bitcoin-core-dev
 972017-04-13T08:06:45  *** molz_ has joined #bitcoin-core-dev
 982017-04-13T08:10:07  *** mol has quit IRC
 992017-04-13T08:12:45  *** vicenteH has joined #bitcoin-core-dev
1002017-04-13T08:22:59  *** d_t has quit IRC
1012017-04-13T08:29:34  <wumpus> "oh dear god lets not default to running random peoples' commitmsg scripts on wumpus' computer" yes that's not going to happen, I'm already paranoid with github-merge.py itself, I use a version outside the repository and only update it if I carefully reviewed changes inside the repo
1022017-04-13T08:31:01  <gmaxwell> lol, please only on pulltester which is already vulnerable as heck.
1032017-04-13T08:31:15  <MarcoFalke> The script could be run in a vm. Though, it comes with an overhead...
1042017-04-13T08:31:44  <gmaxwell> There are a LOT of vm escape exploits.
1052017-04-13T08:32:18  <wumpus> in any case I don't like the idea of adding more functionality to github-merge.py, please just keep it a merge script and not add any other hooks
1062017-04-13T08:32:19  <MarcoFalke> Running it on travis is not enough. travis is just an indicator that should not be trusted
1072017-04-13T08:32:28  <sipa> i doubt you can trigger any of them from a shell script in a way that it's obvious to cursory review, though
1082017-04-13T08:32:38  <gmaxwell> most recent one in QEMU was awful, with the instruction decoder. Esp since previously I'd intentionally avoided kvm to try to lower risk but that made it trivially exploitable.
1092017-04-13T08:32:53  <MarcoFalke> Just need to make sure the script is reviewed on every (ut)ACK
1102017-04-13T08:33:08  <gmaxwell> sipa: doubt it enough to put a bounty on it though? :P
1112017-04-13T08:43:21  *** AaronvanW has joined #bitcoin-core-dev
1122017-04-13T08:45:43  *** AaronvanW has quit IRC
1132017-04-13T08:46:00  *** AaronvanW has joined #bitcoin-core-dev
1142017-04-13T08:50:35  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/de01da7cad32...c9ff4f8ee601
1152017-04-13T08:50:36  <bitcoin-git> bitcoin/master 714e4ad John Newbery: AddToWalletIfInvolvingMe should test pIndex, not posInBlock
1162017-04-13T08:50:36  <bitcoin-git> bitcoin/master d0cd0bd John Newbery: Make CWallet::SyncTransactions() interface friendlier
1172017-04-13T08:50:37  <bitcoin-git> bitcoin/master c9ff4f8 Wladimir J. van der Laan: Merge #10186: Remove SYNC_TRANSACTION_NOT_IN_BLOCK magic number...
1182017-04-13T08:51:04  <bitcoin-git> [bitcoin] laanwj closed pull request #10186: Remove SYNC_TRANSACTION_NOT_IN_BLOCK magic number (master...remove_SYNC_TRANSACTION_NOT_IN_BLOCK_magic_number) https://github.com/bitcoin/bitcoin/pull/10186
1192017-04-13T08:57:23  *** RubenSomsen has joined #bitcoin-core-dev
1202017-04-13T09:00:41  *** d_t has joined #bitcoin-core-dev
1212017-04-13T09:26:04  *** jtimon has joined #bitcoin-core-dev
1222017-04-13T09:26:16  *** wasi has joined #bitcoin-core-dev
1232017-04-13T09:37:40  *** vFSgrcFGBJHg has quit IRC
1242017-04-13T09:38:57  *** harrymm has quit IRC
1252017-04-13T09:46:44  *** CubicEarth has quit IRC
1262017-04-13T09:53:57  *** RubenSomsen has quit IRC
1272017-04-13T09:55:04  *** harrymm has joined #bitcoin-core-dev
1282017-04-13T10:07:15  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.14: https://github.com/bitcoin/bitcoin/compare/55f641ca194b...06909df179e7
1292017-04-13T10:07:15  <bitcoin-git> bitcoin/0.14 b7caa30 Suhas Daftuar: Mention dbcache memory changes in 0.14.1 release notes
1302017-04-13T10:07:16  <bitcoin-git> bitcoin/0.14 06909df Wladimir J. van der Laan: Merge #10185: [0.14] Mention dbcache memory changes in release notes...
1312017-04-13T10:08:46  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/c9ff4f8ee601...70f6f56e9dde
1322017-04-13T10:08:47  <bitcoin-git> bitcoin/master fd44ac1 NicolasDorier: [Wallet] Rename std::pair<const CWalletTx*, unsigned int> to CInputCoin
1332017-04-13T10:08:48  <bitcoin-git> bitcoin/master e78bc45 NicolasDorier: [Wallet] Decouple CInputCoin from CWalletTx
1342017-04-13T10:08:48  <bitcoin-git> bitcoin/master f597dcb NicolasDorier: [Wallet] Simplify code using CInputCoin
1352017-04-13T10:09:17  <bitcoin-git> [bitcoin] laanwj closed pull request #10165: [Wallet] Refactoring by using CInputCoin instead of std::pair (master...inputcoin) https://github.com/bitcoin/bitcoin/pull/10165
1362017-04-13T10:10:49  *** d_t has quit IRC
1372017-04-13T10:20:38  *** DarkAngel has joined #bitcoin-core-dev
1382017-04-13T10:28:49  *** DarkAngel has quit IRC
1392017-04-13T10:30:36  <wumpus> gmaxwell: one problem is that x86 is such a complex beast to emulate (or even write a instruction decoder for). If you induce the overhead of full emulation for security reasons, might as wll choose a simpler  platform to emulate
1402017-04-13T10:31:51  *** laurentmt has joined #bitcoin-core-dev
1412017-04-13T10:32:38  *** laurentmt has quit IRC
1422017-04-13T10:37:38  <wumpus> may also help to restrict what qemu can do through e.g. apparmor, so if a process manages to escape from the vm it isn't immediately able to do much more than the VM could. libvirt does that by default AFAIK
1432017-04-13T10:43:48  *** RubenSomsen has joined #bitcoin-core-dev
1442017-04-13T11:34:08  *** To7 has joined #bitcoin-core-dev
1452017-04-13T11:53:50  *** annanay25 has quit IRC
1462017-04-13T11:54:00  *** annanay25 has joined #bitcoin-core-dev
1472017-04-13T11:54:40  *** jtimon has quit IRC
1482017-04-13T12:21:35  <sdaftuar> gmaxwell: i ran the sim, with 10 seconds / 50000 satoshi fee threshold, roughly 95% of CNB invocations included a recent transaction.
1492017-04-13T12:29:14  *** goksinen has joined #bitcoin-core-dev
1502017-04-13T12:33:52  *** goksinen has quit IRC
1512017-04-13T12:34:27  *** Cheeseo has joined #bitcoin-core-dev
1522017-04-13T12:34:31  *** Cheeseo has quit IRC
1532017-04-13T12:34:31  *** Cheeseo has joined #bitcoin-core-dev
1542017-04-13T12:56:44  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1552017-04-13T13:02:06  *** gielbier has quit IRC
1562017-04-13T13:06:04  *** gielbier has joined #bitcoin-core-dev
1572017-04-13T13:14:40  *** Chris_Stewart_5 has quit IRC
1582017-04-13T13:23:33  *** goksinen has joined #bitcoin-core-dev
1592017-04-13T13:27:58  *** goksinen has quit IRC
1602017-04-13T13:38:06  <sdaftuar> gmaxwell: for comparison, i re-ran my patch with a setting of 10seconds, 0.2% fee drop, and less than 2% of CNB calls included recent transactions
1612017-04-13T13:45:20  *** jtimon has joined #bitcoin-core-dev
1622017-04-13T13:45:55  <bitcoin-git> [bitcoin] mariodian opened pull request #10201: pass Consensus::Params& to ReceivedBlockTransactions() (master...consensusparams-receivedblocktransactions) https://github.com/bitcoin/bitcoin/pull/10201
1632017-04-13T13:47:08  <bitcoin-git> [bitcoin] NicolasDorier closed pull request #10068: [Wallet] FundRawTransaction accepts preset non-wallet inputs (master...nonwalletinputs) https://github.com/bitcoin/bitcoin/pull/10068
1642017-04-13T13:48:31  <bitcoin-git> [bitcoin] NicolasDorier opened pull request #10202: [Wallet] FundRawTransaction can fund a transaction with preset inputs found in the CoinView (master...fundrawtransaction) https://github.com/bitcoin/bitcoin/pull/10202
1652017-04-13T13:50:32  *** d_t has joined #bitcoin-core-dev
1662017-04-13T13:55:04  *** d_t has quit IRC
1672017-04-13T13:59:52  *** d9b4bef9 has quit IRC
1682017-04-13T14:00:58  *** d9b4bef9 has joined #bitcoin-core-dev
1692017-04-13T14:01:42  <BlueMatt> cfields: hmm, whats the status of #7522?
1702017-04-13T14:01:44  <gribble> https://github.com/bitcoin/bitcoin/issues/7522 | Bugfix: Only use git for build info if the repository is actually the right one by luke-jr · Pull Request #7522 · bitcoin/bitcoin · GitHub
1712017-04-13T14:03:17  <BlueMatt> luke-jr: are you going to rebase #7289?
1722017-04-13T14:03:19  <gribble> https://github.com/bitcoin/bitcoin/issues/7289 | [WIP] Make arguments reconfigurable at runtime via RPC by luke-jr · Pull Request #7289 · bitcoin/bitcoin · GitHub
1732017-04-13T14:06:10  *** goksinen has joined #bitcoin-core-dev
1742017-04-13T14:08:56  <bitcoin-git> [bitcoin] laanwj closed pull request #7148: [NO MERGE] Travis: Run nightly test suite (master...travis/nightly) https://github.com/bitcoin/bitcoin/pull/7148
1752017-04-13T14:12:27  *** jtimon has quit IRC
1762017-04-13T14:15:04  <wumpus> I agree it's a bit strange but I can't be bothered to change it, it's not as if incidents ever get reported to it
1772017-04-13T14:15:19  *** Samdney has joined #bitcoin-core-dev
1782017-04-13T14:15:55  <wumpus> eh, wrong key
1792017-04-13T14:16:17  <BlueMatt> wumpus: you have a key which types whole sentences? wow!
1802017-04-13T14:16:20  <BlueMatt> :p
1812017-04-13T14:17:26  *** dodomojo has joined #bitcoin-core-dev
1822017-04-13T14:17:45  *** n1ce has joined #bitcoin-core-dev
1832017-04-13T14:18:18  <wumpus> yes this smart-keyboard has analyzed all of the text I've entered on it, put it into a  markov chain, and now generated it's own text with just one keypress :p
1842017-04-13T14:19:50  *** e4xit has joined #bitcoin-core-dev
1852017-04-13T14:20:45  <BlueMatt> wumpus: you jest, but thats what fucking mobile phones do :(
1862017-04-13T14:21:56  <jnewbery> and your markov chain predicts that your most common response is "I agree it's a bit strange but I can't be bothered to change it". Seems pretty accurate :)
1872017-04-13T14:21:57  <wumpus> ah yes that's always the first thing I disable
1882017-04-13T14:22:08  *** dodomojo has quit IRC
1892017-04-13T14:24:31  <wumpus> jnewbery: yep, the keyboard can almost replace me already :-)
1902017-04-13T14:27:14  <michagogo> Yeah, the keyboard auto correct is the best app that I can use on my iPhone and my phone is a very quiet app and the fact is that it doesn't have a plan to use Facebook to access the web for the past couple weeks
1912017-04-13T14:28:02  <michagogo> (I typed the first 4 words of that and selected the rest from the 3 suggestions)
1922017-04-13T14:32:37  <sipa> wumpus: it's annoying to create PRs against the bitcoin core leveldb repository
1932017-04-13T14:32:56  <sipa> because it's marked as 'forked from' the upstream google repo (which didn't exist at the time ours was created)
1942017-04-13T14:33:00  <sipa> *isn't marked
1952017-04-13T14:33:11  <sipa> seems the only way to fix that is to delete it and recreate it
1962017-04-13T14:33:31  <wumpus> that'll lose all the current issues and PRs though
1972017-04-13T14:33:59  <sipa> true
1982017-04-13T14:34:06  <sipa> maybe we can contact support to just fix it for us?
1992017-04-13T14:34:18  <wumpus> yes I think they can reparent repositories
2002017-04-13T14:36:31  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/70f6f56e9dde...cf8a8b1028d6
2012017-04-13T14:36:31  <bitcoin-git> bitcoin/master c851be4 Cory Fields: net: define NodeId as an int64_t...
2022017-04-13T14:36:32  <bitcoin-git> bitcoin/master cf8a8b1 Wladimir J. van der Laan: Merge #10176: net: gracefully handle NodeId wrapping...
2032017-04-13T14:36:57  *** talmai has joined #bitcoin-core-dev
2042017-04-13T14:36:57  <bitcoin-git> [bitcoin] laanwj closed pull request #10176: net: gracefully handle NodeId wrapping (master...nodeid-no-wrap) https://github.com/bitcoin/bitcoin/pull/10176
2052017-04-13T14:37:14  <wumpus> are you going to contact support or should I?
2062017-04-13T14:37:41  <sipa> i can
2072017-04-13T14:41:34  *** goksinen has quit IRC
2082017-04-13T14:43:06  *** goksinen has joined #bitcoin-core-dev
2092017-04-13T14:52:17  *** talmai has quit IRC
2102017-04-13T15:03:54  *** BCBot_ has joined #bitcoin-core-dev
2112017-04-13T15:04:27  *** Taek42 has joined #bitcoin-core-dev
2122017-04-13T15:04:56  *** berndj-blackout has joined #bitcoin-core-dev
2132017-04-13T15:05:02  *** Samdney has quit IRC
2142017-04-13T15:05:44  *** crudel has quit IRC
2152017-04-13T15:06:23  *** harding_ has joined #bitcoin-core-dev
2162017-04-13T15:07:14  *** cfields_ has joined #bitcoin-core-dev
2172017-04-13T15:07:54  *** mariorz_ has joined #bitcoin-core-dev
2182017-04-13T15:08:16  *** warren_ has joined #bitcoin-core-dev
2192017-04-13T15:08:33  *** Pat_Boy has joined #bitcoin-core-dev
2202017-04-13T15:08:35  *** jnewbery has quit IRC
2212017-04-13T15:09:39  *** ryan-c- has joined #bitcoin-core-dev
2222017-04-13T15:09:53  *** musalbas- has joined #bitcoin-core-dev
2232017-04-13T15:09:56  *** NielsvG` has joined #bitcoin-core-dev
2242017-04-13T15:10:49  *** wasi has quit IRC
2252017-04-13T15:10:49  *** arubi has quit IRC
2262017-04-13T15:10:49  *** afk11 has quit IRC
2272017-04-13T15:10:50  *** cfields has quit IRC
2282017-04-13T15:10:51  *** mariorz has quit IRC
2292017-04-13T15:10:52  *** harding has quit IRC
2302017-04-13T15:10:52  *** NielsvG has quit IRC
2312017-04-13T15:10:52  *** musalbas has quit IRC
2322017-04-13T15:10:52  *** luke-jr has quit IRC
2332017-04-13T15:10:53  *** tunafizz has quit IRC
2342017-04-13T15:10:53  *** ryan-c has quit IRC
2352017-04-13T15:10:54  *** BCBot has quit IRC
2362017-04-13T15:10:54  *** Soligor has quit IRC
2372017-04-13T15:10:54  *** berndj has quit IRC
2382017-04-13T15:10:56  *** murr4y has quit IRC
2392017-04-13T15:10:56  *** PatBoy has quit IRC
2402017-04-13T15:10:58  *** nsh has quit IRC
2412017-04-13T15:10:58  *** ensign_ has quit IRC
2422017-04-13T15:10:58  *** warren has quit IRC
2432017-04-13T15:10:59  *** Taek has quit IRC
2442017-04-13T15:11:00  *** berndj-blackout is now known as berndj
2452017-04-13T15:11:00  *** Pat_Boy is now known as PatBoy
2462017-04-13T15:11:01  *** musalbas- is now known as musalbas
2472017-04-13T15:11:40  *** luke-jr has joined #bitcoin-core-dev
2482017-04-13T15:11:43  *** tunafizz has joined #bitcoin-core-dev
2492017-04-13T15:11:46  *** murr4y has joined #bitcoin-core-dev
2502017-04-13T15:12:52  <sdaftuar> wumpus: i just noticed #9665 has been sitting around for a couple of months, it has a few ACKs and I think could be merged
2512017-04-13T15:12:53  <gribble> https://github.com/bitcoin/bitcoin/issues/9665 | Use cached [compact] blocks to respond to getdata messages by TheBlueMatt · Pull Request #9665 · bitcoin/bitcoin · GitHub
2522017-04-13T15:15:21  *** nsh has joined #bitcoin-core-dev
2532017-04-13T15:15:51  *** ensign has joined #bitcoin-core-dev
2542017-04-13T15:16:17  *** mariorz_ is now known as mariorz
2552017-04-13T15:18:44  <wumpus> sdaftuar: thanks
2562017-04-13T15:22:48  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/cf8a8b1028d6...eab00d96dfe9
2572017-04-13T15:22:49  <bitcoin-git> bitcoin/master efc135f Matt Corallo: Use cached [compact] blocks to respond to getdata messages
2582017-04-13T15:22:49  <bitcoin-git> bitcoin/master c47f5b7 Matt Corallo: Cache witness-enabled state with recent-compact-block-cache
2592017-04-13T15:22:50  <bitcoin-git> bitcoin/master b49ad44 Matt Corallo: Add comment about cs_most_recent_block coverage
2602017-04-13T15:23:04  <bitcoin-git> [bitcoin] laanwj closed pull request #9665: Use cached [compact] blocks to respond to getdata messages (master...2017-02-processgetdata-cache) https://github.com/bitcoin/bitcoin/pull/9665
2612017-04-13T15:24:26  * BlueMatt notes something similar for #9942 and #9480
2622017-04-13T15:24:28  <gribble> https://github.com/bitcoin/bitcoin/issues/9942 | Refactor CBlockPolicyEstimator by morcos · Pull Request #9942 · bitcoin/bitcoin · GitHub
2632017-04-13T15:24:29  <gribble> https://github.com/bitcoin/bitcoin/issues/9480 | De-duplicate SignatureCacheHasher by JeremyRubin · Pull Request #9480 · bitcoin/bitcoin · GitHub
2642017-04-13T15:25:09  *** Soligor has joined #bitcoin-core-dev
2652017-04-13T15:30:23  *** aantonop has joined #bitcoin-core-dev
2662017-04-13T15:33:49  *** afk11 has joined #bitcoin-core-dev
2672017-04-13T15:33:59  *** arubi has joined #bitcoin-core-dev
2682017-04-13T15:34:42  *** Samdney has joined #bitcoin-core-dev
2692017-04-13T15:41:05  *** talmai has joined #bitcoin-core-dev
2702017-04-13T15:43:44  *** goksinen_ has joined #bitcoin-core-dev
2712017-04-13T15:44:15  *** goksinen has quit IRC
2722017-04-13T15:44:22  *** jnewbery has joined #bitcoin-core-dev
2732017-04-13T15:48:03  *** goksinen_ has quit IRC
2742017-04-13T15:50:46  *** afk11 has quit IRC
2752017-04-13T15:50:46  *** arubi has quit IRC
2762017-04-13T15:54:07  *** laurentmt has joined #bitcoin-core-dev
2772017-04-13T15:54:34  *** laurentmt has quit IRC
2782017-04-13T15:55:20  *** abpa has joined #bitcoin-core-dev
2792017-04-13T16:00:51  *** goksinen has joined #bitcoin-core-dev
2802017-04-13T16:08:13  <sdaftuar> sipa: i was trying to review #9743, and i'm confused by the lockstack cleanup commit.  the boost documentation i'm reading suggests that by default, delete should be called already?
2812017-04-13T16:08:15  <gribble> https://github.com/bitcoin/bitcoin/issues/9743 | Fix several potential issues found by sanitizers by sipa · Pull Request #9743 · bitcoin/bitcoin · GitHub
2822017-04-13T16:10:52  <sipa> sdaftuar: hmm
2832017-04-13T16:11:18  *** talmai has quit IRC
2842017-04-13T16:12:21  <sdaftuar> i'm looking at this: http://www.boost.org/doc/libs/1_63_0/doc/html/thread/thread_local_storage.html
2852017-04-13T16:12:34  <sdaftuar> there is this comment: "Note: on some platforms, cleanup of thread-specific data is not performed for threads created with the platform's native API. On those platforms such cleanup is only done for threads that are started with boost::thread unless boost::on_thread_exit() is called manually from that thread.
2862017-04-13T16:13:20  <sipa> sdaftuar: but that would mean that the custom cleanup function is also not called?
2872017-04-13T16:13:29  <sdaftuar> sipa: that was my guess, but i wasn't sure!
2882017-04-13T16:14:04  <sipa> i seem to recall that fixed things
2892017-04-13T16:14:19  *** aantonop has quit IRC
2902017-04-13T16:18:59  *** belcher has quit IRC
2912017-04-13T16:28:54  *** d_t has joined #bitcoin-core-dev
2922017-04-13T16:28:54  *** goksinen has quit IRC
2932017-04-13T16:29:14  *** mol has joined #bitcoin-core-dev
2942017-04-13T16:29:37  *** RubenSomsen has quit IRC
2952017-04-13T16:29:40  *** Victor_sueca has joined #bitcoin-core-dev
2962017-04-13T16:30:00  *** laurentmt has joined #bitcoin-core-dev
2972017-04-13T16:31:38  *** Taek has joined #bitcoin-core-dev
2982017-04-13T16:32:08  *** Taek42 has quit IRC
2992017-04-13T16:32:08  *** Naphex has quit IRC
3002017-04-13T16:32:19  *** Naphex has joined #bitcoin-core-dev
3012017-04-13T16:32:20  *** molz_ has quit IRC
3022017-04-13T16:32:30  *** Alina-malina has quit IRC
3032017-04-13T16:32:36  *** Victorsueca has quit IRC
3042017-04-13T16:32:57  *** Olen2 has joined #bitcoin-core-dev
3052017-04-13T16:33:19  *** Alina-malina has joined #bitcoin-core-dev
3062017-04-13T16:33:34  *** RubenSomsen has joined #bitcoin-core-dev
3072017-04-13T16:36:04  *** Alina-malina has quit IRC
3082017-04-13T16:36:04  *** Alina-malina has joined #bitcoin-core-dev
3092017-04-13T16:37:39  *** Olen2 has quit IRC
3102017-04-13T16:37:48  *** goksinen has joined #bitcoin-core-dev
3112017-04-13T16:38:29  *** aantonop has joined #bitcoin-core-dev
3122017-04-13T16:41:19  *** d_t has quit IRC
3132017-04-13T16:41:50  *** Cortney has joined #bitcoin-core-dev
3142017-04-13T16:42:52  *** belcher has joined #bitcoin-core-dev
3152017-04-13T16:43:15  *** belcher is now known as Guest66310
3162017-04-13T16:52:02  *** Guest66310 has quit IRC
3172017-04-13T16:52:23  *** belcher_ has joined #bitcoin-core-dev
3182017-04-13T16:52:46  *** belcher_ is now known as Guest38408
3192017-04-13T16:54:37  *** belcher has joined #bitcoin-core-dev
3202017-04-13T16:54:45  *** belcher has quit IRC
3212017-04-13T16:57:15  *** jtimon has joined #bitcoin-core-dev
3222017-04-13T17:13:38  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/eab00d96dfe9...b7365f0545b1
3232017-04-13T17:13:38  <bitcoin-git> bitcoin/master f9c8807 Jeremy Rubin: Deduplicate SignatureCacheHasher...
3242017-04-13T17:13:38  <bitcoin-git> bitcoin/master b7365f0 Pieter Wuille: Merge #9480: De-duplicate SignatureCacheHasher...
3252017-04-13T17:13:52  <bitcoin-git> [bitcoin] sipa closed pull request #9480: De-duplicate SignatureCacheHasher (master...refactor-signaturecachehasher-visibility) https://github.com/bitcoin/bitcoin/pull/9480
3262017-04-13T17:14:54  *** btcdrak has quit IRC
3272017-04-13T17:15:32  *** Cheeseo has quit IRC
3282017-04-13T17:23:31  *** afk11 has joined #bitcoin-core-dev
3292017-04-13T17:24:32  *** arubi has joined #bitcoin-core-dev
3302017-04-13T17:33:40  <cfields_> sipa: for leveldb merge, whenever it's needed: https://github.com/theuni/bitcoin/commit/2cb7dda13884e44105f33c16e7e2c1a9aed46295
3312017-04-13T17:35:47  <cfields_> BlueMatt: hmm, i thought 7522 was merged a long time ago. Having a look.
3322017-04-13T17:40:13  *** talmai has joined #bitcoin-core-dev
3332017-04-13T17:40:52  *** jnewbery has quit IRC
3342017-04-13T17:41:09  *** jnewbery has joined #bitcoin-core-dev
3352017-04-13T17:47:56  *** CubicEarth has joined #bitcoin-core-dev
3362017-04-13T17:50:23  *** e4xit has quit IRC
3372017-04-13T17:53:57  *** btcdrak has joined #bitcoin-core-dev
3382017-04-13T17:57:17  *** RubenSomsen has quit IRC
3392017-04-13T17:58:42  *** belcher has joined #bitcoin-core-dev
3402017-04-13T18:01:08  *** aantonop has quit IRC
3412017-04-13T18:03:07  *** d_t has joined #bitcoin-core-dev
3422017-04-13T18:04:52  *** aantonop has joined #bitcoin-core-dev
3432017-04-13T18:06:44  <luke-jr> hm, thought I was late; am I early?
3442017-04-13T18:07:32  <gmaxwell> you are early
3452017-04-13T18:07:45  <luke-jr> cool
3462017-04-13T18:08:53  *** e4xit has joined #bitcoin-core-dev
3472017-04-13T18:12:08  <aantonop> gmaxwell: apologies for the trolling by an "aantonop" imposter the other day. I hadn't turned on Nickserv enforcement. It's on now.
3482017-04-13T18:13:24  <gmaxwell> aantonop: oh no problem, people should have just ignored him. :) trolls show up all the time.
3492017-04-13T18:15:34  *** limpkin has quit IRC
3502017-04-13T18:16:09  *** limpkin has joined #bitcoin-core-dev
3512017-04-13T18:19:57  *** talmai has quit IRC
3522017-04-13T18:25:35  *** aantonop has quit IRC
3532017-04-13T18:30:30  *** spudowiar has joined #bitcoin-core-dev
3542017-04-13T18:31:04  <spudowiar> Is there a good way to get a transaction input and find the BIP32 derivation path?
3552017-04-13T18:31:20  <spudowiar> I don't think the keystore stores BIP32 derivation information
3562017-04-13T18:33:00  <luke-jr> pretty sure it does..
3572017-04-13T18:33:45  <spudowiar> luke-jr: Well, I was looking in src/keystore.h but it seems I can only get a CKey or CPubKey out which I don't think stores derivation information
3582017-04-13T18:34:10  *** Ylbam has quit IRC
3592017-04-13T18:37:30  <sipa> CKeyMetaData or something stores ot
3602017-04-13T18:37:32  <sipa> *it
3612017-04-13T18:39:37  *** goksinen has quit IRC
3622017-04-13T18:39:58  <spudowiar> sipa: How do I get one of those from a public key?
3632017-04-13T18:45:15  *** goksinen has joined #bitcoin-core-dev
3642017-04-13T19:00:02  <wumpus> meeting time?
3652017-04-13T19:00:11  <jonasschnelli> Yes. Hi all.
3662017-04-13T19:00:17  <wumpus> #startmeeting
3672017-04-13T19:00:17  <lightningbot> Meeting started Thu Apr 13 19:00:17 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3682017-04-13T19:00:17  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3692017-04-13T19:00:25  <morcos> roger
3702017-04-13T19:00:28  <sdaftuar> hello
3712017-04-13T19:00:30  <CodeShark> hi
3722017-04-13T19:00:32  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure blue
3732017-04-13T19:00:33  <wumpus> matt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
3742017-04-13T19:00:38  <kanzure> hi.
3752017-04-13T19:00:39  <wumpus> hello
3762017-04-13T19:00:45  <cfields_> hi
3772017-04-13T19:00:50  <instagibbs> hi
3782017-04-13T19:00:55  <phantomcircuit> hi
3792017-04-13T19:00:55  <wumpus> topics?
3802017-04-13T19:01:02  <gmaxwell> Hi!
3812017-04-13T19:01:13  <wumpus> #topic 0.14.1
3822017-04-13T19:01:20  <wumpus> anyone had report of bugs with the rc1?
3832017-04-13T19:01:28  <cfields_> topic suggestion (after 0.14.1): scripted-diffs
3842017-04-13T19:01:32  <gmaxwell> Push the button?
3852017-04-13T19:01:47  <gmaxwell> wumpus: you know that the bug reports only come after releasing it. :P
3862017-04-13T19:01:55  <petertodd> hi
3872017-04-13T19:02:12  <wumpus> gmaxwell: the serious ones, yes :p
3882017-04-13T19:02:25  * cfields_ scrambles to backport 10176
3892017-04-13T19:02:42  <wumpus> but apparently no one heard anything, so time to tag -final
3902017-04-13T19:03:26  <cfields_> wumpus: wait for ^^ ? doing now.
3912017-04-13T19:04:36  <wumpus> would be nice but I think that's not a regression since 0.14.0, so I'm not sure it warrants another rc
3922017-04-13T19:05:15  <gmaxwell> can talk about post meeting, certantly nothing but that is in the air.
3932017-04-13T19:05:40  <cfields_> ok
3942017-04-13T19:05:40  <wumpus> if you think it's really important to do we can do another rc, no problem
3952017-04-13T19:06:26  <gmaxwell> I really don't want to delay 0.14.1 further.
3962017-04-13T19:06:36  <cfields_> wumpus: it was more of a since-we're-releasing-anyway kind of thing
3972017-04-13T19:06:47  <wumpus> I'd prefer not to either; we should fix the wrapping, but could just was well be included for 0.14.2
3982017-04-13T19:07:11  <wumpus> I agree it's something that should be backported to the 0.14 branch
3992017-04-13T19:07:25  <morcos> no opinion either way here
4002017-04-13T19:07:55  <wumpus> ok
4012017-04-13T19:07:58  <BlueMatt> wumpus: I think we should do it in 0.14
4022017-04-13T19:08:00  <BlueMatt> .1
4032017-04-13T19:08:10  <BlueMatt> because its free, we're already doing 0.14.1 and delaying 1 week isnt gonna kill us
4042017-04-13T19:08:42  *** BlueMatt_ has joined #bitcoin-core-dev
4052017-04-13T19:08:43  <luke-jr> cfields_: new fixes = new rc required
4062017-04-13T19:08:49  <luke-jr> so not worth it in that scenario
4072017-04-13T19:09:26  <BlueMatt_> But delaying 1 week isn't too bad
4082017-04-13T19:09:40  <BlueMatt> wait, who is BlueMatt_ ?
4092017-04-13T19:09:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4102017-04-13T19:10:04  * wumpus confused
4112017-04-13T19:10:19  *** Dizzle has joined #bitcoin-core-dev
4122017-04-13T19:10:23  * BlueMatt_ confused
4132017-04-13T19:10:24  * BlueMatt has no idea who BlueMatt_ is
4142017-04-13T19:10:31  <instagibbs> :/
4152017-04-13T19:10:31  * BlueMatt_ has no idea who BlueMatt is
4162017-04-13T19:10:47  <kanzure> different timeline, carry on.
4172017-04-13T19:10:52  <luke-jr> whois says it's Matt Corallo
4182017-04-13T19:11:03  <jcorgan> digital ocean ip
4192017-04-13T19:11:12  <BlueMatt> not me
4202017-04-13T19:11:19  * BlueMatt has no digitalocean-lon vpses
4212017-04-13T19:11:42  <gmaxwell> wumpus: shoot the T1000 (BlueMatt_) and lets move on.
4222017-04-13T19:12:01  <sipa> BlueMatt_: this statement is false
4232017-04-13T19:12:09  *** ChanServ sets mode: +o wumpus
4242017-04-13T19:12:12  <spudowiar> gmaxwell: I think that's the fake aantonop IP
4252017-04-13T19:12:27  <luke-jr> sipa: :D
4262017-04-13T19:12:37  <spudowiar> 2017-04-11 21:37:35 -- Mode #bitcoin [+b *!*@178.62.68.75] by gmaxwell
4272017-04-13T19:12:41  *** wumpus sets mode: +b *!*@178.62.68.7
4282017-04-13T19:12:45  <gmaxwell> We've got lots more to discuss.
4292017-04-13T19:12:50  <BlueMatt> yes, lets move on
4302017-04-13T19:12:55  *** BlueMatt_ was kicked by wumpus (Kindergarten is elsewhere!)
4312017-04-13T19:13:04  <wumpus> so have we decided anything?
4322017-04-13T19:13:11  <sipa> 0.14.1 yay
4332017-04-13T19:13:56  <wumpus> #topic scripted-diffs
4342017-04-13T19:14:15  <cfields_> yes, let's finish discussing after the meeting
4352017-04-13T19:14:45  <cfields_> ok, for reference: #10189
4362017-04-13T19:14:46  <gribble> https://github.com/bitcoin/bitcoin/issues/10189 | devtools/net: add a verifier for scriptable changes. Use it to make CNode::id private. by theuni · Pull Request #10189 · bitcoin/bitcoin · GitHub
4372017-04-13T19:14:46  <luke-jr> mv meeting/* after-meeting/
4382017-04-13T19:15:01  <wumpus> haven't had a time to look at that one yet
4392017-04-13T19:15:29  <cfields_> the idea is for changes that are basically just search/replace, to allow a short script to be placed in the commit message, and verified by Travis
4402017-04-13T19:15:48  <cfields_> if they don't transform the old commit to the new one exactly, travis will reject
4412017-04-13T19:15:58  <cfields_> the aim is to make those kinds of changes easier to review
4422017-04-13T19:16:03  <BlueMatt> is ther emuch to discuss? I think its a good idea
4432017-04-13T19:16:04  *** stoner19 has joined #bitcoin-core-dev
4442017-04-13T19:16:05  *** tw2006 has joined #bitcoin-core-dev
4452017-04-13T19:16:17  <cfields_> example: https://github.com/bitcoin/bitcoin/pull/10189/commits/d04198309e7e9b21de1604cc4321148b37a46347
4462017-04-13T19:16:20  <luke-jr> IMO we shouldn't trust Travis
4472017-04-13T19:16:33  <gmaxwell> I'm fine with it so long as we don't expect commiters to be running it.  I think someone should write a list of examples, because when I've made mass programatic changes I haven't done it in ways that would look too tidy in a commit message.
4482017-04-13T19:16:34  <wumpus> would that execute arbitrary scripts in commit messages?
4492017-04-13T19:16:36  <luke-jr> which is basicaly what you're suggesting)
4502017-04-13T19:16:37  <cfields_> BlueMatt: well, you brought up a good point about the safety of random scripts
4512017-04-13T19:16:47  <wumpus> seems kind of dangerous, I certainly wouldn't want to run that locally
4522017-04-13T19:16:50  <cfields_> so i thought it might be worth discussing possibly constraining. Say to sed or so.
4532017-04-13T19:17:00  <BlueMatt> gmaxwell: there are already two examplesa
4542017-04-13T19:17:03  <wumpus> I'm really careful what scripts I run, and wouldn't want anything to be run automatically
4552017-04-13T19:17:13  <BlueMatt> and, yes, agree, jtimon suggested that they only be run if there is a scripted prefix in the commit's title
4562017-04-13T19:17:15  <spudowiar> What sort of damage can be done with, say, sed or awk?
4572017-04-13T19:17:16  <BlueMatt> to make it much more obvious
4582017-04-13T19:17:25  *** tw2006 has quit IRC
4592017-04-13T19:17:28  <petertodd> wumpus: granted, if you ever compile bitcoin you're running stuff within the repo anyway
4602017-04-13T19:17:28  <gmaxwell> spudowiar: arbritary damage.
4612017-04-13T19:17:31  <spudowiar> I don't think you can do much with sed, not too sure about awk
4622017-04-13T19:17:42  <spudowiar> gmaxwell: I mean dangerous code execution
4632017-04-13T19:17:47  <cfields_> wumpus: sure, agreed. Travis can run them, and they can ofc be run manually as well.
4642017-04-13T19:17:51  <sipa> try applying sed to /etc/init.d files
4652017-04-13T19:17:57  <BlueMatt> see-also #10193
4662017-04-13T19:17:57  *** tw2006 has joined #bitcoin-core-dev
4672017-04-13T19:17:58  <gribble> https://github.com/bitcoin/bitcoin/issues/10193 | scripted-diff: Remove #include foreach.hpp> by jtimon · Pull Request #10193 · bitcoin bitcoin · GitHub
4682017-04-13T19:18:01  <BlueMatt> (which is an example)
4692017-04-13T19:18:09  <jcorgan> maybe there should only be a predefined set of opcodes in the script that can run, with a stack...oh wait
4702017-04-13T19:18:14  <wumpus> just make it create a ~/.bashrc, runs next time
4712017-04-13T19:18:22  <gmaxwell> in any case, if it's a travis mostly thing I think thats ducky. I would attempt to use it.
4722017-04-13T19:18:27  <wumpus> I'd really prefer not to do this
4732017-04-13T19:18:54  <luke-jr> I don't see the value in a Travis-"mostly" thing.
4742017-04-13T19:18:55  <spudowiar> What are the benefits?
4752017-04-13T19:18:56  <gmaxwell> I guess the reason to just not commit the script is that they're one time things?
4762017-04-13T19:18:57  <cfields_> gmaxwell: that was my intention, yes.
4772017-04-13T19:19:05  <luke-jr> it gives a false sense of review
4782017-04-13T19:19:09  <wumpus> if there's a script then reviewers can manually verify it too, after reviewing the script
4792017-04-13T19:19:13  <BlueMatt> gmaxwell: yes, if they're one-time things its annoying to commit them, also annoying to lose them
4802017-04-13T19:19:35  <sipa> when would these scripts be ru
4812017-04-13T19:19:37  <sipa> n
4822017-04-13T19:20:02  <cfields_> yes, i got the idea from bac5c9cf643e9333479ac667426d0b70f8f3aa7f
4832017-04-13T19:20:05  <luke-jr> I wouldn't mind including the scripts in non-first-line commit msg, and having a dev tool to run them, but IMO better if Travis *doesn't* do it
4842017-04-13T19:20:17  <gmaxwell> luke-jr: but reviewers can test it. After reviewing the script. The challenge there is just that you normally don't critically review commit messages in that way. but it's kind of perfect-- in that its one time information about the change.
4852017-04-13T19:20:23  <cfields_> https://github.com/bitcoin/bitcoin/commit/bac5c9cf643e9333479ac667426d0b70f8f3aa7f
4862017-04-13T19:20:55  <gmaxwell> luke-jr: the purpose of travis doing it is for feedback that you've formated it right and it runs on computers other than yours. Not as a review step.
4872017-04-13T19:20:58  <cfields_> if we're going to include a transform in the message like that, I figured we may as well standardize it
4882017-04-13T19:21:00  <luke-jr> gmaxwell: as long as reviewers do test it, and don't trust Travis
4892017-04-13T19:21:02  <wumpus> cfields_: the idea of that was to give reviewers a way to verify it, as well as make it easy for myself to repeat the work if it needs rebase
4902017-04-13T19:21:03  <spudowiar> You could create format like `*.cpp *.h | s/boost::filesystem/fs/g`
4912017-04-13T19:22:25  <sipa> spudowiar: little bobby tables will haunt you
4922017-04-13T19:23:01  <luke-jr> lol
4932017-04-13T19:23:02  <petertodd> gmaxwell: note how this is rather like how a merkle sum tree works... the script is a function to transform input to output, and both input and final output are committed via the git commit object
4942017-04-13T19:23:14  <cfields_> ok, put a different way, then: if it could be done so that it worked on nothing but a dummy git index, with no access to the filesystem, would that be more acceptable?
4952017-04-13T19:23:37  <wumpus> cfields_: if a transformation of the files could be perfectly sandboxed , I'd be all for it, but I'm kind of afraid of anything that will automatically execute scripts from commit messages, especially as most people review the code changes but not so much the messages :)
4962017-04-13T19:23:46  <petertodd> cfields_: I mean, with travis the compilation process can do anything anyway, so I don't see how this is a security risk on top of anything else
4972017-04-13T19:23:53  <gmaxwell> I don't know that sandboxing this is worth the effort. If you want to do that, knock yourself out, I guess?
4982017-04-13T19:23:53  <petertodd> cfields_: that's true for your local dev setup too
4992017-04-13T19:24:02  <wumpus> I don't think it's worth the effort, no
5002017-04-13T19:24:18  <BlueMatt> wumpus: that was my concern, hence why I like jtimon's suggestion of only doing it if, eg, the commit title starts with "AUTO-SCRIPT: "
5012017-04-13T19:24:19  <BlueMatt> or something
5022017-04-13T19:24:23  <gmaxwell> petertodd: the only concern I have wrt security is that there is a new thing you need to review before running things. Not just the git diff but the commit messages.
5032017-04-13T19:24:24  <BlueMatt> then its obvious from the first line of the commit
5042017-04-13T19:24:25  <cfields_> petertodd: i agree. The concern here (I guess) is that we'd get a malicious script committed, then someone would run it locally.
5052017-04-13T19:24:26  <BlueMatt> and you will see it
5062017-04-13T19:24:57  <petertodd> cfields_: but that's already a problem anyway: I can commit a malicious commit that adds rm -rf / to the makefile
5072017-04-13T19:25:16  <gmaxwell> cfields_: I dunno about your workflow, but I could be tricked by this, because I'll pull and git diff <where I was before>  which won't show me the commit message(s).
5082017-04-13T19:25:32  <gmaxwell> otherwise I'd argue there is no change.
5092017-04-13T19:25:45  <cfields_> gmaxwell: but it wouldn't touch anything in that case. You'd have to actively run it.
5102017-04-13T19:25:51  <wumpus> petertodd: you can, but changes to the makefile would be apparent to me at least
5112017-04-13T19:25:51  <petertodd> gmaxwell: so long as devs never have git hooks that run this automatically I think we're covered
5122017-04-13T19:26:01  <spudowiar> Why not have a script that manually does these checks, prints out each commit message beginning with "AUTO-SCRIPT: " and the commands it would run and asks if you want to run them?
5132017-04-13T19:26:08  <petertodd> wumpus: right, but see my reply to gmaxwell above
5142017-04-13T19:26:08  <gmaxwell> petertodd: yea, I'm not too concerned.
5152017-04-13T19:26:11  <wumpus> yes, as long as it's not executed automatically outside of travis it's fine
5162017-04-13T19:26:21  <wumpus> I don't care what is done in travis, that is already somebody else's sandbox
5172017-04-13T19:26:24  <cfields_> yes, that's the case as-is.
5182017-04-13T19:26:26  <petertodd> wumpus: +1
5192017-04-13T19:26:28  <gmaxwell> oh actually too spudowiar's suggestion is good  unless run with --force the script could ask for confirmation.
5202017-04-13T19:26:30  <cfields_> nothing is touched locally.
5212017-04-13T19:26:44  *** goksinen has quit IRC
5222017-04-13T19:26:50  <wumpus> my point was just that I just don't want e.g. github_merge.py to execute it automatically
5232017-04-13T19:26:54  <wumpus> great
5242017-04-13T19:27:08  <petertodd> wumpus: yup, that'd be a bit crazy :)
5252017-04-13T19:27:09  <cfields_> wait, please back up, I'm not sure if there's a communication breakdown here.
5262017-04-13T19:27:24  *** mol has quit IRC
5272017-04-13T19:27:25  *** Samdney has quit IRC
5282017-04-13T19:27:47  * sipa makes backup
5292017-04-13T19:27:49  <cfields_> as-is, this is travis-only. Nothing runs automatically anywhere but there.
5302017-04-13T19:27:55  <wumpus> cfields_: as said I haven't seen the actual PR, just rumors from this channel
5312017-04-13T19:28:10  <spudowiar> Well, Travis can run it with --force, github_merge.py can run it without --force?
5322017-04-13T19:28:14  <wumpus> yes makes sense to me then cfields_
5332017-04-13T19:28:25  <spudowiar> Without --force, no actual commands are run
5342017-04-13T19:28:29  <spudowiar> Unless you interactively say so
5352017-04-13T19:28:34  <gmaxwell> spudowiar: no need to make merge run it at all. just an extra review step available.
5362017-04-13T19:28:35  <cfields_> spudowiar: there's nothing to run "it".
5372017-04-13T19:28:43  <wumpus> no, github_merge.py won't run it at all, that is a merge script and shouldn't do anything else
5382017-04-13T19:29:02  <wumpus> (I run that on the machine that has the gpg key, so I'm paranoid about it)
5392017-04-13T19:29:03  *** moli_ has joined #bitcoin-core-dev
5402017-04-13T19:29:10  <gmaxwell> But I do think it would be nice if when you manually run that review step it shows you what it's going to run.. to avoid my workflow issue example.
5412017-04-13T19:29:12  <spudowiar> cfields_: I'm talking about a hypothetical script
5422017-04-13T19:29:18  <spudowiar> wumpus: Buy a PGP smartcard :)
5432017-04-13T19:29:47  <petertodd> spudowiar: adversary still can cause the PGP smartcard to sign something you didn't aprove
5442017-04-13T19:29:50  <wumpus> ok. seems a communication breakdown here.
5452017-04-13T19:29:58  <wumpus> let's just review the PR, and talk about it again next week
5462017-04-13T19:30:01  <gmaxwell> okay
5472017-04-13T19:30:03  <cfields_> heh, yes please :)
5482017-04-13T19:30:12  <sdaftuar> +1!
5492017-04-13T19:30:17  <wumpus> #action review #10193
5502017-04-13T19:30:20  <gribble> https://github.com/bitcoin/bitcoin/issues/10193 | scripted-diff: Remove #include foreach.hpp> by jtimon · Pull Request #10193 · bitcoin bitcoin · GitHub
5512017-04-13T19:30:20  <morcos> good thing our trolling coordination doesn't suffer from these communication problems
5522017-04-13T19:30:23  <wumpus> other topics?
5532017-04-13T19:31:11  <wumpus> #action review #10189
5542017-04-13T19:31:12  <gribble> https://github.com/bitcoin/bitcoin/issues/10189 | devtools/net: add a verifier for scriptable changes. Use it to make CNode::id private. by theuni · Pull Request #10189 · bitcoin/bitcoin · GitHub
5552017-04-13T19:31:19  <sdaftuar> topic suggestion: goals for 0.15
5562017-04-13T19:31:40  <cfields_> good one.
5572017-04-13T19:31:42  <BlueMatt> ok, so ryanofsky wanted to talk about multi-process, too, i think
5582017-04-13T19:31:48  <BlueMatt> and, ofc, pr review targets for the week
5592017-04-13T19:31:49  <BlueMatt> :)
5602017-04-13T19:31:56  <wumpus> #topic goals for 0.15
5612017-04-13T19:32:27  <BlueMatt> sdaftuar: my interpretation of "goals for 0.15" is "everyone has their own goals, and should mention the PRs they want reviewed to further their goals as review priorities, and we should all help them :)"
5622017-04-13T19:32:53  <gmaxwell> Per-txo dbcache and non-atomic flushing please...
5632017-04-13T19:32:58  <wumpus> agree with BlueMatt, though people could state what their goals for 0.15 are
5642017-04-13T19:33:01  <jonasschnelli> My goals for 0.15 are: HD auto-restore, Qt feebumper and multiwallet
5652017-04-13T19:33:15  <spudowiar> Watch only HD wallets sound good for 0.15 :)
5662017-04-13T19:33:20  <gmaxwell> and multiwallet.
5672017-04-13T19:33:21  <jonasschnelli> Oh.. yes. That!
5682017-04-13T19:33:26  <sdaftuar> gmaxwell: agreed, also i think it would be good to get the new fee estimation in place
5692017-04-13T19:33:26  <jonasschnelli> (hd watch only)
5702017-04-13T19:33:40  <BlueMatt> multithreaded net_processing (and wallet) with CValidationInterface generating callbacks into it
5712017-04-13T19:33:54  <BlueMatt> ie disconnecting validation and everything else with CValidationInterface in betwene :)
5722017-04-13T19:34:02  <sipa> when is 0.15 feature freeze?
5732017-04-13T19:34:05  <wumpus> luke-jr: are you planning to update the multiwallet prepare pull according to review comments, or should I take it over?
5742017-04-13T19:34:07  <achow101> is replacing accounts with labels planned for 0.15?
5752017-04-13T19:34:13  <gmaxwell> sdaftuar: I was going to bring that up. I think that we really need a high level description of the algorithim that we could give to non-developers (e.g. academics) to review.  I don't know if that should hold the improvements but we need to get to that.
5762017-04-13T19:34:20  <wumpus> luke-jr: it's kind of blocking other things right now I think
5772017-04-13T19:34:32  <morcos> yes, re: fee estimation.. i understand its a giant pain in the ass to review...  and for little perceived gain.  but i do think its worth it, and merging it sooner rather than later is better in case there are any edge case improvements needed.
5782017-04-13T19:34:44  <luke-jr> wumpus: when I get home
5792017-04-13T19:34:45  <BlueMatt> I do NOT think its little perceived gain
5802017-04-13T19:34:50  <cfields_> my big goals are: finally move to libevent for connman, deterministic toolchain creator (so we can drop our reliance on ubuntu's toolchain)
5812017-04-13T19:34:58  <wumpus> #link Release schedule for 0.15.0 https://github.com/bitcoin/bitcoin/issues/9961
5822017-04-13T19:35:00  <sipa> cfields_: woooh!
5832017-04-13T19:35:05  *** dgenr8_ has joined #bitcoin-core-dev
5842017-04-13T19:35:06  <BlueMatt> morcos: one of the topics discussed at the wallet dev meetup thing was about how shit fee estimates across the ecosystem are
5852017-04-13T19:35:08  <wumpus> yes libevent please
5862017-04-13T19:35:09  <BlueMatt> and bitcoin core is a big part of that
5872017-04-13T19:35:10  <morcos> gmaxwell: heh... it's more art than science i think
5882017-04-13T19:35:14  <gmaxwell> jonasschnelli: I don't know about HD watch only, we have a lot of overhang in the HD change that isn't done yet. We really need to hammer out all these corner cases before we go adding more major new features in key management.
5892017-04-13T19:35:24  <wumpus> I'd also really like to get the UNIX p2p/rpc stuff in
5902017-04-13T19:35:35  <jonasschnelli> gmaxwell: can you explain "a lot"?
5912017-04-13T19:35:41  <BlueMatt> morcos: your previous warrants to me about weekend fee estimates in your new design being good represent a huge win for the ecosystem
5922017-04-13T19:36:07  *** Chris_Stewart_5 has quit IRC
5932017-04-13T19:36:07  <luke-jr> wumpus: (tomorrow)
5942017-04-13T19:36:09  <wumpus> it's all very low-risk and shouldn't affect non-unix-socket use cases
5952017-04-13T19:36:11  <sdaftuar> BlueMatt: I also think the ability to return non-conservative (ie, lower) fee estimates is important
5962017-04-13T19:36:17  <gmaxwell> jonasschnelli: all the things related to recovery are broken and we even don't know how to fix some of them.
5972017-04-13T19:36:18  <morcos> BlueMatt: yes, but exactly the kind of thing that need real world experimentation, b/c they change the real world conditions
5982017-04-13T19:36:18  <wumpus> luke-jr: thanks
5992017-04-13T19:36:22  <sipa> i want pertxoutcache, remove memory peak at flushing, better dbcache eviction policy, ...
6002017-04-13T19:36:44  <jonasschnelli> gmaxwell: Yes. I'm working on the recover (one of my 0.15 goals: "HD auto-restore")
6012017-04-13T19:36:52  <BlueMatt> OKOK, so review priorities towards all these amazing things? whats up this week :)
6022017-04-13T19:36:54  <sipa> oh, and segwit activated? pretty please?
6032017-04-13T19:36:58  <gmaxwell> morcos: right but there are incentives and security implications in the design, that deserve wider review than we'll get from people who will infer it from the code. Even if the description wasn't completely precise it would help.
6042017-04-13T19:37:00  <BlueMatt> sipa: lol
6052017-04-13T19:37:08  <cfields_> wumpus: yes. I've looked over that and it kinda clashes with my libevent changes. But it makes sense to get yours in first, then I can adapt mine.
6062017-04-13T19:37:22  * BlueMatt registers #10179
6072017-04-13T19:37:23  <gribble> https://github.com/bitcoin/bitcoin/issues/10179 | Give CValidationInterface Support for calling notifications on the CScheduler Thread by TheBlueMatt · Pull Request #10179 · bitcoin/bitcoin · GitHub
6082017-04-13T19:37:27  <wumpus> cfields_: the RPC pull (the first one) shouldn't collide
6092017-04-13T19:37:28  <gmaxwell> sipa: would likely help to get 0.14.1 out...
6102017-04-13T19:37:29  *** talmai has joined #bitcoin-core-dev
6112017-04-13T19:37:39  <wumpus> cfields_: I'm fine with including that one only for now, it's most of the code
6122017-04-13T19:37:40  <sipa> gmaxwell: ack
6132017-04-13T19:37:46  <cfields_> wumpus: no, the other. But it's a non-issue either way.
6142017-04-13T19:38:10  <wumpus> cfields_: the p2p-over-unix-socket is a very small patch on top of that, Im fine with doing that after libevent which means it can share the code with the RPC path
6152017-04-13T19:38:29  <morcos> gmaxwell: yes, writing up the high level design is actually simpler than explaining the actual implementation.  the high level design is pretty simple.. maybe i'll put more effort into the last commit which adds commentary
6162017-04-13T19:38:31  <wumpus> cfields_: though it depends on the time frame I guess
6172017-04-13T19:38:40  <gmaxwell> morcos: I think that would be really helpful.
6182017-04-13T19:38:46  <cfields_> sounds good.
6192017-04-13T19:38:59  <gmaxwell> morcos: Also for general review, I've lost track of the overall design of the estimator.
6202017-04-13T19:39:11  <sipa> morcos: i would like to see a 1-page document explaining what it tries to accomplish
6212017-04-13T19:39:20  <gmaxwell> morcos: in any case I strongly support improving it, the current one is dumb on weekends.
6222017-04-13T19:39:25  <cfields_> sipa: let's activate segwit after the meeting. We only have 20 min left :p
6232017-04-13T19:39:32  <gmaxwell> cfields_: ack
6242017-04-13T19:39:37  <wumpus> #action activate segwit
6252017-04-13T19:39:41  <morcos> sipa: ok
6262017-04-13T19:39:45  <gmaxwell> jinx
6272017-04-13T19:39:59  <sipa> (i have no clue how the estimator works, or ever worked, beside "something with buckets")
6282017-04-13T19:40:04  <morcos> gmaxwell: yes this is much better on weekends (optionally)
6292017-04-13T19:40:06  <instagibbs> ack on explanation, I was asking really dumb questions about it yesterday, may help
6302017-04-13T19:40:22  <gmaxwell> So we should bring up again per-txo and non-atomic flushing.  These changes are straight forward but call for a lot of heroic crash testing.
6312017-04-13T19:41:01  <BlueMatt> gmaxwell: I'm waiting for non-atomic to support disconnects
6322017-04-13T19:41:05  <BlueMatt> then I'll re-review :)
6332017-04-13T19:41:41  <bitcoin-git> [bitcoin] jnewbery opened pull request #10204: [rpc] rename disconnectnode argument (master...rename_disconnect_node_argument) https://github.com/bitcoin/bitcoin/pull/10204
6342017-04-13T19:42:00  <sipa> gmaxwell: agree, it needs to support reorgs
6352017-04-13T19:42:08  <sipa> also... even harder to test
6362017-04-13T19:42:28  <cfields_> high-level question about per-txo: what's the desired/expected outcome when downgrading from 0.15 to 0.14 ?
6372017-04-13T19:42:33  <gmaxwell> sipa: hm? with the current code we finish the flush all at once.
6382017-04-13T19:42:50  <gmaxwell> needing to support reorgs is only an issue with the changes we discussed post per-txo.
6392017-04-13T19:43:20  <MarcoFalke> wumpus: The pull jnewbery just opened could go into 0.14.1 if we do another rc anyway
6402017-04-13T19:43:32  <sipa> gmaxwell: a crash in the middle a flush after a disconnect cannot be recovered from with the current code
6412017-04-13T19:43:32  <wumpus> MarcoFalke: yep
6422017-04-13T19:43:37  <gmaxwell> cfields_: per-txo cannot be downgraded. reindex. Gotta take the cost at some point.  Non-atomic is downgradable on clean shutdown, reindex otherwise.
6432017-04-13T19:43:48  <jnewbery> MarcoFalke has suggested that I split off the non-backwards compatible rpc argument name change from #10143 into its own PR so it can be backported
6442017-04-13T19:43:50  <gribble> https://github.com/bitcoin/bitcoin/issues/10143 | [net] Allow disconnectnode RPC to be called with node id by jnewbery · Pull Request #10143 · bitcoin/bitcoin · GitHub
6452017-04-13T19:43:58  <gmaxwell> sipa: gotcha.
6462017-04-13T19:44:31  <gmaxwell> cfields_: We're going to have to take a non-downgradable change for per-txo at some point, I don't think never doing it is a realistic option, the improvement is too significant.
6472017-04-13T19:44:33  <wumpus> jnewbery: makes sense, it's still fairly safe to rename named arguments now, but they should be backported
6482017-04-13T19:45:12  *** d_t has quit IRC
6492017-04-13T19:45:15  <gmaxwell> cfields_: the overall changes to the dbcache are too burdensom to realisitcally support a version that can support both.
6502017-04-13T19:45:35  <sipa> i still wish for non-atomic flush in 0.14.2
6512017-04-13T19:45:38  <cfields_> gmaxwell: sure, makes sense. is it worth trying to slip in a bit of smarts into 0.14.1/0.14.2 gracefully saying that (in the event of an attempted downgrade) the format has changed?
6522017-04-13T19:45:41  * sipa keeps dreaming
6532017-04-13T19:46:02  <gmaxwell> cfields_: yes, that would be more reasonable than getting a generic corruption message.
6542017-04-13T19:46:10  <wumpus> cfields_: yes, something for 0.14.2
6552017-04-13T19:46:12  <sipa> cfields_: we could add a change in 0.14 that would make explicit downgrade easy
6562017-04-13T19:46:13  <morcos> sipa: too big a change
6572017-04-13T19:46:15  *** gmaxwell_ has joined #bitcoin-core-dev
6582017-04-13T19:46:18  <wumpus> no more new things for 0.14.1 please
6592017-04-13T19:46:19  <cfields_> .2, ignore for .1.
6602017-04-13T19:46:32  <gmaxwell> "Your database format is from the future, so sad for you. Please run reindex."
6612017-04-13T19:46:35  <cfields_> wumpus: sorry, realized my mistake too late :)
6622017-04-13T19:46:38  *** gmaxwell_ is now known as Guest93648
6632017-04-13T19:46:47  <sipa> morcos: i said wish, not demand :)
6642017-04-13T19:47:03  *** Guest93648 has left #bitcoin-core-dev
6652017-04-13T19:47:24  <sdaftuar> sipa: feature freeze for 0.15 is 2017-07-16
6662017-04-13T19:47:30  <luke-jr> sh AI sipa in 0.14.2
6672017-04-13T19:47:44  <gmaxwell> T1000 is back.
6682017-04-13T19:47:45  <sipa> sdaftuar: yeah, i saw, wumpus gave link
6692017-04-13T19:47:58  *** luke-jr_ has joined #bitcoin-core-dev
6702017-04-13T19:48:06  <luke-jr> I wish*
6712017-04-13T19:48:34  <gmaxwell>  /mode #bitcoin-dev +b *!*@178.62.68.75
6722017-04-13T19:48:39  <luke-jr_> :(
6732017-04-13T19:48:52  <luke-jr_> I can't think of a good nick :(
6742017-04-13T19:49:00  <wumpus> apparently we need to make meetings invite-to-speak only
6752017-04-13T19:49:17  <wumpus> stupid childish trolls are why we can't have nice things
6762017-04-13T19:49:17  <kanzure> you used wrong ip address last time
6772017-04-13T19:49:36  <spudowiar> wumpus: If you did that, I wouldn't be able to participate :(
6782017-04-13T19:49:40  <gmaxwell> wumpus: lets discuss in the meta meeting. :P
6792017-04-13T19:49:45  <luke-jr_> spudowiar: Well, no one gives a fuck
6802017-04-13T19:49:52  <cfields_> kanzure: no need, they're easy to spot. just ignore.
6812017-04-13T19:49:56  <gmaxwell> (after the meeting)
6822017-04-13T19:50:01  *** wumpus sets mode: +b *!*@178.62.68.75
6832017-04-13T19:50:10  *** luke-jr_ was kicked by wumpus (Kindergarten is elsewhere!)
6842017-04-13T19:50:19  <gmaxwell> in any case, lots of good things in flight. I think progress for 15 is good right now.
6852017-04-13T19:50:26  <BlueMatt> ok, so 10 minutes left
6862017-04-13T19:50:28  <BlueMatt> ryanofsky: ?
6872017-04-13T19:50:33  <BlueMatt> did you want to talk about multi-proces
6882017-04-13T19:50:43  <BlueMatt> also please folks list your review-priority for this week :)
6892017-04-13T19:50:55  <spudowiar> If that gets merged I will hug ryanofsky :)
6902017-04-13T19:50:59  <wumpus> spudowiar: I don't see why not; would just make it more work to invite everyone
6912017-04-13T19:51:11  <ryanofsky> not sure, what there is to say, #10102 is not complete, but the code that's there could use some review
6922017-04-13T19:51:12  <gribble> https://github.com/bitcoin/bitcoin/issues/10102 | bitcoin-qt: spawn bitcoind and communicate over pipe (Experimental, WIP) by ryanofsky · Pull Request #10102 · bitcoin/bitcoin · GitHub
6932017-04-13T19:51:20  <spudowiar> wumpus: No one would invite me :(
6942017-04-13T19:51:36  <sipa> i'm not sure what the appeal of multi process is
6952017-04-13T19:51:37  <wumpus> #topic multiprocess
6962017-04-13T19:51:47  <wumpus> process isolation
6972017-04-13T19:52:00  <sipa> i'd like to see the wallet go into a separate process from the networking
6982017-04-13T19:52:03  <jonasschnelli> sipa: #10102
6992017-04-13T19:52:04  <gribble> https://github.com/bitcoin/bitcoin/issues/10102 | bitcoin-qt: spawn bitcoind and communicate over pipe (Experimental, WIP) by ryanofsky · Pull Request #10102 · bitcoin/bitcoin · GitHub
7002017-04-13T19:52:18  <BlueMatt> sipa: then review my PRs, those do the first step of splitting it off neatly
7012017-04-13T19:52:26  <cfields_> ryanofsky: I've been wanting to split out net into a separate process, but the barrier was creating an IPC. So I'm all for it.
7022017-04-13T19:52:29  <BlueMatt> then we can use ryanofsky's multiprocess stuff to do the process :)
7032017-04-13T19:52:31  <wumpus> not having the gui and the rest in one address space would be a good start
7042017-04-13T19:52:32  <sipa> that that's qt from the rest
7052017-04-13T19:52:49  <sipa> that seems like a pointless gimmick to me
7062017-04-13T19:53:01  <jonasschnelli> Yes. The wallet seems to be more important.
7072017-04-13T19:53:06  <wumpus> sigh
7082017-04-13T19:53:11  <gmaxwell> If it could disconect and reconnect it would have some value.
7092017-04-13T19:53:15  <ryanofsky> agreed the wallet is more important
7102017-04-13T19:53:18  * BlueMatt wasnt sure whether folks would like the many-process approach, over two-processes (wallet, and other)
7112017-04-13T19:53:29  <jonasschnelli> not saying the Qt part is not important
7122017-04-13T19:53:41  <ryanofsky> reason for starting with qt is that wallet work will depend on matt's changes
7132017-04-13T19:53:41  <jnewbery> I'd like one process per wallet for multi-wallet
7142017-04-13T19:53:44  <spudowiar> Oh, I thought that was wallet as well (my offer of hug has been withdrawn, ryanofsky)
7152017-04-13T19:53:54  <wumpus> the gui has more pressing problems though: too much happens synchronous with the core in the GUI loop
7162017-04-13T19:54:05  <jonasschnelli> wumpus: thats a good point
7172017-04-13T19:54:09  <ryanofsky> and qt seemed like it might be a less controversial place to start since we already have separate bitcoind and bitcoin-qt executables
7182017-04-13T19:54:18  <wumpus> ryanofsky: yes I agree
7192017-04-13T19:54:32  *** BCBot_ has quit IRC
7202017-04-13T19:54:44  <cfields_> i suspect this will probably go down like the scripted-diffs discussion. Maybe we should assign ourselves homework to read the PR fully and discuss next week?
7212017-04-13T19:54:48  <jonasschnelli> Architectural wise: splitting of Qt makes more sense.. security: wallet. Splitting of the wallet with something similar to an ssh/gpg-agent shouldn't be very complicated.
7222017-04-13T19:54:50  *** BCBot has joined #bitcoin-core-dev
7232017-04-13T19:55:03  <wumpus> ryanofsky: would make sense to not have them share all that code
7242017-04-13T19:55:03  <sipa> hmm, i withdraw my comment about it being pointless
7252017-04-13T19:55:10  <gmaxwell> I've read the PR.
7262017-04-13T19:55:35  <wumpus> also having one example of IPC between process could make other splits easier
7272017-04-13T19:55:40  <gmaxwell> But this is not a good design.
7282017-04-13T19:55:46  <gmaxwell> as such an example.
7292017-04-13T19:55:58  <jnewbery> 5 minutes left.
7302017-04-13T19:55:59  <jnewbery> Suggested topic: PR review requests
7312017-04-13T19:56:11  <wumpus> gmaxwell: have you commented about the design in the PR?
7322017-04-13T19:56:20  <wumpus> #topic high-priority PR review requests
7332017-04-13T19:56:33  <BlueMatt> #10179
7342017-04-13T19:56:34  <gribble> https://github.com/bitcoin/bitcoin/issues/10179 | Give CValidationInterface Support for calling notifications on the CScheduler Thread by TheBlueMatt · Pull Request #10179 · bitcoin/bitcoin · GitHub
7352017-04-13T19:56:34  <BlueMatt> for me
7362017-04-13T19:57:09  <sipa> #9792 plz
7372017-04-13T19:57:11  <gribble> https://github.com/bitcoin/bitcoin/issues/9792 | FastRandomContext improvements and switch to ChaCha20 by sipa · Pull Request #9792 · bitcoin/bitcoin · GitHub
7382017-04-13T19:57:12  <morcos> wumpus: #9942 can be merged i think which will at least make the rest of the fee estimation changes smaller to review
7392017-04-13T19:57:12  *** moli_ has quit IRC
7402017-04-13T19:57:13  <gribble> https://github.com/bitcoin/bitcoin/issues/9942 | Refactor CBlockPolicyEstimator by morcos · Pull Request #9942 · bitcoin/bitcoin · GitHub
7412017-04-13T19:57:17  *** stoner19 has left #bitcoin-core-dev
7422017-04-13T19:57:18  <spudowiar> wumpus: For external signing, currently messing about with external command, using stdio but other IPC example would be useful
7432017-04-13T19:57:24  <spudowiar> Oops, topic's moved on, sorry
7442017-04-13T19:57:26  <gmaxwell> (What this PR does is pulls in a compat library to just break the function boundaries, to work across processes, it is not an actual IPC.  And for just making the GUI more concurrent and perhaps reconnectable that fine.  But that is not how we should seperate the wallet.
7452017-04-13T19:57:31  <gmaxwell> )
7462017-04-13T19:57:42  <gmaxwell> wumpus: I can comment more if I haven't.
7472017-04-13T19:58:10  <spudowiar> Wallet communicating over the JSON-RPC interface would be quite good, but then you have the issue that wallet functionality is provided over the JSON-RPC interface?
7482017-04-13T19:58:24  <wumpus> morcos: BlueMatt: ok added them to the project  https://github.com/bitcoin/bitcoin/projects/8
7492017-04-13T19:58:27  <jnewbery> I'd like some review on #10044. The concept had some ACKs in the meeting a few weeks ago.
7502017-04-13T19:58:28  <gribble> https://github.com/bitcoin/bitcoin/issues/10044 | Run functional tests in `make check` by jnewbery · Pull Request #10044 · bitcoin/bitcoin · GitHub
7512017-04-13T19:58:41  <wumpus> also sipa's
7522017-04-13T19:58:46  <morcos> wumpus: ok, in 9942 case i think it has enough acks already
7532017-04-13T19:59:03  <cfields_> jnewbery: will do.
7542017-04-13T19:59:16  <wumpus> jnewbery: also added
7552017-04-13T19:59:28  *** moli_ has joined #bitcoin-core-dev
7562017-04-13T19:59:35  <luke-jr> spudowiar: JSON-RPC already provides wallet..
7572017-04-13T20:00:00  <BlueMatt> DONG
7582017-04-13T20:00:04  <wumpus> #endmeeting
7592017-04-13T20:00:04  <lightningbot> Meeting ended Thu Apr 13 20:00:04 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7602017-04-13T20:00:04  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-13-19.00.html
7612017-04-13T20:00:04  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-13-19.00.txt
7622017-04-13T20:00:04  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-13-19.00.log.html
7632017-04-13T20:00:13  <BlueMatt> gmaxwell: so is your objection that qt and other things dont need separated, or that this isnt the right approach?
7642017-04-13T20:00:15  <spudowiar> luke-jr: That's the point I was making. If you have the wallet talking to the daemon over JSON-RPC, how can you provide the wallet functionality over JSON-RPC?
7652017-04-13T20:00:24  <spudowiar> luke-jr: I'm just really bad at wording stuff :)
7662017-04-13T20:00:33  <jnewbery> cfields_ wumpus thanks
7672017-04-13T20:00:37  <spudowiar> petertodd: That's why we need OpenPGP Card 4.0 :)
7682017-04-13T20:00:51  *** harrymm has quit IRC
7692017-04-13T20:00:51  <spudowiar> petertodd: So that the smart card can request bits of the data, etc. and display it on the display
7702017-04-13T20:00:52  <petertodd> spudowiar: it'll have to have a display at least... fudnemental probelm
7712017-04-13T20:00:59  <spudowiar> petertodd: TREZOR
7722017-04-13T20:01:08  <spudowiar> petertodd: I have a working OpenPGP implementation for TREZOR
7732017-04-13T20:01:12  <spudowiar> Only does ECDSA signing though
7742017-04-13T20:01:16  <spudowiar> Rewriting it in Rust though
7752017-04-13T20:01:17  <petertodd> spudowiar: heh, git support for trezor...
7762017-04-13T20:01:30  <spudowiar> petertodd: I signed a Git commit with it :)
7772017-04-13T20:01:41  <petertodd> spudowiar: oh, theres a rust impl for the trezor uc?
7782017-04-13T20:02:03  <gmaxwell> BlueMatt: QT being seperated can improve concurrency and ... if done right allow it to turn off and on, while the daemon keeps running. Which I think are moderately useful things.   And the way that it is done here is more or less okay for just accomplishing that.  But it not a way that we should seperate the wallet, it is HIGHLY trusting, it wouldn't support multiple concurrent users, it doesn'
7792017-04-13T20:02:07  <spudowiar> petertodd: Rust runs on pretty much anything (there's an LLVM backend for STM32*)
7802017-04-13T20:02:09  <gmaxwell> t provide for a stable interface. etc.
7812017-04-13T20:02:25  <petertodd> spudowiar: nice!
7822017-04-13T20:02:31  <luke-jr> bbl
7832017-04-13T20:02:33  <gmaxwell> wumpus: metametting we should +v all the regulars and then if there is noise we can set the channel +m and +v the few extra non-regulars that aren't causing trouble.
7842017-04-13T20:02:35  <petertodd> spudowiar: I've got a big project I'm doing in rust right now
7852017-04-13T20:02:44  <spudowiar> !m petertodd
7862017-04-13T20:02:44  <[b__b]> You're doing good work, petertodd!
7872017-04-13T20:02:44  <gribble> Error: "m" is not a valid command.
7882017-04-13T20:02:51  <spudowiar> Go away gribble
7892017-04-13T20:03:07  <petertodd> heh
7902017-04-13T20:03:31  <spudowiar> petertodd: https://pgp.mit.edu/pks/lookup?op=vindex&search=0xEDD78A88C5D03B56 is the key generated by my TREZOR
7912017-04-13T20:03:37  <luke-jr> (not sure if anyone's fixed 0.14.1 relnotes confusing ppl re miner signalling.. but it should probably get fixed befoe firal)
7922017-04-13T20:03:56  <petertodd> spudowiar: nice!
7932017-04-13T20:04:04  <spudowiar> https://github.com/trezor/trezor-mcu/pull/133 is the firmware code (written in C)
7942017-04-13T20:04:04  *** dgenr8_ has quit IRC
7952017-04-13T20:04:08  <jonasschnelli> spudowiar: Yeah. Nice stuff...
7962017-04-13T20:04:41  <spudowiar> Only thing stopping me from getting this all finished is school :(
7972017-04-13T20:05:21  <jonasschnelli> skip school
7982017-04-13T20:05:23  <spudowiar> lol
7992017-04-13T20:05:25  <spudowiar> Wait...
8002017-04-13T20:05:32  <spudowiar> I actually have a video of this :)
8012017-04-13T20:05:52  <jcorgan> of you skipping school?
8022017-04-13T20:05:58  <petertodd> spudowiar: I dropped out of a physics degree for bitcoin (though I was doing it part time while working at a startup...)
8032017-04-13T20:05:59  <wumpus> gmaxwell: yes, seems a good idea
8042017-04-13T20:06:45  <cfields_> petertodd: you had that lucrative art degree as a fallback, though :p
8052017-04-13T20:06:56  <petertodd> cfields_: lol
8062017-04-13T20:07:29  *** harrymm has joined #bitcoin-core-dev
8072017-04-13T20:07:47  <spudowiar> https://twitter.com/spudowiar/status/784429631545958400
8082017-04-13T20:07:50  <spudowiar> NO, THAT IS THE WRONG VIDEO
8092017-04-13T20:07:53  <spudowiar> https://twitter.com/spudowiar/status/802960101992759296
8102017-04-13T20:07:55  <spudowiar> Sorry
8112017-04-13T20:08:20  <jcorgan> petertodd: worst case you can always rely on bridgette's money
8122017-04-13T20:08:22  <spudowiar> Someone asked me if it worked on Windows so I recorded that for them :)
8132017-04-13T20:09:02  <petertodd> jcorgan: heh
8142017-04-13T20:09:16  <spudowiar> Wait... petertodd liked that video? When...?
8152017-04-13T20:09:26  <spudowiar> Oh wait, late Twitter notifications
8162017-04-13T20:09:35  <petertodd> spudowiar: just now :)
8172017-04-13T20:11:14  <spudowiar> petertodd: The firmware in the Pong video was written in Rust
8182017-04-13T20:12:48  <petertodd> spudowiar: nice! I'm rather excited for rust on embedded; I used to do a bunch of asm and C uC stuff, and it always kinda sucked
8192017-04-13T20:13:46  *** g0d355__ has joined #bitcoin-core-dev
8202017-04-13T20:17:07  <BlueMatt> re: splitting qt process: can we use our own serialization instead of capnproto, ryanofsky?
8212017-04-13T20:18:50  <ryanofsky> BlueMatt: yes we can, i'm working on splitting up the change into two prs, one adding ipc interface and another adding capnproto glue to show how separation works
8222017-04-13T20:18:52  <wumpus> the gui has more pressing problems though: too much happens synchronous with the core in the GUI loop <- in any case, this needs to be addressed first, or as part of the move to a seprate process
8232017-04-13T20:19:06  <wumpus> the GUI thread should never block on a IPC request
8242017-04-13T20:20:16  <wumpus> (currently it blocks on calls to core, or while taking the cs_main lock, resulting in lack of user response for significant time)
8252017-04-13T20:21:03  <spudowiar> sipa: If I'm parsing a scriptPubKey using Solver, I get a CPubKey. How to get to a CKeyMetadata from there? (to get hdMasterKeyID)
8262017-04-13T20:21:30  <gmaxwell> wumpus: Can you explain shimming in the IPC address those blocks?-- if none of the dataflow is changed.
8272017-04-13T20:22:06  <ryanofsky> i'm not changing gui locking / blocking in my pr. if there are cases where gui is freezing up, the only way to address those is individually
8282017-04-13T20:22:30  <wumpus> gmaxwell: shimming?
8292017-04-13T20:23:17  <ryanofsky> the only impact my will have on gui responsiveness is there are a lot of ipc calls being called in a tight loop where they might be noticablely slower than current function calls
8302017-04-13T20:23:36  <wumpus> ryanofsky: that's kind of my problem with it; it may compound thecurrent issues
8312017-04-13T20:23:37  <ryanofsky> or ipc calls that have to serialize / deserialize a large amount of data
8322017-04-13T20:23:40  <gmaxwell> my read on ryanofsky's patch is that it just inserts IPC dispatch at these communication points. The software would still block no less as a result.  By shimming I mean replacing  function() with  ipc->function->ipc.
8332017-04-13T20:23:58  <wumpus> gmaxwell: that's why I say that should be addressed first
8342017-04-13T20:23:59  <ryanofsky> wumpus, yes, we will have to see what performance will be
8352017-04-13T20:24:25  <wumpus> gmaxwell: one everything the GUI does is asynchronous, making it work over IPC is also a lot easier
8362017-04-13T20:24:30  <ryanofsky> but i do think any performance problems that are uncovered can be dealt with
8372017-04-13T20:24:39  <wumpus> gmaxwell: that was my original plan for the GUI but I never had time to finish it :(
8382017-04-13T20:24:45  <gmaxwell> wumpus: ah!
8392017-04-13T20:24:57  <ryanofsky> it seems to me a lot easier to fix performance problems that come up than "make everything asyncrhonous"
8402017-04-13T20:25:06  <wumpus> easier, but not better
8412017-04-13T20:25:09  <gmaxwell> (I was thinking you thought the ipc changes did this already and thought I was confused).
8422017-04-13T20:25:28  <wumpus> no, ideally IPC chnanges would do that
8432017-04-13T20:25:35  <wumpus> but these don't, no
8442017-04-13T20:25:39  <gmaxwell> ryanofsky: is it your thought that eventually the GUI could be started and stopped independantly of the backend?
8452017-04-13T20:26:13  <wumpus> making everything asynchronous would improve the user experience a lot
8462017-04-13T20:26:35  <wumpus> as well as avoid silly things like the gui not coming up because it's blocked on one value that it needs to get under a cs_main
8472017-04-13T20:26:40  <ryanofsky> gmaxwell, supporting that would be pretty easy, but i don't know what the use-cases would be
8482017-04-13T20:27:00  <wumpus> ryanofsky: the typical windows service idea: have a GUI to manage it, that runs only part of the time
8492017-04-13T20:27:19  <gmaxwell> If not then I really do not understand the purpose of IPC seperating it at all. Making it (largely)-async is an independant issue.  The kind of approach here is tightly coupled, so it couldn't really support a GUI in a seperate codebase, multiple GUI projects, or concurrent multiple GUIs.
8502017-04-13T20:27:33  <gmaxwell> The advantage of being able to start and stop is so the GUI doesn't run when it's not needed.
8512017-04-13T20:27:39  <spudowiar> Oh, wait, I can call CWallet::LoadKeyMetadata!
8522017-04-13T20:27:49  <wumpus> well the cap'n'proto thing could theoretically work with a separate process
8532017-04-13T20:27:56  <wumpus> codebase*
8542017-04-13T20:28:08  <wumpus> they only have to share the interface definition
8552017-04-13T20:28:19  <ryanofsky> gmaxwell, i think the approach can support all of those things. but my initial plan for the pr is just to change the infrastructure without exposing new features
8562017-04-13T20:28:22  <gmaxwell> wumpus: yes but without a designed and clean interface you can't reasonably support that.
8572017-04-13T20:28:37  <wumpus> gmaxwell: maybe not in the first version
8582017-04-13T20:28:41  <gmaxwell> And you get the ZMQ like "everything has to run exactly the same version of ZMQ" issue.
8592017-04-13T20:28:56  <wumpus> gmaxwell: but I think you want too much at the same time
8602017-04-13T20:29:28  <ryanofsky> gmaxwell, my pr defines an interface
8612017-04-13T20:29:41  <gmaxwell> ISTM if the goal is those things, what is needed is a RPC.  This just seems like a 170 degree turn from existing plans on seperating the wallet as a SPV client with special messages for mempool and whatnot.
8622017-04-13T20:29:51  <wumpus> baby steps sometimes make sense so that there is at least progress, the interface he defines may not be super clean yet but it's at least a start
8632017-04-13T20:30:01  <gmaxwell> and replacing it with something that we'll never be able to precisely define or secure.
8642017-04-13T20:30:19  <wumpus> anyhow I don't think we'll ever make progress here this way, we just all want too different things
8652017-04-13T20:30:21  <sipa> spudowiar: no
8662017-04-13T20:30:30  <ryanofsky> how is the interface not precisely designed & secure?
8672017-04-13T20:30:46  <ryanofsky> i mean defined not designed
8682017-04-13T20:30:54  <sipa> spudowiar: that method is for loading metadata into the wallet
8692017-04-13T20:31:31  <spudowiar> sipa: Yeah, I just saw that
8702017-04-13T20:31:43  <gmaxwell> ryanofsky: where is a wire specification for captin proto that can be independantly implemented?
8712017-04-13T20:32:14  <ryanofsky> oh this is just an objection to capnproto?
8722017-04-13T20:32:17  <wumpus> ryanofsky: even then, you're not currently opening it up, this first experimental version in the PR is internal only
8732017-04-13T20:32:43  <ryanofsky> if capnproto is a real problem, a different protocol could be dropped in instead
8742017-04-13T20:33:00  <gmaxwell> ryanofsky: yea, a lot of my concern is the approach of taking an internal boundary and then wrapping it in captinproto (which I have specific concerns about which might be outdated).
8752017-04-13T20:33:01  <wumpus> once you have a better idea of what you need you can improve the protocol, then eventually open it up to other applications maybe
8762017-04-13T20:33:11  <ryanofsky> most of the work i'm doing here is in making qt not call wallet/node functions directly
8772017-04-13T20:33:30  *** spudowiar has quit IRC
8782017-04-13T20:33:37  <ryanofsky> if you have suggestions for another wire format to use instead of capnproto, that'd be helpful
8792017-04-13T20:33:41  <gmaxwell> ryanofsky: that stuff all sounds great to me independant of the rest.
8802017-04-13T20:34:16  <wumpus> what I like about cap'n'proto is that the interface is cleanly defined in the .capnp file, other software could in principle use that interface definition and just communicate with it
8812017-04-13T20:34:38  <ryanofsky> there is a lot i like about capnproto, but so far it actually requires a lot more boilerplate than i was expected, and i'm not at all wedded to it
8822017-04-13T20:34:39  <wumpus> e.g. https://github.com/bitcoin/bitcoin/pull/10102/files#diff-1832023b80d9337ec49f60646c7a9c5dR1
8832017-04-13T20:35:36  <gmaxwell> wumpus: yes so long as they also take all of captin proto, of the same vintage.
8842017-04-13T20:35:58  <wumpus> gmaxwell: yes, they have to use the same IPC library
8852017-04-13T20:36:12  <wumpus> gmaxwell: you'd want an independent implementation of the protocol?
8862017-04-13T20:36:12  *** Dizzle has quit IRC
8872017-04-13T20:37:10  <wumpus> I vaguely remember the wire format for capnp is documented, but can't find it quickly
8882017-04-13T20:37:14  <gmaxwell> that comes back to IPC vs RPC.  I believe the wallet seperation should be a RPC.  I don't really have any opinion in GUI IPC seperation, beyond being able to independantly start and stop it, I don't see the value-- but I acknoweldge and respect that people who know more about the GUI parts may see value in it that I don't.
8892017-04-13T20:37:51  <sipa> well it would be nice to just have bitcoind running, and occasionally connect your qt frontend to it
8902017-04-13T20:37:58  <wumpus> https://capnproto.org/encoding.html
8912017-04-13T20:37:59  <gmaxwell> If it truly just is an IPC then I don't care much about requring the same versions or an interface that wasn't really designed and documented and supported as a public interface.
8922017-04-13T20:38:03  <gmaxwell> sipa: agreed.
8932017-04-13T20:38:22  <ryanofsky> i don't really see a significant difference between ipc / rpc here. either way you have bytes going across a socket. the only difference is whether you bind the socket to a port or not
8942017-04-13T20:38:43  <sipa> ryanofsky: i think what gmaxwell means is whether it's a well defined interface
8952017-04-13T20:38:53  <sipa> will the gui and server always be the same version
8962017-04-13T20:39:04  <sipa> or do they need to interact across different versions
8972017-04-13T20:39:12  <wumpus> at first: no
8982017-04-13T20:39:13  <ryanofsky> sipa, that's up to us
8992017-04-13T20:39:14  <gmaxwell> Well defined and stable, right.
9002017-04-13T20:39:42  <sipa> ryanofsky: and i think gmaxwell means that for the Qt split, no well defined and stable interface is needed
9012017-04-13T20:39:42  <wumpus> there's no reason that couldn't be added, but it doesn't seem required for doing this in the first place
9022017-04-13T20:39:48  <sipa> but for the wallet separation there is
9032017-04-13T20:40:17  <gmaxwell> Also how much do you trust the code you're talking to.  With captin proto, if the far end does something unexpected (much less malicious) access to the objects long after the IPC completes will throw exceptions.
9042017-04-13T20:40:18  <ryanofsky> capnproto supports extending interfaces in backwards compatible ways, that's the reason for all the field numbers & interface method numbers in the schema file
9052017-04-13T20:40:34  <wumpus> ryanofsky: indeed, they have thought of this
9062017-04-13T20:41:10  <gmaxwell> And thats fine for gui/rest since it's all one codebase, from one group.. and of course function calls also do crazy things if you get anything wrong.
9072017-04-13T20:41:18  <wumpus> but yes secure IPC for sandboxed code is difficult, and maybe cap'\n'proto is not the best suited for that
9082017-04-13T20:41:18  <gmaxwell> But that isn't what we want for wallet seperation.
9092017-04-13T20:41:51  <sipa> i think for wallet separation we should just use p2p
9102017-04-13T20:42:16  <sipa> and have the wallet side implement spv
9112017-04-13T20:42:27  <gmaxwell> That is what we've always planned, and I think it is good and as a side effect mostly written already.
9122017-04-13T20:42:31  *** Guyver2 has quit IRC
9132017-04-13T20:42:40  <sipa> and designed for
9142017-04-13T20:44:01  *** Guyver2 has joined #bitcoin-core-dev
9152017-04-13T20:44:03  <wumpus> looked at chromium: for IPC they use a serialization system (like ours) called pickle, and serialize/deserialize using that in the IPC entry points where needed, no interface compiler
9162017-04-13T20:44:48  <gmaxwell> thats totally not confusing with python. :P
9172017-04-13T20:45:19  <BlueMatt> wumpus: i think you can remove the merged PRs from https://github.com/bitcoin/bitcoin/projects/8
9182017-04-13T20:45:51  <BlueMatt> luke-jr: where are you on #8694? looks like you have a bunch of comments to fix?
9192017-04-13T20:45:53  <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
9202017-04-13T20:46:28  <ryanofsky> wumpus, chromium is in the middle of transitioning between ipc systems
9212017-04-13T20:46:49  <wumpus> communication (on unix) is done over a SOCK_DGRAM or SOCK_SEQPACKET socketpair, they support some advanced things like sending over file descriptors
9222017-04-13T20:46:57  <wumpus> ryanofsky: oh?
9232017-04-13T20:46:58  <ryanofsky> older one is based on c macros, newer one is a stripped down fork of https://github.com/domokit/mojo
9242017-04-13T20:48:13  <ryanofsky> mojo is similar to capnproto, but supports passing file descriptors & shared memory over the socket, not just sending bytes
9252017-04-13T20:48:36  <wumpus> didn't know about mojo
9262017-04-13T20:49:09  <ryanofsky> this page describes the older chromium ipc mechanism: https://www.chromium.org/developers/design-documents/inter-process-communication
9272017-04-13T20:49:49  <ryanofsky> yeah i actually looked into using mojo before capnproto
9282017-04-13T20:50:07  <ryanofsky> but the mojo project itself is actually dead
9292017-04-13T20:50:52  <ryanofsky> there are now two forks of mojo, one is internal to chromium, and the other is internal to google's fuschia os project
9302017-04-13T20:51:03  <wumpus> so they don't use the project itself, just copied some files to their project?
9312017-04-13T20:51:20  <ryanofsky> copied & stripped out parts they didn't need
9322017-04-13T20:51:38  <ryanofsky> https://chromium.googlesource.com/chromium/src/+/master/mojo
9332017-04-13T20:57:08  <wumpus> yes that seems quite close to cap'n'proto
9342017-04-13T20:57:51  *** tw2006 has quit IRC
9352017-04-13T21:10:16  *** Ylbam has joined #bitcoin-core-dev
9362017-04-13T21:19:54  <bitcoin-git> [bitcoin] theuni opened pull request #10205: net: define NodeId as an int64_t (0.14...10176-backport) https://github.com/bitcoin/bitcoin/pull/10205
9372017-04-13T21:24:56  *** chjj has quit IRC
9382017-04-13T21:37:02  *** talmai has quit IRC
9392017-04-13T21:42:11  <bitcoin-git> [bitcoin] dramaticbulgarian opened pull request #10206: Chainparams: In ReceivedBlockTransactions() (master...chainparams) https://github.com/bitcoin/bitcoin/pull/10206
9402017-04-13T21:52:14  *** Giszmo has joined #bitcoin-core-dev
9412017-04-13T21:55:26  *** jtimon has quit IRC
9422017-04-13T22:00:20  *** jcorgan is now known as jcorgan_
9432017-04-13T22:01:14  *** jcorgan_ is now known as jcorgan
9442017-04-13T22:04:34  *** LeMiner2 has joined #bitcoin-core-dev
9452017-04-13T22:06:56  *** LeMiner has quit IRC
9462017-04-13T22:06:56  *** LeMiner2 is now known as LeMiner
9472017-04-13T22:06:57  *** fao has quit IRC
9482017-04-13T22:07:32  *** fao has joined #bitcoin-core-dev
9492017-04-13T22:12:55  *** Guyver2 has quit IRC
9502017-04-13T22:13:25  *** TheV01D has joined #bitcoin-core-dev
9512017-04-13T22:14:27  <TheV01D> lo
9522017-04-13T22:35:54  *** fao has quit IRC
9532017-04-13T22:36:19  *** fao has joined #bitcoin-core-dev
9542017-04-13T22:36:24  *** LeMiner2 has joined #bitcoin-core-dev
9552017-04-13T22:39:08  *** LeMiner has quit IRC
9562017-04-13T22:39:08  *** LeMiner2 is now known as LeMiner
9572017-04-13T22:39:13  *** owowo has quit IRC
9582017-04-13T22:41:41  *** ryan-c- is now known as ryan-c
9592017-04-13T22:46:47  *** tw2006 has joined #bitcoin-core-dev
9602017-04-13T22:51:37  *** tw2006 has quit IRC
9612017-04-13T22:57:38  *** AaronvanW has quit IRC
9622017-04-13T22:58:15  *** AaronvanW has joined #bitcoin-core-dev
9632017-04-13T23:17:06  <bitcoin-git> [bitcoin] dramaticbulgarian closed pull request #10206: Chainparams: In ReceivedBlockTransactions() (master...chainparams) https://github.com/bitcoin/bitcoin/pull/10206
9642017-04-13T23:20:09  *** goksinen has joined #bitcoin-core-dev
9652017-04-13T23:24:35  *** goksinen has quit IRC
9662017-04-13T23:25:24  *** goksinen has joined #bitcoin-core-dev
9672017-04-13T23:31:09  *** goksinen has quit IRC
9682017-04-13T23:32:01  *** owowo has joined #bitcoin-core-dev
9692017-04-13T23:33:47  *** AaronvanW has quit IRC
9702017-04-13T23:41:10  *** owowo has quit IRC
9712017-04-13T23:42:02  *** owowo has joined #bitcoin-core-dev
9722017-04-13T23:54:54  *** btcdrak has quit IRC