Poor man's/de facto transaction replacement

[blueadept]

As of 0.8, the IsStandard check looks to see if a transaction is finalized. If I'm correct in my understanding, this means that 0.8 nodes won't accept into their memory pools or relay non final transactions. This would be a very similar effect to having transaction replacement enabled on the network when 0.8 and later clients make up the majority of the network.

When this happens, contracts like two party escrow and rapidly adjusted micropayment channels can use non final transactions to prevent permanent loss of bitcoins, and dominant assurance contract vendors won't need to worry about funders broadcasting their non final transactions early so they hang out in memory pools and block the final, successful transaction from propagating.

I'm working on a description of a peer-to-peer instant transaction clearing network based on others' previously explained concepts with chained two-step commit and routing/reputation information stored in the blockchain as a side effect. I think transaction replacement may reduce the need for reputation, which in my scheme is mostly a way to reduce the risk of maliciously burned coins. The scheme would allow the network to settle on the blockchain, reducing but not eliminating the need to increase the maximum block size.

I'm on my phone, so please pardon the lack of links.

[1714959570]

1714959570

[1714959570]

1714959570

[1714959570]

1714959570

[lophie]

I am very much interested in transaction replacement as well because of my interest in rapidly changing micro transactions. Could you please shed light on what makes a transaction final?

Now for example if a tx with a lock time was made. One of the reasons to do this is to be able to send a tx later on with a higher version number invalidating the previous one. This is the basic idea behind the rapidly changing micro-tx.

If the first tx was sent to the network. What makes it not finaland makes the second one final?. Suppose the second one was not made at all! So the first one is final after all! then when can I send it to the network and make sure that they would keep it in their mem pool?

Now consider the 45th tx O_O!, Should the nodes remember only the previous version with the farthest lock time? or what should they do exactly?

Thank you for the help

[Gavin Andresen]

A transaction is final if:

All of its sequence numbers are INT_MAX
  OR
lockTime has passed.

I'm still of the opinion that non-final transactions shouldn't be broadcast over the p2p network; I think the parties negotiating using them should keep them to themselves until they are final, and broadcast then.