1 2018-01-20 12:44:35	0|promag|should we disallow multiple change outputs?
 2 2018-01-20 12:45:04	0|promag|if sendmany sends to a change address, should we create another change or increment that output?
 3 2018-01-20 12:45:57	0|promag|should CreateTransaction always create change outputs?
 4 2018-01-20 12:46:43	0|promag|provoostenator: should you check if there is one change output already and use that type before eveything else?
 5 2018-01-20 12:47:44	0|promag|I'm about to submit 2018-01-reuse-change branch, but I would like to have feedback on these questions, thanks
 6 2018-01-20 12:52:21	0|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)
 7 2018-01-20 12:52:46	0|sipa|promag: i'm not sure sendmany is the right place though
 8 2018-01-20 12:57:40	0|gmaxwell|Also to control dependency chains.
 9 2018-01-20 12:58:37	0|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.
10 2018-01-20 13:08:02	0|promag|gmaxwell: I've done that in the past, where a large change was split in N random outputs
11 2018-01-20 13:08:42	0|promag|sipa: sendmany uses CreateTransaction, as well fundrawtransction and others
12 2018-01-20 13:09:31	0|promag|but should #12119 check existing change outputs?
13 2018-01-20 13:09:34	0|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
14 2018-01-20 13:10:11	0|bitcoin-git|[13bitcoin] 15MCFX2 opened pull request #12232: Improve "Turn Windows Features On or Off" step (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/12232
15 2018-01-20 13:11:28	0|promag|however IMO having the option to reuse change output results in a lower fee so..
16 2018-01-20 13:12:14	0|promag|maybe we should add some enum ChangePolicy flag to daemon argument and rpc options, dunno
17 2018-01-20 13:15:54	0|gmaxwell|huh?
18 2018-01-20 13:16:04	0|gmaxwell|What do you mean by reuse change output?
19 2018-01-20 13:16:29	0|sipa|gmaxwell: if you use getrawchangeaddress and use that as a destination in sendmany
20 2018-01-20 13:16:38	0|gmaxwell|Reusing addresses doesn't result in lower fees, -- perhaps I misunderstand what reuse means in this context?
21 2018-01-20 13:16:42	0|gmaxwell|Ah! I did.
22 2018-01-20 13:17:28	0|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.
23 2018-01-20 13:17:56	0|sipa|promag: imho getrawchangeaddress is an expert feature, mostly intended to be used in conjunction with createrawtransaction
24 2018-01-20 13:18:38	0|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
25 2018-01-20 13:51:22	0|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.
26 2018-01-20 13:59:23	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #12231: rpc: Avoid KeyError in getpeerinfo bytes per msg (06master...06Mf1801-rpcPeerInfoKeyError) 02https://github.com/bitcoin/bitcoin/pull/12231
27 2018-01-20 14:28:58	0|promag|sipa: gmaxwell: there is also the case of fundraw after fundraw
28 2018-01-20 14:29:30	0|promag|if we want to re-fund because fee bump for instance
29 2018-01-20 14:46:21	0|sipa|promag: in the context of fundraw it may make more sense
30 2018-01-20 14:47:24	0|promag|well this is a very very edge case and should probably be handled on the caller side
31 2018-01-20 14:48:03	0|promag|fund returns the change position, if the user wants to refund maybe he should remove the change, and reuse the previously returned address
32 2018-01-20 14:48:06	0|promag|wdyt?
33 2018-01-20 15:28:07	0|promag|Requesting expertise here https://github.com/bitcoin/bitcoin/pull/12119#discussion_r162784913
34 2018-01-20 17:28:55	0|contrapumpkin|is there a good way to ask bitcoin core to reverify the entire chain on disk?
35 2018-01-20 17:29:41	0|contrapumpkin|aha, verifychain in the console looks right
36 2018-01-20 17:29:54	0|eck|there's also a command (i forget the name) to give you a hash of the current utxo set
37 2018-01-20 17:31:56	0|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.
38 2018-01-20 17:33:01	0|jb55|like if I wanted to donate my dust to miners or something
39 2018-01-20 17:35:30	0|sipa|jb55: i know of no good reason for that
40 2018-01-20 17:37:14	0|arubi|jb55, do you mean "no outputs" or zero amount?
41 2018-01-20 17:37:22	0|jb55|no outputs
42 2018-01-20 17:37:32	0|arubi|no that's not a valid transaction
43 2018-01-20 17:37:35	0|jb55|oh?
44 2018-01-20 17:38:04	0|arubi|need one output at least
45 2018-01-20 17:38:19	0|jb55|was asking because of this lightning-rfc issue: https://github.com/lightningnetwork/lightning-rfc/issues/360
46 2018-01-20 17:38:24	0|jb55|wanted to confirm
47 2018-01-20 17:38:53	0|jb55|like it's not valid as consensus rule? where in the code is that
48 2018-01-20 17:40:38	0|jb55|oh CheckTransaction
49 2018-01-20 17:41:11	0|arubi|ah I was trying to find it :)
50 2018-01-20 17:51:54	0|sipa|jb55: conseneus ruoes require at least 1 input and at oeast 1 output in every tx
51 2018-01-20 17:56:14	0|jb55|literally unusable
52 2018-01-20 19:23:20	0|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
53 2018-01-20 19:23:22	0|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
54 2018-01-20 19:23:49	0|BlueMatt|also, #12229 needs an 0.16 tag
55 2018-01-20 19:23:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/12229 | Shutdown deadlock in SyncWithValidationInterfaceQueue · Issue #12229 · bitcoin/bitcoin · GitHub
56 2018-01-20 21:03:08	0|promag|BlueMatt: don't forget #11041
57 2018-01-20 21:03:11	0|gribble|https://github.com/bitcoin/bitcoin/issues/11041 | Add LookupBlockIndex by promag · Pull Request #11041 · bitcoin/bitcoin · GitHub
58 2018-01-20 21:04:11	0|BlueMatt|promag: lol, I havent...on vacation this week so not being super productive review-wise, just marshalling where needed
59 2018-01-20 21:04:25	0|promag|BlueMatt: have fun!
60 2018-01-20 23:39:25	0|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-
61 2018-01-20 23:40:40	0|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]).