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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sipa@ulyssis.org>) id 1R7EyR-00007E-R8
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Sep 2011 23:16:03 +0000
X-ACL-Warn:
Received: from rhcavuit01.kulnet.kuleuven.be ([134.58.240.129]
helo=cavuit01.kulnet.kuleuven.be)
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1R7EyQ-0006Nk-2X for bitcoin-development@lists.sourceforge.net;
Fri, 23 Sep 2011 23:16:03 +0000
X-KULeuven-Envelope-From: sipa@ulyssis.org
X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5,
autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00,
FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20)
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 09DCC138025.ABCB8
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from smtps02.kuleuven.be (smtpshost02.kulnet.kuleuven.be
[134.58.240.75])
by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 09DCC138025
for <bitcoin-development@lists.sourceforge.net>;
Sat, 24 Sep 2011 01:15:49 +0200 (CEST)
Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be
[193.190.253.235])
by smtps02.kuleuven.be (Postfix) with ESMTP id C6229F3862
for <bitcoin-development@lists.sourceforge.net>;
Sat, 24 Sep 2011 01:15:48 +0200 (CEST)
Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182])
by smtp.ulyssis.org (Postfix) with ESMTP id 327CB1001C
for <bitcoin-development@lists.sourceforge.net>;
Sat, 24 Sep 2011 01:20:50 +0200 (CEST)
Received: by wop.ulyssis.org (Postfix, from userid 615)
id CE4E487C1AC; Sat, 24 Sep 2011 01:15:48 +0200 (CEST)
Date: Sat, 24 Sep 2011 01:15:48 +0200
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20110923231547.GA28700@ulyssis.org>
References: <20110923162102.GA13532@ulyssis.org> <4E7CC428.6020500@jerviss.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4E7CC428.6020500@jerviss.org>
X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1R7EyQ-0006Nk-2X
Subject: Re: [Bitcoin-development] Beyond IP transactions: towards a bitcoin
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, 23 Sep 2011 23:16:03 -0000
On Fri, Sep 23, 2011 at 12:38:48PM -0500, kjj wrote:
> Pieter Wuille wrote:
> >Hello everyone,
> >
> >here is an idea i've bean writing up: https://gist.github.com/1237788
> >
> >I hope it can start some discussion about moving away from static bitcoin addresses
> >as descriptions for transactions. I suppose it's a candidate for a BIP/BEPS/BFC/...,
> >but as things don't seem to have been decided completely about those, I put it in a
> >Gist.
> >
> >Please, comment.
> >
> This may just be me, but this really looks like an incredibly
> convoluted way to solve a bunch of problems that aren't really
> problems. The central issue that I see, is that you assume that
> there is no out of band channel, as if people were just sending
> transactions to addresses that came to them in a dream.
>
> I think that this assumption is only true when it doesn't matter.
> For example, I have a donation link in my sig on the forums. I
> don't care much who sends to it, or why, and I certainly don't need
> annotations or a refund address. The rest of the time, payments are
> sent to addresses that already have sufficient context.
Well, I agree, this scheme is not (primarily) intended to be a solution
for people who want to accept anonymous donations; static addresses
work very well for that application (unless you want unlinkability
between different payments).
Let me try to explain what I do want to accomplish.
What current addresses are, is a reference to a public key. The way they
are used is as a template for a transaction. If you do not need complex
transactions, this suffices indeed, given that all other negotiation about
the payment occurs out-of-band already (e.g., a webshop interface that
after clicking 'pay' gives you a freshly generated bitcoin address and
stores it so it can track your payment).
What I want to do is to standardize part of that out-of-band communication
inside a protocol. The first observation is that if you want a freshly
negotiated key each time, some form of bidirectional communication is
necessary anyway, and a static txout template does not suffice anymore.
If you're doing bidirectional communication, you are no longer limited
by the space constraints of something by-human-copy-pastable, and you can
just negotiate the txout directly, which transparently adds support for
anything that is possible through bitcoin scripts.
So far, the creation of transactions is "solved". However, by asking nodes
not to broadcast their transaction, but instead just send it back (we're
communicating with some other party already anyway, and this other party
is the one who cares about the tx being accepted), the receiver can track
it as well. Furthermore, by passing tags along, identification of
transactions becomes a lot easier. As a extra advantage, this makes the
requirements for a client easier as well (it doesn't need to be a p2p
node).
The third step is adding signatures to authenticate the whole process.
They are necessary to make sure the client is communicating with who he
thinks he is, but by using them for the submission of the transaction as
well, it gives the client a proof of payment acceptance too.
Summarized: addresses are a limited method for defining payments, and as
soon as you move to a protocol instead of a static template, a lot of
possibilities open up.
--
Pieter
|
