< promag> should we disallow multiple change outputs?
< promag> if sendmany sends to a change address, should we create another change or increment that output?
< promag> should CreateTransaction always create change outputs?
< promag> provoostenator: should you check if there is one change output already and use that type before eveything else?
< promag> I'm about to submit 2018-01-reuse-change branch, but I would like to have feedback on these questions, thanks
< sipa> promag: there may be good reasons for multiple change outputs (mostly privacy, but also possibly preparing to split yiur coins during a low-fee period ahead of tike to do multiple concurrent payments)
< sipa> promag: i'm not sure sendmany is the right place though
< gmaxwell> Also to control dependency chains.
< gmaxwell> I was planning on working on implementing autmatic multiple change outputs when change would otherwise be very large, ... after murch's selection stuff makes it in.
< promag> gmaxwell: I've done that in the past, where a large change was split in N random outputs
< promag> sipa: sendmany uses CreateTransaction, as well fundrawtransction and others
< promag> but should #12119 check existing change outputs?
< gribble> https://github.com/bitcoin/bitcoin/issues/12119 | [wallet] use P2WPKH change output if any destination is P2WPKH or P2WSH by Sjors · Pull Request #12119 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MCFX2 opened pull request #12232: Improve "Turn Windows Features On or Off" step (master...patch-1) https://github.com/bitcoin/bitcoin/pull/12232
< promag> however IMO having the option to reuse change output results in a lower fee so..
< promag> maybe we should add some enum ChangePolicy flag to daemon argument and rpc options, dunno
< gmaxwell> huh?
< gmaxwell> What do you mean by reuse change output?
< sipa> gmaxwell: if you use getrawchangeaddress and use that as a destination in sendmany
< gmaxwell> Reusing addresses doesn't result in lower fees, -- perhaps I misunderstand what reuse means in this context?
< gmaxwell> Ah! I did.
< gmaxwell> I had thought our behavior was to merge any repeated outputs, so if you ask it to pay A 1 and A 2, it will pay A 3.
< sipa> promag: imho getrawchangeaddress is an expert feature, mostly intended to be used in conjunction with createrawtransaction
< sipa> promag: i don't see why someone would use change as destination in sendmany at all... it will work fine, but i don't think it's useful or something to spend more work on
< gmaxwell> sipa: so for example, you could pass input requested by users to sendmany, and some genius user could manage to send to some random change address of yours.
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12231: rpc: Avoid KeyError in getpeerinfo bytes per msg (master...Mf1801-rpcPeerInfoKeyError) https://github.com/bitcoin/bitcoin/pull/12231
< promag> sipa: gmaxwell: there is also the case of fundraw after fundraw
< promag> if we want to re-fund because fee bump for instance
< sipa> promag: in the context of fundraw it may make more sense
< promag> well this is a very very edge case and should probably be handled on the caller side
< promag> fund returns the change position, if the user wants to refund maybe he should remove the change, and reuse the previously returned address
< promag> wdyt?
< contrapumpkin> is there a good way to ask bitcoin core to reverify the entire chain on disk?
< contrapumpkin> aha, verifychain in the console looks right
< eck> there's also a command (i forget the name) to give you a hash of the current utxo set
< jb55> is there any reason why zero-output transactions would not be allowed? Other than to catch common mistakes? Just noticed the check in CheckTransaction.
< jb55> like if I wanted to donate my dust to miners or something
< sipa> jb55: i know of no good reason for that
< arubi> jb55, do you mean "no outputs" or zero amount?
< jb55> no outputs
< arubi> no that's not a valid transaction
< jb55> oh?
< arubi> need one output at least
< jb55> was asking because of this lightning-rfc issue: https://github.com/lightningnetwork/lightning-rfc/issues/360
< jb55> wanted to confirm
< jb55> like it's not valid as consensus rule? where in the code is that
< jb55> oh CheckTransaction
< arubi> ah I was trying to find it :)
< sipa> jb55: conseneus ruoes require at least 1 input and at oeast 1 output in every tx
< jb55> literally unusable
< BlueMatt> cfields: if you get a chance to re-review #11512 and ack it, it'd probably be worth merging and we can kill another 0.16-milestone pr
< gribble> https://github.com/bitcoin/bitcoin/issues/11512 | Use GetDesireableServiceFlags in seeds, dnsseeds, fixing static seed adding by TheBlueMatt · Pull Request #11512 · bitcoin/bitcoin · GitHub
< BlueMatt> also, #12229 needs an 0.16 tag
< gribble> https://github.com/bitcoin/bitcoin/issues/12229 | Shutdown deadlock in SyncWithValidationInterfaceQueue · Issue #12229 · bitcoin/bitcoin · GitHub
< promag> BlueMatt: don't forget #11041
< gribble> https://github.com/bitcoin/bitcoin/issues/11041 | Add LookupBlockIndex by promag · Pull Request #11041 · bitcoin/bitcoin · GitHub
< BlueMatt> promag: lol, I havent...on vacation this week so not being super productive review-wise, just marshalling where needed
< promag> BlueMatt: have fun!
< jonasschnelli> gmaxwell: I guess fee estimation for the utxo-scan sweep transaction is not very accurate. Example: If you scan for an p2pkh address, you don't know if the pubkey is compressed-
< jonasschnelli> Also, we don't know if the found P2SH address is a P2SH-P2WPKH or a 1of1 multisig (we could decide to only support a single P2SH form [P2WPKH]).