public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tom Zander <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks
Date: Fri, 25 Nov 2016 16:25:58 +0100	[thread overview]
Message-ID: <61681436.SvSR6Fsd9n@strawberry> (raw)
In-Reply-To: <CAKzdR-r7or+DF64qxT=HLUvrtdkSQD0hpO43kUjfWS-397+yHA@mail.gmail.com>

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


  reply	other threads:[~2016-11-25 15:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-22 16:31 [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks Peter R
2016-11-25  1:39 ` Sergio Demian Lerner
2016-11-25 15:25   ` Tom Zander [this message]
2016-11-25 22:31     ` Sergio Demian Lerner
2016-11-25 23:45       ` Sergio Demian Lerner
2016-11-26 15:01         ` Tom Zander
2016-11-26 23:35           ` Peter R
2016-11-27  7:47             ` Tom Zander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=61681436.SvSR6Fsd9n@strawberry \
    --to=tomz@freedommail.ch \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox