Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations

[jl2012 via bitcoin-dev]

I have an ugly solution to this problem, with minimal change to the 
current softfork logic, and still allows all features described in 
sipa's Version bits BIP


1. xVersion = nVersion AND 0b10011000
2. miners supporting BIP65 will set xVersion = 8 or greater
3. If 750 of the last 1000 blocks are xVersion >= 8, reject invalid 
xVersion 8 (or greater) blocks
4. If 950 of the last 1000 blocks are xVersion >= 8, reject all blocks 
with xVersion < 8


So the logic is exactly the same as BIP66, with the AND masking in step 
1. After the BIP65 softfork is implied, xVersion may take only one of 
the following values: 8, 16, 24


This is basically moving the "high bits" in sipa's proposal to the 
middle of the nVersion field. After the BIP65 softfork, this will still 
leave 29 available bits for parallel soft forks, just in different 
position.


This is ugly, but I believe this is the easiest solution

Ref: https://gist.github.com/sipa/bf69659f43e763540550

Peter Todd via bitcoin-dev 於 2015-08-27 19:19 寫到:

On Thu, Aug 27, 2015 at 11:08:32PM +0100, Btc Drak wrote:

This BIP was assigned number 113.

I have updated the text accordingly and added credits to Gregory 
Maxwell.


Please see the changes in the pull request:
https://github.com/bitcoin/bips/pull/182


On Thu, Aug 27, 2015 at 11:11:10PM +0100, Btc Drak via bitcoin-dev 
wrote:

I have changed BIPS 112 and 113 to reflect this amended deployment
strategy. I'm beginning to think the issues created by Bitcoin XT are
so serious it probably deserves converting OPs text into an
informational BIP.


I thought we had decided that the masking thing doesn't work as
intended?

To recap, XT nodes are producing blocks with nVersion=0b001...111

You're suggesting that we apply a mask of ~0b001...111 then trigger the
soft-fork on nVersion >= 0b0...100 == 4, with miners producing blocks 
with

nVersion=0b0...1000

That will work, but it still uses up a version bit. The reason why is
blocks with nVersion=0b001...000 - the intended deployment of the
nVersion bits proposal - will be rejected by the nVersion >= 4 rule,
hard-forking them off the network. In short, we have in fact "burnt" a
version bit unnecessarily.

If you're going to accept hard-forking some people off the network, why
not just go with my stateless nVersion bits w/ time-expiration proposal
instead? The only case where it leads to a hard-fork is if a soft-fork
has been rejected by the time the upgrade deadline is reached. It's 
easy

to set this multiple years into the future, so I think in practice it
won't be a major issue for non-controversial soft-forks.

Equally, spending the time to implement the original stateful nVersion
bits proposal is possible as well, though higher risk due to the extra
complexity of tracking soft-fork state.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations

[Peter Todd via bitcoin-dev]

On Thu, Aug 27, 2015 at 11:08:32PM +0100, Btc Drak wrote:
> This BIP was assigned number 113.
> 
> I have updated the text accordingly and added credits to Gregory Maxwell.
> 
> Please see the changes in the pull request:
> https://github.com/bitcoin/bips/pull/182

On Thu, Aug 27, 2015 at 11:11:10PM +0100, Btc Drak via bitcoin-dev wrote:
> I have changed BIPS 112 and 113 to reflect this amended deployment
> strategy. I'm beginning to think the issues created by Bitcoin XT are
> so serious it probably deserves converting OPs text into an
> informational BIP.

I thought we had decided that the masking thing doesn't work as
intended?

To recap, XT nodes are producing blocks with nVersion=0b001...111

You're suggesting that we apply a mask of ~0b001...111 then trigger the
soft-fork on nVersion >= 0b0...100 == 4, with miners producing blocks with
nVersion=0b0...1000

That will work, but it still uses up a version bit. The reason why is
blocks with nVersion=0b001...000 - the intended deployment of the
nVersion bits proposal - will be rejected by the nVersion >= 4 rule,
hard-forking them off the network. In short, we have in fact "burnt" a
version bit unnecessarily.

If you're going to accept hard-forking some people off the network, why
not just go with my stateless nVersion bits w/ time-expiration proposal
instead? The only case where it leads to a hard-fork is if a soft-fork
has been rejected by the time the upgrade deadline is reached. It's easy
to set this multiple years into the future, so I think in practice it
won't be a major issue for non-controversial soft-forks.

Equally, spending the time to implement the original stateful nVersion
bits proposal is possible as well, though higher risk due to the extra
complexity of tracking soft-fork state.

-- 
'peter'[:-1]@petertodd.org
08ba8215b2b644e33a98a762fd40710bc5e8c7f1b0e78375


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations

[Btc Drak via bitcoin-dev]

This BIP was assigned number 113.

I have updated the text accordingly and added credits to Gregory Maxwell.

Please see the changes in the pull request:
https://github.com/bitcoin/bips/pull/182

On Sat, Aug 22, 2015 at 1:57 AM, Peter Todd via bitcoin-dev
 wrote:
> On Fri, Aug 21, 2015 at 12:13:09PM +0100, Thomas Kerin wrote:
>>
>> I submitted the pull-request for the median-past timelock BIP just now
>>
>> https://github.com/bitcoin/bips/pull/182
>>
>> Any luck finding the link to this discussion? It would be nice to
>> include this for posterity.
>
> Found it! From #bitcoin-wizards, 2013-07-16:
>
> 23:57 < petertodd> See, it'd be possible for nLockTime w/ time-based locks to 
> create some really ugly incentives for miners to mine blocks at thelimit of 
> the 2hr window - a timestamping chain could provide a way for nodes to at 
> least detect that their clocks are off, especially given how peers can mess 
> with them.
> 23:58 < petertodd> It's still dodgy though... I was thinking if 
> nLockTime-by-time inclusion was based on the previous block timestamp it'd be 
> ok, but that still leaves large miners with incentives to screw with the 2hr 
> window, never mind how it can reduce competition if there exists clock skew 
> in the mining nodes.
> --- Log closed Wed Jul 17 00:00:57 2013
> --- Log opened Wed Jul 17 00:00:57 2013
> 00:01 < petertodd> (remember that if this is a timestamping facility any node 
> wanting to know the current time simply gets a nonce timestamped, and then 
> they know what time it is!)
> 00:11 < Luke-Jr> I don't see how nLockTime can discourage forward-dating 
> blocks
> 00:11 < Luke-Jr> and there is no 2hr window backward..
> 00:12 < Luke-Jr> well, I guess if miners are behaving there is <.<
> 00:19 < petertodd> The problem is a block being created with nTime > actual 
> time, and the incentive is to get a head start on other miners to put, say, a 
> high-fee nLockTime in the block you are creating.
> 00:21 < Luke-Jr> petertodd: but nLockTime only sets a minimum time, it cannot 
> set a maximum
> 00:22 < petertodd> but that's it, if I have a 1BTC fee tx, with nLockTime 
> expiring in two hours, why not take the increased orphan chance and set nTime 
> on my block to two hours ahead/
> 00:22 < petertodd> ?
> 00:22 < petertodd> yet if we allow that incentive, it's very bad for consensus
> 00:23 < gmaxwell> ha. We can fix.
> 00:23 < gmaxwell> it's a soft forking fix.
> 00:23 < gmaxwell> use the last blocks ntime, not this one.
> 00:23 < Luke-Jr> is sipa's secp256k1 branch reasonably stable?
> 00:23 < petertodd> gmaxwell: that's what I said...
> 00:24 < gmaxwell> petertodd: sorry I just read the last couple lines.
> 00:24 < Luke-Jr> petertodd: AFAIK we already don't relay transactions with 
> time in the future?
> 00:24 < gmaxwell> petertodd: well I agree. (or not even the last block— it 
> could use the minimum time)
> 00:24 < petertodd> gmaxwell: The problem is, that's only a fix if mining 
> power is well distributed, it actually makes things worse because if there is 
> a lot of profit to be gained the miners with a lot of hashing power still 
> have the incentive, and it's to a much greater degree. (their orphan rate is 
> less)
> 00:24 < Luke-Jr> gmaxwell: the minimum time will be earlier than the last 
> block's :p
> 00:25 < gmaxwell> Luke-Jr: sure, but that doesn't change it really. 
> Presumably if people start locking in the future miners will run nodes that 
> take what they get and selfishly horde them, creating incentives for all 
> miners to run good collection networks.
> 00:25 < petertodd> Luke-Jr: sure, but there are lots of ways to learn that a 
> tx exists
> 00:26 < gmaxwell> petertodd: one of the reasons that the min is important 
> there is because (1) it's hard to advance, and (2) when you advance it you 
> raise the difficulty.
> 00:26 < petertodd> gmaxwell: I was working on figuring out the expected 
> return - the math is really ugly
> 00:27 < gmaxwell> petertodd: a worst case expected return may be easier.
> 00:27 < petertodd> gmaxwell: Worst case is easy - your block is orphaned.
> 00:28 < petertodd> gmaxwell: See the issue is that once I find a block, the 
> other side needs to find two blocks to beat me. As time goes on more of the 
> other sides hashing power will accept my from the future block as valid, so 
> then you get the next level where the remainder needs three blocks and so on.
> 00:28 < petertodd> gmaxwell: Pretty sure it can't be done as a closed-form 
> equation.
> 00:30 < petertodd> gmaxwell: I don't think minimum time works either, because 
> you still get to manipulate it by creating blocks in the future, although the 
> ability too is definitely less. If I could show you'd need >50% hashing power 
> to do anything interesting I'd be set.
> 00:31 < Luke-Jr> petertodd: hmm, is block-uneconomic-utxo-creation basically 
> just an older revision of what Gavin did in 0.8.2?
> 00:31 < gmaxwell> petertodd: moving the minimum time forward needs 

Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations

[Peter Todd via bitcoin-dev]

On Fri, Aug 21, 2015 at 12:13:09PM +0100, Thomas Kerin wrote:
> 
> I submitted the pull-request for the median-past timelock BIP just now
> 
> https://github.com/bitcoin/bips/pull/182
> 
> Any luck finding the link to this discussion? It would be nice to
> include this for posterity.

Found it! From #bitcoin-wizards, 2013-07-16:

23:57 < petertodd> See, it'd be possible for nLockTime w/ time-based locks to 
create some really ugly incentives for miners to mine blocks at thelimit of the 
2hr window - a timestamping chain could provide a way for nodes to at least 
detect that their clocks are off, especially given how peers can mess with them.
23:58 < petertodd> It's still dodgy though... I was thinking if 
nLockTime-by-time inclusion was based on the previous block timestamp it'd be 
ok, but that still leaves large miners with incentives to screw with the 2hr 
window, never mind how it can reduce competition if there exists clock skew in 
the mining nodes.
--- Log closed Wed Jul 17 00:00:57 2013
--- Log opened Wed Jul 17 00:00:57 2013
00:01 < petertodd> (remember that if this is a timestamping facility any node 
wanting to know the current time simply gets a nonce timestamped, and then they 
know what time it is!)
00:11 < Luke-Jr> I don't see how nLockTime can discourage forward-dating blocks
00:11 < Luke-Jr> and there is no 2hr window backward..
00:12 < Luke-Jr> well, I guess if miners are behaving there is <.<
00:19 < petertodd> The problem is a block being created with nTime > actual 
time, and the incentive is to get a head start on other miners to put, say, a 
high-fee nLockTime in the block you are creating.
00:21 < Luke-Jr> petertodd: but nLockTime only sets a minimum time, it cannot 
set a maximum
00:22 < petertodd> but that's it, if I have a 1BTC fee tx, with nLockTime 
expiring in two hours, why not take the increased orphan chance and set nTime 
on my block to two hours ahead/
00:22 < petertodd> ?
00:22 < petertodd> yet if we allow that incentive, it's very bad for consensus
00:23 < gmaxwell> ha. We can fix.
00:23 < gmaxwell> it's a soft forking fix.
00:23 < gmaxwell> use the last blocks ntime, not this one.
00:23 < Luke-Jr> is sipa's secp256k1 branch reasonably stable?
00:23 < petertodd> gmaxwell: that's what I said...
00:24 < gmaxwell> petertodd: sorry I just read the last couple lines.
00:24 < Luke-Jr> petertodd: AFAIK we already don't relay transactions with time 
in the future?
00:24 < gmaxwell> petertodd: well I agree. (or not even the last block— it 
could use the minimum time)
00:24 < petertodd> gmaxwell: The problem is, that's only a fix if mining power 
is well distributed, it actually makes things worse because if there is a lot 
of profit to be gained the miners with a lot of hashing power still have the 
incentive, and it's to a much greater degree. (their orphan rate is less)
00:24 < Luke-Jr> gmaxwell: the minimum time will be earlier than the last 
block's :p
00:25 < gmaxwell> Luke-Jr: sure, but that doesn't change it really. Presumably 
if people start locking in the future miners will run nodes that take what they 
get and selfishly horde them, creating incentives for all miners to run good 
collection networks.
00:25 < petertodd> Luke-Jr: sure, but there are lots of ways to learn that a tx 
exists
00:26 < gmaxwell> petertodd: one of the reasons that the min is important there 
is because (1) it's hard to advance, and (2) when you advance it you raise the 
difficulty.
00:26 < petertodd> gmaxwell: I was working on figuring out the expected return 
- the math is really ugly
00:27 < gmaxwell> petertodd: a worst case expected return may be easier.
00:27 < petertodd> gmaxwell: Worst case is easy - your block is orphaned.
00:28 < petertodd> gmaxwell: See the issue is that once I find a block, the 
other side needs to find two blocks to beat me. As time goes on more of the 
other sides hashing power will accept my from the future block as valid, so 
then you get the next level where the remainder needs three blocks and so on.
00:28 < petertodd> gmaxwell: Pretty sure it can't be done as a closed-form 
equation.
00:30 < petertodd> gmaxwell: I don't think minimum time works either, because 
you still get to manipulate it by creating blocks in the future, although the 
ability too is definitely less. If I could show you'd need >50% hashing power 
to do anything interesting I'd be set.
00:31 < Luke-Jr> petertodd: hmm, is block-uneconomic-utxo-creation basically 
just an older revision of what Gavin did in 0.8.2?
00:31 < gmaxwell> petertodd: moving the minimum time forward needs the 
coperation of >50% of the hashpower over the small median window.
00:32 < petertodd> Luke-Jr: It's what Gavin did but non-hardcoded. I'd 
emphasize the better, not the older. :P
00:32 < Luke-Jr> petertodd: will you be rebasing it despite its closed status?
00:32 < Luke-Jr> actually, what about Gavin's is hardcoded? <.<
00:33 < petertodd> gmaxwell: Yeah, but you have to assume a steady stream of 
these incentives.

Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations

[Thomas Kerin via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I submitted the pull-request for the median-past timelock BIP just now

https://github.com/bitcoin/bips/pull/182

Any luck finding the link to this discussion? It would be nice to
include this for posterity.


On 19/08/15 02:08, Mark Friedenbach wrote:
> You are absolutely correct! My apologies for the oversight in editing. If you 
> could dig up the link
though that would be really helpful.
>
> On Tue, Aug 18, 2015 at 6:04 PM, Peter Todd via bitcoin-dev
mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> On Tue, Aug 18, 2015 at 02:22:10AM +0100, Thomas Kerin via
bitcoin-dev wrote:
> > ==Acknowledgements==
> >
> > Mark Friedenbach for designing and authoring the reference
> > implementation of this BIP.
> >
> > Thomas Kerin authored this BIP document.
>
> IIRC Gregory Maxwell came up with the actual idea in question,
during a
> discussion between myself and Luke-Jr about incentives related to
nTime
> on #bitcoin-dev or #bitcoin-wizards. He should get credit for it; I'll
> see if I can dig up a link to the discussion for historical interest.
>
> --
> 'peter'[:-1]@petertodd.org 
> 0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org

> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

- -- 
My PGP key can be found here: 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJV1we8AAoJEAiDZR291eTlkdwP/Rv3wE1kUSGe62Im9VIm49ZW
hL71+9+C9BMyRWfUjizqGi/FgWzKlS5dVrKJdNnzV5g1KjZYIWF7Zy824Gnv8hrE
zW2pJc4vgu8igjtO+Qm/Wi+yy5WNjQ9qhRO+chELx4JLvD5JalagrBP2V693gNNd
g2K6fjXlogx/Rw4mK2pxYlUxgaWf2j+iJ2v09238+aWuXruTirpf/HJ70Pxwm4oq
LvJervkEUtUJLiwqsiwAQwqjesFPfuV1nYCi48G0/QfYK7tpajGD7NkO89RBNnP8
P6XGouBqulSvzc3QgtQqPIfOdEtV2Qi8Aohv+ebttaxFM8LSycvG9wxrQ+5Y/F4w
h7HDkn7ziM8MVS+KfFuuyfKxhDKdfpgu61r1YTzt7TyMSzdvQ8c9XhYCN3/AvL9S
6kwOeWTONVNpQbhI3WkzRPpTpaInLm1LkeXWuZVy9jbUtD8tlI0a6HmLzIrhcpdS
keOZiH1eV1nritrEFeToaTNL09MjyfdJk0kN9dr6fI3eOV/cPQkY52iCHWLMj+WY
X2wWwMPiNzfkgmMC+GvcQNmGSklaIr2OoUuT92q4M1pVi24vPNSvVy00W4+klXgK
UsCIMzo+n1OLRV8I1zuYkCAwOKzzJlvMw/7bggLxhuNsLubtM0HvDjq0uquE+zu6
BO12PmW8qOA2KqyeYEVn
=1Fst
-END PGP SIGNATURE-

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations

[Mark Friedenbach via bitcoin-dev]

You are absolutely correct! My apologies for the oversight in editing. If
you could dig up the link though that would be really helpful.

On Tue, Aug 18, 2015 at 6:04 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Aug 18, 2015 at 02:22:10AM +0100, Thomas Kerin via bitcoin-dev
> wrote:
> > ==Acknowledgements==
> >
> > Mark Friedenbach for designing and authoring the reference
> > implementation of this BIP.
> >
> > Thomas Kerin authored this BIP document.
>
> IIRC Gregory Maxwell came up with the actual idea in question, during a
> discussion between myself and Luke-Jr about incentives related to nTime
> on #bitcoin-dev or #bitcoin-wizards. He should get credit for it; I'll
> see if I can dig up a link to the discussion for historical interest.
>
> --
> 'peter'[:-1]@petertodd.org
> 0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations

[Peter Todd via bitcoin-dev]

On Tue, Aug 18, 2015 at 02:22:10AM +0100, Thomas Kerin via bitcoin-dev wrote:
> ==Acknowledgements==
> 
> Mark Friedenbach for designing and authoring the reference
> implementation of this BIP.
> 
> Thomas Kerin authored this BIP document.

IIRC Gregory Maxwell came up with the actual idea in question, during a
discussion between myself and Luke-Jr about incentives related to nTime
on #bitcoin-dev or #bitcoin-wizards. He should get credit for it; I'll
see if I can dig up a link to the discussion for historical interest.

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


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations

[Thomas Kerin via 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.


  BIP: XX
  Title: Median time-past as endpoint for lock-time calculations
  Author: Thomas Kerin 
  Mark Friedenbach 
  Status: Draft
  Type: Standards Track
  Created: 2015-08-10



==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: 
-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/gXEXeBmI9