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
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1WFsVd-0005Pt-6H
for bitcoin-development@lists.sourceforge.net;
Tue, 18 Feb 2014 21:47:21 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.98 as permitted sender)
client-ip=62.13.148.98; envelope-from=pete@petertodd.org;
helo=outmail148098.authsmtp.com;
Received: from outmail148098.authsmtp.com ([62.13.148.98])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WFsVb-0000fP-Am for bitcoin-development@lists.sourceforge.net;
Tue, 18 Feb 2014 21:47:21 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s1ILlCI1099346;
Tue, 18 Feb 2014 21:47:12 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s1ILl7N7013492
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 18 Feb 2014 21:47:10 GMT
Date: Tue, 18 Feb 2014 16:47:22 -0500
From: Peter Todd <pete@petertodd.org>
To: "Ryan X. Charles" <ryan@bitpay.com>
Message-ID: <20140218214721.GA25356@savin>
References: <le05ca$qn5$1@ger.gmane.org>
<5303B110.70603@bitpay.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW"
Content-Disposition: inline
In-Reply-To: <5303B110.70603@bitpay.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 3849ab7f-98e6-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwoUHlAWAgsB AmIbWVVeVFp7WGM7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrAGV9 WhlgVRlzdAFPejBx ZEFkXj5YVEBzJBR6
FFNdHTgAeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4hPwZj H1gaBzI3GlYIS204 LxUgJVMHdAAA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/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
X-Headers-End: 1WFsVb-0000fP-Am
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP70 proposed changes
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: Tue, 18 Feb 2014 21:47:21 -0000
--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Feb 18, 2014 at 02:14:24PM -0500, Ryan X. Charles wrote:
> The payment protocol is also the perfect opportunity to implement merge
> avoidance to increase customer and merchant privacy. The merchant can
> simply deliver multiple outputs in the payment details, say 10 or so,
> and the customer can spend multiple outputs to those outputs in separate
> transactions. It would be great if BitPay could work with wallet authors
> to make merge avoidance a reality in the near-term.
>=20
> Merge avoidance would increase the need to have a bitcoin-paymentstatus
> message since it's possible that some, but not all, of the transactions
> would confirm, and so knowing the status of payment would be a complex
> question that should be handled automatically by the software.
Note that merge-avoidance implemented in conjunction CoinJoin doesn't
have this problem - the CoinJoin'd transaction either does or doesn't
confirm. Meanwhile being able to avoid merges, or more precisely, being
able to be flexible with them, makes achiving good value-privacy much
easier.
Secondly merge-flexibility also makes cut-thru payments possible. For
example BitPay can direct customers paying for goods to pay to addresses
controlled by merchants and other parties who are owed money by BitPay.
This skips a step, saving on transction fees as well as increasing
privacy. Notably in this case the only parties that have to deal with
accounting complexity are BitPay and the merchants - consumers' wallet
software needs no changes beyond generic payment protocol support, and
notably you can even use this technique without the payment protocol.
See my post "DarkWallet Best Practices" for more info:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03=
508.html
> On an unrelated note, X.509 is a terrible standard that should be
> abandoned as quickly as possible. BitPay is working on a new standard
> based on bitcoin-like addresses for authentication. It would be great if
> we could work with the community to establish a complete, decentralized
> authentication protocol. The sooner we can evolve beyond X.509 the better.
What specifically do you dislike about X.509? The technical standard or
the infrastructure around it? (IE the centralized authorities)
--=20
'peter'[:-1]@petertodd.org
000000000000000051ad2df596f45df71320fb44b3c5f1b50231a591ffeb1d24
--0F1p//8PRICkK4MW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJTA9TpXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA1MWFkMmRmNTk2ZjQ1ZGY3MTMyMGZiNDRiM2M1ZjFiNTAy
MzFhNTkxZmZlYjFkMjQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkft5VQf9G7sebMqLguwzLRdssq1s5n5a
2CBz9Hl0oxO+CGMLVwTbCIqxZDd8g5mDWAZfyKmlp2PuRx3+brX1fr5oZOa1dZLr
Uq5DsulDV8WmlHqo/WYFhfMXocVgCVMZ8q4Hzh1FVGkl9PnYIykNaOHsTwD5CHVC
cYIpxm5XWx7EHIMGO1Sge9LWG/eEn1LAAja13472fPUOOWkWwTV9FWUotVVb8bcM
GYc6tk3OuxUOmkeYC1UEGPPAVHtL5hcW5/MS3j+TtxZc0kKFX1pMlmQcyeGAUWFr
MmX85gYFL7/X3SD/Cgo0oegGwQDEgYtDQErgOBjBbvLi+Jt/jkVxjxLrpLZHAw==
=sijw
-----END PGP SIGNATURE-----
--0F1p//8PRICkK4MW--
|
