public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations
@ 2015-08-18  1:22 Thomas Kerin
  2015-08-19  1:04 ` Peter Todd
  0 siblings, 1 reply; 25+ messages in thread
From: Thomas Kerin @ 2015-08-18  1:22 UTC (permalink / raw)
  To: bitcoin-dev


-----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.

<pre>
  BIP: XX
  Title: Median time-past as endpoint for lock-time calculations
  Author: Thomas Kerin <me@thomaskerin•io>
          Mark Friedenbach <mark@friedenbach•org>    
  Status: Draft
  Type: Standards Track
  Created: 2015-08-10
</pre>


==Abstract==

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.


==Motivation==

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).


==Specification==

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=11 };
    
    int64_t GetMedianTimePast(const CBlockIndex* pindex)
    {
        int64_t pmedian[nMedianTimeSpan];
        int64_t* pbegin = &pmedian[nMedianTimeSpan];
        int64_t* pend = &pmedian[nMedianTimeSpan];
        for (int i = 0; i < nMedianTimeSpan && pindex; i++, pindex =
pindex->pprev)
             *(--pbegin) = 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


==Deployment==

We reuse the double-threshold switchover mechanism from BIPs 34 and 66,
with the
same thresholds, but for block.nVersion = 4. The new rules are in effect for
every block (at height H) with nVersion = 4 and at least 750 out of 1000
blocks
preceding it (with heights H-1000...H-1) also have nVersion = 4.
Furthermore,
when 950 out of the 1000 blocks preceding a block do have nVersion = 4,
nVersion = 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.


==Acknowledgements==

Mark Friedenbach for designing and authoring the reference
implementation of this BIP.

Thomas Kerin authored this BIP document.


==Compatibility==

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.


==References==
[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]


==Copyright==

This document is placed in the public domain.




- -- 
My PGP key can be found here: <https://thomaskerin.io/me.pub.asc>
-----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
=EQdY
-----END PGP SIGNATURE-----




^ permalink raw reply	[flat|nested] 25+ messages in thread
* [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners
@ 2015-08-19  5:50 Peter Todd
  2015-08-19  6:10 ` Mark Friedenbach
  2015-08-20 17:32 ` jl2012
  0 siblings, 2 replies; 25+ messages in thread
From: Peter Todd @ 2015-08-19  5:50 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 4744 bytes --]

Deployment of the proposed CLTV, CSV, etc. soft-forks has been recently
complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners. Both
mine blocks with nVersion=0x20000007, which would falsely trigger the
previously suggested implementation using the IsSuperMajority()
mechanism and nVersion=4 blocks. Additionally while the
XT/Not-Bitcoin-XT software claims to support Wuille/Todd/Maxwell's
nVersion soft-fork mechanism(3) a key component of it - fork
deadlines(3) - is not implemented.


XT/Not-Bitcoin-XT behavior
--------------------------

Both implementations produce blocks with nVersion=0x20000007,
or in binary: 0b001...111

Neither implementation supports a fork deadline; both Not-Bitcoin-XT and
XT will produce blocks with those bits set indefinitely under any
circumstance, with the proviso that while XT has a hashing power
majority, blocks it produces might not be part of the Bitcoin blockchain
after Jan 11th 2016. (though this can flap back and forth if reorgs
happen)

Curiously the BIP101 draft was changed(4) at the last minute from using
the nVersion bits compliant 0x20000004 block nVersion, to using two more
bits unnecessarily. The rational for doing this is unknown; the git
commit message associated with the change suggested "compatibility
concerns", but what the concerns actually were isn't specified. Equally
even though implementing the fork deadline would be very each in the XT
implementation, this was not done. (the XT codebase has had almost no
peer review)


Options for CLTV/CSV/etc. deployment
------------------------------------

1) Plain IsSuperMajority() with nVersion=4

This option can be ruled out immediately due to the high risk of
premature triggering, without genuine 95% miner support.


2) nVersion mask, with IsSuperMajority()

In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would
be masked away, prior to applying standard IsSuperMajority() logic:

    block.nVersion & ~0x20000007

This means that CLTV/CSV/etc. miners running Bitcoin Core would create
blocks with nVersion=8, 0b1000. From the perspective of the
CLTV/CSV/etc.  IsSuperMajority() test, XT/Not-Bitcoin-XT miners would be
advertising blocks that do not trigger the soft-fork.

For the perpose of soft-fork warnings, the highest known version can
remain nVersion=8, which is triggered by both XT/Not-Bitcoin-XT blocks
as well as a future nVersion bits implementation. Equally,
XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an
unknown bit set.

When nVersion bits is implemented by the Bitcoin protocol, the plan of
setting the high bits to 0b001 still works. The three lowest bits will
be unusable for some time, but will be eventually recoverable as
XT/Not-Bitcoin-XT mining ceases.

Equally, further IsSuperMajority() softforks can be accomplished with
the same masking technique.

This option does complicate the XT-coin protocol implementation in the
future. But that's their problem, and anyway, the maintainers
(Hearn/Andresen) has strenuously argued(5) against the use of soft-forks
and/or appear to be in favor of a more centralized mandatory update
schedule.(6)


3) Full nVersion bits implementation

The most complex option would be to deploy via full nVersion bits
implementation using flag bit #4 to trigger the fork. Compliant miners
would advertise 0x20000008 initially, followed by 0x20000000 once the
fork had triggered. The lowest three bits would be unusable for forks
for some time, although they could be eventually recovered as
XT/Not-Bitcoin-XT mining ceases.

The main disadvantage of this option is high initial complexity - the
reason why IsSuperMajority() was suggested for CLTV/CSV in the first
place. That said, much of the code required has been implemented in XT
for the BIP101 hard-fork logic, although as mentioned above, the code
has had very little peer review.


References
----------

1) https://github.com/bitcoinxt/bitcoinxt

2) https://github.com/xtbit/notbitcoinxt

3) "Version bits proposal",
    Pieter Wuille, May 26th 2015, Bitcoin-development mailing list,
    http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008282.html,
    https://gist.github.com/sipa/bf69659f43e763540550

4) https://github.com/bitcoin/bips/commit/3248c9f67bd7fcd1d05b8db7c5c56e4788deebfe

5) "On consensus and forks - What is the difference between a hard and soft fork?",
   Mike Hearn, Aug 12th 2015,
   https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7

6) 2013 San Jose Bitcoin conference developer round-table

-- 
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2015-08-28 15:27 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-18  1:22 [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations Thomas Kerin
2015-08-19  1:04 ` Peter Todd
2015-08-19  1:08   ` Mark Friedenbach
2015-08-21 11:13     ` Thomas Kerin
2015-08-22  0:57       ` Peter Todd
2015-08-27 22:08         ` Btc Drak
2015-08-27 23:19           ` Peter Todd
2015-08-28 15:27             ` jl2012
2015-08-19  5:50 [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners Peter Todd
2015-08-19  6:10 ` Mark Friedenbach
2015-08-19  9:34   ` Jorge Timón
2015-08-19 10:20     ` Btc Drak
2015-08-19 10:31       ` Jorge Timón
2015-08-19 13:15         ` Btc Drak
2015-08-19 13:24           ` Tier Nolan
2015-08-19 17:25             ` Btc Drak
2015-08-19 18:17               ` Tier Nolan
2015-08-19 12:36     ` Matt Corallo
2015-08-19 13:22   ` Tier Nolan
2015-08-19 14:01     ` Jeff Garzik
2015-08-19 16:32     ` Mark Friedenbach
2015-08-19 21:03       ` Peter Todd
2015-08-20 17:32 ` jl2012
2015-08-20 17:42   ` Mark Friedenbach
2015-08-27 22:11     ` Btc Drak

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox