Re: [bitcoin-dev] Your Gmaxwell exchange

[Gregory Maxwell <gmaxwell@gmail.com>]

On Sun, Aug 30, 2015 at 4:13 AM, Peter R <peter_r@gmx.com> wrote:
> I agree that miners may change their level of centralization.  This neither
> affects the model nor the results presented in the paper.

It has tremdous significance to the real-world impact of your results.

If not for the other errors in your work, this point would make the
take away of your work not "a healthy transaction fee market exists
without a block size limit" but rather "a decenteralized bitcoin
cannot exist"-- as, accepting the other errors as fact your model
shows that centralizing mining is always strictly more profitable at
any level of fee demand; because your model equivilent shows that for
any level of fee demand and gamma miners could increase their income
by centeralizing further.

I absolutely agree that simplifications are useful and essential, but
it is critically important to call them out before someone mistakes
theoretical work as useful motivation for policy in the non-simplified
system.

> -- Instead the same information can be transmitted _in advance_, as
> has been previously proposed, and various techniques can make doing
> so arbitrarily efficient.
>
> I assume, very reasonably, that the block solutions contain information
> about the transactions included in the block.  This is the case today, this
> is the case using the relay network, and this would be the case using any
> compression scheme I can personally imagine actually occurring in the
> future.

This assumption is unreasonable, and does not-- in fact-- accurately
reflect the situation today.

For example it does not reflect how hashers return work to pools
_today_ (and since 2011) as they so to only by referencing the merkel
root... the pool already knows the  transaction set. In that
particular case it knows it because it selected it to begin with, but
the same behavior holds if the hasher selects the transaction set and
sends it first.

It only _very_ weakly reflects how the relay protocol works (only the
selection and permutation is communicated; not the transaction data
itself; for already known transactions). Even if you assume nothing
more than that (in spite of the existing reality) you have not shown
that the compressed data must be linear in the size of the block.

It does not reflect how P2Pool works (which also sends the
transactions in advance).

There is a simple, and intuitive understanding that does not require
any complex supposition:  You argue that the information must be
transfered when a block is found, thus delaying it.  I point out, no,
any required information (to the extent that there is any at all after
efficient encoding) can be sent in advance of the block.

I believe that you've allowed the fact that the specifc example block
relay protocol doesn't bother sending _all_ information in advance to
confuse it for mere compression.

> My public comments have been factual.  I've even gone out of my way in
> several public threads to point out your objection that the coding gain
> could be zero (even though I think it is flawed "black-and-white thinking"
> about an academic scenario that will never unfold and might actually be
> physically impossible without Bitcoin already being centralized).

I believe my reponses are firmly grounded in the physical reality of
actually deployed systems and constructable protocols.

By comparison, even if I were to agree that the bound is not actually
exactly 0 proporionality  you have already agreed that with
"compression" the amount sent could be arbritarily low. The result
being that the behavior you're describing would only be asymptoic and
have no relationship to the actual Bitcoin system that exists in a
finite universe.

But you continue to demand debate over this meaningless point.

> I'll end by saying that I am the one describing things as the presently are.
> You are talking about a hypothetical future that may or may not exist (and
> may not even be possible).  The results of my paper logically follow from
> the assumptions made. You think the assumption that "block solutions contain
> information about the transactions included in the block" will not hold in
> the future.  Can you show:
>
> (a) Under what assumptions/requirements your communication scheme is
> physically possible.

Pratically every block today is mined under a protocol which does not
need to communicate anything but constant data when a block is found.

I am getting a little tired of people suggesting things which are
widely deployed are not physically possible.

Yes, that particular example is not the most powerful form of that
idea-- but it has the benefit of _universal_ use.

> (b) That such a configuration is not equivalent to a single entity[1]
> controlling >50% of the hash power.

I find this a little amusing. Even in this messsage you defend
ignoring of centeralization considerations in your paper. But here ask
that I address concerns which you refused to suggest. Why do you
demand my correction use weaker assumptions than your work?

That said-- I already gave you a fairly concrete description of a
pratical protocol which would accomplish your requirement ( (a) reduce
the information transmitted in a latency critical way at block
discovery time to O(1) network wide, (b) without creating
centeralization in chain or transaction selection). I believe my
description in the messages was adequate that anyone working on
Bitcoin Core could go implement a version of it, at least.  You appear
to have simply ignrored it.

If the actual technical details made your eyes glaze over I also
offered a simple intutive understanding:  The no proportional
information need be transfered at the latency critical time, because
it can be transfered in _advance_. Everything beyond that is just
efficiency optimizations to reduce the cost of doing the advanced
transmission.

> (c) That the network moving into such a configuration is plausible.

That it already uses advanced information techniques in every widely
used mining protocol, that the relay protocol was rapidly adopted, and
that your own model would suggest significant profits from any such
improvement would seem to remove any doubt related to (c)... and again
here you hold me to a higher bar than your own work: as nowhere do you
show that the "limits" your model erroniously extracts are plausable
as limits, and in private you seemed to admit to me that they may well
not be.