BIP: Using Median time-past as endpoint for locktime calculations

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>

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.

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
> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<bitcoin-dev@lists•linuxfoundation•org <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 <http://petertodd.org>
>     00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists•linuxfoundation•org

<mailto:bitcoin-dev@lists.linuxfoundation.org>

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

- -- My PGP key can be found here: <https://thomaskerin.io/me.pub.asc>

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. 00:33 < gmaxwell> petertodd: right, so you have some force that turns all miners into a conspiracy. 00:34 < petertodd> gmaxwell: exactly 00:34 < petertodd> gmaxwell: nLockTime by time should have never been added in the first place, but it's such a nice idea on the face of it 00:35 -!- realazthat is now known as rudeasthat 00:35 -!- rudeasthat is now known as rudest 00:35 < Luke-Jr> softfork so nLockTime requires data on what block a transaction was created at, and enforces the 10 min per block <.< 00:36 -!- rudest is now known as heh 00:36 < petertodd> Luke-Jr: ? 00:36 -!- heh is now known as realz 00:36 < Luke-Jr> petertodd: for example, if you nLockTime for 1 day from now, it also enforces 144 blocks passing too 00:37 < Luke-Jr> so block count must be >now+144 AND time must be >now+24h 00:37 < Luke-Jr> not perfect, but might help 00:37 < petertodd> Still doesn't help in the usual case where mean interval is < 10 minutes, because you're back to only caring about time. 00:38 < Luke-Jr> usual now, but not eventually 00:38 < petertodd> Right, you've solved half the problem, when measured over the entire lifespan of Bitcoin, and only approximately half. :P 00:39 < Luke-Jr> theory is so much nicer than practice <.< 00:39 < gmaxwell> I'm forgetting why this is a problem again? If miners mine blocks early, people will just artifically inflate their times or switch to height locking. 00:39 < petertodd> The problem is you're incentivising miners to make the 2hr window for block acceptance effectively shorter. 00:39 < petertodd> Thus requiring accurate clocks for consensus. 00:39 < gmaxwell> if miners do this consistently they'll drive difficulty up too which wouldn't be in their interest. 00:39 < Luke-Jr> ^ 00:40 < petertodd> gmaxwell: It's only a fixed 2hr offset, that just drives difficulty up by 0.5% 00:40 < Luke-Jr> and on top of that, you'd just end up treating nTime with a minus-2-hours :p 00:41 < Luke-Jr> if everyone does it, it's predictable. 00:41 < petertodd> More to the point for any individual miner the marginal difference if they do it is effectively zero. 00:41 < gmaxwell> consider, why why cant the 2 hour window be 24 hours? 00:41 < petertodd> Luke-Jr: But that's the problem, if everyone does it, and people respond, then you can extend the interval even further! 00:41 < Luke-Jr> petertodd: how? 00:41 < petertodd> gmaxwell: It should have been more like 24 hours in the first place... 00:42 < Luke-Jr> you don't change the 2h rule 00:42 < Luke-Jr> you just assume miner times will always be up against it 00:42 < gmaxwell> Luke-Jr: move your clock/window forward so you dont reject stupid blocks. 00:42 < petertodd> Luke-Jr: Again, the issue is the effect on *consusus*. I don't care when the tx gets mined, I care that miners are incentivised to break consunsus for anyone without NTP. 00:43 < petertodd> The problem is no matter *what* the window is, there is an incentive to mine as close to the window as possible to accept a tx sooner than your competitors. 00:43 < petertodd> It could be a week and people would still have an incentive to set nTime + 1 week - 1 second 00:44 < Luke-Jr> if nTime is future, wait until that time before relaying it? <.< 00:44 -!- realz is now known as pleasedont 00:44 < gmaxwell> and once people did that, you'd want to start accepting blocks that where nTime + 1 week because god knows you don't want to reject a block if your clock was 2 seconds slow and most hashpower accepted it. 00:44 < petertodd> About the only thing that might change that is if the rule was nLockTime > nTime of last block, and then after that being allowed to include a tx was based on H(txhash, last hash) or similar 00:45 < petertodd> gmaxwell: exactly, the fundemental issue is there is no good incentive to set nTime accurately other than miners rejecting your blocks, and nLockTime sabotages that 00:45 -!- pleasedont is now known as realzies 00:45 < petertodd> gmaxwell: (timestamping could do, but the cause->effect is less obvious) 00:45 < Luke-Jr> I guess I just incentivized always setting nTime to the minimum then 00:45 < Luke-Jr> [04:32:26] <Luke-Jr> petertodd: will you be rebasing it despite its closed status? (block-uneconomic-utxo-creation) 00:46 < petertodd> Luke-Jr: again, relaying does nothing - consider the case of nLockTime'd fidelity bonds where it's guaranteed 100% of the hashing power know (why I wrote the spec as by-block-height in the first place) 00:46 < petertodd> Luke-Jr: sure 00:46 < Luke-Jr> petertodd: I mean delaying relaying the BLOCK 00:46 < Luke-Jr> ie, increasing the risk of it being stale 00:47 < petertodd> Luke-Jr: then you have your mining pool connect directly to other mining pools playing the same game 00:47 < petertodd> you have to assume perfect information knowledge in this stuff, at least if you're writing worst-case academic papers 00:48 < gmaxwell> petertodd: so ... prior block vs minimum time. 00:48 < petertodd> see, that's why I was talking about timestamping, because it provides a way for all users to set their clocks to what the majority of hashing power thinks nTime is, sidestepping the problem 00:48 < gmaxwell> petertodd: what are your arguments there? 00:48 < petertodd> gmaxwell: minimum time is definitely stronger because it involves more hashing power 00:49 < petertodd> gmaxwell: users would prefer minimum time - easier to understand why the tx isn't getting mined 00:49 < gmaxwell> sidestepping the problem < that doesn't sidestep the problem, it would allow the majority of hashpower to mine difficulty down to 1; also moots nlocktime as _time_ being more reliable than a height. 00:49 < gmaxwell> petertodd: plus, you can just add a constant offset to your nlocktime to adjust for the expected minimum lag. 00:51 < petertodd> gmaxwell: yes, it creates a new problem, but it did sidestep the existing one :P 00:51 < gmaxwell> petertodd: yea, lol, creates an inflation attack. Keep it up and you'll be qualified to create an altcoin. :P 00:52 < gmaxwell> (sorry, hah, I'm not poking fun at you, I'm poking fun at all the altcoins that "solved the Foo problem" where foo is something no one else thinks is a problem and they totally broke security as a side effect) 00:52 < petertodd> gmaxwell: yup, now you see how it only sidesteps the problem truly when there is enough hashing power setting their clocks back, IE 50% honest, which is better 00:53 < petertodd> gmaxwell: without the timestamping, nodes have the consensus failures, which can be attacked, likely it trades off one risk for a more existential risk 00:53 < petertodd> gmaxwell: and it's a good excuse for timestamping, lol 00:54 < gmaxwell> I thin the min solves the consensus failure so long as hashpower is well distributed. 00:54 < petertodd> yeah, I'm thinking min is probably the best we can do

https://download.wpsoftware.net/bitcoin/wizards/2013/07/13-07-16.log

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 <bitcoin-dev@lists•linuxfoundation•org> 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 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.
> 00:33 < gmaxwell> petertodd: right, so you have some force that turns all miners into a conspiracy.
> 00:34 < petertodd> gmaxwell: exactly
> 00:34 < petertodd> gmaxwell: nLockTime by time should have never been added in the first place, but it's such a nice idea on the face of it
> 00:35 -!- realazthat is now known as rudeasthat
> 00:35 -!- rudeasthat is now known as rudest
> 00:35 < Luke-Jr> softfork so nLockTime requires data on what block a transaction was created at, and enforces the 10 min per block <.<
> 00:36 -!- rudest is now known as heh
> 00:36 < petertodd> Luke-Jr: ?
> 00:36 -!- heh is now known as realz
> 00:36 < Luke-Jr> petertodd: for example, if you nLockTime for 1 day from now, it also enforces 144 blocks passing too
> 00:37 < Luke-Jr> so block count must be >now+144 AND time must be >now+24h
> 00:37 < Luke-Jr> not perfect, but might help
> 00:37 < petertodd> Still doesn't help in the usual case where mean interval is < 10 minutes, because you're back to only caring about time.
> 00:38 < Luke-Jr> usual now, but not eventually
> 00:38 < petertodd> Right, you've solved half the problem, when measured over the entire lifespan of Bitcoin, and only approximately half. :P
> 00:39 < Luke-Jr> theory is so much nicer than practice <.<
> 00:39 < gmaxwell> I'm forgetting why this is a problem again?  If miners mine blocks early, people will just artifically inflate their times or switch to height locking.
> 00:39 < petertodd> The problem is you're incentivising miners to make the 2hr window for block acceptance effectively shorter.
> 00:39 < petertodd> Thus requiring accurate clocks for consensus.
> 00:39 < gmaxwell> if miners do this consistently they'll drive difficulty up too which wouldn't be in their interest.
> 00:39 < Luke-Jr> ^
> 00:40 < petertodd> gmaxwell: It's only a fixed 2hr offset, that just drives difficulty up by 0.5%
> 00:40 < Luke-Jr> and on top of that, you'd just end up treating nTime with a minus-2-hours :p
> 00:41 < Luke-Jr> if everyone does it, it's predictable.
> 00:41 < petertodd> More to the point for any individual miner the marginal difference if they do it is effectively zero.
> 00:41 < gmaxwell> consider, why why cant the 2 hour window be 24 hours?
> 00:41 < petertodd> Luke-Jr: But that's the problem, if everyone does it, and people respond, then you can extend the interval even further!
> 00:41 < Luke-Jr> petertodd: how?
> 00:41 < petertodd> gmaxwell: It should have been more like 24 hours in the first place...
> 00:42 < Luke-Jr> you don't change the 2h rule
> 00:42 < Luke-Jr> you just assume miner times will always be up against it
> 00:42 < gmaxwell> Luke-Jr: move your clock/window forward so you dont reject stupid blocks.
> 00:42 < petertodd> Luke-Jr: Again, the issue is the effect on *consusus*. I don't care when the tx gets mined, I care that miners are incentivised to break consunsus for anyone without NTP.
> 00:43 < petertodd> The problem is no matter *what* the window is, there is an incentive to mine as close to the window as possible to accept a tx sooner than your competitors.
> 00:43 < petertodd> It could be a week and people would still have an incentive to set nTime + 1 week - 1 second
> 00:44 < Luke-Jr> if nTime is future, wait until that time before relaying it? <.<
> 00:44 -!- realz is now known as pleasedont
> 00:44 < gmaxwell> and once people did that, you'd want to start accepting blocks that where nTime + 1 week because god knows you don't want to reject a block if your clock was 2 seconds slow and most hashpower accepted it.
> 00:44 < petertodd> About the only thing that might change that is if the rule was nLockTime > nTime of last block, and then after that being allowed to include a tx was based on H(txhash, last hash) or similar
> 00:45 < petertodd> gmaxwell: exactly, the fundemental issue is there is no good incentive to set nTime accurately other than miners rejecting your blocks, and nLockTime sabotages that
> 00:45 -!- pleasedont is now known as realzies
> 00:45 < petertodd> gmaxwell: (timestamping could do, but the cause->effect is less obvious)
> 00:45 < Luke-Jr> I guess I just incentivized always setting nTime to the minimum then
> 00:45 < Luke-Jr> [04:32:26] <Luke-Jr> petertodd: will you be rebasing it despite its closed status? (block-uneconomic-utxo-creation)
> 00:46 < petertodd> Luke-Jr: again, relaying does nothing - consider the case of nLockTime'd fidelity bonds where it's guaranteed 100% of the hashing power know (why I wrote the spec as by-block-height in the first place)
> 00:46 < petertodd> Luke-Jr: sure
> 00:46 < Luke-Jr> petertodd: I mean delaying relaying the BLOCK
> 00:46 < Luke-Jr> ie, increasing the risk of it being stale
> 00:47 < petertodd> Luke-Jr: then you have your mining pool connect directly to other mining pools playing the same game
> 00:47 < petertodd> you have to assume perfect information knowledge in this stuff, at least if you're writing worst-case academic papers
> 00:48 < gmaxwell> petertodd: so ... prior block vs minimum time.
> 00:48 < petertodd> see, that's why I was talking about timestamping, because it provides a way for all users to set their clocks to what the majority of hashing power thinks nTime is, sidestepping the problem
> 00:48 < gmaxwell> petertodd: what are your arguments there?
> 00:48 < petertodd> gmaxwell: minimum time is definitely stronger because it involves more hashing power
> 00:49 < petertodd> gmaxwell: users would prefer minimum time - easier to understand why the tx isn't getting mined
> 00:49 < gmaxwell> sidestepping the problem < that doesn't sidestep the problem, it would allow the majority of hashpower to mine difficulty down to 1; also moots nlocktime as _time_ being more reliable than a height.
> 00:49 < gmaxwell> petertodd: plus, you can just add a constant offset to your nlocktime to adjust for the expected minimum lag.
> 00:51 < petertodd> gmaxwell: yes, it creates a new problem, but it did sidestep the existing one :P
> 00:51 < gmaxwell> petertodd: yea, lol, creates an inflation attack. Keep it up and you'll be qualified to create an altcoin. :P
> 00:52 < gmaxwell> (sorry, hah, I'm not poking fun at you, I'm poking fun at all the altcoins that "solved the Foo problem" where foo is something no one else thinks is a problem and they totally broke security as a side effect)
> 00:52 < petertodd> gmaxwell: yup, now you see how it only sidesteps the problem truly when there is enough hashing power setting their clocks back, IE 50% honest, which is better
> 00:53 < petertodd> gmaxwell: without the timestamping, nodes have the consensus failures, which can be attacked, likely it trades off one risk for a more existential risk
> 00:53 < petertodd> gmaxwell: and it's a good excuse for timestamping, lol
> 00:54 < gmaxwell> I thin the min solves the consensus failure so long as hashpower is well distributed.
> 00:54 < petertodd> yeah, I'm thinking min is probably the best we can do
>
> https://download.wpsoftware.net/bitcoin/wizards/2013/07/13-07-16.log
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>