Add option to add a fee to dead transactions

[TierNolan]

Ahh.  The reason is probably because reusing keys is a bad idea, in general.  Many cryptosystems have are weak when an attacker is able to collect many cyphertexts all using the same key.  I don't know how much of a problem it is when using ECDSA, but all the textbooks since WWII have said not to do it unnecessarily.

Good to know . 

The client could reduce this problem by keeping track of the addresses getting change, and chaining them into the following spend on the changeless side.

In this X+Y==A+(B-F) example, B is the change.  The next transaction the client does would be B+Z==C+D, or C+(D-F).  Then the next would be D+W, and so on.

Ideally, there would be some kind of incentive to reduce the total number of active transactions.  The recommended fee could be lower for transactions that combined lots of low value coins into high value coins.

Minimum fees based on the size of the transaction already mean that tiny coins have less value than larger coins.

[kjj]

Ideally, there would be some kind of incentive to reduce the total number of active transactions.  The recommended fee could be lower for transactions that combined lots of low value coins into high value coins.

Minimum fees based on the size of the transaction already mean that tiny coins have less value than larger coins.

Right now the default client enforces some limits on transaction fees, mostly to stop transaction spam.  Over time, those will go away, and each network node and miner will be able to set their own rules for accepting and relaying transactions, which means that there will be a market of sorts for fees.

But, when there are a lot of transactions to process, the miners will evaluate them in the terms that make sense to them.  That mostly means that they will want a high ratio of fee to work.  Each input to a transaction involves a certain amount of work, so there is no possible way to provide incentives to miners for consolidation transactions.

So, while consolidation may be useful to other parts of the network, it will not be prioritized by the group capable of making it actually happen.

[Insti]

Why isn't a dependent transaction which pays a fee all that is needed? This requires no dropping of existing transactions.

1. A+B -> C + D
2. D+E -> F + (G - Fee)

In this case the Fee pays for both transaction 1 and transaction 2.
The only problem seems to be if you make a transaction with zero change and then want to add an additional fee. But that is up to the choice of the sender anyway.

[TierNolan]

Why isn't a dependent transaction which pays a fee all that is needed? This requires no dropping of existing transactions.

1. A+B -> C + D
2. D+E -> F + (G - Fee)

In this case the Fee pays for both transaction 1 and transaction 2.

A zero fee transaction won't propagate and neither will one that collides with another transaction.  If you have a rule that higher transaction fee transactions that have all the same inputs and outputs replace the older transaction, then it doesn't matter if the node has seen the earlier transaction or not, it will propagate.

[TierNolan]

Ahh.  The reason is probably because reusing keys is a bad idea, in general.  Many cryptosystems have are weak when an attacker is able to collect many cyphertexts all using the same key.  I don't know how much of a problem it is when using ECDSA, but all the textbooks since WWII have said not to do it unnecessarily.

Good to know . 

Does this mean that you shouldn't ask people to send money to an address once you have sent money from the address?