From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1X1vnU-0002ID-NB for bitcoin-development@lists.sourceforge.net; Tue, 01 Jul 2014 11:00:24 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of osfda.org designates 217.23.13.216 as permitted sender) client-ip=217.23.13.216; envelope-from=mw@osfda.org; helo=smtp.osfda.org; Received: from smtp.osfda.org ([217.23.13.216]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1X1vnS-0006jy-Px for bitcoin-development@lists.sourceforge.net; Tue, 01 Jul 2014 11:00:24 +0000 Received: from [192.168.1.117] (207-38-214-214.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com [207.38.214.214]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osfda.org (Postfix) with ESMTPSA id 79CB313A017F; Tue, 1 Jul 2014 12:42:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Wozniak In-Reply-To: Date: Tue, 1 Jul 2014 06:42:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140320215208.GC88006@giles.gnomon.org.uk> <20140326224826.GE62995@giles.gnomon.org.uk> To: Andreas Schildbach X-Mailer: Apple Mail (2.1878.2) X-Spam-Score: -1.6 (-) 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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1X1vnS-0006jy-Px Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 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: Tue, 01 Jul 2014 11:00:24 -0000 I think it makes more sense to not add a duplicate parameter. Current = implementations will break if multiple r parameters are used (either = reject the URI completely, or do something undefined). If a new = parameter is used, then the current implementations will just ignore it = if they don=E2=80=99t support it. - Michael Wozniak On Jul 1, 2014, at 5:48 AM, Andreas Schildbach = wrote: > On 07/01/2014 10:18 AM, Mike Hearn wrote: >> =E2=80=8BHowever it's not ideal at the moment. Basically the main = problem is >> that in the BIP72 there is no way to provide a fallback = alternative >> URI for payment request fetch if client wallet supports BIP70 but >> doesn't not support fetching over bluetooth or bluetooth = connection >> fails for any reason.=20 >=20 > I think the way to go here is using multiple r=3D parameters. >=20 >> So the idea here is that the recipient wallet both uploads to the >> internet and exposes the payment request over Bluetooth = simultaneously, >> then let's the sending wallet pick whatever radio layer works best in >> its current conditions? >=20 > Either that, or just use the other ones as a fallback. Currently, > Bitcoin Wallet just falls back to BIP21 if fetching the PR via the r=3D > URL fails. >=20 >> I think having multiple r=3D params is reasonable, but the Bluetooth >> support is not specced in any BIP anyway. And if it were to be, = people >> would point out the lack of link-layer encryption. >=20 > Its "specced" in code and implemented by several parties. I think its > clear that link-layer encryption has to be an add-on to the current > unencrypted connection, just like HTTPS is on top of HTTP. Anyway, > that's unrelated to the question of how to provide fallback URLs. >=20 > One more thought: We have a similar problem with the BIP70 payment = URL. > It doesn't allow for fallbacks either. I brought this issue up in the > discussion phase of BIP70, but it was dismissed I think because of > "let's not get too complex for the first version". The fallback here = is > to send the transaction via the P2P network. >=20 > (I think BIP70 via P2P radio will get used more often in future. I = plan > to look into Bluetooth 4 LE as soon as I have devices and wanted to = try > WIFI Direct again also. I hope we can skip BIP72 for both of those, = but > lets see.) >=20 >=20 >=20 > = --------------------------------------------------------------------------= ---- > Open source business process management suite built on Java and = Eclipse > Turn processes into business applications with Bonita BPM Community = Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development