[bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

[bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

[Peter R]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

Dear all,

Bitcoin Unlimited’s market-based solution to the block-size limit is slowly winning support from node operators and miners.  With this increased attention, many people are asking for a better explanation of how Bitcoin Unlimited actually works.  The article linked below describes how Bitcoin Unlimited’s excessive-block logic works from the perspective of a single node. (I’m hoping to do a follow-up article that describe how this “node-scale” behavior facilitates the emergence of a fluid and organic block size limit at the network scale.)

https://medium.com/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4 <https://medium.com/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4>

Best regards,
Peter R

[-- Attachment #2: Type: text/html, Size: 1241 bytes --]

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

Hi Peter,

How would a person or exchange decide to accept a payment in BU if it does
not know the gate policy of 51% of the miners?

Suppose that the exchange receives B1,S2,S3,S4 (a big block at height 1,
and 3 small blocks at height 2, 3 and 4), and an alternate chain A1,A2,A3
(three small blocks). The first is the longest, but the second may be the
one 51% of the miners will extend.

Without knowing  the policy of at least 51% of the miners (the maximum
acceptance depth) it's unclear if the exchange has to obey the longest
chain or the chain with higher probability of being extended.
If the maximum acceptance depth of the majority of miners is higher than 6
blocks, accepting a transaction with 6 confirmations is risky.
So BU would set a lower bound on the number of confirmations equal to the
maximum acceptance depth of the majority of miners.But miners do not
publish their acceptance depth, so basically users are clue-less. I think
miners should at least advertise their gate block size and acceptance depth
in their coinbase field.

Is there a game-theoretic analysis of confirmation blocks and their
probabilities in BU ?
Without a detailed analysis, unlimited block size seems a risky change to
Bitcoin, to me.

Regards, Sergio.



On Tue, Nov 22, 2016 at 1:31 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Dear all,
>
> Bitcoin Unlimited’s market-based solution to the block-size limit is
> slowly winning support from node operators and miners.  With this increased
> attention, many people are asking for a better explanation of how Bitcoin
> Unlimited actually works.  The article linked below describes how Bitcoin
> Unlimited’s excessive-block logic works from the perspective of a single
> node. (I’m hoping to do a follow-up article that describe how this
> “node-scale” behavior facilitates the emergence of a fluid and organic
> block size limit at the network scale.)
>
> https://medium.com/@peter_r/the-excessive-block-gate-how-
> a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4
>
> Best regards,
> Peter R
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3228 bytes --]

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

[Tom Zander]

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?

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’.

As far as I understand the document from Peter, there is no change there at 
all. Only chains with more POW will win.
Or, to answer your example, miners will prefer to extend the chain with the 
most POW.

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.

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.

That said, I’m sure there are improvements to be made to the policy that BU 
uses. But since this is a node-local policy, the consensus rules are not 
affected by it.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 4793 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6259 bytes --]

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 5829 bytes --]

I now think my reasoning and conclusions are based on a false premise: that
BU block size policies for miners can be heterogeneous.

There can't be short forks because forks are not in the best interest of
the honest miner majority. All miners need to announce and follow the same
block size policy to prevent short forks.

The incentives are established so that all block size negotiations will be
carried between miners in a off-chain manner, not by modifying the policy
nor by announcing anything in the coinbase,

If block size negotiations are meant to be open and carried on on-chain,
then it's much better to let miners increase or decrease the block size
limit by 1% per block (such as what Ethereum does with the gas limit).





On Fri, Nov 25, 2016 at 7:31 PM, Sergio Demian Lerner <
sergio.d.lerner@gmail.com> wrote:

>
>
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 7634 bytes --]

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

[Tom Zander]

On Friday, 25 November 2016 20:45:20 CET Sergio Demian Lerner wrote:
> I now think my reasoning and conclusions are based on a false premise:
> that BU block size policies for miners can be heterogeneous.

Agreed.
 
> There can't be short forks because forks are not in the best interest of
> the honest miner majority. All miners need to announce and follow the same
> block size policy to prevent short forks.

What you appear to want to say is that it is in everyones best interest to 
avoid short forks.
Its impossible to guarentee they can't happen, but very possible to minimize 
them.
 
> If block size negotiations are meant to be open and carried on on-chain,
> then it's much better to let miners increase or decrease the block size
> limit by 1% per block (such as what Ethereum does with the gas limit).

No, there are no block-size-negotiations on chain.

The blockchain is used here for one purpose, to state the position of 
individual miners. But what may not be clear is that you can use this as a 
time-stamped way to hold them to it. Which means that if they lie (by 
rejecting a block), everyone in the world will be able to individually 
verify that fact and their credibility will be affected.

Which will not help their case next time any block size negotiations will 
happen.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

[Peter R]

[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]

Great discussion, Sergio and Tom!

> I now think my reasoning and conclusions are based on a false premise: that BU block size policies for miners can be heterogeneous.


Right, miners who set their block size limits (BSL) above OR below the "effective BSL" are disadvantaged.  Imagine that we plot the distribution (by hash power) for all miners' BSLs.  We might get a chart that looks like this:

http://imgur.com/a/tWNr6 <http://imgur.com/a/tWNr6>

In this chart, the "effective BSL" is defined as the largest block size that no less than half the hash power will accept.  

If a block is mined with a size Q that is less than the "effective BSL," then all the hash power with BSLs between BSL_min and Q will be forked from the longest chain (until they update their software if they're running Core or until their acceptance depth is hit if they're running BU).  This wastes these miners' hash power.  

However, if a block is mined with a size Q that is greater than the effective BSL, then all the hash power with BSLs between Q and BSL_max will temporarily be mining on a "destined to be orphaned" chain.  This also wastes these miners' hash power.  

Therefore, it is in the best interest of miners to all set the same block size limit (and reliably signal in their coinbase TX what that limit is, as done by Bitcoin Unlimited miners).  

We have empirical evidence the miners in fact behave this way: 

(1) No major miner has ever set his block size limit to less than 1 MB (not even those such as Luke-Jr who think 1 MB is too big) because doing so would just waste money.  

(2) After switching to Bitcoin Unlimited, both ViaBTC and the Bitcoin.com pool temporarily set their BSLs to 2 MB and 16 MB, respectively (of course keeping their _generation limit_ at 1MB).  However, both miners quickly reduced these limits back to 1 MB when they realized how it was possible to lose money in an attack scenario.  (This actually surprised me because the only way they could lose money is if some _other_ miner wasted even more money by purposely mining a destined-to-be-orphaned block.)   

The follow-up article I'm working on is about the topics we're discussing now, particularly about how Bitcoin Unlimited's “node-scale” behavior facilitates the emergence of a fluid and organic block size limit at the network scale.  Happy to keep continue with this current discussion, however.

Best regards
Peter


[-- Attachment #2: Type: text/html, Size: 3488 bytes --]

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

[Tom Zander]

On Saturday, 26 November 2016 15:35:49 CET Peter R via bitcoin-dev wrote:
> Therefore, it is in the best interest of miners to all set the same block
> size limit (and reliably signal in their coinbase TX what that limit is,
> as done by Bitcoin Unlimited miners).

As a point of interest, last week I merged into Classic the same concept. 
Classic will now respect the EB limit and put it in the coinbase.

>  (This actually surprised me because the only way they could lose money is
>  if some _other_ miner wasted even more money by purposely mining a
>  destined-to-be-orphaned block.)

Your surprise may come from the difference in cost vs. expected earnings of 
creating a block, which is quite significant.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel