{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-11-24\n📝 Original message:On Tue, Nov 24, 2015 at 10:30:52AM +0000, Btc Drak via bitcoin-dev wrote:\n\u003e BIP68 introduces relative lock-time semantics to part of the nSequence\n\u003e field leaving the majority of bits undefined for other future applications.\n\u003e \n\u003e BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifically\n\u003e limited to verifying transaction inputs according to BIP68's relative\n\u003e lock-time[1], yet the _name_ OP_CSV is much boarder than that. We spent\n\u003e months limiting the number of bits used in BIP68 so they would be available\n\u003e for future use cases, thus we have acknowledged there will be completely\n\u003e different usecases that take advantage of unused nSequence bits.\n\u003e \n\u003e For this reason I believe the BIP112 should be renamed specifically for\n\u003e it's usecase, which is verifying the time/maturity of transaction inputs\n\u003e relative to their inclusion in a block.\n\u003e \n\u003e Suggestions:-\n\u003e \n\u003e CHECKMATURITYVERIFY\n\nDefinitely this one.\n\nAlthough I wouldn't rush to make the change just yet - I for one am busy\nwriting some test programs to actually use BIP112, and in theory they\nmight say the more general CSV concept is better.\n\nWhatever we call it, deciding on that is a simple s/FOO/BAR/ prior to\nrelease.\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000008cd594ba6601fcc5e9e919b30630076c64657209b13c7b4\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151124/4d685b3f/attachment.sig\u003e"}