BIP 21 (modification BIP 20)

Hi all,

Speaking on behalf of the MultiBit team (Jim's currently on holiday), we will not be supporting Tonal Bitcoins anytime soon. Therefore we back the BIP 21 proposal.

At present MultiBit does not support the "message" or "send" fields but we would be happy to add this functionality as required.

Regarding the idea of a signed URI, it is appealing, however, it may not work. If I understand it correctly, the main idea appears to be to protect a URI from malicious replacement (at MultiBit we were concerned that a Bitcoin "swatch" would be subjected to the same attack vector and we came up with the term "swatch swabbing"). If a Bitcoin URI is served up from a trusted source (e.g. a merchant site over HTTPS) then there is no need for signing. It should be assumed that the merchant will offer a clean room payment area so that no untrusted JavaScript will creep into the final page and wreak havoc.

It would seem that in any situation where the attacker has complete control over the content of the URI they will be able to successfully swab it to match their own fraudulent address. Imagine attempting to protect a QR code posted against a pole attempting to get BTC donations for a charity. How long before that was replaced by a different version operated by the thieves with good signatures all round?

Of course, I may have misunderstood so I would welcome further discussion.

One field that the MultiBit team would like to add to the BIP 21 proposal is "expires" which would contain an ISO8601 formatted date/time in UTC (e.g. "2000-01-01T23:59:59Z"). This would allow merchants to issue Bitcoin URIs that would expose them to a currency/inventory risk for a defined period of time.

Kind regards,

Gary Rowe

PS First post to this list

On Monday, January 30, 2012 1:50:03 PM Gary Rowe wrote:

> Speaking on behalf of the MultiBit team (Jim's currently on holiday), we
> will not be supporting Tonal Bitcoins anytime soon. Therefore we back the
> BIP 21 proposal.

It is not correct to imply that BIP 20 requires Tonal Bitcoin support. In fact, the exact opposite is true; it states that even if one unit (eg, TBC) would be a more rational way to display a specified amount, clients should still interpret it in the way that is deemed to be most intuitive to the user (eg, BTC).

Having closely read the BIP20 proposal, I can see your point. As I see it, BIP 20 vs BIP 21 is about standardising on a representation of the "amount" field. BIP 20 proposes that "amount" can contain alternative representations, clearly defined, whereas BIP 21 requires the use of a single representation in decimal notation.

In my view, BIP 21 still wins since it reduces complexity for the end client both at the human and machine level.

On 30 January 2012 18:56, Luke-Jr <luke@dashjr•org> wrote:

> On Monday, January 30, 2012 1:50:03 PM Gary Rowe wrote:
> > Speaking on behalf of the MultiBit team (Jim's currently on holiday), we
> > will not be supporting Tonal Bitcoins anytime soon. Therefore we back the
> > BIP 21 proposal.
>
> It is not correct to imply that BIP 20 requires Tonal Bitcoin support.
> In fact, the exact opposite is true; it states that even if one unit (eg,
> TBC)
> would be a more rational way to display a specified amount, clients should
> still interpret it in the way that is deemed to be most intuitive to the
> user
> (eg, BTC).
>

On Monday, January 30, 2012 2:13:52 PM Gary Rowe wrote:

> Having closely read the BIP20 proposal, I can see your point. As I see it,
> BIP 20 vs BIP 21 is about standardising on a representation of the "amount"
> field. BIP 20 proposes that "amount" can contain alternative
> representations, clearly defined, whereas BIP 21 requires the use of a
> single representation in decimal notation.
>
> In my view, BIP 21 still wins since it reduces complexity for the end
> client both at the human and machine level.

If the goal is to reduce complexity, strtol-compatible amount is the answer ;)

> Regarding the idea of a signed URI, it is appealing, however, it may not
> work. If I understand it correctly, the main idea appears to be to protect
> a URI from malicious replacement

No. The main idea is to protect the consumer against a malicious seller pretending that he has not been paid. Please read the forum.

> If a Bitcoin URI is served up from a
> trusted source (e.g. a merchant site over HTTPS) then there is no need for
> signing. It should be assumed that the merchant will offer a clean room
> payment area so that no untrusted JavaScript will creep into the final
> page
> and wreak havoc.
>
> It would seem that in any situation where the attacker has complete
> control
> over the content of the URI they will be able to successfully swab it to
> match their own fraudulent address. Imagine attempting to protect a QR
> code
> posted against a pole attempting to get BTC donations for a charity. How
> long before that was replaced by a different version operated by the
> thieves with good signatures all round?
>
> Of course, I may have misunderstood so I would welcome further discussion.

The bitcoin address that is used to sign URIs will establish the online reputation of the merchant. If a merchant has received a payment and pretends not to have received it, the signed URI will prove him wrong.

In principle it would be possible to use HTTPS signatures for that purpose, but this is not really the way HTTPS is supposed to work, and it has disadvantages: - HTTPS is not always available; there are other communication channels. - A website, even a single page, may contain URIs posted by various merchants; we need to distinguish the identity of the merchant from the identity of the website. - with signed URIs, a Bitcoin client can easily keep track of the signatures for all the payments it made. if we used the HTTPS signature of the webpage as receipts, then users would need to save them manually. To my knowledge, nobody does that.

> One field that the MultiBit team would like to add to the BIP 21 proposal
> is "expires" which would contain an ISO8601 formatted date/time in UTC
> (e.g. "2000-01-01T23:59:59Z"). This would allow merchants to issue Bitcoin
> URIs that would expose them to a currency/inventory risk for a defined
> period of time.

yes, that too. see my proposal here: https://bitcointalk.org/index.php?topic=60828.0;topicseen

RE: BIP 21 versus BIP 20: I like BIP 21; simpler is better.

RE: signing and dating URIs: good ideas. I think we should agree that there is consensus around BIP 21 and then after there is some experience with signing/dating URIs you should write follow-up BIPs .

On 1/02/2012 00:12, Gavin Andresen wrote:

> RE: BIP 21 versus BIP 20:  I like BIP 21; simpler is better.
>
> RE: signing and dating URIs:  good ideas.  I think we should agree
> that there is consensus around BIP 21 and then after there is some
> experience with signing/dating URIs you should write follow-up BIPs .
>

If we had a self signed URI, we could just pay directly to the public key (or calculate the bitcoin address from it). It would no longer require a bitcoin address in the URI.