From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Tgffs-0001ya-RM for bitcoin-development@lists.sourceforge.net; Thu, 06 Dec 2012 17:55:56 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.47 as permitted sender) client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f47.google.com; Received: from mail-oa0-f47.google.com ([209.85.219.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Tgffr-0001lk-W3 for bitcoin-development@lists.sourceforge.net; Thu, 06 Dec 2012 17:55:52 +0000 Received: by mail-oa0-f47.google.com with SMTP id h1so7038612oag.34 for ; Thu, 06 Dec 2012 09:55:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.172.164 with SMTP id bd4mr1025059oec.51.1354816546635; Thu, 06 Dec 2012 09:55:46 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.128.139 with HTTP; Thu, 6 Dec 2012 09:55:46 -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 18:55:46 +0100 X-Google-Sender-Auth: SfPgBITUEyA_KxjzpD2so-i7_io Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.5 (-) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1Tgffr-0001lk-W3 Cc: Bitcoin Dev 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 17:55:57 -0000 Re: the newest spec. Rather than make the signature over the "concatenation of", why not just make it a signature over the serialized protobuf minus the signature field (as I did in my demo code). Otherwise it seems like we'd need more code than really necessary. We can state explicitly tags must be ordered if you want, even though all implementations should do that already. > 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. Yeah, that sounds reasonable. Not that we should really design it now, but let's use the term "mediation" rather than "escrow", which has connotations of depositing funds with the escrow service. I think it's best to see the existing payment messages as structures that'll get filled out with more features over time. So rather than have a separate EscrowProposal message, you would integrate it with payment requests. Older clients that don't understand mediation would just ignore the extra data they don't recognize. message PaymentRequest { .... // One per mediator acceptable to the seller. repeated MediationProposal mediation_data = 10; } message MediationProposal { required SignedMediatorIdentity identity = 2; // Opaque bytes that the mediator can be asked to turn into a human readable description // of how disputes will be mediated. The merchant sets this to describe whatever policy it // is willing to go along with, so policies may be arbitrarily complicated. required bytes policy = 3; } message SignedMediatorIdentity { required MediatorIdentity identity = 1; // If the identity data is signed ... optional string pki_type = 2; optional bytes pki_data = 3; optional bytes pki_signature = 4; } message MediatorIdentity { // Name of the mediator to be displayed to the user. required string friendly_name = 1; // PNG image that can be used to represent the mediator to the user. optional bytes logo = 2; // Some text shown to the user under the name explaining the mediators policies, why they should be chosen, etc. optional string blurb = 3; // An HTTP URL where a mediator can be reached to do things like prove ownership of pubkeys, initiate the protocols, etc. required string contact_url = 4; } ... etc .... So the user experience would be that when a payment request is received: - older clients ignore the mediation_data field and do a direct payment as normal - newer clients ask the user to pick a mediator (if they want to) and if mediation is requested, the PaymentRequest is then discarded and the next step of the mediation protocol begins. The old request has to be discarded because the outputs would have been written on the assumption of no mediation being in use (for backwards compatibility). Anyway, though I'm awfully guilty, let's not get off track. Just that this is how I imagined new payment features being done - as new extensions to the payment protocol, which would be a living document amended by BIPs.