Topic: Add option to add a fee to dead transactions (Read 2595 times)

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

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.

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.

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.

Good to know . 


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.

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.

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.

It would make it easier to require an absolute match, since transaction data management is potentially a big overhead for miners.


Currently, the default client doesn't send anything back to the original address.  What was the reason for that?  Was it to create a psuedo mix-net?


I think the idea that it must go back to the same address as the input would fix the issue anyway.  Most of the mixing could be preserved if only a small portion of the money was placed in the "reserve".

However, the hardening of bitcoins is incorporation into the main chain.  Some miners will accept transactions being sent directly to them.

Oh, I know. A Finney Attack would still allow double-spending, but the idea is to not make double-spending as simple as clicking "cancel".

This is just to make it easy for nodes to recognize replacement spends.

Say the first transaction is X+Y in and A+B out, with no fee so that X+Y == A+B.  If it doesn't get picked up quickly enough, the user tried a second one with X+Y in and A+(B-F) out so that F is the fee.

We could also make the rule that the output getting reduced, B, has to have the same address as one of the inputs.  That way we know it is the change getting reduced, and not the spend.  Vendors that don't wait for even a single confirmation could get burned otherwise (but if they don't wait, they are asking to get burned anyway).

I'm not sure if this is a good road to go down or not, but if we do decide that a double spend is acceptable in this circumstance, at least it is recognizable, and somewhat safe.

If a transaction hasn't been added into the chain, then there isn't any reason why it is more important than any other colliding transaction.

The fee would only be used as a tie breaker if 2 transactions had the same number confirms (normally zero except during a fork).

In fact, allowing higher fee transactions override lower fee transactions increases the chances that everyone sees the same one as high priority.


Not sure exactly what you mean here.

We absolutely cannot allow people to cancel unconfirmed transactions. Thus, one additional check can be made that the outputs are going to the same addresses and are greater than or equal to the original amounts. To prevent compromising which txOut is the change, there can also be additional change addresses added. In fact, this creates a nice side effect: It would then be possible to attach new transactions to existing open transactions. Imagine if the Faucet could rebundle their mega-transaction every time someone requested coins!

That's true.  However, there is still the problem that non-fee paying transactions aren't forwarded.  It is easier to check for collisions than to scan all transactions in memory and try to find profitable paths from low fee transactions to the incentive transactions.


That is only needed if transactions are only cancelled by identical ones.

What's interesting to me is that a receiver can add a fee by making a tx that is dependent on the unconfirmed one that has a fee. Any miner who wants it has to include the dependent tx.

I think it would be better if multiple variations of the transaction requests were allowed to coexist in the network, leaving the pruning to be done only when creating blocks (so for example if a philanthropic mining operation sees two variations they can choose to process the one with the cheaper transaction fee); but of course, any copies laying around after one has been included in the blockchain would be terminated on sight.

Should be trivial to recognize and allow a transaction that differs only in the fee (and thus, the change).

It might also be a good idea to alter the spend behavior to include a little change in the input even when not strictly necessary, so that the resend attempt doesn't need to add a new input.

Yes, it's not always possible to use the same outputs as input for the new (overriding) transaction, because adding fees sometimes implies using a different input.

So the question actually is about which transaction wins when two transactions share at least one output from a previous transaction as their input. One of the transaction needs to be dropped as invalid.
AFAIK, 0.3.23 will drop the incoming transcation and keep the old one.

There are more ways to deal with an "output/input" conflict, and some (or all) of them might be entirely stupid. To be honest, I can't really tell the consequences..

* Drop the old transaction, use the new incoming transaction as "valid". This probably allows me to increase fees, decrease fees, and even to "cancel" the transaction (by replacing the output of the transaction to go to my own wallet). Of course, if a miner refuses to drop the old transaction, it might still be included in a block and become valid, even though the user canceled/changed his transaction.
* Drop the transaction with lower fees (or lower fee/kb). This allows to increase fees and might solve the "coins in limbo with 0 confirmations" problem.

The client needs some logic to actually allow changing a transaction by the user. An intentional conflict needs to be created that makes sure the old transaction is considered "invalid" by most miners. (Since we can't control what logic miners use to deem transactions invalid, this can never be 100%..)

You could just decrease the output payment in order to increase the fee.

As long as a transaction hasn't been incorporated into the main chain, it is perfectly acceptable to reverse it.

In the general case, it is impossible to use the same outputs, as you may need more/different inputs to pay the fee, resulting in a different change, implying different outputs. It is not possible to detect which outputs are change, so you can't in general detect whether one transaction would be allowed to replace another one.

+1. The "low/no fee" transaction should of course be dropped by miners when a high fee transactions comes in.

I think this is the most elegant solution to the fee problem.

My understanding is that if the default client forwards the transaction, it will also mine it?

In all likelihood, the original transaction won't make it very far unless it is acceptable to the default client and if it is acceptable to the default client, then all miners should get it.  It only requires one miner to change his code to replace low fee paying transactions with high fee paying ones if there is a collision.

The recommended network rules are given on the wiki.

For transactions:

"9. Reject if any other tx in the pool uses the same transaction output as one used by this tx."

Maybe that could be changed to

"9. Reject if any other tx in the pool uses the same transaction output as one used by this tx, and has a greater or equal transaction fee"

It might also be worth adding the actual default client's rules to the wiki.