Re: [bitcoin-dev] BIP49 Derivation scheme changes

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[shiva sitamraju]

[-- Attachment #1: Type: text/plain, Size: 12277 bytes --]

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 <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
> ******************************************
>

[-- Attachment #2: Type: text/html, Size: 17228 bytes --]

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[Pavol Rusnak]

On 05/09/17 09:10, shiva sitamraju via bitcoin-dev wrote:
> 0x042393df ,  sxpr ,   segwit mainnet private key
> 0x04239377 , sxpb , segwit mainnet public key
> 0x04222463 , stpb ,  segwit testnet public key
> 0x042224cc ,  stpr ,  segwit testnet private key 

I am fine with both your proposal and proposal from Thomas
({x,y,z}{pub,prv}).

Let's just decide ASAP which one we'll use.


-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[Thomas Voegtlin]

On 05.09.2017 09:10, shiva sitamraju via bitcoin-dev wrote:
> 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
> 

I have proposed a similar idea, with letters z,y,z combined with pub/prv
(see the electrum documentation page)

The point is that we need 3 types of keys, not 2, because there are two
types of segwit output scripts: native and nested in p2sh.

We could use t,u,v for testnet.

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[Dan Libby]

On 08/30/2017 12:24 AM, shiva sitamraju via bitcoin-dev wrote:

> What would happen if you recover a wallet  using seed words ?
>   1. Since there is no difference in seed words between segwit/non
> segwit, the wallet would discover both m/44' and m/49' accounts
>   2. Note that we cannot ask the user to choose an account he wants to
> operate on (Segwit/Non segwit). This is like asking him the HD
> derivation path and a really bad UI
>   3. The wallet now has to constantly monitor both m/44' and m/49'
> accounts for transactions

small nit with 3.

It seems to me that the wallet would perform initial discovery on m/44
and m/49, and then would find transactions at one or the other, so it
can then record the type somewhere and from then on need only monitor
one branch.

Still, I agree it is ugly, makes initial discovery up to 2x slower, etc.

> *- XPUB Derivation*
> This is something not addressed in the BIP yet.
> 
> 1. Right now you can get an xpub balance/transaction history. With m/49'
> there is no way to know whether an xpub is from m/44' or m/49'
> 
> 2. This breaks lots of things. Wallets like electrum/armory/mycelium
> <https://blog.trezor.io/using-mycelium-to-watch-your-trezor-accounts-a836dce0b954>support
> importing  xpub as a watch only wallet. Also services like
> blockonomics/blockchain.info <http://blockchain.info> use xpub for
> displaying balance/generating merchant addresses
> 
> Looking forward to hearing your thoughts

speaking as author of tools hd-wallet-addrs and hd-wallet-derive, I
agree this is problematic.

would be great if xpub/xprv could somehow encode their absolute path in
wallet for tools to read.  Users cannot be expected to know.

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[shiva sitamraju]

[-- Attachment #1: Type: text/plain, Size: 12845 bytes --]

Hi Thomas,

Can you explain why P2WPKH nested in BIP16 P2SH require a different version
than P2WPKH? It seems to me both would would generate same bitcoin address
in txout and hence would be in the same wallet account.

I am fine with your proposal too. Would be great if you can list all new
versions including testnet ones. I would prefer all testnet ones start with
t (easier to identify) instead of having t,u,v

Thanks



On Wed, Sep 6, 2017 at 3:21 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: BIP49 Derivation scheme changes (Pavol Rusnak)
>    2. Re: Proposal: bip32 version bytes for segwit scripts
>       (Pavol Rusnak)
>    3. Re: BIP49 Derivation scheme changes (Thomas Voegtlin)
>    4. Re: Proposal: bip32 version bytes for segwit scripts (Luke Dashjr)
>    5. Re: Sidechain headers on mainchain (unification of
>       drivechains and spv proofs) (Chris Stewart)
>    6. Re: Proposal: bip32 version bytes for segwit scripts
>       (Thomas Voegtlin)
>    7. SF proposal: prohibit unspendable outputs with    amount=0
>       (Jorge Tim?n)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 5 Sep 2017 17:41:37 +0200
> From: Pavol Rusnak <stick@satoshilabs.com>
> To: shiva sitamraju <shiva@blockonomics.co>,    Bitcoin Protocol
>         Discussion <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
> Message-ID: <9da64df3-c6a9-c232-c801-f379a6d65e44@satoshilabs.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 05/09/17 09:10, shiva sitamraju via bitcoin-dev wrote:
> > 0x042393df ,  sxpr ,   segwit mainnet private key
> > 0x04239377 , sxpb , segwit mainnet public key
> > 0x04222463 , stpb ,  segwit testnet public key
> > 0x042224cc ,  stpr ,  segwit testnet private key
>
> I am fine with both your proposal and proposal from Thomas
> ({x,y,z}{pub,prv}).
>
> Let's just decide ASAP which one we'll use.
>
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 5 Sep 2017 17:44:01 +0200
> From: Pavol Rusnak <stick@satoshilabs.com>
> To: Thomas Voegtlin <thomasv@electrum.org>,     Bitcoin Protocol
>         Discussion <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
>         scripts
> Message-ID: <198be73d-4676-45e9-6e3d-b89f73e31702@satoshilabs.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 05/09/17 12:25, Thomas Voegtlin via bitcoin-dev wrote:
> > ========== =========== ===================================
> > Version    Prefix      Description
> > ========== =========== ===================================
> > 0x0488ade4 xprv        P2PKH or P2SH
> > 0x0488b21e xpub        P2PKH or P2SH
> > 0x049d7878 yprv        (P2WPKH or P2WSH) nested in P2SH
> > 0x049d7cb2 ypub        (P2WPKH or P2WSH) nested in P2SH
> > 0x04b2430c zprv        P2WPKH or P2WSH
> > 0x04b24746 zpub        P2WPKH or P2WSH
> > ========== =========== ===================================
> > (source: http://docs.electrum.org/en/latest/seedphrase.html)
> >
> > I have heard the argument that xpub/xprv serialization is a format for
> > keys, and that it should not be used to encode how these keys are used.
>
> I used this argument for mnemonic/seed, not xpub/xprv. I am fine with
> this proposal of yours, so don't worry.
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 5 Sep 2017 18:33:00 +0200
> From: Thomas Voegtlin <thomasv@electrum.org>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
> Message-ID: <28d57503-c2b3-7736-bfea-46506636d999@electrum.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 05.09.2017 09:10, shiva sitamraju via bitcoin-dev wrote:
> > 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
> >
>
> I have proposed a similar idea, with letters z,y,z combined with pub/prv
> (see the electrum documentation page)
>
> The point is that we need 3 types of keys, not 2, because there are two
> types of segwit output scripts: native and nested in p2sh.
>
> We could use t,u,v for testnet.
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 5 Sep 2017 13:03:39 -0400
> From: Luke Dashjr <luke@dashjr.org>
> To: bitcoin-dev@lists.linuxfoundation.org,      Thomas Voegtlin
>         <thomasv@electrum.org>
> Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
>         scripts
> Message-ID: <201709051303.43410.luke@dashjr.org>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> On Tuesday 05 September 2017 06:25:16 Thomas Voegtlin via bitcoin-dev
> wrote:
> > I have heard the argument that xpub/xprv serialization is a format for
> > keys, and that it should not be used to encode how these keys are used.
> > However, the very existence of version bytes, and the fact that they are
> > used to signal whether keys will be used on testnet or mainnet goes
> > against that argument.
> >
> > If we do not signal the script type in the version bytes, I believe
> > wallet developers are going to use dirtier tricks, such as the bip32
> > child number field in combination with bip43/bip44/bip49.
>
> I think it makes more sense to use a child number field for this purpose.
> It seems desirable to use the same seed for all different script formats...
>
> As you note, xpub\xprv are already being used for both P2PKH and P2SH. It
> really doesn't make sense to differentiate segwit specifically.
>
> Luke
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 5 Sep 2017 12:06:32 -0500
> From: Chris Stewart <chris@suredbits.com>
> To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,         Bitcoin Protocol
> Discussion
>         <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Sidechain headers on mainchain (unification
>         of drivechains and spv proofs)
> Message-ID:
>         <CAGL6+mFHe_SfMea1oMZ3n-G3ey9yToAvTMTcfdxJ5qDD1dTXyQ@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi ZmnSCPxj,
>
> Basically, in case of a sidechain fork, the mainchain considers the longest
> > chain to be valid if it is longer by the SPV proof required length.  In
> the
> > above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E)
> > longer than the other sidechain fork that ended at d.
> >
> > Mainchain nodes can validate this rule because the sidechain headers are
> > embedded in the mainchain block's coinbase.  Thus, mainchain fullnodes
> can
> > validate this part of the sidechain rule of "longest work chain".
> >
>
> What happens in the case that the provided merkle tree hash has a invalid
> transaction in it? Wouldn't this mean that the mainchain nodes would think
> the longest work chain is the valid chain, and it would kill off any
> consensus valid chain that sidechain miners are trying to construct? It
> seems that a malicious miner could extend the chain to whatever the SPV
> proof block height is and make it impossible for the chain to reorg after
> that. I guess if that is a sufficiently long block waiting period it may
> not be a realistic concern, but something to think about any way.
>
> Just a side note -- I think it should be highly recommended that the
> coinbase maturity period on the sidechain to be longer than 288 (or
> whatever we decide on the parameter). This incentivizes the s:miners to
> work together to extend the chain by working with other s:miners (otherwise
> they won't be able to claim their bribes). If they do not work together
> they will not be able to spend their s:coinbase_tx outputs until they
> extend their own sidechain by 288 blocks meaning they need to tie up a
> large amount of capital to go rogue on their fork.
>
> Another interesting thing might be to use the OP_WITHDRAWPROOFVERIFY op
> code
> <https://github.com/ElementsProject/elements/blob/
> elements-0.14.1/src/script/interpreter.cpp#L1420>
> used in the elements project. Since the cannonical merkle root hashes are
> included in the mainchain, we can provide a merkle proof to the bitcoin
> blockchain to initiate a withdrawl from the sidechain. I wrote up a blog
> post on how OP_WPV works here
> <https://medium.com/@Chris_Stewart_5/what-can-go-wrong-
> when-transferring-coins-into-a-sidechain-with-op-withdrawproofverify-
> b2f49b02ab60>.
> This allows us to prove that a transaction occurred on the sidechain to
> lock up those funds.
>
> -Chris
> ?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> attachments/20170905/37b0bcbe/attachment-0001.html>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 5 Sep 2017 20:09:19 +0200
> From: Thomas Voegtlin <thomasv@electrum.org>
> To: Luke Dashjr <luke@dashjr.org>,
>         "bitcoin-dev@lists.linuxfoundation.org"
>         <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
>         scripts
> Message-ID: <41fb5a09-a964-a81b-497e-70a930b6923c@electrum.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 05.09.2017 19:03, Luke Dashjr wrote:
>
> > It seems desirable to use the same seed for all different script
> formats...
>
> That does not seem desirable to everybody.
>
> If you want to guarantee that users will be able to recover all their
> funds from their mnemonic seed (and that is what they expect), then
> wallets must implement all script formats, even the ones that are
> deprecated. In addition, the list of script formats that must be
> supported is not defined in advance, but it keeps growing. This makes
> wallet implementation increasingly difficult. In the long run, seed
> portability is guaranteed to fail in such a system.
>
> > As you note, xpub\xprv are already being used for both P2PKH and P2SH. It
> > really doesn't make sense to differentiate segwit specifically.
>
> That's not a reason. The fact that xpub/xprv can be used for both P2PKH
> and P2SH has already resulted in users receiving coins on addresses they
> do not control.
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 5 Sep 2017 23:51:45 +0200
> From: Jorge Tim?n <jtimon@jtimon.cc>
> To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
> Subject: [bitcoin-dev] SF proposal: prohibit unspendable outputs with
>         amount=0
> Message-ID:
>         <CABm2gDojDQWMhw8wW1UkRGKtdbby2+6AFFZLPuRcUb7WF_u5qQ@mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> This is not a priority, not very important either.
> Right now it is possible to create 0-value outputs that are spendable
> and thus stay in the utxo (potentially forever). Requiring at least 1
> satoshi per output doesn't really do much against a spam attack to the
> utxo, but I think it would be slightly better than the current
> situation.
>
> Is there any reason or use case to keep allowing spendable outputs
> with null amounts in them?
>
> If not, I'm happy to create a BIP with its code, this should be simple.
>
>
> ------------------------------
>
> _______________________________________________
> 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 6
> ******************************************
>

[-- Attachment #2: Type: text/html, Size: 17862 bytes --]

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[Thomas Voegtlin]

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

[bitcoin-dev] BIP49 Derivation scheme changes

[shiva sitamraju]

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]

Hi,

I wanted to discuss few changes in BIP49

*- Breaking backwards compatibility *
The BIP talks about breaking this, and  but it really doesn't.  I really
feel it should completely break this. Here is why

What would happen if you recover a wallet  using seed words ?
  1. Since there is no difference in seed words between segwit/non segwit,
the wallet would discover both m/44' and m/49' accounts
  2. Note that we cannot ask the user to choose an account he wants to
operate on (Segwit/Non segwit). This is like asking him the HD derivation
path and a really bad UI
  3. The wallet now has to constantly monitor both m/44' and m/49' accounts
for transactions

Basically we are always stuck with keeping compatibility with older seed
words or always asking the user if the seed words came from segwit/non
segwit wallet !

Here is my suggestion :
1. By default all new wallets will be created as segwit  m/49' without
asking user anything. I think you would agree with me that in future we
want most wallet to be default segwit (unless user chooses a non segwit
from advanced options)!

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



*- XPUB Derivation*
This is something not addressed in the BIP yet.

1. Right now you can get an xpub balance/transaction history. With m/49'
there is no way to know whether an xpub is from m/44' or m/49'

2. This breaks lots of things. Wallets like electrum/armory/mycelium
<https://blog.trezor.io/using-mycelium-to-watch-your-trezor-accounts-a836dce0b954>support
importing  xpub as a watch only wallet. Also services like blockonomics/
blockchain.info use xpub for displaying balance/generating merchant
addresses

Looking forward to hearing your thoughts

[-- Attachment #2: Type: text/html, Size: 2327 bytes --]