From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2D4B7117B for ; Thu, 17 Sep 2015 19:12:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 05CAD19E for ; Thu, 17 Sep 2015 19:12:28 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so3766239wic.1 for ; Thu, 17 Sep 2015 12:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=G8ULjlxo7LEv77jULYcbvh0r6FriY9BpOUayyRU2Ajk=; b=PFCYTeFfIw/K2EMOxQcz2QOYZagFMQkyraix5rQUbLA294VKRdYh7Ar9qz6hA3m4lV +1R1QXBLHQhmAXHtog1gztlNH04zwRqIrnWXhcz40fMvsW+p8CeZjDxV2lEJI4oatnag 7XALGLZenyITkes7pkrU1ECeNoIbWCsaxro5XnAmFi2ZH/DIQZ4jFKTOHAs1QzAkAdj0 pWV/+Bbd/UFdkiCJ4zkY+04XHGM5KCWnXgCCvR3p49K8MS8/KGybKfE6jzQWLjzsh+VR rRAk0A1/ADGtBqDGrrJCpGRHoCNjoSRwdSrvgSHBxWFwxsCceZyDRzTjPtPJf3jAvmyv RKVA== X-Received: by 10.194.174.227 with SMTP id bv3mr1500091wjc.142.1442517147629; Thu, 17 Sep 2015 12:12:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.21.200 with HTTP; Thu, 17 Sep 2015 12:12:08 -0700 (PDT) In-Reply-To: References: From: Btc Drak Date: Thu, 17 Sep 2015 20:12:08 +0100 Message-ID: To: jl2012@xbt.hk Content-Type: multipart/alternative; boundary=089e013d0f9a2abefd051ff632b4 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=no 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:12:30 -0000 --089e013d0f9a2abefd051ff632b4 Content-Type: text/plain; charset=UTF-8 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 > --089e013d0f9a2abefd051ff632b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Forgive me if I have missed the exact use-case, but this s= eems overly complex. Surely fill-or-kill refers to getting a transaction co= nfirmed 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 s= mall 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-de= v <bitcoin-dev@lists.linuxfoundation.org> wrote:
Fill-or-kill tx is not a new ide= a and is discussed in the Scaling Bitcoin workshop. In Satoshi's implem= entation of nLockTime, a huge range of timestamp (from 1970 to 2009) is was= ted. By exploiting this unused range and with compromise in the time resolu= tion, 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

--089e013d0f9a2abefd051ff632b4--