1 2017-08-31 00:41:13	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #11200: Allow for aborting rescans and canceling showProgress dialogs (06master...06gui-recan-abort) 02https://github.com/bitcoin/bitcoin/pull/11200
  2 2017-08-31 02:30:54	0|achow101|I don't suppose it is possible to lock the comments on the first commit?
  3 2017-08-31 02:45:18	0|sipa|achow101: i don't see an option to do that
  4 2017-08-31 02:45:30	0|achow101|darn
  5 2017-08-31 02:55:03	0|jl2012|i have a question about this line: https://github.com/bitcoin/bitcoin/blob/master/src/validation.h#L376 . Is is same as std::swap(scriptPubKey, check.scriptPubKey); ?
  6 2017-08-31 03:02:07	0|sipa|jl2012: yes
  7 2017-08-31 03:02:26	0|sipa|std::swap also works for primitive types
  8 2017-08-31 03:04:02	0|jl2012|thanks sipa. I have another question about my patch here: https://github.com/bitcoin/bitcoin/pull/10953/files#diff-349fbb003d5ae550a2e8fa658e475880L368 .
  9 2017-08-31 03:04:03	0|jl2012|As I replace amount+scriptPubKey with CTxOut, the default value of amount becomes -1. It should be ok?
 10 2017-08-31 03:05:20	0|sipa|sounds fine
 11 2017-08-31 03:05:44	0|sipa|perhaps add an assert to check that it's not -1 for any actual validation
 12 2017-08-31 03:05:52	0|sipa|or at least not for a witness validation
 13 2017-08-31 03:10:23	0|jl2012|sipa: it sounds already like a serious bug if the validation would use the default value, 0 or -1. Maybe -1 is actually better because it must be invalid
 14 2017-08-31 04:19:13	0|bitcoin-git|[13bitcoin] 15justicz opened pull request #11201: [RPC] Add verifyrawtransaction RPC (06master...06maxj_add_verify_tx_rpc) 02https://github.com/bitcoin/bitcoin/pull/11201
 15 2017-08-31 07:42:46	0|jl2012|is there any easy way to list all segwit txs in the mempool?
 16 2017-08-31 13:01:31	0|wumpus|I won't be at the dev meeting today - just getting settled in here at SF and have a few days holiday
 17 2017-08-31 13:07:29	0|instagibbs|Synced rc3 in 5 hours on my laptop with default dbcache, very tame IO use. Very nice work!
 18 2017-08-31 13:43:24	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #11203: RPC: add wtxid to mempool entry output (06master...062017-08-add-wtxid-to-mempool-entry) 02https://github.com/bitcoin/bitcoin/pull/11203
 19 2017-08-31 13:44:50	0|sdaftuar|jl2012: i don't see an easy way to list all segwit tx's in the mempool currently, but i just opened #11203 which would make it pretty straightforward (just compare txid to wtxid)
 20 2017-08-31 15:07:44	0|gmaxwell|sdaftuar: this should work: ./bitcoin-cli getblocktemplate | jq '.transactions | .[] | select(.hash != .txid) | .txid'
 21 2017-08-31 15:07:58	0|gmaxwell|but that only does it with the blocktemplate.
 22 2017-08-31 15:09:59	0|sdaftuar|gmaxwell: yeah so that only gets segwit tx's in the top of the mempool, rather than the whole mempool
 23 2017-08-31 15:10:11	0|sdaftuar|btw you just improved my life substantially by teaching me about jq
 24 2017-08-31 15:12:09	0|sstone|hi, I have a question about SPV nodes: does bitcoin core include tx witness data in filtered blocks sent to SPV client ?
 25 2017-08-31 15:13:16	0|sdaftuar|sstone: not currently, though there's an open PR on that topic.  see #10350
 26 2017-08-31 15:13:31	0|bitcoin-git|[13bitcoin] 15santyraghavan opened pull request #11204: Merge pull request #1 from bitcoin/master (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11204
 27 2017-08-31 15:16:30	0|sstone|sdaftuar: thanks !
 28 2017-08-31 15:22:25	0|gmaxwell|sstone: if you have a usecase for that I'd like to learn more. I understand codeshark's and I assume we'll do it for his but his is kind of weird and obscure.
 29 2017-08-31 15:27:28	0|sstone|our use case is light-weight (mobile for example) LN compatible wallets. There are cases when you will want to monitor the blockchain and extract preimages from witness data
 30 2017-08-31 16:46:27	0|bitcoin-git|[13bitcoin] 15jnewbery closed pull request #10591: [tests] make pruning.py faster (06master...06fastprune) 02https://github.com/bitcoin/bitcoin/pull/10591
 31 2017-08-31 17:14:19	0|illpadrino|hello all
 32 2017-08-31 17:14:51	0|illpadrino|Does anyone have experience with Bitcoin ATM? I am thinking to put one in Paraguay
 33 2017-08-31 17:23:05	0|Lauda|Wrong chat, go to #bitcoin.
 34 2017-08-31 17:28:49	0|warren|https://github.com/bitcoincore/  is this associated with anyone here?
 35 2017-08-31 17:29:23	0|gmaxwell|warren: IIRC it's controlled by a github employee and they refused to give it up.
 36 2017-08-31 17:56:26	0|luke-jr|it was annoying to have to constantly explain to people that Core is not Bitcoin
 37 2017-08-31 18:00:05	0|warren|Could rename it to Badger? (only half joking)
 38 2017-08-31 18:00:37	0|warren|jonasschnelli: https://github.com/bitcoin/bitcoin/pull/9483  will you be able to rebase this soon?
 39 2017-08-31 18:02:15	0|instagibbs|luke-jr, NotBitcoin
 40 2017-08-31 18:02:21	0|instagibbs|agreed with luke-jr
 41 2017-08-31 18:20:30	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11204: Merge pull request #1 from bitcoin/master (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11204
 42 2017-08-31 18:25:35	0|bitcoin-git|[13bitcoin] 15danra opened pull request #11205: Make fixed CAmounts and related sanity function constexpr (06master...06refactor/constexpr-amount) 02https://github.com/bitcoin/bitcoin/pull/11205
 43 2017-08-31 18:31:24	0|asimplecoder|hey
 44 2017-08-31 18:31:31	0|asimplecoder|anyone online?
 45 2017-08-31 18:35:52	0|sipa|no
 46 2017-08-31 18:37:56	0|bitcoin-git|[13bitcoin] 15polyetilen opened pull request #11206: Update optionsdialog.ui (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/11206
 47 2017-08-31 19:01:46	0|achow101|Meeting?
 48 2017-08-31 19:02:11	0|sdaftuar|here
 49 2017-08-31 19:02:16	0|jnewbery|hello
 50 2017-08-31 19:02:23	0|meshcollider|hi
 51 2017-08-31 19:02:36	0|sipa|hi
 52 2017-08-31 19:02:54	0|cfields|hi
 53 2017-08-31 19:04:10	0|sdaftuar|wumpus said above that he'd be skipping today
 54 2017-08-31 19:04:46	0|achow101|Oh
 55 2017-08-31 19:05:10	0|cfields|well we can still discuss :)
 56 2017-08-31 19:05:11	0|luke-jr|hi
 57 2017-08-31 19:05:15	0|cfields|gmaxwell: have your mass ping handy?
 58 2017-08-31 19:05:35	0|achow101|Whatever shall we do without our fearless leader? :P
 59 2017-08-31 19:05:50	0|luke-jr|someone should do the startmeeting command
 60 2017-08-31 19:05:54	0|luke-jr|(and chair)
 61 2017-08-31 19:05:55	0|sipa|#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
 62 2017-08-31 19:05:59	0|lightningbot|Meeting started Thu Aug 31 19:05:58 2017 UTC.  The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
 63 2017-08-31 19:05:59	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 64 2017-08-31 19:05:59	0|sipa|#startmeeting
 65 2017-08-31 19:06:13	0|sipa|I'm not sure whether gmaxwell is available right now
 66 2017-08-31 19:06:27	0|sipa|topics?
 67 2017-08-31 19:06:40	0|meshcollider|it still lists wumpus as present lol
 68 2017-08-31 19:07:13	0|achow101|Anything with 0.15.0?
 69 2017-08-31 19:07:17	0|luke-jr|meshcollider: it's not a list of present people, just a mention to wake them up
 70 2017-08-31 19:07:19	0|gmaxwell|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101
 71 2017-08-31 19:07:24	0|gmaxwell|I'm not really here.
 72 2017-08-31 19:07:28	0|kanzure|hi.
 73 2017-08-31 19:07:45	0|luke-jr|achow101: there's a string issue, but not sure it matters much
 74 2017-08-31 19:07:50	0|luke-jr|the debug log tooltip IIRC
 75 2017-08-31 19:07:57	0|cfields|any observed 0.15 bugs?
 76 2017-08-31 19:07:58	0|sipa|what is up with #11198?
 77 2017-08-31 19:08:08	0|kanzure|next meeting unlikely to be on irc
 78 2017-08-31 19:08:24	0|achow101|(I'm not really here, hard to irc on a bike)
 79 2017-08-31 19:09:02	0|gmaxwell|cfields: there was someone complaining rc3 is crashing on windows
 80 2017-08-31 19:09:10	0|luke-jr|what is #11198? (I'm stuck at CLI)
 81 2017-08-31 19:09:14	0|morcos|heh, i am here, for a change
 82 2017-08-31 19:09:18	0|sipa|#topic 0.15.0
 83 2017-08-31 19:09:20	0|cfields|sipa: heh, that hardly seems like something worth waiting for
 84 2017-08-31 19:09:23	0|gmaxwell|achow101 was going to try reproducing.
 85 2017-08-31 19:09:25	0|sipa|luke-jr: Fix display of package name on 'open config file' tooltip
 86 2017-08-31 19:09:33	0|cfields|gmaxwell: hmm, link? or discussion?
 87 2017-08-31 19:09:48	0|achow101|The rc3 problem was fixed with iirc
 88 2017-08-31 19:09:59	0|achow101|(the windows crash thing)
 89 2017-08-31 19:10:04	0|instagibbs|present
 90 2017-08-31 19:10:11	0|gmaxwell|cfields: https://bitcointalk.org/index.php?topic=2132893.0
 91 2017-08-31 19:10:20	0|instagibbs|gmaxwell, running fine here on windows fwiw
 92 2017-08-31 19:10:22	0|gmaxwell|ohcrap this again:
 93 2017-08-31 19:10:22	0|luke-jr|IMO a tooltip doesn't need to block final, but since we're waiting a week anyway, might as well do a RC with it? (maybe merge in the -acceptnonstdtxn fix too)
 94 2017-08-31 19:10:23	0|gmaxwell|Problem solved!  Running bitcoin-qt with the '-resetguisettings' switch fixed it.  Thanks to MeshCollider on github for the fix! Smiley
 95 2017-08-31 19:10:36	0|gmaxwell|^ that is now the third person I've seen screwed by this.
 96 2017-08-31 19:10:45	0|gmaxwell|did we change something that created this problem
 97 2017-08-31 19:10:48	0|luke-jr|gmaxwell: that's the crash?
 98 2017-08-31 19:10:55	0|gmaxwell|luke-jr: apparently it wasn't actually a crash
 99 2017-08-31 19:11:08	0|gmaxwell|the symptom is you start bitcoin and it vanishes after the splash
100 2017-08-31 19:11:11	0|sipa|just the window appearing in an offscreen location?
101 2017-08-31 19:11:18	0|luke-jr|ah
102 2017-08-31 19:11:21	0|sipa|can we add a test for that?
103 2017-08-31 19:11:33	0|luke-jr|sipa: we do already IIRC
104 2017-08-31 19:11:36	0|sipa|(if window is beyond screen coordinates, reset gui settings automatically)
105 2017-08-31 19:11:38	0|sipa|jonasschnelli: ^
106 2017-08-31 19:11:59	0|gmaxwell|16:19 < gmaxwell> jonasschnelli: I just had someone on IRC that had their GUI not displaying after upgrading to 0.14.2 ... this fixed it https://github.com/bitcoin/bitcoin/issues/7869#issuecomment-209265754  is there some underlying bug we need to fix?
107 2017-08-31 19:12:03	0|gmaxwell|11:19 < jonasschnelli> gmaxwell: most possible problem of a not-appearing GUI is probably persisted windows coordinates outside of the screen boundaries.
108 2017-08-31 19:12:06	0|gmaxwell|11:20 < jonasschnelli> could be fixed by checking the screen bounds against the QSettings coords
109 2017-08-31 19:12:09	0|gmaxwell|11:21 < jonasschnelli> -resetguisettings will just evict all user based Qt overrides (and things like window coordinates)
110 2017-08-31 19:12:13	0|meshcollider|#11171 for reference
111 2017-08-31 19:12:17	0|sipa|thnaks
112 2017-08-31 19:12:55	0|gmaxwell|it worries me that I've never seen this complain before and now three in a few weeks, all with people testing 0.15rc
113 2017-08-31 19:13:05	0|gmaxwell|complaint*
114 2017-08-31 19:13:11	0|luke-jr|gmaxwell: could it be the Qt version bump?
115 2017-08-31 19:13:23	0|gmaxwell|thats beyond my pay grade to speculate.
116 2017-08-31 19:14:07	0|cfields|gmaxwell: all windows complaints?
117 2017-08-31 19:14:12	0|gmaxwell|yes
118 2017-08-31 19:14:13	0|luke-jr|a shame the users have done the workaround..
119 2017-08-31 19:14:29	0|gmaxwell|it's a pretty bad failure mode, silently gone...
120 2017-08-31 19:14:33	0|luke-jr|if we can get it reproduced again, it'd be nice to get the registry entries involved
121 2017-08-31 19:14:37	0|cfields|i wonder if they're all multi-monitor
122 2017-08-31 19:14:50	0|gmaxwell|luke-jr: well I told one to do it because it was a hail mary... I had no idea it would actually fix it.
123 2017-08-31 19:14:54	0|luke-jr|cfields: hmm, monitors of different sizes maybe?
124 2017-08-31 19:15:16	0|gmaxwell|we can ask.
125 2017-08-31 19:15:23	0|cfields|luke-jr: i was thinking: bitcoin-qt on monitor 2, shutdown, restart with only monitor 1
126 2017-08-31 19:15:31	0|luke-jr|I could totally see different-sized monitors confusing this
127 2017-08-31 19:15:46	0|luke-jr|cfields: am I wrong that we don't check for visible coordinates?
128 2017-08-31 19:15:51	0|luke-jr|err, that we do*
129 2017-08-31 19:16:16	0|luke-jr|(which would probably fail if the monitors are different sizes, due to blocked-off regions within the total dimensions)
130 2017-08-31 19:16:22	0|cfields|luke-jr: no clue
131 2017-08-31 19:17:17	0|achow101|Gmaxwell: I believe it's a registry problem
132 2017-08-31 19:17:41	0|achow101|Since qsettings stores things in registry
133 2017-08-31 19:18:05	0|sipa|achow101: i think the registry is just a storage medium
134 2017-08-31 19:18:28	0|gmaxwell|did we just start doing this... or
135 2017-08-31 19:18:52	0|sipa|i think bitcoin-qt has done that since forver, and nothing changed wrt to that now
136 2017-08-31 19:18:56	0|achow101|Gmaxwell: I don't think so. It's been reported a few times before with older versions
137 2017-08-31 19:19:13	0|meshcollider|relevant code? https://github.com/bitcoin/bitcoin/blob/master/src/qt/guiutil.cpp#L852
138 2017-08-31 19:20:16	0|BlueMatt|we always see a flood of reports of old issues upon new rc's
139 2017-08-31 19:20:37	0|gmaxwell|yea, okay!
140 2017-08-31 19:21:20	0|MarcoFalke|The "Fix for issues with startup and multiple monitors on windows." is already included https://github.com/bitcoin/bitcoin/commit/e9ff818b69c2f8ce4a151d1a81a3e22a4319c93d
141 2017-08-31 19:22:25	0|ryanofsky|that doesn't seem like a sufficient fix if x and y are just outside screen geometry
142 2017-08-31 19:22:33	0|jtimon|anything else regarding 0.15 ?
143 2017-08-31 19:22:41	0|luke-jr|MarcoFalke: new in 0.15?
144 2017-08-31 19:22:47	0|luke-jr|maybe it's the problem..?
145 2017-08-31 19:22:47	0|MarcoFalke|jup
146 2017-08-31 19:23:04	0|MarcoFalke|Yes, I think the fix is not sufficient
147 2017-08-31 19:24:01	0|ryanofsky|would need to add || pos.x() > screen.width() || pos.y() > screen.height()
148 2017-08-31 19:24:17	0|gmaxwell|from that code it looks obvious how to fix this.
149 2017-08-31 19:24:19	0|gmaxwell|what ryanofsky said
150 2017-08-31 19:24:33	0|gmaxwell|well almost obvious
151 2017-08-31 19:24:47	0|luke-jr|that won't work for the different-sizes scenario, but sure
152 2017-08-31 19:24:49	0|achow101|replicated the problem. will write up how in the issue after this class I am in
153 2017-08-31 19:24:50	0|gmaxwell|ryanofsky: that one will lets the window be at width(),height(). :P
154 2017-08-31 19:24:55	0|BlueMatt|yea, no idea what QApplication::desktop()->screenNumber(parent) == -1 does, but guess it doesnt work on win....someone able to test?
155 2017-08-31 19:25:06	0|achow101|tl;dr look at the registry for qsettings for nWindowPos
156 2017-08-31 19:25:21	0|ryanofsky|BlueMatt, that is probably the check for no longer connected multimonitor
157 2017-08-31 19:25:48	0|meshcollider|^^ if its -1 means the screen doesn't exist
158 2017-08-31 19:25:50	0|achow101|if the setting is for an off screen point, nothing will show
159 2017-08-31 19:25:59	0|gmaxwell|yea but it may do nothing on windows, perhaps on windows the window is just off screen.
160 2017-08-31 19:26:09	0|BlueMatt|ryanofsky: yea, but that should work if you're on no screen? no idea
161 2017-08-31 19:26:20	0|BlueMatt|anyway, I'll stop speculating above my paygrade
162 2017-08-31 19:26:38	0|sipa|can someone open a bug?
163 2017-08-31 19:26:52	0|BlueMatt|^ that
164 2017-08-31 19:27:15	0|gmaxwell|just reopen 7869 perhaps
165 2017-08-31 19:27:21	0|jtimon|perhaps also PR ryanofsky's potential solution ?
166 2017-08-31 19:27:24	0|sipa|i don't think we need to solve this problem in this meeting (though there seem few other topics)
167 2017-08-31 19:27:33	0|ryanofsky|i think achow101 said he would write it up?
168 2017-08-31 19:27:41	0|luke-jr|so that's 3 things for an rc4 I guess?
169 2017-08-31 19:27:47	0|sipa|luke-jr: 3?
170 2017-08-31 19:27:52	0|achow101|I'll make a new issue with the thing I just found
171 2017-08-31 19:27:52	0|gmaxwell|We should talk about progress for full segwit support.
172 2017-08-31 19:27:53	0|meshcollider|whats the 3rd?
173 2017-08-31 19:27:58	0|instagibbs|gmaxwell, ack
174 2017-08-31 19:28:07	0|luke-jr|sipa: 1) positioning; 2) debug log tooltip; 3) acceptnonstdtxn help
175 2017-08-31 19:28:07	0|sipa|achow101: thanks!
176 2017-08-31 19:28:29	0|morcos|i know i'm the cause of rc3, but i actually advocate for drawing the line somewhere
177 2017-08-31 19:28:32	0|luke-jr|maybe 4) Polish translation update
178 2017-08-31 19:28:41	0|morcos|it wasn't clear to me if we have to wait 2 weeks now until we have a new RC
179 2017-08-31 19:28:53	0|luke-jr|morcos: IMO the positioning issue is sufficient to warrant rc4
180 2017-08-31 19:28:56	0|morcos|if so i think none of those are maybe sufficient for RC4
181 2017-08-31 19:29:00	0|sipa|morcos: let's discuss this when wumpus is available
182 2017-08-31 19:29:22	0|luke-jr|especially if users are encountering it
183 2017-08-31 19:29:27	0|morcos|ok. at the very least lets, note that its a question, instead of a conclusion that there will be RC4
184 2017-08-31 19:29:28	0|meshcollider|yeah and first lets make sure the fix for the positioning issue actually solves the problem lol
185 2017-08-31 19:29:33	0|morcos|luke-jr: but there is a workaround no?
186 2017-08-31 19:29:47	0|morcos|how much valuable info do you lose my resetguisettings
187 2017-08-31 19:29:47	0|sipa|meshcollider: indeed
188 2017-08-31 19:29:52	0|luke-jr|morcos: not a nice one - you lose all your other GUI settings
189 2017-08-31 19:29:59	0|achow101|morcos: all gui settings
190 2017-08-31 19:30:07	0|achow101|it can also be fixed with regedt
191 2017-08-31 19:30:12	0|sipa|achow101 said he'd open a bug with relevant information - let's discuss there when we have that
192 2017-08-31 19:30:23	0|luke-jr|k
193 2017-08-31 19:30:27	0|sipa|#topic full segwit support
194 2017-08-31 19:31:38	0|sipa|i have a question: should we 1) automatically add witness redeem scripts for newly generated addresses, or 2) bypass the restriction that the redeemscript must be available for P2WPKH when the pubkey itself is available?
195 2017-08-31 19:32:08	0|morcos|sipa: could you explain that a bit more thoroughly
196 2017-08-31 19:32:19	0|BlueMatt|sipa: #1
197 2017-08-31 19:32:22	0|sipa|the downside of 2) is that we'd accept segwit payments to converted-p2pkh-to-p2wpkh addresses (which i think is a bad property), but that it significantly reduced the overhead of adding a key
198 2017-08-31 19:32:30	0|meshcollider|I'd say 1 is better
199 2017-08-31 19:33:07	0|BlueMatt|i guess drawback of 1 is you cant receive via segwit to old addresses?
200 2017-08-31 19:33:10	0|BlueMatt|I'm ok with that
201 2017-08-31 19:33:20	0|sipa|BlueMatt: i would call that an advantage
202 2017-08-31 19:33:24	0|BlueMatt|agreed
203 2017-08-31 19:33:30	0|sipa|ideally we don't accept anything to an address that wasn't given out
204 2017-08-31 19:33:41	0|sdaftuar|^ that
205 2017-08-31 19:33:42	0|gmaxwell|we should really try to avoid accepting an address that we'd never issue if at all possible, it's very dangerous if people think they can do that and have it work.
206 2017-08-31 19:33:50	0|meshcollider|I guess there'd still be a way to manually do it if you wanted to though right?
207 2017-08-31 19:33:52	0|luke-jr|indeed, if we accept segwit to non-segwit addresses, people might get a false impression it's supported, and lose money
208 2017-08-31 19:33:54	0|Chris_Stewart_5|is #1 really that expensive?
209 2017-08-31 19:34:02	0|sipa|alternatively, we can also have a boolean in the key meta data saying that the "corresponding" address is segwit
210 2017-08-31 19:34:21	0|sipa|in which case we bypass the need-redeemscript property, but just for keys with that flag set
211 2017-08-31 19:34:41	0|sipa|but at the cost of extra complexity
212 2017-08-31 19:34:45	0|morcos|sipa: is hte issue wiht 1) bloat?
213 2017-08-31 19:34:49	0|luke-jr|but when generating an address, it should only automatically add it if the user wants a witness address; we need to support at least P2SH-wrapper addresses until Bech32 adoption is widespread..
214 2017-08-31 19:34:51	0|sipa|morcos: yes, just bloat
215 2017-08-31 19:34:56	0|gmaxwell|manually sure, it's like importing a key.
216 2017-08-31 19:35:33	0|sipa|luke-jr: that brings us to another question - my view is that we shouldn't support choosing on a per-address basis whether it should be segwit or not; just a wallet-wide flag that you now want segwit
217 2017-08-31 19:35:41	0|luke-jr|sipa: I like the key metadata approach; that lets us refuse non-segwit payments to segwit keys
218 2017-08-31 19:35:44	0|sipa|the reason for that is for interaction with hd auto topup
219 2017-08-31 19:35:50	0|gmaxwell|^ I think so to, wallet wide because of recovery.
220 2017-08-31 19:35:53	0|instagibbs|i think wallets make a lot more sense if by default you do one or the other, and support importing otherwise
221 2017-08-31 19:35:54	0|morcos|sipa: +1 on no per-address choosing
222 2017-08-31 19:36:05	0|luke-jr|sipa: then nobody can reasonably use p2wpkh until support for bech32 is universal? :/
223 2017-08-31 19:36:07	0|gmaxwell|importing one shows that violate the wallet wide is fine.
224 2017-08-31 19:36:08	0|morcos|the whole point of segwit (well one of them) is we think thats the right way to do transactions)
225 2017-08-31 19:36:19	0|BlueMatt|sipa: we could also do that on-disk, but in-memory keep the bloat-y version?
226 2017-08-31 19:36:30	0|sdaftuar|how will the migration to bech32 work?
227 2017-08-31 19:36:43	0|instagibbs|luke-jr, is there any reason we cant return multiple address types? thinking out loud :)
228 2017-08-31 19:36:49	0|sipa|luke-jr: i think we'll be forced to support bech32 as an optional thing and treat bech32 and its p2sh embdeed version identially
229 2017-08-31 19:36:50	0|gmaxwell|sdaftuar: send to it first, and when ~everyone can send it it, we start generating addresses.
230 2017-08-31 19:36:50	0|luke-jr|also, doesn't this mean you can't upgrade existing wallets?
231 2017-08-31 19:36:51	0|instagibbs|if we're doing a hard switchover, we can break api a bit?
232 2017-08-31 19:37:05	0|luke-jr|instagibbs: eww :(
233 2017-08-31 19:37:07	0|gmaxwell|sipa: ugh.
234 2017-08-31 19:37:20	0|sipa|gmaxwell: there's no way we can switch over an entire wallet to bech32
235 2017-08-31 19:37:27	0|gmaxwell|certantly not today!
236 2017-08-31 19:37:27	0|sipa|at least not the first ... year?
237 2017-08-31 19:37:34	0|gmaxwell|yes sure. and
238 2017-08-31 19:37:34	0|instagibbs|luke-jr, elaborate the ew
239 2017-08-31 19:37:36	0|luke-jr|sipa: that's why per-address is useful
240 2017-08-31 19:37:50	0|sipa|luke-jr: but per-address is inherently incompatible with hd auto topup
241 2017-08-31 19:37:53	0|gmaxwell|luke-jr: per-address is not backup durable.
242 2017-08-31 19:38:08	0|luke-jr|hmm
243 2017-08-31 19:38:19	0|luke-jr|what if we use separate HD chains for each type?
244 2017-08-31 19:38:22	0|gmaxwell|why are we expanding scope to recieve BIP173 addresses. I think we should not make this scope expansion now.
245 2017-08-31 19:38:33	0|morcos|gmaxwell: what did you not like, having bech32 and p2sh both supported together?
246 2017-08-31 19:38:37	0|sipa|i think we have two options (which apply to both segwit/legacy and to p2sh/bech32): treat them as identical and accept payments to both, or switch over the wallet entirely
247 2017-08-31 19:38:38	0|BlueMatt|<luke-jr> also, doesn't this mean you can't upgrade existing wallets? <-- yea. this. the discussion about hd-upgrade kinda devolved (I've been mia for a week so may be behind), but it seems to me with the current disk structure we need hd-upgrade before we can do segwit-upgrade unless we want to start forking the -upgradewallet stuff
248 2017-08-31 19:39:01	0|gmaxwell|morcos: because then people can randomly turn your addresses to the other kind which you've never given out and pay you.
249 2017-08-31 19:39:48	0|BlueMatt|yea, I think its unacceptable to do that cause we have shit like breaking uncompressed keys, so we really, really dont want to support people blindly converting addresses, sets a terrible understanding
250 2017-08-31 19:39:49	0|sipa|my view is that we should treat bech32 and p2sh as identical - because, by design, they are identical - every segwit version is supposed to work in both
251 2017-08-31 19:39:53	0|gmaxwell|the pre-segwit vs segwit version of that question is incredibly dangerous.   p2sh-embed vs not, is perhaps less so.
252 2017-08-31 19:39:53	0|luke-jr|BlueMatt: even the ability to upgrade an existing HD wallet to a segwit+HD wallet would be nice
253 2017-08-31 19:40:00	0|morcos|so we can do this in 2 stages?  switch whole wallet to p2sh embedded segwit, and then in 6-12 mos switch whole wallet to bech32?
254 2017-08-31 19:40:00	0|sipa|but we should not treat segwit and p2pkh as identical
255 2017-08-31 19:40:19	0|gmaxwell|sipa: we should have specified this as part of the segwit bips then. :(  but okay, it could be done.
256 2017-08-31 19:40:22	0|BlueMatt|sipa: I'm ok with that
257 2017-08-31 19:40:39	0|gmaxwell|morcos: that was my expectation, and we will have to do is regardless at least in terms of what addresses we return.
258 2017-08-31 19:40:41	0|jtimon|sipa: well, we could , for example switch over enterily for segwit/legacy but treat identical for p2sh/bech32, no?
259 2017-08-31 19:40:53	0|sipa|jtimon: that's exactly what i'm suggesting
260 2017-08-31 19:40:59	0|BlueMatt|morcos: i think sipa is advocating for (and I like) - switch wallet over to "segwit" and give users the addresses in p2sh-embedded form, but really thats a ui-level thing
261 2017-08-31 19:41:10	0|BlueMatt|and maybe a flag for "i gave this address out as version X"
262 2017-08-31 19:41:12	0|sipa|however, the bech32 question is not very urgent now
263 2017-08-31 19:41:22	0|sipa|while switchover the segwit is
264 2017-08-31 19:41:44	0|sipa|i guess there are a) support both for our own keys b) use separate hd chains for segwit c) switchover wallet as a whole
265 2017-08-31 19:41:47	0|morcos|BlueMatt: right so we'd be capable of receiving a bech32 payment, but we would not give those out for some time?
266 2017-08-31 19:41:53	0|sipa|i think (c) is best
267 2017-08-31 19:42:00	0|BlueMatt|morcos: yes
268 2017-08-31 19:42:19	0|instagibbs|BlueMatt, and send I hope?
269 2017-08-31 19:42:22	0|BlueMatt|sipa: wait, I'm  confused...does c include a and b?
270 2017-08-31 19:42:25	0|luke-jr|(c) will slow adoption
271 2017-08-31 19:42:38	0|sipa|BlueMatt: they are 3 distinct possibilities
272 2017-08-31 19:43:02	0|achow101|(c) works well with multi wallet
273 2017-08-31 19:43:11	0|sipa|(c) means there is a wallet-wide flag that says "SEGWIT: YES", and if so, all new addresses are generated as segwit, and integrated with hd topup
274 2017-08-31 19:43:21	0|sipa|but no separate chains for segwit or not
275 2017-08-31 19:43:26	0|instagibbs|achow101, right, my ledger support will likely simply utilize multiwallet for crossover
276 2017-08-31 19:43:32	0|gmaxwell|sipa: and if we wanted to convert an old wallet we could just import all the keys.
277 2017-08-31 19:43:33	0|BlueMatt|sipa: ah, yes, back to my previous question...what form does that flag take
278 2017-08-31 19:43:42	0|sipa|BlueMatt: i see
279 2017-08-31 19:43:46	0|BlueMatt|sipa: cause its damn-dirty to add a flag like that and not use our versioning stuff
280 2017-08-31 19:43:51	0|achow101|If we do that, we can also implement the optional features thing for wallets
281 2017-08-31 19:43:55	0|BlueMatt|but using our versioning stuff means we need hd-upgrade
282 2017-08-31 19:44:02	0|sipa|BlueMatt: i want to get rid of the version stuff and have feature flags
283 2017-08-31 19:44:03	0|BlueMatt|which i think we need, but may delay things
284 2017-08-31 19:44:21	0|BlueMatt|sipa: but exponential blowup of feature options :(
285 2017-08-31 19:44:36	0|sipa|BlueMatt: yes...
286 2017-08-31 19:45:04	0|sipa|so perhaps the question is: is there any reason why wallets shouldn't have that segwit flag (apart from backup reasons)
287 2017-08-31 19:45:33	0|instagibbs|BlueMatt, sorry delay how
288 2017-08-31 19:45:43	0|BlueMatt|sipa: yes, like anything else in the wallet, if user doesnt say -upgradewallet, we'd prefer to not break their backward compat
289 2017-08-31 19:45:54	0|BlueMatt|instagibbs: because if we use the versioning stuff, hd-upgrade must happen first
290 2017-08-31 19:46:01	0|morcos|Someone should write up a more comprehensive wallet plan.  The only thing that's clear is we need to support any kind of wallet that has existed in the past
291 2017-08-31 19:46:02	0|instagibbs|Ah, user delay, noted
292 2017-08-31 19:46:20	0|jtimon|sipa: what if the payer can't pay to segwit ? I think that's why luke wants to be able to genreate legacy for receiving, no?
293 2017-08-31 19:46:20	0|meshcollider|well it would only happen when they choose to upgrade to segwit only, so you can just give them a warning then right
294 2017-08-31 19:46:21	0|instagibbs|morcos, some people will be in person in a few days.... would be a good time to review such a doc
295 2017-08-31 19:46:23	0|morcos|But we don't need to support any possible combination..  So we shouldn't have segwit non-HD chain split wallets for example
296 2017-08-31 19:46:29	0|sipa|jtimon: every wallet can send to P2SH
297 2017-08-31 19:46:30	0|morcos|so lets make sure there is no way to create that
298 2017-08-31 19:46:33	0|BlueMatt|morcos: we've generally supported opening new wallets with old versions as long as they are un-upgraded, too
299 2017-08-31 19:46:41	0|jtimon|sipa: , oh, right, never mind
300 2017-08-31 19:46:53	0|gmaxwell|for upgrading I think we'd set the flag, start exploring the segwit address chain from 0 and import all the old keys as whatever they are.
301 2017-08-31 19:46:55	0|sipa|BlueMatt: yes, understood, but apart from that, is there any reason why someone would not want their wallet to construct segwit outputs?
302 2017-08-31 19:47:01	0|sipa|*addresses
303 2017-08-31 19:47:04	0|BlueMatt|morcos: yes, well then we need a "list of acceptable feature flag combinations" against which we check the wallet on load.... :/
304 2017-08-31 19:47:18	0|gmaxwell|sipa: no, only wallets that are trying to stay unupgraded.
305 2017-08-31 19:47:28	0|morcos|or for instance having segwit implies HD-chain split...
306 2017-08-31 19:47:30	0|BlueMatt|sipa: not to my knowledge, no
307 2017-08-31 19:47:31	0|sipa|so do we need a flag at all?
308 2017-08-31 19:47:41	0|sipa|as opposed to just start doing it automatically in a new version
309 2017-08-31 19:47:44	0|BlueMatt|only upgrade, to me
310 2017-08-31 19:47:57	0|BlueMatt|well we'd need users to do a -walletupgrade
311 2017-08-31 19:48:01	0|sipa|i don't think so
312 2017-08-31 19:48:12	0|BlueMatt|errr, I'm not a fan of that
313 2017-08-31 19:48:30	0|meshcollider|If you give them the setting somewhere in Qt then it can give them a compat warning when they go to upgrade it
314 2017-08-31 19:48:31	0|BlueMatt|that'd be the first time we break opening new wallets with an old version by default (and have no way to not break it!)
315 2017-08-31 19:48:33	0|sipa|maybe i'm missing something, but i see no failure scenario
316 2017-08-31 19:48:40	0|BlueMatt|i guess if we do that we should switch to bdb 5
317 2017-08-31 19:48:48	0|gmaxwell|if there is a reason we're unaware of the user can stay on the old version until we add support for whatever we want.
318 2017-08-31 19:48:49	0|luke-jr|sipa: downgrading
319 2017-08-31 19:48:54	0|sipa|luke-jr: elaborate
320 2017-08-31 19:49:07	0|sipa|old versions will produce old addresses, and not add the witness redeem script
321 2017-08-31 19:49:08	0|luke-jr|sipa: if I take my wallet, use it with 0.16, I should be able to use the same wallet with 0.12 again
322 2017-08-31 19:49:10	0|jtimon|do we want to support downgrading wallets?
323 2017-08-31 19:49:26	0|BlueMatt|sipa: its always been the case that you can pretty easily run your wallet with an old version as long as it is not upgraded
324 2017-08-31 19:49:26	0|luke-jr|until I use -walletupgrade ofc
325 2017-08-31 19:49:31	0|BlueMatt|with no significant feature loss
326 2017-08-31 19:49:35	0|sipa|new versions will produce new address, add their redeemscript, and when downgrading, those addresses will keep working
327 2017-08-31 19:49:38	0|BlueMatt|and definitely not with missing transactions
328 2017-08-31 19:49:39	0|sipa|BlueMatt: i don't see a problem
329 2017-08-31 19:49:46	0|achow101|So upgrade it with a version number
330 2017-08-31 19:49:49	0|luke-jr|sipa: old versions don't know how to sign for segwit UTXOs..
331 2017-08-31 19:49:52	0|BlueMatt|sipa: missing transactions
332 2017-08-31 19:49:58	0|sipa|BlueMatt: ?
333 2017-08-31 19:50:13	0|sipa|segwit address will work fine in older versions, if we use the redeemscript add construction
334 2017-08-31 19:50:14	0|BlueMatt|if you receive a payment using segwit and then open that wallet with an old version, it will not be there
335 2017-08-31 19:50:21	0|sipa|yes it will be
336 2017-08-31 19:50:25	0|sipa|at least down to 0.13.0
337 2017-08-31 19:50:31	0|luke-jr|sipa: and it will spend?
338 2017-08-31 19:50:35	0|sipa|luke-jr: yes
339 2017-08-31 19:50:41	0|sipa|luke-jr: the signing code for segwit works fine
340 2017-08-31 19:50:48	0|BlueMatt|mm, fair, though will fail for native segwit, I suppose?
341 2017-08-31 19:50:52	0|sipa|yes
342 2017-08-31 19:50:59	0|sipa|but ignore bech32 for now
343 2017-08-31 19:51:03	0|jtimon|dow we want to support wallet downgrade beyond 0.13 ?
344 2017-08-31 19:51:09	0|luke-jr|sipa: okay, so how does this all work for people who actively do not wish to use segwit transactions?
345 2017-08-31 19:51:11	0|sipa|jtimon: that's a good question
346 2017-08-31 19:51:17	0|BlueMatt|ohhhhhhhhhh, wait, errrrrr, wont everythin break anyway cause it wont deserialize segwit-formatted txn in the wallet pre-0.13.0?
347 2017-08-31 19:51:23	0|sipa|BlueMatt: yes
348 2017-08-31 19:51:31	0|BlueMatt|lol, ok, well we're not fixing that one
349 2017-08-31 19:51:35	0|BlueMatt|so I dont care
350 2017-08-31 19:51:40	0|morcos|we're talking about 2 different things...  are you saying if i open an 0.12 wallet in 0.16, then i can't reopen it in 0.12
351 2017-08-31 19:51:41	0|sipa|i guess BlueMatt answered jtimon's question
352 2017-08-31 19:51:44	0|morcos|that sounds like a terrible idea
353 2017-08-31 19:51:50	0|gmaxwell|I think it's fine if use of segwit makes the wallet 0.15.1+
354 2017-08-31 19:51:52	0|sipa|morcos: that's already the case...
355 2017-08-31 19:51:54	0|morcos|if you upgrade it, then yeah of course you don't need to be able to go backwards
356 2017-08-31 19:52:02	0|BlueMatt|gmaxwell: I'm not ok with that, I think
357 2017-08-31 19:52:03	0|luke-jr|sipa: why?
358 2017-08-31 19:52:03	0|morcos|sipa: huh?
359 2017-08-31 19:52:11	0|gmaxwell|wut
360 2017-08-31 19:52:12	0|sipa|morcos: because of what BlueMatt says
361 2017-08-31 19:52:13	0|morcos|i don't think so at all
362 2017-08-31 19:52:19	0|BlueMatt|gmaxwell: I'm fine with it being 0.13.0, which it already is
363 2017-08-31 19:52:23	0|morcos|hmm.
364 2017-08-31 19:52:26	0|sipa|you can receive a segwit transaction that pays you (via legacy output)
365 2017-08-31 19:52:30	0|BlueMatt|gmaxwell: do we have any need to make it 0.15.1?
366 2017-08-31 19:52:30	0|morcos|i don't think so
367 2017-08-31 19:52:32	0|sipa|that will be stored as a segwit txn in your wallet
368 2017-08-31 19:52:34	0|gmaxwell|I bet it doesn't work for 0.13.0
369 2017-08-31 19:52:36	0|BlueMatt|do we get any features from that, really?
370 2017-08-31 19:52:37	0|morcos|oh maybe
371 2017-08-31 19:52:37	0|sipa|which 0.12 won't open
372 2017-08-31 19:52:39	0|morcos|durn
373 2017-08-31 19:52:45	0|luke-jr|ugh
374 2017-08-31 19:52:52	0|meshcollider|Not if you just open the wallet without generating new addresses though ?
375 2017-08-31 19:52:57	0|gmaxwell|BlueMatt: how about testing resources if nothing else... but also you'll corrupt your wallet, when it doesn't know how to extend the keypool.
376 2017-08-31 19:53:08	0|luke-jr|does that mean if 0.12 receives a segwit tx, it will break newer??
377 2017-08-31 19:53:20	0|BlueMatt|gmaxwell: if the wallet is un-upgraded it wont break?
378 2017-08-31 19:53:20	0|sipa|meshcollider: there can be a segwit address that pays you via a plain old p2pkh address
379 2017-08-31 19:53:31	0|BlueMatt|gmaxwell: obviously if its an hd wallet old versions will refuse to open
380 2017-08-31 19:53:39	0|gmaxwell|BlueMatt: if it's unupgraded it's not giving out segwit addresses.
381 2017-08-31 19:53:49	0|BlueMatt|gmaxwell: though testing resources are obviously always an issue
382 2017-08-31 19:54:03	0|BlueMatt|gmaxwell: sipa was proposing that it give out segwit addresses even if it is unupgraded
383 2017-08-31 19:54:31	0|luke-jr|what happens right now, if we have a segwit tx in the wallet without witness data? :/
384 2017-08-31 19:54:32	0|gmaxwell|BlueMatt: how the heck does this even work for HD chains.
385 2017-08-31 19:54:33	0|instagibbs|6 minutes
386 2017-08-31 19:54:50	0|meshcollider|sipa
387 2017-08-31 19:54:59	0|sipa|gmaxwell: it will work fine, unless you downgrade at the same time as you recover
388 2017-08-31 19:55:00	0|BlueMatt|gmaxwell: hd doesnt matter...wait, sipa was saying no new hd chain, maybe we should reopen that part of the discussion :p
389 2017-08-31 19:55:02	0|meshcollider|isnt that only the case if you gave out the address
390 2017-08-31 19:55:08	0|sipa|meshcollider: no
391 2017-08-31 19:55:15	0|sipa|19:53:19 < sipa> meshcollider: there can be a segwit address that pays you via a plain old p2pkh address
392 2017-08-31 19:55:29	0|sipa|^ in that case you don't ever generated a segwit address
393 2017-08-31 19:55:30	0|meshcollider|Can anyone generate that themselves?
394 2017-08-31 19:55:39	0|jtimon|in any case, is the question adding a new wallet version or not?
395 2017-08-31 19:55:41	0|BlueMatt|lol, sounds like we've got a lot to discuss next week
396 2017-08-31 19:55:50	0|BlueMatt|homework: everyone go farmiliarize yourself with wallet
397 2017-08-31 19:55:54	0|BlueMatt|ALL OF WALLET =D
398 2017-08-31 19:55:55	0|achow101|I'm horribly confused now
399 2017-08-31 19:56:10	0|sipa|meshcollider: no, but the sender can be segwit enabled while you aren't
400 2017-08-31 19:56:14	0|luke-jr|BlueMatt: every time I do that, I get the inclination to throw it all away and start from scratch :x
401 2017-08-31 19:56:34	0|cfields|heh, we desperately need to break this discussion up into chunks
402 2017-08-31 19:56:41	0|BlueMatt|cfields: yes
403 2017-08-31 19:56:51	0|instagibbs|can someone whip up a table or something of concerns
404 2017-08-31 19:56:55	0|instagibbs|action item?
405 2017-08-31 19:57:02	0|luke-jr|kanzure has one
406 2017-08-31 19:57:07	0|luke-jr|just needs updating
407 2017-08-31 19:57:09	0|achow101|Kanzure: add to list?
408 2017-08-31 19:57:16	0|meshcollider|oh I see yeah, true
409 2017-08-31 19:57:21	0|instagibbs|oh, for that too, if you're in SF next week
410 2017-08-31 19:57:25	0|cfields|kanzure: and update it so that it's backwards compatible to the last list, please.
411 2017-08-31 19:57:36	0|achow101|Lol
412 2017-08-31 19:57:55	0|sipa|a) how to deal with 0.13.1 through 0.15.0 receiving a segwit transaction and then downgrading to 0.12.x or below
413 2017-08-31 19:58:06	0|sipa|b) how to switch to generating segwit addresses
414 2017-08-31 19:58:12	0|sipa|c) how to switch to generating bech32 addresses
415 2017-08-31 19:58:40	0|jtimon|I won't go this time :( have productive discussions there, and fun too!
416 2017-08-31 19:58:45	0|BlueMatt|d) how to deal with 0.15.1 downgradingg to 0.13.1 (in both hd and non-hd modes)
417 2017-08-31 19:59:06	0|BlueMatt|e) whether to use a new hd chain for segwit addresses
418 2017-08-31 19:59:14	0|sipa|e falls under b
419 2017-08-31 19:59:19	0|BlueMatt|err, ok
420 2017-08-31 19:59:22	0|gmaxwell|BlueMatt: please just don't support that. It makes no sense to back and revalidate segwit wallet support in old versions.
421 2017-08-31 19:59:44	0|gmaxwell|we will not manage to adequately test it and it will sharply constrain our implementation choices.
422 2017-08-31 19:59:46	0|sipa|any last minute short topic?
423 2017-08-31 19:59:47	0|BlueMatt|gmaxwell: then we should explicitly break it...but, anyway, lets have this discussion next week
424 2017-08-31 19:59:49	0|gmaxwell|and lead to weird corner case bugs.
425 2017-08-31 20:00:02	0|instagibbs|sipa, activate schnorr?
426 2017-08-31 20:00:02	0|sipa|#endmeeting
427 2017-08-31 20:00:03	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-31-19.05.log.html
428 2017-08-31 20:00:03	0|lightningbot|Meeting ended Thu Aug 31 20:00:02 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
429 2017-08-31 20:00:03	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-31-19.05.html
430 2017-08-31 20:00:03	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-31-19.05.txt
431 2017-08-31 20:00:04	0|instagibbs|too late, over
432 2017-08-31 20:00:06	0|jtimon|gmaxwell: besides, is downgrading such an important use case?
433 2017-08-31 20:00:13	0|BlueMatt|if we dont support downgrading, I very, very strongly support switching to bdb5 for wallet
434 2017-08-31 20:00:14	0|gmaxwell|instagibbs: schnorr is cancled.
435 2017-08-31 20:00:22	0|instagibbs|gmaxwell, ah shite.
436 2017-08-31 20:00:29	0|chainhead|aggregated signatures
437 2017-08-31 20:00:39	0|gmaxwell|Yea, AggSig.
438 2017-08-31 20:00:41	0|luke-jr|BlueMatt: what does bdb5 have over 4?
439 2017-08-31 20:00:53	0|meshcollider|eventually we want to remove bdb entirely right
440 2017-08-31 20:00:59	0|sipa|nothing we care about, except likely being slightly longer supported in OSes
441 2017-08-31 20:01:03	0|achow101|luke-jr it's actually in package managers by default
442 2017-08-31 20:01:10	0|BlueMatt|luke-jr: not having every goddamned distro build with the backward-compat-break option?
443 2017-08-31 20:01:10	0|esotericnonsense|is there a specific goal in mind with regard to downgrading? a 'support period' as such? it seems to me that defining that would be useful. say, 1 major version back, otherwise all bets are off.
444 2017-08-31 20:01:27	0|BlueMatt|luke-jr: its purely a make-distros-keep-our-wallets-sane thing
445 2017-08-31 20:01:42	0|sipa|esotericnonsense: https://bitcoincore.org/en/lifecycle/
446 2017-08-31 20:01:55	0|luke-jr|sipa: that's never applied to wallets though
447 2017-08-31 20:01:57	0|sipa|0.12 is EOL
448 2017-08-31 20:02:03	0|luke-jr|wallets were supposed to remain compat to 0.3 even :/
449 2017-08-31 20:02:32	0|BlueMatt|luke-jr: well the second segwit activated that broke - we can now put transactions in the wallet (today) that have witnesses and those versions will fail to deserialize, I presume
450 2017-08-31 20:02:32	0|sipa|we still stupport wallet files from 0.3.0 (and even lower, i think)
451 2017-08-31 20:02:48	0|BlueMatt|er, yes, but loading them should still be fine
452 2017-08-31 20:02:52	0|luke-jr|BlueMatt: sounds like a bug :(
453 2017-08-31 20:02:54	0|sipa|downgrading that far back is probably broken in multiple other ways too
454 2017-08-31 20:03:18	0|luke-jr|BlueMatt: why don't we store them stripped?
455 2017-08-31 20:03:26	0|sipa|luke-jr: iirc, no
456 2017-08-31 20:03:43	0|luke-jr|sipa: ?
457 2017-08-31 20:03:57	0|sipa|if i recall correctly, we do not store wallet transactions stripped
458 2017-08-31 20:03:59	0|luke-jr|"why?" is not a boolean question :p
459 2017-08-31 20:04:25	0|esotericnonsense|i would be curious to know how many users actually express a desire to downgrade significantly (i.e. beyond some sort of emergency 'we found out .15.1 is broken, go back to .15' scenario). but I feel that I'm interrupting and so will shuffle off.
460 2017-08-31 20:04:39	0|jtimon|so our goal is to make 0.15.1 wallets dongradeable to 0.12 ? that's I think too ambitious...
461 2017-08-31 20:04:48	0|BlueMatt|esotericnonsense: I think its really just an "emergency-need-to-downgrade" support thing
462 2017-08-31 20:05:01	0|BlueMatt|which, realistically, just means you need to be able to downgrade to the latest stable of the previous version
463 2017-08-31 20:05:06	0|morcos|we have to stop using confusing technology
464 2017-08-31 20:05:12	0|morcos|we don't support any downgrading now do we
465 2017-08-31 20:05:18	0|BlueMatt|jtimon: I dont think thats possible, 0.13.1 may be possible, but, indeed, is also ambitious
466 2017-08-31 20:05:18	0|morcos|we just support not-upgrading
467 2017-08-31 20:05:26	0|morcos|or at least we used to
468 2017-08-31 20:05:30	0|BlueMatt|morcos: i think you can create an old-version wallet
469 2017-08-31 20:05:34	0|luke-jr|morcos: we've always supported downgrading 0.X wallets back to 0.X
470 2017-08-31 20:05:46	0|morcos|why are you calling downgrading it
471 2017-08-31 20:05:50	0|BlueMatt|morcos: we theoretically try to avoid breaking downgrading if you did not explicitly upgrade your wallet
472 2017-08-31 20:05:54	0|BlueMatt|(with -walletupgrade)
473 2017-08-31 20:06:08	0|morcos|if you take 0.10 wallet and run it in 0.14, it doesn't get upgraded automatically does it, its still a 0.10 wallet
474 2017-08-31 20:06:15	0|luke-jr|morcos: that's the goal, yes
475 2017-08-31 20:06:17	0|BlueMatt|correct
476 2017-08-31 20:06:18	0|morcos|so you don't have to downgrade it to use it in 0.10
477 2017-08-31 20:06:24	0|luke-jr|morcos: apparently we broke that in 0.13.1
478 2017-08-31 20:06:24	0|morcos|you never upgraded it
479 2017-08-31 20:06:27	0|BlueMatt|grrr, terminology
480 2017-08-31 20:06:29	0|morcos|yes i understand
481 2017-08-31 20:06:32	0|morcos|but stop saying downgrade
482 2017-08-31 20:06:40	0|BlueMatt|you downgraded your node
483 2017-08-31 20:06:55	0|morcos|that implies you take a bech32 segwit hd-split schnorr sig aggregation wallet with tons of txs and convert it back to some old format
484 2017-08-31 20:06:59	0|luke-jr|it sounds like a simple fix would be to just store txs stripped in the wallet
485 2017-08-31 20:07:04	0|sipa|luke-jr: a reason to not stre wallet txn as stripped: if you rebroadcast an unconfirmed tx, it needs to include the witness
486 2017-08-31 20:07:13	0|morcos|not that you were using an old format wallet in a new piece of software but not using any of those features
487 2017-08-31 20:07:16	0|jtimon|BlueMatt: right, to 14.2 sounds reasonable " just means you need to be able to downgrade to the latest stable of the previous version"
488 2017-08-31 20:07:21	0|luke-jr|sipa: does this break right now, if we received the tx with 0.12?
489 2017-08-31 20:07:46	0|GAit|jnewbery: want me to just squash or rebase too?
490 2017-08-31 20:07:49	0|BlueMatt|to-be-continued next week :)
491 2017-08-31 20:07:59	0|luke-jr|BlueMatt: kk
492 2017-08-31 20:08:18	0|luke-jr|I need to get back to something too, so next week sgtm
493 2017-08-31 20:09:17	0|meshcollider|next week is sf right? will you guys have a meeting summary online or something for those that aren't going
494 2017-08-31 20:09:31	0|kanzure|i will type things
495 2017-08-31 20:09:40	0|meshcollider|awesome thanks :)
496 2017-08-31 20:11:51	0|achow101|What about doing a voice recording?
497 2017-08-31 20:12:16	0|kanzure|nah
498 2017-08-31 20:12:44	0|kanzure|https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html
499 2017-08-31 20:14:42	0|jnewbery|GAit: no need to rebase if there are no merge conflicts
500 2017-08-31 20:15:26	0|GAit|jnewbery: didn't rebase - however last time while there was no merge conflict the semantic changed and broke the tests :)
501 2017-08-31 20:15:38	0|GAit|thanks
502 2017-08-31 20:17:46	0|kanzure|cfields: please clarify if that was a joke or not
503 2017-08-31 20:17:54	0|cfields|kanzure: heh, yes
504 2017-08-31 20:18:11	0|kanzure|oh sipa's list?
505 2017-08-31 20:18:20	0|kanzure|"yes" to an "or" tsk tsk
506 2017-08-31 20:19:13	0|bitcoin-git|[13bitcoin] 15MeshCollider opened pull request #11208: Fixing offscreen GUI issue (06master...06201709_offscreen_fix) 02https://github.com/bitcoin/bitcoin/pull/11208
507 2017-08-31 20:20:11	0|kanzure|added.
508 2017-08-31 20:36:35	0|gmaxwell|sipa: can you propose a BIP modification to say that anything that accepts p2sh embedded segwit should also accept the non-embedded form  or something
509 2017-08-31 20:36:49	0|gmaxwell|I can buy your argument that it's reasonable to support both forms.
510 2017-08-31 20:36:56	0|gmaxwell|But it's weird if if its totally adhoc.
511 2017-08-31 20:39:54	0|luke-jr|seems a bit late for that
512 2017-08-31 20:40:18	0|luke-jr|do other wallets support it?
513 2017-08-31 20:40:40	0|gmaxwell|::sigh::
514 2017-08-31 20:40:44	0|gmaxwell|it's bad if its inconsistent.
515 2017-08-31 20:40:57	0|gmaxwell|"I converted this address, and it worked, I converted that address and the funds vanished into space"
516 2017-08-31 20:41:27	0|luke-jr|people shouldn't try to "convert" addresses anyway. :/
517 2017-08-31 20:42:57	0|gmaxwell|indeed, which is why I think it's bad to add both key types.
518 2017-08-31 20:42:59	0|kanzure|yep, wallets should only be expected to receive whatever was given
519 2017-08-31 20:43:12	0|kanzure|(by getnewaddress etc)
520 2017-08-31 20:43:17	0|gmaxwell|but we do end up with another migration problem with the later switch to bech32, which would be sad.
521 2017-08-31 20:54:03	0|sipa|luke-jr, gmaxwell: unfortunately, that means we'll be forced to have a separate chain for bech32 addresses
522 2017-08-31 20:54:07	0|sipa|perhaps that's the best solution
523 2017-08-31 20:56:47	0|instagibbs|sipa, in the case of migrating again?
524 2017-08-31 20:56:50	0|luke-jr|probably more future-proof too
525 2017-08-31 20:59:09	0|gmaxwell|sipa: that is what I expected us to do
526 2017-08-31 20:59:44	0|gmaxwell|we'll also have this same thing for future sig versions like a v1 with aggsig.
527 2017-08-31 21:00:19	0|gmaxwell|as an aside the masterkey lines in our dumps should include flags for this stuff
528 2017-08-31 21:00:41	0|gmaxwell|but I coudl also buy the parallel for v0 and p2sh embedded... it would have some migration advantages.
529 2017-08-31 21:01:27	0|gmaxwell|(I'm worried that we shouldn't do anything to delay supporting this though.)
530 2017-08-31 21:10:19	0|morcos|I'm not sure I understand why you have to switch to a new chain.  Why can't you just "upgrade" your old chain to support a new address type.. or is the idea that once you support bech32 you'll no longer support the p2sh version
531 2017-08-31 21:10:37	0|morcos|or that a new bech32 chain won't i mean
532 2017-08-31 21:11:45	0|sipa|morcos: if we want to be strict, and only accept payments to bech32 when a bech32 addr was given out, and p2sh/p2wpkh when that was given out, they need to be separate chains, or you need to drop support for one of them entirely
533 2017-08-31 21:11:48	0|gmaxwell|so if you are adding keys for both types, it means that people can 'convert' your addresses and have it work, which is a funds loss risk when they do it someplace where it doesn't work.
534 2017-08-31 21:11:53	0|sipa|otherwise you can't know when rescanning which is one
535 2017-08-31 21:13:18	0|gmaxwell|We could take a position that we'll always do dual p2sh embedded and native (at least for the forseeable future) in parallel... but that will still be a risk for every wallet that isn't us, and for bitcoin core users with explicitly imported keys, when something thinks it can convert.
536 2017-08-31 21:13:57	0|gmaxwell|and we cannot do dual-addresses for pre-segwit+segwit because of things like uncompressed keys.
537 2017-08-31 21:15:54	0|gmaxwell|Because as sipa points out p2sh embedding would work for _all_ segwit, we could realistically do dual support there.
538 2017-08-31 21:16:24	0|morcos|I don't know.  I guess I'm not 100% sold on the philosophy.   It kind of seems to me that if someone does pay you to an address you didn't give them.. You're going to want to find some way to recover those funds no?
539 2017-08-31 21:17:11	0|morcos|I mean I get why we don't want to encourage a culture of loosey-goosey hide the key in your backyard or however you put it gmaxwell
540 2017-08-31 21:17:20	0|gmaxwell|morcos: thats kind of the issue... then your keys are embedded in an HSM and it's virtually impossible for you to do that... or to do so you need to do dangerous crap with private keys,
541 2017-08-31 21:18:12	0|gmaxwell|So basically if this is supported as a reasonable and customary practice, then it creates an effective obligation to do it.
542 2017-08-31 21:18:53	0|morcos|But to me there is a tenous link btwn the fact that the wallet would be smart enough to accept it and people actually being encouraged to do it
543 2017-08-31 21:19:15	0|instagibbs|also doesn't this basically require someone to understand bech32, but decide to wrap in p2sh?
544 2017-08-31 21:19:27	0|morcos|You could even add some sort of flag or warning on txs that were received using unexpected address types
545 2017-08-31 21:19:43	0|luke-jr|if someone pays to an address I didn't give them, they burned the bitcoins. they didn't pay me.
546 2017-08-31 21:19:44	0|instagibbs|most cases should be the sender simply not understanding the bech32?
547 2017-08-31 21:19:50	0|gmaxwell|morcos: things that work are what people do, this is the lesson from history  -- in bitcoin but also in every internet protocol.  If we make it work we need to be ready to support it.
548 2017-08-31 21:20:34	0|gmaxwell|People deciding what to do don't read specs, they try them out and they do whatever works.
549 2017-08-31 21:21:02	0|gmaxwell|I think we could reasonably support p2sh-embedded and segwit duality. Sipa points out that it'll work universally.
550 2017-08-31 21:21:04	0|morcos|well perhaps we could solve the problem i'm more concerned with in a different way by making different paths in the HD wallet
551 2017-08-31 21:21:11	0|morcos|so the same key never was used for both
552 2017-08-31 21:21:16	0|morcos|but you don't have to change master keys
553 2017-08-31 21:21:25	0|gmaxwell|morcos: you do that by using a different path.
554 2017-08-31 21:21:32	0|morcos|the issue i don't like is invalidating peoples backups
555 2017-08-31 21:21:37	0|gmaxwell|Which is what other wallets are also doing for segwit suppot, fwiw.
556 2017-08-31 21:21:49	0|morcos|so when we're talking about switching to a new chain for bech32, we'r ejust talking about a new path?
557 2017-08-31 21:22:01	0|sipa|morcos: yes
558 2017-08-31 21:22:02	0|morcos|that seems much more reasonable to me
559 2017-08-31 21:22:18	0|gmaxwell|I assume but the backup is somewhat invalidated because the backup doesn't have the metadata to tell it what paths are used. This is also true for the hdsplit.
560 2017-08-31 21:22:18	0|sipa|and perhaps if we plan to do that, we should do the same for p2sh-p2wpkh
561 2017-08-31 21:22:50	0|morcos|ignore my objections then...   seems like we should do a quick online survey of other wallet providers and assess whether most have expected that p2sh wrapped == bech32, that is if you accept one you accept the other
562 2017-08-31 21:22:50	0|sipa|there is a distinction in that bech32 or not is probably something we do want to do on a per-key basis
563 2017-08-31 21:22:59	0|morcos|and unless thats nearly universal, we shouldn't introduce it
564 2017-08-31 21:23:01	0|luke-jr|gmaxwell: backups can be expected invalidated when -walletupgrade is used
565 2017-08-31 21:23:21	0|gmaxwell|Esp for BIP173; the transition can't really be done abruptly unless its seriously delayed.
566 2017-08-31 21:23:36	0|instagibbs|morcos, most are doing bip49 I think, which only is about nested
567 2017-08-31 21:23:37	0|morcos|luke-jr: why?  shouldn't you just be able to -upgrade your backup
568 2017-08-31 21:23:46	0|gmaxwell|while if we do dual embedded and native then probably I can use bech32 on day one, e.g. my exchange supports it, so I have it pay me via a 173 address.
569 2017-08-31 21:23:46	0|instagibbs|not sure what they're expecting to do with bech32
570 2017-08-31 21:24:05	0|sipa|morcos: that doesn't work for upgrading to hd, to hd split, nor for adding new chains
571 2017-08-31 21:24:14	0|gmaxwell|morcos: just the backup doesn't know where and when the pathing change happened.
572 2017-08-31 21:24:24	0|luke-jr|morcos: hmm, it might work in this case, but IMO we shouldn't *expect* it to
573 2017-08-31 21:24:33	0|gmaxwell|i suppose you could replay the same actions and have it work, but it's tricky and easy to screw up.
574 2017-08-31 21:25:20	0|gmaxwell|e.g. backup your wallet on day 0 with no segwith, use 100,000 keys... upgrade it later... use another 10000 keys... erase wallet... now how do you reproduce this...
575 2017-08-31 21:25:42	0|gmaxwell|you need to know to expand the keypool 100,000 keys, then switch...
576 2017-08-31 21:25:43	0|luke-jr|gmaxwell: if segwit uses a new path/chain, this would just work I guess
577 2017-08-31 21:26:00	0|morcos|well, i was assuming the path branch happened at the beginning, but maybe that was a bad assumption
578 2017-08-31 21:26:19	0|morcos|in which case you'd just look ahead whatever the number of keys is on all paths
579 2017-08-31 21:26:26	0|gmaxwell|yes, it should happen at the beggin... how do we know to go to 100,000...
580 2017-08-31 21:26:34	0|gmaxwell|okay, thats a more keypools solution.
581 2017-08-31 21:26:49	0|luke-jr|gmaxwell: start monitoring both chains at their beginning, and extend each as needed
582 2017-08-31 21:26:51	0|morcos|the same way we know to go to 100k if we never did anything and you backedup your wallet with nothing in it
583 2017-08-31 21:26:56	0|gmaxwell|perhaps... this has some other tradeoffs.
584 2017-08-31 21:27:05	0|morcos|i don't understand how you don't have to do that anyway
585 2017-08-31 21:27:11	0|gmaxwell|e.g. say we have 4 segwit versions, and so now we have 10 keypools.
586 2017-08-31 21:27:25	0|gmaxwell|but only one of them has ever been used.
587 2017-08-31 21:28:11	0|morcos|so what happens when you upgrade your wallet?  don't you have to still keep keypools for your old chains anyway?
588 2017-08-31 21:28:41	0|morcos|or are you suggesting the upgrade is the user saying, i have no pending payments forever in the future for any address i've ever given out
589 2017-08-31 21:29:18	0|gmaxwell|yep. that was my thinking.. just import all the keys that are already used.
590 2017-08-31 21:29:24	0|luke-jr|gmaxwell: if we're worried about it, we should just stop using keypools?
591 2017-08-31 21:29:29	0|adiabat|not to complicate things further, but my wallet software supports bech32 / p2wpkh but ignores nested completely
592 2017-08-31 21:29:31	0|gmaxwell|it's not even clear to me that we should support upgrading.
593 2017-08-31 21:30:14	0|gmaxwell|for something that changes your key paths perhaps we should only support that for new wallets.   If you want old keys in it, you can import.
594 2017-08-31 21:30:17	0|sipa|gmaxwell: there is no 'import'
595 2017-08-31 21:30:25	0|gmaxwell|importmulti
596 2017-08-31 21:30:34	0|sipa|gmaxwell: the effect of an import is exactly the same as just adding a key
597 2017-08-31 21:30:44	0|sipa|gmaxwell: i mean that every key we generate is implicitly 'imported'
598 2017-08-31 21:30:47	0|gmaxwell|import doesn't have anything to do with maintaining a keypool.
599 2017-08-31 21:30:56	0|gmaxwell|yes, it's that PLUS keypool management.
600 2017-08-31 21:31:02	0|luke-jr|time to reboot, bbl
601 2017-08-31 21:31:13	0|sipa|gmaxwell: i just mean that is what we already doing
602 2017-08-31 21:31:40	0|sipa|gmaxwell: saying "switching to a new keypool and treating all the existing keys as imported" is exactly the same as "switching to a new keypool"
603 2017-08-31 21:32:16	0|gmaxwell|yes, but it's distinct from following all keypools which is what I was discussing with morcos.
604 2017-08-31 21:32:47	0|morcos|gmaxwell: yeah i think if i understand what sipa is saying, once you've made the decision to start giving out addresses on a new chain, you no longer need to maintain a keypool for your old chain
605 2017-08-31 21:32:49	0|sipa|ok, s/switching to/adding/g in my above statement
606 2017-08-31 21:33:04	0|morcos|youv've already got the current keypool as keys in your wallet, and its exactly as if you imported
607 2017-08-31 21:33:04	0|sipa|still same thing - the 'importing' thing is besides the point
608 2017-08-31 21:33:10	0|gmaxwell|morcos: right thats an option, but it's not 'backup durable'
609 2017-08-31 21:33:19	0|morcos|why not?
610 2017-08-31 21:33:38	0|gmaxwell|because you restore a backup then don't do the upgrade or do instantly before scanning all the keys
611 2017-08-31 21:34:01	0|morcos|hmm.. i see, its just more complicated to get it right i suppose
612 2017-08-31 21:34:08	0|gmaxwell|and when we do the upgrade to we trigger a full (pruning incompatible multihour long) rescan
613 2017-08-31 21:34:17	0|morcos|but the advantage of supporting 2 keypools is we can start issuing bech32 earlier
614 2017-08-31 21:34:22	0|morcos|which seems a big gain
615 2017-08-31 21:34:49	0|gmaxwell|Or we could just do dual-embedded and bech32.
616 2017-08-31 21:35:00	0|morcos|hmm
617 2017-08-31 21:35:06	0|gmaxwell|in which case it's just one keypool and we could use bech32 all the time, but there is a risk of people converting.
618 2017-08-31 21:35:16	0|gmaxwell|For rapid bech32 deployment that is best by far.
619 2017-08-31 21:35:32	0|morcos|but also means we can't ever easily stop supporting the old style
620 2017-08-31 21:35:37	0|gmaxwell|because it lets you immediately use bech32 when you have a counterparty that supports it.
621 2017-08-31 21:36:00	0|gmaxwell|morcos: right, we could for newer wallet 3 years from now, except for the risk of 'conversion'
622 2017-08-31 21:36:34	0|sipa|just in case that isn't clear: if you currently use addwitnessaddress, you'll accept both p2sh and native-witness outputs to that address
623 2017-08-31 21:37:08	0|morcos|and if you don't you'll accept neither?
624 2017-08-31 21:37:23	0|sipa|yes
625 2017-08-31 21:38:20	0|morcos|well i do think it makes sense to think about this comprehensively in the context of legacy -> hd -> hd-split -> p2shsegwit -> bech32 -> future witness versions
626 2017-08-31 21:38:39	0|morcos|there are different issues for each of those
627 2017-08-31 21:39:11	0|morcos|but i think we want the design to be something where people don't get confused understanding how it works
628 2017-08-31 21:41:30	0|gmaxwell|we really cannot do legacy and segwit doppleganging due to the uncompressed key issue.
629 2017-08-31 21:41:36	0|morcos|Imagine that each of those is considered a different path or whatever, and we introduced some concept of whether a path is active or not (meaning we are still potentially giving out addresses on it)  and once it's not active we don't need to maintain keypools anymore, we just have the historical keys
630 2017-08-31 21:41:45	0|sipa|gmaxwell: easy enough with a bit in the metadata
631 2017-08-31 21:41:51	0|gmaxwell|I think we can realistically do native + embedded doppleganging and support it forever.
632 2017-08-31 21:41:54	0|sipa|or just the addwitness approach
633 2017-08-31 21:42:05	0|gmaxwell|bit in the metadata is a backup disaster.
634 2017-08-31 21:42:06	0|morcos|When you upgrade you need to specify which ones you are still active on..  And there is a way to deactivate old types
635 2017-08-31 21:42:17	0|sipa|gmaxwell: it would also be added during hd topup
636 2017-08-31 21:42:31	0|gmaxwell|sipa: I don't understand how that works.
637 2017-08-31 21:42:38	0|gmaxwell|I mean where do the bits come from
638 2017-08-31 21:43:02	0|sipa|gmaxwell: once your wallet is segwit-enabled, you add it for every newly generated key (including auto topup)
639 2017-08-31 21:43:16	0|sipa|it means you can't recover with an old version anymore, but that's inevitable
640 2017-08-31 21:44:26	0|gmaxwell|but then you recover an old backup with a new wallet... will it then set the bit for everything
641 2017-08-31 21:44:40	0|sipa|ah, i see
642 2017-08-31 21:44:55	0|gmaxwell|I'm sorry, I think this is all confused; or I am all confused.  Esp since we don't even really know if we are recovering or not at any point in time.
643 2017-08-31 21:48:40	0|morcos|gmaxwell: I think when you said "that's a more keypools solution", I took that as a negative, but i'm not sure why it has to be a negative.   Have a keypool for every path / type of address.  Who cares?
644 2017-08-31 21:50:44	0|morcos|I don't think it causes any wallet bloat if you're comparing it to importing your keys to a new wallet as you upgrade.  It it causes in-memory bloat, that seems easy enough to optimize away, by leaving most of unlikely to be used keypools on disk.
645 2017-08-31 21:51:38	0|gmaxwell|two keypools, technically.  ends up being a megabyte of keypool for each or whatever with our current inefficient storage...
646 2017-08-31 21:53:17	0|gmaxwell|(change and not change, is the two pools)
647 2017-08-31 21:54:16	0|morcos|Yes, but don't you get that anyway, if you import to each version in turn as you're importing all the prior keypool keys
648 2017-08-31 21:54:45	0|gmaxwell|We could do that.  Also slower accepting blocks, because you now have a lot more keys to scan... but thats something that generally may need to be optimized.
649 2017-08-31 21:55:06	0|gmaxwell|morcos: if you do that, but most users eventually will have just started eventually with vXX and won't have any old ones
650 2017-08-31 21:55:26	0|morcos|yes, and so then you don't create the old ones
651 2017-08-31 21:55:57	0|gmaxwell|so then there is key metadata which says the oldest kind to build, and we build all later ones.
652 2017-08-31 22:26:55	0|tloriato|Hello. I was testing the development of some ideas using the BitcoinCore wallet and the CLI's commands, and I came across the move command. Unfortunately the Docs states that "move will be removed in a later version of Bitcoin Core. " Does another command fulfils its duty? I've read the documentation on the official webpage and came out with empty hands. I don't want to develop an architecture around a command that will be e
653 2017-08-31 22:28:06	0|sipa|tloriato: the whole accounts subsystem is deprecated
654 2017-08-31 22:28:20	0|sipa|there won't be a replacement for move, as there would be nothing to observe its effect
655 2017-08-31 22:29:19	0|sipa|addresses will be able to have labels, and you'll be able to query for payments to specific labels, but labels don't have their own balance
656 2017-08-31 22:30:32	0|tloriato|i see it
657 2017-08-31 22:30:47	0|tloriato|well, thanks for the answer and clarification
658 2017-08-31 22:31:31	0|tloriato|i'd assume that the parameter to GetNewAddress would be the label instead of account when that happens?
659 2017-08-31 22:31:41	0|sipa|indeed
660 2017-08-31 22:32:23	0|tloriato|that's alright then! thank you