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 B7BE21BB for ; Tue, 24 Nov 2015 04:36:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148113.authsmtp.com (outmail148113.authsmtp.com [62.13.148.113]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id E262A164 for ; Tue, 24 Nov 2015 04:36:26 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tAO4aPkq084643 for ; Tue, 24 Nov 2015 04:36:25 GMT Received: from muck (us2x.mullvad.net [173.254.196.27]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tAO4aI6M072539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 24 Nov 2015 04:36:23 GMT Date: Mon, 23 Nov 2015 23:36:18 -0500 From: Peter Todd To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20151124043618.GA7999@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline X-Server-Quench: eb8a25d1-9264-11e5-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hyKltILEZaQVBf Ri5dBBEKBAw1ADwr dVUTOktfZlUwAEN1 UkhIR0JSEA9rBxYD A1AfVRpsdQBCZn95 Y1hgWW9eVENldAg5 MzFQRBQAGGdnamUc WQ5bfgtcPlYYdk5H bwR+SXoPZ2EaZ3s1 QkpjZWE8eG0HcXkM HVBQIQ9PH1AhPwZi F0JKJjgkGksJAiE+ MREiYlEGFUAMNkwo MEcwEV4fPgQURREW GkhODWdCKl8aSkIA X-Authentic-SMTP: 61633532353630.1037:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 173.254.196.27/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] BIP68: Second-level granularity doesn't make sense 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: Tue, 24 Nov 2015 04:36:27 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable BIP68 currently represents by-height locks as a simple 16-bit integer of the number of blocks - effectively giving a granularity of 600 seconds on average - but for for by-time locks the representation is a 25-bit integer with granularity of 1 second. However this granularity doesn't make sense with BIP113, median time-past as endpoint for lock-time calcualtions, and poses potential problems for future upgrades. There's two cases to consider here: 1) No competing transactions By this we mean that the nSequence field is being used simply to delay when an output can be spent; there aren't competing transactions trying to spend that output and thus we're not concerned about one transaction getting mined before another "out of order". For instance, an 2-factor escrow service like GreenAddress could use nSequence with CHECKSEQUENCEVERIFY (CSV) to guarantee that users will eventually get their funds back after some timeout. In this use-case exact miner behavior is irrelevant. Equally given the large tolerances allowed on block times, as well as the poisson distribution of blocks generated, granularity below an hour or two doesn't have much practical significance. 2) Competing transactions Here we are relying on miners prefering lower sequence numbers. For instance a bidirectional payment channel can decrement nSequence for each change of direction; BIP68 suggests such a decrement might happen in increments of one day. BIP113 makes lock-time calculations use the median time-past as the threshold for by-time locks. The median time past is calculated by taking median time of the 11 previous blocks, which means when a miner creates a block they have absolutely no control over what the median time-past is; it's purely a function of the block tip they're building upon. This means that granularity below a block interval will, on average, have absolutely no effect at all on what transaction the miner includes even in the hypothetical case. In practice of course, users will want to use significantly larger than 1 block interval granularity in protocols. The downside of BIP68 as written is users of by-height locktimes have 14 bits unused in nSequence, but by-time locktimes have just 5 bits unused. This presents an awkward situation if we add new meanings to nSequence if we ever need more than 5 bits. Yet as shown above, the extra granularity doesn't have a practical benefit. Recommendation: Change BIP68 to make by-time locks have the same number of bits as by-height locks, and multiply the by-time lock field by the block interval. --=20 'peter'[:-1]@petertodd.org 000000000000000001a06d85a46abce495fd793f89fe342e6da18b235ade373f --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWU+k/XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwMWEwNmQ4NWE0NmFiY2U0OTVmZDc5M2Y4OWZlMzQyZTZk YTE4YjIzNWFkZTM3M2YvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udyOoAgAgqrpuo6Vpg9YxBp6JTlb9zAN /nQ4LZgwuU4sYuZoMc/LD7kcla9SBlVorTjax4AaH3lEtO/p0bunD0RIgWCq02D0 OHnKYag3gffKRr2OC87XZ+h6EI6babTclz0T8b/WDJTgObHGqv2I3TyEXsWLI8QG HjMGwj4rIkQK2EMq7SirAfTTV5PwsGFP4SGhTC6QTzaG2LDZfgWaiBi++uBcrJK7 asc9+0Rn/v4/21uxJP3QY31SUh+QQ9Zzl+N4oU19vypKeHYc1KEbgLUcF4hx9elb z/H9Qw9uKO+CyYoqn2dQVPovXkW3y79O42/tWP9Hw4nL3E5H/J72rUt84+JSWA== =VObD -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb--