š
Original date posted:2017-09-05
š Original message: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 at lists.linuxfoundation.org> wrote:
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at 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 at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner at 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 at gmail.com>
> To: Lucas Clemente Vella <lvella at gmail.com>, Tom Zander
> <tomz at freedommail.ch>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
> Message-ID:
> <CACY+MSOPWhTnR-ZR67T1a5ZU2w4pWa6FkXsGF3_C+
> n3gKFCPSA at 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 at 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 at 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 at aei.ca>
> To: Cserveny Tamas <cserveny.tamas+bc at gmail.com>, Bitcoin Protocol
> Discussion <bitcoin-dev at lists.linuxfoundation.org>, Lucas
> Clemente
> Vella <lvella at gmail.com>, Tom Zander <tomz at freedommail.ch>
> Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
> Message-ID: <e9531342-db9b-ffdf-5ada-0c143eb89d9e at 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 at freedommail.ch>
> To: Cserveny Tamas <cserveny.tamas+bc at gmail.com>
> Cc: Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
> Message-ID: <3416963.LpSpYe5DLS at 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 at electrum.org>
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
> Message-ID: <5a27e555-173e-b5a7-8c05-5ee32e885ee2 at 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 at petertodd.org>
> To: Gregory Maxwell <greg at xiph.org>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Fwd: "Compressed" headers stream
> Message-ID: <20170904140644.GF1276 at 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 at petertodd.org>
> To: Greg Sanders <gsanders87 at gmail.com>, Bitcoin Protocol
> Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] "Compressed" headers stream
> Message-ID: <20170904141017.GG1276 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> End of bitcoin-dev Digest, Vol 28, Issue 3
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170905/a3ece874/attachment-0001.html>;
shiva sitamraju [ARCHIVE] /
npub1wwā¦f0lea
2023-06-07 18:05:15
in reply to nevent1qā¦k2j9
Author Public Key
npub1wwezatsega0v4lf66asgkktymkxxj0lncgn4tef5l7q4xvhd0h0qyf0leaPublished at
2023-06-07 18:05:15Event JSON
{
"id": "769d12378b990bae613bbdee6b66c7418f81eb0a8f9e1a3d5badba5948e27002",
"pubkey": "73b22eae19475ecafd3ad7608b5964dd8c693ff3c22755e534ff815332ed7dde",
"created_at": 1686161115,
"kind": 1,
"tags": [
[
"e",
"46b44a34d77fcd68c66c473be695da22e57d2f60e66adebec21f1b5ec82f088c",
"",
"root"
],
[
"e",
"4aa932285b3523c48946bef7ad497c8ca4e55126c6870ec539a425207325e884",
"",
"reply"
],
[
"p",
"7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05"
]
],
"content": "š
Original date posted:2017-09-05\nš Original message:Hi,\n\nThanks Thomas. The procedure described in\nhttp://docs.electrum.org/en/latest/seedphrase.html is really what I was\nlooking for ! I really don't see any point of following BIP49, If possible\nit would be great if you can propose an alternative to BIP49 that follows\nsimilar structure to what is used in electrum.\n\nI have proposed following changes to BIP32 serialization format\nhttps://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#serialization-format\nto differentiate segwit xpub/xprv. Below the list of new version bytes,\nresulting base58 prefix and network type:\n\n0x042393df , sxpr , segwit mainnet private key\n0x04239377 , sxpb , segwit mainnet public key\n0x04222463 , stpb , segwit testnet public key\n0x042224cc , stpr , segwit testnet private key\n\nLet me know your thoughts\n\nOn Tue, Sep 5, 2017 at 12:12 AM, \u003c\nbitcoin-dev-request at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Send bitcoin-dev mailing list submissions to\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\n\u003e To subscribe or unsubscribe via the World Wide Web, visit\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e or, via email, send a message with subject or body 'help' to\n\u003e bitcoin-dev-request at lists.linuxfoundation.org\n\u003e\n\u003e You can reach the person managing the list at\n\u003e bitcoin-dev-owner at lists.linuxfoundation.org\n\u003e\n\u003e When replying, please edit your Subject line so it is more specific\n\u003e than \"Re: Contents of bitcoin-dev digest...\"\n\u003e\n\u003e\n\u003e Today's Topics:\n\u003e\n\u003e 1. Re: Horizontal scaling of blockchain (Cserveny Tamas)\n\u003e 2. Re: Horizontal scaling of blockchain (Thomas Guyot-Sionnest)\n\u003e 3. Re: Horizontal scaling of blockchain (Tom Zander)\n\u003e 4. Re: BIP49 Derivation scheme changes (Thomas Voegtlin)\n\u003e 5. Re: Fwd: \"Compressed\" headers stream (Peter Todd)\n\u003e 6. Re: \"Compressed\" headers stream (Peter Todd)\n\u003e\n\u003e\n\u003e ----------------------------------------------------------------------\n\u003e\n\u003e Message: 1\n\u003e Date: Fri, 01 Sep 2017 18:15:53 +0000\n\u003e From: Cserveny Tamas \u003ccserveny.tamas+bc at gmail.com\u003e\n\u003e To: Lucas Clemente Vella \u003clvella at gmail.com\u003e, Tom Zander\n\u003e \u003ctomz at freedommail.ch\u003e, Bitcoin Protocol Discussion\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain\n\u003e Message-ID:\n\u003e \u003cCACY+MSOPWhTnR-ZR67T1a5ZU2w4pWa6FkXsGF3_C+\n\u003e n3gKFCPSA at mail.gmail.com\u003e\n\u003e Content-Type: text/plain; charset=\"utf-8\"\n\u003e\n\u003e Yes. I meant the single thread as an analogy, if a block is found, other\n\u003e blocks are worthless. (more or less) Longest chain wins.\n\u003e\n\u003e My line of though was, that currently the only way to scale with the\n\u003e traffic (and lowering the fees) is increasing the block size (which is hard\n\u003e as I learned from recent events), or reducing the complexity which is less\n\u003e secure (most likely more controversial)\n\u003e\n\u003e Splitting the chain is effectively increasing the block size, but without\n\u003e the increased hashing and validation overhead.\n\u003e\n\u003e The usage growth seems to be more of exponential rather than linear. Sooner\n\u003e or later the block size will need to be 4 mb then 40 mb, then what is the\n\u003e real limit? Otherwise waiting times and thus the fees will just grow\n\u003e rapidly. I don't think that it is desirable.\n\u003e\n\u003e With splitting the ledger, the block size can remain 1-2 mb for long time,\n\u003e only new partitions needs to be added on a schedule. This would also make\n\u003e better use of the hashing capacity.\n\u003e\n\u003e Cheers,\n\u003e\n\u003e Tamas\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On Fri, Sep 1, 2017 at 7:15 PM Lucas Clemente Vella \u003clvella at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e \u003e \u003e The current chain is effectively single threaded.\n\u003e \u003e\u003e\n\u003e \u003e\u003e This is not true, since xthin/compactblocks have been introduced we\n\u003e \u003e\u003e completely removed this bottle-neck.\n\u003e \u003e\u003e The transactions will be validated continuously, in parallel and not\n\u003e just\n\u003e \u003e\u003e when a block is found.\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003e If I understood correctly, OP was not talking about the process inside a\n\u003e \u003e node being single threaded, but instead that the whole bitcoin\n\u003e distributed\n\u003e \u003e system behaves as single threaded computation. OP seems to be describing\n\u003e a\n\u003e \u003e system closer to what IOTA uses, by distributing among the miners the\n\u003e task\n\u003e \u003e of validating the transactions. Although, without more specific details,\n\u003e it\n\u003e \u003e is hard to judge the benefits.\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e Lucas Clemente Vella\n\u003e \u003e lvella at gmail.com\n\u003e \u003e\n\u003e -------------- next part --------------\n\u003e An HTML attachment was scrubbed...\n\u003e URL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/\n\u003e attachments/20170901/d908e965/attachment-0001.html\u003e\n\u003e\n\u003e ------------------------------\n\u003e\n\u003e Message: 2\n\u003e Date: Fri, 1 Sep 2017 15:40:44 -0400\n\u003e From: Thomas Guyot-Sionnest \u003cdermoth at aei.ca\u003e\n\u003e To: Cserveny Tamas \u003ccserveny.tamas+bc at gmail.com\u003e, Bitcoin Protocol\n\u003e Discussion \u003cbitcoin-dev at lists.linuxfoundation.org\u003e, Lucas\n\u003e Clemente\n\u003e Vella \u003clvella at gmail.com\u003e, Tom Zander \u003ctomz at freedommail.ch\u003e\n\u003e Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain\n\u003e Message-ID: \u003ce9531342-db9b-ffdf-5ada-0c143eb89d9e at aei.ca\u003e\n\u003e Content-Type: text/plain; charset=windows-1252\n\u003e\n\u003e On 01/09/17 02:15 PM, Cserveny Tamas via bitcoin-dev wrote:\n\u003e \u003e Yes. I meant the single thread as an analogy, if a block is found,\n\u003e \u003e other blocks are worthless. (more or less) Longest chain wins.\n\u003e \u003e\n\u003e \u003e My line of though was, that currently the only way to scale with the\n\u003e \u003e traffic (and lowering the fees) is increasing the block size (which is\n\u003e \u003e hard as I learned from recent events), or reducing the complexity\n\u003e \u003e which is less secure (most likely more controversial)\n\u003e \u003e\n\u003e\n\u003e It wouldn't be less secure as long as you adjust the confirmation\n\u003e accordingly. If we decided to mine one block every minute, then your\n\u003e usual 6 confirmation should become 60 confirmation. In the end, the same\n\u003e amount of work will have been done to prove the transaction is legit and\n\u003e so it's just as secure... Actually, one could argue since the average\n\u003e hash rate over 60 block is more accurate than over 6, it's actually more\n\u003e secure if you also pay attention to hash rate variation as part of the\n\u003e confirmation... That help in the scenario a very large pool goes dark to\n\u003e mine a sidechain.\n\u003e\n\u003e --\n\u003e Thomas\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------\n\u003e\n\u003e Message: 3\n\u003e Date: Sat, 02 Sep 2017 23:13:57 +0200\n\u003e From: Tom Zander \u003ctomz at freedommail.ch\u003e\n\u003e To: Cserveny Tamas \u003ccserveny.tamas+bc at gmail.com\u003e\n\u003e Cc: Bitcoin Protocol Discussion\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain\n\u003e Message-ID: \u003c3416963.LpSpYe5DLS at strawberry\u003e\n\u003e Content-Type: text/plain; charset=\"us-ascii\"\n\u003e\n\u003e On Friday, 1 September 2017 20:15:53 CEST Cserveny Tamas wrote:\n\u003e \u003e The usage growth seems to be more of exponential rather than linear.\n\u003e \u003e Sooner or later the block size will need to be 4 mb then 40 mb, then what\n\u003e \u003e is the real limit? Otherwise waiting times and thus the fees will just\n\u003e \u003e grow rapidly. I don't think that it is desirable.\n\u003e\n\u003e The real limit is set by the technology. Just like in 1990 we could not\n\u003e fathom having something like YouTube and high-res video streaming\n\u003e (Netflix),\n\u003e the limits of what is possible continually shifts.\n\u003e\n\u003e This is basically how any successful product has ever grown, I think that\n\u003e it\n\u003e is not just desirable, it is inevitable.\n\u003e --\n\u003e Tom Zander\n\u003e Blog: https://zander.github.io\n\u003e Vlog: https://vimeo.com/channels/tomscryptochannel\n\u003e\n\u003e\n\u003e ------------------------------\n\u003e\n\u003e Message: 4\n\u003e Date: Sun, 3 Sep 2017 07:19:12 +0200\n\u003e From: Thomas Voegtlin \u003cthomasv at electrum.org\u003e\n\u003e To: bitcoin-dev at lists.linuxfoundation.org\n\u003e Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes\n\u003e Message-ID: \u003c5a27e555-173e-b5a7-8c05-5ee32e885ee2 at electrum.org\u003e\n\u003e Content-Type: text/plain; charset=utf-8\n\u003e\n\u003e\n\u003e\n\u003e On 30.08.2017 09:24, shiva sitamraju via bitcoin-dev wrote:\n\u003e\n\u003e \u003e\n\u003e \u003e 2. Segwit wallet seed words have a different format which is incompatible\n\u003e \u003e with previous wallet seed words. This encodes the information that this\n\u003e \u003e wallet is segwit in the seed words itself. We need to define a structure\n\u003e \u003e for this\n\u003e \u003e\n\u003e\n\u003e That is what Electrum does.\n\u003e See http://docs.electrum.org/en/latest/seedphrase.html\n\u003e\n\u003e\n\u003e ------------------------------\n\u003e\n\u003e Message: 5\n\u003e Date: Mon, 4 Sep 2017 10:06:44 -0400\n\u003e From: Peter Todd \u003cpete at petertodd.org\u003e\n\u003e To: Gregory Maxwell \u003cgreg at xiph.org\u003e, Bitcoin Protocol Discussion\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: Re: [bitcoin-dev] Fwd: \"Compressed\" headers stream\n\u003e Message-ID: \u003c20170904140644.GF1276 at fedora-23-dvm\u003e\n\u003e Content-Type: text/plain; charset=\"us-ascii\"\n\u003e\n\u003e On Mon, Aug 28, 2017 at 05:12:15PM +0000, Gregory Maxwell via bitcoin-dev\n\u003e wrote:\n\u003e \u003e You are leaving a lot of bytes on the table.\n\u003e \u003e\n\u003e \u003e The bits field can only change every 2016 blocks (4 bytes per header),\n\u003e \u003e the timestamp can not be less than the median of the last 11 and is\n\u003e \u003e usually only a small amount over the last one (saves 2 bytes per\n\u003e \u003e header), the block version is usually one of the last few (save 3\n\u003e \u003e bytes per header).\n\u003e \u003e\n\u003e \u003e But all these things improvements are just a constant factor. I think\n\u003e \u003e you want the compact SPV proofs described in the appendix of the\n\u003e \u003e sidechains whitepaper which creates log scaling proofs.\n\u003e\n\u003e Note that I'm already planning on OpenTimestamps having infrastructure for\n\u003e trusted validity attestations; log scaling proofs alone only prove total\n\u003e work,\n\u003e not validity. Timestamping has all kinds of very dubious security\n\u003e properties\n\u003e when done via proof-of-work, due to various ways that miners can get away\n\u003e with\n\u003e inaccurate block times. In particular, setting a block time backwards is\n\u003e something that miners can do, particularly with majority hashing power,\n\u003e which\n\u003e is the exact thing we're trying to prevent in a timestamp proof.\n\u003e\n\u003e This all makes me dubious about risking further weakening of this already\n\u003e weak\n\u003e security with compact SPV proofs; we'd need a lot more analysis to\n\u003e understand\n\u003e what we're risking. Also note that we can ship a known-good\n\u003e sum-merkle-tree tip hash with the software, which further reduces initial\n\u003e download bandwidth needed to get the block headers on top of this obviously\n\u003e safe eliding of redundant hashes.\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e -------------- next part --------------\n\u003e A non-text attachment was scrubbed...\n\u003e Name: signature.asc\n\u003e Type: application/pgp-signature\n\u003e Size: 455 bytes\n\u003e Desc: Digital signature\n\u003e URL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/\n\u003e attachments/20170904/8be560f7/attachment-0001.sig\u003e\n\u003e\n\u003e ------------------------------\n\u003e\n\u003e Message: 6\n\u003e Date: Mon, 4 Sep 2017 10:10:17 -0400\n\u003e From: Peter Todd \u003cpete at petertodd.org\u003e\n\u003e To: Greg Sanders \u003cgsanders87 at gmail.com\u003e, Bitcoin Protocol\n\u003e Discussion\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: Re: [bitcoin-dev] \"Compressed\" headers stream\n\u003e Message-ID: \u003c20170904141017.GG1276 at fedora-23-dvm\u003e\n\u003e Content-Type: text/plain; charset=\"us-ascii\"\n\u003e\n\u003e On Mon, Aug 28, 2017 at 12:26:48PM -0400, Greg Sanders via bitcoin-dev\n\u003e wrote:\n\u003e \u003e Well, if anything my question may bolster your use-case. If there's a\n\u003e \u003e heavier chain that is invalid, I kind of doubt it matters for\n\u003e timestamping\n\u003e \u003e reasons.\n\u003e\n\u003e Timestamping can easily be *more* vulnerable to malicious miners than\n\u003e financial\n\u003e applications for a number of reasons, including the fact that there's no\n\u003e financial feedback loop of miners destroying the value of the coins they\n\u003e produce - timestamping is a non-financial piggy-back application that\n\u003e doesn't\n\u003e directly interact with the Bitcoin economy, beyond a trival number of\n\u003e timestamp\n\u003e transactions.\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e -------------- next part --------------\n\u003e A non-text attachment was scrubbed...\n\u003e Name: signature.asc\n\u003e Type: application/pgp-signature\n\u003e Size: 455 bytes\n\u003e Desc: Digital signature\n\u003e URL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/\n\u003e attachments/20170904/818e9344/attachment.sig\u003e\n\u003e\n\u003e ------------------------------\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e End of bitcoin-dev Digest, Vol 28, Issue 3\n\u003e ******************************************\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170905/a3ece874/attachment-0001.html\u003e",
"sig": "6afcae7ca89fd1bbfebed75c62a86cdd4307b498027a80a1361f3b1d63ec92c2cefdf2ea26421653fc3ace3b668c26ad1fd43afb3255918c3d47ceb189940f9a"
}