Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 86447122E for ; Thu, 17 Sep 2015 19:07:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 600A819D for ; Thu, 17 Sep 2015 19:07:54 +0000 (UTC) Received: by iofh134 with SMTP id h134so33005289iof.0 for ; Thu, 17 Sep 2015 12:07:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dL7qlWiVlOKz6gnXREnQfXTdgHJQhjqXcc7dAbO+Dbg=; b=L4XKXLWMIXLswxppaN9vWJa1eNuU8F4hjDtGN71Rfjq6QPqS68XfenJjwBuDRL1yEi RD9+7So9QM5onS4KVIFMuzOGP+rmRBIvC9NA3TTbaXrVdVrGXHcqB7wIEgHWw0QvRpPn LJCLVMgIm1u91kjP3dFKTWLLqBgDz6sfixUqPiv/+N/woTM/NYCEBSm1lE1kbjnEeDTX joyVMWYUqRBUUHGZWOAAMhkQlUgzT56PQdt3lo89WKP0CTXh1PhfLxjLrCjUXlbbvlNY AHc5xEsm3NJqWnDls4iIGWzyTxMn2DO2HDy1XzIQ48c0dqYbxrEmucuev1cHY0ZVa+fm 1d8g== X-Gm-Message-State: ALoCoQm3WJs4CvJkjHyHzC1EG+RtUenmhXIctpXtNOy5poenSI6c24w+ExB+aCS/RII/YePVzijQ X-Received: by 10.107.15.159 with SMTP id 31mr9945924iop.159.1442516873815; Thu, 17 Sep 2015 12:07:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.135.104 with HTTP; Thu, 17 Sep 2015 12:07:34 -0700 (PDT) X-Originating-IP: [184.162.86.160] In-Reply-To: References: From: Mark Friedenbach Date: Thu, 17 Sep 2015 15:07:34 -0400 Message-ID: To: jl2012@xbt.hk Content-Type: multipart/alternative; boundary=001a113ee868d8c140051ff621a0 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Fill-or-kill transaction X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 19:07:55 -0000 --001a113ee868d8c140051ff621a0 Content-Type: text/plain; charset=UTF-8 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 > --001a113ee868d8c140051ff621a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Note that this violates present assumptions about tra= nsaction validity, unless a constraint also exists that any output of such = an expiry block is not spent for at least 100 blocks.

Do you h= ave a clean way of ensuring this?

<= div class=3D"gmail_quote">On Thu, Sep 17, 2015 at 2:41 PM, jl2012 via bitco= in-dev <bitcoin-dev@lists.linuxfoundation.org><= /span> wrote:
Fill-or-kill tx is not a ne= w idea and is discussed in the Scaling Bitcoin workshop. In Satoshi's i= mplementation of nLockTime, a huge range of timestamp (from 1970 to 2009) i= s wasted. By exploiting this unused range and with compromise in the time r= esolution, 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 >=3D 1,474,562,04= 8 (2016-09-22)
720,001: Tx could be confirmed if the median time-past >=3D 1,474,564,09= 6 (2016-09-22)
.
.
1,853,010 (max): Tx could be confirmed if the median time-past >=3D 3,79= 4,966,528 (2090-04-04)

nKillTime (Range: 0-2047)
if nLockTime2 < 720,000, the tx could be confirmed at or before block (n= LockTime2 + nKillTime * 4)
if nLockTime2 >=3D 720,000, the tx could be confirmed if the median time= -past <=3D (nLockTime2 - 720,001 + nKillTime) * 2048

Finally, nLockTime =3D 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 =3D 20 and nKillTime =3D 100, a tx could be confirmed only = between block 420,080 and 420,480
With nLockTime2 =3D 730,000 and nKillTime =3D 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 =3D 500,000,000 + nKillTime + nLockTime2 *= 2048

For height based nLockTime2 (<=3D 719,999)

For nLockTime2 =3D 0 and nKillTime =3D 0, nLockTime =3D 500,000,000, which = means the tx could be confirmed after 1970-01-01 with the original lock tim= e 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 =3D 719,999 and nKillTime =3D 2047, nLockTime =3D 1,974,559,9= 99, which means 2016-09-22. However, the new rule will not allow confirmati= on until block 3,299,996 which is decades to go



For time based nLockTime2 (> 720,000)

For nLockTime2 =3D 720,000 and nKillTime =3D 0, nLockTime =3D 1,974,560,000= , which means the tx could be confirmed after median time-past 1,474,560,00= 0 (assuming BIP113). However, the new rule will not allow confirmation unti= l 1,474,562,048, therefore a soft fork.

For nLockTime2 =3D 720,000 and nKillTime =3D 2047, nLockTime =3D 1,974,562,= 047, which could be confirmed at 1,474,562,047. Again, the new rule will no= t allow confirmation until 1,474,562,048. The 1 second difference makes it = a soft fork.

Actually, for every nLockTime2 value >=3D 720,000, the lock time with th= e new rule must be 1-2048 seconds later than the original rule.

For nLockTime2 =3D 1,853,010 and nKillTime =3D 2047, nLockTime =3D 4,294,96= 6,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 n= KillTime =3D 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 ge= ts into another block. He will set nLockTime2 =3D 210,000 and nKillTime =3D= 0

----------------
OP_CLTV

Time-based OP_CLTV could be upgraded to support time-based nLockTime2. Howe= ver, height-based OP_CLTV is not compatible with nLockTime2. To spend a hei= ght-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/mail= man/listinfo/bitcoin-dev

--001a113ee868d8c140051ff621a0--