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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Tdf70-0000vN-7q for bitcoin-development@lists.sourceforge.net; Wed, 28 Nov 2012 10:43:26 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.175 as permitted sender) client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f175.google.com; Received: from mail-ob0-f175.google.com ([209.85.214.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Tdf6z-00044b-HF for bitcoin-development@lists.sourceforge.net; Wed, 28 Nov 2012 10:43:26 +0000 Received: by mail-ob0-f175.google.com with SMTP id vb8so12399261obc.34 for ; Wed, 28 Nov 2012 02:43:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.156.99 with SMTP id wd3mr2625339obb.15.1354099400044; Wed, 28 Nov 2012 02:43:20 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.128.139 with HTTP; Wed, 28 Nov 2012 02:43:19 -0800 (PST) In-Reply-To: References: <201211271703.39282.andyparkins@gmail.com> <201211271726.56370.andyparkins@gmail.com> Date: Wed, 28 Nov 2012 11:43:19 +0100 X-Google-Sender-Auth: HTm2NPr8x_RwBJ-OnEPMUZFEjf0 Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.4 (-) 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 0.1 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Tdf6z-00044b-HF 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: Wed, 28 Nov 2012 10:43:26 -0000 The current spec is ambiguous in the case of what to do if the invoice contains one output of a fixed amount and one or more outputs of an unspecified amount. Should the user be prompted once per output? That seems suboptimal. Prompted once for a value that's then randomly distributed between all open-value outputs? It seems this ability of the protocol is somewhat more complex than it appears. The ability to have open outputs is nice for tips though. You could consider moving pki_type and pki_data into a separate message and making both fields required, then making the pki message optional. Otherwise you can have pki_type set but no data or vice-versa. It doesn't make much difference in the end, just slightly improves the automatic sanity checks produced by the proto compiler. w.r.t SIGHASH_ANYONECANPAY. I think it's best not to use this routinely as it relaxes the signature checks in ways that may open non-obvious holes when combined with other features. I thought we pretty much had consensus on recursively calculating fees including dependents in the memory pool? Peter is correct that there are a few degrees of freedom in protobuf serialization, though far fewer than with JSON. I'd like to think upstream would be open to resolving these ambiguities. Re-serialization of an Invoice message in the Payment message is a potential source of mistakes. There's no need to ever concatenate these messages and alternative implementations that don't order serialized fields by tag number are missing an important optimization, so they could be fixed. The main issue is treatment of unknown fields. If/when the Invoice message is extended with other fields that are round-tripped through an old client, the data may get lost. JSON doesn't help resolve that either, of course. There are a few solutions: 1) Change the type of the Invoice field in Payment to be "bytes" and set it to be the hash of the originally received binary Invoice message. Downside, requires merchants to track all outstanding invoices. 2) Ask protobufs upstream to modify the spec/implementations so ordering of unknown fields is specified. The Python implementation could be extended to support them so Python implementors don't end up with accidental message downgrades. 3) Language of the spec could be changed to explicitly state that the received Invoice may not be binary-identical to the one that was sent, in the case of a client that incorrectly downgrades the message. Thus you'd be expected to check what the Invoice was using merchant_data which is opaque and could just be, eg, a database key on your own end. 4) Instead of submitting the entire Invoice back to the merchant, just the merchant_data could be in the Payment message. Of the four options I prefer the last. What is the use case for resubmitting the entire invoice anyway? Even if protobufs are improved so handling of round-tripping new messages through old [Python] clients is more rigorous, some implementors will probably convert the protobuf objects into some internal forms for whatever reason (or serialize them to a database, etc) and they're very likely to mess up the handling of unknown fields when they do it.