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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1Z1FnF-0004hG-CE
for bitcoin-development@lists.sourceforge.net;
Sat, 06 Jun 2015 15:13:53 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.218.49 as permitted sender)
client-ip=209.85.218.49; envelope-from=pieter.wuille@gmail.com;
helo=mail-oi0-f49.google.com;
Received: from mail-oi0-f49.google.com ([209.85.218.49])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z1FnE-0001sM-31
for bitcoin-development@lists.sourceforge.net;
Sat, 06 Jun 2015 15:13:53 +0000
Received: by oiha141 with SMTP id a141so6813917oih.0
for <bitcoin-development@lists.sourceforge.net>;
Sat, 06 Jun 2015 08:13:46 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.202.187.138 with SMTP id l132mr7014977oif.31.1433603626669;
Sat, 06 Jun 2015 08:13:46 -0700 (PDT)
Received: by 10.60.94.36 with HTTP; Sat, 6 Jun 2015 08:13:46 -0700 (PDT)
In-Reply-To: <CAPswA9zhB4GV=JJ28RRLFNrkVwExUv36zujmuAjwPd6rG6rvzQ@mail.gmail.com>
References: <CAPswA9w5Sgg6AV=9Pqx5sqbkdrwv9LmwoxmMu7xZsQSNXtmZnQ@mail.gmail.com>
<CAPg+sBjtovFpLoibpVGLsNJXexBcoiYzjrvctraXntCUZBJsGg@mail.gmail.com>
<CAPswA9zhB4GV=JJ28RRLFNrkVwExUv36zujmuAjwPd6rG6rvzQ@mail.gmail.com>
Date: Sat, 6 Jun 2015 17:13:46 +0200
Message-ID: <CAPg+sBjsjtSamZaBd-6tLLv0qjAHvEBgSbh4HBCUV2Z7hpioGQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Kalle Rosenbaum <kalle@rosenbaum.se>
Content-Type: multipart/alternative; boundary=001a113ccf4aea9f300517dadac7
X-Spam-Score: -0.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
1.0 HTML_MESSAGE BODY: HTML included in message
-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
0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z1FnE-0001sM-31
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP for Proof of Payment
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: Sat, 06 Jun 2015 15:13:53 -0000
--001a113ccf4aea9f300517dadac7
Content-Type: text/plain; charset=UTF-8
On Sat, Jun 6, 2015 at 5:05 PM, Kalle Rosenbaum <kalle@rosenbaum.se> wrote:
> > What do you gain by making PoPs actually valid transactions? You could
> for
> > example change the signature hashing algorithm (prepend a constant
> string,
> > or add a second hashing step) for signing, rendering the signatures in a
> PoP
> > unusable for actual transaction, while still committing to the same
> actual
> > transaction. That would also remove the need for the OP_RETURN to catch
> > fees.
>
> The idea is to simplify implementation. Existing software can be used
> as is to sign and validate PoPs. But I do agree that it would be a
> cleaner specification if we would make the PoP invalid as a
> transaction. I'm open to changes here. I do like the idea to prepend a
> constant string. But that would require changes in transaction signing
> and validation code, wouldn't it?
>
Yes, of course. An alternative is adding a 21M BTC output at the end, or
bitflipping the txin prevout hashes, or another reversible transformation
on the transaction data that is guaranteed to invalidate it.
I think that the risk of asking people to sign something that is not an
actual transaction, but could be used as one, is very scary.
> > Also, I would call it "proof of transaction intent", as it's a
> commitment to
> > a transaction and proof of its validity, but not a proof that an actual
> > transaction took place, nor a means to prevent it from being double
> spent.
>
>
> Naming is hard. I think a simpler name that explains what its main
> purpose is (prove that you paid for something) is better than a name
> that exactly tries to explain what it is.
"Proof of Payment" indeed does make me think it's something that proves you
paid. But as described, that is not what a PoP does. It proves the ability
to create a particular transaction, and committing to it. There is no
actual payment involved (plus, payment makes me think you're talking about
BIP70 payments, not simple Bitcoin transactions).
> "Proof of transaction
> intent" does not help me understand what this is about. But I would
> like to see more name suggestions. The name does not prevent people
> from using it for other purposes, ie internet over telephone network.
>
I don't understand why something like "Proof of Transaction Intent" would
be incompatible with internet over telephone network either...
--
Pieter
--001a113ccf4aea9f300517dadac7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sat, Jun 6, 2015 at 5:05 PM, Kalle Rosenbaum <span dir=
=3D"ltr"><<a href=3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@=
rosenbaum.se</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">> What =
do you gain by making PoPs actually valid transactions? You could for<br>
> example change the signature hashing algorithm (prepend a constant str=
ing,<br>
> or add a second hashing step) for signing, rendering the signatures in=
a PoP<br>
> unusable for actual transaction, while still committing to the same ac=
tual<br>
> transaction. That would also remove the need for the OP_RETURN to catc=
h<br>
> fees.<br>
<br>
</span>The idea is to simplify implementation. Existing software can be use=
d<br>
as is to sign and validate PoPs. But I do agree that it would be a<br>
cleaner specification if we would make the PoP invalid as a<br>
transaction. I'm open to changes here. I do like the idea to prepend a<=
br>
constant string. But that would require changes in transaction signing<br>
and validation code, wouldn't it?<br></blockquote><div><br></div><div>Y=
es, of course. An alternative is adding a 21M BTC output at the end, or bit=
flipping the txin prevout hashes, or another reversible transformation on t=
he transaction data that is guaranteed to invalidate it.<br><br></div><div>=
I think that the risk of asking people to sign something that is not an act=
ual transaction, but could be used as one, is very scary.<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
> Also, I would call it "proof of transaction intent", as it&#=
39;s a commitment to<br>
> a transaction and proof of its validity, but not a proof that an actua=
l<br>
> transaction took place, nor a means to prevent it from being double sp=
ent.<br>
<br>
<br>
</span>Naming is hard. I think a simpler name that explains what its main<b=
r>
purpose is (prove that you paid for something) is better than a name<br>
that exactly tries to explain what it is. </blockquote><div><br></div><div>=
"Proof of Payment" indeed does make me think it's something t=
hat proves you paid. But as described, that is not what a PoP does. It prov=
es the ability to create a particular transaction, and committing to it. Th=
ere is no actual payment involved (plus, payment makes me think you're =
talking about BIP70 payments, not simple Bitcoin transactions).<br>=C2=A0<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">"Proof of transaction<br>
intent" does not help me understand what this is about. But I would<br=
>
like to see more name suggestions. The name does not prevent people<br>
from using it for other purposes, ie internet over telephone network.<br></=
blockquote><div><br></div><div>I don't understand why something like &q=
uot;Proof of Transaction Intent" would be incompatible with internet o=
ver telephone network either...<br><br>-- <br></div><div>Pieter<br>=C2=A0<b=
r></div></div></div></div>
--001a113ccf4aea9f300517dadac7--
|
