Resubmitting transactions with higher fees

[abitcoinuser]

Suppose the number of transactions in the network is great enough that most clients are no longer accepting transactions without fees attached to them.  What happens when a client sends out a transaction with too low of a fee to be processed?  Can the client resubmit the transaction with a higher fee, knowing that other clients will recognize that it is a resubmission and won't mark it as a double spend?

[theymos]

The network forgets about transactions if they haven't made it into a block within a few days. You could resubmit it then.

Bitcoin doesn't currently allow you to "unsend" a transaction, though, so you'd have to restore from a wallet backup to get the "stuck" coins back.

[abitcoinuser]

Consider a scenario where I Alice sends 10 BTC to Bob, but includes a fee so low that no client will accept her transaction.  Although with the official client there may be a limit to how long the transaction lasts in the system, it is possible that a modified client (ie a miner) is holding the transaction for processing.  Alice's money is now in limbo - it is possible that at some point in the future some client could allow it into a block.  If Alice sends 10 BTC more to Bob before this occurs, she could find herself out 10 BTC when the original transaction finally goes through.

Suppose that future bitcoin clients allow for resubmission of the same transaction, but with a different fee.  In the above scenario, Alice, upon realizing that Bob didn't receive her 10 BTC, could resubmit with a higher fee, comfortable with the knowledge that first time her transaction appears in a block (with either the low fee, or the high fee) that any subsequent transactions will be ignored.

Is there value in this?  Is this technically feasible?

[jib]

first time her transaction appears in a block (with either the low fee, or the high fee) that any subsequent transactions will be ignored.

Yes, this is feasible. Alice's client could let her send the same coins again with a higher fee. One of the two transactions will make it into a block and the other one will be ignored as a double spend.

[marcus_of_augustus]

Alice's client could let her send the same coins again with a higher fee.

How does Alice know which coins are the same ones that were sent previously?

Do you mean send the same amount from the same address in her wallet?

[abitcoinuser]

Alice's client could let her send the same coins again with a higher fee.

How does Alice know which coins are the same ones that were sent previously?

Do you mean send the same amount from the same address in her wallet?

Yes, although I think this would require a mechanism outside of the current capabilities of the system. 

Alice's client with the "resend with new fee" feature could attach a unique identifier to each transaction she makes to Bob.  If Alice needs to resend a transaction with a higher fee, she could create a new transaction (with the same amounts, from the same address, to Bob, but with a higher fee) using the unique identifier in the transaction that she is trying to resend.  Other clients would acknowledge the first transaction appearing in a block with this unique identifier, and then disregard any future incoming transactions with the same unique identifier.

[jib]

Do you mean send the same amount from the same address in her wallet?

Not just the same amount. I mean sending a transaction with some of the same inputs, such that the two transactions conflict with each other and only one could be included in the block chain.

This would require the feature to be added to Alice's client, but I don't think it would require changes to the rest of the system. It's already possible to see whether two transactions are using the same coins. No new mechanism or unique identifier is required.

[theymos]

Yes, this is feasible. Alice's client could let her send the same coins again with a higher fee. One of the two transactions will make it into a block and the other one will be ignored as a double spend.

Exactly right. If the two transactions share any inputs, then they will conflict, and both can't exist in the block chain.

Each transaction input has a sequence number associated with it. This is intended for replacement situations like this; a lower sequence number indicates that this transaction should take precedence over other transactions with a higher sequence number. However, miners currently don't respect sequence numbers, so you must rely on the network's forgetfulness.

[Mike Hearn]

Yes, the code that allows for transaction replacement is disabled. Unfortunately the comment there just notes that it's disabled "for now", not why it was disabled in the first place.

[theymos]

Yes, the code that allows for transaction replacement is disabled. Unfortunately the comment there just notes that it's disabled "for now", not why it was disabled in the first place.

I'm guessing it's disabled because it would make accepting 0-confirmation transactions much less safe than it is now. If there was some flag that allowed replacement (maybe nLockTime>0), merchants could ignore such totally unsafe transactions until they get in a block.

[ArtForz]

I'm guessing it's disabled because it would make accepting 0-confirmation transactions much less safe than it is now. If there was some flag that allowed replacement (maybe nLockTime>0), merchants could ignore such totally unsafe transactions until they get in a block.

I think that could be fixed by only allowing replacing a transaction with one where inputs and outputs are a strict superset of the original.
So you could replace [some set of inputs] -> 80 to A, 20 to B with [some set of inputs + some more inputs] -> 80 to A, 20 to B, 9 to X, 1 fee.
Unless I'm missing something, that shouldn't make trusting 0-unconf transactions any more risky than it currently is.

[Mike Hearn]

Sounds reasonable although would that defeat the point of having the feature at all?

I think the nLockTime feature was built on the assumption that you don't trust 0 confirmation transactions at all.

[theymos]

I think that could be fixed by only allowing replacing a transaction with one where inputs and outputs are a strict superset of the original.
So you could replace [some set of inputs] -> 80 to A, 20 to B with [some set of inputs + some more inputs] -> 80 to A, 20 to B, 9 to X, 1 fee.
Unless I'm missing something, that shouldn't make trusting 0-unconf transactions any more risky than it currently is.

The new outputs might trigger a "dust spam" fee or otherwise make the transaction unacceptable for most miners. Right now the client can detect all of these cases, but in the future it might not know all the various miner rules.

It also reduces the functionality of replacement. Transaction locking still couldn't be used for escrow, for example.

[pla]

theymos : The network forgets about transactions if they haven't made it into a block within a few days. You could resubmit it then.  Bitcoin doesn't currently allow you to "unsend" a transaction, though, so you'd have to restore from a wallet backup to get the "stuck" coins back.

And if you don't have a backup (or only one over 100PKs ago, so you would lose other coins as a result)?

Call me crazy, but does anyone else see it as a problem that the BTC economy can and will "lose" coins over time?  From casual experimenters getting bored and abandoning their wallets, to exhausting the PKs in your wallet and then restoring from a backup, to this point you just brought up.

I don't have a problem with a fundamentally deflationary currency, but it seems like we should address this sooner rather than later - Something like revocation lists for "sufficiently idle" coins (which, as a bonus side-effect, would discourage hoarders - If you don't use it within say a decade, you lose it).

Consider, for example, the current influx of Slashdotters to the community (of which I count as one - Hey, gotta learn about everything from somewhere  ).  By all accounts, we've basically doubled the generating capacity of the network in the past week; Of the new users who have received coins (even if just from the "spigot"), how many will get bored within a year, effectively removing their assets from the economy forever?

[jgarzik]

Call me crazy, but does anyone else see it as a problem that the BTC economy can and will "lose" coins over time?

Been covered exhaustively in these forums; search around for hoarding and lost-coin subjects.

[theymos]

And if you don't have a backup (or only one over 100PKs ago, so you would lose other coins as a result)?

You'd have to remove the transaction from wallet.dat somehow. If you know the wallet format in detail, you could remove it with a hex editor. Otherwise, it's probably not too difficult to modify Bitcoin to do it.

[pla]

Been covered exhaustively in these forums; search around for hoarding and lost-coin subjects.

I see that the forums have covered the lost coin issue in general - Basically, it doesn't matter how many outright abandoned bitcoins we have - But the specific post to which I responded brings up an entirely different problem.

Consider a real-world analogy... I buy a newspaper for one dollar; To accomplish this, I tip the paperboy a nickel (a 5% "transaction fee") for the service.

He, however, wants a 10% tip, and rejects the transaction.

In the real world, the transaction doesn't happen and I still have my $1.05.  If I understand correctly, in the BTC world, the publisher doesn't gain anything, the paperboy doesn't gain anything, I don't gain anything, but I still lose my dollar?

I don't think we can just hand-wave that away as "not a problem" by talking about backups.

[caveden]

If block-space becomes so scarce that miners start rejecting paying-transactions like in your example, I bet people will quickly re-enable this resending feature.
Currently, there's enough space on blocks for all transactions to be free.

[ribuck]

I don't gain anything, but I still lose my dollar?

No, if your transaction doesn't make it into the block chain, then that dollar is still yours to spend.