Topic: workflow: app to de.schilbach wallet query for a valid wallet payment address? (Read 1011 times)

Posted by: HCP
Insert Quote
All you seem to be achieving, is moving these user actions from your "wallet" to another app... you still need to tell the app to request the address... which is pretty much like being in your wallet and clicking "receive"... Also, personally, I'm not entirely sure I would want other apps to be able to interact programmatically with my wallet... #notParanoid Tongue

It sounds a bit "edge case" to me, but then I don't have a need to receive a constant flow of payments for anything... you also would run into the issue of the "wallet" needing to run in the background as some kind of service or something listening for requests... which equals battery drain = death as far as mobile apps are concerned.

--------


What this achieves is allowing a single user action to initiate a series of flows of address.  I haven't just moved the set of N user actions from wallet to app. I have potentially a single app action, followed by a sequence of N-1 automatic address flows from wallet to app.

Perhaps if you imagine the wallet actually to be the finance department of an organisation, with payments received and actioned, it might be clearer how properly sanctioned algorithms can indeed be reliable users of the 'wallet'.

You don't necessarily need the wallet to have a service, though in time I think all successful wallets will.  Instead the protocol could be triggered by implicit intents on the bitcoin: uri.

All you seem to be achieving, is moving these user actions from your "wallet" to another app... you still need to tell the app to request the address... which is pretty much like being in your wallet and clicking "receive"... Also, personally, I'm not entirely sure I would want other apps to be able to interact programmatically with my wallet... #notParanoid

It sounds a bit "edge case" to me, but then I don't have a need to receive a constant flow of payments for anything... you also would run into the issue of the "wallet" needing to run in the background as some kind of service or something listening for requests... which equals battery drain = death as far as mobile apps are concerned.

Still, I'm sure if there is a great need for this, then it will happen... I just don't see an overwhelming need for this type of functionality at the present time. But then... I'm not everyone

Hi, insofar as there ever will be a need for an on device app to have a receive address, you'd agree that the current rather manual way of doing it involves a series of user actions.
Having this capacity implemented as a protocol (kind of like a bip 70/75 add on) would obviate the need for potentially N manual user actions.
Imagine for example a use case where a large number and constant flow of (small) payments are needed to be made to you, and you'd like them all to come in to different addresses.
Put another way, the wallet metaphor is too 19th C; in some future world, this so-called wallet might better be described as a hub of permissioned (and valuable) algorithms operating
on addresses and the block chain.
You'd permission well trusted algorithms, with bounds on behaviour, to maximise your utility better than if you had to enact a cumbersome sequence of user behaviours.
Kind of like the difference between buying a stock manually from a broker versus implementing a program trade on a direct market access tool.
John

No offense, but why would you be running an online shop from your phone?

Honestly, I don't really see the issue with going into your bitcoin wallet app... and clicking "receive" and then "sharing" the address to another app via the builtin Android "share" functionality or using the clipboard and copy/pasting it wherever you need it to be input. I'm fairly sure that pretty much all Android wallets support this feature already.

I still don't quite understand why someone would need to be retrieving so many new addresses from within another app that it would be too much hassle to just manually copy/paste from the wallet app?

OP... are you attempting to use your phone as a POS (Point of Sale) device or something? If so, then perhaps there is a niche market opportunity here for someone to develop a phone based POS system that accepts bitcoin payments?

No, I can't find any place in the GUI where you can export the xPub. Maybe there's something in the wallet's code, or bitcoinj that allows it, but looking through it there's nothing immediately obvious.

The closest thing I could find on the github was a tiny library called integration-android for integrating Bitcoin payments with another Android app. Unfortunately it can't export the xPub. I assume that was the library the OP referred to.

https://github.com/bitcoin-wallet/bitcoin-wallet


https://github.com/bitcoin-wallet/bitcoin-wallet/blob/master/integration-android/src/de/schildbach/wallet/integration/android/BitcoinIntegration.java

I don't mean seed or xPrv, but xPub. It can be exported, right? If even xPub can't be exported, I will be disappointed in this wallet. No offence. I have used it before and I really liked it. Don't want to see it going downhill.

I don't think so, in fact it's extremely difficult to export the seed words, or private keys from the wallet.

Andreas Schildbach doesn't agree that users should be able to export their private keys. All his wallet's GUI allows is backing up an encrypted wallet file. Getting the seed is possible, but not through the GUI.

Doesn't Android Bitcoin wallet support exporting xPub? If yes, isn't that enough to generate new addresses? I haven't used android wallet for a long time now. So I don't know what all new features it have.


For receiving payments to new addresses each time. You may need to do it for privacy, for example, if you have a shop or if you are a seller.

I'm still not entirely what the use case is here... Why would you be wanting to automatically generate a receive address from another app?

Would you not be more likely to be wanting to make a payment from another app? So you click the "pay now" link (ie. a bitcoin: URI with address to send to and the amount) and your wallet opens up and creates a transaction ready to be sent.

But I can't quite get my head around wanting to get a receive address while I'm in another app... and needing that app to be able to communicate with my wallet in a programmatic way...

Seems like a good wallet feature.
I base this on the following logic:  if you're prepared to share your public key via the usual manual 'share' link (which sometimes is "bitcoin:" and sometimes just "", then it ought to be programmatically doable too.
That key might be receiving a stream of payments into it.  And you might want it to be a different torn off key from your wallet on each payment, rather than the same one as now (or requiring the user to share/copy multiple times manually).
It would always be a new empty wallet key.

Before long, I think wallet vendors will need to accept that their wallets ought to be the programmatic hubs for all manner of off wallet bitcoin activity.

John

Some sort of "share" intent should allow you to share the address from the wallet to another app (effectively a clipboard copy really), but I do not think that there is any sort of API in the android wallet that allows you to poll it and request addresses...

I doubt this is possible. You can "sweep" the bitcoins from one private key to anoter which completely empties the wallet but I don't think there is a way you can transmit you address between different devices on this anroid app (the electrum or blockchain ones may be able to do this though).
You would have to just place all of the bitcoins you want to use onto your phone or found a way to control your computer from your phone (some sort of remote controlling connection may work).

Hi, is there a way for the android wallet (de.schilbach) to present one of the wallet addresses programmatically to another on-device app which can then treat this as an address to make a payment to?  I'm aware of it happening in the other direction, with de.schilbach.BitcoinIntegration, whereby the app can present an address (and amount) into the wallet via BIP70/INTENTs.  What I'm looking for is the app and the wallet somehow collaborating, to allow an address to be transmitted from wallet to app (ideally, the app would be in a position to request this address on multiple occasions, and on each occasion receive whatever was the latest wallet address created by the app - to prevent address reuse).
thanks
John