< 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.
< promag> sipa: do you think fundrawtransaction should have changetype option?
< gmaxwell> Also things like the payment protocol allow sending funds to a specific script which may not have any address encoding.
< sipa> promag: i guess it could have, yes
< 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.
< promag> folks using just rpc, doing manual signing, can't expect seeing fewer (usable) utxo after upgrading
< gmaxwell> hm?
< gmaxwell> promag: I don't understand your last comment.
< promag> suppose someone creates raw transactions with utxos
< promag> and only uses utxos with "address", because those are the ones the system knows how to sign
< sipa> promag: that's not true
< sipa> bitcoin core was able to sign P2WPKH long before an address type for it existed
< promag> the system != bitcoind
< gmaxwell> indeed, and native mulsig too.
< sipa> and pay to pubkey
< promag> suppose signing is not done with bitcoind
< sipa> ok
< 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.
< sipa> promag: imagine listunspent just gace the svriptPubKey instead of the address
< gmaxwell> promag: suppose signing is done by something that doesn't know anything about p2sh-p2wpkh? it can't sign for that. But so?
< gmaxwell> Some things can't sign for some things, but this is unrelated to addresses.
< promag> so, if there is some fixed decision of change type, then the utxo set is useless for those folks
< sipa> promag: but the type of change is determined by that signer
< sipa> no signer would create a type of change it couldn't sign for itself
< sipa> just like no wallet would crrate an address it can't sig n for
< sipa> my typing makes me look like an idiot, it should go sleep
< promag> ok, so if fundrawtansaction is called with a change address, no change will happen right?
< promag> lol me too --- ... , no change to change will happen right?
< sipa> promag: i'm confused now!
< gmaxwell> if you've called it with a change address, thats what it would use for change.
< promag> gmaxwell: right, ok
< promag> another use case:
< promag> if a user upgrades to 0.16
< promag> and wants to run a while *but* knows that will go back to 0.15
< gmaxwell> Release notes will reflect that if you want to be able to downgrade you'll need to set the type to legacy.
< gmaxwell> thats part of my rational on the auto-native PR to not override a selection of legacy even if all outputs are segwit.
< 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?
< 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.
< sipa> the upgrade will be kind of hard to avoid
< sipa> if you even just send to a bech32, listtransacrions will return bogus addresses after downgrade
< promag> why?
< 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).
< sipa> even without evrr creating such an address yourself
< promag> sipa: but balance will be correct right?
< sipa> yes
< gmaxwell> bogus? hm it just won't show the address. no?
< gmaxwell> We already have this case from the payment protocol which allows sending to arbritary scripts.
< sipa> gmaxwell: it will show a very weird invalid address, we've discovered
< promag> even if the change is bech32 address?
< sipa> 3Qpvllr or sethong like that
< sipa> actually, perhaps this os not the case in listtransactions
< 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.
< sipa> generally they will be
< gmaxwell> not if they downgrade and use a backup.
< gmaxwell> (for example)
< sipa> i think pretty much only that
< gmaxwell> sipa: or salvagewallet
< sipa> downgrading while restoring a backup
< gmaxwell> or downgrading in the presence of a reorg perhaps?
< sipa> no, that should woek
< sipa> *work
< gmaxwell> e.g. you downgrade and the txn is removed from the wallet in a reorg but not readded when it confirms?
< sipa> txn are never removed from the wallet
< sipa> they just become unconfirmed
< gmaxwell> ah, point it's just set to unconfir,ed
< sipa> i guess with abandontx they can be removed
< sipa> in ver specific cases
< gmaxwell> In any case, I don't think people should downgrade unless they've been running with legacy mode.
< gmaxwell> though indeed, it'll kinda work.
< sipa> yes, i think the downgrade after using segwit/bech32 is a best effort thing
< sipa> it's very unlikely to lose you money
< sipa> but RPC output may be weird
< * sipa> goes into standby
< promag> ok guys, thanks for your time
< 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.
< gmaxwell> The "wallet forgot about my outputs" kind of funds loss is pretty creepy.
< promag> gmaxwell: btw, do you think seeing the checkbox could be considered an "expert" option?
< gmaxwell> Hm. I dunno. It's not really a thing that a user could usually hurt themself with.
< promag> do we want people to randomly check/uncheck like "what does this do?"
< 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"...
< promag> didn't thought of that
< 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.
< 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.
< ossifrage> Has anyone noticed a large uptick in "non-continuous headers sequence" from peers?
< gmaxwell> ossifrage: idiotic bitcoin gold peers.
< ossifrage> gmaxwell, ah... it takes a while for them to get banned
< gmaxwell> I thought btg changed the network magic?
< 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.
< ossifrage> It seems to take about 10 'misbehaving's to get them banned
< ossifrage> but my grep foo may be catching other stuff
< CubicEarths> surprisingly, Bitcoin Gold synced quickly using its own peers
< smack> ma
< smack> man
< smack> such wow
< achow101> how come when I enable libevent debugging I don't see any libevent stuff in the debug.log?