Re: [bitcoin-dev] URI scheme with optional bech32 address

[shiva sitamraju via bitcoin-dev]

Hi,

I am not sure why this wasn't discussed more but it seemed like a very good
idea to me
https://www.reddit.com/r/Bitcoin/comments/9iivej/its_been_like_a_year_and_bech32_adoption_remains/

QR code is very important for network wide adoption. The problem is bech32
qr code isn't backward compatible and noone is going to show two QR codes.
Everyone is going safe with P2SH address qr code.

Example of proposed URI. I want not sure of technically best encoding, but
this is just for ideas

bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?bech32=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?keyhash=a70aa2014fbc2151e0a5da78a8dead358d3af384
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?amount=0.123=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy

As merchants/exchanges adopt this QR code, wallets that support bech32 can
chose to autopay to bech32 address  (for lower tx fee). This can create a
network effect as more people start using bech32 and when we reach enough
wallet adoption, people can shift to just showing bech32 QR codes


-- 
Shiva S
CEO @ Blockonomics 
Decentralized and Permissionless Payments
Join us on Telegram 
View our Welcome Guide

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

[bitcoin-dev] Testnet3 Reest

[shiva sitamraju via bitcoin-dev]

Hi,

Testnet is now 1411795 blocks and a full sync is taking atleast 48 hours.

Is a testnet reset scheduled in the next release or any reason not to do a
reset ?

Fast onboarding/lower disk overheads would be  very much appreicated for
testing purposes

Regards


-- 
Shiva S
CEO @ Blockonomics 
Decentralized and Permissionless Payments
Join us on Telegram 
View our Welcome Guide

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

Re: [bitcoin-dev] New serialization/encoding format for key material

[shiva sitamraju via bitcoin-dev]

The idea to add birthdate and gap limit sounds very good and addresses lots
of problems users are facing.

However, adding birthday to keys breaks two basic properties

- Visually Comparing two keys to find if they are same (Important)
- Different wallet software could set different birthday/gap limit.
creating different xpub/xprv for the same set of mathematically derived
individual keys. This removes the decoupling between key and wallet metadata

In fact, same could be argued to add birthday to WIF private key format to
let wallet discover funds faster.


Is it possible to have a serialization so that in the encoding, the key
part is still visually the same ?


On Tue, May 29, 2018 at 5:30 PM, <
bitcoin-dev-requ...@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-requ...@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-ow...@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. New serialization/encoding format for key material
>   (Jonas Schnelli)
>
>
> --
>
> Message: 1
> Date: Tue, 29 May 2018 11:13:37 +0200
> From: Jonas Schnelli 
> To: Bitcoin Protocol Discussion
> 
> Subject: [bitcoin-dev] New serialization/encoding format for key
> material
> Message-ID: <03557e21-8cfc-4822-8494-f4a78e238...@jonasschnelli.ch>
> Content-Type: text/plain; charset="utf-8"
>
> Hi
>
> Extended public and private keys are defined in BIP32 [1].
>
> Encoded extended private keys should not be confused with a wallet ?seed?
> (proposals like BIP39) while they can also partially serve the purpose to
> ?seed? a wallet (there may be an overlap in the use-case).
>
> Recovering a wallet by its extended private master key (xpriv; may or may
> not
> be at depth 0) is a complex task with risks of failing to recover all
> available
> funds.
>
> It may be reasonable to consider that recovering a wallet purely based on
> the
> existence of an extended private master key is a forensic funds recovery
> process and should probably be the last resort in case of a backup-recovery
> situation. A simple example here is, that it was/is possible to have used
> an
> xpriv (referring to extended private master key) in production that is/was
> used
> to derive BIP45 based P2SH multisig addresses (1of1, used by Bitpays BWS
> for
> while), later used for bare BIP45ish multisig 1of1 as well as for P2PKH
> after
> BIP44 & vanilla BIP32 P2WPKH (m/0?/k?).
> I?m not aware of any wallet that would recover 100% of those funds,
> leading to
> the risk that forwarding the unspents and destroying the extended master
> key
> may result in coins forever lost.
>
> The case above may be an edge case, but I?m generally under the assumption
> that
> recovering funds based on the sole existence of an xpriv (or seed) without
> further
> metadata is a fragile concept.
>
> Second, the missing birthday-metadata tend to lead to non-optimal
> blockchain
> scans (eventually increased p2p traffic). Recovering funds can take hours.
>
> Additionally, the BIP44 gap limit seems to be a weak construct. The
> current gap
> limit in BIP44 is set to 20 [2] which basically means, handing out more
> then 20
> incoming payment requests (addresses) results in taking the risks that
> funds
> may be destroyed (or at least not detected) during a recovery.
> The Gap limit value may also depend on the use case, but the current
> proposals
> do not allow to set an arbitrary value. High load merchants very likely
> need a
> different gap limit value then individuals create a transaction once a
> year.
>
> During creation time of an xpriv/xpub, it is impossible to know if the
> created
> xpriv will be used for an unforeseen derivation scheme. Future proposals
> may
> want to limit an extended key to a single derivation scheme.
>
>
> This is an early draft in order to allow discussion that may lead to a
> possible
> proposal.
> This proposals could also make BIP 178 obsolete since it can be replace the
> WIF[3] standard.
>
>
> Thanks for feedback
> /jonas
>
>
> 
>
>
> Titel
> ##
> Bech32 encoded key material including metadata
>
> Abstract
> 
> An error tolerant encoding format for key material up to 520bits with a
> minimal
> amount of metadata.
>
> Motivation
> ##
> (See above; intro text)
>
>
> Specification
> #
>
> ## Serialization format
>
> 1 bit version bit
> 15 bits (bit 1 to 16) key-birthday (0-32767)
> (12 bit gap limit)
> 3 or 5 bits script type
> 256 or 512 or 

Re: [bitcoin-dev] Visually Differentiable - Bitcoin Addresses

[shiva sitamraju via bitcoin-dev]

For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is 62
bytes ! This is very very long. This will create lot of usability problems
in

- Blockexplorers (atleast user should be visually able to compare in a
transaction having multiple outputs which one his address)
- Mobiles
- Payment terminals

>From my limited understanding, the purpose of inventing a bitcoin address
format is for usability and ease of identification (versus a ECDSA public
key), While I get the error/checksum capabilities Bech32 brings, any user
would prefer a 20 byte address with a checksum  over an address that would
wrap several lines !!


On Mon, Oct 30, 2017 at 6:19 PM, Ben Thompson <
thompson.benedictja...@gmail.com> wrote:

> Checking the first few bytes of a Bitcoin Address should not be considered
> sufficient for ensuring that it is correct as it takes less than a second
> to generate a 3 character vanity address that matches the first 3
> characters of an address.
>
> On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bitcoin-dev, <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi,
>>
>> When I copy and paste bitcoin address, I double check the first few
>> bytes, to make sure I copied the correct one. This is to make sure some
>> rogue software is not changing the address, or I incorrectly pasted the
>> wrong address.
>>
>>
>> With Bech32 address, its seems like in this department we are taking as
>> step in the backward direction. With the traditional address, I could
>> compare first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see
>> and compare which is likely to be same anyway. Note that most users will
>> only compare the first few bytes only (since addresses themselves are very
>> long and will overflow in a mobile text box).
>>
>> Is there anyway to make the Bech32 addresses format more visually
>> distinct (atleast the first few bytes) ?
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Visually Differentiable - Bitcoin Addresses

[shiva sitamraju via bitcoin-dev]

Hi,

When I copy and paste bitcoin address, I double check the first few bytes,
to make sure I copied the correct one. This is to make sure some rogue
software is not changing the address, or I incorrectly pasted the wrong
address.


With Bech32 address, its seems like in this department we are taking as
step in the backward direction. With the traditional address, I could
compare first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see
and compare which is likely to be same anyway. Note that most users will
only compare the first few bytes only (since addresses themselves are very
long and will overflow in a mobile text box).

Is there anyway to make the Bech32 addresses format more visually distinct
(atleast the first few bytes) ?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32

[shiva sitamraju via bitcoin-dev]

pt that should be
> > globally limited, such as hash operations, which are not accounted for
> > at this time and cannot be statically assessed, even by the flawed
> > mechanism by which SigOps are counted. I have maintained for some time
> > that bitcoin should move from having multiple separate global limits
> > (weight and sigops, hashed bytes in XT/Classic/BCH) to a single linear
> > metric that combines all of these factors with appropriate
> > coefficients.
> >
>
> I like the idea to have an unified global limit and suggested a way to do
> it (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/
> 013472.html). But I think this is off-topic here.
>
>
>
> > A better way of handling this problem, which works for both SigOps and
> > HashOps, is to have the witness commit to the maximum resources
> > consumed by validation of the spend of the coin, to relay this data
> > with the transaction and include it in the SigHash, and to use the
> > committed maximum for block validation. This could be added in a
> > future script version upgrade. This change would also resolve the
> > issue that led to the clean stack rule in segwit, allowing future
> > versions of script to use tail-call recursion without involving the
> > alt-stack.
> >
> > Nevertheless it is constructive feedback that the current draft of the
> > BIP and its implementation do not count SigOps, at all. There are a
> > couple of ways this can be fixed by evaluating the top-level script
> > and then doing static analysis of the resulting policy script, or by
> > running the script and counting operations actually performed.
>
>
> In any case, I think maintaining static analysability for global limit(s)
> is very important. Ethereum had to give up their DAO softfork plan at the
> last minute, exactly due to the lack of this:
> http://hackingdistributed.com/2016/06/28/ethereum-soft-fork-dos-vector/
>
> Otherwise, one could attack relay and mining nodes by sending many small
> size txs with many sigops, forcing them to validate, and discard due to
> insufficient fees.
>
> Technically it might be ok if we commit the total validation cost (sigop +
> hashop + whatever) as the first witness stack item, but that?d take more
> space and I?m not sure if it is desirable. Anyway, giving up static
> analysability for scripts is a fundamental change to our existing model.
>
> >
> > Additionally, it is possible that we take this time to re-evaluate
> > whether we should be counting SigOps other than for legacy consensus
> > rule compliance. The speed of verification in secp256k1 has made
> > signature operations no longer the chief concern in block validation
> > times.
>
> Without the limit I think we would be DoS-ed to dead
>
>
> >> Witness script versioning is by design fully compatible with P2SH
> >> and BIP173, so there will be no hurdle for existing wallets to pay
> >> to BIP114. Actually it should be completely transparent to them.
> >
> > This is correct. Your feedback will be incorporated.
> >
> >> For code complexity, the minimal BIP114 could be really simple, like
> >> <30 lines of code? It looks complex now because it does much more
> >> than simply hiding scripts in a hash.
> >
> > Is there a repo that contains the latest implementation of BIP 114,
> > for comparison purposes?
>
>
> You can find it here: https://github.com/jl2012/bitcoin/commits/vault
> https://github.com/jl2012/bitcoin/commit/f3f201d232d3995db38e09b171e4d1
> dea8d04ad2
>
> But this does more than your proposal as it allows users adding extra
> scripts when spending a coin. The rationale is described in the revised
> BIP114:
> https://github.com/jl2012/bips/blob/vault/bip-0114.
> mediawiki#Additional_scripts_in_witness
>
> So to make it functionally comparable with your proposal, the
> IsMSV0Stack() function is not needed. The new 249-254 lines in
> interpreter.cpp could be removed. The new 1480-1519 lines could be replaced
> by a few lines copied from the existing P2WSH code. I can make a minimal
> version if you want to see how it looks like
>
>
> >
> > Kind regards,
> > Mark Friedenbach
> >
>
>
>
>
> --
>
> Message: 2
> Date: Tue, 12 Sep 2017 11:06:15 +0200
> From: Thomas Voegtlin <thom...@electrum.org>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
> BIP-32
> Message-ID: <99643f72-f72f-e4e9-ac2b-72bf519c2...@electrum.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 09.

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[shiva sitamraju via bitcoin-dev]

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-requ...@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-requ...@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-ow...@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 withamount=0
>   (Jorge Tim?n)
>
>
> --
>
> Message: 1
> Date: Tue, 5 Sep 2017 17:41:37 +0200
> From: Pavol Rusnak <st...@satoshilabs.com>
> To: shiva sitamraju <sh...@blockonomics.co>,Bitcoin Protocol
> Discussion <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
> Message-ID: <9da64df3-c6a9-c232-c801-f379a6d65...@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 <st...@satoshilabs.com>
> To: Thomas Voegtlin <thom...@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-b89f73e31...@satoshilabs.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 05/09/17 12:25, Thomas Voegtlin via bitcoin-dev wrote:
> > == === ===
> > VersionPrefix  Description
> > == === ===
> > 0x0488ade4 xprvP2PKH or P2SH
> > 0x0488b21e xpubP2PKH or P2SH
> > 0x049d7878 yprv(P2WPKH or P2WSH) nested in P2SH
> > 0x049d7cb2 ypub(P2WPKH or P2WSH) nested in P2SH
> > 0x04b2430c zprvP2WPKH or P2WSH
> > 0x04b24746 zpubP2WPKH 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 <thom...@electrum.org>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
> Message-ID: <28d57503-c2b3-7736-bfea-46506636d...@electrum.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 05.09.2017 09:10, shiva sitamraju via

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[shiva sitamraju via bitcoin-dev]

>
> Message: 2
> Date: Fri, 1 Sep 2017 15:40:44 -0400
> From: Thomas Guyot-Sionnest <derm...@aei.ca>
> To: Cserveny Tamas <cserveny.tamas...@gmail.com>,   Bitcoin Protocol
> Discussion <bitcoin-dev@lists.linuxfoundation.org>, Lucas
> Clemente
> Vella <lve...@gmail.com>, Tom Zander <t...@freedommail.ch>
> Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
> Message-ID: <e9531342-db9b-ffdf-5ada-0c143eb89...@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 <t...@freedommail.ch>
> To: Cserveny Tamas <cserveny.tamas...@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 <thom...@electrum.org>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
> Message-ID: <5a27e555-173e-b5a7-8c05-5ee32e885...@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 <p...@petertodd.org>
> To: Gregory Maxwell <g...@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 +, 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 

[bitcoin-dev] BIP49 Derivation scheme changes

[shiva sitamraju via bitcoin-dev]

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
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev