diff options
author | jl2012 <jl2012@xbt.hk> | 2015-09-17 03:43:02 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-09-17 07:43:05 +0000 |
commit | 80324a759d6dd15a84d2e8a57f85e774fe2fb09f (patch) | |
tree | 5d3e8d6efec063b9febe9f78778006a2086a2fb1 | |
parent | fb1b725a5fca56a89a91f1692a4ac2bd5de63be7 (diff) | |
download | pi-bitcoindev-80324a759d6dd15a84d2e8a57f85e774fe2fb09f.tar.gz pi-bitcoindev-80324a759d6dd15a84d2e8a57f85e774fe2fb09f.zip |
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
-rw-r--r-- | 6b/fc9eaa7f96e2ffe886f54ca71e76e819223913 | 184 |
1 files changed, 184 insertions, 0 deletions
diff --git a/6b/fc9eaa7f96e2ffe886f54ca71e76e819223913 b/6b/fc9eaa7f96e2ffe886f54ca71e76e819223913 new file mode 100644 index 000000000..09f72af5b --- /dev/null +++ b/6b/fc9eaa7f96e2ffe886f54ca71e76e819223913 @@ -0,0 +1,184 @@ +Return-Path: <jl2012@xbt.hk> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 56A63143C + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 17 Sep 2015 07:43:05 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 60AD0AF + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 17 Sep 2015 07:43:04 +0000 (UTC) +Received: from localhost ([::1]:32904 helo=server47.web-hosting.com) + by server47.web-hosting.com with esmtpa (Exim 4.85) + (envelope-from <jl2012@xbt.hk>) + id 1ZcTqQ-0016Jq-SR; Thu, 17 Sep 2015 03:43:02 -0400 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8; + format=flowed +Content-Transfer-Encoding: 8bit +Date: Thu, 17 Sep 2015 03:43:02 -0400 +From: jl2012@xbt.hk +To: Mark Friedenbach <mark@friedenbach.org> +In-Reply-To: <CAOG=w-tuFtX2t+0FVfkoObw_a9-7j4LwX87YJU1n7adYu=DMdQ@mail.gmail.com> +References: <CADJgMztgE_GkbrsP7zCEHNPA3P6T=aSFfhkcN-q=gVhWP0vKXg@mail.gmail.com> + <CADJgMzv8G3EqLBwEYRHJZ+fO_Jwzy0koi2pJ_iNRkXmoVarGcg@mail.gmail.com> + <CABm2gDod9z6ksgaCv86qFCyKLTQSL3+oNns+__5H77hVhs05DQ@mail.gmail.com> + <CAOG=w-sbOcaogkic2i4A5eZnBQ79LUibsGy0dyKyvQg53ktY1Q@mail.gmail.com> + <55DA6470.9040301@thinlink.com> + <CAAS2fgQKQpHu-nC1uSrigDx2JLUt64p-LqidVmiuULDE0MJCFQ@mail.gmail.com> + <CABm2gDqW7OGuyZ1BTTeeivDf9wFVsAK9AaGYm8XWwLb2O2Lb+g@mail.gmail.com> + <CAOG=w-ubk3nPfxy25Hd6kPeehf7vnYD5chksLWU5wU2t=jL5TA@mail.gmail.com> + <CAOG=w-to4Vrx4ykKJTy5EAyN4GZd6Q=G5FzqZH-5J3Thz_VNpQ@mail.gmail.com> + <CAOG=w-tuFtX2t+0FVfkoObw_a9-7j4LwX87YJU1n7adYu=DMdQ@mail.gmail.com> +Message-ID: <52804bf0fb44a77efb3610e6bdf978e4@xbt.hk> +X-Sender: jl2012@xbt.hk +User-Agent: Roundcube Webmail/1.0.5 +X-AntiAbuse: This header was added to track abuse, + please include it with any abuse report +X-AntiAbuse: Primary Hostname - server47.web-hosting.com +X-AntiAbuse: Original Domain - lists.linuxfoundation.org +X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] +X-AntiAbuse: Sender Address Domain - xbt.hk +X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: + jl2012@xbt.hk +X-Source: +X-Source-Args: +X-Source-Dir: +X-From-Rewrite: unmodified, already matched +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for + relative locktime +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 17 Sep 2015 07:43:05 -0000 + +How many years of relative lock time do we need? It really depends why +we need a relative lock time in the first place, what what does it offer +in addition to CHECKLOCKTIMEVERIFY. The only case I know is when the +confirmation taking too long, CLTV may expire before the tx is +confirmed. For use case like this, 1 year of relative lock time is much +more than enough, since Bitcoin is basically worthless if it takes +months to confirm a tx with a reasonable fee. + +Is there any other use case of CSV that is irreplaceable by CLTV? There +is only one example in the BIP CSV draft. + +For the timebased relative lock time, 256 seconds of granularity is more +than enough since the block interval is 600s. Although it is not +impossible to reduce the block interval in the future, that will be a +hardfork anyway and we may just hardfork BIP68/CSV at the same time. + + + +Mark Friedenbach via bitcoin-dev 於 2015-08-27 19:32 寫到: +> So I've created 2 new repositories with changed rules regarding +> sequencenumbers: +> +> https://github.com/maaku/bitcoin/tree/sequencenumbers2 [2] +> +> This repository inverts (un-inverts?) the sequence number. nSequence=1 +> means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means +> 1 second relative lock-height. nSequence>=0x80000000 (most significant +> bit set) is not interpreted as a relative lock-time. +> +> https://github.com/maaku/bitcoin/tree/sequencenumbers3 [3] +> +> This repository not only inverts the sequence number, but also +> interprets it as a fixed-point number. This allows up to 5 year +> relative lock times using blocks as units, and saves 12 low-order bits +> for future use. Or, up to about 2 year relative lock times using +> seconds as units, and saves 4 bits for future use without second-level +> granularity. More bits could be recovered from time-based locktimes by +> choosing a higher granularity (a soft-fork change if done correctly). +> +> On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach +> <mark@friedenbach.org> wrote: +> +>> To follow up on this, let's say that you want to be able to have up +>> to 1 year relative lock-times. This choice is somewhat arbitrary and +>> what I would like some input on, but I'll come back to this point. +>> +>> * 1 bit is necessary to enable/disable relative lock-time. +>> +>> * 1 bit is necessary to indicate whether seconds vs blocks as the +>> unit of measurement. +>> +>> * 1 year of time with 1-second granularity requires 25 bits. +>> However since blocks occur at approximately 10 minute intervals on +>> average, having a relative lock-time significantly less than this +>> interval doesn't make much sense. A granularity of 256 seconds would +>> be greater than the Nyquist frequency and requires only 17 bits. +>> +>> * 1 year of blocks with 1-block granularity requires 16 bits. +>> +>> So time-based relative lock time requires about 19 bits, and +>> block-based relative lock-time requires about 18 bits. That leaves +>> 13 or 14 bits for other uses. +>> +>> Assuming a maximum of 1-year relative lock-times. But what is an +>> appropriate maximum to choose? The use cases I have considered have +>> only had lock times on the order of a few days to a month or so. +>> However I would feel uncomfortable going less than a year for a hard +>> maximum, and am having trouble thinking of any use case that would +>> require more than a year of lock-time. Can anyone else think of a +>> use case that requires >1yr relative lock-time? +>> +>> TL;DR +>> +>> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach +>> <mark@friedenbach.org> wrote: +>> +>> A power of 2 would be far more efficient here. The key question is +>> how long of a relative block time do you need? Figure out what the +>> maximum should be ( I don't know what that would be, any ideas?) and +>> then see how many bits you have left over. +>> +>> On Aug 23, 2015 7:23 PM, "Jorge Timón" +>> <bitcoin-dev@lists.linuxfoundation.org> wrote: +>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev +>> <bitcoin-dev@lists.linuxfoundation.org> wrote: +>>> Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the +>>> discussion has any thought been given to represent one block with +>> more +>>> than one increment? This would leave additional space for future +>>> signaling, or allow, for example, higher resolution numbers for a +>>> sharechain commitement. +>> +>> No, I don't think anybody thought about this. I just explained this +>> to +>> Pieter using "for example, 10 instead of 1". +>> He suggested 600 increments so that it is more similar to +>> timestamps. +>> _______________________________________________ +>> bitcoin-dev mailing list +>> bitcoin-dev@lists.linuxfoundation.org +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1] +> +> +> +> Links: +> ------ +> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> [2] https://github.com/maaku/bitcoin/tree/sequencenumbers2 +> [3] https://github.com/maaku/bitcoin/tree/sequencenumbers3 +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + + |