Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit

[Michael Naber <mickeybob@gmail.com>]

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

Global network consensus means that there is global network recognition
that a particular transaction has occurred and is irreversible. The
off-chain solutions you describe, while probably useful for other purposes,
do not exhibit this characteristic and so they are not global network
consensus networks.

Bitcoin Core scales as O(N), where N is the number of transactions. Can we
do better than this while still achieving global consensus?


On Sat, Jun 27, 2015 at 12:37 PM, Peter Todd <pete@petertodd.org> wrote:

> On Sat, Jun 27, 2015 at 12:09:16PM -0400, Michael Naber wrote:
> > The goal of Bitcoin Core is to meet the demand for global consensus as
> > effectively as possible. Please let's keep the conversation on how to
> best
> > meet that goal.
>
> Keep in mind that Andresen and Hearn both propose that the majority of
> Bitcoin users, even businesses, abandon the global consensus technology
> aspect of Bitcoin - running full nodes - and instead adopt trust
> technology instead - running SPV nodes.
>
> We're very much focused on meeting the demand for global consensus
> technology, but unfortunately global consensus is also has inherently
> O(n^2) scaling with current approaches available. Thus we have a fixed
> capacity system where access is mediated by supply and demand
> transaction fees.
>
> > The off-chain solutions you enumerate are are useful solutions in their
> > respective domains, but none of them solves the global consensus problem
> > with any greater efficiency than Bitcoin does.
>
> Solutions like (hub-and-spoke) payment channels, Lightning, etc. allow
> users of the global consensus technology in Bitcoin to use that
> technology in much more effcient ways, leveraging a relatively small
> amount of global consensus to do large numbers of transactions
> trustlessly.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>

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