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
144
145
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1WipJJ-0003GE-4o
for bitcoin-development@lists.sourceforge.net;
Fri, 09 May 2014 18:14:17 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.84 as permitted sender)
client-ip=62.13.149.84; envelope-from=pete@petertodd.org;
helo=outmail149084.authsmtp.net;
Received: from outmail149084.authsmtp.net ([62.13.149.84])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WipJI-0003AK-20 for bitcoin-development@lists.sourceforge.net;
Fri, 09 May 2014 18:14:17 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s49IE8xC011863;
Fri, 9 May 2014 19:14:08 +0100 (BST)
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 s49IE57I096804
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 9 May 2014 19:14:07 +0100 (BST)
Date: Fri, 9 May 2014 14:13:53 -0400
From: Peter Todd <pete@petertodd.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20140509181353.GB27819@savin>
References: <CANEZrP3VNXSc2cd3b9pz9iC2BR0-vG=tfYwMyUGBGaWPq+geXQ@mail.gmail.com>
<20140509150325.GA30436@savin>
<CANEZrP1m=-GWD5rLRe9vrx0JYKeKXghNw-a47ZbJTd1h3ngFww@mail.gmail.com>
<20140509152715.GA12421@savin>
<CANEZrP0Yom_JjN2PnPsfKV5S4wZSze4XTcJJU2ZWee4VGo20tw@mail.gmail.com>
<CAPg+sBh-OA7xSp3=SEGS1fP-d2CDMzMy_=S_jOs1hvdaWTw0mA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ"
Content-Disposition: inline
In-Reply-To: <CAPg+sBh-OA7xSp3=SEGS1fP-d2CDMzMy_=S_jOs1hvdaWTw0mA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: b6812097-d7a5-11e3-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgsUFVQNAgsB AmIbWl1eUVl7WWs7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrBRV4 cxsZKxl7cQ1GfDBx Y0ZqXj4JWkx7d0Z0
RVMAEjwDeGZhPWMC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4mNRIc DxEEVSkvEAUdTjQ2
Iho6YkYGG1oWOUI2 WQ84
X-Authentic-SMTP: 61633532353630.1023: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: 1WipJI-0003AK-20
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] ECDH in the payment protocol
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, 09 May 2014 18:14:17 -0000
--i0/AhcQY5QxfSsSZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, May 09, 2014 at 05:50:33PM +0200, Pieter Wuille wrote:
> I believe stealth addresses and the payment protocol both have their
> use cases, and that they don't overlap.
>=20
> If you do not want to communicate with the receiver, you typically do
> not want them to know who is paying or for what (otherwise you're
> already talking to them in some way, right?). That's perfect for
> things like anonymous donations.
>=20
> In pretty much every other case, communicating directly with the
> receiver has benefits. Negotiation of the transaction details,
> messages associated with the transaction, refund information, no need
> to scan the blockchain for incoming transaction... and the ability to
> cancel if either party doesn't agree.
>=20
> Instead of adding stealth functionality to the payment protocol as a
> last resort, I'd rather see the payment protocol improve its
> atomicity. Either you want the data channel sender->receiver, or you
> don't. If it isn't available and you want it, things should fail. If
> you don't want it, you shouldn't try to use it in the first place.
I don't think we're going to find that's practical unfortunately due to
change. Every payment I make ties up txouts, so if we try to base the
atomicity of payments on whether or not the payee decides to broadcast
the transaction the payor is stuck with txouts that they can't use until
the payee makes up their mind. That leads to lots and lots of nasty edge
cases.
OTOH if we base the atomicity of payment on whether or not a specific
txout exists everything those edge cases don't exist. Yes, that might
force us to expose transaction fees to the user, but after all it's the
user who has control over those fees.
A separate issue is IsStandard() rules, and a near-term project for me
is to write a much relaxed version of them based on soft-fork safe
whitelisting/blacklisting of opcodes, version numbers, mutability etc.
We can definitely get to the point where those rules will change very
little.
--=20
'peter'[:-1]@petertodd.org
00000000000000006d5945d2dddece39487c36673e56a292b619b1929ff3b40f
--i0/AhcQY5QxfSsSZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJTbRrcXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA3YzJkOGY3MTNlMmEzYzgwNGM2MjQ4Zjc4N2I2ZjU0ZDgw
MjYzZjM0ZDU4MTg5MzAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvlMgf+LTYdD062VsC+5Po/aUoozSOc
2v89oEgtsZ2T2t0eg4ZB11IAaI+6wqfOVXkJK2/ipYUcTqL831Udgth6wm9Yxqnd
fvde99jhY5dQFrRtAHBMbiQM+LZCDinARLxhI1KT6kGAFtQfxYWUml8Jqe1nyhq0
g4PqB6EypHrAfqAUTlr1F1qU83vvzXb+acrx+JvGFngMariRXTWxkfitRv++0+tC
RVgQkwSLfxMhEBLum7FxGBE/GWtJ9xVbCPKRvmlnjSq+LSnyCvBTiATzOK9Z6eI9
C44OXjmNZj1/eMTVZufZNIsgycE2wiI+7Qb0WIoEjx5Ky9TV7nOnk0VqEaWXJA==
=G5gP
-----END PGP SIGNATURE-----
--i0/AhcQY5QxfSsSZ--
|
