[bitcoin-dev] RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts

[bitcoin-dev] RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts

[Daniel Weigl]

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

Re: [bitcoin-dev] RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts

[Jochen Hoenicke]

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

Re: [bitcoin-dev] RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts

[Daniel Weigl]

Hello 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

Thats a good point and should be simple to maintain. Yes, ill extend on that part.

The problem is, we dont have a final decision how the address encoding for P2WPKH 
public keys should look like. Or do we? Bip141 is "Status: Deferred"

But for now, I can at least include the public key derivation path.

> I see no reason why a
> wallet would want to use P2WPKH over P2SH for change addresses instead
> of native P2WPKH, though.

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)

Daniel

On 2016-06-15 12:26, Jochen Hoenicke wrote:
> 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
> 

Re: [bitcoin-dev] RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts

[Pieter Wuille]

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

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

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

Re: [bitcoin-dev] RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts

[Russell O'Connor]

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

On Wed, Jun 15, 2016 at 7:00 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

This isn't quite perfect because if there is only 1 P2PKH output and you
know the person is using the above algorithm then you know the P2PKH output
isn't the change.

I don't know what the perfect method is.  My guess is that it is to let p
be the probability that a P2PKH output is produced over the entire network
and to pick P2PKH for your change output with probability p (and similarly
for other output types).

On Wed, Jun 15, 2016 at 7:00 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

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

Re: [bitcoin-dev] RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts

[Aaron Voisine]

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

This works for segwit version 1 with the addition of also using a different
chain id.

I presume that segwit version 2 will be implementing schnorr signatures.
What do we know about the likely implementation details? Is there any way
to avoid using a third derivation path to support it?


Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com>

On Tue, Jun 14, 2016 at 8:41 AM, Daniel Weigl via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

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

[bitcoin-dev] [cont'd] Derivation scheme for P2WPKH-nested-in-P2SH based accounts

[Daniel Weigl]

Hello again,

sorry, got a bit derailed on that proposal.
But now I think its time to work on it again.

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


Cheers,
Daniel


[1] https://github.com/DanielWeigl/bips/blob/master/bip-0032.mediawiki#Serialization_format
[2] https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki

On 2016-06-14 17:41, Daniel Weigl via bitcoin-dev wrote:
> 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
>