From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VrTzd-0006sv-1f for bitcoin-development@lists.sourceforge.net; Fri, 13 Dec 2013 14:45:29 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.108 as permitted sender) client-ip=62.13.148.108; envelope-from=pete@petertodd.org; helo=outmail148108.authsmtp.net; Received: from outmail148108.authsmtp.net ([62.13.148.108]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VrTzb-0004s7-SW for bitcoin-development@lists.sourceforge.net; Fri, 13 Dec 2013 14:45:28 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rBDEjKXd023493; Fri, 13 Dec 2013 14:45:20 GMT Received: from [10.170.249.152] ([111.91.234.160]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rBDEiaIO089188; Fri, 13 Dec 2013 14:44:40 GMT User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Peter Todd Date: Fri, 13 Dec 2013 21:43:09 +0700 To: Jeff Garzik , Gavin Andresen Message-ID: <38aa6d9e-15fa-46d2-80c8-1cde567290dd@email.android.com> X-Server-Quench: 2e243722-6405-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdwEUHFAXAgsB AmUbWlBeVFh7WGU7 agtQcwxcfEhNWxtr VkhWR1pVCwUmQ251 c0dPK2ZyfwxHcHY+ ZEVmWnQVXhF4cUV6 QExJE2kGYHphaTUc TRJQdwFJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDOzMm SB1KFCsoHEEMQS4+ ZxUgJhYkRn5ZOUI0 N1YqRVMfNX4fDAZE DllRAShfT9X/ X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 111.91.234.160/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: bitpay.com] X-Headers-End: 1VrTzb-0004s7-SW Cc: Bitcoin Dev , Paul Rabahy Subject: Re: [Bitcoin-development] Merge avoidance and P2P connection encryption X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 14:45:29 -0000 -----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 wrote: >On Thu, Dec 12, 2013 at 7:20 PM, Gavin Andresen > 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-----