From: Andreas Schildbach <andreas@schildbach•de>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] BIP70/71 issue, RFD
Date: Sun, 26 Jan 2014 23:14:52 +0100 [thread overview]
Message-ID: <lc41cf$fdd$1@ger.gmane.org> (raw)
In-Reply-To: <CANEZrP0GLcSf0B-bW7jZq5m+wdkBLe_iEok-XCCOFASGAthtug@mail.gmail.com>
Just keep in mind that if it turns out we need to retrofit messages with
length prefixes I fear we will have to restart with new mime-types. The
nature of prefixes being always at the start means this rules out simply
incrementing a protocol version number.
Correcting myself:
> it might be a good idea to apply this to all messages if any.
Of course I only mean the "root" messages, namely PaymentRequest,
Payment, and PaymentACK. The embedded messages don't need length prefixes.
On 01/26/2014 11:00 PM, Mike Hearn wrote:
> I think for "binding" the payment protocol to those transports we should
> indeed use protobuf varint length prefixes. But it's unnecessary for all
> cases. Unless Gavin feels it'd be better to be consistent everywhere and
> is willing to change the spec and code - as far as I know though we're
> trying to ship 0.9rc1 soonish .....
>
>
> On Sun, Jan 26, 2014 at 10:32 PM, Andreas Schildbach
> <andreas@schildbach•de <mailto:andreas@schildbach•de>> wrote:
>
> Bluetooth, Wifi Direct, HTTP request/responses via broken proxies, smoke
> signals... basically anything that is a stream rather than a file.
>
> Right, NFC NDEF and QR codes are not affected, so we can skip the
> delimiter for these mediums.
>
>
> On 01/26/2014 10:24 PM, Mike Hearn wrote:
> > Which medium is this an issue for? As you note, for files and HTTP
> > responses it's not a problem in practice. i'd guess nor for NFC
> tags nor
> > QR codes.
> >
> >
> > On Sun, Jan 26, 2014 at 10:11 PM, Andreas Schildbach
> > <andreas@schildbach•de <mailto:andreas@schildbach•de>
> <mailto:andreas@schildbach•de <mailto:andreas@schildbach•de>>> wrote:
> >
> > I'm experimenting with BIP70/71 (payment protocol) usage in
> face to face
> > payments (more on that soon).
> >
> > I've excountered an issue with the protobuf format. Protobufs
> are not
> > self-delimiting. That means if you're reading from an undelimited
> > stream, you will read endlessly because you don't know how
> much to read.
> >
> > The current BIP70 implementations probably work because
> they're reading
> > either from a file or from an HTTP resource which sets the
> > Content-Length header. Trouble is the Content-Length header is
> optional,
> > and also there are many kinds of streams that don't have this
> built-in
> > delimiting mechanism.
> >
> > The Java protobuf API solves this by offering delimited I/O, like
> >
> > payment.writeDelimitedTo(os);
> >
> > This writes the size of the message as a varint before writing
> the data.
> > I don't know about protobuf implementations for other
> languages but I'd
> > expect them to offer something compatible.
> >
> > However, this leading varint is an incompatible change and
> would need to
> > be added to the spec.
> >
> > I specifically encountered this with PaymentMessage and
> PaymentACK, but
> > it might be a good idea to apply this to all messages if any.
> Open for
> > discussion.
> >
> >
> >
> ------------------------------------------------------------------------------
> > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> > Learn Why More Businesses Are Choosing CenturyLink Cloud For
> > Critical Workloads, Development Environments & Everything In
> Between.
> > Get a Quote or Start a Free Trial Today.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge.net
> <mailto:Bitcoin-development@lists•sourceforge.net>
> > <mailto:Bitcoin-development@lists•sourceforge.net
> <mailto:Bitcoin-development@lists•sourceforge.net>>
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> > Learn Why More Businesses Are Choosing CenturyLink Cloud For
> > Critical Workloads, Development Environments & Everything In Between.
> > Get a Quote or Start a Free Trial Today.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge.net
> <mailto:Bitcoin-development@lists•sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> <mailto:Bitcoin-development@lists•sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
next prev parent reply other threads:[~2014-01-26 22:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-26 21:11 Andreas Schildbach
2014-01-26 21:24 ` Mike Hearn
2014-01-26 21:32 ` Andreas Schildbach
2014-01-26 22:00 ` Mike Hearn
2014-01-26 22:14 ` Andreas Schildbach [this message]
2014-01-26 23:01 ` Mike Hearn
2014-01-27 2:05 ` Gavin
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='lc41cf$fdd$1@ger.gmane.org' \
--to=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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