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 

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 ( 
I propose the following format with optional labels and amounts:


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 
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":


As well as these examples:



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:

Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt!
Bitcoin-development mailing list

Reply via email to