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; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP1iS4_MFi2=3Qa4_rSGXe5EK8B0wWy43hXJOeKp-SfpPg@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
	<20121128233619.GA6368@giles.gnomon.org.uk>
	<CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com>
	<20121129170713.GD6368@giles.gnomon.org.uk>
	<CANEZrP233CytLs3PWBQ1TyuBTMv4sLGJkEMeGWYq5xRi+iLKew@mail.gmail.com>
	<20121129185330.GE6368@giles.gnomon.org.uk>
	<CABsx9T35qD_xJEVw002eAhJ1kr6x5aMU7RpD+U84XEOZXmXcYw@mail.gmail.com>
	<CANEZrP2riPBViBqAOWfY9uSQwoEm=gN108JU988XvouMbai1Ug@mail.gmail.com>
	<CABsx9T023aw11cq6iiZhT3cgfNYJXr=qG40Fzc7rYZOimJ=62w@mail.gmail.com>
	<50C03BDA.6010600@petersson.at>
	<CANEZrP1iS4_MFi2=3Qa4_rSGXe5EK8B0wWy43hXJOeKp-SfpPg@mail.gmail.com>
Date: Thu, 6 Dec 2012 11:56:49 -0500
Message-ID: <CABsx9T2UBQXzDPj0zHio+9i0uKNqiPYwL=kYgWKSirXRvckQ4g@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=0016e6d647e5323a6704d031fcba
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
	Invoices/Payments/Receipts
Precedence: list

--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

<div>Spec updated yet again:</div><div>=A0=A0<a href=3D"https://gist.github=
.com/4120476">https://gist.github.com/4120476</a></div><div><br></div><div>=
Renamed to PaymentRequest/PaymentACK.</div><div><br></div><div>Added a &#39=
;network&#39; field (&quot;main&quot; or &quot;test&quot;) to PaymentReques=
t so testnet and main network (and alterna-chain) payment requests don&#39;=
t get confused.</div>
<div><br></div><div>Updated description of PaymentRequest.outputs:</div><di=
v><br></div><div><p style=3D"margin:15px 0px;padding:0px;line-height:19.600=
000381469727px;font-family:helvetica,arial,freesans,clean,sans-serif;font-s=
ize:14px;background-color:rgb(255,255,255)">
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).</p>
</div><div>-------------</div><div><br></div>RE: escrow/multisig:<div><br><=
/div><div>Setting up a multi-person escrow will, I think, need it&#39;s own=
 set of messages. I think we should leave that for a future spec.</div>
<div><br></div><div>Thumbnail sketch: =A0escrow service or participant send=
s around an EscrowProposal, gets EscrowProposalACK&#39;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.<br>
<br>When I say &quot;pass around&quot; I&#39;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&#39;ve got the simpler customer-pays-merchant flow working nicely (=
funded-escrow-pays-merchant is a subset of that, anyway).<br>
<br>-- <br>--<br>Gavin Andresen<br><br>
</div>

--0016e6d647e5323a6704d031fcba--