From: Mike Hearn <mike@plan99•net>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Date: Wed, 28 Nov 2012 11:43:19 +0100 [thread overview]
Message-ID: <CANEZrP1wgMgo8N5f97KF6zNaPzoYVDU9Q=YABkz=jvTpM10jKQ@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T13C4eFC9caTmCRm==YAESknX8xhhumb7Mg0mZNdzEosQ@mail.gmail.com>
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.
next prev parent reply other threads:[~2012-11-28 10:43 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-26 22:37 Gavin Andresen
2012-11-26 23:02 ` Mike Hearn
2012-11-26 23:13 ` Luke-Jr
2012-11-26 23:16 ` Mike Hearn
2012-11-26 23:19 ` Luke-Jr
2012-11-26 23:27 ` Mike Hearn
2012-11-26 23:32 ` Gregory Maxwell
2012-11-26 23:44 ` Luke-Jr
2012-11-27 0:16 ` Gregory Maxwell
2012-11-27 0:26 ` Mike Hearn
2012-11-27 0:45 ` Rick Wesson
2012-11-27 1:09 ` Gavin
2012-11-27 8:44 ` Mike Hearn
2012-11-27 0:44 ` Luke-Jr
2012-11-26 23:38 ` Rick Wesson
2012-11-26 23:52 ` Jeff Garzik
2012-11-27 0:02 ` Rick Wesson
2012-11-27 0:31 ` Luke-Jr
2012-11-27 0:37 ` Rick Wesson
2012-11-27 2:16 ` Walter Stanish
2012-11-27 2:47 ` Gregory Maxwell
2012-11-27 3:16 ` Walter Stanish
2012-11-27 3:29 ` Rick Wesson
2012-11-27 3:31 ` Walter Stanish
2012-11-27 3:54 ` Rick Wesson
2012-11-27 4:17 ` Walter Stanish
2012-11-27 8:43 ` Michael Gronager
2012-11-27 10:23 ` Mike Hearn
2012-11-27 10:42 ` Michael Gronager
2012-11-27 11:36 ` Pieter Wuille
2012-11-27 11:46 ` Michael Gronager
2012-11-27 12:03 ` Mike Hearn
2012-11-27 12:39 ` Michael Gronager
2012-11-27 14:05 ` Gavin Andresen
2012-11-27 14:26 ` Gavin Andresen
2012-11-28 13:55 ` Walter Stanish
2012-11-27 17:03 ` Andy Parkins
2012-11-27 17:14 ` Mike Hearn
2012-11-27 17:26 ` Andy Parkins
2012-11-27 18:16 ` Mike Hearn
2012-11-27 21:39 ` Gavin Andresen
2012-11-28 10:43 ` Mike Hearn [this message]
2012-11-28 12:57 ` Peter Todd
2012-11-28 14:09 ` Gavin Andresen
2012-11-28 8:33 ` Peter Todd
2012-11-28 23:36 ` Roy Badami
2012-11-29 0:30 ` Watson Ladd
2012-11-29 8:16 ` slush
2012-11-29 16:11 ` Gavin Andresen
2012-11-29 17:07 ` Roy Badami
2012-11-29 17:30 ` Gavin Andresen
2012-11-29 17:31 ` Mike Hearn
2012-11-29 18:53 ` Roy Badami
2012-12-01 19:25 ` Gavin Andresen
2012-12-03 19:35 ` Mike Koss
2012-12-03 20:59 ` Gavin Andresen
2012-12-03 21:28 ` Mike Hearn
2012-12-03 22:26 ` Roy Badami
2012-12-03 22:34 ` Jeff Garzik
2012-12-03 22:48 ` Roy Badami
2012-12-16 21:15 ` Melvin Carvalho
2012-12-17 2:18 ` Jeff Garzik
2012-12-17 8:24 ` Melvin Carvalho
2012-12-17 9:19 ` Mike Hearn
2012-12-17 9:31 ` Gary Rowe
2012-12-17 11:23 ` Melvin Carvalho
2012-12-17 17:57 ` Gavin Andresen
2012-12-20 16:53 ` Stephen Pair
2012-12-20 17:43 ` Mike Hearn
2012-12-20 19:32 ` Stephen Pair
2012-12-21 17:05 ` Stephen Pair
2012-12-24 0:38 ` Elden Tyrell
2012-12-04 17:06 ` Mike Hearn
2012-12-05 19:34 ` Gavin Andresen
2012-12-06 6:31 ` Andreas Petersson
2012-12-06 8:53 ` Mike Hearn
2012-12-06 16:56 ` Gavin Andresen
2012-12-06 17:55 ` Mike Hearn
2012-12-06 19:13 ` Gavin Andresen
2012-12-07 10:45 ` Mike Hearn
2012-12-07 11:01 ` Mike Hearn
2012-12-07 16:19 ` Gavin Andresen
2012-12-07 16:27 ` Mike Hearn
2012-12-06 18:13 ` Alan Reiner
[not found] ` <CALf2ePx5jS@mail.gmail.com>
2014-09-17 19:28 ` Vezalke
2012-12-03 21:42 ` Gregory Maxwell
2012-12-23 2:33 ` Mark Friedenbach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP1wgMgo8N5f97KF6zNaPzoYVDU9Q=YABkz=jvTpM10jKQ@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox