TX Only Valid Until X Block

[grau]

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?

[HorseCoin]

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

[kjj]

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?

Because if the transaction stops being valid after block X, and X is in the middle of the reorg, then it can no longer be placed in a block.

[Cryddit]

Because if the transaction stops being valid after block X, and X is in the middle of the reorg, then it can no longer be placed in a block.

And this is different from any other tx that can no longer be placed in a block after a reorg? 

The crucial consistency property is not violated here.  You never have a transaction getting into a block which later becomes an invalid transaction.  What you're thinking about here is just switching to an alternate view of history where it *never* got into a block, and *isn't* a valid transaction.  That's a reorg, not an inconsistency in either branch.

[gmaxwell]

The crucial consistency property is not violated here.  You never have a transaction getting into a block which later becomes an invalid transaction.  What you're thinking about here is just switching to an alternate view of history where it *never* got into a block, and *isn't* a valid transaction.  That's a reorg, not an inconsistency in either branch.

Only if you're Tron and living inside the ENCOM blockchain. The rest of us users actually witness the reorg and may have potentially taken irreversible actions based on the prior state.

[Cryddit]

Only if you're Tron and living inside the ENCOM blockchain. The rest of us users actually witness the reorg and may have potentially taken irreversible actions based on the prior state.

There's still no difference between this and any other transaction that can't get into the reorganized blockchain.  The reorganized blockchain presents a revised view of history, not an internally inconsistent one.  One side or the other of a double spend but not both.  A transaction with expiry time, or not. 

If a reorg happens after you ship someone something they bought using double spent txouts that disappear in the reorg, that's exactly the same problem.  And it doesn't make the system break down, it just makes it prudent to wait for confirmation before shipping.

[grau]

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?

Because if the transaction stops being valid after block X, and X is in the middle of the reorg, then it can no longer be placed in a block.

I see, that is however a "legitimate" loss since there is nothing higher priority than the longest chain. A transaction in the mempool has to be forgotten if it is double spend according to the longest chain.

[gmaxwell]

If a reorg happens after you ship someone something they bought using double spent txouts that disappear in the reorg, that's exactly the same problem.  And it doesn't make the system break down, it just makes it prudent to wait for confirmation before shipping.

It isn't the same thing at all, as it can cause irrecoverable loss even completely absent any misconduct on any party (and, in particular, any party involved in the transaction). It changes the loss criteria from if and only if there is a reorg and a conflicting spend and the conflicting spend wins in the reorg, to just if and only if there is a reorg.

[Foxpup]

If a reorg happens after you ship someone something they bought using double spent txouts that disappear in the reorg, that's exactly the same problem.

No it isn't. A double-spend requires deliberate fraud or gross negligence on the part of the sender. The disappearing payment is entirely their fault, they're liable for it, and they can be sued and/or prosecuted if they don't make good on their payment. Allowing previously confirmed transactions to become invalid by an accidental glitch in the network with nobody to blame is entirely unacceptable in a payment system.

And it doesn't make the system break down, it just makes it prudent to wait for confirmation before shipping.

Methinks you don't understand what a reorg is. Confirmation means nothing in the event of a reorg. Some confirmed transactions will become unconfirmed in a reorg, by definition. But, and this is crucial to the integrity of the payment system, such unconfirmed transactions will be re-confirmed on the new branch, and cannot be made invalid barring a double-spend attack. If confirmed transactions can become invalid without a double-spend attack, what's the point of confirmations at all?

[grau]

It changes the loss criteria from if and only if there is a reorg and a conflicting spend and the conflicting spend wins in the reorg, to just if and only if there is a reorg.

I still d not get it. If reorg resurrects transactions into the mempool that are not on new trunk, what could be forgotten? There could be no conflict with any tx on mempool since they were on the previous trunk that was not in conflict with the mempool.

[gmaxwell]

I still d not get it. If reorg resurrects transactions into the mempool that are not on new trunk, what could be forgotten? There could be no conflict with any tx on mempool since they were on the previous trunk that was not in conflict with the mempool.

The question being asked here is why Bitcoin has no equivalent of an nlocktime which prevents a transaction from being confirmed after a particular time (instead of just the before direction), after a reorg such transactions may be unresurrectable even though there is no conflict, because the time has passed, because their wasn't enough room in the boundary block, etc.

[grau]

I still d not get it. If reorg resurrects transactions into the mempool that are not on new trunk, what could be forgotten? There could be no conflict with any tx on mempool since they were on the previous trunk that was not in conflict with the mempool.

The question being asked here is why Bitcoin has no equivalent of an nlocktime which prevents a transaction from being confirmed after a particular time (instead of just the before direction), after a reorg such transactions may be unresurrectable even though there is no conflict, because the time has passed, because their wasn't enough room in the boundary block, etc.

Thanks, now I agree. Resurrection of transactions from blocks just being removed from trunk has to be unconditional. I was thinking of a timeout on the mempool, so that it allows replacement, not an explicit constant expiry of a transaction.

Added: that time to live should start new for resurrected transactions entering the mempool.

[Cryddit]

Well, there is a business use case for knowing that if a transaction has not happened by X time, then it definitely will not happen.  A "drop dead date" is absolutely crucial for some contracts.  

And of course, you know how that's implemented today?  It's implemented with a double spend.  If you want to be sure that a transaction  will not go through, you double-spend one of its inputs on something else, thereby guaranteeing that it will not go through. 

This is common in exchange protocols for example.  Usually the counterparty has a time-locked transaction that can get into the blockchain after a certain time; you have up until that time to stop the tx from going through if that counterparty does not perform, and the way you do that is to double spend one of the inputs so that the held tx is invalid.  This does not mean you have committed fraud; it simply means you have retained your money when the counterparty failed to perform. 

The vast majority of reorgs are <6 blocks, which is why confirmation works in the usual case.  Even if the transaction becomes unconfirmed (goes from 7 blocks deep to 2 blocks deep) it's still in the chain and rapidly becomes confirmed again.  Longer reorgs can drop confirmed transactions completely, but when that happens you either resubmit the transaction, or if you can't then you needed a longer confirmation time.

If you wanna be extra sure, the way we want to be extra-sure about coinbase transactions, then tx with an expiry time should take as long to confirm as coinbase transactions.  

But, I don't think of double spends as necessarily fraudulent.  double spends are the "refund if it doesn't work out" transaction in most exchange protocols.  You get your 'stuck' zero-fee transaction out of limbo by killing it with a double spend that replaces it with a fee-paid transaction.  Double spends are the failsafe options that prevent escrows from keeping your money.  And so on.  

Rejecting double spends is a fraud-prevention mechanism in both the negative sense (double spends are "fraudulent or misguided") and the positive sense (we use double spends deliberately to prevent fraudsters from keeping our money).  

So I simply don't buy the idea that an expiry time (equally useful for preventing fraud) is somehow worse than a double spend.

[gmaxwell]

Well, there is a business use case for knowing that if a transaction has not happened by X time, then it definitely will not happen.  A "drop dead date" is absolutely crucial for some contracts.  

Sure, and you can have that— conflict it with an alternative spend and then it cannot happen.

[Cryddit]

Well, there is a business use case for knowing that if a transaction has not happened by X time, then it definitely will not happen.  A "drop dead date" is absolutely crucial for some contracts.  

Sure, and you can have that— conflict it with an alternative spend and then it cannot happen.

That was kinda the point.  Transactions becoming invalid due to double spends does not indicate fraudulent or gravely mistaken -- it just indicates a protocol move.  Transactions becoming invalid due to timeout are no more nor less than the same kind of protocol move. 

If anything, it would make it more defensible to consider double spends to be fraudulent or gravely mistaken because it would give people another, cleaner, more reliable option to accomplish the same kind of move in most cases.

The advantage is that it would eliminate an attack on protocol.  With cancellation via double spend somebody can try to prevent cancellation by forcing the potential canceller offline (via a DDoS if they're technical, or via lineman's pliers if they're old-school)  until the transaction he might need to cancel becomes valid and confirms.  If you can build an expiry time into the transaction in the first place, you don't get to confirm that transaction after the time, whether or not you can keep the other protocol participant offline.

[kjj]

Well, there is a business use case for knowing that if a transaction has not happened by X time, then it definitely will not happen.  A "drop dead date" is absolutely crucial for some contracts.  

Sure, and you can have that— conflict it with an alternative spend and then it cannot happen.

That was kinda the point.  Transactions becoming invalid due to double spends does not indicate fraudulent or gravely mistaken -- it just indicates a protocol move.  Transactions becoming invalid due to timeout are no more nor less than the same kind of protocol move. 

If anything, it would make it more defensible to consider double spends to be fraudulent or gravely mistaken because it would give people another, cleaner, more reliable option to accomplish the same kind of move in most cases.

The advantage is that it would eliminate an attack on protocol.  With cancellation via double spend somebody can try to prevent cancellation by forcing the potential canceller offline (via a DDoS if they're technical, or via lineman's pliers if they're old-school)  until the transaction he might need to cancel becomes valid and confirms.  If you can build an expiry time into the transaction in the first place, you don't get to confirm that transaction after the time, whether or not you can keep the other protocol participant offline.

I don't normally consider contracts expiring when their agreed-upon expiration dates hit to be fraudulent.  Why would I start now just because some software is mediating the event?

At any rate, the question is not "Could this feature be useful in some unusual situation some day?".  It is rather "Is this feature, upon consideration of many scenarios, expected to be a net gain for the system?".  In this case, the answer looks like a pretty clear no.  It would be misused and abused in ways that will cause mayhem, probably a thousand times for every time it is used properly and intentionally.

Right now, you can convince yourself of the safety of your transactions by taking simple steps like making sure that you are connected to the bulk of the network, making sure your received payment has a number of confirmations sufficient for your risk tolerance, and making sure that no competing transactions are visible.  Having expiration heights degrades that safety by a factor that is difficult to estimate.

P.S.  Your DOS scenario is the stuff of movie plots.

[Brangdon]

This is common in exchange protocols for example.  Usually the counterparty has a time-locked transaction that can get into the blockchain after a certain time; you have up until that time to stop the tx from going through if that counterparty does not perform, and the way you do that is to double spend one of the inputs so that the held tx is invalid.  This does not mean you have committed fraud; it simply means you have retained your money when the counterparty failed to perform. 

It's not a double-spend unless the network sees both transactions. In those scenarios, the network only needs to see one of them. There is no need for the counter-party to publish their time-locked transaction before the lock has expired, and if you have spent one of its inputs before then, there's no point in them publishing it ever.

As a newbie, publishing a time-locked transaction before the lock has expired seems like bad practice to me. It's surely unreliable; and at best selfish and at worst a potential denial of service attack. Suppose the transaction is locked for six months. Why should the network remember your transaction for you for such a long time? It'd be more reliable to remember it yourself and then broadcast it when the network can accept it, when the lock has expired. The same argument applies to shorter periods.

My take-away from discussion in this thread is that broadcasting time-locked transactions early, in the situations you describe, is also morally wrong and dangerous. Whether a party gets paid should depend only on whether they fulfilled the real-world contract. It should not depend on transaction races or on block-chain re-organisations.

So I am agreeing with you that transactions with expiry times are similar to various kinds of double-spends, but my conclusion is not that expiry times are OK, but that those double-spends are not OK.

You get your 'stuck' zero-fee transaction out of limbo by killing it with a double spend that replaces it with a fee-paid transaction.

When the new transaction is the same as the old one but with a higher fee, the race condition is benign. The receiver doesn't care which transaction wins, because they get paid either way. A block-chain re-organisation is harmless to them. So that's fine.

The double-spends that are bad are the ones where different receivers get paid. Who gets paid should not depend on race conditions in the block-chain. It shouldn't depend on luck. That's always bad.

[prophetx]

Well, there is a business use case for knowing that if a transaction has not happened by X time, then it definitely will not happen.  A "drop dead date" is absolutely crucial for some contracts.  

Sure, and you can have that— conflict it with an alternative spend and then it cannot happen.

That was kinda the point.  Transactions becoming invalid due to double spends does not indicate fraudulent or gravely mistaken -- it just indicates a protocol move.  Transactions becoming invalid due to timeout are no more nor less than the same kind of protocol move.  

If anything, it would make it more defensible to consider double spends to be fraudulent or gravely mistaken because it would give people another, cleaner, more reliable option to accomplish the same kind of move in most cases.

The advantage is that it would eliminate an attack on protocol.  With cancellation via double spend somebody can try to prevent cancellation by forcing the potential canceller offline (via a DDoS if they're technical, or via lineman's pliers if they're old-school)  until the transaction he might need to cancel becomes valid and confirms.  If you can build an expiry time into the transaction in the first place, you don't get to confirm that transaction after the time, whether or not you can keep the other protocol participant offline.

I don't normally consider contracts expiring when their agreed-upon expiration dates hit to be fraudulent.  Why would I start now just because some software is mediating the event?

At any rate, the question is not "Could this feature be useful in some unusual situation some day?".  It is rather "Is this feature, upon consideration of many scenarios, expected to be a net gain for the system?".  In this case, the answer looks like a pretty clear no.  It would be misused and abused in ways that will cause mayhem, probably a thousand times for every time it is used properly and intentionally.

Right now, you can convince yourself of the safety of your transactions by taking simple steps like making sure that you are connected to the bulk of the network, making sure your received payment has a number of confirmations sufficient for your risk tolerance, and making sure that no competing transactions are visible.  Having expiration heights degrades that safety by a factor that is difficult to estimate.

P.S.  Your DOS scenario is the stuff of movie plots.

A pretty clear no to who?  The  0.03% of world population who uses this technology?

I don't quiet understand the many scenarios in which this could be abused; does someone want to enumerate a couple of these?  Other than having to wait several confirms to ensure that there is no re-org, which you ought to do anyway, what's the issue?

From an accounting standpoint and contractual obligation standpoint this is a big issue.  Also from an SLA perspective.

If delivery of an asset, in this case bitcoins, needs to occur by a certain time or it causes a cascade of counterparty risks no large institution would take the risk of using bitcoins as a currency.  And we want this to be a currency right?  

I suppose at $580 a pop and a <$10B valuation using bitcoin as a reserve currency or for corporate treasury is a bit of a joke to sovereign bankers and corporate treasury managers, but if you all want to see this system being using for real serious business and sovereign transactions these kind of capabilities need to be written into the protocol.  

It is probably not critical now, but if we all want this to be taken seriously it is critical to achieving that.

[Cryddit]

I think there needs to be some cryptocurrency development specifically to address business concerns. 

Bitcoin is digital cash.  That's fine, but businesses don't actually use cash very much.  They accept cash as payments, sure, but when they turn around and pay someone it's always a check or an EFT or a payment authorization or a money order or something. 

And there's a reason why businesses use these forms.  They use them because they limit risk due to theft, because they limit risk due to embezzlement (which is also theft but has a different risk profile), because they involve counterparties who can revoke payments if the payee fails to perform, because they leave a paper trail specifically so that it is possible to know exactly  who is being paid in terms of real-world identity, because they leave a paper trail specifically so that they can later prove that the payment was made and when and who authorized it, and for many other reasons -- many of which are the same reasons why the crypto-anarchist contingent want to NOT use those means of payment.

The crypto-anarchists and the businesspeople agree one hundred percent on keeping down payment processing costs.  Cheap is good; free is better.  Businesses now are using these other payment forms rather than cash even though they increase bottom-line costs in the normal case, and that indicates that these additional services have substantial value to them. 

I think that if we want to provide that value -- if we want to "get traction" as something that businesses will actually use -- then we have to build these capabilities into the blockchain.   

An issue like this sort of illustrates the divide.  Technicians can be satisfied with the "just issue a double spend to invalidate the pending payment" solution, because there's a reasonable way to get the effect - but if you're going to be using it for business purposes, you want it in a more solid nailed-down format; one where everybody knows exactly what the rules about this tx are and nobody has to take any final step to get it to (not) happen after the deadline. 

[prophetx]

I think there needs to be some cryptocurrency development specifically to address business concerns.  

Bitcoin is digital cash.  That's fine, but businesses don't actually use cash very much.  They accept cash as payments, sure, but when they turn around and pay someone it's always a check or an EFT or a payment authorization or a money order or something.  

And there's a reason why businesses use these forms.  They use them because they limit risk due to theft, because they limit risk due to embezzlement (which is also theft but has a different risk profile), because they involve counterparties who can revoke payments if the payee fails to perform, because they leave a paper trail specifically so that it is possible to know exactly  who is being paid in terms of real-world identity, because they leave a paper trail specifically so that they can later prove that the payment was made and when and who authorized it, and for many other reasons -- many of which are the same reasons why the crypto-anarchist contingent want to NOT use those means of payment.

The crypto-anarchists and the businesspeople agree one hundred percent on keeping down payment processing costs.  Cheap is good; free is better.  Businesses now are using these other payment forms rather than cash even though they increase bottom-line costs in the normal case, and that indicates that these additional services have substantial value to them.  

I think that if we want to provide that value -- if we want to "get traction" as something that businesses will actually use -- then we have to build these capabilities into the blockchain.  

An issue like this sort of illustrates the divide.  Technicians can be satisfied with the "just issue a double spend to invalidate the pending payment" solution, because there's a reasonable way to get the effect - but if you're going to be using it for business purposes, you want it in a more solid nailed-down format; one where everybody knows exactly what the rules about this tx are and nobody has to take any final step to get it to (not) happen after the deadline.  

yes i agree.  just to clarify my position, what i was describing was a hack, since bitcoin organizationally currently seems to lack any real good, clear mechanism for collecting capability needs information from the commerce community, digesting it, and coming out with solutions that make sense.  

the fact that transactions can be backed out in a reorg or re-positioned in time alone would drive accountants crazy.  

"oh woops reorg now the money came in on Wednesday morning not Tuesday night..."

try to explain that to a revenue recognition auditor...  

in the real business world, some discounts disappear at midnight at the end of a fiscal year, and if that company does not have the contract and/or payment on the books it doesn't count.  hence there needs to be something that stops transactions from floating around unconfirmed for days, or longer.