1 2018-01-12 00:01:38	0|gmaxwell|So you could just as well say that the pr12119 is "use BIP142" ... I wouldn't bother clarifying it, but the fact that there is not a 1:1 relationship between scripts and addresses is pretty important for cases like sipa points out.
  2 2018-01-12 00:02:01	0|promag|sipa: do you think fundrawtransaction should have changetype option?
  3 2018-01-12 00:02:09	0|gmaxwell|Also things like the payment protocol allow sending funds to a specific script which may not have any address encoding.
  4 2018-01-12 00:02:25	0|sipa|promag: i guess it could have, yes
  5 2018-01-12 00:03:19	0|gmaxwell|yea, probably should and should work like send to does unless overridden. ... though hopefully people will be moving onto the PSBT workflow sooner rather than later and all the old rawtxn interface can be depricated.
  6 2018-01-12 00:03:27	0|promag|folks using just rpc, doing manual signing, can't expect seeing fewer (usable) utxo after upgrading
  7 2018-01-12 00:03:48	0|gmaxwell|hm?
  8 2018-01-12 00:04:29	0|gmaxwell|promag: I don't understand your last comment.
  9 2018-01-12 00:05:43	0|promag|suppose someone creates raw transactions with utxos
 10 2018-01-12 00:06:45	0|promag|and only uses utxos with "address", because those are the ones the system knows how to sign
 11 2018-01-12 00:07:01	0|sipa|promag: that's not true
 12 2018-01-12 00:07:18	0|sipa|bitcoin core was able to sign P2WPKH long before an address type for it existed
 13 2018-01-12 00:07:21	0|promag|the system != bitcoind
 14 2018-01-12 00:07:30	0|gmaxwell|indeed, and native mulsig too.
 15 2018-01-12 00:07:37	0|sipa|and pay to pubkey
 16 2018-01-12 00:07:55	0|promag|suppose signing is not done with bitcoind
 17 2018-01-12 00:08:02	0|sipa|ok
 18 2018-01-12 00:08:08	0|gmaxwell|There should be no need for an address encoding to exist to make a output usable... if there is such a requirement that cropped up, it's a bug.
 19 2018-01-12 00:08:41	0|sipa|promag: imagine listunspent just gace the svriptPubKey instead of the address
 20 2018-01-12 00:08:53	0|gmaxwell|promag: suppose signing is done by something that doesn't know anything about p2sh-p2wpkh?  it can't sign for that. But so?
 21 2018-01-12 00:09:12	0|gmaxwell|Some things can't sign for some things, but this is unrelated to addresses.
 22 2018-01-12 00:09:34	0|promag|so, if there is some fixed decision of change type, then the utxo set is useless for those folks
 23 2018-01-12 00:09:52	0|sipa|promag: but the type of change is determined by that signer
 24 2018-01-12 00:10:03	0|sipa|no signer would create a type of change it couldn't sign for itself
 25 2018-01-12 00:10:14	0|sipa|just like no wallet would crrate an address it can't sig n for
 26 2018-01-12 00:10:54	0|sipa|my typing makes me look like an idiot, it should go sleep
 27 2018-01-12 00:11:21	0|promag|ok, so if fundrawtansaction is called with a change address, no change will happen right?
 28 2018-01-12 00:11:53	0|promag|lol me too --- ... , no change to change will happen right?
 29 2018-01-12 00:12:33	0|sipa|promag: i'm confused now!
 30 2018-01-12 00:12:58	0|gmaxwell|if you've called it with a change address, thats what it would use for change.
 31 2018-01-12 00:13:17	0|promag|gmaxwell: right, ok
 32 2018-01-12 00:13:21	0|promag|another use case:
 33 2018-01-12 00:13:36	0|promag|if a user upgrades to 0.16
 34 2018-01-12 00:14:12	0|promag|and wants to run a while *but* knows that will go back to 0.15
 35 2018-01-12 00:14:19	0|gmaxwell|Release notes will reflect that if you want to be able to downgrade you'll need to set the type to legacy.
 36 2018-01-12 00:14:55	0|gmaxwell|thats part of my rational on the auto-native PR to not override a selection of legacy even if all outputs are segwit.
 37 2018-01-12 00:14:56	0|promag|meanwhile wants to send to a bech32, but doesn't want to add 0.16 stuff to his wallet, because he will go back to 0.15. makes sense?
 38 2018-01-12 00:15:44	0|gmaxwell|right, I specifically arugued that the auto use of native should not apply if the wallet has been specifically set to use legacy outputs for change for mostly that reason.
 39 2018-01-12 00:16:09	0|sipa|the upgrade will be kind of hard to avoid
 40 2018-01-12 00:16:41	0|promag|why?
 41 2018-01-12 00:16:41	0|sipa|if you even just send to a bech32, listtransacrions will return bogus addresses after downgrade
 42 2018-01-12 00:16:53	0|gmaxwell|if you set legacy the only way you'll end up with segwit anything would be either due to manual action or some maniac manually constructing a segwit address for you based on your non-segwit addresses (a suicidal move).
 43 2018-01-12 00:16:55	0|sipa|even without evrr creating such an address yourself
 44 2018-01-12 00:17:17	0|promag|sipa: but balance will be correct right?
 45 2018-01-12 00:17:20	0|sipa|yes
 46 2018-01-12 00:17:22	0|gmaxwell|bogus? hm it just won't show the address. no?
 47 2018-01-12 00:17:36	0|gmaxwell|We already have this case from the payment protocol which allows sending to arbritary scripts.
 48 2018-01-12 00:17:36	0|sipa|gmaxwell: it will show a very weird invalid address, we've discovered
 49 2018-01-12 00:17:47	0|promag|even if the change is bech32 address?
 50 2018-01-12 00:17:52	0|sipa|3Qpvllr or sethong like that
 51 2018-01-12 00:18:36	0|sipa|actually, perhaps this os not the case in listtransactions
 52 2018-01-12 00:18:47	0|gmaxwell|promag: you haven't given enough details, in a downgrade funds send to segwit outputs may not be there, depending on the exact operations.
 53 2018-01-12 00:19:03	0|sipa|generally they will be
 54 2018-01-12 00:19:11	0|gmaxwell|not if they downgrade and use a backup.
 55 2018-01-12 00:19:16	0|gmaxwell|(for example)
 56 2018-01-12 00:19:25	0|sipa|i think pretty much only that
 57 2018-01-12 00:19:38	0|gmaxwell|sipa: or salvagewallet
 58 2018-01-12 00:19:40	0|sipa|downgrading while restoring a backup
 59 2018-01-12 00:19:57	0|gmaxwell|or downgrading in the presence of a reorg perhaps?
 60 2018-01-12 00:20:07	0|sipa|no, that should woek
 61 2018-01-12 00:20:10	0|sipa|*work
 62 2018-01-12 00:20:24	0|gmaxwell|e.g. you downgrade and the txn is removed from the wallet in a reorg but not readded when it confirms?
 63 2018-01-12 00:20:35	0|sipa|txn are never removed from the wallet
 64 2018-01-12 00:20:44	0|sipa|they just become unconfirmed
 65 2018-01-12 00:20:46	0|gmaxwell|ah, point it's just set to unconfir,ed
 66 2018-01-12 00:20:55	0|sipa|i guess with abandontx they can be removed
 67 2018-01-12 00:21:00	0|sipa|in ver specific cases
 68 2018-01-12 00:21:20	0|gmaxwell|In any case, I don't think people should downgrade unless they've been running with legacy mode.
 69 2018-01-12 00:21:31	0|gmaxwell|though indeed, it'll kinda work.
 70 2018-01-12 00:21:51	0|sipa|yes, i think the downgrade after using segwit/bech32 is a best effort thing
 71 2018-01-12 00:21:59	0|sipa|it's very unlikely to lose you money
 72 2018-01-12 00:22:05	0|sipa|but RPC output may be weird
 73 2018-01-12 00:22:40	0|promag|ok guys, thanks for your time
 74 2018-01-12 00:23:21	0|gmaxwell|I'm generally not super comfortable with suggesting things that will have funds go missing if you do something reasonable but slightly uncommon like recover from a backup.
 75 2018-01-12 00:23:49	0|gmaxwell|The "wallet forgot about my outputs" kind of funds loss is pretty creepy.
 76 2018-01-12 00:25:47	0|promag|gmaxwell: btw, do you think seeing the checkbox could be considered an "expert" option?
 77 2018-01-12 00:26:26	0|gmaxwell|Hm. I dunno. It's not really a thing that a user could usually hurt themself with.
 78 2018-01-12 00:26:36	0|promag|do we want people to randomly check/uncheck like "what does this do?"
 79 2018-01-12 00:27:24	0|gmaxwell|E.g. say they select it, get a bech32 addres... recieving site rejects it... then they can try again without it. I guess if they're really confused they might not figure out that they need to turn it off since the site will say "invalid address"...
 80 2018-01-12 00:28:16	0|promag|didn't thought of that
 81 2018-01-12 00:29:30	0|gmaxwell|best would probably be to have very descriptive help text that says "This will use an address that begins with BC1 instead of 1 and will result in lower transaction fees in the future. BC1 style addresses are not accepted everywhere yet. Turn off this option if the sending party says your address is invalid" or similar.
 82 2018-01-12 00:32:05	0|gmaxwell|hopefully in a year or two we can bury the option to turn off these addresses behind some advanced thing... but I think early on it will need to be accessible because people will need both.
 83 2018-01-12 01:18:02	0|ossifrage|Has anyone noticed a large uptick in "non-continuous headers sequence" from peers?
 84 2018-01-12 01:26:09	0|gmaxwell|ossifrage: idiotic bitcoin gold peers.
 85 2018-01-12 01:28:04	0|ossifrage|gmaxwell, ah... it takes a while for them to get banned
 86 2018-01-12 01:28:36	0|gmaxwell|I thought btg changed the network magic?
 87 2018-01-12 01:29:20	0|gmaxwell|I guess its from people setting that option that lets them sync from bitcoin nodes or something, should probably submit a PR to them to remove that option.
 88 2018-01-12 01:29:58	0|ossifrage|It seems to take about 10 'misbehaving's to get them banned
 89 2018-01-12 01:30:20	0|ossifrage|but my grep foo may be catching other stuff
 90 2018-01-12 01:49:39	0|CubicEarths|surprisingly, Bitcoin Gold synced quickly using its own peers
 91 2018-01-12 04:06:40	0|achow101|how come when I enable libevent debugging I don't see any libevent stuff in the debug.log?
 92 2018-01-12 05:49:29	0|gmaxwell|The reason I bring up PR11739 is that getting the SW lockin along with wallet support would be pretty nice to have... since zomg 20000 block reorg fud continues.
 93 2018-01-12 05:49:48	0|d4ve|how can I convert this wallet address into something blockcypher api will understand? 04f50cd1051946c76f0dfe51bdda96b05c3007d81b56c6495c6adbf9db0c75a0f07bbde3e496447a80bb6f3813f5f01c513d4f1d55fec182ac518855065a299c31
 94 2018-01-12 05:52:20	0|d4ve|into WIF format
 95 2018-01-12 05:53:37	0|Randolf|d4ve:  Does libbase58 do what you need?  https://github.com/bitcoin/libbase58
 96 2018-01-12 05:54:05	0|d4ve|i hope so
 97 2018-01-12 05:54:20	0|d4ve|I am using this to extract the pub key from the .pem file :   openssl ec -in priv.pem -pubout -outform DER|tail -c 65|xxd -p -c 65
 98 2018-01-12 05:54:35	0|d4ve|but I want it in WIF format
 99 2018-01-12 05:55:31	0|gmaxwell|WIF format is for private keys.
100 2018-01-12 05:59:27	0|Randolf|d4ve:  This might be useful for a few one-off conversions, and the JavaScript code therein may be helpful for other implementations like what you need:  https://brainwalletx.github.io/#converter
101 2018-01-12 06:01:11	0|Randolf|d4ve:  If you're not asking a question relating to core development, but rather an end-user type of question, then the #bitcoin channel is best-suited to that.
102 2018-01-12 06:01:34	0|d4ve|thanks... so I need to convert to base58?
103 2018-01-12 06:02:11	0|d4ve|that doesnt produce a valid address either
104 2018-01-12 06:02:12	0|Randolf|Base58Check.
105 2018-01-12 06:02:29	0|Randolf|a.k.a., B58Check on that conversion page.
106 2018-01-12 06:05:05	0|d4ve|ok, thanks for the help
107 2018-01-12 06:09:58	0|Randolf|d4ve:  You're welcome.
108 2018-01-12 06:33:58	0|jonasschnelli|BlueMatt: can you shortly comment on https://github.com/bitcoin/bitcoin/pull/11937/files#r159596830?
109 2018-01-12 07:33:19	0|maaku|<morcos> aren't those a bit premature for PR's?
110 2018-01-12 07:33:36	0|maaku|...no? they're explicitly ready for review and merge. we consider them done.
111 2018-01-12 07:35:17	0|maaku|I don't know what Chris_Stewart_5 is talking about. The MAST PR's are not considered immature or work in progress. They are seriously proposed for inclusion in bitcoin core.
112 2018-01-12 07:36:24	0|maaku|As to whether there is consensus for such features, I'm not sure how to answer that. There is a great deal of excitement in the community about MAST. There's not any critique for why we shouldn't have MAST, in general, that I'm aware of.
113 2018-01-12 07:36:39	0|maaku|If there's some objection someone has they should speak up, and should have spoken up months ago.
114 2018-01-12 07:46:21	0|bitcoin-git|[13bitcoin] 15maaku opened pull request #12167: Make segwit failure due to CLEANSTACK violation return a SCRIPT_ERR_CLEANSTACK error code (06master...06cleanstack-script-error) 02https://github.com/bitcoin/bitcoin/pull/12167
115 2018-01-12 07:56:29	0|gmaxwell|maaku: should have spoken up months ago?
116 2018-01-12 07:56:50	0|gmaxwell|maaku: That is a seriously inappropriate tone.
117 2018-01-12 07:58:01	0|maaku|gmaxwell: It's also impolite to hold off on speaking up for why a feature shouldn't be adopted while development goes on for that feature for months.
118 2018-01-12 07:58:48	0|maaku|Particularly when regular updates are provided in person and online during that time, and nobody speaks up for reasons against adoption of the feature.
119 2018-01-12 07:59:06	0|maaku|11th hour objections seriously waste people's time.
120 2018-01-12 08:00:01	0|gmaxwell|maaku: 11th hour? regarding a BIP that hit the list less than two months ago?
121 2018-01-12 08:00:29	0|maaku|gmaxwell: I think perhaps you are reading different into my statement
122 2018-01-12 08:01:10	0|maaku|If someone had an objection to the concept of MAST or this general approach, September of 2017 would have been a good time to air it.
123 2018-01-12 08:01:36	0|gmaxwell|Actually people did raise objections to you multiple times, you have agressively steamrolled their positions!
124 2018-01-12 08:02:05	0|maaku|To the concept of MAST in general?
125 2018-01-12 08:02:18	0|maaku|Again I think you are reading something I didn't say
126 2018-01-12 08:02:51	0|gmaxwell|Okay.
127 2018-01-12 08:04:00	0|gmaxwell|please avoid language that will shut down open discussion.
128 2018-01-12 08:04:03	0|sipa|I don't think I've heard concerns about the general concept of MAST.
129 2018-01-12 08:04:15	0|gmaxwell|There is no point, even _post_ deployment when it's too late to raise concerns.
130 2018-01-12 08:04:39	0|maaku|I agree. I didn't say otherwise.
131 2018-01-12 08:05:06	0|gmaxwell|okay, my apologies then-- that was how the above comments came across to me, thus the comment about tone.
132 2018-01-12 08:05:24	0|maaku|But if someone has an objection, they should not wait on it.
133 2018-01-12 08:06:13	0|sipa|I do think there have been several concerns voiced about how it makes static analysis harder/impossible, and more specifocly later that sigop and ops limits are removed from the subscript.
134 2018-01-12 08:06:34	0|maaku|Morcos asked if there is even consensus over whether this feature is wanted. I know of no one who has ever said we should not have MAST in some form. If there is such an objection, I would like to hear it.
135 2018-01-12 08:07:02	0|gmaxwell|ah! the context you pasted was just about PRs.
136 2018-01-12 08:07:42	0|sipa|i missed that too
137 2018-01-12 08:08:08	0|gmaxwell|(and then you said ready for merge, should have raised objections... so hopefully you can see why I was not reading that about the general construction.)
138 2018-01-12 08:16:41	0|maaku|gmaxwell: what you call "aggressive steamrolling" I call data-driven development
139 2018-01-12 08:24:41	0|echeveria|maaku: I literally never knew there was anything more than the idea of MAST.
140 2018-01-12 08:25:18	0|echeveria|that being a PR is pretty surprising to me, I had no idea it was anything beyond wishful thinking.
141 2018-01-12 08:26:25	0|gmaxwell|well, thats a utility of the PR then...
142 2018-01-12 08:30:12	0|luke-jr|I do recall the sigop issue being mentioned when I tried to add MAST to witnessv1 stuff
143 2018-01-12 08:46:09	0|maaku|luke-jr: the sigop / static analysis issue with respect to this proposal came up on the mailing list in September of last year
144 2018-01-12 08:46:10	0|maaku|https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014992.html
145 2018-01-12 08:46:54	0|maaku|quoting the email : "4MB of secp256k1 signatures takes 10s to validate on my 5 year old laptop (125,000 signatures, ignoring public keys and other things that would consume space). That's much less than bad blocks that can be constructed using other vulnerabilities."
146 2018-01-12 08:47:52	0|maaku|There may be a small constant factor on that, but the point is that you can do more damage in terms of a bad block by other means than stuffing sigops.
147 2018-01-12 08:49:51	0|gmaxwell|10s to validate is not generally acceptable.
148 2018-01-12 08:50:10	0|maaku|10s to validate can be done with 1MB of quadratic hashing
149 2018-01-12 08:51:19	0|gmaxwell|only with strange prep, 2 seconds otherwise; and there is a pretty big difference between attacks that require miner cooperation with non-standard transactions and stuff that can be done with ordinary transactions.
150 2018-01-12 08:58:26	0|maaku|gmaxwell: we shouldn't talk specifics online, but I can make a block with no prep that takes 20s to validate using hashing tricks
151 2018-01-12 08:59:06	0|maaku|using standard transactions
152 2018-01-12 08:59:24	0|maaku|that's why I'm confused about the objection to something which, on the same system, maxes out at 10s validation times
153 2018-01-12 08:59:44	0|gmaxwell|As I've told you before, if thats the case we should fix it.
154 2018-01-12 09:01:07	0|maaku|How? By introducing additional limits? That's not an obvious win to me.
155 2018-01-12 09:01:33	0|maaku|Particularly when the foregone transaction fees provide an economic protection against these attacks.
156 2018-01-12 11:22:50	0|bitcoin-git|[13bitcoin] 15jsarenik opened pull request #12168: Trivial: Fix #include sys/fcntl.h to just fcntl.h (without sys/) (06master...06jasan/fcntl.h) 02https://github.com/bitcoin/bitcoin/pull/12168
157 2018-01-12 11:24:10	0|bitcoin-git|[13bitcoin] 15kekimusmaximus opened pull request #12169: Avoid temporary copies in C++11 ranged-based for loops. (06master...06remove_loop_implicit_casts) 02https://github.com/bitcoin/bitcoin/pull/12169
158 2018-01-12 11:42:33	0|morcos|maaku: It is possible I have been out of the loop.  As you may know a lot has been happening in the last several months.
159 2018-01-12 11:42:44	0|morcos|I though there were several MAST proposals in the works
160 2018-01-12 11:43:14	0|morcos|I thought based on the amount of traffic that they weren't currently getting anywhere near the developer or community mindshare to be getting near adoption
161 2018-01-12 11:43:38	0|morcos|I'd seen know discussion on whetther there was any consensus to the protocol changes or not
162 2018-01-12 11:44:15	0|morcos|To be honest, I don't know if I have any concerns or objections becuase I haven't looked at it yet.  I'm in favor of the general concept, but I'm not convinced it should be a priority right now
163 2018-01-12 11:45:16	0|morcos|It would be one thing if it wasn't a consensus change, but it is, so I think before discussing PR's being ready for Core, it makes sense to discuss whether the community wants this.
164 2018-01-12 11:46:10	0|morcos|That said, having Code is always helpful, and its good for me and others to get the feedback that this is further along than I thought if thats the case
165 2018-01-12 12:21:09	0|provoostenator|sipa: I'm a bit confused as to how to interpret scenario 1 in your gist. At least in the test I wrote, if you restore from a backup then any addresses that were generated after that backup would only reappear if you remember the correct sequence of legacy/p2sh-segwit/bech32 choices: https://github.com/bitcoin/bitcoin/pull/12152
166 2018-01-12 12:21:33	0|provoostenator|And funds don't show up for me unless I get that sequence right.
167 2018-01-12 12:21:54	0|sipa|provoostenator: that's a bug!
168 2018-01-12 12:21:57	0|gmaxwell|?!? what do you mean choices?!
169 2018-01-12 12:22:09	0|provoostenator|sipa: ok, either that or my test is wrong.
170 2018-01-12 12:22:14	0|gmaxwell|they should all appear with you doing nothing but starting the software and waiting for the rescan to complete.
171 2018-01-12 12:22:20	0|sipa|yup
172 2018-01-12 12:22:28	0|sipa|amd it is totally plausible that it is broken
173 2018-01-12 12:22:31	0|sipa|*and
174 2018-01-12 12:22:45	0|sipa|in which case i'd very much like to know
175 2018-01-12 12:22:48	0|provoostenator|Right, but that's what the "look for related keys" logic is for, right?
176 2018-01-12 12:23:15	0|gmaxwell|I did test this at one point.
177 2018-01-12 12:23:38	0|gmaxwell|though only with native segwit outputs.
178 2018-01-12 12:23:49	0|provoostenator|Maybe it's because my tests use accounts, I don't know how that changes things.
179 2018-01-12 12:27:27	0|sipa|provoostenator: the account obviously won't be credited - it can't predict which label you'll give future addresses
180 2018-01-12 12:27:39	0|sipa|but the wallet balance should get uodated
181 2018-01-12 12:30:46	0|provoostenator|I didn't check the total wallet balance, so that might be it then. So after restoring from a backup a user would see random new addresses have funds?
182 2018-01-12 12:31:32	0|sipa|yes
183 2018-01-12 12:31:39	0|provoostenator|I suppose the only way to prevent that is to disallow address creation before rescan / sync is done.
184 2018-01-12 12:31:50	0|sipa|?
185 2018-01-12 12:32:33	0|provoostenator|The wallet would check to see if a key already has funds and then skip it in the new address UI.
186 2018-01-12 12:32:58	0|sipa|i'm very confused :)
187 2018-01-12 12:33:32	0|provoostenator|Right now if you click on new address it will just pick the next key, even the corresponding address has coins on it.
188 2018-01-12 12:33:40	0|sipa|no
189 2018-01-12 12:33:42	0|sipa|oh... if an address is seen used on the network it is removed from the keypool
190 2018-01-12 12:33:44	0|provoostenator|Which is weird for the user, because they thought they created a fresh address.
191 2018-01-12 12:33:56	0|sipa|so it won't be given out agaon
192 2018-01-12 12:34:11	0|provoostenator|"is seen used" is the operating word then, because in my test it doesn't see it in time.
193 2018-01-12 12:34:24	0|sipa|okay
194 2018-01-12 12:34:29	0|sipa|well there may be a bug!
195 2018-01-12 12:34:46	0|sipa|or maybe you didn't wait for rescan etc
196 2018-01-12 12:34:58	0|provoostenator|I did the rescan after generating the address, yes.
197 2018-01-12 12:34:58	0|sipa|s/rescan/sync/
198 2018-01-12 12:35:10	0|provoostenator|So you're saying if I do a rescan before generating an new address this won't happen?
199 2018-01-12 12:35:13	0|sipa|there shouldn't be a need for rescan
200 2018-01-12 12:37:01	0|provoostenator|What happens when you load an outdated wallet backup where new addresses have been added and funded by the user? Does it rescan it?
201 2018-01-12 12:37:47	0|sipa|at startup, if your wallet is older than the chain, the missing part is automatically rescanned
202 2018-01-12 12:38:33	0|provoostenator|In. my test (line 206) I had to do a rescan in order for the balances to show up on generated addresses.
203 2018-01-12 12:39:02	0|provoostenator|Maybe that's because regtest behaves different in this regard and doens't do rescans automatically.
204 2018-01-12 12:40:06	0|provoostenator|The test stops the node, replaces the wallet with an older version, starts the node, generates the same addresses and then calls rescan. That's when the balance shows up for these addresses.
205 2018-01-12 12:40:24	0|provoostenator|Without rescan the address balances remain zero, though I didn't check the wallet balance.
206 2018-01-12 12:40:41	0|provoostenator|I'll try some variations once I understand the intented behavior better.
207 2018-01-12 12:40:54	0|sipa|don't look at address balance
208 2018-01-12 12:40:59	0|sipa|look at wallet balance
209 2018-01-12 12:41:07	0|sipa|listtransactions maybreport garbage
210 2018-01-12 12:41:14	0|sipa|listunspent should probably work
211 2018-01-12 12:41:24	0|provoostenator|I'm using getbalance("account name")
212 2018-01-12 12:41:33	0|sipa|... how could that possibly work?
213 2018-01-12 12:41:53	0|sipa|the backup doesn't know what name you're going to give a future address
214 2018-01-12 12:41:54	0|provoostenator|Which I'm assuming is what QT relies on to show the balance in the receive tab, so it could be pretty confusing (but haven't tested)
215 2018-01-12 12:42:00	0|sipa|no
216 2018-01-12 12:42:07	0|sipa|that's even a deprecated RPC
217 2018-01-12 12:42:21	0|sipa|the GUI doesn't support accounts, and never has
218 2018-01-12 12:42:42	0|blueneon|Hi there, I've made a fork/clone of the bitcoin coin in order for me to play around and get familiar. All went well after updating chainparams.cpp etc and I created new genesis and merkle etc -the code compiles and runs. However it crashes and debug.log says: ERROR: ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=8)
219 2018-01-12 12:42:50	0|blueneon|Any advise would be much appreciated.
220 2018-01-12 12:42:50	0|provoostenator|Ah, that points to my confusion between accouts and labels then..
221 2018-01-12 12:43:03	0|sipa|blueneon: ##altcoin-dev
222 2018-01-12 12:43:17	0|blueneon|Ok thanks
223 2018-01-12 12:43:34	0|sipa|provoostenator: the only thing you should be looking at is getbalance (without argument), listtransactions, listunspent
224 2018-01-12 12:44:08	0|provoostenator|How is the label that I use in QT when I create a payment reqest represented in the RPC?
225 2018-01-12 12:44:14	0|blueneon|seems ##altcoin-dev is a dead chan :/
226 2018-01-12 12:44:59	0|blueneon|Any chance someone here can shed light on my issue?
227 2018-01-12 12:45:09	0|sipa|blueneon: not here, sorry
228 2018-01-12 12:45:49	0|provoostenator|blueneon: that's not a good way to get familiar with the code in my experience. I somewhat selfishly suggest looking at random bitcoin core github issues and trying to help out in little bits.
229 2018-01-12 12:45:50	0|sipa|provoostenator: labels amd accounts are the same up to that functionality... it's a name associated with an address
230 2018-01-12 12:46:01	0|sipa|provoostenator: but labels don't have a balance
231 2018-01-12 12:46:16	0|sipa|listreceivedbyaddress would also work
232 2018-01-12 12:46:36	0|provoostenator|Ah, so a key has multiple addresses, each address can have a label. Not in the other direction?
233 2018-01-12 12:46:37	0|sipa|but inherently, when recovering fromna backup, the labels won't be there - they can't be
234 2018-01-12 12:46:54	0|gmaxwell|one of the many limitations of labels.
235 2018-01-12 12:47:06	0|sipa|provoostenator: addresses have a label; multiple addresses can have the same label
236 2018-01-12 12:47:25	0|provoostenator|I know the labels wouldn't come back. But when the user creates a payment request that address shouldn't already have money on it. But it seems I didn't actually test that, becaus eI was using accounts.
237 2018-01-12 12:48:15	0|provoostenator|Multiple address (from different keys?) can have identical label strings or do you mean they point to the same label object?
238 2018-01-12 12:48:26	0|sipa|provoostenator: what's the difference?
239 2018-01-12 12:48:49	0|provoostenator|The difference is what happens to the label of addres A if I change the label of address B.
240 2018-01-12 12:48:58	0|provoostenator|If they were identical before.
241 2018-01-12 12:48:59	0|sipa|oh, i see
242 2018-01-12 12:49:03	0|sipa|nothing changes to A
243 2018-01-12 12:49:12	0|provoostenator|In other words, what's the SQL schema :-)
244 2018-01-12 12:49:23	0|sipa|addresses have a string lab
245 2018-01-12 12:49:25	0|sipa|el
246 2018-01-12 12:49:48	0|gmaxwell|same label can be on many addresses (and often is)
247 2018-01-12 12:49:53	0|sipa|pro when the user requests a payment it should never give out an address associated with a key that has already been used
248 2018-01-12 12:50:02	0|sipa|*provoostenator
249 2018-01-12 12:51:33	0|provoostenator|Alright, I'll take another look with that background.
250 2018-01-12 12:51:57	0|provoostenator|How are we doing on actually deprecating accounts?
251 2018-01-12 12:52:13	0|sipa|basically rename the string account label everywhere in the source code
252 2018-01-12 12:52:21	0|sipa|and then removing getbalance(account)
253 2018-01-12 12:52:30	0|sipa|and removing the ability to specify a "from" account
254 2018-01-12 12:52:36	0|sipa|when creating a tx
255 2018-01-12 13:02:26	0|sipa|provoostenator: actually, i am pretty interested in knowing what listtransactions shows after recovery
256 2018-01-12 13:03:49	0|provoostenator|sipa: I can take a look later (you should be able to run the backwards compatibilty tests locally in the meantime).
257 2018-01-12 13:18:51	0|provoostenator|sipa: wallet balance immedidately after backup restore: 3 (missing funds and transactions from the post-backup keys)
258 2018-01-12 13:21:55	0|provoostenator|If I add a rescan to the test, 2 coins and their transactions reappear (not associated with an account).
259 2018-01-12 13:24:32	0|provoostenator|There's a third coin that won't appear until you've called getnewaddress 3 times.
260 2018-01-12 13:25:52	0|sipa|provoostenator: after a confirmation?
261 2018-01-12 13:26:25	0|provoostenator|Yes, these were all confirmed and synced before deleting the wallet and replacing it with a backup.
262 2018-01-12 13:26:40	0|provoostenator|But I'm a bit confused myself now as to what's so special about htat 3rd ps2sh-segwit address.
263 2018-01-12 13:27:41	0|provoostenator|It appears that a rescan revealed the wallet balance for 2 out of 3 keys (p2sh-segwit, bech32, p2sh-segwit), but it took 3 calls to getnewaddress to reveal the third one. Either a bug or more likely something really weird about my test.
264 2018-01-12 13:28:21	0|provoostenator|Or maybe these transactions are chained in a way that matters.
265 2018-01-12 13:28:39	0|provoostenator|I have a node0 which mines the blocks and sprinkles coins to the test nodes.
266 2018-01-12 13:31:08	0|provoostenator|https://gist.github.com/Sjors/b6ad5ee7a12973ad93edd81e2beff876
267 2018-01-12 13:31:33	0|provoostenator|That's the output of listtransactions at the end. The bottom transaction didn't immedidatley show up.
268 2018-01-12 13:34:53	0|provoostenator|Here's the 5 transactions (from a different test run) where I called rescan immedidatley after recovery: https://gist.github.com/Sjors/df8a35ae3481f83546d2ec7518e0ce28  (note that the last two account names aren't know, obviously)
269 2018-01-12 13:35:45	0|provoostenator|I should probably run these with deterministic random seed for easier comparison.
270 2018-01-12 13:37:47	0|sdaftuar|gmaxwell: re #11739 -- thoughts on next steps there?  i was thinking i need to document the change somehow, perhaps an update to the relevant bips and an email to the -dev list?
271 2018-01-12 13:37:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/11739 | RFC: Enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis by sdaftuar · Pull Request #11739 · bitcoin/bitcoin · GitHub
272 2018-01-12 13:39:48	0|gmaxwell|sdaftuar: sounds good to me.
273 2018-01-12 13:43:24	0|provoostenator|I should add that these 3 transactions, of which 1 only appears later, are in the same block.
274 2018-01-12 13:57:34	0|sipa|provoostenator: cool, i'll loook into it
275 2018-01-12 15:26:18	0|larafale|hello guys, any brave soul to help me on this. I'm learning and testing address decoding. I've got a public key (from an electrum wallet) and I'm trying to ripemd160(sha256(pubkey)), but the result I get is not the result I'm expecting. I thought the result was going to be the pubkeyhash present in the scriptpubkey in one of the output where that address was used. Am I missing something ?
276 2018-01-12 15:27:55	0|sipa|larafale: https://bitcoin.stackexchange.com
277 2018-01-12 15:55:07	0|Randolf|larafale:  This may also be helpful to you:  https://github.com/bitcoin/libbase58
278 2018-01-12 16:48:13	0|SopaXorzTaker|Why does "satoshi" appear in the BIP39 wordlist?
279 2018-01-12 16:48:25	0|SopaXorzTaker|I don't think that's a well-known, unique English word
280 2018-01-12 16:48:30	0|SopaXorzTaker|a tribute to Nakamoto?
281 2018-01-12 16:52:14	0|mlz|SopaXorzTaker, wrong channel
282 2018-01-12 16:55:13	0|SopaXorzTaker|mlz, I know, I am sorry
283 2018-01-12 16:55:21	0|SopaXorzTaker|but there's no #ask-bitcoin-devs
284 2018-01-12 17:32:12	0|jtimon|I'm not sure I understand the point of fDumpMempoolLater ...
285 2018-01-12 17:33:23	0|gmaxwell|jtimon: we don't want to dump the mempool if we haven't finished loading the last dump yet.
286 2018-01-12 17:34:34	0|jtimon|well, that code doesn't seem to be working then, https://github.com/bitcoin/bitcoin/issues/12142
287 2018-01-12 17:35:33	0|gmaxwell|I think thats just an issue with the rpc, it handles it fine on shutdown as far as I know.
288 2018-01-12 17:36:04	0|jtimon|shouldn't https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L682 just set it to true? why to !fRequestShutdown ?
289 2018-01-12 17:37:08	0|jtimon|no, never minf
290 2018-01-12 18:38:42	0|provoostenator|Call me superstitious, but Travis seems in a much better mood today.
291 2018-01-12 18:45:13	0|BlueMatt|aws disk io more available cause everyone's jobs got slowed down at the cpu level for meltdown fixes? :p
292 2018-01-12 18:56:40	0|cfields|gmaxwell: interesting side-effect from the toolchain work, you may be interested: https://gcc.gnu.org/ml/gcc/2018-01/msg00068.html
293 2018-01-12 21:01:06	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #12172: Bugfix: RPC: savemempool: Don't save until LoadMempool() is finished (06master...06b16-bugfix-savemempool) 02https://github.com/bitcoin/bitcoin/pull/12172
294 2018-01-12 21:03:00	0|jtimon|being a bugfix, could #12172 get in for 0.16 ?
295 2018-01-12 21:03:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/12172 | Bugfix: RPC: savemempool: Dont save until LoadMempool() is finished by jtimon · Pull Request #12172 · bitcoin/bitcoin · GitHub
296 2018-01-12 21:06:48	0|jtimon|btw, gmaxwell previously I was wondering if I could reuse fDumpMempoolLater instead of creating g_is_mempool_loaded, thanks for the help
297 2018-01-12 21:31:37	0|luke-jr|jtimon: IMO savemempool shouldn't succeed until it is actually saved, so if you make it delay the save, the RPC probably needs to block, which is complex
298 2018-01-12 21:32:50	0|jtimon|luke-jr: yeah, that's an interesting point but kind of orthogonal, no? (although definitely related)
299 2018-01-12 21:35:58	0|jtimon|luke-jr: perhaps I can add something to the documentation while at it?
300 2018-01-12 21:36:41	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #12173: [Qt] Use flexible font size for QRCode image address (06master...062018/01/fix_qr_font) 02https://github.com/bitcoin/bitcoin/pull/12173
301 2018-01-12 21:40:08	0|jonasschnelli|sipa: mind doing a short review on #11281 (since you have raised some issues there)?
302 2018-01-12 21:40:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
303 2018-01-12 22:28:31	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0910cbe4ef31...b7450cdbd89a
304 2018-01-12 22:28:32	0|bitcoin-git|13bitcoin/06master 14ca9085a 15Russell Yanofsky: Prevent TestNodeCLI.args mixups...
305 2018-01-12 22:28:32	0|bitcoin-git|13bitcoin/06master 14fcfb952 15Russell Yanofsky: Improve TestNodeCLI output parsing...
306 2018-01-12 22:28:33	0|bitcoin-git|13bitcoin/06master 14ff9a363 15Russell Yanofsky: TestNodeCLI batch emulation...
307 2018-01-12 22:29:28	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11970: Add test coverage for bitcoin-cli multiwallet calls (06master...06pr/mcli) 02https://github.com/bitcoin/bitcoin/pull/11970
308 2018-01-12 23:05:59	0|bitcoin-git|[13bitcoin] 15MarcoFalke reopened pull request #12089: qa: Make TestNodeCLI command optional in send_cli (06master...06Mf1801-qaCliOptions) 02https://github.com/bitcoin/bitcoin/pull/12089