From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W7XC6-0002GQ-3a for bitcoin-development@lists.sourceforge.net; Sun, 26 Jan 2014 21:24:42 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.41 as permitted sender) client-ip=209.85.219.41; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f41.google.com; Received: from mail-oa0-f41.google.com ([209.85.219.41]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W7XC4-0007XS-QZ for bitcoin-development@lists.sourceforge.net; Sun, 26 Jan 2014 21:24:42 +0000 Received: by mail-oa0-f41.google.com with SMTP id j17so5989323oag.0 for ; Sun, 26 Jan 2014 13:24:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.233.228 with SMTP id tz4mr241545obc.56.1390771475417; Sun, 26 Jan 2014 13:24:35 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.99.112 with HTTP; Sun, 26 Jan 2014 13:24:35 -0800 (PST) In-Reply-To: References: Date: Sun, 26 Jan 2014 22:24:35 +0100 X-Google-Sender-Auth: 9ebIKPS5Gl-4WzRdo_mwoRCFnWI Message-ID: From: Mike Hearn To: Andreas Schildbach Content-Type: multipart/alternative; boundary=001a11c30600c1925904f0e6374b X-Spam-Score: -0.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 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1W7XC4-0007XS-QZ Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP70/71 issue, RFD 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: Sun, 26 Jan 2014 21:24:42 -0000 --001a11c30600c1925904f0e6374b Content-Type: text/plain; charset=UTF-8 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 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 > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a11c30600c1925904f0e6374b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 fo= r NFC tags nor QR codes.


On Sun, Jan 26, 2014 at 10:11 PM, Andreas Schildbach <= andreas@schildba= ch.de> wrote:
I'm experimenting with BIP70/71 (payment protocol) usage in face to fac= e
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<= br> 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&#= 39;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/gam= pad/clk?id=3D119420431&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11c30600c1925904f0e6374b--