dogisland (OP)
|
|
September 26, 2011, 12:26:43 PM Last edit: September 27, 2011, 08:31:37 AM by 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.20If anyone can come up with a working solution I'm willing to pay 20BTC.
|
|
|
|
Stefan Thomas
Full Member
Offline
Activity: 234
Merit: 100
AKA: Justmoon
|
|
September 27, 2011, 01:25:00 AM |
|
Just sent a partial solution (no UI) via PM.
|
Twitter: @justmoonPGP: D16E 7B04 42B9 F02E 0660 C094 C947 3700 A4B0 8BF3
|
|
|
|
Stefan Thomas
Full Member
Offline
Activity: 234
Merit: 100
AKA: Justmoon
|
|
September 27, 2011, 01:49:45 AM |
|
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.
|
Twitter: @justmoonPGP: D16E 7B04 42B9 F02E 0660 C094 C947 3700 A4B0 8BF3
|
|
|
dogisland (OP)
|
|
September 27, 2011, 08:31:02 AM |
|
Stefan has sent me a solution that we're going to work with so the bounty is claimed.
|
|
|
|
pointbiz
Sr. Member
Offline
Activity: 437
Merit: 415
1ninja
|
|
September 27, 2011, 12:34:53 PM |
|
cool bounty. interesting discussion. good luck with the project.
|
|
|
|
Stefan Thomas
Full Member
Offline
Activity: 234
Merit: 100
AKA: Justmoon
|
|
September 27, 2011, 12:49:39 PM |
|
Bounty received!
|
Twitter: @justmoonPGP: D16E 7B04 42B9 F02E 0660 C094 C947 3700 A4B0 8BF3
|
|
|
|
|
netrin
Sr. Member
Offline
Activity: 322
Merit: 251
FirstBits: 168Bc
|
|
September 28, 2011, 01:28:01 PM Last edit: September 28, 2011, 01:43:33 PM by 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
Full Member
Offline
Activity: 234
Merit: 100
AKA: Justmoon
|
|
September 28, 2011, 01:43:47 PM |
|
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: 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.
|
Twitter: @justmoonPGP: D16E 7B04 42B9 F02E 0660 C094 C947 3700 A4B0 8BF3
|
|
|
netrin
Sr. Member
Offline
Activity: 322
Merit: 251
FirstBits: 168Bc
|
|
September 28, 2011, 09:05:21 PM Last edit: September 28, 2011, 09:33:02 PM by 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
Full Member
Offline
Activity: 234
Merit: 100
AKA: Justmoon
|
|
September 28, 2011, 09:26:28 PM |
|
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.
|
Twitter: @justmoonPGP: D16E 7B04 42B9 F02E 0660 C094 C947 3700 A4B0 8BF3
|
|
|
pointbiz
Sr. Member
Offline
Activity: 437
Merit: 415
1ninja
|
|
September 29, 2011, 02:06:37 AM |
|
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
Sr. Member
Offline
Activity: 322
Merit: 251
FirstBits: 168Bc
|
|
September 29, 2011, 04:04:56 AM |
|
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
Full Member
Offline
Activity: 234
Merit: 100
AKA: Justmoon
|
|
September 29, 2011, 06:42:20 AM |
|
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?
|
Twitter: @justmoonPGP: D16E 7B04 42B9 F02E 0660 C094 C947 3700 A4B0 8BF3
|
|
|
dogisland (OP)
|
|
September 29, 2011, 08:49:54 AM |
|
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
Full Member
Offline
Activity: 234
Merit: 100
AKA: Justmoon
|
|
September 29, 2011, 08:50:34 AM |
|
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?
|
Twitter: @justmoonPGP: D16E 7B04 42B9 F02E 0660 C094 C947 3700 A4B0 8BF3
|
|
|
dogisland (OP)
|
|
September 29, 2011, 03:24:17 PM |
|
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.
|
|
|
|
|