Send bitcoin-dev mailing list submissions to
        bitcoin-dev@lists.linuxfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
        bitcoin-dev-request@lists.linuxfoundation.org

You can reach the person managing the list at
        bitcoin-dev-owner@lists.linuxfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."


Today's Topics:

   1. Re: Horizontal scaling of blockchain (Cserveny Tamas)
   2. Re: Horizontal scaling of blockchain (Thomas Guyot-Sionnest)
   3. Re: Horizontal scaling of blockchain (Tom Zander)
   4. Re: BIP49 Derivation scheme changes (Thomas Voegtlin)
   5. Re: Fwd:  "Compressed" headers stream (Peter Todd)
   6. Re: "Compressed" headers stream (Peter Todd)


----------------------------------------------------------------------

Message: 1
Date: Fri, 01 Sep 2017 18:15:53 +0000
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
Message-ID:
        <CACY+MSOPWhTnR-ZR67T1a5ZU2w4pWa6FkXsGF3_C+n3gKFCPSA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170901/d908e965/attachment-0001.html>

------------------------------

Message: 2
Date: Fri, 1 Sep 2017 15:40:44 -0400
From: Thomas Guyot-Sionnest <dermoth@aei.ca>
To: Cserveny Tamas <cserveny.tamas+bc@gmail.com>,       Bitcoin Protocol
        Discussion <bitcoin-dev@lists.linuxfoundation.org>,     Lucas Clemente
        Vella <lvella@gmail.com>, Tom Zander <tomz@freedommail.ch>
Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
Message-ID: <e9531342-db9b-ffdf-5ada-0c143eb89d9e@aei.ca>
Content-Type: text/plain; charset=windows-1252

On 01/09/17 02:15 PM, Cserveny Tamas via bitcoin-dev wrote:
> 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)
>

It wouldn't be less secure as long as you adjust the confirmation
accordingly. If we decided to mine one block every minute, then your
usual 6 confirmation should become 60 confirmation. In the end, the same
amount of work will have been done to prove the transaction is legit and
so it's just as secure... Actually, one could argue since the average
hash rate over 60 block is more accurate than over 6, it's actually more
secure if you also pay attention to hash rate variation as part of the
confirmation... That help in the scenario a very large pool goes dark to
mine a sidechain.

--
Thomas



------------------------------

Message: 3
Date: Sat, 02 Sep 2017 23:13:57 +0200
From: Tom Zander <tomz@freedommail.ch>
To: Cserveny Tamas <cserveny.tamas+bc@gmail.com>
Cc: Bitcoin Protocol Discussion
        <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
Message-ID: <3416963.LpSpYe5DLS@strawberry>
Content-Type: text/plain; charset="us-ascii"

On Friday, 1 September 2017 20:15:53 CEST Cserveny Tamas wrote:
> 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.

The real limit is set by the technology. Just like in 1990 we could not
fathom having something like YouTube and high-res video streaming (Netflix),
the limits of what is possible continually shifts.

This is basically how any successful product has ever grown, I think that it
is not just desirable, it is inevitable.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


------------------------------

Message: 4
Date: Sun, 3 Sep 2017 07:19:12 +0200
From: Thomas Voegtlin <thomasv@electrum.org>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
Message-ID: <5a27e555-173e-b5a7-8c05-5ee32e885ee2@electrum.org>
Content-Type: text/plain; charset=utf-8



On 30.08.2017 09:24, shiva sitamraju via bitcoin-dev wrote:

>
> 2. Segwit wallet seed words have a different format which is incompatible
> with previous wallet seed words. This  encodes the information that this
> wallet is segwit in the seed words itself. We need to define a structure
> for this
>

That is what Electrum does.
See http://docs.electrum.org/en/latest/seedphrase.html


------------------------------

Message: 5
Date: Mon, 4 Sep 2017 10:06:44 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <greg@xiph.org>,    Bitcoin Protocol Discussion
        <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fwd:  "Compressed" headers stream
Message-ID: <20170904140644.GF1276@fedora-23-dvm>
Content-Type: text/plain; charset="us-ascii"

On Mon, Aug 28, 2017 at 05:12:15PM +0000, Gregory Maxwell via bitcoin-dev wrote:
> You are leaving a lot of bytes on the table.
>
> The bits field can only change every 2016 blocks (4 bytes per header),
> the timestamp can not be less than the median of the last 11 and is
> usually only a small amount over the last one (saves 2 bytes per
> header), the block version is usually one of the last few (save 3
> bytes per header).
>
> But all these things improvements are just a constant factor. I think
> you want the compact SPV proofs described in the appendix of the
> sidechains whitepaper which creates log scaling proofs.

Note that I'm already planning on OpenTimestamps having infrastructure for
trusted validity attestations; log scaling proofs alone only prove total work,
not validity. Timestamping has all kinds of very dubious security properties
when done via proof-of-work, due to various ways that miners can get away with
inaccurate block times. In particular, setting a block time backwards is
something that miners can do, particularly with majority hashing power, which
is the exact thing we're trying to prevent in a timestamp proof.

This all makes me dubious about risking further weakening of this already weak
security with compact SPV proofs; we'd need a lot more analysis to understand
what we're risking. Also note that we can ship a known-good
sum-merkle-tree tip hash with the software, which further reduces initial
download bandwidth needed to get the block headers on top of this obviously
safe eliding of redundant hashes.

--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170904/8be560f7/attachment-0001.sig>

------------------------------

Message: 6
Date: Mon, 4 Sep 2017 10:10:17 -0400
From: Peter Todd <pete@petertodd.org>
To: Greg Sanders <gsanders87@gmail.com>,        Bitcoin Protocol Discussion
        <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] "Compressed" headers stream
Message-ID: <20170904141017.GG1276@fedora-23-dvm>
Content-Type: text/plain; charset="us-ascii"

On Mon, Aug 28, 2017 at 12:26:48PM -0400, Greg Sanders via bitcoin-dev wrote:
> Well, if anything my question may bolster your use-case. If there's a
> heavier chain that is invalid, I kind of doubt it matters for timestamping
> reasons.

Timestamping can easily be *more* vulnerable to malicious miners than financial
applications for a number of reasons, including the fact that there's no
financial feedback loop of miners destroying the value of the coins they
produce - timestamping is a non-financial piggy-back application that doesn't
directly interact with the Bitcoin economy, beyond a trival number of timestamp
transactions.

--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170904/818e9344/attachment.sig>

------------------------------

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


End of bitcoin-dev Digest, Vol 28, Issue 3
******************************************