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 064A318A6 for ; Sat, 3 Oct 2015 14:31:07 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149056.authsmtp.com (outmail149056.authsmtp.com [62.13.149.56]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 56DAC24C for ; Sat, 3 Oct 2015 14:31:06 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t93EV4rD008413 for ; Sat, 3 Oct 2015 15:31:05 +0100 (BST) Received: from muck (port-87-193-173-182.static.qsc.de [87.193.173.182]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t93EV1u3038945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 3 Oct 2015 15:31:03 +0100 (BST) Date: Sat, 3 Oct 2015 16:30:56 +0200 From: Peter Todd To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20151003143056.GA27942@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline X-Server-Quench: 60192dfe-69db-11e5-b39a-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hyKltILEZaQVBf Ri5dBBEKBAw1ADwr dVUTOktdYVUxDEF1 UkhIR0JTEQ9rABYB BVAWVQdzfgZYeXlz e0dqXG9eVENldAg5 S00hc2xDZmdjYGkb VQ5bcQJXPgVKfxZH PgYqSXUENTcaZ3s1 Qko5ZGE4eG0HcnkE GghUcF4bHlAgPhMX ZCsvJAgCO2YoeQgJ DjIXYhtUI0tZNEg/ PRMkXkgVewIJBwZX BExWSDNeb1wGWys1 BB9XFVIeHXVWQS5a DRBA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 87.193.173.182/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. 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 Subject: [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 14:31:07 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. --=20 'peter'[:-1]@petertodd.org 00000000000000000ea95b4a24d0a510d4b5a98186f904dc16da07c41189d8b8 --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWD+adXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwZWE5NWI0YTI0ZDBhNTEwZDRiNWE5ODE4NmY5MDRkYzE2 ZGEwN2M0MTE4OWQ4YjgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udwmzAf/b1NtKnXWL448NnQZasJh6+uH 4tyYOp6BhNUAXxpN8ZR2WLjrUSYDsh6gAily5fM5dW+zsmoBoHt5dJ0QzgQoJ+p1 zQ+BzXZo+L12xCtntMqr13ZZTmQWVFSGU+zhdpuQ6QZ6iepjEmw8tMF86Z6bMykN fRFWF0c9mYyrSLa1RxUNxw3qWFOH9Jroy83XonkL6uj4LeZsVd4vB/jSsRsq+qX0 HJX/abu0MdEUVKPm3Hp5n5MKPzEnufJGRtRjZoN8F3Ok1+Jl6Ox6C5iyNE12MJsd ufv/O+LOIDDobtBCkfBYu4nrXS0kiep7pIf+OqX9SuTRsmOMosqI2wiSJwSLBw== =O9ap -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS--