BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry... [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2014-11-28T12:03:52+00:00


Summary:

During a discussion about the fungibility of coins, Flavien Charlon expressed concern that making coins less fungible could result in them being non-reorg safe. However, it was argued that coins are already not reorg safe since a double spend can invalidate them after a reorg. To mitigate this risk, it is recommended to wait for 6 confirmations for important payments. It was also noted that roughly 1% of blocks are lost to reorganizations by chance. Longer reorgs could potentially destroy large amounts of coins if descendants had additional constraints. This highlights the potential for substantial losses if reorganizations prevent the recovery of valid transactions placed earlier in the chain.The use of CHECKLOCKTIMEVERIFY was discussed, with Peter Todd suggesting that the BIP text needs further clarification. He proposed that actual working examples in code, such as micropayment channels and a greenaddress-style wallet, would be more helpful. However, Gregory Maxwell pointed out that these suggestions were intentionally excluded from the proposal. Maxwell also emphasized that coins are never reorg safe, as a double spend in their history is enough to render them invalid after a reorg. Therefore, it is advised to wait for 6 confirmations for important payments.In an email exchange, Richard Moore questioned the use of OP_CHECKLOCKTIMEVERIFY in BIP 65. He suggested an alternative approach using OP_CHECKLOCKTIME, which would push either OP_TRUE or OP_FALSE onto the stack. However, it was explained that updating the stack is not soft-fork compatible and would immediately fork the network. Similarly, an invertible test is also not soft-fork compatible. A possible solution proposed by Moore is to have the VERIFY test inside a branch and have the signer provide its falseness as input to the branch. Moore also proposed allowing an opcode that would use similar semantics against an item in the stack, enabling multiple nLockTimes in a single script. However, these suggestions would break existing invariants and potentially reduce the fungibility of coins. The locktime validity, which is monotonic, was highlighted as a useful intentional property. It was concluded that these suggestions should be further clarified in the BIP text.The email questioning the use of BIP 65 and proposing alternative approaches was sent by Richard Moore, founder of Genetic Mistakes Software Inc. Contact information for Moore can be found at the end of the email.


Updated on: 2023-08-01T10:54:56.294047+00:00