Ability for client app using "in-app payment" to pass scriptPubKey by Intent to this app

[GoogleCodeExporter]

This is an enhancement suggestion.

When using the "In-App Payments" feature of bitcoin-wallet, the client app 
invokes the `BitcoinIntegration.request()` or `requestForResult()` methods, 
passing a String argument whose value is the Bitcoin address to which coins are 
to be sent.

It would be useful if rather than passing only a Bitcoin address to the 
`request()` method, it were possible to pass also the value of the 
`scriptPubKey` to be used in output of the consequent transaction.  As it 
currently stands, by passing only the address I am limited to the standard 
_send-to-address_ transaction type.  I would like to be able to do something 
like:

    ScriptBuilder builder = new ScriptBuilder();
    ...add the chunks of the scriptPubKey...
    Script myScript = ScriptBuilder.build();
    request(myActivity, address, myScript);

Actually, I would really like to leave the address out of it, but I'm not sure 
that's possible since a Bitcoin URL requires it.

I don't think this should be too hard to implement.  I've attached an untested 
suggestion in the form of a diff.  The most obvious (to me) issue with the 
attached suggestion is that the address in the Bitcoin URL is used only for 
determining the network parameters, so the display to the user is misleading in 
that it shows the destination address from the URL, but then sends the coins to 
according to the script.  However, since it seems that the recipient--not the 
sender--would be harmed by coins going to the wrong place, and since the 
recipient is the one who writes the script, I'm not sure this is really a 
dangerous problem.  In any event, if this suggestion is actually implemented, 
`SendCoinsFragment` could be modified so the information it displays indicates 
that coins will be sent according to a script and not to the address that came 
in the URL.

I'm happy to do whatever I can to make this happen, including contributing more 
code (assuming, of course, that I'm not missing some reason why implementing 
this would be a Bad Idea).

--
Adam Mackler

Original issue reported on code.google.com by adammack...@gmail.com on 12 Aug 2013 at 2:32

Attachments:

• suggestion.rcs

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Can you say why do you want to pass pubkeys around? What's so bad about regular 
Bitcoin addresses?

Original comment by andreas....@gmail.com on 12 Aug 2013 at 10:07

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I have no interest in passing public keys; I'm interested in using the Bitcoin 
scripting language.

https://en.bitcoin.it/wiki/Script

scriptPubKey is just the name of the payment validation instructions that are 
attached to a transaction output; it doesn't actually have to have a public key 
in it.

My immediate goal is to use the PUSHDATA op-codes to add constants to the 
script so I can associate Bitcoin payments with particular 
(non-bitcoin-payment) transactions.  If someone places an order, and then I see 
a payment, I need to know whether it came from the person placing the 
order--and there's even more risk if the payment precedes the order since it's 
publicly viewable in the block chain.   Beyond that, I am also interested in 
being able to create some of the more complex transactions described here:

https://en.bitcoin.it/wiki/Contracts

These require the ability to program transaction output scripts.

Original comment by adammack...@gmail.com on 12 Aug 2013 at 11:10

[GoogleCodeExporter]

The API for external applications will be enhanced as usecases mature. However, 
I won't open it for passing "arbitrary script data". You'd only find that the 
app would not handle special transactions the right way.

I suggest using bitcoinj in your app directly for experimenting. If you feel 
your usecase is already mature, feel free to start a discussion in the forum or 
maybe even the bitcoinj developer mailing list and we find a way to get your 
usecase covered.

Original comment by andreas....@gmail.com on 18 Aug 2013 at 9:27

[GoogleCodeExporter]

Okay.  Thank you for the consideration, prompt response and explanation.

Original comment by adammack...@gmail.com on 18 Aug 2013 at 11:09

[GoogleCodeExporter]

With the arrival of the payment protocol it appears to make more sense to 
specify whole scriptPubKeys rather than just addresses. The payment protocol 
itself allows for this. I'll add this to the integration subproject eventually.

Original comment by andreas....@gmail.com on 24 Feb 2014 at 10:00

• Changed state: Accepted

[GoogleCodeExporter]

It will also allow for multiple outputs and other payment protocol features.

Original comment by andreas....@gmail.com on 24 Feb 2014 at 10:01

[GoogleCodeExporter]

looking forward to the multiple outputs feature ... would be great to have a 
basic implementation already by mid/end of next week ... Bitcoin Conference and 
SXSW coming up ... would love to demo the integration there to people on my app 
- hey but no pressure ;)

Original comment by rotz...@googlemail.com on 24 Feb 2014 at 10:51

[GoogleCodeExporter]

I have a branch that implements the feature here:
https://github.com/schildbach/bitcoin-wallet/commits/integration-payment-request

Try building all sub-projects. Then deploy to your device "wallet" and 
"sample-integration-android". The later will show you how to build and send a 
payment request. In bitcoinj 0.12, we expect to see a helper class for creating 
payment requests, but for now you need to create it "by hand".

Does this work for you?

Note that before actually using this on mainnet, you need to wait for until I 
merge this branch and deploy a new version of the app to the Play Store.

Original comment by andreas....@gmail.com on 24 Feb 2014 at 1:55

[GoogleCodeExporter]

One more thought: I think I will even return a BIP70 payment message via the 
result intent (in case you used "requestForResult"). Currently, you only get a 
transaction hash, which by the way is the old one that is affected by 
transaction malleability. I'll implement this the coming days.

Original comment by andreas....@gmail.com on 26 Feb 2014 at 12:39

[GoogleCodeExporter]

Excellent; thank you Andreas.  I am certain that I am not alone in my 
expectation that this will prove to me a widely-appreciated and usefully-used 
feature.

Original comment by adammack...@gmail.com on 27 Feb 2014 at 5:33

[GoogleCodeExporter]

Cool ... got it working on my supporttr app. That is really easing the process 
with multiple outputs! Thanks :) Let me know when the feature got released on 
official client.

Original comment by rotz...@googlemail.com on 27 Feb 2014 at 1:49

[GoogleCodeExporter]

Cool! I'll work on this branch over the weekend, let you test again for one 
round and release after that (at least as a public beta version).

Original comment by andreas....@gmail.com on 27 Feb 2014 at 2:38

[GoogleCodeExporter]

Actually I didn't wait for the weekend and implemented the payment message in 
the result right away. The branch is almost ready to merge -- I just want to do 
some regression testing.

It would be nice if you took a quick glance if your app still works. It should, 
as I didn't change any API. You can use 
BitcoinIntegration.paymentFromResult(data) if you can make any use of the 
payment message.

Original comment by andreas....@gmail.com on 27 Feb 2014 at 5:08

[GoogleCodeExporter]

I checked out the branch again, compiled it and its still working with my App :)

Original comment by rotz...@googlemail.com on 1 Mar 2014 at 11:29

[GoogleCodeExporter]

Brilliant, thanks! I just merged everything and pushed version 3.38 to Google 
Play. For getting the mainnet version, subscribe to beta versions here: 
https://play.google.com/apps/testing/de.schildbach.wallet

More testing appreciated.

Original comment by andreas....@gmail.com on 1 Mar 2014 at 2:09

[GoogleCodeExporter]

Original comment by andreas....@gmail.com on 1 Mar 2014 at 2:10

• Changed state: Fixed