1 2017-04-13T00:00:57  *** abpa has quit IRC
  2 2017-04-13T00:04:14  *** AaronvanW has quit IRC
  3 2017-04-13T00:11:32  *** chjj has joined #bitcoin-core-dev
  4 2017-04-13T00:14:10  *** Ylbam has quit IRC
  5 2017-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
  6 2017-04-13T00:22:50  *** Giszmo has joined #bitcoin-core-dev
  7 2017-04-13T00:32:33  <sdaftuar> gmaxwell: is this what you have in mind? https://github.com/sdaftuar/bitcoin/tree/2017-04-braindead-simple-mining
  8 2017-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
  9 2017-04-13T00:33:27  <sdaftuar> i'm not a fan of the model though
 10 2017-04-13T00:35:48  *** midnightmagic has quit IRC
 11 2017-04-13T00:41:53  *** midnightmagic has joined #bitcoin-core-dev
 12 2017-04-13T01:10:11  *** d_t has joined #bitcoin-core-dev
 13 2017-04-13T01:11:52  *** d_t has joined #bitcoin-core-dev
 14 2017-04-13T01:19:07  <gmaxwell> sdaftuar: 10 seconds and .0005 BTC should be fine for a test run.
 15 2017-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.
 16 2017-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)
 17 2017-04-13T01:25:05  *** isle2983 has quit IRC
 18 2017-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?
 19 2017-04-13T01:26:53  <gmaxwell> sdaftuar: 10 seconds is a non-trivial amount of time to allow propagation however.
 20 2017-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.
 21 2017-04-13T01:28:10  <sdaftuar> even if i rbf every 5 seconds, its a trivial amount of money
 22 2017-04-13T01:28:26  *** Guest76166 has quit IRC
 23 2017-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.
 24 2017-04-13T01:30:09  <gmaxwell> (mentioned somewhere in the logs here)
 25 2017-04-13T01:31:16  <sdaftuar> yeah i have no idea what the actual stale rates people see are
 26 2017-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
 27 2017-04-13T01:32:46  <sdaftuar> for clarity:  that "/" above is not meant to be division
 28 2017-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
 29 2017-04-13T01:34:12  <gmaxwell> etition was sending an empty block.
 30 2017-04-13T01:34:53  *** btcdrak has quit IRC
 31 2017-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?
 32 2017-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
 33 2017-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
 34 2017-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?
 35 2017-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
 36 2017-04-13T01:53:41  <sdaftuar> ah, i guess my language is potentially confusing
 37 2017-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.
 38 2017-04-13T01:55:12  <sdaftuar> right
 39 2017-04-13T01:55:21  <sdaftuar> all i wanted to explain was "multiply by 2!"
 40 2017-04-13T01:55:28  <sdaftuar> maybe just delete my parenthetical?
 41 2017-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.
 42 2017-04-13T02:00:06  *** dermoth has quit IRC
 43 2017-04-13T02:00:48  *** dermoth has joined #bitcoin-core-dev
 44 2017-04-13T02:04:10  *** AaronvanW has joined #bitcoin-core-dev
 45 2017-04-13T02:05:49  *** Samdney has quit IRC
 46 2017-04-13T02:07:40  *** jtimon has quit IRC
 47 2017-04-13T02:09:00  *** Chris_Stewart_5 has quit IRC
 48 2017-04-13T02:15:45  *** Giszmo has quit IRC
 49 2017-04-13T02:17:24  *** AaronvanW has quit IRC
 50 2017-04-13T02:21:45  *** AaronvanW has joined #bitcoin-core-dev
 51 2017-04-13T02:26:47  *** d_t has quit IRC
 52 2017-04-13T02:29:04  *** talmai has joined #bitcoin-core-dev
 53 2017-04-13T03:01:20  *** AaronvanW has quit IRC
 54 2017-04-13T03:06:05  *** AaronvanW has joined #bitcoin-core-dev
 55 2017-04-13T03:12:21  *** arowser has quit IRC
 56 2017-04-13T03:13:48  *** arowser has joined #bitcoin-core-dev
 57 2017-04-13T03:30:57  *** AaronvanW has quit IRC
 58 2017-04-13T03:33:27  *** AaronvanW has joined #bitcoin-core-dev
 59 2017-04-13T03:46:06  *** dodomojo has joined #bitcoin-core-dev
 60 2017-04-13T03:50:56  *** d_t has joined #bitcoin-core-dev
 61 2017-04-13T03:51:05  *** AaronvanW has quit IRC
 62 2017-04-13T03:53:38  *** AaronvanW has joined #bitcoin-core-dev
 63 2017-04-13T04:13:21  *** AaronvanW has quit IRC
 64 2017-04-13T04:14:42  *** AaronvanW has joined #bitcoin-core-dev
 65 2017-04-13T04:27:10  *** AaronvanW has quit IRC
 66 2017-04-13T04:30:51  *** AaronvanW has joined #bitcoin-core-dev
 67 2017-04-13T04:44:11  *** AaronvanW has quit IRC
 68 2017-04-13T04:47:36  *** Cheeseo has quit IRC
 69 2017-04-13T04:49:25  *** AaronvanW has joined #bitcoin-core-dev
 70 2017-04-13T04:51:49  *** justan0theruser has joined #bitcoin-core-dev
 71 2017-04-13T04:54:12  *** justanotheruser has quit IRC
 72 2017-04-13T05:05:05  *** n1ce has quit IRC
 73 2017-04-13T05:17:01  *** AaronvanW has quit IRC
 74 2017-04-13T05:18:13  *** AaronvanW has joined #bitcoin-core-dev
 75 2017-04-13T05:19:27  *** dodomojo has quit IRC
 76 2017-04-13T05:42:10  *** btcdrak has joined #bitcoin-core-dev
 77 2017-04-13T05:57:33  *** talmai has quit IRC
 78 2017-04-13T06:05:49  *** AaronvanW has quit IRC
 79 2017-04-13T06:07:50  *** AaronvanW has joined #bitcoin-core-dev
 80 2017-04-13T06:10:16  *** goksinen has joined #bitcoin-core-dev
 81 2017-04-13T06:15:07  *** Ylbam has joined #bitcoin-core-dev
 82 2017-04-13T06:15:12  *** goksinen has quit IRC
 83 2017-04-13T06:16:16  *** AaronvanW has quit IRC
 84 2017-04-13T06:25:03  *** AaronvanW has joined #bitcoin-core-dev
 85 2017-04-13T06:31:13  *** AaronvanW has quit IRC
 86 2017-04-13T06:33:45  *** AaronvanW has joined #bitcoin-core-dev
 87 2017-04-13T06:47:19  *** AaronvanW has quit IRC
 88 2017-04-13T06:49:18  *** AaronvanW has joined #bitcoin-core-dev
 89 2017-04-13T06:49:34  *** vFSgrcFGBJHg has joined #bitcoin-core-dev
 90 2017-04-13T07:04:05  *** kexkey has quit IRC
 91 2017-04-13T07:05:20  *** AaronvanW has quit IRC
 92 2017-04-13T07:08:10  *** AaronvanW has joined #bitcoin-core-dev
 93 2017-04-13T07:28:09  *** AaronvanW has quit IRC
 94 2017-04-13T07:30:46  *** CubicEarth has joined #bitcoin-core-dev
 95 2017-04-13T07:31:14  *** To7 has quit IRC
 96 2017-04-13T07:43:10  *** Guyver2 has joined #bitcoin-core-dev
 97 2017-04-13T08:06:45  *** molz_ has joined #bitcoin-core-dev
 98 2017-04-13T08:10:07  *** mol has quit IRC
 99 2017-04-13T08:12:45  *** vicenteH has joined #bitcoin-core-dev
100 2017-04-13T08:22:59  *** d_t has quit IRC
101 2017-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
102 2017-04-13T08:31:01  <gmaxwell> lol, please only on pulltester which is already vulnerable as heck.
103 2017-04-13T08:31:15  <MarcoFalke> The script could be run in a vm. Though, it comes with an overhead...
104 2017-04-13T08:31:44  <gmaxwell> There are a LOT of vm escape exploits.
105 2017-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
106 2017-04-13T08:32:19  <MarcoFalke> Running it on travis is not enough. travis is just an indicator that should not be trusted
107 2017-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
108 2017-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.
109 2017-04-13T08:32:53  <MarcoFalke> Just need to make sure the script is reviewed on every (ut)ACK
110 2017-04-13T08:33:08  <gmaxwell> sipa: doubt it enough to put a bounty on it though? :P
111 2017-04-13T08:43:21  *** AaronvanW has joined #bitcoin-core-dev
112 2017-04-13T08:45:43  *** AaronvanW has quit IRC
113 2017-04-13T08:46:00  *** AaronvanW has joined #bitcoin-core-dev
114 2017-04-13T08:50:35  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/de01da7cad32...c9ff4f8ee601
115 2017-04-13T08:50:36  <bitcoin-git> bitcoin/master 714e4ad John Newbery: AddToWalletIfInvolvingMe should test pIndex, not posInBlock
116 2017-04-13T08:50:36  <bitcoin-git> bitcoin/master d0cd0bd John Newbery: Make CWallet::SyncTransactions() interface friendlier
117 2017-04-13T08:50:37  <bitcoin-git> bitcoin/master c9ff4f8 Wladimir J. van der Laan: Merge #10186: Remove SYNC_TRANSACTION_NOT_IN_BLOCK magic number...
118 2017-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
119 2017-04-13T08:57:23  *** RubenSomsen has joined #bitcoin-core-dev
120 2017-04-13T09:00:41  *** d_t has joined #bitcoin-core-dev
121 2017-04-13T09:26:04  *** jtimon has joined #bitcoin-core-dev
122 2017-04-13T09:26:16  *** wasi has joined #bitcoin-core-dev
123 2017-04-13T09:37:40  *** vFSgrcFGBJHg has quit IRC
124 2017-04-13T09:38:57  *** harrymm has quit IRC
125 2017-04-13T09:46:44  *** CubicEarth has quit IRC
126 2017-04-13T09:53:57  *** RubenSomsen has quit IRC
127 2017-04-13T09:55:04  *** harrymm has joined #bitcoin-core-dev
128 2017-04-13T10:07:15  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.14: https://github.com/bitcoin/bitcoin/compare/55f641ca194b...06909df179e7
129 2017-04-13T10:07:15  <bitcoin-git> bitcoin/0.14 b7caa30 Suhas Daftuar: Mention dbcache memory changes in 0.14.1 release notes
130 2017-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...
131 2017-04-13T10:08:46  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/c9ff4f8ee601...70f6f56e9dde
132 2017-04-13T10:08:47  <bitcoin-git> bitcoin/master fd44ac1 NicolasDorier: [Wallet] Rename std::pair<const CWalletTx*, unsigned int> to CInputCoin
133 2017-04-13T10:08:48  <bitcoin-git> bitcoin/master e78bc45 NicolasDorier: [Wallet] Decouple CInputCoin from CWalletTx
134 2017-04-13T10:08:48  <bitcoin-git> bitcoin/master f597dcb NicolasDorier: [Wallet] Simplify code using CInputCoin
135 2017-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
136 2017-04-13T10:10:49  *** d_t has quit IRC
137 2017-04-13T10:20:38  *** DarkAngel has joined #bitcoin-core-dev
138 2017-04-13T10:28:49  *** DarkAngel has quit IRC
139 2017-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
140 2017-04-13T10:31:51  *** laurentmt has joined #bitcoin-core-dev
141 2017-04-13T10:32:38  *** laurentmt has quit IRC
142 2017-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
143 2017-04-13T10:43:48  *** RubenSomsen has joined #bitcoin-core-dev
144 2017-04-13T11:34:08  *** To7 has joined #bitcoin-core-dev
145 2017-04-13T11:53:50  *** annanay25 has quit IRC
146 2017-04-13T11:54:00  *** annanay25 has joined #bitcoin-core-dev
147 2017-04-13T11:54:40  *** jtimon has quit IRC
148 2017-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.
149 2017-04-13T12:29:14  *** goksinen has joined #bitcoin-core-dev
150 2017-04-13T12:33:52  *** goksinen has quit IRC
151 2017-04-13T12:34:27  *** Cheeseo has joined #bitcoin-core-dev
152 2017-04-13T12:34:31  *** Cheeseo has quit IRC
153 2017-04-13T12:34:31  *** Cheeseo has joined #bitcoin-core-dev
154 2017-04-13T12:56:44  *** Chris_Stewart_5 has joined #bitcoin-core-dev
155 2017-04-13T13:02:06  *** gielbier has quit IRC
156 2017-04-13T13:06:04  *** gielbier has joined #bitcoin-core-dev
157 2017-04-13T13:14:40  *** Chris_Stewart_5 has quit IRC
158 2017-04-13T13:23:33  *** goksinen has joined #bitcoin-core-dev
159 2017-04-13T13:27:58  *** goksinen has quit IRC
160 2017-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
161 2017-04-13T13:45:20  *** jtimon has joined #bitcoin-core-dev
162 2017-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
163 2017-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
164 2017-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
165 2017-04-13T13:50:32  *** d_t has joined #bitcoin-core-dev
166 2017-04-13T13:55:04  *** d_t has quit IRC
167 2017-04-13T13:59:52  *** d9b4bef9 has quit IRC
168 2017-04-13T14:00:58  *** d9b4bef9 has joined #bitcoin-core-dev
169 2017-04-13T14:01:42  <BlueMatt> cfields: hmm, whats the status of #7522?
170 2017-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
171 2017-04-13T14:03:17  <BlueMatt> luke-jr: are you going to rebase #7289?
172 2017-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
173 2017-04-13T14:06:10  *** goksinen has joined #bitcoin-core-dev
174 2017-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
175 2017-04-13T14:12:27  *** jtimon has quit IRC
176 2017-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
177 2017-04-13T14:15:19  *** Samdney has joined #bitcoin-core-dev
178 2017-04-13T14:15:55  <wumpus> eh, wrong key
179 2017-04-13T14:16:17  <BlueMatt> wumpus: you have a key which types whole sentences? wow!
180 2017-04-13T14:16:20  <BlueMatt> :p
181 2017-04-13T14:17:26  *** dodomojo has joined #bitcoin-core-dev
182 2017-04-13T14:17:45  *** n1ce has joined #bitcoin-core-dev
183 2017-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
184 2017-04-13T14:19:50  *** e4xit has joined #bitcoin-core-dev
185 2017-04-13T14:20:45  <BlueMatt> wumpus: you jest, but thats what fucking mobile phones do :(
186 2017-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 :)
187 2017-04-13T14:21:57  <wumpus> ah yes that's always the first thing I disable
188 2017-04-13T14:22:08  *** dodomojo has quit IRC
189 2017-04-13T14:24:31  <wumpus> jnewbery: yep, the keyboard can almost replace me already :-)
190 2017-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
191 2017-04-13T14:28:02  <michagogo> (I typed the first 4 words of that and selected the rest from the 3 suggestions)
192 2017-04-13T14:32:37  <sipa> wumpus: it's annoying to create PRs against the bitcoin core leveldb repository
193 2017-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)
194 2017-04-13T14:33:00  <sipa> *isn't marked
195 2017-04-13T14:33:11  <sipa> seems the only way to fix that is to delete it and recreate it
196 2017-04-13T14:33:31  <wumpus> that'll lose all the current issues and PRs though
197 2017-04-13T14:33:59  <sipa> true
198 2017-04-13T14:34:06  <sipa> maybe we can contact support to just fix it for us?
199 2017-04-13T14:34:18  <wumpus> yes I think they can reparent repositories
200 2017-04-13T14:36:31  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/70f6f56e9dde...cf8a8b1028d6
201 2017-04-13T14:36:31  <bitcoin-git> bitcoin/master c851be4 Cory Fields: net: define NodeId as an int64_t...
202 2017-04-13T14:36:32  <bitcoin-git> bitcoin/master cf8a8b1 Wladimir J. van der Laan: Merge #10176: net: gracefully handle NodeId wrapping...
203 2017-04-13T14:36:57  *** talmai has joined #bitcoin-core-dev
204 2017-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
205 2017-04-13T14:37:14  <wumpus> are you going to contact support or should I?
206 2017-04-13T14:37:41  <sipa> i can
207 2017-04-13T14:41:34  *** goksinen has quit IRC
208 2017-04-13T14:43:06  *** goksinen has joined #bitcoin-core-dev
209 2017-04-13T14:52:17  *** talmai has quit IRC
210 2017-04-13T15:03:54  *** BCBot_ has joined #bitcoin-core-dev
211 2017-04-13T15:04:27  *** Taek42 has joined #bitcoin-core-dev
212 2017-04-13T15:04:56  *** berndj-blackout has joined #bitcoin-core-dev
213 2017-04-13T15:05:02  *** Samdney has quit IRC
214 2017-04-13T15:05:44  *** crudel has quit IRC
215 2017-04-13T15:06:23  *** harding_ has joined #bitcoin-core-dev
216 2017-04-13T15:07:14  *** cfields_ has joined #bitcoin-core-dev
217 2017-04-13T15:07:54  *** mariorz_ has joined #bitcoin-core-dev
218 2017-04-13T15:08:16  *** warren_ has joined #bitcoin-core-dev
219 2017-04-13T15:08:33  *** Pat_Boy has joined #bitcoin-core-dev
220 2017-04-13T15:08:35  *** jnewbery has quit IRC
221 2017-04-13T15:09:39  *** ryan-c- has joined #bitcoin-core-dev
222 2017-04-13T15:09:53  *** musalbas- has joined #bitcoin-core-dev
223 2017-04-13T15:09:56  *** NielsvG` has joined #bitcoin-core-dev
224 2017-04-13T15:10:49  *** wasi has quit IRC
225 2017-04-13T15:10:49  *** arubi has quit IRC
226 2017-04-13T15:10:49  *** afk11 has quit IRC
227 2017-04-13T15:10:50  *** cfields has quit IRC
228 2017-04-13T15:10:51  *** mariorz has quit IRC
229 2017-04-13T15:10:52  *** harding has quit IRC
230 2017-04-13T15:10:52  *** NielsvG has quit IRC
231 2017-04-13T15:10:52  *** musalbas has quit IRC
232 2017-04-13T15:10:52  *** luke-jr has quit IRC
233 2017-04-13T15:10:53  *** tunafizz has quit IRC
234 2017-04-13T15:10:53  *** ryan-c has quit IRC
235 2017-04-13T15:10:54  *** BCBot has quit IRC
236 2017-04-13T15:10:54  *** Soligor has quit IRC
237 2017-04-13T15:10:54  *** berndj has quit IRC
238 2017-04-13T15:10:56  *** murr4y has quit IRC
239 2017-04-13T15:10:56  *** PatBoy has quit IRC
240 2017-04-13T15:10:58  *** nsh has quit IRC
241 2017-04-13T15:10:58  *** ensign_ has quit IRC
242 2017-04-13T15:10:58  *** warren has quit IRC
243 2017-04-13T15:10:59  *** Taek has quit IRC
244 2017-04-13T15:11:00  *** berndj-blackout is now known as berndj
245 2017-04-13T15:11:00  *** Pat_Boy is now known as PatBoy
246 2017-04-13T15:11:01  *** musalbas- is now known as musalbas
247 2017-04-13T15:11:40  *** luke-jr has joined #bitcoin-core-dev
248 2017-04-13T15:11:43  *** tunafizz has joined #bitcoin-core-dev
249 2017-04-13T15:11:46  *** murr4y has joined #bitcoin-core-dev
250 2017-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
251 2017-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
252 2017-04-13T15:15:21  *** nsh has joined #bitcoin-core-dev
253 2017-04-13T15:15:51  *** ensign has joined #bitcoin-core-dev
254 2017-04-13T15:16:17  *** mariorz_ is now known as mariorz
255 2017-04-13T15:18:44  <wumpus> sdaftuar: thanks
256 2017-04-13T15:22:48  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/cf8a8b1028d6...eab00d96dfe9
257 2017-04-13T15:22:49  <bitcoin-git> bitcoin/master efc135f Matt Corallo: Use cached [compact] blocks to respond to getdata messages
258 2017-04-13T15:22:49  <bitcoin-git> bitcoin/master c47f5b7 Matt Corallo: Cache witness-enabled state with recent-compact-block-cache
259 2017-04-13T15:22:50  <bitcoin-git> bitcoin/master b49ad44 Matt Corallo: Add comment about cs_most_recent_block coverage
260 2017-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
261 2017-04-13T15:24:26  * BlueMatt notes something similar for #9942 and #9480
262 2017-04-13T15:24:28  <gribble> https://github.com/bitcoin/bitcoin/issues/9942 | Refactor CBlockPolicyEstimator by morcos · Pull Request #9942 · bitcoin/bitcoin · GitHub
263 2017-04-13T15:24:29  <gribble> https://github.com/bitcoin/bitcoin/issues/9480 | De-duplicate SignatureCacheHasher by JeremyRubin · Pull Request #9480 · bitcoin/bitcoin · GitHub
264 2017-04-13T15:25:09  *** Soligor has joined #bitcoin-core-dev
265 2017-04-13T15:30:23  *** aantonop has joined #bitcoin-core-dev
266 2017-04-13T15:33:49  *** afk11 has joined #bitcoin-core-dev
267 2017-04-13T15:33:59  *** arubi has joined #bitcoin-core-dev
268 2017-04-13T15:34:42  *** Samdney has joined #bitcoin-core-dev
269 2017-04-13T15:41:05  *** talmai has joined #bitcoin-core-dev
270 2017-04-13T15:43:44  *** goksinen_ has joined #bitcoin-core-dev
271 2017-04-13T15:44:15  *** goksinen has quit IRC
272 2017-04-13T15:44:22  *** jnewbery has joined #bitcoin-core-dev
273 2017-04-13T15:48:03  *** goksinen_ has quit IRC
274 2017-04-13T15:50:46  *** afk11 has quit IRC
275 2017-04-13T15:50:46  *** arubi has quit IRC
276 2017-04-13T15:54:07  *** laurentmt has joined #bitcoin-core-dev
277 2017-04-13T15:54:34  *** laurentmt has quit IRC
278 2017-04-13T15:55:20  *** abpa has joined #bitcoin-core-dev
279 2017-04-13T16:00:51  *** goksinen has joined #bitcoin-core-dev
280 2017-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?
281 2017-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
282 2017-04-13T16:10:52  <sipa> sdaftuar: hmm
283 2017-04-13T16:11:18  *** talmai has quit IRC
284 2017-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
285 2017-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.
286 2017-04-13T16:13:20  <sipa> sdaftuar: but that would mean that the custom cleanup function is also not called?
287 2017-04-13T16:13:29  <sdaftuar> sipa: that was my guess, but i wasn't sure!
288 2017-04-13T16:14:04  <sipa> i seem to recall that fixed things
289 2017-04-13T16:14:19  *** aantonop has quit IRC
290 2017-04-13T16:18:59  *** belcher has quit IRC
291 2017-04-13T16:28:54  *** d_t has joined #bitcoin-core-dev
292 2017-04-13T16:28:54  *** goksinen has quit IRC
293 2017-04-13T16:29:14  *** mol has joined #bitcoin-core-dev
294 2017-04-13T16:29:37  *** RubenSomsen has quit IRC
295 2017-04-13T16:29:40  *** Victor_sueca has joined #bitcoin-core-dev
296 2017-04-13T16:30:00  *** laurentmt has joined #bitcoin-core-dev
297 2017-04-13T16:31:38  *** Taek has joined #bitcoin-core-dev
298 2017-04-13T16:32:08  *** Taek42 has quit IRC
299 2017-04-13T16:32:08  *** Naphex has quit IRC
300 2017-04-13T16:32:19  *** Naphex has joined #bitcoin-core-dev
301 2017-04-13T16:32:20  *** molz_ has quit IRC
302 2017-04-13T16:32:30  *** Alina-malina has quit IRC
303 2017-04-13T16:32:36  *** Victorsueca has quit IRC
304 2017-04-13T16:32:57  *** Olen2 has joined #bitcoin-core-dev
305 2017-04-13T16:33:19  *** Alina-malina has joined #bitcoin-core-dev
306 2017-04-13T16:33:34  *** RubenSomsen has joined #bitcoin-core-dev
307 2017-04-13T16:36:04  *** Alina-malina has quit IRC
308 2017-04-13T16:36:04  *** Alina-malina has joined #bitcoin-core-dev
309 2017-04-13T16:37:39  *** Olen2 has quit IRC
310 2017-04-13T16:37:48  *** goksinen has joined #bitcoin-core-dev
311 2017-04-13T16:38:29  *** aantonop has joined #bitcoin-core-dev
312 2017-04-13T16:41:19  *** d_t has quit IRC
313 2017-04-13T16:41:50  *** Cortney has joined #bitcoin-core-dev
314 2017-04-13T16:42:52  *** belcher has joined #bitcoin-core-dev
315 2017-04-13T16:43:15  *** belcher is now known as Guest66310
316 2017-04-13T16:52:02  *** Guest66310 has quit IRC
317 2017-04-13T16:52:23  *** belcher_ has joined #bitcoin-core-dev
318 2017-04-13T16:52:46  *** belcher_ is now known as Guest38408
319 2017-04-13T16:54:37  *** belcher has joined #bitcoin-core-dev
320 2017-04-13T16:54:45  *** belcher has quit IRC
321 2017-04-13T16:57:15  *** jtimon has joined #bitcoin-core-dev
322 2017-04-13T17:13:38  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/eab00d96dfe9...b7365f0545b1
323 2017-04-13T17:13:38  <bitcoin-git> bitcoin/master f9c8807 Jeremy Rubin: Deduplicate SignatureCacheHasher...
324 2017-04-13T17:13:38  <bitcoin-git> bitcoin/master b7365f0 Pieter Wuille: Merge #9480: De-duplicate SignatureCacheHasher...
325 2017-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
326 2017-04-13T17:14:54  *** btcdrak has quit IRC
327 2017-04-13T17:15:32  *** Cheeseo has quit IRC
328 2017-04-13T17:23:31  *** afk11 has joined #bitcoin-core-dev
329 2017-04-13T17:24:32  *** arubi has joined #bitcoin-core-dev
330 2017-04-13T17:33:40  <cfields_> sipa: for leveldb merge, whenever it's needed: https://github.com/theuni/bitcoin/commit/2cb7dda13884e44105f33c16e7e2c1a9aed46295
331 2017-04-13T17:35:47  <cfields_> BlueMatt: hmm, i thought 7522 was merged a long time ago. Having a look.
332 2017-04-13T17:40:13  *** talmai has joined #bitcoin-core-dev
333 2017-04-13T17:40:52  *** jnewbery has quit IRC
334 2017-04-13T17:41:09  *** jnewbery has joined #bitcoin-core-dev
335 2017-04-13T17:47:56  *** CubicEarth has joined #bitcoin-core-dev
336 2017-04-13T17:50:23  *** e4xit has quit IRC
337 2017-04-13T17:53:57  *** btcdrak has joined #bitcoin-core-dev
338 2017-04-13T17:57:17  *** RubenSomsen has quit IRC
339 2017-04-13T17:58:42  *** belcher has joined #bitcoin-core-dev
340 2017-04-13T18:01:08  *** aantonop has quit IRC
341 2017-04-13T18:03:07  *** d_t has joined #bitcoin-core-dev
342 2017-04-13T18:04:52  *** aantonop has joined #bitcoin-core-dev
343 2017-04-13T18:06:44  <luke-jr> hm, thought I was late; am I early?
344 2017-04-13T18:07:32  <gmaxwell> you are early
345 2017-04-13T18:07:45  <luke-jr> cool
346 2017-04-13T18:08:53  *** e4xit has joined #bitcoin-core-dev
347 2017-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.
348 2017-04-13T18:13:24  <gmaxwell> aantonop: oh no problem, people should have just ignored him. :) trolls show up all the time.
349 2017-04-13T18:15:34  *** limpkin has quit IRC
350 2017-04-13T18:16:09  *** limpkin has joined #bitcoin-core-dev
351 2017-04-13T18:19:57  *** talmai has quit IRC
352 2017-04-13T18:25:35  *** aantonop has quit IRC
353 2017-04-13T18:30:30  *** spudowiar has joined #bitcoin-core-dev
354 2017-04-13T18:31:04  <spudowiar> Is there a good way to get a transaction input and find the BIP32 derivation path?
355 2017-04-13T18:31:20  <spudowiar> I don't think the keystore stores BIP32 derivation information
356 2017-04-13T18:33:00  <luke-jr> pretty sure it does..
357 2017-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
358 2017-04-13T18:34:10  *** Ylbam has quit IRC
359 2017-04-13T18:37:30  <sipa> CKeyMetaData or something stores ot
360 2017-04-13T18:37:32  <sipa> *it
361 2017-04-13T18:39:37  *** goksinen has quit IRC
362 2017-04-13T18:39:58  <spudowiar> sipa: How do I get one of those from a public key?
363 2017-04-13T18:45:15  *** goksinen has joined #bitcoin-core-dev
364 2017-04-13T19:00:02  <wumpus> meeting time?
365 2017-04-13T19:00:11  <jonasschnelli> Yes. Hi all.
366 2017-04-13T19:00:17  <wumpus> #startmeeting
367 2017-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.
368 2017-04-13T19:00:17  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
369 2017-04-13T19:00:25  <morcos> roger
370 2017-04-13T19:00:28  <sdaftuar> hello
371 2017-04-13T19:00:30  <CodeShark> hi
372 2017-04-13T19:00:32  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure blue
373 2017-04-13T19:00:33  <wumpus> matt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
374 2017-04-13T19:00:38  <kanzure> hi.
375 2017-04-13T19:00:39  <wumpus> hello
376 2017-04-13T19:00:45  <cfields_> hi
377 2017-04-13T19:00:50  <instagibbs> hi
378 2017-04-13T19:00:55  <phantomcircuit> hi
379 2017-04-13T19:00:55  <wumpus> topics?
380 2017-04-13T19:01:02  <gmaxwell> Hi!
381 2017-04-13T19:01:13  <wumpus> #topic 0.14.1
382 2017-04-13T19:01:20  <wumpus> anyone had report of bugs with the rc1?
383 2017-04-13T19:01:28  <cfields_> topic suggestion (after 0.14.1): scripted-diffs
384 2017-04-13T19:01:32  <gmaxwell> Push the button?
385 2017-04-13T19:01:47  <gmaxwell> wumpus: you know that the bug reports only come after releasing it. :P
386 2017-04-13T19:01:55  <petertodd> hi
387 2017-04-13T19:02:12  <wumpus> gmaxwell: the serious ones, yes :p
388 2017-04-13T19:02:25  * cfields_ scrambles to backport 10176
389 2017-04-13T19:02:42  <wumpus> but apparently no one heard anything, so time to tag -final
390 2017-04-13T19:03:26  <cfields_> wumpus: wait for ^^ ? doing now.
391 2017-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
392 2017-04-13T19:05:15  <gmaxwell> can talk about post meeting, certantly nothing but that is in the air.
393 2017-04-13T19:05:40  <cfields_> ok
394 2017-04-13T19:05:40  <wumpus> if you think it's really important to do we can do another rc, no problem
395 2017-04-13T19:06:26  <gmaxwell> I really don't want to delay 0.14.1 further.
396 2017-04-13T19:06:36  <cfields_> wumpus: it was more of a since-we're-releasing-anyway kind of thing
397 2017-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
398 2017-04-13T19:07:11  <wumpus> I agree it's something that should be backported to the 0.14 branch
399 2017-04-13T19:07:25  <morcos> no opinion either way here
400 2017-04-13T19:07:55  <wumpus> ok
401 2017-04-13T19:07:58  <BlueMatt> wumpus: I think we should do it in 0.14
402 2017-04-13T19:08:00  <BlueMatt> .1
403 2017-04-13T19:08:10  <BlueMatt> because its free, we're already doing 0.14.1 and delaying 1 week isnt gonna kill us
404 2017-04-13T19:08:42  *** BlueMatt_ has joined #bitcoin-core-dev
405 2017-04-13T19:08:43  <luke-jr> cfields_: new fixes = new rc required
406 2017-04-13T19:08:49  <luke-jr> so not worth it in that scenario
407 2017-04-13T19:09:26  <BlueMatt_> But delaying 1 week isn't too bad
408 2017-04-13T19:09:40  <BlueMatt> wait, who is BlueMatt_ ?
409 2017-04-13T19:09:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
410 2017-04-13T19:10:04  * wumpus confused
411 2017-04-13T19:10:19  *** Dizzle has joined #bitcoin-core-dev
412 2017-04-13T19:10:23  * BlueMatt_ confused
413 2017-04-13T19:10:24  * BlueMatt has no idea who BlueMatt_ is
414 2017-04-13T19:10:31  <instagibbs> :/
415 2017-04-13T19:10:31  * BlueMatt_ has no idea who BlueMatt is
416 2017-04-13T19:10:47  <kanzure> different timeline, carry on.
417 2017-04-13T19:10:52  <luke-jr> whois says it's Matt Corallo
418 2017-04-13T19:11:03  <jcorgan> digital ocean ip
419 2017-04-13T19:11:12  <BlueMatt> not me
420 2017-04-13T19:11:19  * BlueMatt has no digitalocean-lon vpses
421 2017-04-13T19:11:42  <gmaxwell> wumpus: shoot the T1000 (BlueMatt_) and lets move on.
422 2017-04-13T19:12:01  <sipa> BlueMatt_: this statement is false
423 2017-04-13T19:12:09  *** ChanServ sets mode: +o wumpus
424 2017-04-13T19:12:12  <spudowiar> gmaxwell: I think that's the fake aantonop IP
425 2017-04-13T19:12:27  <luke-jr> sipa: :D
426 2017-04-13T19:12:37  <spudowiar> 2017-04-11 21:37:35 -- Mode #bitcoin [+b *!*@178.62.68.75] by gmaxwell
427 2017-04-13T19:12:41  *** wumpus sets mode: +b *!*@178.62.68.7
428 2017-04-13T19:12:45  <gmaxwell> We've got lots more to discuss.
429 2017-04-13T19:12:50  <BlueMatt> yes, lets move on
430 2017-04-13T19:12:55  *** BlueMatt_ was kicked by wumpus (Kindergarten is elsewhere!)
431 2017-04-13T19:13:04  <wumpus> so have we decided anything?
432 2017-04-13T19:13:11  <sipa> 0.14.1 yay
433 2017-04-13T19:13:56  <wumpus> #topic scripted-diffs
434 2017-04-13T19:14:15  <cfields_> yes, let's finish discussing after the meeting
435 2017-04-13T19:14:45  <cfields_> ok, for reference: #10189
436 2017-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
437 2017-04-13T19:14:46  <luke-jr> mv meeting/* after-meeting/
438 2017-04-13T19:15:01  <wumpus> haven't had a time to look at that one yet
439 2017-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
440 2017-04-13T19:15:48  <cfields_> if they don't transform the old commit to the new one exactly, travis will reject
441 2017-04-13T19:15:58  <cfields_> the aim is to make those kinds of changes easier to review
442 2017-04-13T19:16:03  <BlueMatt> is ther emuch to discuss? I think its a good idea
443 2017-04-13T19:16:04  *** stoner19 has joined #bitcoin-core-dev
444 2017-04-13T19:16:05  *** tw2006 has joined #bitcoin-core-dev
445 2017-04-13T19:16:17  <cfields_> example: https://github.com/bitcoin/bitcoin/pull/10189/commits/d04198309e7e9b21de1604cc4321148b37a46347
446 2017-04-13T19:16:20  <luke-jr> IMO we shouldn't trust Travis
447 2017-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.
448 2017-04-13T19:16:34  <wumpus> would that execute arbitrary scripts in commit messages?
449 2017-04-13T19:16:36  <luke-jr> which is basicaly what you're suggesting)
450 2017-04-13T19:16:37  <cfields_> BlueMatt: well, you brought up a good point about the safety of random scripts
451 2017-04-13T19:16:47  <wumpus> seems kind of dangerous, I certainly wouldn't want to run that locally
452 2017-04-13T19:16:50  <cfields_> so i thought it might be worth discussing possibly constraining. Say to sed or so.
453 2017-04-13T19:17:00  <BlueMatt> gmaxwell: there are already two examplesa
454 2017-04-13T19:17:03  <wumpus> I'm really careful what scripts I run, and wouldn't want anything to be run automatically
455 2017-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
456 2017-04-13T19:17:15  <spudowiar> What sort of damage can be done with, say, sed or awk?
457 2017-04-13T19:17:16  <BlueMatt> to make it much more obvious
458 2017-04-13T19:17:25  *** tw2006 has quit IRC
459 2017-04-13T19:17:28  <petertodd> wumpus: granted, if you ever compile bitcoin you're running stuff within the repo anyway
460 2017-04-13T19:17:28  <gmaxwell> spudowiar: arbritary damage.
461 2017-04-13T19:17:31  <spudowiar> I don't think you can do much with sed, not too sure about awk
462 2017-04-13T19:17:42  <spudowiar> gmaxwell: I mean dangerous code execution
463 2017-04-13T19:17:47  <cfields_> wumpus: sure, agreed. Travis can run them, and they can ofc be run manually as well.
464 2017-04-13T19:17:51  <sipa> try applying sed to /etc/init.d files
465 2017-04-13T19:17:57  <BlueMatt> see-also #10193
466 2017-04-13T19:17:57  *** tw2006 has joined #bitcoin-core-dev
467 2017-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
468 2017-04-13T19:18:01  <BlueMatt> (which is an example)
469 2017-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
470 2017-04-13T19:18:14  <wumpus> just make it create a ~/.bashrc, runs next time
471 2017-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.
472 2017-04-13T19:18:27  <wumpus> I'd really prefer not to do this
473 2017-04-13T19:18:54  <luke-jr> I don't see the value in a Travis-"mostly" thing.
474 2017-04-13T19:18:55  <spudowiar> What are the benefits?
475 2017-04-13T19:18:56  <gmaxwell> I guess the reason to just not commit the script is that they're one time things?
476 2017-04-13T19:18:57  <cfields_> gmaxwell: that was my intention, yes.
477 2017-04-13T19:19:05  <luke-jr> it gives a false sense of review
478 2017-04-13T19:19:09  <wumpus> if there's a script then reviewers can manually verify it too, after reviewing the script
479 2017-04-13T19:19:13  <BlueMatt> gmaxwell: yes, if they're one-time things its annoying to commit them, also annoying to lose them
480 2017-04-13T19:19:35  <sipa> when would these scripts be ru
481 2017-04-13T19:19:37  <sipa> n
482 2017-04-13T19:20:02  <cfields_> yes, i got the idea from bac5c9cf643e9333479ac667426d0b70f8f3aa7f
483 2017-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
484 2017-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.
485 2017-04-13T19:20:23  <cfields_> https://github.com/bitcoin/bitcoin/commit/bac5c9cf643e9333479ac667426d0b70f8f3aa7f
486 2017-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.
487 2017-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
488 2017-04-13T19:21:00  <luke-jr> gmaxwell: as long as reviewers do test it, and don't trust Travis
489 2017-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
490 2017-04-13T19:21:03  <spudowiar> You could create format like `*.cpp *.h | s/boost::filesystem/fs/g`
491 2017-04-13T19:22:25  <sipa> spudowiar: little bobby tables will haunt you
492 2017-04-13T19:23:01  <luke-jr> lol
493 2017-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
494 2017-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?
495 2017-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 :)
496 2017-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
497 2017-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?
498 2017-04-13T19:23:53  <petertodd> cfields_: that's true for your local dev setup too
499 2017-04-13T19:24:02  <wumpus> I don't think it's worth the effort, no
500 2017-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: "
501 2017-04-13T19:24:19  <BlueMatt> or something
502 2017-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.
503 2017-04-13T19:24:24  <BlueMatt> then its obvious from the first line of the commit
504 2017-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.
505 2017-04-13T19:24:26  <BlueMatt> and you will see it
506 2017-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
507 2017-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).
508 2017-04-13T19:25:32  <gmaxwell> otherwise I'd argue there is no change.
509 2017-04-13T19:25:45  <cfields_> gmaxwell: but it wouldn't touch anything in that case. You'd have to actively run it.
510 2017-04-13T19:25:51  <wumpus> petertodd: you can, but changes to the makefile would be apparent to me at least
511 2017-04-13T19:25:51  <petertodd> gmaxwell: so long as devs never have git hooks that run this automatically I think we're covered
512 2017-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?
513 2017-04-13T19:26:08  <petertodd> wumpus: right, but see my reply to gmaxwell above
514 2017-04-13T19:26:08  <gmaxwell> petertodd: yea, I'm not too concerned.
515 2017-04-13T19:26:11  <wumpus> yes, as long as it's not executed automatically outside of travis it's fine
516 2017-04-13T19:26:21  <wumpus> I don't care what is done in travis, that is already somebody else's sandbox
517 2017-04-13T19:26:24  <cfields_> yes, that's the case as-is.
518 2017-04-13T19:26:26  <petertodd> wumpus: +1
519 2017-04-13T19:26:28  <gmaxwell> oh actually too spudowiar's suggestion is good  unless run with --force the script could ask for confirmation.
520 2017-04-13T19:26:30  <cfields_> nothing is touched locally.
521 2017-04-13T19:26:44  *** goksinen has quit IRC
522 2017-04-13T19:26:50  <wumpus> my point was just that I just don't want e.g. github_merge.py to execute it automatically
523 2017-04-13T19:26:54  <wumpus> great
524 2017-04-13T19:27:08  <petertodd> wumpus: yup, that'd be a bit crazy :)
525 2017-04-13T19:27:09  <cfields_> wait, please back up, I'm not sure if there's a communication breakdown here.
526 2017-04-13T19:27:24  *** mol has quit IRC
527 2017-04-13T19:27:25  *** Samdney has quit IRC
528 2017-04-13T19:27:47  * sipa makes backup
529 2017-04-13T19:27:49  <cfields_> as-is, this is travis-only. Nothing runs automatically anywhere but there.
530 2017-04-13T19:27:55  <wumpus> cfields_: as said I haven't seen the actual PR, just rumors from this channel
531 2017-04-13T19:28:10  <spudowiar> Well, Travis can run it with --force, github_merge.py can run it without --force?
532 2017-04-13T19:28:14  <wumpus> yes makes sense to me then cfields_
533 2017-04-13T19:28:25  <spudowiar> Without --force, no actual commands are run
534 2017-04-13T19:28:29  <spudowiar> Unless you interactively say so
535 2017-04-13T19:28:34  <gmaxwell> spudowiar: no need to make merge run it at all. just an extra review step available.
536 2017-04-13T19:28:35  <cfields_> spudowiar: there's nothing to run "it".
537 2017-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
538 2017-04-13T19:29:02  <wumpus> (I run that on the machine that has the gpg key, so I'm paranoid about it)
539 2017-04-13T19:29:03  *** moli_ has joined #bitcoin-core-dev
540 2017-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.
541 2017-04-13T19:29:12  <spudowiar> cfields_: I'm talking about a hypothetical script
542 2017-04-13T19:29:18  <spudowiar> wumpus: Buy a PGP smartcard :)
543 2017-04-13T19:29:47  <petertodd> spudowiar: adversary still can cause the PGP smartcard to sign something you didn't aprove
544 2017-04-13T19:29:50  <wumpus> ok. seems a communication breakdown here.
545 2017-04-13T19:29:58  <wumpus> let's just review the PR, and talk about it again next week
546 2017-04-13T19:30:01  <gmaxwell> okay
547 2017-04-13T19:30:03  <cfields_> heh, yes please :)
548 2017-04-13T19:30:12  <sdaftuar> +1!
549 2017-04-13T19:30:17  <wumpus> #action review #10193
550 2017-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
551 2017-04-13T19:30:20  <morcos> good thing our trolling coordination doesn't suffer from these communication problems
552 2017-04-13T19:30:23  <wumpus> other topics?
553 2017-04-13T19:31:11  <wumpus> #action review #10189
554 2017-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
555 2017-04-13T19:31:19  <sdaftuar> topic suggestion: goals for 0.15
556 2017-04-13T19:31:40  <cfields_> good one.
557 2017-04-13T19:31:42  <BlueMatt> ok, so ryanofsky wanted to talk about multi-process, too, i think
558 2017-04-13T19:31:48  <BlueMatt> and, ofc, pr review targets for the week
559 2017-04-13T19:31:49  <BlueMatt> :)
560 2017-04-13T19:31:56  <wumpus> #topic goals for 0.15
561 2017-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 :)"
562 2017-04-13T19:32:53  <gmaxwell> Per-txo dbcache and non-atomic flushing please...
563 2017-04-13T19:32:58  <wumpus> agree with BlueMatt, though people could state what their goals for 0.15 are
564 2017-04-13T19:33:01  <jonasschnelli> My goals for 0.15 are: HD auto-restore, Qt feebumper and multiwallet
565 2017-04-13T19:33:15  <spudowiar> Watch only HD wallets sound good for 0.15 :)
566 2017-04-13T19:33:20  <gmaxwell> and multiwallet.
567 2017-04-13T19:33:21  <jonasschnelli> Oh.. yes. That!
568 2017-04-13T19:33:26  <sdaftuar> gmaxwell: agreed, also i think it would be good to get the new fee estimation in place
569 2017-04-13T19:33:26  <jonasschnelli> (hd watch only)
570 2017-04-13T19:33:40  <BlueMatt> multithreaded net_processing (and wallet) with CValidationInterface generating callbacks into it
571 2017-04-13T19:33:54  <BlueMatt> ie disconnecting validation and everything else with CValidationInterface in betwene :)
572 2017-04-13T19:34:02  <sipa> when is 0.15 feature freeze?
573 2017-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?
574 2017-04-13T19:34:07  <achow101> is replacing accounts with labels planned for 0.15?
575 2017-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.
576 2017-04-13T19:34:20  <wumpus> luke-jr: it's kind of blocking other things right now I think
577 2017-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.
578 2017-04-13T19:34:44  <luke-jr> wumpus: when I get home
579 2017-04-13T19:34:45  <BlueMatt> I do NOT think its little perceived gain
580 2017-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)
581 2017-04-13T19:34:58  <wumpus> #link Release schedule for 0.15.0 https://github.com/bitcoin/bitcoin/issues/9961
582 2017-04-13T19:35:00  <sipa> cfields_: woooh!
583 2017-04-13T19:35:05  *** dgenr8_ has joined #bitcoin-core-dev
584 2017-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
585 2017-04-13T19:35:08  <wumpus> yes libevent please
586 2017-04-13T19:35:09  <BlueMatt> and bitcoin core is a big part of that
587 2017-04-13T19:35:10  <morcos> gmaxwell: heh... it's more art than science i think
588 2017-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.
589 2017-04-13T19:35:24  <wumpus> I'd also really like to get the UNIX p2p/rpc stuff in
590 2017-04-13T19:35:35  <jonasschnelli> gmaxwell: can you explain "a lot"?
591 2017-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
592 2017-04-13T19:36:07  *** Chris_Stewart_5 has quit IRC
593 2017-04-13T19:36:07  <luke-jr> wumpus: (tomorrow)
594 2017-04-13T19:36:09  <wumpus> it's all very low-risk and shouldn't affect non-unix-socket use cases
595 2017-04-13T19:36:11  <sdaftuar> BlueMatt: I also think the ability to return non-conservative (ie, lower) fee estimates is important
596 2017-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.
597 2017-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
598 2017-04-13T19:36:18  <wumpus> luke-jr: thanks
599 2017-04-13T19:36:22  <sipa> i want pertxoutcache, remove memory peak at flushing, better dbcache eviction policy, ...
600 2017-04-13T19:36:44  <jonasschnelli> gmaxwell: Yes. I'm working on the recover (one of my 0.15 goals: "HD auto-restore")
601 2017-04-13T19:36:52  <BlueMatt> OKOK, so review priorities towards all these amazing things? whats up this week :)
602 2017-04-13T19:36:54  <sipa> oh, and segwit activated? pretty please?
603 2017-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.
604 2017-04-13T19:37:00  <BlueMatt> sipa: lol
605 2017-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.
606 2017-04-13T19:37:22  * BlueMatt registers #10179
607 2017-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
608 2017-04-13T19:37:27  <wumpus> cfields_: the RPC pull (the first one) shouldn't collide
609 2017-04-13T19:37:28  <gmaxwell> sipa: would likely help to get 0.14.1 out...
610 2017-04-13T19:37:29  *** talmai has joined #bitcoin-core-dev
611 2017-04-13T19:37:39  <wumpus> cfields_: I'm fine with including that one only for now, it's most of the code
612 2017-04-13T19:37:40  <sipa> gmaxwell: ack
613 2017-04-13T19:37:46  <cfields_> wumpus: no, the other. But it's a non-issue either way.
614 2017-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
615 2017-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
616 2017-04-13T19:38:31  <wumpus> cfields_: though it depends on the time frame I guess
617 2017-04-13T19:38:40  <gmaxwell> morcos: I think that would be really helpful.
618 2017-04-13T19:38:46  <cfields_> sounds good.
619 2017-04-13T19:38:59  <gmaxwell> morcos: Also for general review, I've lost track of the overall design of the estimator.
620 2017-04-13T19:39:11  <sipa> morcos: i would like to see a 1-page document explaining what it tries to accomplish
621 2017-04-13T19:39:20  <gmaxwell> morcos: in any case I strongly support improving it, the current one is dumb on weekends.
622 2017-04-13T19:39:25  <cfields_> sipa: let's activate segwit after the meeting. We only have 20 min left :p
623 2017-04-13T19:39:32  <gmaxwell> cfields_: ack
624 2017-04-13T19:39:37  <wumpus> #action activate segwit
625 2017-04-13T19:39:41  <morcos> sipa: ok
626 2017-04-13T19:39:45  <gmaxwell> jinx
627 2017-04-13T19:39:59  <sipa> (i have no clue how the estimator works, or ever worked, beside "something with buckets")
628 2017-04-13T19:40:04  <morcos> gmaxwell: yes this is much better on weekends (optionally)
629 2017-04-13T19:40:06  <instagibbs> ack on explanation, I was asking really dumb questions about it yesterday, may help
630 2017-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.
631 2017-04-13T19:41:01  <BlueMatt> gmaxwell: I'm waiting for non-atomic to support disconnects
632 2017-04-13T19:41:05  <BlueMatt> then I'll re-review :)
633 2017-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
634 2017-04-13T19:42:00  <sipa> gmaxwell: agree, it needs to support reorgs
635 2017-04-13T19:42:08  <sipa> also... even harder to test
636 2017-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 ?
637 2017-04-13T19:42:33  <gmaxwell> sipa: hm? with the current code we finish the flush all at once.
638 2017-04-13T19:42:50  <gmaxwell> needing to support reorgs is only an issue with the changes we discussed post per-txo.
639 2017-04-13T19:43:20  <MarcoFalke> wumpus: The pull jnewbery just opened could go into 0.14.1 if we do another rc anyway
640 2017-04-13T19:43:32  <sipa> gmaxwell: a crash in the middle a flush after a disconnect cannot be recovered from with the current code
641 2017-04-13T19:43:32  <wumpus> MarcoFalke: yep
642 2017-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.
643 2017-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
644 2017-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
645 2017-04-13T19:43:58  <gmaxwell> sipa: gotcha.
646 2017-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.
647 2017-04-13T19:44:33  <wumpus> jnewbery: makes sense, it's still fairly safe to rename named arguments now, but they should be backported
648 2017-04-13T19:45:12  *** d_t has quit IRC
649 2017-04-13T19:45:15  <gmaxwell> cfields_: the overall changes to the dbcache are too burdensom to realisitcally support a version that can support both.
650 2017-04-13T19:45:35  <sipa> i still wish for non-atomic flush in 0.14.2
651 2017-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?
652 2017-04-13T19:45:41  * sipa keeps dreaming
653 2017-04-13T19:46:02  <gmaxwell> cfields_: yes, that would be more reasonable than getting a generic corruption message.
654 2017-04-13T19:46:10  <wumpus> cfields_: yes, something for 0.14.2
655 2017-04-13T19:46:12  <sipa> cfields_: we could add a change in 0.14 that would make explicit downgrade easy
656 2017-04-13T19:46:13  <morcos> sipa: too big a change
657 2017-04-13T19:46:15  *** gmaxwell_ has joined #bitcoin-core-dev
658 2017-04-13T19:46:18  <wumpus> no more new things for 0.14.1 please
659 2017-04-13T19:46:19  <cfields_> .2, ignore for .1.
660 2017-04-13T19:46:32  <gmaxwell> "Your database format is from the future, so sad for you. Please run reindex."
661 2017-04-13T19:46:35  <cfields_> wumpus: sorry, realized my mistake too late :)
662 2017-04-13T19:46:38  *** gmaxwell_ is now known as Guest93648
663 2017-04-13T19:46:47  <sipa> morcos: i said wish, not demand :)
664 2017-04-13T19:47:03  *** Guest93648 has left #bitcoin-core-dev
665 2017-04-13T19:47:24  <sdaftuar> sipa: feature freeze for 0.15 is 2017-07-16
666 2017-04-13T19:47:30  <luke-jr> sh AI sipa in 0.14.2
667 2017-04-13T19:47:44  <gmaxwell> T1000 is back.
668 2017-04-13T19:47:45  <sipa> sdaftuar: yeah, i saw, wumpus gave link
669 2017-04-13T19:47:58  *** luke-jr_ has joined #bitcoin-core-dev
670 2017-04-13T19:48:06  <luke-jr> I wish*
671 2017-04-13T19:48:34  <gmaxwell>  /mode #bitcoin-dev +b *!*@178.62.68.75
672 2017-04-13T19:48:39  <luke-jr_> :(
673 2017-04-13T19:48:52  <luke-jr_> I can't think of a good nick :(
674 2017-04-13T19:49:00  <wumpus> apparently we need to make meetings invite-to-speak only
675 2017-04-13T19:49:17  <wumpus> stupid childish trolls are why we can't have nice things
676 2017-04-13T19:49:17  <kanzure> you used wrong ip address last time
677 2017-04-13T19:49:36  <spudowiar> wumpus: If you did that, I wouldn't be able to participate :(
678 2017-04-13T19:49:40  <gmaxwell> wumpus: lets discuss in the meta meeting. :P
679 2017-04-13T19:49:45  <luke-jr_> spudowiar: Well, no one gives a fuck
680 2017-04-13T19:49:52  <cfields_> kanzure: no need, they're easy to spot. just ignore.
681 2017-04-13T19:49:56  <gmaxwell> (after the meeting)
682 2017-04-13T19:50:01  *** wumpus sets mode: +b *!*@178.62.68.75
683 2017-04-13T19:50:10  *** luke-jr_ was kicked by wumpus (Kindergarten is elsewhere!)
684 2017-04-13T19:50:19  <gmaxwell> in any case, lots of good things in flight. I think progress for 15 is good right now.
685 2017-04-13T19:50:26  <BlueMatt> ok, so 10 minutes left
686 2017-04-13T19:50:28  <BlueMatt> ryanofsky: ?
687 2017-04-13T19:50:33  <BlueMatt> did you want to talk about multi-proces
688 2017-04-13T19:50:43  <BlueMatt> also please folks list your review-priority for this week :)
689 2017-04-13T19:50:55  <spudowiar> If that gets merged I will hug ryanofsky :)
690 2017-04-13T19:50:59  <wumpus> spudowiar: I don't see why not; would just make it more work to invite everyone
691 2017-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
692 2017-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
693 2017-04-13T19:51:20  <spudowiar> wumpus: No one would invite me :(
694 2017-04-13T19:51:36  <sipa> i'm not sure what the appeal of multi process is
695 2017-04-13T19:51:37  <wumpus> #topic multiprocess
696 2017-04-13T19:51:47  <wumpus> process isolation
697 2017-04-13T19:52:00  <sipa> i'd like to see the wallet go into a separate process from the networking
698 2017-04-13T19:52:03  <jonasschnelli> sipa: #10102
699 2017-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
700 2017-04-13T19:52:18  <BlueMatt> sipa: then review my PRs, those do the first step of splitting it off neatly
701 2017-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.
702 2017-04-13T19:52:29  <BlueMatt> then we can use ryanofsky's multiprocess stuff to do the process :)
703 2017-04-13T19:52:31  <wumpus> not having the gui and the rest in one address space would be a good start
704 2017-04-13T19:52:32  <sipa> that that's qt from the rest
705 2017-04-13T19:52:49  <sipa> that seems like a pointless gimmick to me
706 2017-04-13T19:53:01  <jonasschnelli> Yes. The wallet seems to be more important.
707 2017-04-13T19:53:06  <wumpus> sigh
708 2017-04-13T19:53:11  <gmaxwell> If it could disconect and reconnect it would have some value.
709 2017-04-13T19:53:15  <ryanofsky> agreed the wallet is more important
710 2017-04-13T19:53:18  * BlueMatt wasnt sure whether folks would like the many-process approach, over two-processes (wallet, and other)
711 2017-04-13T19:53:29  <jonasschnelli> not saying the Qt part is not important
712 2017-04-13T19:53:41  <ryanofsky> reason for starting with qt is that wallet work will depend on matt's changes
713 2017-04-13T19:53:41  <jnewbery> I'd like one process per wallet for multi-wallet
714 2017-04-13T19:53:44  <spudowiar> Oh, I thought that was wallet as well (my offer of hug has been withdrawn, ryanofsky)
715 2017-04-13T19:53:54  <wumpus> the gui has more pressing problems though: too much happens synchronous with the core in the GUI loop
716 2017-04-13T19:54:05  <jonasschnelli> wumpus: thats a good point
717 2017-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
718 2017-04-13T19:54:18  <wumpus> ryanofsky: yes I agree
719 2017-04-13T19:54:32  *** BCBot_ has quit IRC
720 2017-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?
721 2017-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.
722 2017-04-13T19:54:50  *** BCBot has joined #bitcoin-core-dev
723 2017-04-13T19:55:03  <wumpus> ryanofsky: would make sense to not have them share all that code
724 2017-04-13T19:55:03  <sipa> hmm, i withdraw my comment about it being pointless
725 2017-04-13T19:55:10  <gmaxwell> I've read the PR.
726 2017-04-13T19:55:35  <wumpus> also having one example of IPC between process could make other splits easier
727 2017-04-13T19:55:40  <gmaxwell> But this is not a good design.
728 2017-04-13T19:55:46  <gmaxwell> as such an example.
729 2017-04-13T19:55:58  <jnewbery> 5 minutes left.
730 2017-04-13T19:55:59  <jnewbery> Suggested topic: PR review requests
731 2017-04-13T19:56:11  <wumpus> gmaxwell: have you commented about the design in the PR?
732 2017-04-13T19:56:20  <wumpus> #topic high-priority PR review requests
733 2017-04-13T19:56:33  <BlueMatt> #10179
734 2017-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
735 2017-04-13T19:56:34  <BlueMatt> for me
736 2017-04-13T19:57:09  <sipa> #9792 plz
737 2017-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
738 2017-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
739 2017-04-13T19:57:12  *** moli_ has quit IRC
740 2017-04-13T19:57:13  <gribble> https://github.com/bitcoin/bitcoin/issues/9942 | Refactor CBlockPolicyEstimator by morcos · Pull Request #9942 · bitcoin/bitcoin · GitHub
741 2017-04-13T19:57:17  *** stoner19 has left #bitcoin-core-dev
742 2017-04-13T19:57:18  <spudowiar> wumpus: For external signing, currently messing about with external command, using stdio but other IPC example would be useful
743 2017-04-13T19:57:24  <spudowiar> Oops, topic's moved on, sorry
744 2017-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.
745 2017-04-13T19:57:31  <gmaxwell> )
746 2017-04-13T19:57:42  <gmaxwell> wumpus: I can comment more if I haven't.
747 2017-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?
748 2017-04-13T19:58:24  <wumpus> morcos: BlueMatt: ok added them to the project  https://github.com/bitcoin/bitcoin/projects/8
749 2017-04-13T19:58:27  <jnewbery> I'd like some review on #10044. The concept had some ACKs in the meeting a few weeks ago.
750 2017-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
751 2017-04-13T19:58:41  <wumpus> also sipa's
752 2017-04-13T19:58:46  <morcos> wumpus: ok, in 9942 case i think it has enough acks already
753 2017-04-13T19:59:03  <cfields_> jnewbery: will do.
754 2017-04-13T19:59:16  <wumpus> jnewbery: also added
755 2017-04-13T19:59:28  *** moli_ has joined #bitcoin-core-dev
756 2017-04-13T19:59:35  <luke-jr> spudowiar: JSON-RPC already provides wallet..
757 2017-04-13T20:00:00  <BlueMatt> DONG
758 2017-04-13T20:00:04  <wumpus> #endmeeting
759 2017-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)
760 2017-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
761 2017-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
762 2017-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
763 2017-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?
764 2017-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?
765 2017-04-13T20:00:24  <spudowiar> luke-jr: I'm just really bad at wording stuff :)
766 2017-04-13T20:00:33  <jnewbery> cfields_ wumpus thanks
767 2017-04-13T20:00:37  <spudowiar> petertodd: That's why we need OpenPGP Card 4.0 :)
768 2017-04-13T20:00:51  *** harrymm has quit IRC
769 2017-04-13T20:00:51  <spudowiar> petertodd: So that the smart card can request bits of the data, etc. and display it on the display
770 2017-04-13T20:00:52  <petertodd> spudowiar: it'll have to have a display at least... fudnemental probelm
771 2017-04-13T20:00:59  <spudowiar> petertodd: TREZOR
772 2017-04-13T20:01:08  <spudowiar> petertodd: I have a working OpenPGP implementation for TREZOR
773 2017-04-13T20:01:12  <spudowiar> Only does ECDSA signing though
774 2017-04-13T20:01:16  <spudowiar> Rewriting it in Rust though
775 2017-04-13T20:01:17  <petertodd> spudowiar: heh, git support for trezor...
776 2017-04-13T20:01:30  <spudowiar> petertodd: I signed a Git commit with it :)
777 2017-04-13T20:01:41  <petertodd> spudowiar: oh, theres a rust impl for the trezor uc?
778 2017-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'
779 2017-04-13T20:02:07  <spudowiar> petertodd: Rust runs on pretty much anything (there's an LLVM backend for STM32*)
780 2017-04-13T20:02:09  <gmaxwell> t provide for a stable interface. etc.
781 2017-04-13T20:02:25  <petertodd> spudowiar: nice!
782 2017-04-13T20:02:31  <luke-jr> bbl
783 2017-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.
784 2017-04-13T20:02:35  <petertodd> spudowiar: I've got a big project I'm doing in rust right now
785 2017-04-13T20:02:44  <spudowiar> !m petertodd
786 2017-04-13T20:02:44  <[b__b]> You're doing good work, petertodd!
787 2017-04-13T20:02:44  <gribble> Error: "m" is not a valid command.
788 2017-04-13T20:02:51  <spudowiar> Go away gribble
789 2017-04-13T20:03:07  <petertodd> heh
790 2017-04-13T20:03:31  <spudowiar> petertodd: https://pgp.mit.edu/pks/lookup?op=vindex&search=0xEDD78A88C5D03B56 is the key generated by my TREZOR
791 2017-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)
792 2017-04-13T20:03:56  <petertodd> spudowiar: nice!
793 2017-04-13T20:04:04  <spudowiar> https://github.com/trezor/trezor-mcu/pull/133 is the firmware code (written in C)
794 2017-04-13T20:04:04  *** dgenr8_ has quit IRC
795 2017-04-13T20:04:08  <jonasschnelli> spudowiar: Yeah. Nice stuff...
796 2017-04-13T20:04:41  <spudowiar> Only thing stopping me from getting this all finished is school :(
797 2017-04-13T20:05:21  <jonasschnelli> skip school
798 2017-04-13T20:05:23  <spudowiar> lol
799 2017-04-13T20:05:25  <spudowiar> Wait...
800 2017-04-13T20:05:32  <spudowiar> I actually have a video of this :)
801 2017-04-13T20:05:52  <jcorgan> of you skipping school?
802 2017-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...)
803 2017-04-13T20:05:59  <wumpus> gmaxwell: yes, seems a good idea
804 2017-04-13T20:06:45  <cfields_> petertodd: you had that lucrative art degree as a fallback, though :p
805 2017-04-13T20:06:56  <petertodd> cfields_: lol
806 2017-04-13T20:07:29  *** harrymm has joined #bitcoin-core-dev
807 2017-04-13T20:07:47  <spudowiar> https://twitter.com/spudowiar/status/784429631545958400
808 2017-04-13T20:07:50  <spudowiar> NO, THAT IS THE WRONG VIDEO
809 2017-04-13T20:07:53  <spudowiar> https://twitter.com/spudowiar/status/802960101992759296
810 2017-04-13T20:07:55  <spudowiar> Sorry
811 2017-04-13T20:08:20  <jcorgan> petertodd: worst case you can always rely on bridgette's money
812 2017-04-13T20:08:22  <spudowiar> Someone asked me if it worked on Windows so I recorded that for them :)
813 2017-04-13T20:09:02  <petertodd> jcorgan: heh
814 2017-04-13T20:09:16  <spudowiar> Wait... petertodd liked that video? When...?
815 2017-04-13T20:09:26  <spudowiar> Oh wait, late Twitter notifications
816 2017-04-13T20:09:35  <petertodd> spudowiar: just now :)
817 2017-04-13T20:11:14  <spudowiar> petertodd: The firmware in the Pong video was written in Rust
818 2017-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
819 2017-04-13T20:13:46  *** g0d355__ has joined #bitcoin-core-dev
820 2017-04-13T20:17:07  <BlueMatt> re: splitting qt process: can we use our own serialization instead of capnproto, ryanofsky?
821 2017-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
822 2017-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
823 2017-04-13T20:19:06  <wumpus> the GUI thread should never block on a IPC request
824 2017-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)
825 2017-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)
826 2017-04-13T20:21:30  <gmaxwell> wumpus: Can you explain shimming in the IPC address those blocks?-- if none of the dataflow is changed.
827 2017-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
828 2017-04-13T20:22:30  <wumpus> gmaxwell: shimming?
829 2017-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
830 2017-04-13T20:23:36  <wumpus> ryanofsky: that's kind of my problem with it; it may compound thecurrent issues
831 2017-04-13T20:23:37  <ryanofsky> or ipc calls that have to serialize / deserialize a large amount of data
832 2017-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.
833 2017-04-13T20:23:58  <wumpus> gmaxwell: that's why I say that should be addressed first
834 2017-04-13T20:23:59  <ryanofsky> wumpus, yes, we will have to see what performance will be
835 2017-04-13T20:24:25  <wumpus> gmaxwell: one everything the GUI does is asynchronous, making it work over IPC is also a lot easier
836 2017-04-13T20:24:30  <ryanofsky> but i do think any performance problems that are uncovered can be dealt with
837 2017-04-13T20:24:39  <wumpus> gmaxwell: that was my original plan for the GUI but I never had time to finish it :(
838 2017-04-13T20:24:45  <gmaxwell> wumpus: ah!
839 2017-04-13T20:24:57  <ryanofsky> it seems to me a lot easier to fix performance problems that come up than "make everything asyncrhonous"
840 2017-04-13T20:25:06  <wumpus> easier, but not better
841 2017-04-13T20:25:09  <gmaxwell> (I was thinking you thought the ipc changes did this already and thought I was confused).
842 2017-04-13T20:25:28  <wumpus> no, ideally IPC chnanges would do that
843 2017-04-13T20:25:35  <wumpus> but these don't, no
844 2017-04-13T20:25:39  <gmaxwell> ryanofsky: is it your thought that eventually the GUI could be started and stopped independantly of the backend?
845 2017-04-13T20:26:13  <wumpus> making everything asynchronous would improve the user experience a lot
846 2017-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
847 2017-04-13T20:26:40  <ryanofsky> gmaxwell, supporting that would be pretty easy, but i don't know what the use-cases would be
848 2017-04-13T20:27:00  <wumpus> ryanofsky: the typical windows service idea: have a GUI to manage it, that runs only part of the time
849 2017-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.
850 2017-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.
851 2017-04-13T20:27:39  <spudowiar> Oh, wait, I can call CWallet::LoadKeyMetadata!
852 2017-04-13T20:27:49  <wumpus> well the cap'n'proto thing could theoretically work with a separate process
853 2017-04-13T20:27:56  <wumpus> codebase*
854 2017-04-13T20:28:08  <wumpus> they only have to share the interface definition
855 2017-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
856 2017-04-13T20:28:22  <gmaxwell> wumpus: yes but without a designed and clean interface you can't reasonably support that.
857 2017-04-13T20:28:37  <wumpus> gmaxwell: maybe not in the first version
858 2017-04-13T20:28:41  <gmaxwell> And you get the ZMQ like "everything has to run exactly the same version of ZMQ" issue.
859 2017-04-13T20:28:56  <wumpus> gmaxwell: but I think you want too much at the same time
860 2017-04-13T20:29:28  <ryanofsky> gmaxwell, my pr defines an interface
861 2017-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.
862 2017-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
863 2017-04-13T20:30:01  <gmaxwell> and replacing it with something that we'll never be able to precisely define or secure.
864 2017-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
865 2017-04-13T20:30:21  <sipa> spudowiar: no
866 2017-04-13T20:30:30  <ryanofsky> how is the interface not precisely designed & secure?
867 2017-04-13T20:30:46  <ryanofsky> i mean defined not designed
868 2017-04-13T20:30:54  <sipa> spudowiar: that method is for loading metadata into the wallet
869 2017-04-13T20:31:31  <spudowiar> sipa: Yeah, I just saw that
870 2017-04-13T20:31:43  <gmaxwell> ryanofsky: where is a wire specification for captin proto that can be independantly implemented?
871 2017-04-13T20:32:14  <ryanofsky> oh this is just an objection to capnproto?
872 2017-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
873 2017-04-13T20:32:43  <ryanofsky> if capnproto is a real problem, a different protocol could be dropped in instead
874 2017-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).
875 2017-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
876 2017-04-13T20:33:11  <ryanofsky> most of the work i'm doing here is in making qt not call wallet/node functions directly
877 2017-04-13T20:33:30  *** spudowiar has quit IRC
878 2017-04-13T20:33:37  <ryanofsky> if you have suggestions for another wire format to use instead of capnproto, that'd be helpful
879 2017-04-13T20:33:41  <gmaxwell> ryanofsky: that stuff all sounds great to me independant of the rest.
880 2017-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
881 2017-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
882 2017-04-13T20:34:39  <wumpus> e.g. https://github.com/bitcoin/bitcoin/pull/10102/files#diff-1832023b80d9337ec49f60646c7a9c5dR1
883 2017-04-13T20:35:36  <gmaxwell> wumpus: yes so long as they also take all of captin proto, of the same vintage.
884 2017-04-13T20:35:58  <wumpus> gmaxwell: yes, they have to use the same IPC library
885 2017-04-13T20:36:12  <wumpus> gmaxwell: you'd want an independent implementation of the protocol?
886 2017-04-13T20:36:12  *** Dizzle has quit IRC
887 2017-04-13T20:37:10  <wumpus> I vaguely remember the wire format for capnp is documented, but can't find it quickly
888 2017-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.
889 2017-04-13T20:37:51  <sipa> well it would be nice to just have bitcoind running, and occasionally connect your qt frontend to it
890 2017-04-13T20:37:58  <wumpus> https://capnproto.org/encoding.html
891 2017-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.
892 2017-04-13T20:38:03  <gmaxwell> sipa: agreed.
893 2017-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
894 2017-04-13T20:38:43  <sipa> ryanofsky: i think what gmaxwell means is whether it's a well defined interface
895 2017-04-13T20:38:53  <sipa> will the gui and server always be the same version
896 2017-04-13T20:39:04  <sipa> or do they need to interact across different versions
897 2017-04-13T20:39:12  <wumpus> at first: no
898 2017-04-13T20:39:13  <ryanofsky> sipa, that's up to us
899 2017-04-13T20:39:14  <gmaxwell> Well defined and stable, right.
900 2017-04-13T20:39:42  <sipa> ryanofsky: and i think gmaxwell means that for the Qt split, no well defined and stable interface is needed
901 2017-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
902 2017-04-13T20:39:48  <sipa> but for the wallet separation there is
903 2017-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.
904 2017-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
905 2017-04-13T20:40:34  <wumpus> ryanofsky: indeed, they have thought of this
906 2017-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.
907 2017-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
908 2017-04-13T20:41:18  <gmaxwell> But that isn't what we want for wallet seperation.
909 2017-04-13T20:41:51  <sipa> i think for wallet separation we should just use p2p
910 2017-04-13T20:42:16  <sipa> and have the wallet side implement spv
911 2017-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.
912 2017-04-13T20:42:31  *** Guyver2 has quit IRC
913 2017-04-13T20:42:40  <sipa> and designed for
914 2017-04-13T20:44:01  *** Guyver2 has joined #bitcoin-core-dev
915 2017-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
916 2017-04-13T20:44:48  <gmaxwell> thats totally not confusing with python. :P
917 2017-04-13T20:45:19  <BlueMatt> wumpus: i think you can remove the merged PRs from https://github.com/bitcoin/bitcoin/projects/8
918 2017-04-13T20:45:51  <BlueMatt> luke-jr: where are you on #8694? looks like you have a bunch of comments to fix?
919 2017-04-13T20:45:53  <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
920 2017-04-13T20:46:28  <ryanofsky> wumpus, chromium is in the middle of transitioning between ipc systems
921 2017-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
922 2017-04-13T20:46:57  <wumpus> ryanofsky: oh?
923 2017-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
924 2017-04-13T20:48:13  <ryanofsky> mojo is similar to capnproto, but supports passing file descriptors & shared memory over the socket, not just sending bytes
925 2017-04-13T20:48:36  <wumpus> didn't know about mojo
926 2017-04-13T20:49:09  <ryanofsky> this page describes the older chromium ipc mechanism: https://www.chromium.org/developers/design-documents/inter-process-communication
927 2017-04-13T20:49:49  <ryanofsky> yeah i actually looked into using mojo before capnproto
928 2017-04-13T20:50:07  <ryanofsky> but the mojo project itself is actually dead
929 2017-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
930 2017-04-13T20:51:03  <wumpus> so they don't use the project itself, just copied some files to their project?
931 2017-04-13T20:51:20  <ryanofsky> copied & stripped out parts they didn't need
932 2017-04-13T20:51:38  <ryanofsky> https://chromium.googlesource.com/chromium/src/+/master/mojo
933 2017-04-13T20:57:08  <wumpus> yes that seems quite close to cap'n'proto
934 2017-04-13T20:57:51  *** tw2006 has quit IRC
935 2017-04-13T21:10:16  *** Ylbam has joined #bitcoin-core-dev
936 2017-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
937 2017-04-13T21:24:56  *** chjj has quit IRC
938 2017-04-13T21:37:02  *** talmai has quit IRC
939 2017-04-13T21:42:11  <bitcoin-git> [bitcoin] dramaticbulgarian opened pull request #10206: Chainparams: In ReceivedBlockTransactions() (master...chainparams) https://github.com/bitcoin/bitcoin/pull/10206
940 2017-04-13T21:52:14  *** Giszmo has joined #bitcoin-core-dev
941 2017-04-13T21:55:26  *** jtimon has quit IRC
942 2017-04-13T22:00:20  *** jcorgan is now known as jcorgan_
943 2017-04-13T22:01:14  *** jcorgan_ is now known as jcorgan
944 2017-04-13T22:04:34  *** LeMiner2 has joined #bitcoin-core-dev
945 2017-04-13T22:06:56  *** LeMiner has quit IRC
946 2017-04-13T22:06:56  *** LeMiner2 is now known as LeMiner
947 2017-04-13T22:06:57  *** fao has quit IRC
948 2017-04-13T22:07:32  *** fao has joined #bitcoin-core-dev
949 2017-04-13T22:12:55  *** Guyver2 has quit IRC
950 2017-04-13T22:13:25  *** TheV01D has joined #bitcoin-core-dev
951 2017-04-13T22:14:27  <TheV01D> lo
952 2017-04-13T22:35:54  *** fao has quit IRC
953 2017-04-13T22:36:19  *** fao has joined #bitcoin-core-dev
954 2017-04-13T22:36:24  *** LeMiner2 has joined #bitcoin-core-dev
955 2017-04-13T22:39:08  *** LeMiner has quit IRC
956 2017-04-13T22:39:08  *** LeMiner2 is now known as LeMiner
957 2017-04-13T22:39:13  *** owowo has quit IRC
958 2017-04-13T22:41:41  *** ryan-c- is now known as ryan-c
959 2017-04-13T22:46:47  *** tw2006 has joined #bitcoin-core-dev
960 2017-04-13T22:51:37  *** tw2006 has quit IRC
961 2017-04-13T22:57:38  *** AaronvanW has quit IRC
962 2017-04-13T22:58:15  *** AaronvanW has joined #bitcoin-core-dev
963 2017-04-13T23:17:06  <bitcoin-git> [bitcoin] dramaticbulgarian closed pull request #10206: Chainparams: In ReceivedBlockTransactions() (master...chainparams) https://github.com/bitcoin/bitcoin/pull/10206
964 2017-04-13T23:20:09  *** goksinen has joined #bitcoin-core-dev
965 2017-04-13T23:24:35  *** goksinen has quit IRC
966 2017-04-13T23:25:24  *** goksinen has joined #bitcoin-core-dev
967 2017-04-13T23:31:09  *** goksinen has quit IRC
968 2017-04-13T23:32:01  *** owowo has joined #bitcoin-core-dev
969 2017-04-13T23:33:47  *** AaronvanW has quit IRC
970 2017-04-13T23:41:10  *** owowo has quit IRC
971 2017-04-13T23:42:02  *** owowo has joined #bitcoin-core-dev
972 2017-04-13T23:54:54  *** btcdrak has quit IRC