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 4D48997 for ; Sat, 22 Aug 2015 01:03:11 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148101.authsmtp.com (outmail148101.authsmtp.com [62.13.148.101]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id B2B1EAB for ; Sat, 22 Aug 2015 01:03:09 +0000 (UTC) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7M135Hx089847; Sat, 22 Aug 2015 02:03:05 +0100 (BST) Received: from muck (S0106e03f49079160.ok.shawcable.net [174.4.1.120]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7M0vpq7045505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 22 Aug 2015 01:58:45 +0100 (BST) Date: Fri, 21 Aug 2015 17:57:49 -0700 From: Peter Todd To: Thomas Kerin Message-ID: <20150822005749.GA22371@muck> References: <55D288C2.9020207@gmail.com> <20150819010404.GB2835@muck> <55D707C5.50803@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <55D707C5.50803@gmail.com> X-Server-Quench: 8b499740-4869-11e5-9f75-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAAUGUATAgsB AmMbW1ZeUF57WWY7 ag1VcwFDY1RPXQV1 VUBOXVMcUAIVAVpB RxkeVhx3dwAIfH90 ZUAsViJfVU19cUZg RkZSHHAHZDJldWlJ V0VFdwNWdQpKLx5G bwR8GhFYa3VsNCMk FAgyOXU9MCtqYA50 elNFEEkTR0lDOzMw RhkEVSkuGEBAXywo M1QvMRYRGkoJNUQ0 LRMvXkh6exsVAQ5C HkRASCRQI1IcQyM3 DARcRiYA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.4.1.120/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham 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: Sat, 22 Aug 2015 01:03:11 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 21, 2015 at 12:13:09PM +0100, Thomas Kerin wrote: >=20 > I submitted the pull-request for the median-past timelock BIP just now >=20 > https://github.com/bitcoin/bips/pull/182 >=20 > 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 m= ess with them. 23:58 < petertodd> It's still dodgy though... I was thinking if nLockTime-b= y-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 th= e 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 no= de wanting to know the current time simply gets a nonce timestamped, and th= en they know what time it is!) 00:11 < Luke-Jr> I don't see how nLockTime can discourage forward-dating bl= ocks 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 cann= ot set a maximum 00:22 < petertodd> but that's it, if I have a 1BTC fee tx, with nLockTime e= xpiring in two hours, why not take the increased orphan chance and set nTim= e on my block to two hours ahead/ 00:22 < petertodd> ? 00:22 < petertodd> yet if we allow that incentive, it's very bad for consen= sus 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=E2= =80=94 it could use the minimum time) 00:24 < petertodd> gmaxwell: The problem is, that's only a fix if mining po= wer 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 i= s less) 00:24 < Luke-Jr> gmaxwell: the minimum time will be earlier than the last b= lock's :p 00:25 < gmaxwell> Luke-Jr: sure, but that doesn't change it really. Presuma= bly if people start locking in the future miners will run nodes that take w= hat they get and selfishly horde them, creating incentives for all miners t= o 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 t= here is because (1) it's hard to advance, and (2) when you advance it you r= aise the difficulty. 00:26 < petertodd> gmaxwell: I was working on figuring out the expected ret= urn - 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 th= e 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 s= o 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, becau= se you still get to manipulate it by creating blocks in the future, althoug= h the ability too is definitely less. If I could show you'd need >50% hashi= ng power to do anything interesting I'd be set. 00:31 < Luke-Jr> petertodd: hmm, is block-uneconomic-utxo-creation basicall= y just an older revision of what Gavin did in 0.8.2? 00:31 < gmaxwell> petertodd: moving the minimum time forward needs the cope= ration 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 emph= asize the better, not the older. :P 00:32 < Luke-Jr> petertodd: will you be rebasing it despite its closed stat= us? 00:32 < Luke-Jr> actually, what about Gavin's is hardcoded? <.< 00:33 < petertodd> gmaxwell: Yeah, but you have to assume a steady stream o= f these incentives. 00:33 < gmaxwell> petertodd: right, so you have some force that turns all m= iners 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 transa= ction 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 no= w, 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 ove= r 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 mi= ne 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 2= hr 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 u= p 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, an= d 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 rejec= t 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 soon= er than your competitors. 00:43 < petertodd> It could be a week and people would still have an incent= ive to set nTime + 1 week - 1 second 00:44 < Luke-Jr> if nTime is future, wait until that time before relaying i= t? <.< 00:44 -!- realz is now known as pleasedont 00:44 < gmaxwell> and once people did that, you'd want to start accepting b= locks 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 ru= le was nLockTime > nTime of last block, and then after that being allowed t= o 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 blo= cks, 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 mi= nimum then 00:45 < Luke-Jr> [04:32:26] petertodd: will you be rebasing it de= spite its closed status? (block-uneconomic-utxo-creation) 00:46 < petertodd> Luke-Jr: again, relaying does nothing - consider the cas= e of nLockTime'd fidelity bonds where it's guaranteed 100% of the hashing p= ower 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, becaus= e 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 un= derstand why the tx isn't getting mined 00:49 < gmaxwell> sidestepping the problem < that doesn't sidestep the prob= lem, 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 yo= ur nlocktime to adjust for the expected minimum lag. 00:51 < petertodd> gmaxwell: yes, it creates a new problem, but it did side= step 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 o= ne else thinks is a problem and they totally broke security as a side effec= t) 00:52 < petertodd> gmaxwell: yup, now you see how it only sidesteps the pro= blem 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 conse= nsus failures, which can be attacked, likely it trades off one risk for a m= ore 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 ha= shpower 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 --=20 'peter'[:-1]@petertodd.org 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJV18kKXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzYCQf/erkIoXBscykeg3NuOZl6Gk1k UbnMgYm9V1VHZ/A6mUjMH6fk0FMFfq3gN/+Rqec9NyDvXbmWOFzgTaJX6Bl4rF3v mIBCsZ23Gs95JkvT5evlkUfdHXBVrhcaY54H2w+XuU9L6IKF2U8HOsTGn+uTLqf+ T90ojRxq7E0P0SujnYig/97KCVUTW2rRfNyoxHtciy17XXalc4qISer6YThuiJuy LrVHqTB3JKm2d5zdRtfNxJW8zEZUZZoEd0kMy6mui8pPn8BNDaw/ZS03+RBz3cEm mlIGwVeTAOXuK5XAhIAU8a6enS9KZo56dNMqP7fN7QMlIoTEmVzJrx3KTatKeA== =EVnu -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J--