Just a note here but I think that basing fees on tx size, while technically accurate, is too opaque for mainstream users.   Fees IMO ought to be based on some measure that they can easily see and understand knowing no more than the amounts they're transferring, the same way sales taxes are in most jurisdictions.

If the tx fees were to be an ultra-simple 0.1% of the transaction, rounded to a MicroCoin,  I think we'd get a lot less confusion and mistakes, and miners would get about the same amount in fees. 

'Cos here, the "low fees" obstruction was based on tx size divided by 1000 and the fee estimation was based on tx size divided by 1024 - But Joe and Jane end-user have no idea what a tx size is if it isn't the amount of money they're transferring in the first place.

Okay, I'm not fully "up" on the ins & outs of mining.

But for what reasons do miners choose which transactions to include and exclude when they form a block? 

Why wouldn't they take these transaction fees?

I'm here (invested in Bitcoin) because I believe that it's a Better Solution to transferring money via the Internet.  And if it's failing to be a Better Solution I want to understand why, and what is necessary to fix it.

With more and more mentions in the news, Bitcoin is headed for a sort of "general awareness" as an option that it hasn't achieved now.  But when it gets that sort of "general awareness" we don't want people experiencing service failures as their first interaction with it, because if that happens they'll drop it like a rock. This is one of the biggest reasons I'm concerned about mining and scalability; those are where we have the biggest vulnerabilities to failure. 

If the miners are picking transactions to not process, or if the blockchain cannot handle it when one day we get slashdotted and it's hit with massive volume, then we have a fundamental problem that will prevent Bitcoin from achieving a critical mass of public acceptance and becoming what it could otherwise become -- a universal, easy, reliable, cheap way to transfer money via the Internet. 

So, when something like this happens and the system isn't even terribly stressed, I am more than a little concerned.  If we want public acceptance, we must have public trust.  If we want public trust, then service failure is not an option. 

See, I think this is nuts.  I mean, it's a pretty severe problem when a transaction can be out there for hours without getting into a block, especially with an appropriate tx fee paid.

Ten or twenty minutes is acceptable.  Thirty ought to be something that's very rare. 

But this is looking more and more like a service failure -- something about the P2P protocol that needs to be fixed. 

We keep talking about "bitcoin is the future" - but the future has better service than this. 

This has two inputs -- one of which results from several hundred transactions (So, cashing it out is going to take some space in the blockchain) and the other of which has a confirmed but fairly recent transaction (so it may be delayed a little while things that the transaction processors are more sure of go first). 

Did you include a tx processing fee, or is this thing queueing up for the very limited space in a block's free area? 

So let me see if I get this right.  We suppose that Bob wants to connect to Alice's server.

Alice picks a nonce N0, adds Bob and Alice's Server IDs to it, 
   hashes it, and communicates the hash H0 to Bob. 
Bob picks a nonce N1, adds Alice and Bob's Server IDs to it, 
   hashes it, and communicates the hash  H1 to Alice.

Alice reveals her nonce, so Bob can verify that the constructed 
    value is the preimage to the hash H0.
Bob reveals his nonce, so Alice can verify that the constructed 
    value is the preimage to the hash H1.

Now both of them can calculate N = N0 ^ N1. 

Alice picks an address A (say) 32 bits long, then performs the following: 

    initialize V (a hash-wide value) with N
    for each bit B in A
        V = hash (V,B);

and asks Bob, "What is the address of Vfinal?"

And now Bob must exhaustively compute (or have stored) the 
hash tree in order to find the address.  

My immediate thought is that the burden on Bob is asymmetric, but not by as much as you think.  

If I am Bob, I will set up a Bloom Filter Tree.  Bob needs to exhaustively compute the hash tree once in order to initialize the filters, but can then use a set of filters much smaller than the whole tree to efficiently narrow the address search.  He can spend less than one percent of the memory you thought you were requiring and still find the address with less than ten thousand hashes.

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.

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. 

So, it's that time of year again.  What do you do?

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.

I think that these nodes are listening to see where transactions originate.  As long as, by listening, they can see where transactions originate, they will continue to listen. The only way to get rid of them is to deprive them of the ability to obtain the information they seek.  They are worth getting rid of because they fail to follow protocol in propagation of tx and block information.  If this defection from protocol becomes widespread it constitutes a DoS attack, wherein nodes are cut off from the network by having their connections clogged with these useless fake clients. 

Obtaining the information they seek relies on the fact that the current client propagates transactions to all connected nodes, including them.   

The only way to get rid of them, therefore, is to quit doing that.  Instead, propagate a new transaction to one, two, or three nodes, regardless of how many are connected.  Propagate a received transaction to nine or ten nodes, regardless of how many are connected. 

That will make it very difficult for these eavesdroppers to tell where new transactions originate.  And hopefully it will deprive their owners of the motivation to continue to keep up this attack.