From: Jonathan Levin <jonathan.levin@sant.ox.ac.uk>
To: Mark Friedenbach <mark@monetize.io>
Thread-Topic: Economics of information propagation
Thread-Index: AQHPXYEWpTaZmGM7n0CdxFu2gwNUfg==
Date: Mon, 21 Apr 2014 16:45:22 +0000
Message-ID: <F956A706-5730-4B68-A8CB-4F832915319B@sant.ox.ac.uk>
References: <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net>
	<52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk>
	<CACh7GpFGEvR+_qArYCkgi7AW4coSeH741ob4hmBpj6G3MayNAQ@mail.gmail.com>
	<a9a262a9-c70f-470d-81e0-ca32c41d8dc5@email.android.com>
	<53554089.1010503@monetize.io>
In-Reply-To: <53554089.1010503@monetize.io>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: multipart/signed;
	boundary="Apple-Mail=_F256537F-C6CF-44DD-BAD7-5B2E660686C0";
	protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Economics of information propagation
Precedence: list

--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 <mark@monetize.io> 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--