[bitcoin-dev] Fill-or-kill transaction

[bitcoin-dev] Fill-or-kill transaction

[jl2012]

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.

Re: [bitcoin-dev] Fill-or-kill transaction

[Mark Friedenbach]

[-- 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 --]

Re: [bitcoin-dev] Fill-or-kill transaction

[Btc Drak]

[-- 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 --]

Re: [bitcoin-dev] Fill-or-kill transaction

[Jorge Timón]

[-- 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 --]

Re: [bitcoin-dev] Fill-or-kill transaction

[Chun Wang]

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

Re: [bitcoin-dev] Fill-or-kill transaction

[Peter Todd]

-----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-----

Re: [bitcoin-dev] Fill-or-kill transaction

[jl2012]

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

Re: [bitcoin-dev] Fill-or-kill transaction

[Btc Drak]

[-- 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 --]

Re: [bitcoin-dev] Fill-or-kill transaction

[jl2012]

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.

Re: [bitcoin-dev] Fill-or-kill transaction

[Jorge Timón]

[-- 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 --]

Re: [bitcoin-dev] Fill-or-kill transaction

[Luke Dashjr]

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

Re: [bitcoin-dev] Fill-or-kill transaction

[Jorge Timón]

[-- 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 --]

Re: [bitcoin-dev] Fill-or-kill transaction

[Tom Harding]

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.

Re: [bitcoin-dev] Fill-or-kill transaction

[Jorge Timón]

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.