summaryrefslogtreecommitdiff
path: root/f3/1adbb27b5aef1ef8188fa0c08836f6806fdeb1
blob: e732d0294845027735d6ef4ead1b365040cb897a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
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 <pete@petertodd.org>) 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: <CAJHLa0NUNpGWXv4WFhtkM0WXQMFmX98Tvp_O5p7aWqLXHf+H_A@mail.gmail.com>
References: <CANEZrP1gDxcKO8z4hgM9BJU6-+Ft0oaiCZjqjN4MxGEJCgs5Ng@mail.gmail.com>
	<CADu7o8MXuUVrRP0vsvEkPLJ4f=2pC6V7W3hYE0jCVDRKmvqu8A@mail.gmail.com>
	<CANEZrP33bRx6abbXcf6nQYiPXFOOWSsZJqiFZY+A08x6O3X+pg@mail.gmail.com>
	<CABsx9T0VEu15KXH_XPn+cAERQFz=Tmjqna6ZoNpLrxkzeKw9kQ@mail.gmail.com>
	<CAJHLa0NUNpGWXv4WFhtkM0WXQMFmX98Tvp_O5p7aWqLXHf+H_A@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
From: Peter Todd <pete@petertodd.org>
Date: Fri, 13 Dec 2013 21:43:09 +0700
To: Jeff Garzik <jgarzik@bitpay.com>, Gavin Andresen <gavinandresen@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>,
	Paul Rabahy <prabahy@gmail.com>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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-----