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 CAF87F46 for ; Thu, 27 Aug 2015 22:08:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9172B129 for ; Thu, 27 Aug 2015 22:08:52 +0000 (UTC) Received: by ykdt205 with SMTP id t205so35925414ykd.1 for ; Thu, 27 Aug 2015 15:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=G8tmb1tMX7SArgF0UCxo6fFQ7kSDvMuAA0QEGmoi6FU=; b=mXZMj0j6nI2Twwr4OOeyIxM2+Z3s9L5nJm2yJQUCyFQvUq4AA7HN3cT1zW77rCaRHA mfOaObPZ6+7P+K3sXyjzgm+gDJ8dtEwO2Aizfu/Shruj7MzLFzq9wV8knD6s322e7hgG HGN5P4mVouoiaQei+ShudbIiyJ/jzNeG/+aOkyfjSNlaTVQxTwLOvorW1nIguAkr/54p s4UE3eQfNQPX/WPZUwUz1P9jyCS5C1yJzvagXAF7/H/8f6WjcoWmVD3KwJPBiEHirSRL 61zqT5vD9DoxvyDLLj0Fp699zCYYyEVZD7FDTdY+wVhR4Ggl60o8ZD32apix9noMVHGY dRPw== X-Received: by 10.170.172.84 with SMTP id o81mr5635488ykd.69.1440713331863; Thu, 27 Aug 2015 15:08:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.94.132 with HTTP; Thu, 27 Aug 2015 15:08:32 -0700 (PDT) In-Reply-To: <20150822005749.GA22371@muck> References: <55D288C2.9020207@gmail.com> <20150819010404.GB2835@muck> <55D707C5.50803@gmail.com> <20150822005749.GA22371@muck> From: Btc Drak Date: Thu, 27 Aug 2015 23:08:32 +0100 Message-ID: To: Peter Todd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [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: Thu, 27 Aug 2015 22:08:53 -0000 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 lock= s to create some really ugly incentives for miners to mine blocks at thelim= it of the 2hr window - a timestamping chain could provide a way for nodes t= o 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, bu= t that still leaves large miners with incentives to screw with the 2hr wind= ow, 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 > actu= al time, and the incentive is to get a head start on other miners to put, s= ay, a high-fee nLockTime in the block you are creating. > 00:21 < Luke-Jr> petertodd: but nLockTime only sets a minimum time, it ca= nnot 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 nT= ime on my block to two hours ahead/ > 00:22 < petertodd> ? > 00:22 < petertodd> yet if we allow that incentive, it's very bad for cons= ensus > 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 wit= h time in the future? > 00:24 < gmaxwell> petertodd: well I agree. (or not even the last block=E2= =80=94 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 stil= l 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. Presu= mably 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 tha= t 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 r= eturn - 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, t= he 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-for= m equation. > 00:30 < petertodd> gmaxwell: I don't think minimum time works either, bec= ause you still get to manipulate it by creating blocks in the future, altho= ugh the ability too is definitely less. If I could show you'd need >50% has= hing power to do anything interesting I'd be set. > 00:31 < Luke-Jr> petertodd: hmm, is block-uneconomic-utxo-creation basica= lly just an older revision of what Gavin did in 0.8.2? > 00:31 < gmaxwell> petertodd: moving the minimum time forward needs the co= peration 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 em= phasize the better, not the older. :P > 00:32 < Luke-Jr> petertodd: will you be rebasing it despite its closed st= atus? > 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 add= ed 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 tran= saction 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+24= h > 00:37 < Luke-Jr> not perfect, but might help > 00:37 < petertodd> Still doesn't help in the usual case where mean interv= al 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 o= ver 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 swit= ch 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 driv= es difficulty up by 0.5% > 00:40 < Luke-Jr> and on top of that, you'd just end up treating nTime wit= h 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 margina= l 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 th= e 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 rej= ect 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 t= o break consunsus for anyone without NTP. > 00:43 < petertodd> The problem is no matter *what* the window is, there i= s an incentive to mine as close to the window as possible to accept a tx so= oner than your competitors. > 00:43 < petertodd> It could be a week and people would still have an ince= ntive 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 rejec= t 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 n= o good incentive to set nTime accurately other than miners rejecting your b= locks, and nLockTime sabotages that > 00:45 -!- pleasedont is now known as realzies > 00:45 < petertodd> gmaxwell: (timestamping could do, but the cause->effec= t 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] 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 c= ase 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 direct= ly to other mining pools playing the same game > 00:47 < petertodd> you have to assume perfect information knowledge in th= is 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, beca= use it provides a way for all users to set their clocks to what the majorit= y 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 pr= oblem, 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 si= destep 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 eff= ect) > 00:52 < petertodd> gmaxwell: yup, now you see how it only sidesteps the p= roblem 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 con= sensus 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 >