Re: invoice and payments spec for bitcoin

On 12/02/12 09:11, Melvin Carvalho wrote:
> https://gist.github.com/4120476

Thanks for the link Melvin - interesting stuff.

My first reaction is that creating an invoice and payments
specification, but providing a binary protocol for the specification, is
not as flexible as an invoicing and payments protocol should be. For
example:

message PaymentRequest {
    optional string network = 1 [default = "main"];
    repeated Output outputs = 2;
    required uint64 time = 3;
    optional uint64 expires = 4;
    optional bool single_use = 5 [default = true];
    optional string memo = 6;
    optional string receipt_url = 7;
    optional bytes merchant_data = 8;
}

Problem #1: Fixed, binary protocol.
Problem #2: No extensibility, AFAICT.

I guess one could dump whatever data they wanted into the merchant_data
and memo fields, but that just means that you don't have a truly
interoperable standard at that point. There is no way to do discovery on
the merchant_data if you wanted to do so. From an extensibility and
interoperability perspective, what you put into the merchant_data and
memo fields matters. This is one of the reasons we decided to use Linked
Data for specifying that information and chose to use JSON-LD to express
the information.

The other major issue I think with any payment request / invoicing
specification is that it's tied to the currency, which seems like a bad
idea. Specifically, this seems wrong:

amount: Number of satoshis (0.00000001 BTC) to be paid.

A payment request / invoicing specification that hopes to gain
widespread acceptance should be currency agnostic.

>From a security standpoint, I don't see any sort of analysis on forgery
or replay attacks. I don't see anything on nonces or values that would
prevent a replay attack from occurring. I don't have a very good grasp
on when things are signed in a Bitcoin network, but if the
PaymentRequest is not signed, then all sorts of bad things can happen
from a forgery perspective (adding your bitcoin account on to an
existing merchant so that you siphon off monthly payments, for instance).

There also doesn't seem like there is a mechanism for identifying
identities on the network, so I'm wondering how the trust layer works
for this stuff. How do you trust the person that has sent you an
invoice? Is there a way to tell if they are trustworthy?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: HTML5 and RDFa 1.1
http://manu.sporny.org/2012/html5-and-rdfa/

Received on Wednesday, 19 December 2012 18:39:22 UTC