Topic: TX Only Valid Until X Block (Read 2410 times)

 Why would you ask something you could google. Are you an idiot?

The accounting world will have to adapt to bitcoin.  They will not be dragging their current fiat notions into bitcoin intact.

For some strange reason, plenty of people on this forum think that the rules of accounting were handed down to Moses on Sinai and have been passed down from father to son unchanged since then.  This is, of course, nonsense.  Accounting changes all the time.

Bitcoin does what it can.  The block timestamp is the only time with any meaning for bitcoin.  If that isn't good enough for the accounting industry, they will just have to come up with something else that does.

Same goes for everyone else, pretty much.  I'm reasonably sure that the "commerce community" "needs" the "capability" to reverse transactions.  Ain't gonna happen, so they'd better get over it sooner rather than later.

P.S.  I can think of several ways to address your specific example that don't involve wishful thinking.  1)  Don't wait until the last fucking minute.  2) Accept a receipt from an audited timestamping service as the effective time.  3) Accept the timestamp of an orphaned, but otherwise valid, block as the effective time.  4) Pay more fees.

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.

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. 

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

2 weeks

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. 

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.

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. 

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?

that would be cool.

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

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.

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.

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.

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

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

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.

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?

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?

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

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

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.