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 994F7166F for ; Sat, 3 Oct 2015 18:49:22 +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 131378C for ; Sat, 3 Oct 2015 18:49:21 +0000 (UTC) Received: from localhost ([::1]:34716 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZiRs0-0013p1-Ne; Sat, 03 Oct 2015 14:49:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sat, 03 Oct 2015 14:49:20 -0400 From: jl2012@xbt.hk To: Peter Todd In-Reply-To: <20151003143056.GA27942@muck> References: <20151003143056.GA27942@muck> Message-ID: 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 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: Sat, 03 Oct 2015 18:49:22 -0000 BIP68 allows per-input locktime, though I don't know how this could be useful. BIP68 and BIP112 are mostly ready. If we try to reimplement relative-locktime without using nSequence, we may need to wait for another year for deployment. A compromise is to make BIP68 optional, indicated by a bit in tx nVersion, as I suggested earlier (1). This will allow deploying relative-locktime without further delay while not permanently limiting future upgrades. (1) http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html Peter Todd via bitcoin-dev 於 2015-10-03 10:30 寫到: > BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics, > which can be summarized conceptually as a relative CHECKLOCKTIMEVERIFY. > However, CSV does define behavior for the previously undefined > nSequence > field, which is the only "free-form" field we currently have in the > transaction serialization format that can be used for future upgrades - > we should justify this new behavior carefully as it limits our options > in the future. Adding new fields to the serialization format is very > difficult, due to the very broad system-wide impact of the hard-fork > required to do so. > > So we need to make the case for two main things: > > 1) We have applications that need a relative (instead of absolute CLTV) > > 2) Additionally to RCLTV, we need to implement this via nSequence > > To show we need RCLTV BIP112 provides the example "Escrow with > Timeout", > which is a need that was brought up by GreenAddress, among others; I > don't think we have an issue there, though getting more examples would > be a good thing. (the CLTV BIP describes seven use cases, and one > additional future use-case) > > However I don't think we've done a good job showing why we need to > implement this feature via nSequence. BIP68 describes the new nSequence > semantics, and gives the rational for them as being a > "Consensus-enforced tx replacement" mechanism, with a bidirectional > payment channel as an example of this in action. However, the > bidirectional payment channel concept itself can be easily implemented > with CLTV alone. There is a small drawback in that the initial > transaction could be delayed, reducing the overall time the channel > exists, but the protocol already assumes that transactions can be > reliably confirmed within a day - significantly less than the proposed > 30 days duration of the channel. That example alone I don't think > justifies a fairly complex soft-fork that limits future upgrades; we > need more justification. > > So, what else can the community come up with? nSequence itself exists > because of a failed feature that turned out to not work as intended; > it'd be a shame to make that kind of mistake again, so let's get our > semantics and use-cases in the BIPs and documented before we deploy. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev