From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
To: Peter R <peter_r@gmx.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks
Date: Thu, 24 Nov 2016 22:39:05 -0300 [thread overview]
Message-ID: <CAKzdR-r7or+DF64qxT=HLUvrtdkSQD0hpO43kUjfWS-397+yHA@mail.gmail.com> (raw)
In-Reply-To: <C10BF9D1-435D-47C9-B98C-9B118B5922A1@gmx.com>
[-- 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 --]
next prev parent reply other threads:[~2016-11-25 1:39 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 [this message]
2016-11-25 15:25 ` Tom Zander
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='CAKzdR-r7or+DF64qxT=HLUvrtdkSQD0hpO43kUjfWS-397+yHA@mail.gmail.com' \
--to=sergio.d.lerner@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=peter_r@gmx.com \
/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