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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
|
Return-Path: <keatonatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8C365E91
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Dec 2018 05:06:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com
[209.85.221.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DA0487A4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Dec 2018 05:06:56 +0000 (UTC)
Received: by mail-wr1-f43.google.com with SMTP id p4so7124123wrt.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 30 Nov 2018 21:06:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=m3x0hYrNJY7EDEgmP0Dd4zwCXx6UVe1pHt5OWd3442M=;
b=NhGSBDM+MjUgDgQ03jKtBNSPWPvtVf7loehbsR6a0FnUVamgtW1oGGQt7DB2HvGv1N
LPejhbxM6pYMBzC/qk7ubzCgMcUhINt5rS/IH0bV2B+I+KU2kKeVKmIE0Nr1yBhnRWv5
5gHnfUrLG3v2wzYfY/Dx0ncMhPXHGuxk2ttFEvpK5LHAPzNh75onM+OrrpPfHnZQimdS
sDKxladTPKCMNNWlDuy35lroabvZwZHccW2c8ysJiKFdF9X6zjRnBHTbMqyzxMnafGKg
dnIKEbWda6g8jL3aQ4jwPq1MxMj9CGmYaZz8fM9GCu0wchWW6O6CA6UyCCnr2K8gGCAn
w+dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=m3x0hYrNJY7EDEgmP0Dd4zwCXx6UVe1pHt5OWd3442M=;
b=fcQt9cRJavpf83MfO936Ag3dnECU+wJUVblSKK5WYQkXyIN9jszs/NTKqZwAjJ9+BJ
gp0c3BO5NNlQaHtr/TplnL4QCMMIcnbFS1NX/BNSsU6j6Exbmuy0FkSo3L/t5ByxQiVQ
cOVhRJCw+QKY634FvMjNB5gaqHwmsoEkHR21Q+RXelrhqvnlO/3sJ9gqJEWwio8R/GXN
/Yg0Un9r7lmRzn52XYI3lBU26A1iEU9+33d8ZXgggAbmFJ67CYnhStgVNFUS4tElBfAo
Qd8f3O2AyletE1HZ4wh/Ms6pHp28usdnC8NYoMZT3k0BAC7L0k14NgYMJRsHEB2Yi0e8
dq4w==
X-Gm-Message-State: AA+aEWa3AAXtNsG3YAQlOej3vxXunbW6NjfkOcmpC/vLPc37rfq4+Mpr
d3YuQ6li26UJBZFSWQtQ0ztPYS5VAG8BPBcn/6pvFBXa
X-Google-Smtp-Source: AFSGD/UUVuRajX0Nho4L8Y0Rsl7xF1BJc3nIAMhsvE+UgfOQOg32U9xVpbKg05wEARc6ZyLf9OSVseaNzr9vyqDXu9Q=
X-Received: by 2002:a5d:5089:: with SMTP id a9mr7315071wrt.327.1543640815309;
Fri, 30 Nov 2018 21:06:55 -0800 (PST)
MIME-Version: 1.0
References: <CAAQdECAGuScCLoG_62g6G__yiyN8KRiPDBGYJ2pDBwxRCNFtZQ@mail.gmail.com>
In-Reply-To: <CAAQdECAGuScCLoG_62g6G__yiyN8KRiPDBGYJ2pDBwxRCNFtZQ@mail.gmail.com>
From: James MacWhyte <macwhyte@gmail.com>
Date: Fri, 30 Nov 2018 21:06:29 -0800
Message-ID: <CAH+Axy5Qa+2YHLhmnoqLR-94QmWyePcckDjj+8jGrU37q51ZCA@mail.gmail.com>
To: nothingmuch@woobling.org,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007518bf057beee20e"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 01 Dec 2018 14:04:25 +0000
Subject: Re: [bitcoin-dev] draft proposal: change forwarding (improved
fungibility through wallet interoperability)
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: Sat, 01 Dec 2018 05:06:57 -0000
--0000000000007518bf057beee20e
Content-Type: text/plain; charset="UTF-8"
Hi Yuval!
Sorry for reviving an old email thread. Could you describe what the UX
would be like, or how a wallet developer might implement this? Is the
intention that someone would open their non-private wallet, and choose an
option that slowly siphons their funds into a different app? Why would
anyone want that feature?
If the user is privacy-conscious, why did they choose the non-private
wallet to begin with? Why wouldn't they just move all their funds to the
private wallet so they can continue to use just one app?
And if the user is not privacy-conscious, they would never choose to enable
this option, so why would the wallet developer even bother to implement it?
From a product standpoint, I can't see how this would be useful, and
therefore I'm not sure why it needs to be a BIP. If I'm missing something,
please let me know!
Thanks,
James
On Tue, Nov 6, 2018 at 10:18 AM Yuval Kogman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello,
>
> I would like to propose a method based on BIP32 (and optionally BIP44) for
> improving fungibility and on chain privacy with wallets for which this is
> not a primary concern, requiring minimal changes to allow such wallets to
> safely forward change outputs to more specialized wallets. This is intended
> to complement more comprehensive proposals such as BIP79.
>
> Note that this draft is still incomplete, there are open questions about
> the particular format to use. In its current form it proposes two viable
> options (and two more are included completeness) and though I have a slight
> preference for the first option, I remain undecided given the tradeoffs,
> and so I am writing the mailing list to solicit inputs/criticism.
>
> https://gist.github.com/nothingmuch/652f3a98089a0600637eadab738b2d6a
>
> Thanks to SirMeow, Adam Ficsor, and Adam Gibson for reviewing earlier
> versions and providing valuable feedback and suggestions.
>
> Regards,
> Yuval
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000007518bf057beee20e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Yuval!<div><br></div><div>Sorry for reviving an old ema=
il thread. Could you describe what the UX would be like, or how a wallet de=
veloper might implement this? Is the intention that someone would open thei=
r non-private wallet, and choose an option that slowly siphons their funds =
into a different app? Why would anyone want that feature?<div><br></div><di=
v>If the user is privacy-conscious, why did they choose the non-private wal=
let to begin with? Why wouldn't they just move all their funds to the p=
rivate wallet so they can continue to use just one app?<br><br>And if the u=
ser is not privacy-conscious, they would never choose to enable this option=
, so why would the wallet developer even bother to implement it?</div><div>=
<br></div><div>From a product standpoint, I can't see how this would be=
useful, and therefore I'm not sure why it needs to be a BIP. If I'=
m missing something, please let=C2=A0me know!</div><div><br></div><div>Than=
ks,</div><div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmai=
l=3D"gmail_signature"><div dir=3D"ltr"><div>James<br></div></div></div></di=
v><br></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On =
Tue, Nov 6, 2018 at 10:18 AM Yuval Kogman via bitcoin-dev <<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati=
on.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div dir=3D"ltr"><div dir=3D"ltr">Hello,<div><br></div><div>I would lik=
e to propose a method based on BIP32 (and optionally BIP44) for improving f=
ungibility and on chain privacy with wallets for which this is not a primar=
y concern, requiring minimal changes to allow such wallets to safely forwar=
d change outputs to more specialized wallets. This is intended to complemen=
t more comprehensive proposals such as BIP79.</div><div><br></div><div>Note=
that this draft is still incomplete, there are open questions about the pa=
rticular format to use. In its current form it proposes two viable options =
(and two more are included completeness) and though I have a slight prefere=
nce for the first option, I remain undecided given the tradeoffs, and so I =
am writing the mailing list to solicit inputs/criticism.</div><div><br></di=
v><div><a href=3D"https://gist.github.com/nothingmuch/652f3a98089a0600637ea=
dab738b2d6a" target=3D"_blank">https://gist.github.com/nothingmuch/652f3a98=
089a0600637eadab738b2d6a</a><br></div><div><br></div><div>Thanks to SirMeow=
, Adam Ficsor, and Adam Gibson for reviewing earlier versions and providing=
valuable feedback and suggestions.</div><div><br></div><div>Regards,</div>=
<div>Yuval</div></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--0000000000007518bf057beee20e--
|
