{"type":"rich","version":"1.0","author_name":"npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4","author_url":"https://nostr.ae/npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-09-17\n📝 Original message:Fill-or-kill tx is not a new idea and is discussed in the Scaling \nBitcoin workshop. In Satoshi's implementation of nLockTime, a huge range \nof timestamp (from 1970 to 2009) is wasted. By exploiting this unused \nrange and with compromise in the time resolution, a fill-or-kill system \ncould be built with a softfork.\n\n-----------\nTwo new parameters, nLockTime2 and nKillTime are defined:\n\nnLockTime2 (Range: 0-1,853,010)\n0: Tx could be confirmed at or after block 420,000\n1: Tx could be confirmed at or after block 420,004\n.\n.\n719,999: Tx could be confirmed at or after block 3,299,996 (about 55 \nyears from now)\n720,000: Tx could be confirmed if the median time-past \u003e= 1,474,562,048 \n(2016-09-22)\n720,001: Tx could be confirmed if the median time-past \u003e= 1,474,564,096 \n(2016-09-22)\n.\n.\n1,853,010 (max): Tx could be confirmed if the median time-past \u003e= \n3,794,966,528 (2090-04-04)\n\nnKillTime (Range: 0-2047)\nif nLockTime2 \u003c 720,000, the tx could be confirmed at or before block \n(nLockTime2 + nKillTime * 4)\nif nLockTime2 \u003e= 720,000, the tx could be confirmed if the median \ntime-past \u003c= (nLockTime2 - 720,001 + nKillTime) * 2048\n\nFinally, nLockTime = 500,000,000 + nKillTime + nLockTime2 * 2048\n\nSetting a bit flag in tx nVersion will activate the new rules.\n\nThe resolution is 4 blocks or 2048s (34m)\nThe maximum confirmation window is 8188 blocks (56.9 days) or \n16,769,024s (48.5 days)\n\nFor example:\nWith nLockTime2 = 20 and nKillTime = 100, a tx could be confirmed only \nbetween block 420,080 and 420,480\nWith nLockTime2 = 730,000 and nKillTime = 1000, a tx could be confirmed \nonly between median time-past of 1,495,042,048 and 1,497,090,048\n\n----------------\nWhy is this a softfork?\n\nRemember this formula: nLockTime = 500,000,000 + nKillTime + nLockTime2 \n* 2048\n\nFor height based nLockTime2 (\u003c= 719,999)\n\nFor nLockTime2 = 0 and nKillTime = 0, nLockTime = 500,000,000, which \nmeans the tx could be confirmed after 1970-01-01 with the original lock \ntime rule. As the new rule does not allow confirmation until block \n420,000, it's clearly a softfork.\n\nIt is not difficult to see that the growth of nLockTime will never catch \nup nLockTime2.\n\nAt nLockTime2 = 719,999 and nKillTime = 2047, nLockTime = 1,974,559,999, \nwhich means 2016-09-22. However, the new rule will not allow \nconfirmation until block 3,299,996 which is decades to go\n\n\n\nFor time based nLockTime2 (\u003e 720,000)\n\nFor nLockTime2 = 720,000 and nKillTime = 0, nLockTime = 1,974,560,000, \nwhich means the tx could be confirmed after median time-past \n1,474,560,000 (assuming BIP113). However, the new rule will not allow \nconfirmation until 1,474,562,048, therefore a soft fork.\n\nFor nLockTime2 = 720,000 and nKillTime = 2047, nLockTime = \n1,974,562,047, which could be confirmed at 1,474,562,047. Again, the new \nrule will not allow confirmation until 1,474,562,048. The 1 second \ndifference makes it a soft fork.\n\nActually, for every nLockTime2 value \u003e= 720,000, the lock time with the \nnew rule must be 1-2048 seconds later than the original rule.\n\nFor nLockTime2 = 1,853,010 and nKillTime = 2047, nLockTime = \n4,294,966,527, which is the highest possible value with the 32-bit \nnLockTime\n\n----------------\nUser's perspective:\n\nA user wants his tx either filled or killed in about 3 hours. He will \nset a time-based nLockTime2 according to the current median time-past, \nand set nKillTime = 5\n\nA user wants his tx get confirmed in the block 630000, the first block \nwith reward below 10BTC. He is willing to pay high fee but don't want it \ngets into another block. He will set nLockTime2 = 210,000 and nKillTime \n= 0\n\n----------------\nOP_CLTV\n\nTime-based OP_CLTV could be upgraded to support time-based nLockTime2. \nHowever, height-based OP_CLTV is not compatible with nLockTime2. To \nspend a height-based OP_CLTV output, user must use the original \nnLockTime.\n\nWe may need a new OP_CLTV2 which could verify both nLockTime and \nnLockTime2\n\n----------------\n55 years after?\n\nThe height-based nLockTime2 will overflow in 55 years. It is very likely \na hard fork will happen to implement a better fill-or-kill system. If \nnot, we could reboot everything with another tx nVersion for another 55 \nyears."}