On Fri, Nov 25, 2016 at 12:25 PM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thursday, 24 November 2016 22:39:05 CET Sergio Demian Lerner via
> bitcoin-
> dev wrote:
> > Without a detailed analysis, unlimited block size seems a risky change to
> > Bitcoin, to me.
>
> What exactly do you think is a ‘change’ in bitcoin here?
>
> A change is anything that modifies with a HF the current state of the
Bitcoin Core implementation of the consensus protocol. Sadly (or happily,
for some) there is no "abstract" definition of Bitcoin.



> The concept of proof-of-work is that the longer a chain, the higher
> probability that that one will be extended for the simple reason that
> another chain will have to show a higher amount of proof of work to ‘win’.
>
> We know what Bitcoin the protocol dictates, but if what the protocol
dictates is not in the best interest of miners or full-nodes? then they
will simply choose a rule that maximizes their revenue (or any other
measure of performance, such as lower latency, or less transaction reversal
probability).


As far as I understand the document from Peter, there is no change there at
> all. Only chains with more POW will win.
>

I haven't gone to the code to check, but the video Peter sent does not say
that. It says that miners will mine on top of a block ONLY if the "gate"
has been opened for that block (e.g. there is additional blocks to push a
big block). So a miner having a preferring low block sizes will choose to
mine on top of the A1,A2,A3 chain (3 units of work), while miners
supporting bigger sizes will mine on top of the chain B1,S2,S3,S4 (4 units
of work).

Saying that the chain starting with B1 is not considered by a node X does
not mean that the node X is blind to the information that can be extracted
from the fact that there is a chain of 4 blocks starting from B1.
If there is more information, there may be a better local choice. If there
are better local choices, there is probably a better global equilibrium (or
not equilibrium at all).


> Or, to answer your example, miners will prefer to extend the chain with the
> most POW.
>

Clearly this is not universal: some miners will, and some other miners
won't, because some miners have postponed adding some blocks.



>
> The other fact stays the same as well, if you protect from reorgs by
> expecting more confirmations. Nothing changes here either. The
> common-sense 6
> confirmations for things like exchange-deposits keep having the same
> security.
>

Suppose that I provide a service that accepts payments with 2
confirmations, and in certain time I have the information that the network
is at the same time considering the forks B1 S2 and A1 A2. Then the best I
can do is NOT to accept the 2-confirmation and wait for a resolution of the
fork. Choosing either fork may put me at the risk of immediate reversal.

The existence of fork information changes equilibrium decision to choose
the longest-chain.  This is the same that happens with the GHOST protocol:
the information on the existence of uncles changes the local incentives to
choose the longest chain to some different strategy, and when all nodes
change their strategy, then the supposedly last equilibrium state is that
all follow the GHOST strategy for choosing the heaviest chain.


>
> The basic idea that we have a 3 or 4 deep fork is a huge problem in
> Bitcoin.
> It hasn’t happened for ages, and we like it that way. The miners like it
> that way too. Its disruptive.
> The is a problem that is not created by the ‘excessive block’ concept. It
> does, however, provide a possible solution to this very far-fetched
> problem.
>
> You should also realize that the policy of a miner is stored in the
> coinbase.
>
> This is important, but yet the full node does not use this information
automatically. The amount of confirmations that a node accepts is not
affected by the miner's policies or the size of the blocks mined, but it
should.


> That said, I’m sure there are improvements to be made to the policy that BU
> uses.


Probably a simple wise addition would be to estimate the accepted block
size for the majority of the miners (S), and only count block confirmations
for wallet transactions taking into account only blocks whose size is lower
or equal than S. So for example, if Alice receives a transaction T in block
B1 and it is confirmed by block B2, but size(B1)>S and size(B2)>S, then the
wallet should tell Alice that transaction T has 0 confirmations. This local
strategy reduces the chances that Alice accept T but is then easily
reversed for the opposite fork growing one block ahead.

Regards,
 Sergio