Topic: What I want in a coin control release. (Read 689 times)

Well, there will always be some reuse. 

The point behind a "Blue" address (as I called it above) is that it's your address for receiving payments from a particular source, and that source doesn't care to get a new address for you every time.  This is your annuity payment, or your paycheck, or your dividend payment, or any of a thousand things that comes out many many times, where you want a firm "account number" that someone else can use over and over. 

There are ways around that if someone has a designation that causes a new address to be negotiated - but that fails if your client doesn't happen to be online at the moment when someone else wants to pay you, so it's not very reliable.  There are other ways around it if someone can compute a new address for you given one of your old ones, but then your addresses are linkable.

Because it was not anticipated that users would reuse addresses to begin with. It's intended that they use a new address for every transaction.

The whole point of the post was that different people *do* want different things in coin control.  I never imagined that my "rules" above should be everyone's rules.  I threw them out as an example.

If you want different behavior from coin control, then you should have different options checked in the coin control dropdown box or whatever UI it eventually acquires. 

Anyway, the latest client has this new feature; what do various people want from it?

As for the question of what I want to happen if the coin control settings make a payment impossible, I want a dialog box that says so and gives me the option of canceling the payment (So I can then do it a different way) or disregarding coin control to make the payment.

It's true that spending all coin from a given address when spending any does frontload transaction fees, and, as you said, that's probably cheaper for the user in the long run.  But it also reduces the number of unspent txouts, which is good for the whole network, and also helps to preserve the user's financial privacy.  So, I really don't see why this isn't the default.  It is good for literally every purpose it touches. 

No.

Glad we've settled that.

You can feel free to ignore payments you don't like and weren't made to your specification. Heck, feel free to define some address format that makes your requirements crystal clear. There is no need to add risky complexity to our already very complex consensus protocol to try to force users to not be stupid.

This will also frontload all fee payments— e.g. you could make a free transaction but instead you're going to have, say, 0.01 BTC in fees by aggregating up two dozen inputs. Since it's reasonable to expect that fees will be higher in the future this is arguably a rational strategy but in the past users have been _very_ spazzy about fees and have been violently angry about them. Do you have any idea how to communicate to people that this strategy is really in their interest?

How do you propose dealing with uncertainty about future reuse? E.g. avoiding the case where you spent all of them but more come?

Not always possible. Where it's not possible ... what strategy do you think it should use?   What if it has a choice between re-linking obvious change with coins sent to a previously used address in a result that produces no change, vs not linking but resulting in more jagged change?

The reference software already does this. I was somewhat unhappy that the coincontrol UI made it possible to achieve other behavior.

The new client has coin control.  So, what do you guys all *WANT* coin control to do? 

Here's my list.

I want my wallet to do these three things as default settings that I never ever have to think about.

1. Always spend *all* the txouts associated with a particular bitcoin address when spending *any* of them -- even if it means adding completely unnecessary txins to a transaction.  This should be the default anyway as it's a good long term strategy for limiting "dust".

2. Make all payments by using the SMALLEST number of bitcoin addresses possible, ideally one.  Better, IMO, to use a thousand-dollar address to buy a tube of toothpaste than to use "dust" from more than one address.   And

3. Always generate a new address for change; never ever allow change from a transaction to be sent back to a txin address.


I would also like these five additional features but they would have to be added to the blockchain rules and possibly the blockchain representation. 

1. Normal addresses, by default, ought to hold value from exactly one transaction.  Any attempts to transfer value into an address from a second or subsequent transaction should either fail, or immediately trigger a transfer of the new txout to a designated charity or whatever.

2. Ability to mark addresses as "Blue" meaning that more than one payment can be accepted at this address. 

3.  "Blue" addresses if implemented should also never EVER be used to make a payment in combination with any other address.   I would rather have my bitcoin client simply tell me it can't make the payment while respecting my privacy rules than have it silently mix coin from a "Blue" address with coin from any other address.

4. Finally, "Blue" addresses would be an exception to the rule about generating new addresses for change; change from a transaction in which coin from a "Blue" address was spent should always go back to the very same "Blue" address. 

5. Ability to mark addresses as "Green" meaning both that it will never accept input from any new tx, and coin held at a "Green" address can never be spent mixed with coin from any other address.  Any change rec'vd from a tx in which a "Green" address was spent should also be held at a (newly generated) "Green" address.  Again, I would rather have my client tell me it can't make a payment while respecting my privacy rules than have it silently mix coin from a "Green" address with any other coin.