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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <shaker521@hushmail.com>) id 1UfDLn-000065-Ie
for bitcoin-development@lists.sourceforge.net;
Wed, 22 May 2013 18:01:23 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of hushmail.com
designates 65.39.178.235 as permitted sender)
client-ip=65.39.178.235; envelope-from=shaker521@hushmail.com;
helo=smtp5.hushmail.com;
Received: from smtp5a.hushmail.com ([65.39.178.235] helo=smtp5.hushmail.com)
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1UfDLl-0008JO-MN
for bitcoin-development@lists.sourceforge.net;
Wed, 22 May 2013 18:01:23 +0000
Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235])
by smtp5.hushmail.com (Postfix) with SMTP id 6BED0580B4
for <bitcoin-development@lists.sourceforge.net>;
Wed, 22 May 2013 18:01:15 +0000 (UTC)
Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80])
by smtp5.hushmail.com (Postfix) with ESMTP;
Wed, 22 May 2013 18:01:12 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
id D88AEE6736; Wed, 22 May 2013 18:01:11 +0000 (UTC)
MIME-Version: 1.0
Date: Wed, 22 May 2013 18:01:08 +0000
To: "Wladimir" <laanwj@gmail.com>
From: shaker521@hushmail.com
In-Reply-To: <CA+s+GJD2Ty-pUcAV1HsztHjrBqJXzN-Z9XL_ideUpmN02V=pCQ@mail.gmail.com>
References: <20130522032504.1C461E6718@smtp.hushmail.com>
<CA+s+GJD2Ty-pUcAV1HsztHjrBqJXzN-Z9XL_ideUpmN02V=pCQ@mail.gmail.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20130522180111.D88AEE6736@smtp.hushmail.com>
X-Spam-Score: -2.3 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [65.39.178.235 listed in list.dnswl.org]
-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
(shaker521[at]hushmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-1.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (shaker521[at]hushmail.com)
0.0 SPF_HELO_NEUTRAL SPF: HELO does not match SPF record (neutral)
X-Headers-End: 1UfDLl-0008JO-MN
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 0021 idea: sendmany
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: Wed, 22 May 2013 18:01:23 -0000
You can pull use cases out of thin air. Humble Bundle is a perfect example.
BIP 0001 instructed me to introduce the idea here before performing the labor of writing a new BIP. If others reply in support then the labor will be justified.
The intended purpose is to give users the simplest way to perform a transaction with multiple outputs. Ideal would be to provide a single URI (or QR code or what have you) that specifies all of the outputs (address:amount pairs) and minimizes opportunities for user error, e.g. by omitting or altering an output. I'll take you through the process that brought me to the solution below.
The main part of the current bitcoin URI scheme is a single bitcoinaddress. If the sendmany scheme left this foundation unchanged there will be difficulty with both semantics and backwards compatibility.
Contemplate some use cases for sendmany URIs. Are each of the outputs in a given transaction equally important? In other words, are all outputs necessary to fulfill the terms of the exchange between the parties? I would say so.
Not that the bitcoin client should forbid changing the outputs after processing the URI, but that it should reject the entire URI if the client does not support the multi-output syntax.
The discussion of backward compatibility in BIP 0021 recommends against reqparams being used in a mission-critical way while users upgrade their clients. A reqparams approach would permit the gravest possible error, i.e. an older client silently discarding all but the first address and allowing the user unwittingly to violate the terms of the exchange AND irreversibly send some BTC to a possibly adversarial party. We must guard against this potentially devastating failure mode.
After a study of pchar and other BNF terms (http://www.w3.org/TR/hdml20-8.html) I propose the following format with optional labels and amounts:
bitcoin:label/address:amount;label/address:amount?params
Before arriving at this format I tried and rejected these other output formats:
address/label:amount (ambiguous since ":" and amount are allowed in label's *pchar)
address:amount/label (less readable since the label is split from its referent)
The proposed format keeps labels and addresses together for human readability. The label delimiter "/" is a reserved character which eliminates ambiguous cases, making this format easy for bitcoin clients to parse.
Therefore I propose the following grammar:
bitcoinurn = "bitcoin:" outputs [ "?" bitcoinparams ]
outputs = output *[ ";" output ] | bitcoinaddress
output = [ label "/" ] bitcoinaddress [ ":" amount ]
bitcoinaddress = base58 *base58
amount = *digit [ "." *digit ]
bitcoinparams = bitcoinparam *[ "&" bitcoinparam ]
bitcoinparam = amountparam | labelparam | messageparam | otherparam | reqparam
amountparam = "amount=" amount
labelparam = "label=" label
label = *pchar
messageparam = "message=" *pchar
otherparam = pchar *pchar "=" *pchar
reqparam = "req-" pchar *pchar "=" *pchar
This may be added under "Simpler syntax":
bitcoin:<address>[:<amount>][/<label>][;<address>[:<amount>][/<label>]][?message=<message>]
As well as these examples:
bitcoin:Bitcoin+Foundation/1BTCorgHwCg6u2YSAWKgS17qUad6kHmtQW
bitcoin:eBook+Store/175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W:0.1;Bob+Author/1F4JfsqiDTG7vjnsz5daUrz2yexQGXB8uo:1.9?message=Purchased+eBook:+Bobgraphy
Brief testing with MultiBit shows that the URIs above are fully rejected by the client. This is the desired behavior for clients lacking support for multiple-output URIs. Thus we guard against the devastating failure mode outlined above.
Do you appreciate my work? Send a tip:
1F4JfsqiDTG7vjnsz5daUrz2yexQGXB8uo
|
