Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Dave Hudson <dave@hashingit.com>
In-Reply-To: <7F9283D5-5F0F-4318-BE64-A1C20A5B7606@gmx.com>
Date: Wed, 5 Aug 2015 15:44:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2312E340-EA7D-48DC-B3FF-319D6AF9E955@hashingit.com>
References: <CABsx9T1E1s=4h-SxLTOAXK4GniZrUekcEb6zDdTDFG+h7X98MA@mail.gmail.com>
	<1438640036.2828.0.camel@auspira.com>
	<CABsx9T2A-Mz9z=TTifbL2_sKCDvy8coRpNse+0vff6EbXbp8cg@mail.gmail.com>
	<BF420F3B-044C-46F6-8880-FEEB9A3DC748@gmx.com>
	<3162BC78-EC0B-4DAA-A472-D143389DDD8A@hashingit.com>
	<7F9283D5-5F0F-4318-BE64-A1C20A5B7606@gmx.com>
To: Peter R <peter_r@gmx.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block
	Size Limit"--new research paper suggests
Precedence: list

>=20
> On 5 Aug 2015, at 15:15, Peter R <peter_r@gmx.com> wrote:
>=20
> Hi Dave,
>=20
> Thank you for the feedback regarding my paper. =20
>=20
>> The paper is nicely done, but I'm concerned that there's a real =
problem with equation 4. The orphan rate is not just a function of time; =
it's also a function of the block maker's proportion of the network hash =
rate. Fundamentally a block maker (pool or aggregation of pools) does =
not orphan its own blocks.
>=20
> With the benefit of hindsight, I think the paper would be stronger if =
it also analyzed how the model changes (or doesn't) if we assume zero =
propagation impedance for intra-miner communication, as you suggested =
(the "you don't orphan your own blocks" idea).  Note that the paper did =
briefly discuss miner-dependent propagation times in the second =
paragraph of page 9 and in note 13.

I think this would be really interesting. It's an area that seems to be =
lacking research.

While I've not had time to model it I did have a quick discussion with =
the author of the Organ-of-Corti blog a few months ago and he seemed to =
think that the Poisson process model isn't quite accurate here. =
Intuitively this makes sense as until a block has fully propagated we're =
only seeing some fraction of the actual hashing network operating on the =
same problem, so we actually see slightly fewer very quick blocks than =
we might expect.

I do suspect that if we were to model this more accurately we might be =
able to infer the "typical" propagation characteristics by measuring the =
deviation from the expected distribution.

>> Consider that a 1% miner must assume a greater risk from orphaning =
than, say, a pool with 25%, or worse 40% of the hash rate.
>=20
> I'd like to explore this in more detail.  Although a miner may not =
orphan his own block, by building on his own block he may now orphan two =
blocks in a row.  At some point, his solution or solutions must be =
communicated to his peers.  And if there's information about the =
transactions in his blocks to communicate, I think there's a cost =
associated with that.  It's an interesting problem and I'd like to =
continue working on it.  \

Agreed - I think this would be really interesting!

>> I suspect this may well change some of the conclusions as larger =
block makers will definitely be able to create larger blocks than their =
smaller counterparts.
>=20
> It will be interesting to see.  I suspect that the main result that "a =
healthy fee market exists" will still hold (assuming of course that a =
single miner with >50% of the hash power isn't acting maliciously).  =
Whether miners with larger value of h/H have a profit advantage, I'm not =
sure (but that was outside the scope of the paper anyways).

I really look forward to seeing the revised version. Seeing the =
differences will also help assess how much impact there is from =
simplified models.


Regards,
Dave