Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C1FC19D for ; 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 ; Sat, 1 Dec 2018 15:34:18 +0000 (UTC) Received: by mail-wm1-f53.google.com with SMTP id z18so1715816wmc.4 for ; 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: In-Reply-To: From: Yuval Kogman Date: Sat, 1 Dec 2018 15:33:52 +0000 Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
Hi,

On = Sat, 1 Dec 2018 at 05:06, James MacWhyte <macwhyte@gmail.com> wrote:
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?

Yes, that's the idea. And t= hen send them back in a controlled manner.
=C2=A0
W= hy would anyone want that feature?

<= 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 = protip.is 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.

Conversely, fungibility focused wallets are highly specialized and li= mited 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, e= specially as these features require a great deal of care and effort to do c= orrectly (cf. SharedCoin)

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't provide a s= ufficient degree of control in order to achieve that manually, and reducing= the possibility of operator error.

Could you describe what the UX woul= d be like

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.

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.

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.
=C2=A0
o= r how a wallet developer might implement this?

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.

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.

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 us= e just one app?

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.

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

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.
=C2=A0
From a product standpoint, I can't see how this woul= d be useful, and therefore I'm not sure why it needs to be a BIP. If I&= #39;m missing something, please let=C2=A0me know!

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'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 La= urentMT though, and I'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.

Re= gards,
Yuval
--000000000000067054057bf7a6e4--