Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6906FF46 for ; Thu, 17 Sep 2015 19:14:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 18DEB19E for ; Thu, 17 Sep 2015 19:14:40 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so3877924wic.0 for ; Thu, 17 Sep 2015 12:14:38 -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:date :message-id:subject:from:to:cc:content-type; bh=GOCMr9+cVy1uGDNbpw+eBjpbmWPe45gTYTdZv2MEdv0=; b=gjWcmxWW4yPtEM/h0MaaPf131+YA0ziQPK3h0Zmy0nWldwawp/+Mwh2AbZYMmSCY37 uBAhtH3eQ1YGqP2yI8O/yai9qPp7wsSxZId3ogy441fG1NYR50YqDedgvkbI2u1Y3vtx nadBfZx++cxVM016MM/ubwGYbykFzd6NYlPKFhaIJqtGn3e/TgfLN5pvDW5mFFEv3usL zItmDpnghKUJYD1Wc9+MF8ttGozCPekUfF/5g46762AaTGKKMiHBn2Su8Zz1U2wuGhw2 NSzZZtINeOEww+WgIQqrVSob/vL+J5M0tyRhFS9kEa9OqQM5QHdQrHWZxtDVHnlxooG4 Z3Sg== X-Gm-Message-State: ALoCoQkzBK6qMwNIjZtct2p9MTUNVYfO1BOeLuHrkwyHwkWl55OD2sWGPlj2jzMnahVUzrlInNtc MIME-Version: 1.0 X-Received: by 10.194.238.39 with SMTP id vh7mr1349419wjc.109.1442517278819; Thu, 17 Sep 2015 12:14:38 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Thu, 17 Sep 2015 12:14:38 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Thu, 17 Sep 2015 12:14:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Sep 2015 21:14:38 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Mark Content-Type: multipart/alternative; boundary=089e0141aa1afcd58d051ff639b4 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:14:41 -0000 --089e0141aa1afcd58d051ff639b4 Content-Type: text/plain; charset=UTF-8 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 > > --089e0141aa1afcd58d051ff639b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 a= ll the outputs of a transaction that can expire have op_maturity/csv/rcltv = of 100. That makes them as reorg-safe as coinbase transactions. Unfortunate= ly 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 th= is violates present assumptions about transaction validity, unless a constr= aint also exists that any output of such an expiry block is not spent for a= t least 100 blocks.

Do you have a clean way of ensuring this?<= br>

On Thu, = Sep 17, 2015 at 2:41 PM, jl2012 via bitcoin-dev <bitco= in-dev@lists.linuxfoundation.org> wrote:
Fill-or-kill tx is not a new idea and is discussed in the Sca= ling Bitcoin workshop. In Satoshi's implementation of nLockTime, a huge= range of timestamp (from 1970 to 2009) is wasted. By exploiting this unuse= d range and with compromise in the time resolution, a fill-or-kill system c= ould 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


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--089e0141aa1afcd58d051ff639b4--