📅 Original date posted:2015-09-17
📝 Original message:Fill or kill us normally used for trades and I think it can be confusing.
Previous times this has been discussed it has been discussed under
nExpiryTime or op_height (which enables expiration), for example, in the
freimarkets white paper.
As Mark points out this can be made safe by requiring that all the outputs
of a transaction that can expire have op_maturity/csv/rcltv of 100. That
makes them as reorg-safe as coinbase transactions. Unfortunately this
doesn't play very well with p2sh...
On Sep 17, 2015 3:08 PM, "Mark Friedenbach via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Note that this violates present assumptions about transaction validity,
> unless a constraint also exists that any output of such an expiry block is
> not spent for at least 100 blocks.
>
> Do you have a clean way of ensuring this?
>
> On Thu, Sep 17, 2015 at 2:41 PM, jl2012 via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Fill-or-kill tx is not a new idea and is discussed in the Scaling Bitcoin
>> workshop. In Satoshi's implementation of nLockTime, a huge range of
>> timestamp (from 1970 to 2009) is wasted. By exploiting this unused range
>> and with compromise in the time resolution, a fill-or-kill system could be
>> built with a softfork.
>>
>> -----------
>> Two new parameters, nLockTime2 and nKillTime are defined:
>>
>> nLockTime2 (Range: 0-1,853,010)
>> 0: Tx could be confirmed at or after block 420,000
>> 1: Tx could be confirmed at or after block 420,004
>> .
>> .
>> 719,999: Tx could be confirmed at or after block 3,299,996 (about 55
>> years from now)
>> 720,000: Tx could be confirmed if the median time-past >= 1,474,562,048
>> (2016-09-22)
>> 720,001: Tx could be confirmed if the median time-past >= 1,474,564,096
>> (2016-09-22)
>> .
>> .
>> 1,853,010 (max): Tx could be confirmed if the median time-past >=
>> 3,794,966,528 (2090-04-04)
>>
>> nKillTime (Range: 0-2047)
>> if nLockTime2 < 720,000, the tx could be confirmed at or before block
>> (nLockTime2 + nKillTime * 4)
>> if nLockTime2 >= 720,000, the tx could be confirmed if the median
>> time-past <= (nLockTime2 - 720,001 + nKillTime) * 2048
>>
>> Finally, nLockTime = 500,000,000 + nKillTime + nLockTime2 * 2048
>>
>> Setting a bit flag in tx nVersion will activate the new rules.
>>
>> The resolution is 4 blocks or 2048s (34m)
>> The maximum confirmation window is 8188 blocks (56.9 days) or 16,769,024s
>> (48.5 days)
>>
>> For example:
>> With nLockTime2 = 20 and nKillTime = 100, a tx could be confirmed only
>> between block 420,080 and 420,480
>> With nLockTime2 = 730,000 and nKillTime = 1000, a tx could be confirmed
>> only between median time-past of 1,495,042,048 and 1,497,090,048
>>
>> ----------------
>> Why is this a softfork?
>>
>> Remember this formula: nLockTime = 500,000,000 + nKillTime + nLockTime2 *
>> 2048
>>
>> For height based nLockTime2 (<= 719,999)
>>
>> For nLockTime2 = 0 and nKillTime = 0, nLockTime = 500,000,000, which
>> means the tx could be confirmed after 1970-01-01 with the original lock
>> time rule. As the new rule does not allow confirmation until block 420,000,
>> it's clearly a softfork.
>>
>> It is not difficult to see that the growth of nLockTime will never catch
>> up nLockTime2.
>>
>> At nLockTime2 = 719,999 and nKillTime = 2047, nLockTime = 1,974,559,999,
>> which means 2016-09-22. However, the new rule will not allow confirmation
>> until block 3,299,996 which is decades to go
>>
>>
>>
>> For time based nLockTime2 (> 720,000)
>>
>> For nLockTime2 = 720,000 and nKillTime = 0, nLockTime = 1,974,560,000,
>> which means the tx could be confirmed after median time-past 1,474,560,000
>> (assuming BIP113). However, the new rule will not allow confirmation until
>> 1,474,562,048, therefore a soft fork.
>>
>> For nLockTime2 = 720,000 and nKillTime = 2047, nLockTime = 1,974,562,047,
>> which could be confirmed at 1,474,562,047. Again, the new rule will not
>> allow confirmation until 1,474,562,048. The 1 second difference makes it a
>> soft fork.
>>
>> Actually, for every nLockTime2 value >= 720,000, the lock time with the
>> new rule must be 1-2048 seconds later than the original rule.
>>
>> For nLockTime2 = 1,853,010 and nKillTime = 2047, nLockTime =
>> 4,294,966,527, which is the highest possible value with the 32-bit nLockTime
>>
>> ----------------
>> User's perspective:
>>
>> A user wants his tx either filled or killed in about 3 hours. He will set
>> a time-based nLockTime2 according to the current median time-past, and set
>> nKillTime = 5
>>
>> A user wants his tx get confirmed in the block 630000, the first block
>> with reward below 10BTC. He is willing to pay high fee but don't want it
>> gets into another block. He will set nLockTime2 = 210,000 and nKillTime = 0
>>
>> ----------------
>> OP_CLTV
>>
>> Time-based OP_CLTV could be upgraded to support time-based nLockTime2.
>> However, height-based OP_CLTV is not compatible with nLockTime2. To spend a
>> height-based OP_CLTV output, user must use the original nLockTime.
>>
>> We may need a new OP_CLTV2 which could verify both nLockTime and
>> nLockTime2
>>
>> ----------------
>> 55 years after?
>>
>> The height-based nLockTime2 will overflow in 55 years. It is very likely
>> a hard fork will happen to implement a better fill-or-kill system. If not,
>> we could reboot everything with another tx nVersion for another 55 years.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150917/3db9f191/attachment-0001.html>;
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 17:40:44
in reply to nevent1q…f5q7
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 17:40:44Event JSON
{
"id": "d669e35373dc088564a2fc850559992b0d5af99fa3130f54674a71873482df94",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686159644,
"kind": 1,
"tags": [
[
"e",
"d245f3cd2427d9c30e488b3eacebf2ae42b122d633366f33db323c8696dd9375",
"",
"root"
],
[
"e",
"84b66ca13d0ec23555a200ba1d4f1e9fab7d7ea63fe7f29d5dc16e52c88ffdc9",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2015-09-17\n📝 Original message:Fill or kill us normally used for trades and I think it can be confusing.\nPrevious times this has been discussed it has been discussed under\nnExpiryTime or op_height (which enables expiration), for example, in the\nfreimarkets white paper.\n\nAs Mark points out this can be made safe by requiring that all the outputs\nof a transaction that can expire have op_maturity/csv/rcltv of 100. That\nmakes them as reorg-safe as coinbase transactions. Unfortunately this\ndoesn't play very well with p2sh...\nOn Sep 17, 2015 3:08 PM, \"Mark Friedenbach via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Note that this violates present assumptions about transaction validity,\n\u003e unless a constraint also exists that any output of such an expiry block is\n\u003e not spent for at least 100 blocks.\n\u003e\n\u003e Do you have a clean way of ensuring this?\n\u003e\n\u003e On Thu, Sep 17, 2015 at 2:41 PM, jl2012 via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Fill-or-kill tx is not a new idea and is discussed in the Scaling Bitcoin\n\u003e\u003e workshop. In Satoshi's implementation of nLockTime, a huge range of\n\u003e\u003e timestamp (from 1970 to 2009) is wasted. By exploiting this unused range\n\u003e\u003e and with compromise in the time resolution, a fill-or-kill system could be\n\u003e\u003e built with a softfork.\n\u003e\u003e\n\u003e\u003e -----------\n\u003e\u003e Two new parameters, nLockTime2 and nKillTime are defined:\n\u003e\u003e\n\u003e\u003e nLockTime2 (Range: 0-1,853,010)\n\u003e\u003e 0: Tx could be confirmed at or after block 420,000\n\u003e\u003e 1: Tx could be confirmed at or after block 420,004\n\u003e\u003e .\n\u003e\u003e .\n\u003e\u003e 719,999: Tx could be confirmed at or after block 3,299,996 (about 55\n\u003e\u003e years from now)\n\u003e\u003e 720,000: Tx could be confirmed if the median time-past \u003e= 1,474,562,048\n\u003e\u003e (2016-09-22)\n\u003e\u003e 720,001: Tx could be confirmed if the median time-past \u003e= 1,474,564,096\n\u003e\u003e (2016-09-22)\n\u003e\u003e .\n\u003e\u003e .\n\u003e\u003e 1,853,010 (max): Tx could be confirmed if the median time-past \u003e=\n\u003e\u003e 3,794,966,528 (2090-04-04)\n\u003e\u003e\n\u003e\u003e nKillTime (Range: 0-2047)\n\u003e\u003e if nLockTime2 \u003c 720,000, the tx could be confirmed at or before block\n\u003e\u003e (nLockTime2 + nKillTime * 4)\n\u003e\u003e if nLockTime2 \u003e= 720,000, the tx could be confirmed if the median\n\u003e\u003e time-past \u003c= (nLockTime2 - 720,001 + nKillTime) * 2048\n\u003e\u003e\n\u003e\u003e Finally, nLockTime = 500,000,000 + nKillTime + nLockTime2 * 2048\n\u003e\u003e\n\u003e\u003e Setting a bit flag in tx nVersion will activate the new rules.\n\u003e\u003e\n\u003e\u003e The resolution is 4 blocks or 2048s (34m)\n\u003e\u003e The maximum confirmation window is 8188 blocks (56.9 days) or 16,769,024s\n\u003e\u003e (48.5 days)\n\u003e\u003e\n\u003e\u003e For example:\n\u003e\u003e With nLockTime2 = 20 and nKillTime = 100, a tx could be confirmed only\n\u003e\u003e between block 420,080 and 420,480\n\u003e\u003e With nLockTime2 = 730,000 and nKillTime = 1000, a tx could be confirmed\n\u003e\u003e only between median time-past of 1,495,042,048 and 1,497,090,048\n\u003e\u003e\n\u003e\u003e ----------------\n\u003e\u003e Why is this a softfork?\n\u003e\u003e\n\u003e\u003e Remember this formula: nLockTime = 500,000,000 + nKillTime + nLockTime2 *\n\u003e\u003e 2048\n\u003e\u003e\n\u003e\u003e For height based nLockTime2 (\u003c= 719,999)\n\u003e\u003e\n\u003e\u003e For nLockTime2 = 0 and nKillTime = 0, nLockTime = 500,000,000, which\n\u003e\u003e means the tx could be confirmed after 1970-01-01 with the original lock\n\u003e\u003e time rule. As the new rule does not allow confirmation until block 420,000,\n\u003e\u003e it's clearly a softfork.\n\u003e\u003e\n\u003e\u003e It is not difficult to see that the growth of nLockTime will never catch\n\u003e\u003e up nLockTime2.\n\u003e\u003e\n\u003e\u003e At nLockTime2 = 719,999 and nKillTime = 2047, nLockTime = 1,974,559,999,\n\u003e\u003e which means 2016-09-22. However, the new rule will not allow confirmation\n\u003e\u003e until block 3,299,996 which is decades to go\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e For time based nLockTime2 (\u003e 720,000)\n\u003e\u003e\n\u003e\u003e For nLockTime2 = 720,000 and nKillTime = 0, nLockTime = 1,974,560,000,\n\u003e\u003e which means the tx could be confirmed after median time-past 1,474,560,000\n\u003e\u003e (assuming BIP113). However, the new rule will not allow confirmation until\n\u003e\u003e 1,474,562,048, therefore a soft fork.\n\u003e\u003e\n\u003e\u003e For nLockTime2 = 720,000 and nKillTime = 2047, nLockTime = 1,974,562,047,\n\u003e\u003e which could be confirmed at 1,474,562,047. Again, the new rule will not\n\u003e\u003e allow confirmation until 1,474,562,048. The 1 second difference makes it a\n\u003e\u003e soft fork.\n\u003e\u003e\n\u003e\u003e Actually, for every nLockTime2 value \u003e= 720,000, the lock time with the\n\u003e\u003e new rule must be 1-2048 seconds later than the original rule.\n\u003e\u003e\n\u003e\u003e For nLockTime2 = 1,853,010 and nKillTime = 2047, nLockTime =\n\u003e\u003e 4,294,966,527, which is the highest possible value with the 32-bit nLockTime\n\u003e\u003e\n\u003e\u003e ----------------\n\u003e\u003e User's perspective:\n\u003e\u003e\n\u003e\u003e A user wants his tx either filled or killed in about 3 hours. He will set\n\u003e\u003e a time-based nLockTime2 according to the current median time-past, and set\n\u003e\u003e nKillTime = 5\n\u003e\u003e\n\u003e\u003e A user wants his tx get confirmed in the block 630000, the first block\n\u003e\u003e with reward below 10BTC. He is willing to pay high fee but don't want it\n\u003e\u003e gets into another block. He will set nLockTime2 = 210,000 and nKillTime = 0\n\u003e\u003e\n\u003e\u003e ----------------\n\u003e\u003e OP_CLTV\n\u003e\u003e\n\u003e\u003e Time-based OP_CLTV could be upgraded to support time-based nLockTime2.\n\u003e\u003e However, height-based OP_CLTV is not compatible with nLockTime2. To spend a\n\u003e\u003e height-based OP_CLTV output, user must use the original nLockTime.\n\u003e\u003e\n\u003e\u003e We may need a new OP_CLTV2 which could verify both nLockTime and\n\u003e\u003e nLockTime2\n\u003e\u003e\n\u003e\u003e ----------------\n\u003e\u003e 55 years after?\n\u003e\u003e\n\u003e\u003e The height-based nLockTime2 will overflow in 55 years. It is very likely\n\u003e\u003e a hard fork will happen to implement a better fill-or-kill system. If not,\n\u003e\u003e we could reboot everything with another tx nVersion for another 55 years.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150917/3db9f191/attachment-0001.html\u003e",
"sig": "25a41db3eb7b9d327eb710609490284f3a918f07bd061d3ec0224f859d4fd4054a9fdd3151128e68ff1374aa73072b685b93ee4e13cf76a11e0fb347160cbf3d"
}