Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

[Peter Todd <pete@petertodd.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

So, vendors hat on, what would it take for, say, BitPay to implement merge avoidance and coinjoin together?

At the dark wallet hackathon when we were talking usability we decided that the main way to get coinjoin working well is to take advantage of non-time-critical payments to act as counterparties to time-critical payments. For instance BitPay could schedule a vendor payment to happen in full by some time in the future, say 1 day, and send the funds in one or more joins. The actual amounts sent in each tx are then picked to match the amounts desired by the counterparty who needs funds sent right now.

We expect this to be first implemented just as a "anonymize my coins" button for wallet software on always on machines; getting vendors on board would be gravy.

We may even allow joins to happen when one party pays less fees than the other, although this is tricky: the main Sybil resistance of coinjoin is fees so you don't want to overdo it. OTOH the idea of the NSA and Chinese equivalent wasting money completing each others joins is hilarious...


Jeff Garzik <jgarzik@bitpay.com> wrote:
>On Thu, Dec 12, 2013 at 7:20 PM, Gavin Andresen
><gavinandresen@gmail.com> wrote:
>> If the use case is:  I give the Foundation a "here's where to pay my
>salary"
>> PaymentRequest, maybe with several Outputs each having a different
>xpubkey,
>> then it seems to me the Foundation's wallet software should take care
>of
>> iterating.
>
>Absolutely.  This is a key address-non-reuse case we really need to
>solve.  Miner payouts, BitPay salary payouts, etc. all use a
>statically provided, manually changed address.
>
>Rotating through multiple outputs is a stopgap -- but IMO a useful
>one.  HD wallets will solve this in a better way, but existing randkey
>systems will be around for a long time.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.9

iQFQBAEBCAA6BQJSqxz9MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhTMBB/9L8h5NuSHxsC6W5ptm
gucxg2AbCwReuWQzRzqW42TYKQ7MnAhpfLLbSQrewNoXRP4H/j6aG8uWOt+z7fZf
pJZ9K8kxmSltHm8SJcmPLTb62yazEKQXF5TDsdpgBdH14M/pFsjUR4H2hypW8k4T
gcEAIhymZvlXev1NXDMh6rbuw0LtRTBE4NgE2buCuFzp0sEwTNTLxMU1WenMXfRQ
PooSBn8UoAVNw7Vztnag0T0f5D45VFNJBvQ8m42ee0u3gvMCa4JNRTBM49N2U9qc
Gk6WAvDakOf7FwaJiNMYoDpGyWphx6g697j28NnfB2q2hdjUVnZF+UVuBzkjnNwD
Y40/
=4dxZ
-----END PGP SIGNATURE-----