Topic: MultiBit - page 26. (Read 336309 times)

Hi Roland,

Yes I think everybody will be pleased when we get encrypted wallet support available to everyone.

Because of all the work on MultiBit and the ever increasing downloads we have not had time to work on anything else (other than a websote refresh which is being worked on currently). I cannot see that changing for the next few months.

Regards,

Jim

Ok , looking forward to the encrypted wallets in the latest version so that i can recommend it to the visitors of my website

p.s. any news on the bitcoin-merchant front ?

Greetz roland.

Hi Jim,

a general usage question: how long does it take before payments show up in the wallet? I was sent 3 small payments today, see http://blockchain.info/address/
There are over 40 confirmations for each, but nothing is showing up in my wallet, while other wallets at least show maturing payments etc.

Thanks in advance.

EDIT: I used the method here https://bitcointalksearch.org/topic/support-i-sent-some-bitcoin-to-multibit-but-they-never-arrived-159437 which got the transactions in. Still quite annoying, hope you can fix that.

Hi Roland,

The wallet encryption is in the 0.5.9-SNAPSHOT version that is available at:
https://multibit.org/releases

The rough timeline for general release is:

+ at the moment people on the bitcoinj mailing list are testing it. I will fix any bugs they raise but generally not be adding new code for a while - this is called 'washup'. This will probably be a week or so.
+ once we are confident that the quality is ok I will then create a release candidate with the bug fixes (and move it to use the bitcoinj 0.8 that Mike has just announced). This is then retested by the bitcoinj mailing list and anyone else interested. That will probably be another week.

After that if there are no problems it will go on multibit.org as the general download.

Whilst people are testing it I will probably work on the help and the new website we are working on. You don't want to be adding new code (other than bug fixes) whilst people are testing it as it invalidates their test work.

Hi jim, long time no see!

I just installed the latest version of multibit on my usb-drive and its looking good

2 quick questions:
- when will wallet-encryption be included?
- Is it possible to add one extra button/screen to the installer so that you can choose the portable option
  e.g. multibit.properties is created for you.

Keep up the good work!

Roland.

Good !

i have done 'Reset blockchain and transactions'  in my version and all things are sort out i have uninstalled java and update to new all things working great now

@PTSeller, you might want to try the just release v0.5.9 version to see if you can do a 'Reset blockchain and transactions' with that as that will save you having to work with the private keys.

i am new to BTC the method you mention it kinda out of my mind can you please tell me step by step mate ? where to get private keys and how to import into blockchain ?

I have not seen that exception before so you'd better send me the logs.
Just zip up everything in the log directory and email it to me (https://multibit.org/team.html).

If you are after your BTC quickly you can export the private keys (unencrypted) and import them into blockchain.info or bitcoind.

@jim618

Hello mate i have some problem in my wallet there is no transaction from 4 months in my wallet and yesterday a guy send me few BTC on my btc address but still not received on blockchain. 177 confirmation on blockchain but in my wallet still no BTC has been credited kindly please help me out

when i try reset blockchain and transaction option it gives me error -> Blockchain replay was unsuccessful.  Error was "java.nio.channels.ClosedChannelException".

Waiting for reply !!

Automatic backups of your wallet.

Very good !

:-)

Hi Jim,

you are right.
Since I am using automatic backups I tend to forget that many people do them manually and sometimes forget them.

Kind Regards,
fremoney458

There is no perfect way to choose a change address that works in all cases.
If you choose the last address there is much more chance that the user does not have that key in any backups they have made.

We all do it. You make a backup and then forget to keep it updated.

Hi Jim,


What if BEFORE importing the wallet contained already more than one key?
In this case people would still experience that after importing keys the change is sent to an address outside their original 'somewhere' wallet.

To circumvent this, may I suggest that you send the change always to the LAST key of a wallet instead of the second key.

Of course people could import keys from multiple wallets or create new keys after the import, giving the same unwanted result as with the current solution (change to 1st key).

But there is an additional advantage to it:
Experienced users who want a 'fresh' address for the change of their next transaction can simply create a new address before spending.
For users who want to obfuscate the addresses they control, this could be helpful.
Because if the change is always sent to the same address this allows to easily track down which keys belong to the same wallet after a spend with change has been made.
On the other hand, if the change is sent always to a fresh address an analysis will not be able to link addresses which send change to the same address.

Hi FreeMoney,

I think you are right about that initial private key in the wallet.

I think what I will end up doing is:
+ the wallet that is created by default for new users will have one address in like now and initially be unencrypted. This is for usability for newbies.


But - when you click on New Wallet you will open a tab where you select things like:

+ wallet location
+ description
+ wallet type
+ number of keys to put in it initially
+ password

That way a new encrypted wallet will only ever have existed as encrypted.

That will probably go into the next round of "UI work".

Also, change (in the 0.4.23 release and the coming 0.5.9beta release) now goes to the SECOND address in the wallet - if it exists - so that the initial key is not used. This I put in as I found people were importing keys from "somewhere" and then not liking that the change was not going to one of their imported keys.  This would also fix change going to a key that was at one point stored unencrypted as you point out.

Hi Jim,

I am using MultiBit-0.5.8beta, and generally I am having a great experience using it.
Thank you for developing this awesome client.

I think I already mentioned the following in an earlier post, but want to get some update:

When creating a new wallet (or when starting the first installed version) MultiBit creates one address.
The wallet by default is unencrypted, so the private key for this first address in the wallet will be stored unencrypted in the filesystem.
At this time, malicious software on the computer would be able the seize the private key.
Therefore, I consider this private key and the corresponding public address to be insecure.
Even if later on you encrypt the wallet, the private key for this first address might already be compromised and could some months later be used by an attacker to seize the bitcoins stored at this address.

This behaviour I find especially troublesome due to the following reasons:
I. Change is sent back specifically to this first address. It can happen that large amounts are stored in this address due to this behaviour.
II. Now that MultiBit is the #1 recommended client on bitcoin.org for novice users (congratulations!), many people are using this client and more to come. This makes it a bigger target for attackers.

How do you want to close this tiny (but nonetheless existing) security hole?
Will there be a version without the first address generated by default?

Thanks again for all your efforts.

Hi FarmerBlue,

This is most likely caused by the transaction containing lots of small "satoshi sized" inputs creating a large transaction.
There is more about this in this support note:

https://bitcointalksearch.org/topic/support-i-sent-some-bitcoin-from-multibit-but-they-are-stuck-161311

Note section 2.1 which is the most likely cause.
The only real answer is to increase the miners' fee you add and to be patient after the send. If you search the forum there are anecdotal reports of these sorts of transactions taking a day or two to confirm (across all clients - it's not particularly a MultiBit thing).

Lots of small transaction outputs are becoming quite problematical to spend as the miners' fee can be more than their actual value.

Regards,

Jim

i need help

i have a wallet for freebee bitcoins i collect on those sites giving out bitcoins, then i send those coins once i get a bunch to my MAIN wallet been doing that for over a month now.
(both wallets are in multibit)

now i have tried 3 different times to send some coin like this and it is only coming up seen by 1 peer but not seen in block chain. (i am sending the 0.001 required tx fee)

i was using 0.4.20 and then after i had trouble the first time i upgraded to 0.4.23 and still happened again, i had reset block chain from a date 1 day before that transaction and the bitcoins just disappear from both wallets......so i then reset form original date and all bitcoins are back so i try to send to main wallet again and it just keeps being seen by 1 peer but not showing up in either block explorer or blockchain......i dont know what to do?


and now i am noticing this error now

Unable to load "https://multibit.org/version.txt". The error was "javax.net.ssl.SSLHandshakeException sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target".

Hi fsb4000,

I plan to keep MultiBit BTC only.

If another dev wants to fork it and put in LTC support that is up to them. The underlying library I use for all the Bitcoin stuff (bitcoinj) does not support LTC.