From: Cserveny Tamas <cserveny.tamas+bc@gmail•com>
To: Lucas Clemente Vella <lvella@gmail•com>,
Tom Zander <tomz@freedommail•ch>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
Date: Fri, 01 Sep 2017 18:15:53 +0000 [thread overview]
Message-ID: <CACY+MSOPWhTnR-ZR67T1a5ZU2w4pWa6FkXsGF3_C+n3gKFCPSA@mail.gmail.com> (raw)
In-Reply-To: <CAGCathxjDsST6xD+CvKN_3md3UcWuKqgSvV+CjaTqS4gPaPGZg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]
Yes. I meant the single thread as an analogy, if a block is found, other
blocks are worthless. (more or less) Longest chain wins.
My line of though was, that currently the only way to scale with the
traffic (and lowering the fees) is increasing the block size (which is hard
as I learned from recent events), or reducing the complexity which is less
secure (most likely more controversial)
Splitting the chain is effectively increasing the block size, but without
the increased hashing and validation overhead.
The usage growth seems to be more of exponential rather than linear. Sooner
or later the block size will need to be 4 mb then 40 mb, then what is the
real limit? Otherwise waiting times and thus the fees will just grow
rapidly. I don't think that it is desirable.
With splitting the ledger, the block size can remain 1-2 mb for long time,
only new partitions needs to be added on a schedule. This would also make
better use of the hashing capacity.
Cheers,
Tamas
On Fri, Sep 1, 2017 at 7:15 PM Lucas Clemente Vella <lvella@gmail•com>
wrote:
> > The current chain is effectively single threaded.
>>
>> This is not true, since xthin/compactblocks have been introduced we
>> completely removed this bottle-neck.
>> The transactions will be validated continuously, in parallel and not just
>> when a block is found.
>>
>
> If I understood correctly, OP was not talking about the process inside a
> node being single threaded, but instead that the whole bitcoin distributed
> system behaves as single threaded computation. OP seems to be describing a
> system closer to what IOTA uses, by distributing among the miners the task
> of validating the transactions. Although, without more specific details, it
> is hard to judge the benefits.
>
> --
> Lucas Clemente Vella
> lvella@gmail•com
>
[-- Attachment #2: Type: text/html, Size: 2862 bytes --]
next prev parent reply other threads:[~2017-09-01 18:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-01 12:47 Cserveny Tamas
2017-09-01 13:12 ` Tom Zander
2017-09-01 17:15 ` Lucas Clemente Vella
2017-09-01 17:24 ` Thomas Guyot-Sionnest
2017-09-01 18:15 ` Cserveny Tamas [this message]
2017-09-01 19:40 ` Thomas Guyot-Sionnest
2017-09-02 21:13 ` 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=CACY+MSOPWhTnR-ZR67T1a5ZU2w4pWa6FkXsGF3_C+n3gKFCPSA@mail.gmail.com \
--to=cserveny.tamas+bc@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lvella@gmail$(echo .)com \
--cc=tomz@freedommail$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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