From: jl2012@xbt•hk
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Fill-or-kill transaction
Date: Thu, 17 Sep 2015 14:41:39 -0400 [thread overview]
Message-ID: <a50b82c156c805a284386d80a42cc926@xbt.hk> (raw)
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.
next reply other threads:[~2015-09-17 18:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-17 18:41 jl2012 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a50b82c156c805a284386d80a42cc926@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox