RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts

	https://github.com/DanielWeigl/bips/blob/master/bip-p2sh-accounts.mediawiki
> Hi List,
>
> Following up to the discussion last month ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012695.html ), ive prepared a proposal for a BIP here:
>
> 	https://github.com/DanielWeigl/bips/blob/master/bip-p2sh-accounts.mediawiki
>
>
> Any comments on it? Does anyone working on a BIP44 compliant wallet implement something different?
> If there are no objection, id also like to request a number for it.
  Jochen
> I think we should already consider not only P2WPKH over P2SH addresses
> but also "native" P2WPKH addresses.  Instead of having one BIP for these
> BIP?? compatible wallet must support both of them.  Since P2WPKH is
> simpler than P2WPKH over P2SH, this is IMHO reasonable to require.
> E.g., 0,1 for
> P2WPKH over P2SH and 2,3 for native P2WPKH.  I see no reason why a
> I see no reason why a
> wallet would want to use P2WPKH over P2SH for change addresses instead
> of native P2WPKH, though.
> Hello Daniel,
>
> Am 14.06.2016 um 17:41 schrieb Daniel Weigl via bitcoin-dev:
>> Hi List,
>>
>> Following up to the discussion last month ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012695.html ), ive prepared a proposal for a BIP here:
>>
>> 	https://github.com/DanielWeigl/bips/blob/master/bip-p2sh-accounts.mediawiki
>>
>>
>> Any comments on it? Does anyone working on a BIP44 compliant wallet implement something different?
>> If there are no objection, id also like to request a number for it.
>
> thank you for going forward with this.  Should we keep the discussion on
> the list, or should we make it on github?
>
> I think we should already consider not only P2WPKH over P2SH addresses
> but also "native" P2WPKH addresses.  Instead of having one BIP for these
> two kinds of segwit addresses and forcing the user to have several
> different accounts for each BIP, the idea would be that every fully
> BIP?? compatible wallet must support both of them.  Since P2WPKH is
> simpler than P2WPKH over P2SH, this is IMHO reasonable to require.
>
> I would go with the suggestion from Aaron Voisine to use different chain
> id's to distinguish between different address types.   E.g., 0,1 for
> P2WPKH over P2SH and 2,3 for native P2WPKH.  I see no reason why a
> wallet would want to use P2WPKH over P2SH for change addresses instead
> of native P2WPKH, though.
>
>   Jochen
>
>
> That would be a big privacy leak, imo. As soon as both outputs are spent,
> which one was the P2WPKH-in-P2SH and which one the pure P2WPKH and as a
> you leak which output was the change and which one the actual sent output
>
> So, i'd suggest to even make it a requirement for "normal"
> to always use the same output type for the change output (if the wallet
> outputs, pick one at random, and mimic it for the change output. This means
> that if you have a P2PKH and 3 P2SH sends, you'll have 25% chance for a
> P2PKH change output, and 75% chance for a P2SH output.
>
>
> On Jun 15, 2016 12:53, "Daniel Weigl via bitcoin-dev" <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
> >
> > That would be a big privacy leak, imo. As soon as both outputs are
> spent, its visible
> > which one was the P2WPKH-in-P2SH and which one the pure P2WPKH and as a
> consequence
> > you leak which output was the change and which one the actual sent output
> >
> > So, i'd suggest to even make it a requirement for "normal"
> send-to-single-address transactions
> > to always use the same output type for the change output (if the wallet
> is able to recognize it)
>
> Indeed, and you can go even further. When there are multiple "sending"
> outputs, pick one at random, and mimic it for the change output. This means
> that if you have a P2PKH and 3 P2SH sends, you'll have 25% chance for a
> P2PKH change output, and 75% chance for a P2SH output.
>
> You can go even further of course, if you want privacy that remains after
> those sends get spent. In that case, you also need to match the template of
> the redeemscript/witnessscript. For example, if the send you are mimicking
> is a 2-of-3, the change output should also use 2-of-3.
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> Hi List,
>
> Following up to the discussion last month (
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012695.html
> ), ive prepared a proposal for a BIP here:
>
>
> https://github.com/DanielWeigl/bips/blob/master/bip-p2sh-accounts.mediawiki
>
>
> Any comments on it? Does anyone working on a BIP44 compliant wallet
> implement something different?
> If there are no objection, id also like to request a number for it.
>
> Thx,
> Daniel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
- Any objections to get a BIP-number for it?
	If not, can I get one, so I can finish up the test vectors.
	Current version: https://github.com/DanielWeigl/bips/blob/master/bip-p2sh-accounts.mediawiki
- I decided against extending it for future P2WPKH addresses
	I think that should be a separate account on its own, to reduce implementation work
	for future wallets, that only want/need to implement P2WPKH accounts. And to keep it simple.
	Was someone working on the P2WPKH address format in the meantime? (ie. alternative for [2])
- We will also need a extension to the BIP32 serialization format[1]
	It should be possible to export/import a xPriv/xPub key across compatible wallets, and they
	should be able without guesswork, fuzzy checks or asking the user to import the correct account type.
	Thinking about some flexible tag-based backwards compatible extensions - but thats a different BIP in itself.
[1] https://github.com/DanielWeigl/bips/blob/master/bip-0032.mediawiki#Serialization_format
[2] https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki
> Hi List,
>
> Following up to the discussion last month ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012695.html ), ive prepared a proposal for a BIP here:
>
> 	https://github.com/DanielWeigl/bips/blob/master/bip-p2sh-accounts.mediawiki
>
>
> Any comments on it? Does anyone working on a BIP44 compliant wallet implement something different?
> If there are no objection, id also like to request a number for it.
>
> Thx,
> Daniel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>