Spec updated yet again:
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