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
|
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 <pieter.wuille@gmail.com>) id 1Win4K-0006Il-5u
for bitcoin-development@lists.sourceforge.net;
Fri, 09 May 2014 15:50:40 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.182 as permitted sender)
client-ip=209.85.223.182; envelope-from=pieter.wuille@gmail.com;
helo=mail-ie0-f182.google.com;
Received: from mail-ie0-f182.google.com ([209.85.223.182])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Win4J-00085l-4f
for bitcoin-development@lists.sourceforge.net;
Fri, 09 May 2014 15:50:40 +0000
Received: by mail-ie0-f182.google.com with SMTP id tp5so4248703ieb.41
for <bitcoin-development@lists.sourceforge.net>;
Fri, 09 May 2014 08:50:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.43.136 with SMTP id w8mr10712527igl.20.1399650633178;
Fri, 09 May 2014 08:50:33 -0700 (PDT)
Received: by 10.50.100.72 with HTTP; Fri, 9 May 2014 08:50:33 -0700 (PDT)
In-Reply-To: <CANEZrP0Yom_JjN2PnPsfKV5S4wZSze4XTcJJU2ZWee4VGo20tw@mail.gmail.com>
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>
Date: Fri, 9 May 2014 17:50:33 +0200
Message-ID: <CAPg+sBh-OA7xSp3=SEGS1fP-d2CDMzMy_=S_jOs1hvdaWTw0mA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Win4J-00085l-4f
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 15:50:40 -0000
I believe stealth addresses and the payment protocol both have their
use cases, and that they don't overlap.
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.
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.
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.
On Fri, May 9, 2014 at 5:34 PM, Mike Hearn <mike@plan99.net> wrote:
>> Ah, you're still misunderstanding my point: You can get atomicity in the
>> worst-case where the communications medium fails *and* stealth payments
>> that use up no extra space in the blockchain. This gives you the best of
>> both worlds.
>
>
> Sounds great! How does a lightweight client identify such transactions
> without any markers?
>
> Regardless, there are lots of other useful features that require BIP70 to
> work well person to person, like messages, refund addresses, etc. So
> extending it with ECDH makes sense in the end anyway no matter what.
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
