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?
2 weeks
Topic: TX Only Valid Until X Block - page 2. (Read 2410 times)
2 weeks
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.
If transactions of blocks removed from trunk and not existent or double spent on the new trunk were resurrected in the memory pool, would then be a loss through expiry during reorg?
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.
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.
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.
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.
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?
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
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?
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?
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.
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.
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
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.
An expiry there is practical but still not guarantee, since anyone recorded the transaction can rebroadcast it again.
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
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.
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.
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
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
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. 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?
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
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.
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.
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?
A transaction that is already on the chain will not become "invalid", such a bullshit can only happen in ..... Mastercoin?
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
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?
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
e.g.:
https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments
Jump to: