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.

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

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:<apublickey>" and sometimes just "<apublickey>", 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

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

In jcenter I see a 2.0 version but the android-wallet overall is associated with a 5.21 version in github, so I just wanted to check in case 2.0 is too old.
thanks!

https://docs.gradle.org/3.3/userguide/gradle_wrapper.html

5.2. Adding the Wrapper to a project

The Wrapper is something you should check into version control. By distributing the Wrapper with your project, anyone can work with it without needing to install Gradle beforehand. Even better, users of the build are guaranteed to use the version of Gradle that the build was designed to work with. Of course, this is also great for continuous integration servers (i.e. servers that regularly build your project) as it requires no configuration on the server.

I'm trying to build the wallet on Android Studio 2.3.2 and getting into difficulty.

Try 1.  I tried to build it using "Check out project from version control: GitHub".  Ideally I'd like gradle wrapper to be the driving component here. 
When it downloads, the IDE asks: "Would you like to create a studio project?", to which I say yes.
I then chose "Import Model from external model", with the single option "gradle" selected.  I reckon this is more appropriate, since the github has gradle files.
On the next page, unfortunately the gradle wrapper option is greyed out ("not configured for the current project") and the only choice I have is a "local gradle distribution" option.
For gradle home I set: C:/Program Files/Android/Android Studio/gradle/gradle-3.2  and project format of .idea.

The gradle daemon starts and after a minute of activity, stops with:
"Gradle version 2.10 is required.  Current version is 3.2.  If you are using gradle wrapper ...<edit some file>"  - I'm unfortunately not on gradle wrapper for this project (though I'd like to be, for precisely this predicament.  The file it asks me to edit is one in the project's "gradle/wrapper" folder but I don't have that folder (since gradle wrapper was greyed out for me).
So dead end on try 1.
 
I reckon the AS 2.3.2 project launcher tool just doesn't know how properly to convert a github project straight into a 'gradle wrapper' controlled one.
Android studio 2.3.2 installed gradle/gradle-3.2 for me in that folder, and I'd rather like android studio and gradle wrapper to handle things like specific versions of the build tool - that after all is its purpose.

Try 2. Try 1 of course left the clone of the repository in my local file system, so next I tried to "Open an Existing Android Studio Project" on it.
Here I get asked "Gradle settings are not configured yet. Would you like to use gradle wrapper", to which I say OK.  I am hoping, in doing this, that gradle will get to know that 2.10 is required.
The daemon whirrs for a while then fails on:
Error:(1, 0) Gradle version 2.10 is required. Current version is 3.3.
Please fix the project's Gradle settings.
<a href="fixGradleVersionInWrapper">Fix Gradle wrapper and re-import project</a><br><a href="openGradleSettings">Gradle settings</a>

So now I have a gradle/wrapper folder and I edit the gradle-wrapper.properties in that project changing this line to
distributionUrl=https\://services.gradle.org/distributions/gradle-2.10-all.zip:

This works (project builds, testnet APK launches into emulator) but I get this nagging message:

Warning:Android Studio 2.3.2.0 requires Gradle 2.14.1 (or newer) but project is using version 2.10.
It is strongly recommended that you update Gradle to version 2.14.1 or newer.
<a href="fixGradleElements">Fix Gradle version (as part of the update, the Android plugin will be updated to version 2.3.2)</a><br><a href="https://developer.android.com/studio/releases/index.html#Revisions">Open Documentation</a>



What do you recommend I do from here?

many thanks guys!

John, Kimbrough Software

by "sign up to" i mean the wallet developer decides at design time to implement BIP20 - this functionality is already there in some wallets.  they've signed up to implementing and responding to this kind of protocol message.

Does anyone have any other thoughts on the matter?

thanks,
John
Kimbrough Software

I guess I'm asking if this exists implicitly or explicitly in the bip20 / bip 70 / a.n. other protocol which wallets sign up to?  By the way, which wallets allow this kind of query? 

the use case is: i have a bitcoin-aware app A on an andriod phone, which would then like to trigger a bitcoin payment request to be executed by an on-phone bitcoin wallet via the BIB20/bitcoin: URI mechanism. Rather than generating the payment request directly and immediately for an arbitrary amount of bitcoin, is there a way to in effect ask the bitcoin wallet if it has at least N bitcoins in it first?

I'm reading Franco's book "Understanding Bitcoin" and greatly enjoying it.   Franco says these are usually written by miners on bespoke node code bases.  What are the main purposes of such transactions? I have discovered that, separately, transactions with dates in the future (non final) also get dropped from the mempool.  As too do double spends.  But i'm curious to know how people are using these non-standard txs.