From: Yuval Kogman <nothingmuch@woobling•org>
To: macwhyte@gmail•com
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] draft proposal: change forwarding (improved fungibility through wallet interoperability)
Date: Sat, 1 Dec 2018 15:33:52 +0000 [thread overview]
Message-ID: <CAAQdECC8V4cQxYOPda9+Fuob+n5oMx1vkfcv95sPaDyjTPyQKw@mail.gmail.com> (raw)
In-Reply-To: <CAH+Axy5Qa+2YHLhmnoqLR-94QmWyePcckDjj+8jGrU37q51ZCA@mail.gmail.com>
[-- 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 --]
prev parent reply other threads:[~2018-12-01 15:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-06 15:50 Yuval Kogman
2018-12-01 5:06 ` James MacWhyte
2018-12-01 15:33 ` Yuval Kogman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAQdECC8V4cQxYOPda9+Fuob+n5oMx1vkfcv95sPaDyjTPyQKw@mail.gmail.com \
--to=nothingmuch@woobling$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=macwhyte@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox