Fill-or-kill transaction
14 messages, 17 to 22 Sep 2015. Started by Johnson Lau.
Jorge Timón (4), Johnson Lau (3), Btc Drak (2), Mark F, Wang Chun, Peter Todd, Luke Dashjr, Tom Harding
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.
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@lists•linuxfoundation•org> wrote:
Quoted text (118 lines)
> 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@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Forgive me if I have missed the exact use-case, but this seems overly complex. Surely fill-or-kill refers to getting a transaction confirmed within a few confirms or to drop the tx from the mempool so it wont be considered for inclusion anymore. As such, you could just repurpose a small range of nLocktime such that a TX will be accepted into mempool for a specific period before expiring.
On Thu, Sep 17, 2015 at 7:41 PM, jl2012 via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (118 lines)
> 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@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
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@lists•linuxfoundation•org> wrote:
Quoted text (136 lines)
> 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@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@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
We are currently using nLockTime for share info and nSequence for extranonce2. I have carefully reviewed the reference implementation of BIP68 and it should be compatible, but this proposal may break the implementation unless it does not affect coinbase transactions.
On Fri, Sep 18, 2015 at 2:41 AM, jl2012 via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (117 lines)
> 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@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On 17 September 2015 12:14:38 GMT-07:00, "Jorge Timón via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (13 lines)
>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...
Why wouldn't that work with p2sh? It can be implemented by a "treat like Coinbase" flag in the UTXO set, set when the output is created.
Peter Todd via bitcoin-dev 於 2015-09-17 18:44 寫到:
Quoted text (2 lines)
> It can be implemented by a "treat like Coinbase" flag in the > UTXO set, set when the output is created.
I think this is the cleanest way to implement the maturity requirement. I understand why we need maturity, However, requiring 100 block maturity will unfortunately make the system much less appealing since the recipient may not like it. A fill-or-kill tx may still be used as the initial funding tx to the Lightning Network, as long as the counterparty is willing to take the extra risk.
Actually, a fill-or-kill tx is slight safer than a coinbase tx, depending on the difference between the absolute kill time and actual confirmation time. In a re-org, an orphaned coinbase tx is permanently invalidated and has no hope to be included again. However, an orphaned fill-or-kill tx may still be confirmed by another miner. If there is still a few days until the absolute kill time, a fill-or-kill tx is basically as safe as a normal tx.
With possibility of re-org and unpredictable block interval in mind, height-based fill-or-kill is not very useful since it is difficult for users to determine the actual kill time. If we could abolish the idea of height-based fill-or-kill, the resolution of time-based fill-or-kill might be improved.
------------------------------------
Chun Wang 於 2015-09-17 18:33 寫到:
Quoted text (5 lines)
> We are currently using nLockTime for share info and nSequence for > extranonce2. I have carefully reviewed the reference implementation of > BIP68 and it should be compatible, but this proposal may break the > implementation unless it does not affect coinbase transactions. >
The fill-or-kill system is totally optional, using a bit flag in tx nVersion to indicate. Everything should be fine unless you are also messing with the nVersion
-------------------------------------
Btc Drak 於 2015-09-17 15:12 寫到:
Quoted text (6 lines)
> Forgive me if I have missed the exact use-case, but this seems overly > complex. Surely fill-or-kill refers to getting a transaction confirmed > within a few confirms or to drop the tx from the mempool so it wont be > considered for inclusion anymore. As such, you could just repurpose a > small range of nLocktime such that a TX will be accepted into mempool > for a specific period before expiring.
What I'm describing is to implement fill-or-kill as consensus rule. Certainly, we could implement it at the P2P network level: everything is the same as I described, but the nLockTime2 and nKillTime are for reference only and tx validity depends only on the nLockTime. Benevolent miners should drop the tx after the suggested kill time but there is no guarantee
-------------------------------------
I made a mistake in this example:
Quoted text (4 lines)
> 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
The correct nLockTime2 for this example should be 210000/4 = 52500
On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (16 lines)
> Btc Drak 於 2015-09-17 15:12 寫到: > >> Forgive me if I have missed the exact use-case, but this seems overly >> complex. Surely fill-or-kill refers to getting a transaction confirmed >> within a few confirms or to drop the tx from the mempool so it wont be >> considered for inclusion anymore. As such, you could just repurpose a >> small range of nLocktime such that a TX will be accepted into mempool >> for a specific period before expiring. >> > > What I'm describing is to implement fill-or-kill as consensus rule. > Certainly, we could implement it at the P2P network level: everything is > the same as I described, but the nLockTime2 and nKillTime are for reference > only and tx validity depends only on the nLockTime. Benevolent miners > should drop the tx after the suggested kill time but there is no guarantee >
Sure, you can make the scheme I describe consensus based by adding the rule tx is not valid to mine after expiry: this still keeps the simplicity I described.
Btc Drak 於 2015-09-18 02:42 寫到:
Quoted text (27 lines)
> On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org> wrote: > >> Btc Drak 於 2015-09-17 15:12 寫到: >> >>> Forgive me if I have missed the exact use-case, but this seems >>> overly >>> complex. Surely fill-or-kill refers to getting a transaction >>> confirmed >>> within a few confirms or to drop the tx from the mempool so it >>> wont be >>> considered for inclusion anymore. As such, you could just >>> repurpose a >>> small range of nLocktime such that a TX will be accepted into >>> mempool >>> for a specific period before expiring. >> >> What I'm describing is to implement fill-or-kill as consensus rule. >> Certainly, we could implement it at the P2P network level: >> everything is the same as I described, but the nLockTime2 and >> nKillTime are for reference only and tx validity depends only on the >> nLockTime. Benevolent miners should drop the tx after the suggested >> kill time but there is no guarantee > > Sure, you can make the scheme I describe consensus based by adding the > rule tx is not valid to mine after expiry: this still keeps the > simplicity I described.
If you simply redefine a range of unused nLockTime as nKillTime, users will be constrained to use either nLockTime or nKillTime, but not both in the same tx.
If we are willing to scarify a large range of tx nVersion, say 10-15bits, the nKillTime data could be embedded there.
Another option is nSequence, which will allow per-input nKillTime and nLockTime.
The cleanest way, of course, is a hardfork to add a new nKillTime field to the tx so people could use nLockTime and nKillTime in parallel.
On Sep 17, 2015 6:48 PM, "Peter Todd" <pete@petertodd•org> wrote:
Quoted text (7 lines)
> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > On 17 September 2015 12:14:38 GMT-07:00, "Jorge Timón via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (15 lines)
> >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... > > Why wouldn't that work with p2sh? It can be implemented by a "treat like
Coinbase" flag in the UTXO set, set when the output is created.
I said require all scrptPubkeys to have op_maturity/rcltv/csv 100+, but yeah, that would work.
Regarding nKillTime, please call it nExpiryTime. And instead of fill or kill transactions, ttansactions that expire. It is not only more accurate (ie fill or kill is for market orders that complete in their full amount now or are cancelled, not for transfers) and it is the term we have been using for years.
Reinventing the wheel by changing its name it's something we do often (for example, rcltv was op_maturity in February 2014 and was "reinvented" as rcltv recently. This makes it harder for people to learn and follow up. Please don't insist in fok, that's for market orders and works differently than expiries. Expiry is the old name and it's also much more accurate.
Quoted text (11 lines)
> > iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV+0Ip > AAoJEMCF8hzn9Lncz4MIAIQpz7tKbmjEuETX6BnPatJ50I+kS6CQ4eE+e1irXpbb > OCMe0A2TGzw9G5t7DgMU1lCcbcbuqOxMOrHYXuGsGkpVtRrLFbkS/F9vCS2RJT0w > kRkL2ecN8riAjh1lUUgY1CEgVyhkwh6Rw1ZALu3Ba2tISysMfXjAW1GiLHlgxP7g > xD6zS0OTTokG/7+s1hGK2Nd4q/ZHnfOO1JgiBzrykGNq4enp7nRhiZKhnc/0ILJA > 3WAsAMI14ZUxs95onjey7J3100tZBetYr14jzLRvf+w1klBNSvcen9dr+VhdyXYk > MPMOwuUtq4OI1vt3HDoMjNFT6olg0gTxzWe8Grn96S4= > =pP3Q > -----END PGP SIGNATURE----- >
On Thursday, September 17, 2015 7:14:38 PM Jorge Timón via bitcoin-dev wrote:
Quoted text (3 lines)
> 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.
Not quite as safe. Remember that mined bitcoins have not only a 100-block maturity requirement, but *also* are expensive to generate. Mere OP_CHECKMATURITYVERIFY (aka rcltv) has no cost to use...
Luke
How them being expensive to generate make them less likely to be reorged? Would an op_return output used as a nonce to make the hash of the transaction contain some proof of work make the non-coinbase expirable transaction more secure against reorgs? I'm afraid your point is irrelevant. On Sep 19, 2015 4:01 AM, "Luke Dashjr" <luke@dashjr•org> wrote:
Quoted text (13 lines)
> On Thursday, September 17, 2015 7:14:38 PM Jorge Timón via bitcoin-dev > wrote: > > 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. > > Not quite as safe. Remember that mined bitcoins have not only a 100-block > maturity requirement, but *also* are expensive to generate. > Mere OP_CHECKMATURITYVERIFY (aka rcltv) has no cost to use... > > Luke >
On 9/17/2015 8:27 PM, jl2012 via bitcoin-dev wrote:
Quoted text (2 lines)
> However, requiring 100 block maturity will unfortunately make the > system much less appealing since the recipient may not like it.
The maturity requirement can be dropped if the expiration height is more that 100 blocks after inclusion height.
On Fri, Sep 18, 2015 at 12:44 AM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (21 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > On 17 September 2015 12:14:38 GMT-07:00, "Jorge Timón via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation•org> wrote: >>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... > > Why wouldn't that work with p2sh? It can be implemented by a "treat like Coinbase" flag in the UTXO set, set when the output is created.
That would work. I was thinking about requiring OP_MATURITY 100 (or greater than 100) in all the scriptPubKey's of the expiry transaction.