From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Tgekr-0004gF-VP for bitcoin-development@lists.sourceforge.net; Thu, 06 Dec 2012 16:56:58 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.177 as permitted sender) client-ip=209.85.212.177; envelope-from=gavinandresen@gmail.com; helo=mail-wi0-f177.google.com; Received: from mail-wi0-f177.google.com ([209.85.212.177]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Tgekq-0006v3-3G for bitcoin-development@lists.sourceforge.net; Thu, 06 Dec 2012 16:56:57 +0000 Received: by mail-wi0-f177.google.com with SMTP id hm2so514561wib.10 for ; Thu, 06 Dec 2012 08:56:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.145.160 with SMTP id p32mr813469wej.44.1354813009967; Thu, 06 Dec 2012 08:56:49 -0800 (PST) Received: by 10.194.27.136 with HTTP; Thu, 6 Dec 2012 08:56:49 -0800 (PST) In-Reply-To: References: <20121128233619.GA6368@giles.gnomon.org.uk> <20121129170713.GD6368@giles.gnomon.org.uk> <20121129185330.GE6368@giles.gnomon.org.uk> <50C03BDA.6010600@petersson.at> Date: Thu, 6 Dec 2012 11:56:49 -0500 Message-ID: From: Gavin Andresen To: Bitcoin Dev Content-Type: multipart/alternative; boundary=0016e6d647e5323a6704d031fcba X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Tgekq-0006v3-3G Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 16:56:58 -0000 --0016e6d647e5323a6704d031fcba Content-Type: text/plain; charset=ISO-8859-1 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 --0016e6d647e5323a6704d031fcba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Spec updated yet again:

= Renamed to PaymentRequest/PaymentACK.

Added a '= ;network' field ("main" or "test") to PaymentReques= t 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 o= utputs.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 custo= mer 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 zer= o amounts shall be ignored).

-------------

RE: escrow/multisig:

<= /div>
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: =A0escrow service or participant send= s around an EscrowProposal, gets EscrowProposalACK's with public keys t= o use, then sends all participants an EscrowEstablished message with the fi= nal multisig script or address. =A0Escrow gets funded by any/all of the par= ticipants, and then gets spent using the SignedPaymentRequest/Payment/Payme= ntACK 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 copyin= g and pasting, that would be a terrible user experience; all of that commun= ication needs to happen automatically behind the scenes. Lets tackle that a= fter we've got the simpler customer-pays-merchant flow working nicely (= funded-escrow-pays-merchant is a subset of that, anyway).

--
--
Gavin Andresen

--0016e6d647e5323a6704d031fcba--