From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0C844A84 for ; Tue, 5 Sep 2017 07:10:39 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from blockonomics.co (blockonomics.co [52.10.115.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 66739124 for ; Tue, 5 Sep 2017 07:10:37 +0000 (UTC) Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com [209.85.213.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by blockonomics.co (Postfix) with ESMTPSA id 7D1F91E0FC1 for ; Tue, 5 Sep 2017 07:10:36 +0000 (UTC) Received: by mail-vk0-f49.google.com with SMTP id v203so4542972vkv.3 for ; Tue, 05 Sep 2017 00:10:36 -0700 (PDT) X-Gm-Message-State: AHPjjUjniC5LpxWyXoReOy1yU8UFFa6PYzxXr+dVdXGZ/L61T7y48uH4 X1mAM+C1mbgC0jhF234gbSRtegeB9g== X-Google-Smtp-Source: ADKCNb43bCoB3+yCUSssj03MTsdPnSBcZY/nihiEKYpfAY/vi71n/MQXG89yP+0ZNpin34IM9DuyyOMKs9uaDyj0wTA= X-Received: by 10.31.204.194 with SMTP id c185mr1687927vkg.126.1504595435392; Tue, 05 Sep 2017 00:10:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.75.9 with HTTP; Tue, 5 Sep 2017 00:10:15 -0700 (PDT) From: shiva sitamraju Date: Tue, 5 Sep 2017 12:40:15 +0530 X-Gmail-Original-Message-ID: Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="94eb2c07d33a7515e905586beceb" X-Spam-Status: No, score=0.5 required=5.0 tests=HTML_MESSAGE, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 05 Sep 2017 14:36:59 +0000 Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 07:10:39 -0000 --94eb2c07d33a7515e905586beceb Content-Type: text/plain; charset="UTF-8" Hi, Thanks Thomas. The procedure described in http://docs.electrum.org/en/latest/seedphrase.html is really what I was looking for ! I really don't see any point of following BIP49, If possible it would be great if you can propose an alternative to BIP49 that follows similar structure to what is used in electrum. I have proposed following changes to BIP32 serialization format https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#serialization-format to differentiate segwit xpub/xprv. Below the list of new version bytes, resulting base58 prefix and network type: 0x042393df , sxpr , segwit mainnet private key 0x04239377 , sxpb , segwit mainnet public key 0x04222463 , stpb , segwit testnet public key 0x042224cc , stpr , segwit testnet private key Let me know your thoughts On Tue, Sep 5, 2017 at 12:12 AM, < bitcoin-dev-request@lists.linuxfoundation.org> wrote: > 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 > To: Lucas Clemente Vella , Tom Zander > , Bitcoin Protocol Discussion > > Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain > Message-ID: > 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 > 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: attachments/20170901/d908e965/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Fri, 1 Sep 2017 15:40:44 -0400 > From: Thomas Guyot-Sionnest > To: Cserveny Tamas , Bitcoin Protocol > Discussion , Lucas > Clemente > Vella , Tom Zander > Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain > Message-ID: > 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 > To: Cserveny Tamas > Cc: Bitcoin Protocol Discussion > > 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 > 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 > To: Gregory Maxwell , Bitcoin Protocol Discussion > > 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: attachments/20170904/8be560f7/attachment-0001.sig> > > ------------------------------ > > Message: 6 > Date: Mon, 4 Sep 2017 10:10:17 -0400 > From: Peter Todd > To: Greg Sanders , Bitcoin Protocol > Discussion > > 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: 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 > ****************************************** > --94eb2c07d33a7515e905586beceb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thanks Thomas. The procedu= re described in http://docs.electrum.org/en/latest/seedphrase.html is really what I= was looking for ! I really don't see any point of following BIP49, If = possible it would be great if you can propose an alternative to BIP49 that = follows similar structure to what is used in electrum.

I have = proposed following changes to BIP32 serialization format https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#serializa= tion-format to differentiate segwit xpub/xprv. Below the list of new ve= rsion bytes, resulting base58 prefix and network type:

0x042393df ,= =C2=A0 sxpr ,=C2=A0=C2=A0 segwit mainnet private key
0x04239377 , sxpb = , segwit mainnet public key
0x04222463 , stpb ,=C2=A0 segwit testnet pu= blic key
0x042224cc ,=C2=A0 stpr ,=C2=A0 segwit testnet private key=C2= =A0

Let me know your thoughts

On Tue, Sep 5, 2017 = at 12:12 AM, <bitcoin-dev-request@lists.linux= foundation.org> wrote:
Send bitcoin-dev mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev@lists.linuxfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://li= sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev-request@lists.linuxfoundation.org
You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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:

=C2=A0 =C2=A01. Re: Horizontal scaling of blockchain (Cserveny Tamas)
=C2=A0 =C2=A02. Re: Horizontal scaling of blockchain (Thomas Guyot-Sionnest= )
=C2=A0 =C2=A03. Re: Horizontal scaling of blockchain (Tom Zander)
=C2=A0 =C2=A04. Re: BIP49 Derivation scheme changes (Thomas Voegtlin)
=C2=A0 =C2=A05. Re: Fwd:=C2=A0 "Compressed" headers stream (Peter= Todd)
=C2=A0 =C2=A06. Re: "Compressed" headers stream (Peter Todd)


-----------------------------------------------------------------= -----

Message: 1
Date: Fri, 01 Sep 2017 18:15:53 +0000
From: Cserveny Tamas <c= serveny.tamas+bc@gmail.com>
To: Lucas Clemente Vella <lvella@gma= il.com>, Tom Zander
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <tomz= @freedommail.ch>,=C2=A0 Bitcoin Protocol Discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CACY+MSOPWhTnR-ZR67T1a5= ZU2w4pWa6FkXsGF3_C+n3gKFCPSA@mail.gmail.com>
Content-Type: text/plain; charset=3D"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<= br> 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,<= br> 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 w= e
>> completely removed this bottle-neck.
>> The transactions will be validated continuously, in parallel and n= ot 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 distrib= uted
> system behaves as single threaded computation. OP seems to be describi= ng a
> system closer to what IOTA uses, by distributing among the miners the = task
> of validating the transactions. Although, without more specific detail= s, 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/<= wbr>attachments/20170901/d908e965/attachment-0001.html>

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

Message: 2
Date: Fri, 1 Sep 2017 15:40:44 -0400
From: Thomas Guyot-Sionnest <dermoth@a= ei.ca>
To: Cserveny Tamas <cse= rveny.tamas+bc@gmail.com>,=C2=A0 =C2=A0 =C2=A0 =C2=A0Bitcoin Protoco= l
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Discussion <bitcoin-dev@lists.linuxfoundation.org>= ,=C2=A0 =C2=A0 =C2=A0Lucas Clemente
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Vella <l= vella@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=3Dwindows-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 mor= e
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@freedommai= l.ch>
To: Cserveny Tamas <cse= rveny.tamas+bc@gmail.com>
Cc: Bitcoin Protocol Discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
Message-ID: <3416963.LpSpYe5DLS@strawberry>
Content-Type: text/plain; charset=3D"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 w= hat
> 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 i= t
is not just desirable, it is inevitable.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel<= /a>


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

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



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

>
> 2. Segwit wallet seed words have a different format which is incompati= ble
> with previous wallet seed words. This=C2=A0 encodes the information th= at this
> wallet is segwit in the seed words itself. We need to define a structu= re
> for this
>

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


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

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

On Mon, Aug 28, 2017 at 05:12:15PM +0000, Gregory Maxwell via bitcoin-dev w= rote:
> 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<= br> > 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 wo= rk,
not validity. Timestamping has all kinds of very dubious security propertie= s
when done via proof-of-work, due to various ways that miners can get away w= ith
inaccurate block times. In particular, setting a block time backwards is something that miners can do, particularly with majority hashing power, whi= ch
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 w= eak
security with compact SPV proofs; we'd need a lot more analysis to unde= rstand
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.

--
http= s://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.o= rg>
To: Greg Sanders <gsanders87@gma= il.com>,=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bitcoin Protocol Discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] "Compressed" headers stream
Message-ID: <20170904141017.GG1276@fedora-23-dvm>
Content-Type: text/plain; charset=3D"us-ascii"

On Mon, Aug 28, 2017 at 12:26:48PM -0400, Greg Sanders via bitcoin-dev wrot= e:
> 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 timestam= ping
> reasons.

Timestamping can easily be *more* vulnerable to malicious miners than finan= cial
applications for a number of reasons, including the fact that there's n= o
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 times= tamp
transactions.

--
http= s://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/at= tachments/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
******************************************

--94eb2c07d33a7515e905586beceb--