Mobile wallets with BIP70 extended public keys

giszmo

legendary

Activity: 1862

Merit: 1114

WalletScrutiny.com

Quote from: Mike Hearn on December 03, 2014, 07:34:28 AM

Yes for now the wallet has to specify outputs explicitly. BIP70 doesn't have any kind of generation support in it at the moment. Besides, they are supposed to expire after a while to let wallets forget keys.

Well, the idea is out there. Judge for yourself:
http://thisapp.io/ connects bitcoiners with merchants in a way that clients pay the merchant that in turn deducts it from money that was handed to him by a promoter. Imagine the promoter fronting $1000 to a café. It might take 100 transactions until the debt is settled. It might take less. Sure it would be possible to work with a static address or a hand full of addresses but what would really make sense would be to use a generator that the promoter transfers to the merchant who in turn presents addresses to his clients.

Quote from: Mike Hearn on December 03, 2014, 07:34:28 AM

WRT NFC - you can also use Bluetooth to transfer the payment request. Andreas Schildbach's wallet and derivatives support this.

Ah, true, haven't thought of that. Wonder how commonly they are used, though.

Mike Hearn

legendary

Activity: 1526

Merit: 1134

Yes for now the wallet has to specify outputs explicitly. BIP70 doesn't have any kind of generation support in it at the moment. Besides, they are supposed to expire after a while to let wallets forget keys.

WRT NFC - you can also use Bluetooth to transfer the payment request. Andreas Schildbach's wallet and derivatives support this.

giszmo

legendary

Activity: 1862

Merit: 1114

WalletScrutiny.com

Quote from: fbueller on November 30, 2014, 07:49:12 AM

It depends on your use case. BIP70 challenges the user to sign a transaction paying the outputs you define. If you already know the extended public key, you're can derive the address yourself.

As far as I understand BIP70, it does not contain a full transaction ready to be signed as it only provides the addresses to send to and not where it will come from. I had asked if these addresses could also be provided in the form of a generator (extended public key) instead of just a limited amount of addresses.

I want to request a million payments over the next years, so I don't want to upload a million addresses (derived from my extended public key) but rather a generator.

fbueller

sr. member

Activity: 412

Merit: 287

It depends on your use case. BIP70 challenges the user to sign a transaction paying the outputs you define. If you already know the extended public key, you're can derive the address yourself.

giszmo

legendary

Activity: 1862

Merit: 1114

WalletScrutiny.com

So over the day I came to the assumption that BIP70 does allow to send a payment request with actual addresses but not with extended public keys, so I will have to go with many simple addresses rather than with a generator?

giszmo

legendary

Activity: 1862

Merit: 1114

WalletScrutiny.com

I'm implementing a (most likely soon to be open source) product that already kind of works with normal addresses but I would really want it to interact with BIP32 extended public keys coming from users' phones, most likely via a BIP70 payment request.

Is there any mobile or web wallet that does generate these requests or do they all merely understand and react to them?

In the absence of NFC (yeah, most phones don't have NFC still) a QR-Code representation would be cool but BIP72 talks about a link that's being communicated. In a server-less scenario that is kind of a problem and QR-codes (yeah, they must die but for now lets assume they will be around and dominant for another 5 years) can store by far more information than is necessary for an extended public key. Is there a standard and how would data for such a QR look like? Is BIP70 as maybe BASE64-encoded QR anywhere close to being a standard?

Thank you in advance for any hints.

Topic: Mobile wallets with BIP70 extended public keys (Read 1761 times)