summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorjl2012 <jl2012@xbt.hk>2015-09-17 03:43:02 -0400
committerbitcoindev <bitcoindev@gnusha.org>2015-09-17 07:43:05 +0000
commit80324a759d6dd15a84d2e8a57f85e774fe2fb09f (patch)
tree5d3e8d6efec063b9febe9f78778006a2086a2fb1
parentfb1b725a5fca56a89a91f1692a4ac2bd5de63be7 (diff)
downloadpi-bitcoindev-80324a759d6dd15a84d2e8a57f85e774fe2fb09f.tar.gz
pi-bitcoindev-80324a759d6dd15a84d2e8a57f85e774fe2fb09f.zip
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
-rw-r--r--6b/fc9eaa7f96e2ffe886f54ca71e76e819223913184
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
+
+