As promised I'd like to present my work done on leveraging the payment
protocol for face-to-face payments. The general assumption is that
individuals don't own X.509 certificates. Their devices may be only
badly connected to the internet or in some cases not at all. I've
implemented a prototype on
Thanks Andreas, that's really interesting work. Comments below.
On Mon, Jan 27, 2014 at 12:59 PM, Andreas Schildbach
wrote:
> Because I could not find any standard for Bluetooth URLs, I made
> up my own: "bt:112233445566" means MAC address 11:22:33:44:55:66.
I would like to see Bluetooth contin
At the moment there's no way to distinguish between a failed / rejected
submission and a successful one beyond the freeform memo field, right? It'd
be good if we had an error code field as well, perhaps for a future version.
--
On 01/27/2014 03:54 PM, Gavin Andresen wrote:
> The purpose of PaymentACK is to give the customer reassurance that their
> payment request has been received and will be processed (or not).
>
> If it is syntactically incorrect or invalid in a way that the payment
> processor can detect right away
On Sun, Jan 26, 2014 at 4:56 PM, Andreas Schildbach
wrote:
> The BIP70 is very brief on what a PaymentACK is supposed to mean. Quote:
>
> "it [PaymentACK] is sent from the merchant's server to the bitcoin
> wallet in response to a Payment message"
>
> Does it simply mean we received a syntacticall
On 01/27/2014 06:11 PM, Jeremy Spilman wrote:
>> SCAN TO PAY
>> For scan-to-pay, the current landscape looks different. I assume at
>> least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
>> into a QR-code. Nevertheless, I tried to encode a payment request into
>> the bitcoin URL
On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
wrote:
> SCAN TO PAY
> For scan-to-pay, the current landscape looks different. I assume at
> least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
> into a QR-code. Nevertheless, I tried to encode a payment request into
> t
On Jan 27, 2014, at 9:39 AM, Andreas Schildbach wrote:
> On 01/27/2014 06:11 PM, Jeremy Spilman wrote:
>
>>> SCAN TO PAY
>>> For scan-to-pay, the current landscape looks different. I assume at
>>> least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
>>> into a QR-code. Neverth
On 01/27/2014 02:11 PM, Mike Hearn wrote:
> I would like to see Bluetooth continue to work for scan-to-pay even in
> the signed case. So for this reason the current approach with a BTMAC
> parameter in the Bitcoin URI seems to work universally across NFC tags
> and QR codes, and would allow downlo
On Mon, Jan 27, 2014 at 7:18 PM, Andreas Schildbach
wrote:
> I'm not saying I'm against signed payment requests, but unfortunately
> they are just too big for QR-codes. Then again, QR-codes *can* take up
> to 2 KB. How big would a very basic trust chain plus signature be?
>
As I said, the test re
On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:
> On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
> wrote:
>
> > SCAN TO PAY
> > For scan-to-pay, the current landscape looks different. I assume at
> > least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
On 01/27/2014 07:18 PM, Andreas Schildbach wrote:
>> Rather than pack a file into a URL, if you don't want to
>> use the current r= extension it's better for apps to just register to
>> handle .bitcoinpaymentrequest files / the right MIME type. Downloading
>> it and opening it would do the right t
>
> All insist on handling the link with their download manager, which would
> involve an additional click.
That's the expected behaviour, right? That's why I said "download and
open". The Bitcoin URI with r= is better because it lets you remove that
second click, but in some contexts the file ap
+1 for an error field.
Should the wallet broadcast the transaction to the bitcoin network when it
receives an ACK, or always assume that the merchant server will do that?
On Mon, Jan 27, 2014 at 7:52 AM, Mike Hearn wrote:
> At the moment there's no way to distinguish between a failed / rejecte
On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene wrote:
> +1 for an error field.
Agree, I think we need a way for client applications to interpret the response.
> Should the wallet broadcast the transaction to the bitcoin network when it
> receives an ACK, or always assume that the merchant server
>> Should the wallet broadcast the transaction to the bitcoin network when
it
>> receives an ACK, or always assume that the merchant server will do that?
>
> In my opinion, that should be the primary meaning of receiving an ACK:
> acknowledgement that the receiver takes responsibility for getting t
Hi,
[I sent this email 2 days ago prior my registration to the mailing list; please
forgive me if this is a duplicate]
I would like to propose an extension to the Payment Protocol (bip-0070) to
address the case of recurring payments in Bitcoin -- new bip or modification of
bip-0070.
There has
+1 to the idea of recurring payment requests.
Perhaps one way to realize this would be to add an optional URL to the
PaymentRequest object where the next PaymentRequest can be fetched and the
date at which the merchant expects the next payment.
On Mon, Jan 27, 2014 at 6:36 PM, Stephane Brossier
Yes, recurring payments and subscriptions is a frequently-requested
feature. It needs a new BIP. Here is an outline:
The situation is somewhat analogous to HTML5 local storage. The
remote (merchant) wants to initiate a persistent behavior.
Note: This is ONE
--
Jeff Garzik
Bitcoin core develo
Yes, recurring payments and subscriptions is a frequently-requested
feature. It needs a new BIP. Here is an outline:
The situation is somewhat analogous to HTML5 local storage. The remote
(merchant) wants to initiate a persistent behavior. This is bitcoin, so we
have a "push" model for payment
It could be useful to schedule x payments for y amount every z time
period, but you'd want to be able to pause or cancel at any time.
If you want the merchant to be able to request a series of payments
like a subscription, the merchant might also be able to request that
the subscription be paused
Greatly appreciate seeing this discussion occur. This is something that
potentially could be supported through a bounty - possibly a process BIP?
Possibly related: https://gist.github.com/ABISprotocol/8515891
> Yes, recurring payments and subscriptions is a frequently-requested
> feature. It ne
I think the right approach for this is to actually implement it and
*then* propose
a BIP. There are so many possible features we could add to the payment
protocol, any other approach would rapidly turn into lots of people
deciding to do the "fun bits" and often leaving others doing the hard work
wi
Let's keep fund raising off this mailing list, please. PS bounties don't
work.
On Tue, Jan 28, 2014 at 1:08 AM, Odinn Cyberguerrilla <
odinn.cyberguerri...@riseup.net> wrote:
> Greatly appreciate seeing this discussion occur. This is something that
> potentially could be supported through a bo
24 matches
Mail list logo
