Bitcoin Forum
April 03, 2020, 09:54:31 PM *
News: Latest Bitcoin Core release: 0.19.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 »  All
  Print  
Author Topic: TX Only Valid Until X Block  (Read 2388 times)
prophetx
Legendary
*
Offline Offline

Activity: 1610
Merit: 1002


he who has the gold makes the rules


View Profile WWW
March 16, 2014, 04:22:16 PM
 #1

I am curious if there is any discussion that has ever occurred about a time limit parameter during which an unconfirmed tx can stay valid, and after which it is no longer a valid tx?

sort of like an SLA, so that people can have a reasonable expectation of performance, if they need a tx to happen before a certain time, and to be able to then gather statistics on that performance.
1585950871
Hero Member
*
Offline Offline

Posts: 1585950871

View Profile Personal Message (Offline)

Ignore
1585950871
Reply with quote  #2

1585950871
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1585950871
Hero Member
*
Offline Offline

Posts: 1585950871

View Profile Personal Message (Offline)

Ignore
1585950871
Reply with quote  #2

1585950871
Report to moderator
1585950871
Hero Member
*
Offline Offline

Posts: 1585950871

View Profile Personal Message (Offline)

Ignore
1585950871
Reply with quote  #2

1585950871
Report to moderator
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1010


View Profile
March 16, 2014, 04:52:31 PM
 #2

I am curious if there is any discussion that has ever occurred about a time limit parameter during which an unconfirmed tx can stay valid, and after which it is no longer a valid tx?

sort of like an SLA, so that people can have a reasonable expectation of performance, if they need a tx to happen before a certain time, and to be able to then gather statistics on that performance.

No, but we have the opposite, i.e. TX only valid after block X

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
March 16, 2014, 04:53:32 PM
 #3

There were schemes discussed where an offsetting refund transaction with nLockTime in the future invalidates the transaction.
e.g.:

https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments
prophetx
Legendary
*
Offline Offline

Activity: 1610
Merit: 1002


he who has the gold makes the rules


View Profile WWW
March 16, 2014, 09:34:25 PM
 #4

There were schemes discussed where an offsetting refund transaction with nLockTime in the future invalidates the transaction.
e.g.:

https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments

ah interesting, but not exactly useful in this kind of case?  perhaps?


or could one use it like this:

1. send nlocktime tx to send all btc from address1 to address2  at block X

2. send regular tx to send some btc from address1 to address3 when block number is < X

that would me that if block X arrives and then tx 1 should have higher priority then tx 2 because it is older, and therefor tx 2 becomes invalid double spend

assuming their were both broadcast, would there be any common case under which at block X or greater that tx 2 would be confirmed before tx 1?
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
March 16, 2014, 09:58:29 PM
 #5

A transaction can not be included into the block chain before its nLockTime is reached.

A transaction that is already on the chain will not become "invalid", such a bullshit can only happen in ..... Mastercoin?
Foxpup
Legendary
*
Offline Offline

Activity: 2870
Merit: 1948


Vile Vixen


View Profile
March 17, 2014, 03:11:44 AM
 #6

This isn't allowed because a chain reorg could cause the previously confirmed transaction to become unconfirmed, and if it isn't confirmed again before the required block height, it will become permanently invalid. This means a confirmed transaction can become invalid purely by accident, breaking the assumption that confirmed transactions are always valid barring double-spend attacks.

Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4
prophetx
Legendary
*
Offline Offline

Activity: 1610
Merit: 1002


he who has the gold makes the rules


View Profile WWW
March 17, 2014, 09:41:39 AM
 #7

A transaction can not be included into the block chain before its nLockTime is reached.

yes i am aware of that....

A transaction that is already on the chain will not become "invalid", such a bullshit can only happen in ..... Mastercoin?

i am talking about sla's and tx that stay unconfirmed for unusually long periods

i guess your emotions are clouding your rationality.  that is not what I wrote.

read the scenario again with a sober mind please.
prophetx
Legendary
*
Offline Offline

Activity: 1610
Merit: 1002


he who has the gold makes the rules


View Profile WWW
March 17, 2014, 09:46:25 AM
 #8

This isn't allowed because a chain reorg could cause the previously confirmed transaction to become unconfirmed, and if it isn't confirmed again before the required block height, it will become permanently invalid. This means a confirmed transaction can become invalid purely by accident, breaking the assumption that confirmed transactions are always valid barring double-spend attacks.

sorry i don't follow.

what i wrote was if one sends 2 tx: the first with one with nlocktime, and the 2nd as a non-nlocktime tx. if the the 2nd does not occur (i.e., get confirmed) before the nlocktime block happens, can we assume that the nlocktime tx will always get confirmed before the other (i.e., have higher priority) at or after nlocktime block?
Foxpup
Legendary
*
Offline Offline

Activity: 2870
Merit: 1948


Vile Vixen


View Profile
March 17, 2014, 10:29:43 AM
 #9

sorry i don't follow.
I was talking about why Bitcoin doesn't have a transaction type that does what you want.

what i wrote was if one sends 2 tx: the first with one with nlocktime, and the 2nd as a non-nlocktime tx. if the the 2nd does not occur (i.e., get confirmed) before the nlocktime block happens, can we assume that the nlocktime tx will always get confirmed before the other (i.e., have higher priority) at or after nlocktime block?
No. As I understand, locktime transactions aren't even relayed before locktime is reached, and if you try to resend it after locktime, it still won't be relayed because it's a double-spend as long as your intended transaction is in the memory pool. And if the locktime transaction is relayed and is added to the miners' memory pools, all you've succeeded in doing is guaranteeing that your intended transaction will never confirm, because it's a double-spend of the locktime transaction. In either case, the scheme doesn't work at all.

Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1582
Merit: 1006


View Profile
March 17, 2014, 10:58:09 AM
 #10

This is a longstanding problem with bitcoin -- transactions hang out in limbo until confirmed, possibly forever.

And just as longstanding is my proposal to fix it -- expire transactions out of the memory pool after 1-2 days.  Clients are built to resend.  They may choose to not resend at that point.

There is now a pull req that accomplishes this: https://github.com/bitcoin/bitcoin/pull/3753

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

Activity: 1610
Merit: 1002


he who has the gold makes the rules


View Profile WWW
March 18, 2014, 01:12:44 AM
 #11

sorry i don't follow.
I was talking about why Bitcoin doesn't have a transaction type that does what you want.

what i wrote was if one sends 2 tx: the first with one with nlocktime, and the 2nd as a non-nlocktime tx. if the the 2nd does not occur (i.e., get confirmed) before the nlocktime block happens, can we assume that the nlocktime tx will always get confirmed before the other (i.e., have higher priority) at or after nlocktime block?
No. As I understand, locktime transactions aren't even relayed before locktime is reached, and if you try to resend it after locktime, it still won't be relayed because it's a double-spend as long as your intended transaction is in the memory pool. And if the locktime transaction is relayed and is added to the miners' memory pools, all you've succeeded in doing is guaranteeing that your intended transaction will never confirm, because it's a double-spend of the locktime transaction. In either case, the scheme doesn't work at all.

ah ok that was the detail i was missing, i was working under an assumption that the nlocktime tx was relayed and kept in memory at mining nodes (obviously that could cause massive memory problems).

but btw that is what i was trying to accomplish, b/c some people want to cancel out a requested tx (let's call it an order since it is not a tx) if it takes too long.  banks have SLAs and requirements on when money gets delivered.  they don't just hope that Mr. Miner processes his tx. Wink

prophetx
Legendary
*
Offline Offline

Activity: 1610
Merit: 1002


he who has the gold makes the rules


View Profile WWW
March 18, 2014, 01:40:30 AM
 #12

This is a longstanding problem with bitcoin -- transactions hang out in limbo until confirmed, possibly forever.

And just as longstanding is my proposal to fix it -- expire transactions out of the memory pool after 1-2 days.  Clients are built to resend.  They may choose to not resend at that point.

There is now a pull req that accomplishes this: https://github.com/bitcoin/bitcoin/pull/3753


Great, glad someone takes this seriously. 

There has to be some assurance that a tx will get processed in a reasonable amount of time, or just gets thrown out.  Especially when contracts (real or virtual) are concerned this is very important. 

And I think for bank adoption and to have bitcoin start to function as a real reserve currency that is used in treasury mgmt and treated like money stuff like this is going to have to happen.

I guess we'll find out in the next year or two as the banking and finance regulators calm down, and national banks start looking at what is missing for them to make use of this.



grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
March 18, 2014, 07:07:28 AM
 #13

This is a longstanding problem with bitcoin -- transactions hang out in limbo until confirmed, possibly forever.

And just as longstanding is my proposal to fix it -- expire transactions out of the memory pool after 1-2 days.  Clients are built to resend.  They may choose to not resend at that point.

There is now a pull req that accomplishes this: https://github.com/bitcoin/bitcoin/pull/3753


Great, glad someone takes this seriously. 

Sorry, I did not understand your question previously. So were only talking about the memory pool?

An expiry there is practical but still not guarantee, since anyone recorded the transaction can rebroadcast it again.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 3010
Merit: 3408



View Profile
March 18, 2014, 07:48:20 AM
Merited by Foxpup (3)
 #14

An expiry there is practical but still not guarantee, since anyone recorded the transaction can rebroadcast it again.
Outright enforced expiration is not reorganization safe and can cause coins and their history to be suddenly invalidated even in the complete absence of an attacker. This exposure different for coins based on their depth would degrade the fungability of the coins, and avoiding it is one of the reason that generated coins cannot be spent for 100 blocks.

There is, however, some work going on towards allowing single transaction refunds that would allow you to easily spend a coin to an alternative output in order to cancel it after some time has passed.  This addresses some but not all of the use-cases for expiration (as well as many other use cases) without the risks. I should have a proposal on the mailing list in a few days— I'm still hammering out the details of exactly what I'll be proposing with a few other people first.
prophetx
Legendary
*
Offline Offline

Activity: 1610
Merit: 1002


he who has the gold makes the rules


View Profile WWW
March 18, 2014, 09:02:40 AM
 #15

An expiry there is practical but still not guarantee, since anyone recorded the transaction can rebroadcast it again.
Outright enforced expiration is not reorganization safe and can cause coins and their history to be suddenly invalidated even in the complete absence of an attacker. This exposure different for coins based on their depth would degrade the fungability of the coins, and avoiding it is one of the reason that generated coins cannot be spent for 100 blocks.

There is, however, some work going on towards allowing single transaction refunds that would allow you to easily spend a coin to an alternative output in order to cancel it after some time has passed.  This addresses some but not all of the use-cases for expiration (as well as many other use cases) without the risks. I should have a proposal on the mailing list in a few days— I'm still hammering out the details of exactly what I'll be proposing with a few other people first.


that would be cool.

though in any case one would need to wait long enough to ensure that a reorg hasn't occurred.
Cryddit
Legendary
*
Offline Offline

Activity: 924
Merit: 1044


View Profile
March 19, 2014, 02:47:20 AM
 #16

I think I don't understand the reorganization issue.

A hypothetical transaction A has an expiry time.  But it gets into a block before the expiry time, so txouts which may later be spent are created, and txins are destroyed. 

Then there's a reorg.  And in the other chain, A did not get into a block before its expiry time, so it was considered invalid.

I don't see how this is different from the ordinary case of a zero-fee transaction that did make it into the blockchain, but then after a reorg to a chain where it didn't make it into the blockchain, doesn't ever make it into the "free" area and eventually gets evicted from everybody's mempool. 

In either case, we see a revised history in which the transaction (and any other tx that depend on it) simply did not happen.  In either case, a replacement transaction can be broadcast. 

What's the problem in scenario A that isn't a problem in scenario B?
prophetx
Legendary
*
Offline Offline

Activity: 1610
Merit: 1002


he who has the gold makes the rules


View Profile WWW
March 19, 2014, 06:57:21 AM
 #17

I think I don't understand the reorganization issue.

A hypothetical transaction A has an expiry time.  But it gets into a block before the expiry time, so txouts which may later be spent are created, and txins are destroyed.  

Then there's a reorg.  And in the other chain, A did not get into a block before its expiry time, so it was considered invalid.

I don't see how this is different from the ordinary case of a zero-fee transaction that did make it into the blockchain, but then after a reorg to a chain where it didn't make it into the blockchain, doesn't ever make it into the "free" area and eventually gets evicted from everybody's mempool.  

In either case, we see a revised history in which the transaction (and any other tx that depend on it) simply did not happen.  In either case, a replacement transaction can be broadcast.  

What's the problem in scenario A that isn't a problem in scenario B?

take the inverse of your scenario

does not get in, user spends the money again

then there is reorg

does get in, then there is another spend which now may be invalid
Cryddit
Legendary
*
Offline Offline

Activity: 924
Merit: 1044


View Profile
March 19, 2014, 03:39:19 PM
 #18


take the inverse of your scenario

does not get in, user spends the money again

then there is reorg

does get in, then there is another spend which now may be invalid

I still don't see how that's different from the analogous scenario with a zero-fee transaction.  It doesn't get into the blockchain, but stays in the mempool.   The sender makes another transaction using the same coins, so at most one of them will succeed because the second would be a double spend.  Say the second one succeeds.  Then there's a reorg, to a chain where the first one succeeded instead and the second is invalid. 

We have this scenario every day.  I don't see any relevant difference between expiry times and other reasons for tx to fail. 

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 3010
Merit: 3408



View Profile
March 19, 2014, 04:35:03 PM
Merited by Foxpup (1)
 #19

The double spend requires fraudulent (or at least gravely mistaken!) actions on the part of the users. The expiry just happens as a product of chance or due to actions by totally unrelated third parties. We've had some long reorgs during network events in the past which resulted in no losses, expirations would effectively guarantee losses in these cases and in general complicate the security analysis in accepting a transaction because now you not only need to worry about past fraud risk, you need to worry about past expiration exposure.
Cryddit
Legendary
*
Offline Offline

Activity: 924
Merit: 1044


View Profile
March 19, 2014, 05:31:07 PM
 #20

It certainly is not "fraudulent or gravely mistaken" to resend the same txouts with a fee when your zero-fee transaction has been sitting there for three days unconfirmed!  The fee-paid transaction will go through, and the double spend will kill the zero-fee transaction, and that's exactly what you want to do! 

Worrying about whether an expiry-timed transaction made it into both sides of a fork is no different from worrying about whether a double-spent transaction made it into both sides of a fork. 

Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!