1 2017-09-21 00:21:40	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #11377: Disallow uncompressed pubkeys in bitcoin-tx [multisig] output adds (06master...062017-09-bitcoin-tx-uncompressed-segwit) 02https://github.com/bitcoin/bitcoin/pull/11377
  2 2017-09-21 00:43:25	0|phantomcircuit|gmaxwell, why wouldn't it work?
  3 2017-09-21 00:43:30	0|phantomcircuit|it's just slowish
  4 2017-09-21 00:58:57	0|bitcoin-git|[13bitcoin] 15btc1-prevention opened pull request #11378: Update COPYING (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/11378
  5 2017-09-21 01:15:48	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11378: Update COPYING (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/11378
  6 2017-09-21 03:16:55	0|meshcollider|Is anything in the share/certs/ directory actually relevant anymore? Seems pretty outdated
  7 2017-09-21 03:21:09	0|achow101|meshcollider: yes, that's information about the codesigning certs
  8 2017-09-21 03:22:38	0|achow101|the threat mitigation part is outdated I think because of the detached sigs thing. the codesigned binaries are now gitian built
  9 2017-09-21 03:29:49	0|kallewoof|Would it be worth it to add a replay protection mechanism in Bitcoin where a NOP is replaced with <height> <blockhash> OP_CHECKBLOCKVERIFY which would fail if the hash of the block at the given height did not match <blockhash>? (It would probably require that <height> was less than <current height> - 100 to avoid nasty double spends at reorgs...)
 10 2017-09-21 03:31:24	0|kallewoof|Actually, I don't think that would solve anything, since old UTXOs would still be replayed, just unspendable. Nevermind.
 11 2017-09-21 03:36:13	0|achow101|meshcollider: well I suppose the keys there are outdated as it looks like the codesigned stuff uses a more recent cert
 12 2017-09-21 03:36:29	0|achow101|cfields: would you mind updating that? or do you think it should be removed entirely?
 13 2017-09-21 03:37:23	0|meshcollider|achow101: yeah that's what I thought, this is stuff from 5 years ago
 14 2017-09-21 03:38:51	0|achow101|meshcollider: the keys there are expired too
 15 2017-09-21 03:44:18	0|cfields|achow101: yea, i think it can just be removed. The signing process is documented (and scripted)
 16 2017-09-21 03:44:31	0|achow101|cfields: where is it documented?
 17 2017-09-21 03:44:54	0|cfields|achow101: in the gitian build instructions
 18 2017-09-21 03:45:19	0|achow101|oh I see.
 19 2017-09-21 03:45:30	0|achow101|where is this script: detached-sig-create.sh?
 20 2017-09-21 03:45:33	0|achow101|I only see one for osx
 21 2017-09-21 03:45:36	0|bitcoin-git|[13bitcoin] 15MeshCollider opened pull request #11380: Remove outdated share/certs/ directory (06master...06201709_remove_old_certs) 02https://github.com/bitcoin/bitcoin/pull/11380
 22 2017-09-21 03:45:44	0|achow101|and not one for windows
 23 2017-09-21 03:45:46	0|cfields|I've helped a few other projects (litecoin, for ex), build using our process. The last one (i forget who, now) was able to sign without my assistance.
 24 2017-09-21 03:46:41	0|cfields|hmm, we have one for windows as of 0.15. surely i updated the instructions for it. Checking.
 25 2017-09-21 03:47:27	0|cfields|(the script/cert are in contrib/windeploy )
 26 2017-09-21 03:47:41	0|achow101|ah, I see it now.
 27 2017-09-21 03:47:51	0|achow101|missed that earlier
 28 2017-09-21 03:48:34	0|achow101|no certs for osx? (I don't see any in macdeploy)
 29 2017-09-21 03:48:39	0|cfields|well, there aren't instructions in that gitian doc like i thought there were. Will add.
 30 2017-09-21 03:49:23	0|achow101|the gitian doc has instructions for running the scripts
 31 2017-09-21 03:49:34	0|achow101|err the release process doc
 32 2017-09-21 03:49:37	0|meshcollider|cfields: might be in the release process doc
 33 2017-09-21 03:50:26	0|cfields|no, I got distracted from finishing the osx tool, so committed osx certs can't be used yet
 34 2017-09-21 03:50:33	0|cfields|ah, maybe that's it
 35 2017-09-21 03:51:19	0|cfields|anyway, gitian spits out "*unsigned.tar.gz", which the signer just untars and runs ./detached-sig-create.sh. Very straigtforward.
 36 2017-09-21 03:51:32	0|cfields|but if it's not fully written up, I can do so
 37 2017-09-21 03:52:05	0|achow101|it's written up here: https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#next-steps
 38 2017-09-21 03:52:32	0|achow101|why are there 3 certs in win-codesign.cert?
 39 2017-09-21 03:52:46	0|achow101|oh, 2 are comodo's and one is ours
 40 2017-09-21 03:52:49	0|cfields|yea, there we go
 41 2017-09-21 03:52:59	0|cfields|yea, it's the whole chain
 42 2017-09-21 03:53:46	0|achow101|Is the osx one the same as the one in share/certs?
 43 2017-09-21 03:53:51	0|achow101|it expires in 2018
 44 2017-09-21 03:55:15	0|cfields|probably so
 45 2017-09-21 03:55:44	0|meshcollider|so they should be moved instead of removed?
 46 2017-09-21 03:56:16	0|achow101|meshcollider: the windows one should be removed
 47 2017-09-21 03:56:35	0|achow101|don't know about the osx one, but it probably can't be used with the osx script provided in contrib/macdeploy
 48 2017-09-21 03:56:51	0|achow101|(I don't have a mac to check if the signature matches that cert)
 49 2017-09-21 03:57:02	0|cfields|the stuff in share/certs is informational only, it isn't used atm
 50 2017-09-21 03:57:32	0|cfields|the windows certs in contrib/windeploy are actually used by the signing/re-attaching process
 51 2017-09-21 03:58:20	0|cfields|the cert chain could be ripped out of an osx binary with some hacking (or maybe there's a tool for it?)
 52 2017-09-21 03:59:34	0|achow101|cfields: is there some way to check the detached sigs?
 53 2017-09-21 04:00:07	0|cfields|what do you mean by check?
 54 2017-09-21 04:00:29	0|achow101|like extract the chain out of them
 55 2017-09-21 04:00:44	0|achow101|or see if they verify to that cert
 56 2017-09-21 04:03:22	0|cfields|checking
 57 2017-09-21 04:10:58	0|cfields|the 0.15.0.1 binary contains the same localKeyID as the committed .pem
 58 2017-09-21 04:12:07	0|achow101|ok, thanks
 59 2017-09-21 04:12:30	0|achow101|I wonder if gavin made bitcoin xt or bitcoin classic releases signed with that key...
 60 2017-09-21 04:14:53	0|cfields|not afaik
 61 2017-09-21 04:15:32	0|achow101|I assume that he isn't stupid enough to do that
 62 2017-09-21 04:15:32	0|cfields|fwiw: https://pastebin.com/raw/UZKRpdPc
 63 2017-09-21 04:15:48	0|cfields|anyone on osx can reproduce ^^
 64 2017-09-21 04:16:10	0|achow101|is codesign some osx utility?
 65 2017-09-21 04:16:35	0|cfields|yea
 66 2017-09-21 04:17:24	0|cfields|i patched an ios tool to do osx signing a while ago. It's 99% ready, just never finished it/hooked it up
 67 2017-09-21 04:18:04	0|cfields|https://github.com/theuni/osx-codesign
 68 2017-09-21 04:19:05	0|achow101|why?
 69 2017-09-21 04:19:28	0|achow101|luke-jr: supposedly qt supports android in some way
 70 2017-09-21 04:19:42	0|cfields|achow101: why what?
 71 2017-09-21 04:19:53	0|luke-jr|achow101: yes, or I wouldn't even consider it a possibility :p
 72 2017-09-21 04:20:23	0|luke-jr|(it also supports iOS)
 73 2017-09-21 04:20:24	0|achow101|cfields: why did you make an osx signing tool if there already is one?
 74 2017-09-21 04:20:42	0|achow101|(the one existing being whatever is used now)
 75 2017-09-21 04:20:52	0|achow101|luke-jr: it does?
 76 2017-09-21 04:20:58	0|luke-jr|achow101: yes
 77 2017-09-21 04:21:02	0|luke-jr|http://doc.qt.io/qt-5/ios-support.html
 78 2017-09-21 04:21:13	0|cfields|achow101: oh, sorry. portable tool. Works from Linux.
 79 2017-09-21 04:22:05	0|achow101|cfields: ah. ok. I figured it was probably also that it is open source
 80 2017-09-21 04:22:28	0|cfields|achow101: well most (all?) of osx userspace is open-source. It's just a tangled web.
 81 2017-09-21 04:23:18	0|luke-jr|cfields: pretty sure the GUI stuff isn't?
 82 2017-09-21 04:24:06	0|cfields|luke-jr: that would make sense
 83 2017-09-21 04:29:05	0|meshcollider|luke-jr: that can't even be considered until SPV mode is added though right, no way android is going to run Qt with even a pruned blockchain and full UTXO set lol
 84 2017-09-21 04:31:24	0|achow101|meshcollider: it can run bitcoind
 85 2017-09-21 04:31:29	0|achow101|look up ABCore
 86 2017-09-21 04:32:12	0|achow101|and android devices (smartphones in general) are getting more powerful and have more ram
 87 2017-09-21 04:32:24	0|cfields|meshcollider: no reason why it should be less performant than gnu/linux on an arm machine
 88 2017-09-21 04:35:08	0|meshcollider|hmm that's true, I've just never even considered trying to run a full node on a smartphone
 89 2017-09-21 04:35:41	0|meshcollider|that's an interesting idea
 90 2017-09-21 08:38:44	0|esotericnonsense|my smartphone is multiple years old and is more powerful than many machines i've synced a node from
 91 2017-09-21 08:39:54	0|esotericnonsense|much better than a raspberry pi anyway :)\
 92 2017-09-21 09:16:39	0|sdfgsdfg_|ohio, how much until LN is tested on mainnet ?
 93 2017-09-21 09:37:11	0|kallewoof|Someone wrote a post about that on reddit. One of the devs said two weeks I think. (LN is actually not bitcoin core, but a separate client entirely.)
 94 2017-09-21 09:46:14	0|meshcollider|link: https://www.reddit.com/r/Bitcoin/comments/714x2k/what_is_the_status_of_the_lightning_network/dn8docc/
 95 2017-09-21 09:50:44	0|promag|wumpus: is there a thread pool for RPC handling?
 96 2017-09-21 15:13:45	0|bitcoin-git|[13bitcoin] 15aqibbak opened pull request #11381: Update .travis.yml (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/11381
 97 2017-09-21 15:34:09	0|wumpus|promag: yes, the HTTP worker threads
 98 2017-09-21 17:03:37	0|ossifrage|The 'reindexing blocks on disk...' progress bar flaps around quite a bit, not exactly a stable progress bar
 99 2017-09-21 17:24:38	0|wumpus|at least better than not showing progress at all
100 2017-09-21 17:25:05	0|ossifrage|wumpus, yeah it just was flapping between "5 year" and "3 years" behind, which is a bit extreme
101 2017-09-21 17:26:03	0|gmaxwell|huh....
102 2017-09-21 17:26:07	0|gmaxwell|it shouldn't do that
103 2017-09-21 17:26:18	0|ossifrage|I restarted the node with txindex=1
104 2017-09-21 17:26:47	0|ossifrage|I set dbcache to 4096
105 2017-09-21 17:27:53	0|wumpus|I expect there to be larger variance in the beginning, once it gets to the blocks that are actually filled, it's probably more stable
106 2017-09-21 17:28:42	0|ossifrage|I thought the estimate was just based on block count not transaction count?
107 2017-09-21 17:29:13	0|sipa|no, it's based on transaction count
108 2017-09-21 17:29:50	0|ossifrage|Now it is flapping + 1 year
109 2017-09-21 17:40:02	0|wumpus|I've never seen it flapping here, though I must say I haven't ever paid close attention to it, after all it's hardly something you can wait for to complete :)
110 2017-09-21 17:43:33	0|ossifrage|Maybe it is specific to reindexing with txindex=1... Oddly it doesn't seem to be io bound or cpu bound (none of the threads consume 100% cpu). Lock contention? Or maybe blocking on fsync()?
111 2017-09-21 17:44:30	0|wumpus|that's just in the beginning, it will get cpu bound soon enough
112 2017-09-21 17:45:38	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11381: Update .travis.yml (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/11381
113 2017-09-21 17:46:06	0|gmaxwell|if its flaping then it doesn't work like I understood...
114 2017-09-21 17:48:14	0|ossifrage|Both the bar and the text are flapping but the "Progress x%" is counting up smoothly (that must be just block height?)
115 2017-09-21 17:48:19	0|wumpus|before it gets to the blocks that require serious validation I expect it's mostly waiting for i/o latency (reading blocks from disk, updating db), interspersed with a bit of cpu use
116 2017-09-21 17:51:59	0|wumpus|I don't think it has used block height as a progress measure in the UI since 0.5.x or so
117 2017-09-21 17:53:23	0|wumpus|block height is pretty useless for that because it starts off really fast and then slows down more and more
118 2017-09-21 19:00:12	0|sipa|meetung?
119 2017-09-21 19:00:27	0|lightningbot|Meeting started Thu Sep 21 19:00:26 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
120 2017-09-21 19:00:27	0|wumpus|#startmeeting
121 2017-09-21 19:00:28	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
122 2017-09-21 19:00:49	0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101
123 2017-09-21 19:00:55	0|kanzure|hi.
124 2017-09-21 19:01:00	0|sipa|hi.
125 2017-09-21 19:01:05	0|meshcollider|hello
126 2017-09-21 19:01:10	0|cfields|hi
127 2017-09-21 19:01:25	0|sdaftuar|hey
128 2017-09-21 19:01:26	0|luke-jr|hi
129 2017-09-21 19:01:43	0|jnewbery|hello
130 2017-09-21 19:02:07	0|achow101|hi
131 2017-09-21 19:02:17	0|wumpus|so PSA: we've released 0.15.0.1 with a single patch #11332, compared to 0.15.0, to solve the qt crash issue for some users
132 2017-09-21 19:02:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/11332 | Fix possible crash with invalid nCustomFeeRadio in QSettings (achow101, TheBlueMatt) by jonasschnelli · Pull Request #11332 · bitcoin/bitcoin · GitHub
133 2017-09-21 19:02:27	0|sdaftuar|yay
134 2017-09-21 19:02:50	0|wumpus|#topic high-priority for review
135 2017-09-21 19:03:11	0|achow101|#10871 please?
136 2017-09-21 19:03:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/10871 | Handle getinfo in bitcoin-cli w/ -getinfo (revival of #8843) by achow101 · Pull Request #10871 · bitcoin/bitcoin · GitHub
137 2017-09-21 19:03:32	0|wumpus|I don't think we made much progress on review, this week (me included)
138 2017-09-21 19:03:49	0|BlueMatt|no, we (or at least I) did not :(
139 2017-09-21 19:04:24	0|sipa|regarding that: i've seen several reports of people wondering what happened because getinfo doesn't work... i guess they went from 0.14 to 0.5.99 and never saw the deprecation
140 2017-09-21 19:04:50	0|gmaxwell|Well they shouldn't run 0.5, that would be bad.
141 2017-09-21 19:04:50	0|wumpus|added 10871
142 2017-09-21 19:04:51	0|BlueMatt|heh, so, what, when a new release is announced they just build master? :(
143 2017-09-21 19:05:08	0|luke-jr|Maybe `bitcoin-cli getinfo` should print a message informing the user about the new RPCs, like we did when bitcoind client got deprecated
144 2017-09-21 19:05:13	0|gmaxwell|BlueMatt: some people do that.
145 2017-09-21 19:05:16	0|wumpus|luke-jr: also thought about that
146 2017-09-21 19:05:20	0|BlueMatt|gmaxwell: wat
147 2017-09-21 19:05:27	0|luke-jr|lol
148 2017-09-21 19:05:34	0|wumpus|luke-jr: it should at least print a deprecated message
149 2017-09-21 19:05:44	0|sipa|BlueMatt: gmaxwell is joking about my typo (0.5 instead of 0.15)
150 2017-09-21 19:05:46	0|BlueMatt|gmaxwell: so...what you're saying is we should start using a "develop" branch with master pointing to released versions?
151 2017-09-21 19:05:54	0|BlueMatt|sipa: i figured......
152 2017-09-21 19:05:55	0|wumpus|luke-jr: instead of just about a missing call, as if it's never existed
153 2017-09-21 19:06:22	0|sipa|i like the approach being used for the estimatefee deprecation
154 2017-09-21 19:06:24	0|luke-jr|BlueMatt: github lets you change the default branch, so we could just make it the latest stable branch
155 2017-09-21 19:06:25	0|goatpig|dont poeple typically pull tags, not just the head of a branch (in this case master)
156 2017-09-21 19:06:27	0|wumpus|BlueMatt: or we can just change the github default branch to something else, you know
157 2017-09-21 19:06:31	0|luke-jr|problem is, it's also the default for PRs…
158 2017-09-21 19:06:34	0|BlueMatt|wumpus: yea, possible
159 2017-09-21 19:06:37	0|sipa|where it disappears, but you have a cmdline switch to re-enable
160 2017-09-21 19:06:41	0|BlueMatt|I mean really not joking there that's a serious issue
161 2017-09-21 19:06:50	0|wumpus|but yes, PRs also go there by default, whichi s kinda annoying
162 2017-09-21 19:06:56	0|achow101|topic suggestion: deprecation stuff a la #11031
163 2017-09-21 19:06:56	0|BlueMatt|people building master right after release is usually bad cause we merge lots of fun stuff on master right after release :/
164 2017-09-21 19:06:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/11031 | [rpc] deprecate estimatefee by jnewbery · Pull Request #11031 · bitcoin/bitcoin · GitHub
165 2017-09-21 19:07:06	0|luke-jr|I suppose we can expect developers to be smarter than users
166 2017-09-21 19:07:22	0|gmaxwell|BlueMatt: I am not saying we should, just pointing out people do that. We have warnings on master... so I don't worry too much.
167 2017-09-21 19:07:23	0|cfields|sipa: i like that too. or even an rpc arg like -force-deprecated.
168 2017-09-21 19:07:28	0|wumpus|PRs to branches are really annoying, so I'd prefer to just keep the status quo there
169 2017-09-21 19:07:33	0|BlueMatt|gmaxwell: yea, maybe we should make the warnings louder?
170 2017-09-21 19:07:38	0|BlueMatt|that may be acceptable similar
171 2017-09-21 19:07:39	0|sipa|i think the reports  saw were from pretty much first time users "how do i set this up", and following a guide to build from source
172 2017-09-21 19:07:44	0|luke-jr|cfields: better to force the user to be involved IMO
173 2017-09-21 19:07:56	0|sipa|wumpus: agree
174 2017-09-21 19:08:07	0|wumpus|it can't be the release announcement, as I mention the exact tag to check out there...
175 2017-09-21 19:08:14	0|jonasschnelli|hi
176 2017-09-21 19:08:16	0|cfields|luke-jr: that's what i meant.
177 2017-09-21 19:08:32	0|luke-jr|cfields: a RPC arg wouldn't have the user involved
178 2017-09-21 19:08:45	0|BlueMatt|maybe bitcoind should need a -iknowthisisunreleasedunstableversion option :(
179 2017-09-21 19:08:46	0|luke-jr|software would just set it
180 2017-09-21 19:08:48	0|wumpus|maybe would make sense to add a git clone command in there too for people that can't figure that out themselves
181 2017-09-21 19:08:58	0|BlueMatt|or configure could take it
182 2017-09-21 19:09:05	0|luke-jr|BlueMatt: default to testnet?
183 2017-09-21 19:09:17	0|cfields|luke-jr: oh ok, different definitions of user. i see what you mean.
184 2017-09-21 19:09:20	0|wumpus|configure already has that information, so that'd make sense
185 2017-09-21 19:09:21	0|BlueMatt|./configure --this-version-is-unreleased-and-possibly-unstable
186 2017-09-21 19:09:38	0|BlueMatt|that would make people think twice and make people fix their guides
187 2017-09-21 19:09:44	0|luke-jr|s/unstable/insecure/ ☺
188 2017-09-21 19:09:51	0|achow101|luke-jr: we would forget to make it default to mainnet for releases
189 2017-09-21 19:10:02	0|BlueMatt|heh, ok, at the risk of bikeshedding, I vote cfields implement it...I dunno anything 'bout autotools
190 2017-09-21 19:10:03	0|BlueMatt|:p
191 2017-09-21 19:10:04	0|luke-jr|achow101: would we? release-process.md
192 2017-09-21 19:10:04	0|wumpus|I've never forget to set IS_RELEASE to true for releases
193 2017-09-21 19:10:21	0|wumpus|a few times we've forgot to bump the version number but only for *minor* releases
194 2017-09-21 19:10:23	0|luke-jr|or just have -testnet default to !IS_RELEASE
195 2017-09-21 19:10:44	0|cfields|heh
196 2017-09-21 19:10:47	0|wumpus|and for branches the IS_RELEASE is always true anyhow
197 2017-09-21 19:10:49	0|BlueMatt|luke-jr: I kinda like it not modifying the bitcoind at all now that i think about it
198 2017-09-21 19:11:02	0|sipa|wumpus: an alternative would be to have a bitcoin-releases repo (under the same org), to which only release tags get pushed
199 2017-09-21 19:11:05	0|BlueMatt|build the same bitcoind, but make people type something that says "is not release"
200 2017-09-21 19:11:14	0|sipa|wumpus: and direct people to clone from there if they just want stable things
201 2017-09-21 19:11:17	0|sipa|but meh...
202 2017-09-21 19:11:24	0|wumpus|sipa: I don't know...
203 2017-09-21 19:11:29	0|BlueMatt|sipa: heh, if we make it not build from bitcoin/bitcoin, ok
204 2017-09-21 19:11:33	0|wumpus|I really prefer not to mess with the repopsotiry too much
205 2017-09-21 19:11:45	0|jonasschnelli|agree with wumpus
206 2017-09-21 19:11:45	0|morcos|This doesn't seem that large a problem to me...
207 2017-09-21 19:11:49	0|sipa|wumpus: yes, agree - i don't think we should do anything
208 2017-09-21 19:11:49	0|wumpus|agree
209 2017-09-21 19:11:55	0|wumpus|any other topics?
210 2017-09-21 19:11:59	0|achow101|we could move the repo to bitcoin-core and break all of those guides :)
211 2017-09-21 19:12:00	0|BlueMatt|agreed, though I'd vote for a configure flag
212 2017-09-21 19:12:04	0|gmaxwell|yea, I think we don't need to do anything except hunt down and kill people with bad guides. :P
213 2017-09-21 19:12:04	0|sipa|achow101 had a topic
214 2017-09-21 19:12:06	0|BlueMatt|its not a huge issue, but it sounds rather dangerous
215 2017-09-21 19:12:12	0|sipa|(though maybe we've covered it already)
216 2017-09-21 19:12:14	0|gmaxwell|perhaps increase the profile of tarball downloads.
217 2017-09-21 19:12:18	0|BlueMatt|and I dont think hunting down guide-writers is possible
218 2017-09-21 19:12:26	0|wumpus|gmaxwell: now that sounds like a good action item
219 2017-09-21 19:12:34	0|wumpus|$action hunt down and kill people with bad guides
220 2017-09-21 19:12:45	0|gmaxwell|BlueMatt: publishers, not technically authors.
221 2017-09-21 19:12:50	0|jnewbery|any other feedback on the approach in #11031? I think it's a useful pattern for deprecating RPCs (which we'll need to do a few times)
222 2017-09-21 19:12:51	0|gribble|https://github.com/bitcoin/bitcoin/issues/11031 | [rpc] deprecate estimatefee by jnewbery · Pull Request #11031 · bitcoin/bitcoin · GitHub
223 2017-09-21 19:13:28	0|wumpus|#topic deprecation stuff a la #11031
224 2017-09-21 19:13:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/11031 | [rpc] deprecate estimatefee by jnewbery · Pull Request #11031 · bitcoin/bitcoin · GitHub
225 2017-09-21 19:13:37	0|luke-jr|there's only 363 0.15.99 nodes
226 2017-09-21 19:14:03	0|BlueMatt|luke-jr: I'd expect there to be ~0 on mainnet aside from some developer test nodes, fwiw
227 2017-09-21 19:14:18	0|achow101|I think that we might run into a problem where people just have -deprecatedrpc (or whatever it is called) and enable all deprecated behavior until it disappears
228 2017-09-21 19:14:43	0|BlueMatt|achow101: thats fine, at least they were made to type "I know this is going away soon"
229 2017-09-21 19:14:48	0|BlueMatt|so they cant show up and complain that its gone
230 2017-09-21 19:14:49	0|cfields|jnewbery: i like it (better than an rpc arg, on second thought), though the name could use some bikeshedding :(
231 2017-09-21 19:15:06	0|jonasschnelli|luke-jr: my crawler counts 2496
232 2017-09-21 19:15:17	0|jonasschnelli|oh.. no .99,.. sry
233 2017-09-21 19:15:52	0|wumpus|I also prefer command line arg to rpc arg
234 2017-09-21 19:15:59	0|wumpus|it's enough to type it once
235 2017-09-21 19:16:05	0|jnewbery|achow101: it's designed such that the user needs to include `-enablerpcmethod=<method1> -enablerpcmethod=<method2> ...` to avoid the problem of a user just setting `-enablealldepractedrpcmethods` and forgetting
236 2017-09-21 19:16:43	0|jnewbery|cfields: yes, name could probably be improved
237 2017-09-21 19:16:46	0|gmaxwell|yea, don't have a deprecatedall, it needs to be specific.
238 2017-09-21 19:16:50	0|wumpus|the purpose is just to signal, not to overburden a user with extra work updating their client applications (apart from getting rid of using the RPC call in the first place)
239 2017-09-21 19:16:54	0|meshcollider|hmm yeah "-enablerpcmethod=" should probably have the word "deprecated" in it
240 2017-09-21 19:17:00	0|wumpus|yes
241 2017-09-21 19:17:11	0|achow101|I propose calling it -enableddeprecatedrpc
242 2017-09-21 19:17:18	0|jonasschnelli|ack
243 2017-09-21 19:17:19	0|wumpus|otherwise it sounds more like a silly security feature
244 2017-09-21 19:17:21	0|meshcollider|+!
245 2017-09-21 19:17:34	0|meshcollider|s/!/1/
246 2017-09-21 19:17:58	0|sipa|-yesimnaughtyandneedtoupdatemyclienttonotuserpcmethod=name
247 2017-09-21 19:18:16	0|achow101|although maybe enabled may not necessarily be the best word for that since we have PRCs that themselves are not deprecated but have deprecated output fields and only the deprecated output fields would show if that option is set
248 2017-09-21 19:18:34	0|luke-jr|thought: should rpcuser auth always throw RPC_METHOD_DEPRECATED? if so, how does the user bypass it?
249 2017-09-21 19:18:44	0|morcos|-deprecatedrpc is good enough
250 2017-09-21 19:18:46	0|luke-jr|maybe -enabledeprecated= would be better
251 2017-09-21 19:18:51	0|morcos|in a light pink
252 2017-09-21 19:18:51	0|wumpus|morcos: yes!
253 2017-09-21 19:18:54	0|gmaxwell|-backwardscompatibilitylaunchcode=0xdeadbeef234828429342893429  < that could trigger fields that are going away. :P
254 2017-09-21 19:19:06	0|wumpus|hehehe
255 2017-09-21 19:19:17	0|gmaxwell|(and you need to read the release notes to get the launch code)
256 2017-09-21 19:19:22	0|gmaxwell|(or source)
257 2017-09-21 19:19:30	0|jnewbery|ok, -deprecatedrpc it is
258 2017-09-21 19:19:36	0|wumpus|release notes scavenger hunt
259 2017-09-21 19:19:38	0|cfields|gmaxwell: where the launchcode is the git commit, so it changes every day until release
260 2017-09-21 19:20:16	0|cfields|jnewbery: ack
261 2017-09-21 19:20:18	0|gmaxwell|well the idea there was that each depricated feature would have its own code. So you'd look up the code and specify it.
262 2017-09-21 19:20:20	0|luke-jr|gmaxwell: too strong for mere deprecation IMO
263 2017-09-21 19:20:42	0|gmaxwell|luke-jr: yes, though it solved the how about deprecated fields case.
264 2017-09-21 19:20:46	0|luke-jr|something like that feels more like to allow changing consensus-critical stuff
265 2017-09-21 19:20:56	0|achow101|I suppose we can then put all of the deprecated account RPCs behind that argument
266 2017-09-21 19:21:07	0|cfields|gmaxwell: you're deprecating me? :(
267 2017-09-21 19:21:12	0|wumpus|yes
268 2017-09-21 19:21:15	0|luke-jr|gmaxwell: how about if the "launch code" matches the method name for methods? :p
269 2017-09-21 19:21:23	0|luke-jr|and "accounts" for accounts
270 2017-09-21 19:21:30	0|luke-jr|"rpcuser" for -rpcuser
271 2017-09-21 19:21:30	0|wumpus|in the case of accounts it'd be a group not one single call
272 2017-09-21 19:21:42	0|wumpus|right
273 2017-09-21 19:21:55	0|luke-jr|this code already fits that paradigm I think, except for the param name
274 2017-09-21 19:21:58	0|achow101|luke-jr: doing that for rpcuser is going to annoy a lot of people
275 2017-09-21 19:22:16	0|luke-jr|achow101: yes, that can be discussed separately; it was an example
276 2017-09-21 19:22:20	0|wumpus|I  think we should keep the discussion of what things to deprecate separate
277 2017-09-21 19:22:27	0|sipa|agree
278 2017-09-21 19:22:34	0|achow101|ok
279 2017-09-21 19:23:56	0|jonasschnelli|removing the account support via -depracaterpc and positioned arguments seems pretty difficult and/or dangerous.
280 2017-09-21 19:24:09	0|jnewbery|achow101: As long as you're happy with that I'll update 11031 with the new name so you can rebase your various RPC deprecation PRs on it
281 2017-09-21 19:24:18	0|luke-jr|"rpc" probably shouldn't be in the arg name.
282 2017-09-21 19:24:44	0|jonasschnelli|users may be confuse why account are deprecated but still work while -depacaterpc=accounts
283 2017-09-21 19:25:00	0|luke-jr|-enabledeprecated seemed nicer IMO
284 2017-09-21 19:25:05	0|achow101|jnewbery: I guess so. I haven't looked over 11031 in a while so I want to review it before rebasing
285 2017-09-21 19:25:13	0|wumpus|jonasschnelli: it's just the account rpcs that are deprecated, accounts themselves will work as labels
286 2017-09-21 19:25:17	0|meshcollider|jonasschnelli: are you suggesting disable the account system completely?
287 2017-09-21 19:25:24	0|meshcollider|(without deprecation)
288 2017-09-21 19:25:49	0|jonasschnelli|wumpus: yes. That makes sense.
289 2017-09-21 19:25:52	0|wumpus|we'll not rip out the account arguments from any non-account RPC calls
290 2017-09-21 19:26:00	0|wumpus|just that move etc are deprecated
291 2017-09-21 19:26:23	0|achow101|topic suggestion: what to deprecate
292 2017-09-21 19:26:37	0|jonasschnelli|But the transition of having a -enabledepracatedrpc= and not disabling the depracated account features seems not to be ideal.. although I guess it's okay
293 2017-09-21 19:27:03	0|wumpus|I doubt there is any ideal way to deprecate a monster like the accounts feature, tbh
294 2017-09-21 19:27:07	0|luke-jr|wumpus: getbalance <non-*> should fail too
295 2017-09-21 19:27:35	0|wumpus|luke-jr: yes
296 2017-09-21 19:28:13	0|luke-jr|jonasschnelli: no "rpc" :/
297 2017-09-21 19:28:16	0|wumpus|do we have any more upbeat topic than deprecation?
298 2017-09-21 19:28:37	0|gmaxwell|China blocking bitcoin?
299 2017-09-21 19:28:39	0|gmaxwell|(not really)
300 2017-09-21 19:28:40	0|meshcollider|segwit wallet support progress?
301 2017-09-21 19:28:44	0|gmaxwell|That
302 2017-09-21 19:28:52	0|wumpus|#topic segwit wallet support progress
303 2017-09-21 19:28:53	0|sipa|i'll have a PR soon
304 2017-09-21 19:28:56	0|wumpus|thanks
305 2017-09-21 19:29:06	0|sipa|otherwise, review #11167
306 2017-09-21 19:29:08	0|gmaxwell|sipa: Have you heard from thomasv about them blocking v>0
307 2017-09-21 19:29:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub
308 2017-09-21 19:29:27	0|achow101|sipa: how soon is soon
309 2017-09-21 19:29:27	0|sipa|gmaxwell: yes, we discussed it in here yesterday
310 2017-09-21 19:29:33	0|sipa|achow101: this week, i hope
311 2017-09-21 19:29:59	0|jonasschnelli|sipa: are you also tackling the GUI?
312 2017-09-21 19:30:05	0|gmaxwell|did you take my advice and call the new file key-i-key-i-o.cpp
313 2017-09-21 19:30:12	0|sipa|jonasschnelli: no, i'll need help for that
314 2017-09-21 19:30:22	0|sipa|gmaxwell: just key_io
315 2017-09-21 19:30:33	0|meshcollider|haha
316 2017-09-21 19:30:36	0|jonasschnelli|sipa: please point me to your branch after the meeting so I can start to work on that
317 2017-09-21 19:30:58	0|sipa|(for context, gmaxwell is talking about the followup #11372, which is not for 0.15.1)
318 2017-09-21 19:30:59	0|gribble|https://github.com/bitcoin/bitcoin/issues/11372 | Address encoding cleanup by sipa · Pull Request #11372 · bitcoin/bitcoin · GitHub
319 2017-09-21 19:31:02	0|gmaxwell|There should be almost no GUI intersection, other than perhaps offering the default overrides in the gui.
320 2017-09-21 19:31:24	0|sipa|yeah, i expect some expert mode setting to choose the address type - but otherwise it can just use the default
321 2017-09-21 19:31:37	0|gmaxwell|oh right, point of use switching, sure.
322 2017-09-21 19:31:50	0|jonasschnelli|sipa: yes. That is what I though...
323 2017-09-21 19:32:08	0|sipa|not that much to say about the topic otherwise
324 2017-09-21 19:32:15	0|gmaxwell|jonasschnelli: another thing in the GUI is that we should eventually have a BIP173 error hinter.  We need a monospace text entry field that can be told to underline characters or something like that.
325 2017-09-21 19:32:26	0|gmaxwell|(not necessarily a 0.15.1 feature in any case)
326 2017-09-21 19:32:30	0|jonasschnelli|Yes! I just wanted to write that
327 2017-09-21 19:32:54	0|gmaxwell|well sipa's bip173 patch doesn't have the error finder in it.
328 2017-09-21 19:33:04	0|sipa|i think there is another question, that ThomasV brought up yesterday
329 2017-09-21 19:33:15	0|sipa|what to do with private key import/export for segwit addresses
330 2017-09-21 19:33:24	0|gmaxwell|Though we've written one (a port of it to JS is on that demo page)... it deserves a nice gui handling though (even the js demo is kind of lame, in that it can't highlight inline)
331 2017-09-21 19:33:34	0|wumpus|some importmulti ?
332 2017-09-21 19:33:35	0|achow101|sipa: importmulti
333 2017-09-21 19:33:37	0|sipa|importmulti can handle this natively
334 2017-09-21 19:33:45	0|wumpus|ok, seems good enough for me then
335 2017-09-21 19:33:50	0|gmaxwell|importmulti was my first thought too.
336 2017-09-21 19:33:55	0|achow101|deprecate the other import* rpcs
337 2017-09-21 19:33:55	0|sipa|but perhaps at least a warning for importprivkey / dumpprivkey is needed
338 2017-09-21 19:34:01	0|wumpus|just highlight that the old import* rpcs don't work with segwit
339 2017-09-21 19:34:08	0|jonasschnelli|sipa: yes. Or depracate?
340 2017-09-21 19:34:12	0|gmaxwell|When we do the changes that split the key types later, we'll have more to think about. Right now any key is all keytypes.
341 2017-09-21 19:34:19	0|wumpus|or deprecate them at some point, but not for a minor release
342 2017-09-21 19:34:31	0|sipa|right
343 2017-09-21 19:34:40	0|gmaxwell|we can announce an intent at any time. (I think we just did.)
344 2017-09-21 19:34:47	0|ThomasV|importmulti does not seem as easy to use as a serialized format
345 2017-09-21 19:34:55	0|wumpus|yes, intent+reason could be menitoned in the release notes
346 2017-09-21 19:35:10	0|sipa|ThomasV: i consider that a feature :)
347 2017-09-21 19:35:13	0|gmaxwell|ThomasV: because of versioning issues, we're not going to solve a new serialized format right now.
348 2017-09-21 19:35:24	0|jonasschnelli|importmulti is a bit cumbersome to use,... but should the okay for an RPC layer
349 2017-09-21 19:35:25	0|wumpus|importing keys in bitcoin core is considered advanced functionality anyhow
350 2017-09-21 19:36:03	0|sipa|ThomasV: as said, i don't mind discussing a more convenient import format for some use case, but we're not going to solve that instantly
351 2017-09-21 19:36:08	0|jonasschnelli|importaddress and key with the current rescan-everything approach must go away at some point anyways
352 2017-09-21 19:36:19	0|wumpus|jonasschnelli: yeah... that too
353 2017-09-21 19:36:26	0|ThomasV|gmaxwell: we were also considering an import format along the lines of bip124
354 2017-09-21 19:36:29	0|gmaxwell|raw key handling frequently results in funds loss, even for advanced users too.. but I do think we should ultimately be embedding the required metadata to actually use a key. but it's not something we can really do right now.
355 2017-09-21 19:36:55	0|achow101|the bech32-for-privkeys thing could be something for segwit only and have a the witness version number included in that?
356 2017-09-21 19:37:10	0|wumpus|achow101: yes
357 2017-09-21 19:37:26	0|sipa|achow101: yes, or no - i'm not sure
358 2017-09-21 19:37:30	0|gmaxwell|achow101: witness version number isn't the right data.
359 2017-09-21 19:37:41	0|sipa|i think we need a 'pure private key' format, which is just a key
360 2017-09-21 19:37:43	0|instagibbs|doesn't tell you how it's being used, specifically
361 2017-09-21 19:37:46	0|sipa|to minimize the data needed for backup
362 2017-09-21 19:37:58	0|wumpus|more like a 'key use'
363 2017-09-21 19:37:59	0|gmaxwell|it effectively needs to communicate the scriptpubkey (perhaps be template reference).
364 2017-09-21 19:38:02	0|sipa|the associated addresses/chains/... can be stored separately
365 2017-09-21 19:38:03	0|jonasschnelli|Not sure if we should really support exporting / importing private keys over an RPC layer in the long run
366 2017-09-21 19:38:15	0|luke-jr|sipa: but if you're going for minimal, you'd backup the seed, not the keys?
367 2017-09-21 19:38:16	0|sipa|jonasschnelli: yeah... that's a hard question
368 2017-09-21 19:38:24	0|gmaxwell|sipa: still needs metadata.
369 2017-09-21 19:38:29	0|sipa|gmaxwell: how so?
370 2017-09-21 19:38:41	0|wumpus|right, you could backup the seed, and some metadata, no need to backup the keys themselves
371 2017-09-21 19:38:43	0|achow101|<scriptpubkey>|<privkey(s)>
372 2017-09-21 19:39:01	0|gmaxwell|I mean you need to know _what_ chains or key types are expected. Otherwise it's a lossy search problem to figure out what you should be actually getting.
373 2017-09-21 19:39:11	0|wumpus|yes
374 2017-09-21 19:39:13	0|sipa|gmaxwell: sure, but i think that can be separate
375 2017-09-21 19:39:48	0|sipa|ideally, your wallet has 1 piece of actually secret data, and then a bunch of chains/addresses/scripts/... that use keys derived from that secret data
376 2017-09-21 19:39:52	0|gmaxwell|it's critical data without which you can't recover the keys... and with which you can.  (maybe you could bruteforce it out, under somewhat reasonble assumptions...)
377 2017-09-21 19:40:09	0|jonasschnelli|Conceptual, we should work towards private key separation with a daemon (or agent) and core only deals with public keys. The private-keys agent/tool could still be in the repository (or different one)
378 2017-09-21 19:40:13	0|gmaxwell|it's also potentially a rather small amount of data.
379 2017-09-21 19:40:31	0|sipa|gmaxwell: an example i came up yesterday is CLTV scripts
380 2017-09-21 19:40:44	0|sipa|there is no way you can enumerate all CLTV scripts from a particular seed
381 2017-09-21 19:41:03	0|gmaxwell|no, indeed, but the inability to back up CLTV cleanly was one of the motivations for CSV.
382 2017-09-21 19:41:17	0|sipa|but perhaps there is no need, if you have built-in backups of the chain data (which don't risk monetary loss), and a separate backup of the private key
383 2017-09-21 19:41:31	0|luke-jr|so three levels of data really: the seed itself, the types/chains/etc, and the comments/labels
384 2017-09-21 19:41:37	0|sipa|the private key in that case is just a piece of secret data, referred to by the chains
385 2017-09-21 19:41:49	0|gmaxwell|asking people to handle two critical to maintain pieces of information instead of one would be unfortunate.
386 2017-09-21 19:42:11	0|gmaxwell|(and by unfortunate I mean result in non-negligible funds loss in practice)
387 2017-09-21 19:42:25	0|luke-jr|gmaxwell: maybe concatenate seed + types/chains/etc in practice
388 2017-09-21 19:42:36	0|sipa|sure, for simple situations you can create a convenient format that handles both simultaneously
389 2017-09-21 19:42:39	0|gmaxwell|sure. that would be okay to.
390 2017-09-21 19:42:40	0|wumpus|you could encode it into one identifier somehow...
391 2017-09-21 19:42:44	0|wumpus|sounds easy enough
392 2017-09-21 19:42:45	0|gmaxwell|(re to both luke and sipa)
393 2017-09-21 19:43:00	0|sipa|but i expect there to be cases where you really just want to backup a key, and will handle the metadata (which is too complicated) yourself
394 2017-09-21 19:43:03	0|gmaxwell|the logical seperation sounds fine, but for at least the common case there should be some format for combined data.
395 2017-09-21 19:43:22	0|sipa|sure
396 2017-09-21 19:43:23	0|morcos|+1 for the common case combined format
397 2017-09-21 19:43:33	0|gmaxwell|A possible metadata flag is  'external, good luck'. :)
398 2017-09-21 19:44:14	0|jonasschnelli|X509
399 2017-09-21 19:44:21	0|sipa|JSONx!!
400 2017-09-21 19:44:22	0|ThomasV|lol
401 2017-09-21 19:44:41	0|wumpus|you could always back up the key and metadata separately, then combine them before importing, or have import accept multiple formats, this is just details
402 2017-09-21 19:44:50	0|gmaxwell|Could just have a box where people can just type in x86 machine code and it will decode the result for you ...  almost as flexible as x509.
403 2017-09-21 19:44:58	0|gmaxwell|:-)
404 2017-09-21 19:45:10	0|luke-jr|XD
405 2017-09-21 19:45:21	0|sipa|ok, other topics?
406 2017-09-21 19:45:30	0|wumpus|nice, though too easy to use, should be some ancient 8-bit assembly like z80 or 6502
407 2017-09-21 19:46:09	0|sipa|INTERCAL
408 2017-09-21 19:46:14	0|luke-jr|suggested topic: it would be really nice to get #7533 in, since it is a constant rebase hell otherwise; comments on how to improve the code quality (ugh, macros) appreciated
409 2017-09-21 19:46:15	0|gribble|https://github.com/bitcoin/bitcoin/issues/7533 | RPC: sendrawtransaction: Allow the user to ignore/override specific rejections by luke-jr · Pull Request #7533 · bitcoin/bitcoin · GitHub
410 2017-09-21 19:46:17	0|gmaxwell|I've had to use 6502 assembly in the last couple years ... (for a mystery hunt puzzle)
411 2017-09-21 19:46:26	0|wumpus|yeah
412 2017-09-21 19:47:08	0|gmaxwell|other topics: did people see on the mailing list that there is a new Dandelion post?
413 2017-09-21 19:47:08	0|wumpus|gmaxwell: did you still manage to? :)
414 2017-09-21 19:47:17	0|jnewbery|wumpus: you suggested topic high-priority for review earlier. Did you want to discuss individual PRs or were you just asking if people had PRs they want added to the list?
415 2017-09-21 19:47:39	0|meshcollider|https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html
416 2017-09-21 19:47:43	0|wumpus|#topic Dandelion post
417 2017-09-21 19:48:19	0|wumpus|jnewbery: both is ok, though there are too many PRs on the list right now, would prefer some to be reviewed first - the point of it focusing review is lost if we just add all PRs in there :)
418 2017-09-21 19:48:39	0|gmaxwell|I don't know that I have much to say, other that I thought it should get some attention (I know not everyone reads the list closely). I think this will be a good thing to implement and the people working on it are pretty eager.
419 2017-09-21 19:48:49	0|gmaxwell|(and responsive)
420 2017-09-21 19:49:41	0|jnewbery|wumpus: ok, tit-for-tat. I'll review a couple of those in the next week. Can you add #10740. I think it's ready for initial review
421 2017-09-21 19:49:41	0|wumpus|thanks for mentioning it, I indeed missed it
422 2017-09-21 19:49:42	0|gribble|https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
423 2017-09-21 19:49:55	0|wumpus|#link https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html
424 2017-09-21 19:50:21	0|BlueMatt|though I havent read the dandelion stuff much
425 2017-09-21 19:50:43	0|wumpus|jnewbery: ok added
426 2017-09-21 19:50:44	0|gmaxwell|BlueMatt: externally to it. Basically it's a quiet forwarding thing that has little to no mempool interaction.
427 2017-09-21 19:50:54	0|jnewbery|wumpus: thanks!
428 2017-09-21 19:50:59	0|gmaxwell|BlueMatt: so that public distribution of transactions happens away from the source.
429 2017-09-21 19:51:36	0|BlueMatt|gmaxwell: well based on the dandelion tl; dr i just got, it seems to me that dandelion is essentially the old mempool-sync proposal of "relay txn to only one, maybe two peers but then do sync of your mempool with your peers every so often to propagate things more fully"
430 2017-09-21 19:51:48	0|BlueMatt|except they replace sync with "broadcast after a while"
431 2017-09-21 19:52:08	0|gmaxwell|BlueMatt: kind of. it's not in your mempool though when it passes through in the one at a time propagation.
432 2017-09-21 19:52:36	0|sipa|BlueMatt: but dandelion has rebroadcast too, which can't be avoided (if you dandelion-forwarded a TX, but don't see it N seconds later on the normal network, you yourself start broadcasting it normally)
433 2017-09-21 19:52:58	0|morcos|sipa: why not dandelion it again?
434 2017-09-21 19:53:24	0|BlueMatt|sipa: yes, I'm asking for comparison between dandelion and the old mempool-sync proposal of gmaxwell
435 2017-09-21 19:53:35	0|sipa|morcos: the dandelion stem isn't expected to reach the entire network
436 2017-09-21 19:53:55	0|BlueMatt|it sounds to me like the gmaxwell proposal is effeciely similar, though maybe dandelion pointed out (correctly, I suppose) that you want to not add it to your mempool until later to preserve privacy
437 2017-09-21 19:53:57	0|sipa|so you still need something outside of dandelion-forward and mempool reconciliation
438 2017-09-21 19:54:00	0|gmaxwell|Peer hands you a txn with a private flag. Assuming the txn is valid wrt your mempool, you set it aside and forward it on to a single other peer (determinstically selected based on the input peer).  At random, you drop the private flag when you relay it with some fixed probablity.   If the txn is offered by other peers you fetch it.
439 2017-09-21 19:54:37	0|gmaxwell|If after a timeout you never see it from other peers you broadcast it yourself.. but that only happens if someone in the 'stem' path drops the ball.
440 2017-09-21 19:54:57	0|sipa|BlueMatt: there seems to be some overlap, but i don't think dandelion+sync is a complete solution
441 2017-09-21 19:55:08	0|gmaxwell|so it is similar to my relay improvement proposal, but the privacy requirements mean that it doesn't accomplish syncing itself.
442 2017-09-21 19:55:12	0|morcos|sipa: hmm, i was just asking if you didn't see it, why you wouldn't repeat the whole process assuming the stem got cut somehwere, and hoping that you can get to the fluff on try 2.  why fall back to old method
443 2017-09-21 19:55:39	0|BlueMatt|wait, wait doesnt "(determinstically selected based on the input peer)" imply that you can still group transactions from a single source based on where you first saw them....sure where you first saw them wont be the guy who created it, but it'll still be the same for all txn from the same guy
444 2017-09-21 19:55:45	0|BlueMatt|maybe I should shut up and go read it
445 2017-09-21 19:55:45	0|sipa|morcos: the 'fluff' is just normal tx relay
446 2017-09-21 19:55:49	0|gmaxwell|BlueMatt: so it is like my relay bandwidth improving proposal, without improving relay bandwidth. :P
447 2017-09-21 19:56:21	0|BlueMatt|heh, yea, ok
448 2017-09-21 19:56:29	0|gmaxwell|BlueMatt: only if you are inside the stem yourself.  (this was a change their latest work makes)
449 2017-09-21 19:56:38	0|BlueMatt|hmm, alright
450 2017-09-21 19:57:25	0|gmaxwell|the tradeoff is that if you don't do the determinstic routing and the sender sends lots of txn you are certian to be in the stem for some of them.
451 2017-09-21 19:57:50	0|gmaxwell|basically related to the guardnodes problem in tor.
452 2017-09-21 19:58:39	0|gmaxwell|in any case, it would be good to have more critical eyes on their design. I've only just started thinking about the implications of the change to determinstic paths.
453 2017-09-21 20:00:02	0|sipa|PLOINK
454 2017-09-21 20:00:12	0|wumpus|yes, extrememly important for privacy to not make any mistakes here
455 2017-09-21 20:00:18	0|wumpus|#endmeeting
456 2017-09-21 20:00:20	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-21-19.00.log.html
457 2017-09-21 20:00:20	0|lightningbot|Meeting ended Thu Sep 21 20:00:18 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
458 2017-09-21 20:00:20	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-21-19.00.html
459 2017-09-21 20:00:20	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-09-21-19.00.txt
460 2017-09-21 20:00:37	0|gmaxwell|wumpus: At least the current behavior is weak enough that it would be hard to not make an improvement. :)
461 2017-09-21 20:00:51	0|BlueMatt|hah, yea, that ^
462 2017-09-21 20:02:25	0|wumpus|sure
463 2017-09-21 20:04:40	0|gmaxwell|unrelated, my gpg encryption subkey expired a bit ago.  I just replaced it with a newly generated one... with the rationale that its good to rotate such things, and unlike identity keys, easy to rotate them. I can still decrypt with the old one for now.
464 2017-09-21 20:05:13	0|wumpus|your new key is on the keyserver?
465 2017-09-21 20:05:37	0|achow101|does anyone know when verack was added to the protocol? It's not in the first version but I can't find any documentation about it
466 2017-09-21 20:05:51	0|wumpus|apparently it is, refresh-key worked gpg:            new subkeys: 1
467 2017-09-21 20:06:03	0|gmaxwell|wumpus: yes. as of about the beginning of the meeting.
468 2017-09-21 20:06:19	0|sipa|achow101: 0.2.9
469 2017-09-21 20:08:04	0|achow101|sipa: thanks
470 2017-09-21 20:08:44	0|wumpus|sipa: achow101: seems it's missing here https://bitcoin.org/en/developer-reference#protocol-versions
471 2017-09-21 20:09:02	0|achow101|wumpus: yeah, I noticed
472 2017-09-21 20:09:04	0|wumpus|only mentions adding the checksum field there
473 2017-09-21 20:09:18	0|achow101|I assume that's because that's all the commit message mentions too
474 2017-09-21 20:09:20	0|wumpus|please file a PR :)
475 2017-09-21 20:10:07	0|luke-jr|FYI https://www.blackhat.com/eu-17/briefings/schedule/#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine-8668
476 2017-09-21 20:10:45	0|wumpus|luke-jr: :-(
477 2017-09-21 20:13:12	0|BlueMatt|#11116 could probably use a merge
478 2017-09-21 20:13:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/11116 | [script] Unit tests for script/standard and IsMine functions. by jimpo · Pull Request #11116 · bitcoin/bitcoin · GitHub
479 2017-09-21 20:16:47	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/98212745c8ac...49f3d57eeb66
480 2017-09-21 20:16:48	0|bitcoin-git|13bitcoin/06master 147a1e873 15Jim Posen: [script] Unit tests for IsMine...
481 2017-09-21 20:16:48	0|bitcoin-git|13bitcoin/06master 14d7afe2d 15Jim Posen: [script] Unit tests for script/standard functions
482 2017-09-21 20:16:49	0|bitcoin-git|13bitcoin/06master 1449f3d57 15Wladimir J. van der Laan: Merge #11116: [script] Unit tests for script/standard and IsMine functions....
483 2017-09-21 20:17:24	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11116: [script] Unit tests for script/standard and IsMine functions. (06master...06script-standard-tests) 02https://github.com/bitcoin/bitcoin/pull/11116
484 2017-09-21 21:40:19	0|promag|wumpus: jnewbery: is there a strong reason to #10740 have high priority review?
485 2017-09-21 21:40:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
486 2017-09-21 21:42:32	0|jnewbery|promag: because it's likely to take quite a bit of review and I'd like it in for 0.16. It will also provide a resolution to the keypool topup corner cases that prevented a full fix for that issue getting into v0.15.
487 2017-09-21 21:44:15	0|luke-jr|#10615 and GUI support should go before 10740..
488 2017-09-21 21:44:17	0|gribble|https://github.com/bitcoin/bitcoin/issues/10615 | RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet (multiwallet RPC support) by luke-jr · Pull Request #10615 · bitcoin/bitcoin · GitHub
489 2017-09-21 21:44:59	0|luke-jr|far more important to be able to actually use it, than dynamic open/close
490 2017-09-21 21:46:16	0|promag|luke-jr: no PR for GUI support right?
491 2017-09-21 21:50:13	0|luke-jr|promag: no, because it's built on top of 10615
492 2017-09-21 21:50:37	0|luke-jr|promag: the branch is named multiwallet_gui
493 2017-09-21 21:50:58	0|promag|mind I take a look?
494 2017-09-21 21:54:18	0|promag|so the concept is to have a combobox to choose the wallet in the mainwindow?
495 2017-09-21 21:54:42	0|luke-jr|promag: yes, it works pretty well
496 2017-09-21 21:55:41	0|luke-jr|been shipping it in Knots since 0.13 ;)
497 2017-09-21 21:56:41	0|luke-jr|maybe I should open a PR so it at least has that
498 2017-09-21 21:56:44	0|promag|does it restores the current wallet when it starts?
499 2017-09-21 21:56:54	0|luke-jr|promag: no
500 2017-09-21 21:57:21	0|luke-jr|maybe it should
501 2017-09-21 21:57:37	0|promag|yeah, like the geometry stuff
502 2017-09-21 22:08:58	0|luke-jr|promag_: not sure it makes sense for the wallet, since presumably you'd be using all the wallets (you don't reposition the GUI geometry normally)
503 2017-09-21 22:09:25	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #11383: Basic Multiwallet GUI support (06master...06multiwallet_gui) 02https://github.com/bitcoin/bitcoin/pull/11383
504 2017-09-21 22:12:06	0|promag|nowadays apps usually restore the state
505 2017-09-21 22:12:12	0|promag|"you continue where you left"
506 2017-09-21 22:12:43	0|promag|tks for the PR
507 2017-09-21 22:13:10	0|promag|we can explore that idea later