Topic: MultiBit - page 81. (Read 336309 times)
@cypherdoc
Thanks for your enquiry about running MultiBit on a USB drive.
You do not mention which operating system you are using. The instructions are slightly different from OS to OS but here are the instructions for on Windows (edit: and Linux):
Installing MultiBit to run on a USB drive for Windows.
1) Insert your USB drive into your PC.
2) Run the MultiBit Windows installer. On the screen with the question "Select the installation path:" click on the "Browse" button and select a directory on your USB drive.
3) Run the rest of the installation as normal.
4) Once the installation is done, in Explorer navigate to your USB drive's MultiBit installation directory. It is the directory with the "multibit.exe" file.
5) Create a new text file called (exactly) "multibit.properties". Leave the file empty.
This is the MultiBit configuration file. Having a copy in the installation directory (rather than the user's application data) tells MultiBit to run locally.
6) To run MultiBit locally, double click on the multibit.exe file.
You will have a single default wallet created, called multibit.wallet. You can create new ones using the 'Create Wallet' button and doing a save into your USB drive. You will be using a locally stored blockchain (called multibit.blockchain).
Installing MultiBit to run on a USB drive for Linux.
1) Insert your USB drive into your Linux machine.
2) Run the MultiBit Linux installer. On the screen with the question "Select the installation path:" click on the "Browse" button and select a directory on your USB drive.
3) Run the rest of the installation as normal.
4) Once the installation is done, navigate to your USB drive's MultiBit installation directory. It is the directory with the "multibit-exe.jar" file.
5) Create a new text file called (exactly) "multibit.properties". Leave the file empty.
This is the MultiBit configuration file. Having a copy in the installation directory (rather than the user's application data) tells MultiBit to run locally.
6) To run MultiBit locally, double click on the multibit-exe.jar. If this does not start up the jar file, open a command line to your installation directory and run "java -jar multibit-exe.jar".
Notes and Gotchas
1) The path of the wallets in the configuration file contains the USB drive letter which may change according to how many other drives you have plugged in. In this case the wallets other than multibit.wallet will not be found when MultiBit opens. You can just use the "Open Wallet" button to load them. I will put on my TODO list to stored the wallet filenames in relative form as this would get round this.
2) With the instructions above, it assumes you have Java installed on the machine you plug into. You can also have a "Java Runtime Environment" stored on the USB too so that it is guaranteed to run. I will write up some notes on how to do this.
3) The installer will add some shortcuts for running MultiBit pointing to the USB drive. Of course these will not work if the USB drive is removed.
Let me know how you get on - running MultiBit on a USB drive will be quite useful to people so I would be interested in your experience and comments. It probably needs a custom screen in the installer where the user can choose a "Run locally" option.
Thanks for your enquiry about running MultiBit on a USB drive.
You do not mention which operating system you are using. The instructions are slightly different from OS to OS but here are the instructions for on Windows (edit: and Linux):
Installing MultiBit to run on a USB drive for Windows.
1) Insert your USB drive into your PC.
2) Run the MultiBit Windows installer. On the screen with the question "Select the installation path:" click on the "Browse" button and select a directory on your USB drive.
3) Run the rest of the installation as normal.
4) Once the installation is done, in Explorer navigate to your USB drive's MultiBit installation directory. It is the directory with the "multibit.exe" file.
5) Create a new text file called (exactly) "multibit.properties". Leave the file empty.
This is the MultiBit configuration file. Having a copy in the installation directory (rather than the user's application data) tells MultiBit to run locally.
6) To run MultiBit locally, double click on the multibit.exe file.
You will have a single default wallet created, called multibit.wallet. You can create new ones using the 'Create Wallet' button and doing a save into your USB drive. You will be using a locally stored blockchain (called multibit.blockchain).
Installing MultiBit to run on a USB drive for Linux.
1) Insert your USB drive into your Linux machine.
2) Run the MultiBit Linux installer. On the screen with the question "Select the installation path:" click on the "Browse" button and select a directory on your USB drive.
3) Run the rest of the installation as normal.
4) Once the installation is done, navigate to your USB drive's MultiBit installation directory. It is the directory with the "multibit-exe.jar" file.
5) Create a new text file called (exactly) "multibit.properties". Leave the file empty.
This is the MultiBit configuration file. Having a copy in the installation directory (rather than the user's application data) tells MultiBit to run locally.
6) To run MultiBit locally, double click on the multibit-exe.jar. If this does not start up the jar file, open a command line to your installation directory and run "java -jar multibit-exe.jar".
Notes and Gotchas
1) The path of the wallets in the configuration file contains the USB drive letter which may change according to how many other drives you have plugged in. In this case the wallets other than multibit.wallet will not be found when MultiBit opens. You can just use the "Open Wallet" button to load them. I will put on my TODO list to stored the wallet filenames in relative form as this would get round this.
2) With the instructions above, it assumes you have Java installed on the machine you plug into. You can also have a "Java Runtime Environment" stored on the USB too so that it is guaranteed to run. I will write up some notes on how to do this.
3) The installer will add some shortcuts for running MultiBit pointing to the USB drive. Of course these will not work if the USB drive is removed.
Let me know how you get on - running MultiBit on a USB drive will be quite useful to people so I would be interested in your experience and comments. It probably needs a custom screen in the installer where the user can choose a "Run locally" option.
New release on website
I have put the 0.3.0beta3 release on the http://multibit.org website:
20 Feb 2012 V0.3.0BETA3
Enhancements
+ Fix for network connection problems in 0.3.0beta2
+ Now tracks bitcoinj 0.4-snapshot instead of 0.3
+ I18n refresh, including Russian
Bugs
+ Private key import is currently not working correctly
New google groups mailing list: bitcoin-multibit
To make it a bit easier for people to keep up-to-date and discuss MultiBit, I have set up a Google groups mailing list:
bitcoin-multibit
http://groups.google.com/group/bitcoin-multibit?hl=en
Please join if you are interested in being part of MultiBit's progress.
I have put the 0.3.0beta3 release on the http://multibit.org website:
20 Feb 2012 V0.3.0BETA3
Enhancements
+ Fix for network connection problems in 0.3.0beta2
+ Now tracks bitcoinj 0.4-snapshot instead of 0.3
+ I18n refresh, including Russian
Bugs
+ Private key import is currently not working correctly
New google groups mailing list: bitcoin-multibit
To make it a bit easier for people to keep up-to-date and discuss MultiBit, I have set up a Google groups mailing list:
bitcoin-multibit
http://groups.google.com/group/bitcoin-multibit?hl=en
Please join if you are interested in being part of MultiBit's progress.
Also, I have been looking into getting some custom USB drives made with the MultiBit logo/ site URL on and preloading them with:
+ the MultiBit executable
+ Java runtimes for Windows + Linux (Macs always have one).
This would mean you could have a 'secure stash' for your bitcoins where you could plug in your 'MultiBit USB drive' into ANY Windows/ Mac/ Linux machine to access your bitcoins. Your wallets would be stored on the USB drive.
When you are not accessing them you just store them wherever you store your passports/ family jewelry.
Our current prefered model is this one:
http://www.usb-flashdrive.co.uk/usb-flash-drives/twister-drive-1
For backup, you will be able to export your wallets' private keys and put them somewhere safe.
For security this would only make sense when both the MultiBit private key export files and wallets are both encrypted hence the push on that.
We will be offering these for sale to the general public at pretty close to cost price. It feels like a good way to get the word out about bitcoin.
+ the MultiBit executable
+ Java runtimes for Windows + Linux (Macs always have one).
This would mean you could have a 'secure stash' for your bitcoins where you could plug in your 'MultiBit USB drive' into ANY Windows/ Mac/ Linux machine to access your bitcoins. Your wallets would be stored on the USB drive.
When you are not accessing them you just store them wherever you store your passports/ family jewelry.
Our current prefered model is this one:
http://www.usb-flashdrive.co.uk/usb-flash-drives/twister-drive-1
For backup, you will be able to export your wallets' private keys and put them somewhere safe.
For security this would only make sense when both the MultiBit private key export files and wallets are both encrypted hence the push on that.
We will be offering these for sale to the general public at pretty close to cost price. It feels like a good way to get the word out about bitcoin.
i've just started looking over this wallet as i'd heard it could run from a usb stick.
i have an Ironkey which i would assume could run this wallet. can u direct me to the instructions how to load Multibit onto it?
I just fired up the 0.3.0beta3 code (the one in the links a few posts above) to check it works post midnight feb20.
It connects ok, downloads blocks and I just sent some BTC to and from it ok.
Also, I think I have figured out what the bug was in the 0.3.0beta2 code that prevents it connecting - I think it was the alert message sent out on Feb 19 - it did not understand it and that messed up the connection
It connects ok, downloads blocks and I just sent some BTC to and from it ok.
Also, I think I have figured out what the bug was in the 0.3.0beta2 code that prevents it connecting - I think it was the alert message sent out on Feb 19 - it did not understand it and that messed up the connection
Hi m3ta, fsb4000, speedbus,
RE: your connection problems today - I have built my current MultiBit codebase into a release 0.3.0beta3 and loaded it to github as follows:
Windows installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-windows.exe
Mac DMG file
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3.dmg
Linux installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-linux.jar
I have done a quick test on my Mac + virtual machines (Win XP, Ubuntu 10.4 LTS) and they all connect and download blocks ok. Please let me know if they connect and download blocks on your systems.
A couple of notes:
1) I was not planning to release this code just yet. I know it has a bug in the private key import that I have not tracked down yet.
I expect I will do another release a bit later on this week once I have fixed it.
2) There is not much visually different with this release compared to the previous. I have mainly been working on updating from an older version of bitcoinj (0.3) to the latest code (0.4-snapshot). Oh - and having a holiday in Spain !
RE: your connection problems today - I have built my current MultiBit codebase into a release 0.3.0beta3 and loaded it to github as follows:
Windows installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-windows.exe
Mac DMG file
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3.dmg
Linux installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-linux.jar
I have done a quick test on my Mac + virtual machines (Win XP, Ubuntu 10.4 LTS) and they all connect and download blocks ok. Please let me know if they connect and download blocks on your systems.
A couple of notes:
1) I was not planning to release this code just yet. I know it has a bug in the private key import that I have not tracked down yet.
I expect I will do another release a bit later on this week once I have fixed it.
2) There is not much visually different with this release compared to the previous. I have mainly been working on updating from an older version of bitcoinj (0.3) to the latest code (0.4-snapshot). Oh - and having a holiday in Spain !
Thanks !! It works
Hi m3ta, fsb4000, speedbus,
RE: your connection problems today - I have built my current MultiBit codebase into a release 0.3.0beta3 and loaded it to github as follows:
Windows installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-windows.exe
Mac DMG file
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3.dmg
Linux installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-linux.jar
I have done a quick test on my Mac + virtual machines (Win XP, Ubuntu 10.4 LTS) and they all connect and download blocks ok. Please let me know if they connect and download blocks on your systems.
A couple of notes:
1) I was not planning to release this code just yet. I know it has a bug in the private key import that I have not tracked down yet.
I expect I will do another release a bit later on this week once I have fixed it.
2) There is not much visually different with this release compared to the previous. I have mainly been working on updating from an older version of bitcoinj (0.3) to the latest code (0.4-snapshot). Oh - and having a holiday in Spain !
RE: your connection problems today - I have built my current MultiBit codebase into a release 0.3.0beta3 and loaded it to github as follows:
Windows installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-windows.exe
Mac DMG file
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3.dmg
Linux installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-linux.jar
I have done a quick test on my Mac + virtual machines (Win XP, Ubuntu 10.4 LTS) and they all connect and download blocks ok. Please let me know if they connect and download blocks on your systems.
A couple of notes:
1) I was not planning to release this code just yet. I know it has a bug in the private key import that I have not tracked down yet.
I expect I will do another release a bit later on this week once I have fixed it.
2) There is not much visually different with this release compared to the previous. I have mainly been working on updating from an older version of bitcoinj (0.3) to the latest code (0.4-snapshot). Oh - and having a holiday in Spain !
Thanks !! It works
Hi m3ta, fsb4000, speedbus,
RE: your connection problems today - I have built my current MultiBit codebase into a release 0.3.0beta3 and loaded it to github as follows:
Windows installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-windows.exe
Mac DMG file
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3.dmg
Linux installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-linux.jar
I have done a quick test on my Mac + virtual machines (Win XP, Ubuntu 10.4 LTS) and they all connect and download blocks ok. Please let me know if they connect and download blocks on your systems.
A couple of notes:
1) I was not planning to release this code just yet. I know it has a bug in the private key import that I have not tracked down yet.
I expect I will do another release a bit later on this week once I have fixed it.
2) There is not much visually different with this release compared to the previous. I have mainly been working on updating from an older version of bitcoinj (0.3) to the latest code (0.4-snapshot). Oh - and having a holiday in Spain !
RE: your connection problems today - I have built my current MultiBit codebase into a release 0.3.0beta3 and loaded it to github as follows:
Windows installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-windows.exe
Mac DMG file
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3.dmg
Linux installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-linux.jar
I have done a quick test on my Mac + virtual machines (Win XP, Ubuntu 10.4 LTS) and they all connect and download blocks ok. Please let me know if they connect and download blocks on your systems.
A couple of notes:
1) I was not planning to release this code just yet. I know it has a bug in the private key import that I have not tracked down yet.
I expect I will do another release a bit later on this week once I have fixed it.
2) There is not much visually different with this release compared to the previous. I have mainly been working on updating from an older version of bitcoinj (0.3) to the latest code (0.4-snapshot). Oh - and having a holiday in Spain !
I had a strange bag today
Connecting.... Synchronising with network 735 blocks to download.
jim618 can give some version of me as well. System: Windows 7 x64 Home Premium
Code:
2012-02-19 19:41:07,640 INFO - PeerGroup - connecting to Peer(dnsseed.bluematt.me/213.216.77.143:8333)
2012-02-19 19:41:08,425 INFO - NetworkConnection - Connected to peer: version=40000, subVer='', services=0x1, time=Sun Feb 19 19:41:08 NOVT 2012, blocks=167511
2012-02-19 19:41:08,426 INFO - Peer - blockChainDownload(0000000000000000000000000000000000000000000000000000000000000000)
2012-02-19 19:41:08,426 INFO - PeerGroup - running Peer(dnsseed.bluematt.me/213.216.77.143:8333)
2012-02-19 19:41:08,426 ERROR - PeerGroup - error while talking to peer : class com.google.bitcoin.core.PeerException com.google.bitcoin.core.ProtocolException: Error deserializing message 73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee00000064000000004653656520626974636f696e2e6f72672f666562323020696620796f7520686176652074726f75626c6520636f6e6e656374696e67206166746572203230204665627275617279004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1
2012-02-19 19:41:12,640 INFO - PeerGroup - connecting to Peer(dnsseed.bluematt.me/193.107.204.107:8333)
2012-02-19 19:41:13,606 INFO - NetworkConnection - Connected to peer: version=32400, subVer='', services=0x1, time=Sun Feb 19 19:38:18 NOVT 2012, blocks=167511
2012-02-19 19:41:13,606 INFO - Peer - blockChainDownload(0000000000000000000000000000000000000000000000000000000000000000)
2012-02-19 19:41:13,607 INFO - PeerGroup - running Peer(dnsseed.bluematt.me/193.107.204.107:8333)
2012-02-19 19:41:13,607 ERROR - PeerGroup - error while talking to peer : class com.google.bitcoin.core.PeerException com.google.bitcoin.core.ProtocolException: Error deserializing message 73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee00000064000000004653656520626974636f696e2e6f72672f666562323020696620796f7520686176652074726f75626c6520636f6e6e656374696e67206166746572203230204665627275617279004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1
2012-02-19 19:41:17,640 INFO - PeerGroup - connecting to Peer(bitseed.xf2.org/173.255.194.34:8333)
2012-02-19 19:41:19,365 ERROR - PeerGroup - error while talking to peer : class com.google.bitcoin.core.PeerException java.net.ConnectException: Connection refused: connect
2012-02-19 19:41:22,641 INFO - PeerGroup - connecting to Peer(bitseed.xf2.org/66.158.72.2:8333)
2012-02-19 19:41:25,056 ERROR - PeerGroup - error while talking to peer : class com.google.bitcoin.core.PeerException java.net.ConnectException: Connection refused: connect
2012-02-19 19:41:27,641 INFO - PeerGroup - connecting to Peer(dnsseed.bluematt.me/184.73.208.210:8333)
2012-02-19 19:41:28,304 INFO - NetworkConnection - Connected to peer: version=50200, subVer='', services=0x1, time=Sun Feb 19 19:41:28 NOVT 2012, blocks=167511
2012-02-19 19:41:28,304 INFO - Peer - blockChainDownload(0000000000000000000000000000000000000000000000000000000000000000)
2012-02-19 19:41:28,304 INFO - PeerGroup - running Peer(dnsseed.bluematt.me/184.73.208.210:8333)
2012-02-19 19:41:28,304 ERROR - PeerGroup - error while talking to peer : class com.google.bitcoin.core.PeerException com.google.bitcoin.core.ProtocolException: Error deserializing message 73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee00000064000000004653656520626974636f696e2e6f72672f666562323020696620796f7520686176652074726f75626c6520636f6e6e656374696e67206166746572203230204665627275617279004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1
Connecting.... Synchronising with network 735 blocks to download.
jim618 can give some version of me as well. System: Windows 7 x64 Home Premium
Hi m3ta,
I know Mike Hearn updated the bitcoinj library for the code throwing the error (TransactionOutput) to handle scripts it does not understand on February 10th. This is not in the released MultiBit yet.
If you let me know the platform you are using (Windows, Mac, Linux) I will create you a build of the latest code for you to try out. This code is not quite production release yet - I need to do some more testing on it and some bug fixes - but will establish whether the latest bitcoinj code fixes your problem.
I know Mike Hearn updated the bitcoinj library for the code throwing the error (TransactionOutput) to handle scripts it does not understand on February 10th. This is not in the released MultiBit yet.
If you let me know the platform you are using (Windows, Mac, Linux) I will create you a build of the latest code for you to try out. This code is not quite production release yet - I need to do some more testing on it and some bug fixes - but will establish whether the latest bitcoinj code fixes your problem.
Code:
05:37:34.263 [AWT-EventQueue-0] ERROR c.g.bitcoin.core.TransactionOutput - Could not parse tx output script: com.google.bitcoin.core.ScriptException: Script not of right size to be a scriptPubKey, expecting 5 but got 1
05:37:34.263 [AWT-EventQueue-0] ERROR c.g.bitcoin.core.TransactionOutput - Could not parse tx output script: com.google.bitcoin.core.ScriptException: Script not of right size to be a scriptPubKey, expecting 5 but got 2
05:37:34.263 [AWT-EventQueue-0] ERROR c.g.bitcoin.core.TransactionOutput - Could not parse tx output script: com.google.bitcoin.core.ScriptException: Script not of right size to be a scriptPubKey, expecting 5 but got 1
05:37:34.264 [AWT-EventQueue-0] ERROR c.g.bitcoin.core.TransactionOutput - Could not parse tx output script: com.google.bitcoin.core.ScriptException: Script not of right size to be a scriptPubKey, expecting 5 but got 1
Quote
3956 block(s) to download. This may take a while
And stuck.
Hi bitcoinspot.nl,
Glad to hear your suggestions - it gives me useful feedback as to where to direct my efforts.
RE: using email for payment requests.
One of the unfortunate limitations of the email practically everyone uses is that is it as insecure as sending someone a postcard written with a pencil. Anybody who forwards it can read it and alter it. (Obviously not true with encrypted, signed email but this isn't widely used).
For payment requests it adds a whole number of security holes: For instance -
Scammer walks into your restaurant, eats a delicious meal and asks for the bitcoin address to pay to.
You email a payment request to him and (via his email server he has set up) swaps out YOUR bitcoin address for an address he controls.
His phone pings when you send the email and right in front of you he pays with the address in the email that looks like it came from you.
The bitcoin actually goes to an address he controls.
You will never see the bitcoin but it looks like he paid (and he can show you 'your' email with 'your' bitcoin address he just paid to).
ThomasV has added an experimental idea to have signed URIs so that you can tell the URI is genuine. This (or something to improve the URI security in a similar way) would have to be added before vanilla email can be used safely for payment requests.
Glad to hear your suggestions - it gives me useful feedback as to where to direct my efforts.
RE: using email for payment requests.
One of the unfortunate limitations of the email practically everyone uses is that is it as insecure as sending someone a postcard written with a pencil. Anybody who forwards it can read it and alter it. (Obviously not true with encrypted, signed email but this isn't widely used).
For payment requests it adds a whole number of security holes: For instance -
Scammer walks into your restaurant, eats a delicious meal and asks for the bitcoin address to pay to.
You email a payment request to him and (via his email server he has set up) swaps out YOUR bitcoin address for an address he controls.
His phone pings when you send the email and right in front of you he pays with the address in the email that looks like it came from you.
The bitcoin actually goes to an address he controls.
You will never see the bitcoin but it looks like he paid (and he can show you 'your' email with 'your' bitcoin address he just paid to).
ThomasV has added an experimental idea to have signed URIs so that you can tell the URI is genuine. This (or something to improve the URI security in a similar way) would have to be added before vanilla email can be used safely for payment requests.
Hi Jim,
There are two parts to that proposal: signed URIs and aliases.
Aliases are similar to email addresses. Instead of handing out your bitcoin address to someone, you just give your alias to someone.
I think that such a possibility would vastly increase the usability and acceptance of Bitcoin.
There is some demand for it (see thewalletlist.com)
However, my current proposal relies on a trusted authority that signs the alias.
The trusted authority must never be hacked, and it must follow certain rules (it should never sign the same alias twice).
If the owner of the alias wants to update the alias, he has to create a chain of signatures.
I think that this proposal would be improved if we could store aliases in the blockchain. The blockchain is a secure way to authenticate ownership of an alias.
I guess we could use Bitcoin or Namecoin. The Namecoin blockchain has been designed to suit that need. To play with the idea, I created the following alias:
http://explorer.dot-bit.org/n/37310
As you can see, it points to a Bitcoin address.
In order to simplify wallet management, I guess the Namecoin address that is used and the Bitcoin address could be derived from the same private key.
Using the Bitcoin blockchain would be perhaps a bit more convenient and easy for both users and programmers. Since we do not need to store arbitrary key-value pairs (the value is a Bitcoin address), using Namecoin introduces unnecessary complexities. We could derive a Bitcoin address from an alias (using a hash, but not the same hash as if the alias was the private key :-) ), and send a satoshi to that address; this creates an alias. To update it, the address owning the alias would need to create a transaction that transfers the alias to another address, for example with two outputs: the alias and the new address.
Hi bitcoinspot.nl,
Glad to hear your suggestions - it gives me useful feedback as to where to direct my efforts.
RE: using email for payment requests.
One of the unfortunate limitations of the email practically everyone uses is that is it as insecure as sending someone a postcard written with a pencil. Anybody who forwards it can read it and alter it. (Obviously not true with encrypted, signed email but this isn't widely used).
For payment requests it adds a whole number of security holes: For instance -
Scammer walks into your restaurant, eats a delicious meal and asks for the bitcoin address to pay to.
You email a payment request to him and (via his email server he has set up) swaps out YOUR bitcoin address for an address he controls.
His phone pings when you send the email and right in front of you he pays with the address in the email that looks like it came from you.
The bitcoin actually goes to an address he controls.
You will never see the bitcoin but it looks like he paid (and he can show you 'your' email with 'your' bitcoin address he just paid to).
ThomasV has added an experimental idea to have signed URIs so that you can tell the URI is genuine. This (or something to improve the URI security in a similar way) would have to be added before vanilla email can be used safely for payment requests.
Glad to hear your suggestions - it gives me useful feedback as to where to direct my efforts.
RE: using email for payment requests.
One of the unfortunate limitations of the email practically everyone uses is that is it as insecure as sending someone a postcard written with a pencil. Anybody who forwards it can read it and alter it. (Obviously not true with encrypted, signed email but this isn't widely used).
For payment requests it adds a whole number of security holes: For instance -
Scammer walks into your restaurant, eats a delicious meal and asks for the bitcoin address to pay to.
You email a payment request to him and (via his email server he has set up) swaps out YOUR bitcoin address for an address he controls.
His phone pings when you send the email and right in front of you he pays with the address in the email that looks like it came from you.
The bitcoin actually goes to an address he controls.
You will never see the bitcoin but it looks like he paid (and he can show you 'your' email with 'your' bitcoin address he just paid to).
ThomasV has added an experimental idea to have signed URIs so that you can tell the URI is genuine. This (or something to improve the URI security in a similar way) would have to be added before vanilla email can be used safely for payment requests.
Hi!
Thanks for incorporating my suggestions in the client, i really appreciate it!
one note though:
I though of the email feature more for payment-requests, not only for payment notifications.
The idea is that: if someone says "to which adress must i send the bitcoins" (e.g. in a restaurant or what have you) that you can say, "well let me just send you an email out of multibit which contains a swatch and bitcoin adress".
Like the notification option though
Greetings!
Thanks for incorporating my suggestions in the client, i really appreciate it!
one note though:
I though of the email feature more for payment-requests, not only for payment notifications.
The idea is that: if someone says "to which adress must i send the bitcoins" (e.g. in a restaurant or what have you) that you can say, "well let me just send you an email out of multibit which contains a swatch and bitcoin adress".
Like the notification option though
Greetings!
Hi freemoney,
Yes - it will be an interesting Spring and Summer if we can program it all up !
:-)
On a completely different note:
piuk - the author of the blockchain.info wallet - has introduced the ability to import the MultiBit key export files in their entirety into the blockchain.info wallet.
The option is in the 'Import/ Export' tab in the 'Import Wallet' section.
You just paste in the whole contents of a MultiBit key export file in the text box and hit 'Import Wallet'.
A couple of times when I have done it I had to close the browser tab, open a new one and relog in to my wallet to get it to refresh (I have mentioned this to piuk) but apart from that it seems to work well. MultiBit does not see the zero-confirmation sends if you send from the blockchain.info wallet but it picks up the block confirmation (I will look into this).
It is like having a 'live backup' of a MultiBit wallet in blockchain.info and vice versa.
Yes - it will be an interesting Spring and Summer if we can program it all up !
:-)
On a completely different note:
piuk - the author of the blockchain.info wallet - has introduced the ability to import the MultiBit key export files in their entirety into the blockchain.info wallet.
The option is in the 'Import/ Export' tab in the 'Import Wallet' section.
You just paste in the whole contents of a MultiBit key export file in the text box and hit 'Import Wallet'.
A couple of times when I have done it I had to close the browser tab, open a new one and relog in to my wallet to get it to refresh (I have mentioned this to piuk) but apart from that it seems to work well. MultiBit does not see the zero-confirmation sends if you send from the blockchain.info wallet but it picks up the block confirmation (I will look into this).
It is like having a 'live backup' of a MultiBit wallet in blockchain.info and vice versa.
Hi Jim and Gary,
thank you for clarifiying the aim of the XChange project and for clarifying the roadmap as you see it for the future of exchange integration.
It is really nice to see that we are thinking along the same lines.
I did not want to sound impatient, I can imagine how much work you already put into it and how much work it still will be.
So: Thank you again for all the work and enthusiasm you are putting into this.
I hope that the other clients and the exchanges will incorporate the XChange API.
thank you for clarifiying the aim of the XChange project and for clarifying the roadmap as you see it for the future of exchange integration.
It is really nice to see that we are thinking along the same lines.
I did not want to sound impatient, I can imagine how much work you already put into it and how much work it still will be.
So: Thank you again for all the work and enthusiasm you are putting into this.
I hope that the other clients and the exchanges will incorporate the XChange API.
Quote
The interface to the brokerage client would need such functions as:
-Inform about the bitcoin balance in a wallet (this would allow automated brokerage whenever the amount of bitcoins in the wallet reaches lower or upper limits)
-Inform about Buy/Sell orders of the user (assuming that the user initiates such orders in the client)
-Payment of bitcoin through the client to a bitcoin buyer in the case that the user want to sell bitcoins
-Inform about bitcoin receiving address generated in the client in the case that the user want to buy bitcoins
-Inform about received bitcoins in the case that the user wants to buy bitcoins
-The whole interface to the brokerage client needs to be encrypted for security reasons
-Inform about the bitcoin balance in a wallet (this would allow automated brokerage whenever the amount of bitcoins in the wallet reaches lower or upper limits)
-Inform about Buy/Sell orders of the user (assuming that the user initiates such orders in the client)
-Payment of bitcoin through the client to a bitcoin buyer in the case that the user want to sell bitcoins
-Inform about bitcoin receiving address generated in the client in the case that the user want to buy bitcoins
-Inform about received bitcoins in the case that the user wants to buy bitcoins
-The whole interface to the brokerage client needs to be encrypted for security reasons
Without hijacking the Multibit thread, I'd just like to clarify the purpose of the XChange project.
It's intended to act as a common API for any exchange (Bitcoin, fiat, centralised, distributed etc) so that applications can easily use any of them, in combination if required. To that end pretty much all of the above functions are going to be supported. For all operations, a brokerage is considered to be the same as an exchange.
When it comes to depositing fiat into the exchange there is a potential issue. XChange won't support this directly (it's not a payment gateway for MasterCard for example) but it would facilitate instructing the exchange to make, say, an authorised debit against a registered bank account if the exchange supported that through it's API.
As mentioned, XChange is Java only at the moment, but if anyone wants to start up a sister project, or work within the same repo, using a different language then they are certainly welcome. Just PM me for more details.
Finally, by providing a standard API XChange may be able to assist developers of new exchanges by showing them what needs to be available and how to implement it securely, and have a suitable test client all ready to go so they can verify that it all works as intended.
Hi freemoney,
I think we are both thinking along the same lines.
I would love for there to be decentralised exchanges in bitcoin but I do not think we are anywhere near there yet.
Initially the MultiBit exchange integration will be quite shallow (probably just getting exchange rates initially just to get the plumbing working) but I would like to deepen it over time to have the buy and sell orders etc.
I figure if I/ the bitcoin community collectively can get it to work for centralised exchanges then we are one step nearer decentralised exchanges.
I think the most difficult area is the contact point with the 'World of Fiat'. In your linked example you mention DarkExchange and a Germany specific account link. I am hoping that experience from integrating a few exchanges and OT will give us a workable interface that gives most functionality that is required (as an interface i.e. there will be limited implementations)
At that point it might be practical to have Country/ Fiat providers specific plugins. The XChange code is open source and whilst we are concentrating on the Java implementation it is not actually language specific. That would be the place for Country/ Fiat provider plugins to go (and hence they would not be MultiBit specific and available to all).
One step at a time here I think !
:-)
p.s. If anyone is interested in actually DOING an open source country/ fiat provider specific plugin let me know.
I think we are both thinking along the same lines.
I would love for there to be decentralised exchanges in bitcoin but I do not think we are anywhere near there yet.
Initially the MultiBit exchange integration will be quite shallow (probably just getting exchange rates initially just to get the plumbing working) but I would like to deepen it over time to have the buy and sell orders etc.
I figure if I/ the bitcoin community collectively can get it to work for centralised exchanges then we are one step nearer decentralised exchanges.
I think the most difficult area is the contact point with the 'World of Fiat'. In your linked example you mention DarkExchange and a Germany specific account link. I am hoping that experience from integrating a few exchanges and OT will give us a workable interface that gives most functionality that is required (as an interface i.e. there will be limited implementations)
At that point it might be practical to have Country/ Fiat providers specific plugins. The XChange code is open source and whilst we are concentrating on the Java implementation it is not actually language specific. That would be the place for Country/ Fiat provider plugins to go (and hence they would not be MultiBit specific and available to all).
One step at a time here I think !
:-)
p.s. If anyone is interested in actually DOING an open source country/ fiat provider specific plugin let me know.
I thought you would be interested in some future MultiBit development work we are starting up.
Tim Molter is a Java developer who is writing a library to integrate with the various bitcoin exchanges.
You can get more details of his project here:
https://github.com/timmolter/XChange/wiki/Milestones
https://github.com/timmolter/XChange/wiki/Exchange-support
We are planning to use XChange in both MultiBit and MultiBitMerchant, initially to get exchange rate data but later on to provide deeper integration with the exchanges. (We are still working out what we can and cannot do).
It will be a while before it appears fully productised in MultiBit / MultiBitMerchant but it is very interesting work.
Tim Molter is a Java developer who is writing a library to integrate with the various bitcoin exchanges.
You can get more details of his project here:
https://github.com/timmolter/XChange/wiki/Milestones
https://github.com/timmolter/XChange/wiki/Exchange-support
We are planning to use XChange in both MultiBit and MultiBitMerchant, initially to get exchange rate data but later on to provide deeper integration with the exchanges. (We are still working out what we can and cannot do).
It will be a while before it appears fully productised in MultiBit / MultiBitMerchant but it is very interesting work.
Hi Jim,
I appreciate that you plan to integrate an interface to bitcoin exchanges.
I think it will really help to improve the usability of any bitcoin client for a broader audience.
However, I think it is not enough to only integrate an interface to centralized exchanges for two reasons.
1. The recent events around Paxum and Tradehill show the vulnerabiltiy of bitcoin and of centralized exchanges.
The experience of the Tradehill customers having to find another exchange is not acceptable for a broader audience, but only for enthusiasts.
2. Even having to sign up and to mantain an account at an exchange is an effort that many people will not like.
I thought a bit about decentralized exchanges and how to integrate them into bitcoin clients, you can find it here:
https://bitcointalksearch.org/topic/m.746894
So here is my conclusion:
An interface for some basic exchange function support should be added to bitcoin clients.
The interface should offer the possibility that the bitcoin client interacts with centralized and with decentralized exchanges.
Ideally, the buying and selling of bitcoins runs automated in the background without the need of a user interaction.
There is no need to integrate everything in the client, this can be done with a brokerage client which interfaces with the bitcoin client.
The interface to the brokerage client would need such functions as:
-Inform about the bitcoin balance in a wallet (this would allow automated brokerage whenever the amount of bitcoins in the wallet reaches lower or upper limits)
-Inform about Buy/Sell orders of the user (assuming that the user initiates such orders in the client)
-Payment of bitcoin through the client to a bitcoin buyer in the case that the user want to sell bitcoins
-Inform about bitcoin receiving address generated in the client in the case that the user want to buy bitcoins
-Inform about received bitcoins in the case that the user wants to buy bitcoins
-The whole interface to the brokerage client needs to be encrypted for security reasons
Do you know if this will be possible with Tim Molters work or with the OT fork of MultiBit?
Jump to: