[Bitcoin-development] Merge avoidance and P2P connection encryption

Peter Todd pete at petertodd.org
Fri Dec 13 14:43:09 UTC 2013

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 at bitpay.com> wrote:
>On Thu, Dec 12, 2013 at 7:20 PM, Gavin Andresen
><gavinandresen at gmail.com> wrote:
>> If the use case is:  I give the Foundation a "here's where to pay my
>> PaymentRequest, maybe with several Outputs each having a different
>> then it seems to me the Foundation's wallet software should take care
>> 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.
Version: APG v1.0.9


More information about the bitcoin-dev mailing list