From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WcHLa-0005RC-IA for bitcoin-development@lists.sourceforge.net; Mon, 21 Apr 2014 16:45:34 +0000 X-ACL-Warn: Received: from relay14.mail.ox.ac.uk ([163.1.2.162]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WcHLX-0006Zv-21 for bitcoin-development@lists.sourceforge.net; Mon, 21 Apr 2014 16:45:34 +0000 Received: from hub03.nexus.ox.ac.uk ([163.1.154.216] helo=HUB03.ad.oak.ox.ac.uk) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1WcHLQ-00058N-kp; Mon, 21 Apr 2014 17:45:24 +0100 Received: from MBX03.ad.oak.ox.ac.uk ([169.254.3.44]) by HUB03.ad.oak.ox.ac.uk ([163.1.154.216]) with mapi id 14.03.0169.001; Mon, 21 Apr 2014 17:45:23 +0100 From: Jonathan Levin To: Mark Friedenbach Thread-Topic: Economics of information propagation Thread-Index: AQHPXYEWpTaZmGM7n0CdxFu2gwNUfg== Date: Mon, 21 Apr 2014 16:45:22 +0000 Message-ID: References: <52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk> <53554089.1010503@monetize.io> In-Reply-To: <53554089.1010503@monetize.io> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.150.236] Content-Type: multipart/signed; boundary="Apple-Mail=_F256537F-C6CF-44DD-BAD7-5B2E660686C0"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-Spam-Score: -0.7 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WcHLX-0006Zv-21 Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Economics of information propagation X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 16:45:34 -0000 --Apple-Mail=_F256537F-C6CF-44DD-BAD7-5B2E660686C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thank you for your thoughts.=20 > The earlier, larger block A will only become stale if *two* blocks are > found in the extra time it takes for block A to propagate the network. > That is a substantially different risk, and probably a negligible > concern to most miners. I really like Mark=92s suggestion but one concern is that it might tip = the needle too far. Currently, there is a private cost to include more = transactions, which might be too high, but limit the amount of negative = externalities that this creates on other miners. If I am able to create = blocks that are very likely to be on the main chain with the maximum = number of transactions then this makes imposing negative externalities = on other miners less costly. Other nodes that are closely connected to = me would experience a positive externality through this as well. Would = have do some more thinking here but it seems that there is a balance to = strike. > If anything, looks like a threat to the current situation with huge > mining subsidies coming from the seigniorage, not a problem that you > would have when the the seigniorage is gone. The incentives remain so long as the ratio of the seignorage revenues to = transaction fees remain very high. Even though the dollar price does not = change that relationship it does mean that Bitcoin becomes more = expensive in USD terms as the USD price of Bitcoin rises. > I think the most important part is that nodes can reliably decide on > "first received", regardless of how they subsequently act on it.=20 If we want to limit the amount of network time spent on redundant = problems it would be best for miners to act on this information? What is = the benefit of serialisation? Is it that the miner would consider it = more likely to make it into the main chain rather than the block that = came second? > But I don't see how miners mining headers first would result in empty > blocks either. I guess it is due to the fact that this is the only way a miner can be = certain that none of the transactions have been spent already resulting = in an orphan block. On 21 Apr 2014, at 17:00, Mark Friedenbach wrote: > That wasn't what I was saying. Right now the primacy of a block is > determined by the time at which the `block` message is received, which > is delays due to both the time it takes to transmit the block data and > the time it takes to validate. Headers-first, on the other hand, has = the > option of basing primacy on the time the block header is received, = which > is O(1) time to transmit and to SPV-validate. Mining on that block > doesn't actually commence until the full block is received and = validated. >=20 > To see how this works, take an example: two blocks with a common = parent > are found relatively close to each other, block A and block B. A is > found first but is a large block with the maximum block size and many > slow scripts. B is found a few seconds later and is an empty block. In > the current regime it is entirely possible that block B, the later but > smaller block, would get received and processed first by more mining > peers than the larger block A, exactly as described in Jonathan = Levin's > email. >=20 > With headers-first, however, the cost of propagation of the block = header > is the same and we should expect block A to win out over block B = nearly > every time. Miners will continue working on the old, known valid = parent > block until the contents of block A are received and processed. So the > smaller block B is still found, and since it's data moves across the > network faster, miners even briefly mine on block B. But as soon as = they > receive and process the contents of block A, they switch to that. >=20 > The earlier, larger block A will only become stale if *two* blocks are > found in the extra time it takes for block A to propagate the network. > That is a substantially different risk, and probably a negligible > concern to most miners. >=20 > On 04/20/2014 09:06 PM, Peter Todd wrote: >> That is mistaken: you can't mine on top of just a block header, >> leaving small miners disadvantaged as they are earning no profit >> while they wait for the information to validate the block and update >> their UTXO sets. This results in the same problem as before, as the >> large pools who mine most blocks can validate either instantly - the >> self-mine case - or more quickly than the smaller miners. >>=20 >> Of course, in reality smaller miners can just mine on top of block >> headers and include no transactions and do no validation, but that is >> extremely harmful to the security of Bitcoin. --Apple-Mail=_F256537F-C6CF-44DD-BAD7-5B2E660686C0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTVUslAAoJEFPmse9fNbQlBoQH/2sxPccDRPK1Da6+e6lHK3tJ RsHpkyKl/lwDlBopES4Ei9eVshzuiFIt3OvpN8DPaXEy8rB+gk10GbVq2kyWiWeb iuWVkMrNCjJi2JYRNzMSoRvw8N1qrJpD+hyLFfwL9j1KolDZvq/T2HAJOl42Ncyp GXXtQkhjxNVlFhEENfuoSPxBuybRUFsBRgZVW9SpRIoSGcfQrJYPQUTaJxJwyMrV x3x3Za3jZWXqqJSnpu1C35h8XQWQSedMCECk0tHH2abMaWPPX+Slq+QaJWBBzbie 4KxG0+lGIm1sKmJBG3pK6aO41blFghnbGG281jsSq4fvyWhPnYRPZE8RYY7JkGI= =1EmZ -----END PGP SIGNATURE----- --Apple-Mail=_F256537F-C6CF-44DD-BAD7-5B2E660686C0--