Bitcoin Forum
March 29, 2024, 03:21:50 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Resubmitting transactions with higher fees  (Read 4069 times)
abitcoinuser (OP)
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
February 13, 2011, 12:09:51 AM
 #1

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?
1711725710
Hero Member
*
Offline Offline

Posts: 1711725710

View Profile Personal Message (Offline)

Ignore
1711725710
Reply with quote  #2

1711725710
Report to moderator
"If you don't want people to know you're a scumbag then don't be a scumbag." -- margaritahuyan
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711725710
Hero Member
*
Offline Offline

Posts: 1711725710

View Profile Personal Message (Offline)

Ignore
1711725710
Reply with quote  #2

1711725710
Report to moderator
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5152
Merit: 12580


View Profile
February 13, 2011, 12:13:34 AM
 #2

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
abitcoinuser (OP)
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
February 13, 2011, 12:25:33 AM
 #3

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
Member
**
Offline Offline

Activity: 92
Merit: 10


View Profile
February 13, 2011, 12:33:20 AM
 #4

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
Legendary
*
Offline Offline

Activity: 3920
Merit: 2347


Eadem mutata resurgo


View Profile
February 13, 2011, 12:45:46 AM
 #5

Quote
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 (OP)
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
February 13, 2011, 12:54:40 AM
 #6

Quote
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
Member
**
Offline Offline

Activity: 92
Merit: 10


View Profile
February 13, 2011, 01:07:47 AM
 #7

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
Administrator
Legendary
*
Offline Offline

Activity: 5152
Merit: 12580


View Profile
February 13, 2011, 01:10:49 AM
Last edit: February 13, 2011, 01:23:48 AM by theymos
 #8

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1128


View Profile
February 14, 2011, 12:52:41 PM
 #9

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
Administrator
Legendary
*
Offline Offline

Activity: 5152
Merit: 12580


View Profile
February 14, 2011, 10:16:13 PM
 #10

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ArtForz
Sr. Member
****
Offline Offline

Activity: 406
Merit: 257


View Profile
February 15, 2011, 10:53:01 AM
 #11

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.

bitcoin: 1Fb77Xq5ePFER8GtKRn2KDbDTVpJKfKmpz
i0coin: jNdvyvd6v6gV3kVJLD7HsB5ZwHyHwAkfdw
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1128


View Profile
February 15, 2011, 12:23:29 PM
 #12

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
Administrator
Legendary
*
Offline Offline

Activity: 5152
Merit: 12580


View Profile
February 15, 2011, 10:18:11 PM
 #13

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
pla
Member
**
Offline Offline

Activity: 65
Merit: 10


View Profile
February 17, 2011, 07:17:36 PM
 #14

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  Wink ).  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?

I don't beg - If I do something to deserve your BTC, you can find my address on the invoice.  Wink
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1596
Merit: 1091


View Profile
February 17, 2011, 07:20:15 PM
 #15

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.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5152
Merit: 12580


View Profile
February 17, 2011, 07:39:19 PM
 #16

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
pla
Member
**
Offline Offline

Activity: 65
Merit: 10


View Profile
February 17, 2011, 08:32:43 PM
 #17

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.

I don't beg - If I do something to deserve your BTC, you can find my address on the invoice.  Wink
caveden
Legendary
*
Offline Offline

Activity: 1106
Merit: 1004



View Profile
February 17, 2011, 08:47:54 PM
 #18

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
Donator
Hero Member
*
Offline Offline

Activity: 826
Merit: 1039


View Profile
February 17, 2011, 09:32:50 PM
 #19

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.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!