I hope that this input does not come too late; I haven't had time to review
the proposal until now.
For alt-chains that have time-varying value (Freicoin[1], currently), it is
necessary in some applications to include a "reference height" in the
invoice. Since the bitcoin protocol does not assume a universally
agreed-upon time source, Freicoin (and presumably other
yet-to-be-implemented time-varying chains) uses blocktime as the clock for
time-value calculations: outputs lose 2**-20 of their value with each
passing block. The reference height for an invoice is the blocktime at
which amount values are specified and the reference point for time-varying
calculations. As a concrete example, an invoice for payment of 50 frc today
could be satisfied by 49.99313402 frc tomorrow.
To implement this, we would require an optional "uint64 refheight" field in
the invoice structure. "refheight" or "nRefHeight" is what we call this
value internally, but "blocktime" or "blockheight" would work as well.
Github is currently down, so I apologize if a suitable field has already
been added.
Cheers,
Mark Friedenbach
[1] http://freico.in/ "Freicoin: a P2P digital currency delivering freedom
from usury."
On Mon, Nov 26, 2012 at 2:37 PM, Gavin Andresen wrote:
> This is the next big "lets all agree to do things the same way" thing
> I think we should tackle. I'm particularly looking for feedback from
> other bitcoin client developers, even if it is just a quick "looks
> reasonable, if everybody else is going to do it then I will
> (eventually) too..."
>
> Thanks to Pieter Wuille and Mike Hearn for lots of feedback and
> suggestions and brainstorming.
>
> This document is online at https://gist.github.com/4120476
>
> If you respond to this message, please be considerate of people who
> subscribe to the digest version of this mailing list and trim your
> response.
>
>
> Invoices, Payments and Receipts for Bitcoin Transactions
>
>
> This document proposes protocol buffer-based formats for signed,
> authenticated "invoices" and "receipts" -- requests for payment, and
> proof-of-payment.
>
> Separate documents propose an extension to the Bitcoin URI syntax and
> new MIME types to support them.
>
> Motivation
> ==
>
> The idea of a "payment protocol" to improve on Bitcoin addresses has
> been around for over a year. Users have been asking for some features
> in this proposal (like the ability to provide a refund address so
> overpayments or refunds can be returned to customers without the need
> to ask them for their address) for two or three years, and have
> started to work around shortcomings in the Bitcoin payment process
> with creative (but inefficient) uses of transactions.
>
> The key features of this proposal are:
>
> + Requests for payment (Invoices) are tied to authenticated identities
> using the only widely-deployed identity authentication system we have
> right now (X.509 certificates signed by root certificate authorities)
> + Invoices include a user-friendly description of what the payment is for
> + Payments include where refunds should be sent
> + At the end of the payment process, the customer holds a
> cryptographically signed Receipt that can be used as proof-of-payment
> if there is any dispute with the merchant.
>
>
> Specification
> =
>
> Invoice/SignedInvoice
> -
>
> An Invoice is a request for payment from a merchant to a customer:
>
> ::
>
> message Output {
> optional uint64 amount = 1;
> required bytes script = 2;
> }
>
> amount: Number of satoshis (0.0001 BTC) to be paid. If not given
> or zero, then the customer will be asked how much to pay.
>
> script: a "TxOut" script to which the customer should direct payment.
> This will normally be one of the standard Bitcoin transaction script
> (e.g. pubkey OP_CHECKSIG).
>
> ::
>
> message Invoice {
> repeated bytes x509chain = 1;
> 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 receiptURI = 7;
> optional bytes merchant_data = 8;
> }
>
> outputs: one or more outputs where Bitcoins are to be sent.
>
> x509chain: one or more DER-encoded X.509 certificates that identifies
> the merchant. See the "Certificates" section below for details.
>
> time: Unix timestamp (seconds since 1-Jan-1970) when the Invoice was
> created.
>
> expires: Unix timestamp after which the Invoice should be considered
> invalid. If not given, the Invoice may be re-used until the earliest
> certificate expiration date in the X509chain.
>
> single_use: If true, this Invoice should be used for only one payment.
> If false, it may be added to the user's address book and used
> repeatedly until it expires (e.g. for donations or a recurring
> payment).
>
> memo: UTF-
