I have been playing around today with the 'seaglass' look and feel.
Whilst it looks very nice unfortunately it does not handle the mouse scroll wheel properly in combo boxes and window scroll bars. It 'kinda' works but not 100%.
I have thus dropped it from the code.
Also, there has been quite a lot of localisation work done over the last couple of weeks (Thanks!)
so I plan to release another live version, hopefully on Monday.
I will include all the localisation work that is done by Monday morning (GMT). There are also some code tidy ups that would be nice to get out but the release if mainly for the localisation work.
Topic: MultiBit - page 35. (Read 336309 times)
If you look at the https://multibit.org/releases.html you can see there is a test version of MultiBit with them in already.
(it's the 0.5.7beta version)
There is some more work in finishing them off before it goes on release to everybody.
You can download it from https://multibit.org/releases/multibit-0.5.7beta to try it out.
(it's the 0.5.7beta version)
There is some more work in finishing them off before it goes on release to everybody.
You can download it from https://multibit.org/releases/multibit-0.5.7beta to try it out.
Giving it a download now. Thanks!
Hm... What's needed right now is a better alternative to Bitcoin-Qt for newbies that don't want to spend several days downloading gigabytes of blockchain. I would recommend MultiBit if it had wallet encryption.
The feature you describe above sounds useful, but is it really worth spending time on it now? How about pushing that to 0.6+, and releasing a 0.5 with the same type of wallet encryption that Bitcoin-Qt has?
MultiBit has an opportunity to increase its "market share" now while Bitcoin-Qt sucks, that may go away when ultraprune arrives.
After some discussion on the bitcoinj mailing list, I've come round to Foo's point of view in that the wallet master key is not really worth the development effort. The time would be better spent on finishing off the current encryption code and getting it out the door.
This would then enable me to contribute earlier to the Java hierarchical deterministic (HD) wallets coding.
HD wallets are probably going to take over from 'random key' wallets anyhow. Having the mnemonic pass phrase will enable you to recreate the whole wallet (Electrum style) if you need to.
If you look at the https://multibit.org/releases.html you can see there is a test version of MultiBit with them in already.
(it's the 0.5.7beta version)
There is some more work in finishing them off before it goes on release to everybody.
You can download it from https://multibit.org/releases/multibit-0.5.7beta to try it out.
(it's the 0.5.7beta version)
There is some more work in finishing them off before it goes on release to everybody.
You can download it from https://multibit.org/releases/multibit-0.5.7beta to try it out.
I know that encrypted wallets are a planned feature in future versions of MultiBit. Any idea when they'll be implemented?
It is already on my ToDo list.
I want to show the Balance per receiving address as part of the functionality to archive off old receiving addresses (like in blockchain.info)
Not that I'll get to doing that functionality soon but it is on the list!
:-)
I want to show the Balance per receiving address as part of the functionality to archive off old receiving addresses (like in blockchain.info)
Not that I'll get to doing that functionality soon but it is on the list!
:-)
Do you mean:
Every unique address in the Request 'list of your addresses' has it's own amount which is stored ie remembered
?
Every unique address in the Request 'list of your addresses' has it's own amount which is stored ie remembered
?
Sorry for confusing you:) I mean Balance, not Amount. So:
Every unique address in the Request 'list of your addresses' will have it's own balance displayed in new field "Balance". So there will be 3 fields:
Label
Address
Balance
Do you mean:
Every unique address in the Request 'list of your addresses' has it's own amount which is stored ie remembered
?
Every unique address in the Request 'list of your addresses' has it's own amount which is stored ie remembered
?
Can you please add field "Amount" in "Request" tab? So every address will have tab "Amount" with amount of BTC on it. Like in Blockchain Wallet.
I have added in a new look and feel, called "seaglass".
It is a bit lighter and more pastel than the current ones.
Screenshot:
It will appear in the next releases.
It is a bit lighter and more pastel than the current ones.
Screenshot:
It will appear in the next releases.
I have started on the work for:
Encrypted wallets with a wallet master key
I've only just started it but there is a google doc with the protobuf wallet definition here:
Bitcoinj Encrypted Private Key Wallets (version 4)
(It is not finished yet)
This is the low level structure of how the wallet is stored - once that has been completed, reviewed and agreed by the bitcoinj mailing list then I'll start coding up the wallet changes and the UI changes, as described in this document:
MultiBit Wallet Improvements
Encrypted wallets with a wallet master key
I've only just started it but there is a google doc with the protobuf wallet definition here:
Bitcoinj Encrypted Private Key Wallets (version 4)
(It is not finished yet)
This is the low level structure of how the wallet is stored - once that has been completed, reviewed and agreed by the bitcoinj mailing list then I'll start coding up the wallet changes and the UI changes, as described in this document:
MultiBit Wallet Improvements
Hi Giszmo,
In my release testing I export the keys from one wallet twice (encrypted and unencrypted) and then reimport them into two new wallets. This is to test the import/export. It picks up the transactions in the blocks ok.
It's quite easy to experiment with moving private keys around but for the general user I don't recommend doing it as it is just too easy to get confused. For instance:
Import Your Keys To A New Wallet And Double Your Bitcoin !!!
Also, you can imagine more complicated scenarios such as:
+ Wallet A and Wallet B have identical private keys but on completely different platforms.
+ there is a spend from Wallet A that appears in a block on one fork
and
+ there is another almost simultaneous spend of the same transaction outputs from Wallet B (on a completely different platform) that appears in a block on another fork.
What *should* happen is that both wallets follow their own fork (and hence the balances in the two wallets will be different until one fork dominates) and then the wallet that is reorged throws out the block with one of the similar transactions in and replays the blocks from the new fork. The balances should then match. This is all quite confusing for the user however so is best avoided.
In my release testing I export the keys from one wallet twice (encrypted and unencrypted) and then reimport them into two new wallets. This is to test the import/export. It picks up the transactions in the blocks ok.
It's quite easy to experiment with moving private keys around but for the general user I don't recommend doing it as it is just too easy to get confused. For instance:
Import Your Keys To A New Wallet And Double Your Bitcoin !!!
Also, you can imagine more complicated scenarios such as:
+ Wallet A and Wallet B have identical private keys but on completely different platforms.
+ there is a spend from Wallet A that appears in a block on one fork
and
+ there is another almost simultaneous spend of the same transaction outputs from Wallet B (on a completely different platform) that appears in a block on another fork.
What *should* happen is that both wallets follow their own fork (and hence the balances in the two wallets will be different until one fork dominates) and then the wallet that is reorged throws out the block with one of the similar transactions in and replays the blocks from the new fork. The balances should then match. This is all quite confusing for the user however so is best avoided.
Hi Giszmo,
You may very well be right but normally I don't recommend having the same private keys in two active wallets. It is too easy to double spend and you start banging up against edge conditions that neither wallet (that has the private keys in) has been tested against.
It's normally better if you copy the private keys from wallet A to wallet B to only use wallet B.
Also, for the distribution of transaction outputs I think Lenny has, MultiBit just isn't very good at dealing with at the moment. Most people just want to be able to press 'Send' and be sure the transaction will be sent ok. Hence my recommendation to use a client that is better with the fee calcs.
You may very well be right but normally I don't recommend having the same private keys in two active wallets. It is too easy to double spend and you start banging up against edge conditions that neither wallet (that has the private keys in) has been tested against.
It's normally better if you copy the private keys from wallet A to wallet B to only use wallet B.
Also, for the distribution of transaction outputs I think Lenny has, MultiBit just isn't very good at dealing with at the moment. Most people just want to be able to press 'Send' and be sure the transaction will be sent ok. Hence my recommendation to use a client that is better with the fee calcs.
I was actually more interested in whether Multibit would forget an "own double-spend" that way. Taken you know you won't reuse the key, it should also be safe to do it. Lastly, under no circumstances you should never loose coins from having any mix of copied keys. Just your book-keeping might get temporarily confused.
Hi Giszmo,
You may very well be right but normally I don't recommend having the same private keys in two active wallets. It is too easy to double spend and you start banging up against edge conditions that neither wallet (that has the duplicate private keys in) has been tested against.
It's normally better if you copy the private keys from wallet A to wallet B to then only use wallet B.
Also, for the distribution of transaction outputs I think Lenny has, MultiBit just isn't very good at dealing with at the moment. Most people just want to be able to press 'Send' and be sure the transaction will be sent ok. Hence my recommendation to use a client that is better with the fee calcs.
You may very well be right but normally I don't recommend having the same private keys in two active wallets. It is too easy to double spend and you start banging up against edge conditions that neither wallet (that has the duplicate private keys in) has been tested against.
It's normally better if you copy the private keys from wallet A to wallet B to then only use wallet B.
Also, for the distribution of transaction outputs I think Lenny has, MultiBit just isn't very good at dealing with at the moment. Most people just want to be able to press 'Send' and be sure the transaction will be sent ok. Hence my recommendation to use a client that is better with the fee calcs.
Hi Lenny,
Unfortunately no - better fees are a non-trivial bit of work and I plan to concentrate on encrypted wallets now until they are out the door.
I think your bitcoin has some small amounts that are aggregated together (from my investigations earlier). The current MultiBit is probably not the best client to use with these transactions for exactly the reasons you state. The transactions created will be too large for the fees added so they won't propagate through the network properly.
Pragmatically you are better off moving your bitcoin out into another client like blockchain.info or Electrum until the fees are calculated better. Come back to MultiBit when the fees are implemented properly and you can use it without any hassle.
You don't even need to send your bitcoin out as you can do an (unencrypted) private key export and import the file directly into blockchain.info. (be sure to secure delete the unencrypted key export file).
Obviously I would prefer you to use MultiBit but being practical I think another alt client would make for an easier life for you.
Unfortunately no - better fees are a non-trivial bit of work and I plan to concentrate on encrypted wallets now until they are out the door.
I think your bitcoin has some small amounts that are aggregated together (from my investigations earlier). The current MultiBit is probably not the best client to use with these transactions for exactly the reasons you state. The transactions created will be too large for the fees added so they won't propagate through the network properly.
Pragmatically you are better off moving your bitcoin out into another client like blockchain.info or Electrum until the fees are calculated better. Come back to MultiBit when the fees are implemented properly and you can use it without any hassle.
You don't even need to send your bitcoin out as you can do an (unencrypted) private key export and import the file directly into blockchain.info. (be sure to secure delete the unencrypted key export file).
Obviously I would prefer you to use MultiBit but being practical I think another alt client would make for an easier life for you.
Wouldn't it be possible to just export one priv key that is used in the non-spreading transaction to do one transaction with it via blockchain.info? Shouldn't multibit forget its own transaction when it sees a confirmed transaction that is in conflict with what it tries to send?
Hi Lenny,
Unfortunately no - better fees are a non-trivial bit of work and I plan to concentrate on encrypted wallets now until they are out the door.
I think your bitcoin has some small amounts that are aggregated together (from my investigations earlier). The current MultiBit is probably not the best client to use with these transactions for exactly the reasons you state. The transactions created will be too large for the fees added so they won't propagate through the network properly.
Pragmatically you are better off moving your bitcoin out into another client like blockchain.info or Electrum until the fees are calculated better. Come back to MultiBit when the fees are implemented properly and you can use it without any hassle.
You don't even need to send your bitcoin out as you can do an (unencrypted) private key export and import the file directly into blockchain.info. (Be sure to secure delete the unencrypted key export file afterwards).
Obviously I would prefer you to use MultiBit but being practical I think another alt client would make life easier for you.
Unfortunately no - better fees are a non-trivial bit of work and I plan to concentrate on encrypted wallets now until they are out the door.
I think your bitcoin has some small amounts that are aggregated together (from my investigations earlier). The current MultiBit is probably not the best client to use with these transactions for exactly the reasons you state. The transactions created will be too large for the fees added so they won't propagate through the network properly.
Pragmatically you are better off moving your bitcoin out into another client like blockchain.info or Electrum until the fees are calculated better. Come back to MultiBit when the fees are implemented properly and you can use it without any hassle.
You don't even need to send your bitcoin out as you can do an (unencrypted) private key export and import the file directly into blockchain.info. (Be sure to secure delete the unencrypted key export file afterwards).
Obviously I would prefer you to use MultiBit but being practical I think another alt client would make life easier for you.
It there any progress with wrong fee issue? Multibit still not working for me, it said "Seen by 1 peer. Not seen in blockchain" and my transactions actually never get out from my machine. I already described this problem few pages ago.
Hi Giszmo,
That is a good idea.
At the moment I don't have any proper server stats on the new server (just the server status which gives away too much system info to make public).
It would be good yes to improve the stats by processing the httpd logs and make them available using one of the Apache log analysers.
(Note: Your IP addresses won't be shown). I also need to add in a privacy policy and delete the logs after a set period too.
It is a background task to improve the server offering so bear with me on this.
That is a good idea.
At the moment I don't have any proper server stats on the new server (just the server status which gives away too much system info to make public).
It would be good yes to improve the stats by processing the httpd logs and make them available using one of the Apache log analysers.
(Note: Your IP addresses won't be shown). I also need to add in a privacy policy and delete the logs after a set period too.
It is a background task to improve the server offering so bear with me on this.
Mulitbit being the best localized client and having some statistically relevant download figures I wonder if you could give us a chart of countries?
I keep an eye on the multibit.org Alexa ranking:
http://www.alexa.com/siteinfo/multibit.org
Its ranking is normally over 700,000 but lower in the US as that has always been the 'heartland' of Bitcoin (currently 338,000 in the US).
Anyhow, looking further down that Alexa page it gives a ranking in Russia of 91,000. I am slightly amazed as I have never seen it ranked so low. Assuming that is real and not some Alexa glitch it would be nice to get the Russian translation complete. It is currently 93% done so is probably missing some of the most recent terms.
If you are a native Russian speaker please have a look at http://translate.multibit.org and click on the Russian flag. Thanks.
http://www.alexa.com/siteinfo/multibit.org
Its ranking is normally over 700,000 but lower in the US as that has always been the 'heartland' of Bitcoin (currently 338,000 in the US).
Anyhow, looking further down that Alexa page it gives a ranking in Russia of 91,000. I am slightly amazed as I have never seen it ranked so low. Assuming that is real and not some Alexa glitch it would be nice to get the Russian translation complete. It is currently 93% done so is probably missing some of the most recent terms.
If you are a native Russian speaker please have a look at http://translate.multibit.org and click on the Russian flag. Thanks.
Jump to: