shiva sitamraju [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-05 📝 Original message:Hi, Thanks Thomas. The ...
📅 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>;
📝 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>;