1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5C434941
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jun 2016 11:00:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com
[209.85.215.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A7B57175
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jun 2016 11:00:44 +0000 (UTC)
Received: by mail-lf0-f49.google.com with SMTP id l188so7686123lfe.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jun 2016 04:00:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc; bh=FcXsR7z8Y6/jjREbLf4NQlYnxmJMC+vx8sjDt6c7KTk=;
b=ejldsQYd6J1Y+cryw5SLsPzUkRDPUfIOH8wSulIHHCmq6EPoJaVesHHjwRYWW6EKcn
yOlgJZBF0i12Gnkx/0Wv/6sGDoll+limwPS52FyJ+cdWInnqWK9epA3C8F2203lv8upe
+slkTf4GXpCwsaciYYVG7dWjNYC/JdxsD7JW/ovdN6EleVOwFGbWUfO8SV8bgk6CIxjS
MOEuVQRykhN5ty9n1JOpJPvHhSNz5fY8pcck7KYTrnXsQnpv3JgGZAst45dIY5dHp47y
WfkCL50n5BMtcPEkHVrfRzoTSYft717p6rdZqhHfhx2/aMXg9G4WmdsrncBC3VWMPXCA
mIcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc;
bh=FcXsR7z8Y6/jjREbLf4NQlYnxmJMC+vx8sjDt6c7KTk=;
b=BVnRRIebAOtSpoAtn7hI8GUxDpDFAZxMCpjeuTbDl1RnE+DE6y6Aqn7Nu08hNrFIYO
J7XiaYkecGwDxLbib3/4MmmiXUkVp1CAwWLUz0+o62jNttAR86LWe2pg8ANF5+MLFldX
tP/Nc2RblfP8Bu/gSew0GUOYklA0KYW01PE2CP2HpaQwOh0Ygo6/fTl/X8E6opq1emIf
6Y9L9EX4x3c+9kAbAwr0XoXuL5SjdcQMBf0SL4fOUEDY54CsG9ARlTEhFowKDeHTMa9n
ST5EQrYcKh06+KNy/3mQWzbVycGV2hCMPK5BqiI9Ix8LBXJN+Fl31btp0difx3G3Oyep
qXYQ==
X-Gm-Message-State: ALyK8tJ7Xhj3wzGBjfIXCnhZvG9vYrLVQc8+4eqe8354XNq/4WnzzYcdsXTzk0ETWbr0NqwxHZfsvbKquj64Pw==
MIME-Version: 1.0
X-Received: by 10.25.207.1 with SMTP id f1mr2688495lfg.39.1465988442826; Wed,
15 Jun 2016 04:00:42 -0700 (PDT)
Received: by 10.114.180.101 with HTTP; Wed, 15 Jun 2016 04:00:42 -0700 (PDT)
Received: by 10.114.180.101 with HTTP; Wed, 15 Jun 2016 04:00:42 -0700 (PDT)
In-Reply-To: <576133A7.6070004@mycelium.com>
References: <5760259B.7040409@mycelium.com> <57612D67.9080007@gmail.com>
<576133A7.6070004@mycelium.com>
Date: Wed, 15 Jun 2016 13:00:42 +0200
Message-ID: <CAPg+sBj_9A8gmqRhs3Yg1+rVubdPLMxUhbcrGovF22RgCfVbrw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Daniel Weigl <Daniel.Weigl@mycelium.com>
Content-Type: multipart/alternative; boundary=001a11417df861305105354f08a3
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] RFC for BIP: Derivation scheme for
P2WPKH-nested-in-P2SH based accounts
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2016 11:00:45 -0000
--001a11417df861305105354f08a3
Content-Type: text/plain; charset=UTF-8
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
--001a11417df861305105354f08a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Jun 15, 2016 12:53, "Daniel Weigl via bitcoin-dev" <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>> wrote:<br>
><br>
> That would be a big privacy leak, imo. As soon as both outputs are spe=
nt, its visible<br>
> which one was the P2WPKH-in-P2SH and which one the pure P2WPKH and as =
a consequence<br>
> you leak which output was the change and which one the actual sent out=
put<br>
><br>
> So, i'd suggest to even make it a requirement for "normal&quo=
t; send-to-single-address transactions<br>
> to always use the same output type for the change output (if the walle=
t is able to recognize it)</p>
<p dir=3D"ltr">Indeed, and you can go even further. When there are multiple=
"sending" outputs, pick one at random, and mimic it for the chan=
ge 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 outpu=
t.</p>
<p dir=3D"ltr">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 t=
he 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.</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>
--001a11417df861305105354f08a3--
|
