* [bitcoin-dev] Fill-or-kill transaction
@ 2015-09-17 18:41 jl2012
2015-09-17 19:07 ` Mark Friedenbach
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: jl2012 @ 2015-09-17 18:41 UTC (permalink / raw)
To: bitcoin-dev
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Fill-or-kill transaction
2015-09-17 18:41 [bitcoin-dev] Fill-or-kill transaction jl2012
@ 2015-09-17 19:07 ` Mark Friedenbach
2015-09-17 19:14 ` Jorge Timón
2015-09-17 19:12 ` Btc Drak
2015-09-17 22:33 ` Chun Wang
2 siblings, 1 reply; 14+ messages in thread
From: Mark Friedenbach @ 2015-09-17 19:07 UTC (permalink / raw)
To: jl2012; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4845 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 5604 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Fill-or-kill transaction
2015-09-17 18:41 [bitcoin-dev] Fill-or-kill transaction jl2012
2015-09-17 19:07 ` Mark Friedenbach
@ 2015-09-17 19:12 ` Btc Drak
2015-09-17 22:33 ` Chun Wang
2 siblings, 0 replies; 14+ messages in thread
From: Btc Drak @ 2015-09-17 19:12 UTC (permalink / raw)
To: jl2012; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5011 bytes --]
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:
> 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
>
[-- Attachment #2: Type: text/html, Size: 5749 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Fill-or-kill transaction
2015-09-17 19:07 ` Mark Friedenbach
@ 2015-09-17 19:14 ` Jorge Timón
2015-09-17 22:44 ` Peter Todd
2015-09-19 2:01 ` Luke Dashjr
0 siblings, 2 replies; 14+ messages in thread
From: Jorge Timón @ 2015-09-17 19:14 UTC (permalink / raw)
To: Mark; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5774 bytes --]
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:
> 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
>
>
[-- Attachment #2: Type: text/html, Size: 6860 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Fill-or-kill transaction
2015-09-17 18:41 [bitcoin-dev] Fill-or-kill transaction jl2012
2015-09-17 19:07 ` Mark Friedenbach
2015-09-17 19:12 ` Btc Drak
@ 2015-09-17 22:33 ` Chun Wang
2 siblings, 0 replies; 14+ messages in thread
From: Chun Wang @ 2015-09-17 22:33 UTC (permalink / raw)
To: jl2012; +Cc: 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:
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Fill-or-kill transaction
2015-09-17 19:14 ` Jorge Timón
@ 2015-09-17 22:44 ` Peter Todd
2015-09-18 3:27 ` jl2012
` (2 more replies)
2015-09-19 2:01 ` Luke Dashjr
1 sibling, 3 replies; 14+ messages in thread
From: Peter Todd @ 2015-09-17 22:44 UTC (permalink / raw)
To: Jorge Timón, Jorge Timón via bitcoin-dev, Mark; +Cc: Bitcoin Dev
-----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.
-----BEGIN PGP SIGNATURE-----
iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV+0Ip
AAoJEMCF8hzn9Lncz4MIAIQpz7tKbmjEuETX6BnPatJ50I+kS6CQ4eE+e1irXpbb
OCMe0A2TGzw9G5t7DgMU1lCcbcbuqOxMOrHYXuGsGkpVtRrLFbkS/F9vCS2RJT0w
kRkL2ecN8riAjh1lUUgY1CEgVyhkwh6Rw1ZALu3Ba2tISysMfXjAW1GiLHlgxP7g
xD6zS0OTTokG/7+s1hGK2Nd4q/ZHnfOO1JgiBzrykGNq4enp7nRhiZKhnc/0ILJA
3WAsAMI14ZUxs95onjey7J3100tZBetYr14jzLRvf+w1klBNSvcen9dr+VhdyXYk
MPMOwuUtq4OI1vt3HDoMjNFT6olg0gTxzWe8Grn96S4=
=pP3Q
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Fill-or-kill transaction
2015-09-17 22:44 ` Peter Todd
@ 2015-09-18 3:27 ` jl2012
2015-09-18 6:42 ` Btc Drak
2015-09-19 15:31 ` Tom Harding
2015-09-18 13:08 ` Jorge Timón
2015-09-22 17:45 ` Jorge Timón
2 siblings, 2 replies; 14+ messages in thread
From: jl2012 @ 2015-09-18 3:27 UTC (permalink / raw)
To: bitcoin-dev
Peter Todd via bitcoin-dev 於 2015-09-17 18:44 寫到:
> 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 寫到:
> 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 寫到:
> 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:
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Fill-or-kill transaction
2015-09-18 3:27 ` jl2012
@ 2015-09-18 6:42 ` Btc Drak
2015-09-18 9:12 ` jl2012
2015-09-19 15:31 ` Tom Harding
1 sibling, 1 reply; 14+ messages in thread
From: Btc Drak @ 2015-09-18 6:42 UTC (permalink / raw)
To: jl2012; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1574 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Fill-or-kill transaction
2015-09-18 6:42 ` Btc Drak
@ 2015-09-18 9:12 ` jl2012
0 siblings, 0 replies; 14+ messages in thread
From: jl2012 @ 2015-09-18 9:12 UTC (permalink / raw)
To: Btc Drak; +Cc: Bitcoin Dev
Btc Drak 於 2015-09-18 02:42 寫到:
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Fill-or-kill transaction
2015-09-17 22:44 ` Peter Todd
2015-09-18 3:27 ` jl2012
@ 2015-09-18 13:08 ` Jorge Timón
2015-09-22 17:45 ` Jorge Timón
2 siblings, 0 replies; 14+ messages in thread
From: Jorge Timón @ 2015-09-18 13:08 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]
On Sep 17, 2015 6:48 PM, "Peter Todd" <pete@petertodd•org> wrote:
>
> -----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.
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.
>
> iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV+0Ip
> AAoJEMCF8hzn9Lncz4MIAIQpz7tKbmjEuETX6BnPatJ50I+kS6CQ4eE+e1irXpbb
> OCMe0A2TGzw9G5t7DgMU1lCcbcbuqOxMOrHYXuGsGkpVtRrLFbkS/F9vCS2RJT0w
> kRkL2ecN8riAjh1lUUgY1CEgVyhkwh6Rw1ZALu3Ba2tISysMfXjAW1GiLHlgxP7g
> xD6zS0OTTokG/7+s1hGK2Nd4q/ZHnfOO1JgiBzrykGNq4enp7nRhiZKhnc/0ILJA
> 3WAsAMI14ZUxs95onjey7J3100tZBetYr14jzLRvf+w1klBNSvcen9dr+VhdyXYk
> MPMOwuUtq4OI1vt3HDoMjNFT6olg0gTxzWe8Grn96S4=
> =pP3Q
> -----END PGP SIGNATURE-----
>
[-- Attachment #2: Type: text/html, Size: 2766 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Fill-or-kill transaction
2015-09-17 19:14 ` Jorge Timón
2015-09-17 22:44 ` Peter Todd
@ 2015-09-19 2:01 ` Luke Dashjr
2015-09-19 5:09 ` Jorge Timón
1 sibling, 1 reply; 14+ messages in thread
From: Luke Dashjr @ 2015-09-19 2:01 UTC (permalink / raw)
To: bitcoin-dev, Jorge Timón
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Fill-or-kill transaction
2015-09-19 2:01 ` Luke Dashjr
@ 2015-09-19 5:09 ` Jorge Timón
0 siblings, 0 replies; 14+ messages in thread
From: Jorge Timón @ 2015-09-19 5:09 UTC (permalink / raw)
To: Luke-Jr; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 884 bytes --]
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:
> 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
>
[-- Attachment #2: Type: text/html, Size: 1148 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Fill-or-kill transaction
2015-09-18 3:27 ` jl2012
2015-09-18 6:42 ` Btc Drak
@ 2015-09-19 15:31 ` Tom Harding
1 sibling, 0 replies; 14+ messages in thread
From: Tom Harding @ 2015-09-19 15:31 UTC (permalink / raw)
To: bitcoin-dev
On 9/17/2015 8:27 PM, jl2012 via bitcoin-dev wrote:
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Fill-or-kill transaction
2015-09-17 22:44 ` Peter Todd
2015-09-18 3:27 ` jl2012
2015-09-18 13:08 ` Jorge Timón
@ 2015-09-22 17:45 ` Jorge Timón
2 siblings, 0 replies; 14+ messages in thread
From: Jorge Timón @ 2015-09-22 17:45 UTC (permalink / raw)
To: Peter Todd; +Cc: Jorge Timón via bitcoin-dev
On Fri, Sep 18, 2015 at 12:44 AM, Peter Todd <pete@petertodd•org> wrote:
> -----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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-09-22 17:45 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-17 18:41 [bitcoin-dev] Fill-or-kill transaction jl2012
2015-09-17 19:07 ` Mark Friedenbach
2015-09-17 19:14 ` Jorge Timón
2015-09-17 22:44 ` Peter Todd
2015-09-18 3:27 ` jl2012
2015-09-18 6:42 ` Btc Drak
2015-09-18 9:12 ` jl2012
2015-09-19 15:31 ` Tom Harding
2015-09-18 13:08 ` Jorge Timón
2015-09-22 17:45 ` Jorge Timón
2015-09-19 2:01 ` Luke Dashjr
2015-09-19 5:09 ` Jorge Timón
2015-09-17 19:12 ` Btc Drak
2015-09-17 22:33 ` Chun Wang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox