Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

[Gavin Andresen <gavinandresen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]

Spec updated yet again:
  https://gist.github.com/4120476

Renamed to PaymentRequest/PaymentACK.

Added a 'network' field ("main" or "test") to PaymentRequest so testnet and
main network (and alterna-chain) payment requests don't get confused.

Updated description of PaymentRequest.outputs:

outputs: one or more outputs where Bitcoins are to be sent. If the sum of
outputs.amount is zero, the customer will be asked how much to pay, and the
bitcoin client may choose any or all of the Outputs (if there are more than
one) for payment. If the sum of outputs.amount is non-zero, then the
customer will be asked to pay the sum, and the payment shall be split among
the Outputs with non-zero amounts (if there are more than one; Outputs with
zero amounts shall be ignored).
-------------

RE: escrow/multisig:

Setting up a multi-person escrow will, I think, need it's own set of
messages. I think we should leave that for a future spec.

Thumbnail sketch:  escrow service or participant sends around an
EscrowProposal, gets EscrowProposalACK's with public keys to use, then
sends all participants an EscrowEstablished message with the final multisig
script or address.  Escrow gets funded by any/all of the participants, and
then gets spent using the SignedPaymentRequest/Payment/PaymentACK
protocol-- participants will pass around a SignedPaymentRequest and a
partially-signed Payment message for all to approve.

When I say "pass around" I'm not thinking of users copying and pasting,
that would be a terrible user experience; all of that communication needs
to happen automatically behind the scenes. Lets tackle that after we've got
the simpler customer-pays-merchant flow working nicely
(funded-escrow-pays-merchant is a subset of that, anyway).

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 2285 bytes --]