One thing that wasn't mentioned yet was that there's not currently a mechanism for replacement. Locked transactions can be "introduced" into the blockchain fairly easily, and nodes will accept them and hold them in their memory pool (and thus drop conflicting transactions), but they won't forward otherwise-valid replacements, and only miners with custom rules will mine them for you. If you want to replace a time-locked transaction, you're going to have to mine it yourself, or go find a miner to agree to help you. Once a replacement is mined (or even just a regular transaction spending one of the inputs), all nodes holding the time-locked tx will see the conflict and drop the one in their memory pool.
So, if you can create the tx, you can get the "time-delay" aspect out of the network right now, but you have to work pretty hard if you use the "replacement" aspect of it.
P.S. - Congrats on being the most well-spoken, research-driven, single-post Newbie I've seen on these forums
So, if you can create the tx, you can get the "time-delay" aspect out of the network right now, but you have to work pretty hard if you use the "replacement" aspect of it.
P.S. - Congrats on being the most well-spoken, research-driven, single-post Newbie I've seen on these forums
etotheipi, I don't think this is the case anymore. Time-locked transactions can't be introduced into the blockchain until the time expires, right?
Also, I believe that transaction replacement is not a problem now because time-locked transactions are non-standard and not relayed until the lock_time is reached. Therefore, replacement isn't needed because nodes aren't storing the locked transactions in their mempools.
Given that, I also think that the Mike Hearn example "Dominent Assurance Contracts" that Aakselrod put on the bitcoin wiki page is wrong when it says "The scheme requires the use of multisignature transactions, nLockTime and transaction replacement which means it won't work until these features are available on the Bitcoin network". Since locked transactions aren't relayed and stored in the mempools, it seems like you can implement this scheme today even though transaction replacement is not available because you should be able to push the transaction that completes the contract because no locked transaction will be in a mempool to conflict.
Could someone confirm this?