Broswer side payment signing in Javascript (20BTC)

[dogisland]

The bounty has now been claimed.

I want to be able to sign a payment transaction on the client side in a web browser.

So here's the challenge, can you create a HTML page using the bitcoinjs-lib JavaScript library https://github.com/bitcoinjs/bitcoinjs-lib and any other JavaScript library you might need.

I see it as a HTML form that takes the following input...

1. Takes a hex or Base58 private key.
2. Takes a destination address.
3. An amount.
4. Fields for any other details you might need. I'm assuming you should be able to get all the details required from the block chain from BlockExplorer ?
5. User click a button the Javascript creates transaction data into a textarea.
6. This raw transaction could then be taken away and imported into bitcoin. I believe this patch supports transaction import. https://bitcointalk.org/index.php?topic=28278.20

If anyone can come up with a working solution I'm willing to pay 20BTC.

[1714022956]

1714022956

[1714022956]

1714022956

[1714022956]

1714022956

[1714022956]

1714022956

[Stefan Thomas]

Just sent a partial solution (no UI) via PM.

[koin]

i don't know if this is relevant but wanted to share just in case it is: http://www.matasano.com/articles/javascript-cryptography/

[Stefan Thomas]

i don't know if this is relevant but wanted to share just in case it is: http://www.matasano.com/articles/javascript-cryptography/

I wrote a response to that article here. That response deals mostly with our implementations though.

The basic argument of the article is that you need to trust the server to deliver valid code, which is true. But nobody disputes that. To get around the problem there are plenty of other ways you can deliver the code, like browser extensions, downloadable apps, etc. It's still nice if your app also runs without installation, even if you have to trust the server in that case.

A longer refutation of the article by Nadim Kobeissi can be found here.

[dogisland]

Stefan has sent me a solution that we're going to work with so the bounty is claimed.

[pointbiz]

cool bounty. interesting discussion. good luck with the project.

[Stefan Thomas]

Bounty received! 

[Andrew Vorobyov]

So share script now

[Stefan Thomas]

So share script now

Here you go! https://gist.github.com/45f49a96669ccb016460

In case you're wondering - the private key that's in there is empty now.

[netrin]

This is fantastic. I'm loving this trend to decouple (de-triple) the data from the infrastructure. Stefan, how close are we to the use-case whereby I can take a memorized passphrase, hash it to generate a private key, generate a transaction offline, then email the transaction so that the recipient can broadcast the payment at his leisure?

[Stefan Thomas]

Stefan, how close are we to the user-case whereby I can take a memorized passphrase, hash it to generate a private key, generate a transaction offline, then email the transaction so that the recipient can broadcast the payment at his leisure?

I'd say about a 40BTC bounty away. 

All you'd need to do is create an HTML page (which you could of course save to your hard drive and run locally) that generates a key from the passphrase and prints out the signed transaction as base64.

Then to make an HTML page that takes a base64 transaction and sends it to a the network would be simply:

Code:

var txBase64= "...";

var exit = new Bitcoin.ExitNode("exit.trucoin.com", 3125, /* SSL= */ true);
exit.query('tx/send', {tx: txBase64}, true, function (res) {
  if (res.success) {
    // Successfully sent
  }
});

The main problem I see is that until the recipient actually publishes the transaction the sender could double spend. So the recipient shouldn't actually deliver his goods or whatever until he has actually published the transaction and preferably until it has made its way into a block.

[netrin]

The main problem I see is that until the recipient actually publishes the transaction the sender could double spend. So the recipient shouldn't actually deliver his goods or whatever until he has actually published the transaction and preferably until it has made its way into a block.

Sure, but I see this like a traveler check 'signed' with a password, an honorable deposit like money on a poker table, a reservation, or a transfer from a sterile computer in a vault that was never tasted a network connection.

STEFAN, YOU'RE A ROCK STAR!! http://www.blinkenfilme.de/phase3/014/ER3_014.webm (1:30++)

[Stefan Thomas]

Sure, but I see this like a traveler check 'signed' with a password, an honorable deposit like money on a poker table, or a reservation. But it can also be used to transfer funds from a sterile computer in a vault that was never tasted a network connection.

Hmm, well, keep in mind that at some point the computer where you want to sign the transaction needs some information from the block chain, namely the transaction hash, output index and value of each output that he wants to use.

So if the sender truly wants to stay offline, somebody who is online (for example the recipient) would have to create the transaction (without signatures), hand it to the sender and the sender would then check it, sign it and hand it back.

[pointbiz]

i don't know if this is relevant but wanted to share just in case it is: http://www.matasano.com/articles/javascript-cryptography/

Interesting read as well as the rebuttals. The rebuttal from the guy who wrote CryptoCat is great, his JavaScript app is a great step in the right direction, I think it's VERY cool. Instant, free, encrypted JavaScript chat rooms... if it's not "secure" it sure seems a lot more secret then the contents of your gmail or facebook chat.

This means that unless you can create a "clean-room" environment for your crypto code to run in, pulling in no resource tainted by any other site resource (from layout to UX) , you can't even know what version of the content you're looking at.

On bitaddress.org I use two techniques to create a "clean room". I include ALL the content embedded in a single HTML document. I include a SHA-1 hash of the HTML document in the documents file name therefore people would not have to review the code of any version more than once. Inside the HTML document I have a link to a text file which has my PGP signature of the SHA-1 hash. I added SSL to the site only due to user requests since people might often use the site without verifying the SHA-1 hash. Technically, someone could write a bot to poll my site every minute and download the HTML and verify the hash. So an environment can be created where the trustworthiness of the JavaScript provider can be challenged.
Theoretically, experts could review and sign the SHA-1 hash as a sign of approval.

matasano has a glaring bias against JavaScript. JavaScript is turing complete and the worlds most wildly used programming language. I suspect that more people have a working knowledge of JavaScript then any other language. It's like everyone's "second" language nowadays.

Also, matasano has not considered the Bitcoin use-case where at no time would you trust the other party to an SSL connection with your Bitcoin private key. I'd rather trust strongcoin over mybitcoin. Review-ability of JavaScript is part of it's beauty.

Installing software is dangerous nowadays. What's worse a flaw in the JavaScript implementation that allows an attacker to see your plaintext OR a keylogger? JavaScript is a great option.

[netrin]

computer where you want to sign the transaction needs some information from the block chain, namely the transaction hash, output index and value of each output that he wants to use.

I guess there's no practical benefit to exporting a transaction rather than an address key pair. I don't like the idea of dividing coins among a plethora of tiny offline address balances.

[Stefan Thomas]

I guess there's no practical benefit to exporting a transaction rather than an address key pair. I don't like the idea of dividing coins among a plethora of tiny offline address balances.

I don't follow. The obvious benefit to exporting a transaction rather than the whole keypair is the ability to spend only part of the money, i.e. any amount.

Why would you divide coins among a plethora of tiny offline address balances?

[dogisland]

We've successfully incorporated Stefans script into StrongCoin. We're now creating Bitcoin key pairs, encrypting them and creating patyments all on the client side.

[Stefan Thomas]

We've successfully incorporated Stefans script into StrongCoin. We're now creating Bitcoin key pairs, encrypting them and creating patyments all on the client side.

Are you running your own exit node?

[dogisland]

We're using yours at the moment Stefan if that's ok.

I need to free up some time and then use the instruction you gave me to install it on my own server.