[bitcoin-dev] draft proposal: change forwarding (improved fungibility through wallet interoperability)

[bitcoin-dev] draft proposal: change forwarding (improved fungibility through wallet interoperability)

[Yuval Kogman]

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

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

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

Re: [bitcoin-dev] draft proposal: change forwarding (improved fungibility through wallet interoperability)

[James MacWhyte]

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

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
>

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

Re: [bitcoin-dev] draft proposal: change forwarding (improved fungibility through wallet interoperability)

[Yuval Kogman]

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

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

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