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 <[email protected]> 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 > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
