path: root/d3/be91a0f38119ab83ddb55388ea54fa2bdb6da4

Return-Path: <nothingmuch@woobling.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C1FC19D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  1 Dec 2018 15:34:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com
	[209.85.128.53])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A9AA419B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  1 Dec 2018 15:34:18 +0000 (UTC)
Received: by mail-wm1-f53.google.com with SMTP id z18so1715816wmc.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 01 Dec 2018 07:34:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=woobling.org; s=google;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=ZYd7BralvjVGNG+r+Uz/MMGQ+UHC4okz6CFEaBkVMBw=;
	b=mvnSgmxyUl76tYws9xapTCDtqmVkrtI9AmhPblEVWde4RLwAAcXz69YPD8CA07dMR4
	YGJFA9E0uvX9FrovOgXA0uvZ61iOOKd3jc6+ghLU0fo+flELfgOF1b2ziqXD3ySzFe7V
	umbeszy2v62//EPA/na6GjlQxP15t98KnhZbo=
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:cc;
	bh=ZYd7BralvjVGNG+r+Uz/MMGQ+UHC4okz6CFEaBkVMBw=;
	b=GCoId20XYr7IfLDU/6wAkSZ1BsnFPQOVWhtRUIn7xYleL12bo67T3fhI4YDt/GLxt3
	AnCnoIKaPhJwKasx2iEmUH2frDjtLevEk2qwqzG8ofcX3j9x7EzPTp9CwN0AjjubadFX
	aN3CJ7PztseH0uiLDGG/9sgfacN5Q1I+K1UE63rtGzfpIIZv9VXoPFvzituy/ML6Pe+J
	PHEu8xTW4RYq+EPlYR+FR1YeA/D1ZSMnmZ4+AbjqGf0i9U7ePVYDBCUfe6B2fz3VwG6M
	oYSs+Oxlqmh9A1HW4wWDHtkJRN2rGUKUqHKlx58lU9vH98sH0on0zTzLR22qIYqDdKYH
	HIsw==
X-Gm-Message-State: AA+aEWZBToUH3bgX6SVQtL22gaHo73fR2Qc+4Mi8Vhyu0zbC5d5yThX2
	YzDPfi2k9tMWmYWHBNnb6RAO1HnuT7OVvUgjc+LjYQ==
X-Google-Smtp-Source: AFSGD/Xxf0CCO/q+VXRAYfpPa11qPXJX/3evgxwk1Ij1OiS77w2bOyDNckT7smApQC0WF/AYip7vBujF2f687EEH+l4=
X-Received: by 2002:a1c:ac42:: with SMTP id v63mr2480163wme.119.1543678456123; 
	Sat, 01 Dec 2018 07:34:16 -0800 (PST)
MIME-Version: 1.0
References: <CAAQdECAGuScCLoG_62g6G__yiyN8KRiPDBGYJ2pDBwxRCNFtZQ@mail.gmail.com>
	<CAH+Axy5Qa+2YHLhmnoqLR-94QmWyePcckDjj+8jGrU37q51ZCA@mail.gmail.com>
In-Reply-To: <CAH+Axy5Qa+2YHLhmnoqLR-94QmWyePcckDjj+8jGrU37q51ZCA@mail.gmail.com>
From: Yuval Kogman <nothingmuch@woobling.org>
Date: Sat, 1 Dec 2018 15:33:52 +0000
Message-ID: <CAAQdECC8V4cQxYOPda9+Fuob+n5oMx1vkfcv95sPaDyjTPyQKw@mail.gmail.com>
To: macwhyte@gmail.com
Content-Type: multipart/alternative; boundary="000000000000067054057bf7a6e4"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, 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: Sun, 02 Dec 2018 16:24:35 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
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 15:34:19 -0000

--000000000000067054057bf7a6e4
Content-Type: text/plain; charset="UTF-8"

Hi,

On Sat, 1 Dec 2018 at 05:06, James MacWhyte <macwhyte@gmail.com> wrote:

> Is the intention that someone would open their non-private wallet, and
> choose an option that slowly siphons their funds into a different app?
>

Yes, that's the idea. And then send them back in a controlled manner.


> Why would anyone want that feature?
>

Most mobile wallets have no coin control features, which are tricky to
implement (lots of design/UI effort required). Some special purpose wallets
have additional privacy concerns and also lack coin control - for example
protip.is may inadvertently disclose browsing habits, or bisq arbitration
contracts are easily identifiable on the blockchain. The latter is actually
an inspiration to this, since it has functionality to allow funding
transactions from an external wallet, as well as withdrawing to one.

Conversely, fungibility focused wallets are highly specialized and limited
in scope. As far as I'm aware, JoinMarket and Wasabi are the only
maintained implementations of mixing wallets available today, and both are
desktop apps, with no hardware wallet integration. It is unlikely that e.g.
coinjoin functionality would be added the application specific wallets,
especially as these features require a great deal of care and effort to do
correctly (cf. SharedCoin)

The goal then is to allow people who are privacy conscious to utilize a
specialized wallet automatically, to isolate the activity of wallets which
don't provide a sufficient degree of control in order to achieve that
manually, and reducing the possibility of operator error.

Could you describe what the UX would be like
>

From a payment standpoint the main difference is that change outputs would
not be usable, so the spendable balance would drop. The best idea I have
for handling that is to still display that balance but conveying that is
locked. However, I think simply removing it from the balance is also
acceptable. Funds would simply be added to the fungibility wallet similarly
to how they are used manually today.

For setup, the fungibility wallet would need to add functionality to export
these xpub variants, perhaps with a way of annotating what each account is
for (but see concerns about BIP44 recoverability). Like standard xpubs,
these would be easily conveyed by QR code.

The forwarding wallet would then offer an advanced configuration feature,
that allows adding and enabling the alternate change address chain. If the
fungibility wallet derives addresses differently, then the forwarding
wallet should reject the configuration value (which is the main technical
point of the writeup), to ensure funds are not misplaced.


> or how a wallet developer might implement this?
>

For fungibility wallets, this requires keeping track of these address
chains, and allowing them to be exported. This is similar to any sort of
scanning functionality implemented in a BIP32 capable wallet, plus the UI
to display them.

In the forwarding wallet, derivation of addresses is again already
implemented in any BIP32 capable wallet (i.e. checking for the next free
address), with the main change in the spending path being dependency
injection required to change the address chain parameters (from what I know
most BIP32 implementations are polymorphic with respect to derivations made
from a public extended key vs. a private extended key). The main effort
then is the setup functionality, which obviously will vary considerably
between wallets, but I imagine it would still be a simpler and safer change
than integrating comprehensive privacy features into the spend path
directly.

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

Platform limitations, or application specific use cases, see above. More
broadly, the main rationale is that diverse, specialized wallets should be
used in a complementary way, as that is more achievable than expecting all
application specific wallets to have robust privacy features.

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

I believe this is a low hanging fruit, easier to implement than coin
control, far easier to implement than safe mixing functionality, so wallet
developers (or contributes) would implement this to allow users more
reliable access to privacy features implemented by other wallets.


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

The reason for documenting it in this way is because if deemed desirable
functionality (which itself is something the BIP process can help
determine), different implementations would need to agree on the details. I
hope I've managed to convince you of the usefulness, though I'm still not
sure about the practicality or desirability - as it stands right now I have
received fairly comprehensive criticism from LaurentMT though, and I've
been focusing on related idea to improve zerolink which I hope would to
revisit this change forwarding idea and address his concerns when I have
more clarity. The main weakness is the assumptions that fungibility wallets
handle arbitrary amounts allowing those funds to be tumbled and
recycled/consolidated, which realistically only applies to Join Market and
even then only if used correctly.

Regards,
Yuval

--000000000000067054057bf7a6e4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On =
Sat, 1 Dec 2018 at 05:06, James MacWhyte &lt;<a href=3D"mailto:macwhyte@gma=
il.com">macwhyte@gmail.com</a>&gt; wrote:</div><div dir=3D"ltr"><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Is the intenti=
on that someone would open their non-private wallet, and choose an option t=
hat slowly siphons their funds into a different app?</div></div></blockquot=
e><div><br></div><div><div dir=3D"ltr"><div>Yes, that&#39;s the idea. And t=
hen send them back in a controlled manner.</div></div></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>W=
hy would anyone want that feature?</div></div></blockquote><div><br></div><=
div>Most mobile wallets have no coin control features, which are tricky to =
implement (lots of design/UI effort required). Some special purpose wallets=
 have additional privacy concerns and also lack coin control - for example =
<a href=3D"http://protip.is">protip.is</a> may inadvertently disclose brows=
ing habits, or bisq arbitration contracts are easily identifiable on the bl=
ockchain. The latter is actually an inspiration to this, since it has funct=
ionality to allow funding transactions from an external wallet, as well as =
withdrawing to one.</div><div><div><br class=3D"gmail-Apple-interchange-new=
line">Conversely, fungibility focused wallets are highly specialized and li=
mited in scope. As far as I&#39;m aware, JoinMarket and Wasabi are the only=
 maintained implementations of mixing wallets available today, and both are=
 desktop apps, with no hardware wallet integration. It is unlikely that e.g=
. coinjoin functionality would be added the application specific wallets, e=
specially as these features require a great deal of care and effort to do c=
orrectly (cf. SharedCoin)</div></div><div><br></div><div>The goal then is t=
o allow people who are privacy conscious to utilize a specialized wallet au=
tomatically, to isolate the activity of wallets which don&#39;t provide a s=
ufficient degree of control in order to achieve that manually, and reducing=
 the possibility of operator error.</div><div><br></div></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div>Could you describe what the UX woul=
d be like</div></div></blockquote><div><br></div><div>From a payment standp=
oint the main difference is that change outputs would not be usable, so the=
 spendable balance would drop. The best idea I have for handling that is to=
 still display that balance but conveying that is locked. However, I think =
simply removing it from the balance is also acceptable. Funds would simply =
be added to the fungibility wallet similarly to how they are used manually =
today.</div><div><br></div><div>For setup, the fungibility wallet would nee=
d to add functionality to export these xpub variants, perhaps with a way of=
 annotating what each account is for (but see concerns about BIP44 recovera=
bility). Like standard xpubs, these would be easily conveyed by QR code.</d=
iv><div><br></div><div>The forwarding wallet would then offer an advanced c=
onfiguration feature, that allows adding and enabling the alternate change =
address chain. If the fungibility wallet derives addresses differently, the=
n the forwarding wallet should reject the configuration value (which is the=
 main technical point of the writeup), to ensure funds are not misplaced.</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>o=
r how a wallet developer might implement this?</div></div></blockquote><div=
><br></div><div>For fungibility wallets, this requires keeping track of the=
se address chains, and allowing them to be exported. This is similar to any=
 sort of scanning functionality implemented in a BIP32 capable wallet, plus=
 the UI to display them.</div><div><br></div><div>In the forwarding wallet,=
 derivation of addresses is again already implemented in any BIP32 capable =
wallet (i.e. checking for the next free address), with the main change in t=
he spending path being dependency injection required to change the address =
chain parameters (from what I know most BIP32 implementations are polymorph=
ic with respect to derivations made from a public extended key vs. a privat=
e extended key). The main effort then is the setup functionality, which obv=
iously will vary considerably between wallets, but I imagine it would still=
 be a simpler and safer change than integrating comprehensive privacy featu=
res into the spend path directly.</div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div><div>If the user is privacy-conscious, why =
did they choose the non-private wallet to begin with? Why wouldn&#39;t they=
 just move all their funds to the private wallet so they can continue to us=
e just one app?<br></div></div></div></blockquote><div><br></div><div>Platf=
orm limitations, or application specific use cases, see above. More broadly=
, the main rationale is that diverse, specialized wallets should be used in=
 a complementary way, as that is more achievable than expecting all applica=
tion specific wallets to have robust privacy features.</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>And if the user i=
s not privacy-conscious, they would never choose to enable this option, so =
why would the wallet developer even bother to implement it?</div></div></di=
v></blockquote><div><br></div><div>I believe this is a low hanging fruit, e=
asier to implement than coin control, far easier to implement than safe mix=
ing functionality, so wallet developers (or contributes) would implement th=
is to allow users more reliable access to privacy features implemented by o=
ther wallets.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div>From a product standpoint, I can&#39;t see how this woul=
d be useful, and therefore I&#39;m not sure why it needs to be a BIP. If I&=
#39;m missing something, please let=C2=A0me know!</div></div></div></blockq=
uote><div><br></div><div>The reason for documenting it in this way is becau=
se if deemed desirable functionality (which itself is something the BIP pro=
cess can help determine), different implementations=C2=A0would need to agre=
e on the details. I hope I&#39;ve managed to convince you of the usefulness=
, though I&#39;m still not sure about the practicality or desirability - as=
 it stands right now I have received fairly comprehensive criticism from La=
urentMT though, and I&#39;ve been focusing on related idea to improve zerol=
ink which I hope would to revisit this change forwarding idea and address h=
is concerns when I have more clarity. The main weakness is the assumptions =
that fungibility wallets handle arbitrary amounts allowing those funds to b=
e tumbled and recycled/consolidated, which realistically only applies to Jo=
in Market and even then only if used correctly.</div><div><br></div><div>Re=
gards,</div><div>Yuval<br></div></div></div>

--000000000000067054057bf7a6e4--