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
|
Return-Path: <tobypadilla@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 17767A16
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 02:10:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com
[209.85.213.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED646117
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 02:10:23 +0000 (UTC)
Received: by vkca188 with SMTP id a188so3722622vkc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 07 Dec 2015 18:10:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=gzmrBtNAki4xQGVnanAFC+x5/+FngL1zn/RLU56D7+Y=;
b=TgfUM5GJ6r9ZLHzjb4YPnFL1BlVEO/xKYi/zMrKeJVtYLsgJFh0yKYqsQQh6B8s5Cr
J3sicz6sFVh2wDXP9RPGA+4fo8Gq6VqcWQ8Ly7TQsDh8C3IA0LYQ4w1+fdm4T/0GVhEJ
TmSdSqh+wp/jNL5upWiHLyt/XNLOkgJbYp4+gRI4eIJM5HGsgF5lwh4jhhE3kSQzjEM0
0d4QKSYnKIGp7mI+z0GLN85wHUnSf4tccNyJSqoovkRjcNE1/wnN1ob+QiOyZ2az/qYa
oSoYkW8zfVoG/wj8JQ9JAlVMLGjOvANIx1ot7Wvxp3vwqT7PHmcIVF1/YE6YVh2rao/w
spqw==
MIME-Version: 1.0
X-Received: by 10.31.49.147 with SMTP id x141mr972884vkx.1.1449540622873; Mon,
07 Dec 2015 18:10:22 -0800 (PST)
Received: by 10.31.96.8 with HTTP; Mon, 7 Dec 2015 18:10:22 -0800 (PST)
Date: Mon, 7 Dec 2015 18:10:22 -0800
Message-ID: <CAGcHOzy--AmRhBYveFF4Aq1dr=2oB4xuHVZPQnQV4kEXroLWXA@mail.gmail.com>
From: Toby Padilla <tobypadilla@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11438346e9fa2d05265979eb
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 08 Dec 2015 11:28:20 +0000
Subject: [bitcoin-dev] Key.run: BIP-70 Payments and OP_RETURN
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2015 02:10:25 -0000
--001a11438346e9fa2d05265979eb
Content-Type: text/plain; charset=UTF-8
Hi all. I've been working on a new publication platform based on Bitcoin
called key.run: http://key.run
The high level overview is that key.run stores BitTorrent info hashes
(magnet links) in the blockchain by sending transactions to a "namespace"
Bitcoin address. Using SPV, I reconstitute the key.run db from the
blockchain. This is meant to be an open source and distributed system so
anyone can run the key.run server (and change namespace keys). More info
here: https://git.playgrub.com/toby/keyrun
Now to my issue...
One of the main use cases I wanted to support was people using their
*existing* Bitcoin wallet to encode the key.run transactions on the
blockchain. Practically speaking this meant building the transactions with
the proper OP_RETURN value server-side then passing them to the end user's
wallet via BIP-70. I have this working with Bitcoin Core (there are issues
with other wallets I've tested with BIP-70).
The problem I'm having is that Bitcoin Core will not allow BIP-70
PaymentDetails to contain outputs with zero value. As stated in
https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki:
"if there are more than one; Outputs with zero amounts shall be ignored"
Bitcoin Core doesn't seem to ignore the output though, it rejects the
transaction and doesn't allow the user to submit it. The key.run
transactions currently work by giving the OP_RETURN outputs a non-zero >
dust value. This value is presumably lost forever.
I think ideally OP_RETURN outputs with zero value WOULD be allowed since
they are valid transactions. Allowing OP_RETURN outputs to be constructed
with BIP-70 Payments is also the only way I can think of to extend the
functionality of existing wallets.
I would love to get feedback on if there is an alternative way to do what I
propose or ideally if BIP-70 could be tweaked to allow OP_RETURN outputs
with zero value.
I'd also love feedback on key.run but this probably isn't the best venue
for that. I've setup #keyrun on Freenode if anyone is interested in
discussing the project.
Regards,
Toby
--
http://twitter.com/toby
--001a11438346e9fa2d05265979eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi all. I've been working on a new publication pl=
atform based on Bitcoin called key.run: <a href=3D"http://key.run">http://k=
ey.run</a></div><div><br></div><div>The high level overview is that key.run=
stores BitTorrent info hashes (magnet links) in the blockchain by sending =
transactions to a "namespace" Bitcoin address. Using SPV, I recon=
stitute the key.run db from the blockchain. This is meant to be an open sou=
rce and distributed system so anyone can run the key.run server (and change=
namespace keys). More info here: <a href=3D"https://git.playgrub.com/toby/=
keyrun">https://git.playgrub.com/toby/keyrun</a></div><div><br></div><div>N=
ow to my issue...</div><div><br></div><div>One of the main use cases I want=
ed to support was people using their *existing* Bitcoin wallet to encode th=
e key.run transactions on the blockchain. Practically speaking this meant b=
uilding the transactions with the proper OP_RETURN value server-side then p=
assing them to the end user's wallet via BIP-70. I have this working wi=
th Bitcoin Core (there are issues with other wallets I've tested with B=
IP-70).</div><div><br></div><div>The problem I'm having is that Bitcoin=
Core will not allow BIP-70 PaymentDetails to contain outputs with zero val=
ue. As stated in <a href=3D"https://github.com/bitcoin/bips/blob/master/bip=
-0070.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-0070.media=
wiki</a>:</div><div><br></div><div>"if there are more than one; Output=
s with zero amounts shall be ignored"</div><div><br></div><div>Bitcoin=
Core doesn't seem to ignore the output though, it rejects the transact=
ion and doesn't allow the user to submit it. The key.run transactions c=
urrently work by giving the OP_RETURN outputs a non-zero > dust value. T=
his value is presumably lost forever.</div><div><br></div><div>I think idea=
lly OP_RETURN outputs with zero value WOULD be allowed since they are valid=
transactions. Allowing OP_RETURN outputs to be constructed with BIP-70 Pay=
ments is also the only way I can think of to extend the functionality of ex=
isting wallets.</div><div><br></div><div>I would love to get feedback on if=
there is an alternative way to do what I propose or ideally if BIP-70 coul=
d be tweaked to allow OP_RETURN outputs with zero value.</div><div><br></di=
v><div>I'd also love feedback on key.run but this probably isn't th=
e best venue for that. I've setup #keyrun on Freenode if anyone is inte=
rested in discussing the project.</div><div><br></div><div>Regards,</div><d=
iv>Toby</div><div><br></div><div>--</div><div><a href=3D"http://twitter.com=
/toby">http://twitter.com/toby</a></div></div>
--001a11438346e9fa2d05265979eb--
|
