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 6D54C7D for ; Tue, 18 Aug 2015 01:22:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F1B92F2 for ; Tue, 18 Aug 2015 01:22:14 +0000 (UTC) Received: by wicja10 with SMTP id ja10so82706391wic.1 for ; Mon, 17 Aug 2015 18:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=wVhNar0mlJO6TRy2WBeF9BIQ26PrEEk6GPeJoDko+4Y=; b=Izzwu0lEZ7EEb8jU0nLUOL/Ge7DEtXyflkXzfFB+Ap6TW4NUf7kIgp1Z+0o/WUxXHF WFvWNU76AqwJt+iVaF5uPKJ9mawTx+0JlWXqvQ3g9d0ZqHJhbJUMrbrK2ZnLK40BlPCA O0+FkqaN/VR8GbJyEVff9Z1N+9VyLxGVY2dTeNSAbg2PoteWcN/r9vFMq+vDtR0dn1o5 EMdxY/YGIHSYV5KrjUpDpIgbr0IOE06o55pOk6iy+Ix4WmAuB//IFIrT/VVHmY/c2rkZ MzvV4/9+BoJLyBWpr0mhnvBWYgmt44mi3WsrgdMpm0iLsAaD9gCMNf8MlqyY2/jiRsHg TGiA== X-Received: by 10.180.215.8 with SMTP id oe8mr17665564wic.0.1439860932068; Mon, 17 Aug 2015 18:22:12 -0700 (PDT) Received: from [192.168.192.10] ([89.100.54.204]) by smtp.gmail.com with ESMTPSA id gj6sm19017511wib.22.2015.08.17.18.22.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2015 18:22:11 -0700 (PDT) Message-ID: <55D288C2.9020207@gmail.com> Date: Tue, 18 Aug 2015 02:22:10 +0100 From: Thomas Kerin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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] BIP: Using Median time-past as endpoint for locktime calculations 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, 18 Aug 2015 01:22:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all, In collaboration with Mark Friedenbach, we have drawn up a proposal for using the median time of the past 11 blocks in locktime calculations. 
  BIP: XX
  Title: Median time-past as endpoint for lock-time calculations
  Author: Thomas Kerin 
          Mark Friedenbach    =20
  Status: Draft
  Type: Standards Track
  Created: 2015-08-10
=3D=3DAbstract=3D=3D This BIP is a proposal to redefine the semantics used in determining a time-locked transaction's eligibility for inclusion in a block. The median of the last 11 blocks is used instead of the block's timestamp, ensuring that it increases monotonically with each block. =3D=3DMotivation=3D=3D At present, transactions are excluded from inclusion in a block if the present time or block height is less than or equal to that specified in the locktime. Since the consensus rules do not mandate strict ordering of block timestamps, this has the unfortunate outcome of creating a perverse incentive for miners to lie about the time of their blocks in order to collect more fees by including transactions that by wall clock determination have not yet matured. This BIP proposes comparing the locktime against the median of the past 11 block's timestamps, rather than the timestamp of the block including the transaction. Existing consensus rules guarantee this value to monotonically advance, thereby removing the capability for miners to claim more transaction fees by lying about the timestamps of their block. This proposal seeks to ensure reliable behaviour in locktime calculations= as required by BIP65, BIP68, and BIPXX (OP_CHECKSEQUENCEVERIFY). =3D=3DSpecification=3D=3D The values for transaction locktime remain unchanged. The difference is only in the calculation determining whether a transaction can be included. Instead of an unreliable timestamp, the following function is used to determine the current block time for the purpose of checking lock-time constraints: enum { nMedianTimeSpan=3D11 }; =20 int64_t GetMedianTimePast(const CBlockIndex* pindex) { int64_t pmedian[nMedianTimeSpan]; int64_t* pbegin =3D &pmedian[nMedianTimeSpan]; int64_t* pend =3D &pmedian[nMedianTimeSpan]; for (int i =3D 0; i < nMedianTimeSpan && pindex; i++, pindex =3D pindex->pprev) *(--pbegin) =3D pindex->GetBlockTime(); std::sort(pbegin, pend); return pbegin[(pend - pbegin)/2]; } Lock-time constraints are checked by the consensus method IsFinalTx(), or LockTime() under BIP68. These methods take the block time as one parameter. This BIP proposes that after activation calls to IsFinalTx() or LockTime() within consensus code use the return value of `GetMedianTimePast(pindexPrev)` instead. A reference implementation of this proposal is provided in the following git repository: https://github.com/maaku/bitcoin/tree/medianpasttimelock =3D=3DDeployment=3D=3D We reuse the double-threshold switchover mechanism from BIPs 34 and 66, with the same thresholds, but for block.nVersion =3D 4. The new rules are in effec= t for every block (at height H) with nVersion =3D 4 and at least 750 out of 100= 0 blocks preceding it (with heights H-1000...H-1) also have nVersion =3D 4. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion =3D 4,= nVersion =3D 3 blocks become invalid, and all further blocks enforce the new rules. It is recommended that this soft-fork deployment trigger include other related proposals for improving Bitcoin's lock-time capabilities, such as BIP 65, BIP68 and CHECKSEQUENCEVERIFY. =3D=3DAcknowledgements=3D=3D Mark Friedenbach for designing and authoring the reference implementation of this BIP. Thomas Kerin authored this BIP document. =3D=3DCompatibility=3D=3D Transactions generated using time-based lock-time will take approximately an hour longer to confirm than would be expected under the old rules. This is not known to introduce any compatibility concerns with existing protocols. =3D=3DReferences=3D=3D [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: OP_CHECKLOCKTIMEVERIFY] [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement signaled via sequence numbers]= [https://github.com/bitcoin/bips/blob/master/bip-00.mediawiki BIPXX: CHECKSEQUENCEVERIFY] =3D=3DCopyright=3D=3D This document is placed in the public domain. - --=20 My PGP key can be found here: -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJV0oi8AAoJEAiDZR291eTl2soP/1MOjgQDncoUdMptqfeqMLfU ewENNPLQwXXje7PFn/gIVa+Ghxu+f9rrRHt6v8Udd4wsnDTqhz2gV6dKCyF0K4IS seLTH2kyTfPGm1KOp6WSwvxoyc5iWLBH4wkSm4oI9WmXkLzDq0yEYUDE8t9yNYwf 0Fgrg1KPIP4bhoxWchEa237rrH/qTh0Zdxdj/N0YCrX9u4fBy+xoTM6gnt0bFCK2 SaGXvC8PsA23gkJjjwFnWh/JU0Q5BJTElUsq1re3gmwcnLNKyB5cx0bFephk2pFd NC3rqEIIVPd7aLs+lWmD4/NXdm+VtUEQo3MmQ1YW5zwjeoJxZhfMfXwmQw3vw2f7 FSyExUXNNwh2lMoLCcWvWWEOKYaSV9iLX4TacvpbOSDQgz3rDl3iqeLmSgp3S8M3 Se1S9AzilJsT0jIe2Ob2hu/gXEXeBmI9k2kRJELSaIFgCWadUky63NwNNfRipiBq USroBIym2dpXFLygcwgwf6F/yAYYg6/5QiUKclhqvxArxVEcijw18SHGZVYpW83S Q0mzJnRVGF7yscJl84zHyAj5QMWoMFgKSqFbOLcmNDUPLoaFJxAGezGCLXNaHinA LY5Qp0t0Vg4hXi6QcCiWv2U8E1K4oN5VZNSlagUyXsAHd3c4icZTVj+TTWKJ7GLB Gmbe3i9G90rpgDbHWXFq =3DEQdY -----END PGP SIGNATURE-----