Hi Jim,
Version 0.5.7beta (Encrypted wallets) downloaded and sent some coins to BitMarket.eu, a free bitcoin exchange market who now needs a bit financial help.
I sent coins two times in rapid succession, I did not notice any unexpected restrictions due to change problems.
I can not tell for sure if it was due to the boomerang rule though, because I have about 20 addresses in my wallet and MultiBit used different addresses to send from.
Anyway, I just wanted to tell you that the whole sending experience was very smooth and fast.
Great work!
Topic: MultiBit - page 39. (Read 336316 times)
Hi Mike,
That would be very useful cheers.
There are three main changes, all of which I have put into the Wallet (though 3 should prob go into Transaction):
1) Wallet#completeTx now looks through the pending tx if there is not enough bitcoin in the unspent pool:
https://github.com/jim618/multibit/blob/v0.5-bitcoinj-0.7/src/main/java/com/google/bitcoin/core/Wallet.java
2) The Wallet#getBalance(BalanceType) works with another BalanceType (BalanceType.AVAILABLE_WITH_BOOMERANG_CHANGE):
(same URL)
This includes pending change if it has been seen by 2 peers.
3) I would be interested if you could think of a neater way of detecting your own change. In the Wallet I have a method:
transactionSpendsFromThisWalletAndHasBoomerangedBack
which feels a little clunky.
The rest of the changes are things like not allowing you to spend before you are connected to 2 peers (so as to give you a good chance of detecting the tx coming back) and UI updates when I get a onTransactionConfidenceChanged that I presume you are not so interested in.
Got a link to the patch you made, so I can give it a quick review?
There is a new test release of MultiBit.
The downloads URLs are at:
http://multibit.org/releases.html
Version 0.5.7beta (Encrypted wallets)
Enhancements:
+ Change is now spendable as soon as the transaction traverses the Bitcoin network.
+ Fix for "Could not generate key from password and salt" bug on send from unencrypted wallets.
Scan of release checklist
This fixes the feature of MultiBit that you could not spend change until the next block confirmation.
It would be very useful if a few people could test it out in the next few days before I put the change into the live code.
The downloads URLs are at:
http://multibit.org/releases.html
Version 0.5.7beta (Encrypted wallets)
Enhancements:
+ Change is now spendable as soon as the transaction traverses the Bitcoin network.
+ Fix for "Could not generate key from password and salt" bug on send from unencrypted wallets.
Scan of release checklist
This fixes the feature of MultiBit that you could not spend change until the next block confirmation.
It would be very useful if a few people could test it out in the next few days before I put the change into the live code.
Yeah - it is quite good fun watching the downloads.
Moving from github to AWS S3 means I have lost the very easy to use download figures - I just have a whole load of Apache style logs that need parsing now. I might actually shell out a few dollars a month on one of the S3 log parsers that are available.
I have not forgotten about notifications no !
:-)
Moving from github to AWS S3 means I have lost the very easy to use download figures - I just have a whole load of Apache style logs that need parsing now. I might actually shell out a few dollars a month on one of the S3 log parsers that are available.
I have not forgotten about notifications no !
:-)
200 a day, nice! Remember the importance of upgrade notifications though!
Running .5.6 Beta here
Whatever i do - i just get an error "Could not generate key from password and salt" every time i try to send coins. None of the wallets is encrypted.
Any idea what this is about?
Whatever i do - i just get an error "Could not generate key from password and salt" every time i try to send coins. None of the wallets is encrypted.
Any idea what this is about?
I have just (I think) found and fixed this bug whilst working on the 0.5.7beta release.
Rebuilding and retesting it now.
It was a bug in the code where it was incorrectly trying to generate an AES key for unencrypted wallets and hence failing.
Hi Foo,
The wallet encryption really has to be as good as possible right from the start. More testing and another round of improvements will be worth it in the long run.
I agree it is a bit frustrating though.
There is also an 'upgrade cost' of having different versions in the wild that I would like to avoid. If there are, say, 50 experienced users running the beta code and a new wallet version comes out then it is much easier to upgrade them rather than 1000s of less experienced users.
Downloads of MultiBit are running at about 200 a day so even a small failure rate means people start losing their bitcoin.
Once the 'spendable change' is released encrypted wallets will be the priority.
Thanks for your feedback.
The wallet encryption really has to be as good as possible right from the start. More testing and another round of improvements will be worth it in the long run.
I agree it is a bit frustrating though.
There is also an 'upgrade cost' of having different versions in the wild that I would like to avoid. If there are, say, 50 experienced users running the beta code and a new wallet version comes out then it is much easier to upgrade them rather than 1000s of less experienced users.
Downloads of MultiBit are running at about 200 a day so even a small failure rate means people start losing their bitcoin.
Once the 'spendable change' is released encrypted wallets will be the priority.
Thanks for your feedback.
Hi Phelix,
That is a good question.
Unfortunately the encryption code is not ready for general release yet mainly because the wallet format is still changing. It is improving - there will be a wallet master key that you can print off and use to reset your password if you forget it and I have a set of suggestions to go through from Mike to do. (He reviewed all the encryption code recently).
The wallet master key is Alan Reiner's idea - apparently forgetting your password is not that uncommon - with the current MultiBit encrypted wallets if you forget your password you are stuck trying to brute force it.
It's probably weeks of work to do it all.
The current beta code is ok if you know what you are doing (ie understand private keys and back things up) but it is not ready for the general user yet.
That is a good question.
Unfortunately the encryption code is not ready for general release yet mainly because the wallet format is still changing. It is improving - there will be a wallet master key that you can print off and use to reset your password if you forget it and I have a set of suggestions to go through from Mike to do. (He reviewed all the encryption code recently).
The wallet master key is Alan Reiner's idea - apparently forgetting your password is not that uncommon - with the current MultiBit encrypted wallets if you forget your password you are stuck trying to brute force it.
It's probably weeks of work to do it all.
The current beta code is ok if you know what you are doing (ie understand private keys and back things up) but it is not ready for the general user yet.
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.
Can you PM me the log files please and I will have a look. The password and salt only apply to encrypted wallets as I am sure you have guessed.
Oh and I have not forgotten about uploading some older versions of multiBit for you. Got a bit sidetracked with setting up Amazon S3.
Edit: you might want to try creating a new unencrypted wallet. Then do an export from the one that is causing you the problem and import them into the new unencrypted one.
Oh and I have not forgotten about uploading some older versions of multiBit for you. Got a bit sidetracked with setting up Amazon S3.
Edit: you might want to try creating a new unencrypted wallet. Then do an export from the one that is causing you the problem and import them into the new unencrypted one.
Running .5.6 Beta here
Whatever i do - i just get an error "Could not generate key from password and salt" every time i try to send coins. None of the wallets is encrypted.
Any idea what this is about?
Whatever i do - i just get an error "Could not generate key from password and salt" every time i try to send coins. None of the wallets is encrypted.
Any idea what this is about?
Previously the MultiBit binaries were being hosted on github.com
They have stopped hosting binaries (presumably to save on bandwidth costs) so I have moved the binaries to Amazon S3.
You shouldn't notice any difference other than the download link is different but any problems let me know.
They have stopped hosting binaries (presumably to save on bandwidth costs) so I have moved the binaries to Amazon S3.
You shouldn't notice any difference other than the download link is different but any problems let me know.
In the test code I have just implemented what I call the "Boomerang Rule" - see below:
It enables change to be spendable immediately as long as the transaction propagates through the network ok.
I will spend a little while testing it and then produce another test release (beta) with it in.
It would be very useful if a few people could test it out to make sure it works as expected before I put it into the live code.
It enables change to be spendable immediately as long as the transaction propagates through the network ok.
I will spend a little while testing it and then produce another test release (beta) with it in.
It would be very useful if a few people could test it out to make sure it works as expected before I put it into the live code.
just keep it simple. fee calculation in the qt-client is way too complicated.
I think BitcoinSpinner work out their fees by size of transaction only (last I spoke to Jan) so maybe I should move to the same algorithm as that would be an improvement on flat fees. I'll have a talk with him.
Hi Phelix,
That is a good question.
Unfortunately the encryption code is not ready for general release yet mainly because the wallet format is still changing. It is improving - there will be a wallet master key that you can print off and use to reset your password if you forget it and I have a set of suggestions to go through from Mike to do. (He reviewed all the encryption code recently).
The wallet master key is Alan Reiner's idea - apparently forgetting your password is not that uncommon - with the current MultiBit encrypted wallets if you forget your password you are stuck trying to brute force it.
It's probably weeks of work to do it all.
The current beta code is ok if you know what you are doing (ie understand private keys and back things up) but it is not ready for the general user yet.
That is a good question.
Unfortunately the encryption code is not ready for general release yet mainly because the wallet format is still changing. It is improving - there will be a wallet master key that you can print off and use to reset your password if you forget it and I have a set of suggestions to go through from Mike to do. (He reviewed all the encryption code recently).
The wallet master key is Alan Reiner's idea - apparently forgetting your password is not that uncommon - with the current MultiBit encrypted wallets if you forget your password you are stuck trying to brute force it.
It's probably weeks of work to do it all.
The current beta code is ok if you know what you are doing (ie understand private keys and back things up) but it is not ready for the general user yet.
There is a new test release of MultiBit at:
github.com
Version 0.5.6beta (Encrypted wallets)
Enhancements:
+ Everything from version 0.4.15 e.g currency support
+ Amount in BTC decimal aligned
+ testnet3 support
+ I think I have fixed the wallet panel being too wide in Linux (I never saw that bug so cannot be sure. Slush < could you try it out please ?).
Scan of release checklist
github.com
Version 0.5.6beta (Encrypted wallets)
Enhancements:
+ Everything from version 0.4.15 e.g currency support
+ Amount in BTC decimal aligned
+ testnet3 support
+ I think I have fixed the wallet panel being too wide in Linux (I never saw that bug so cannot be sure. Slush < could you try it out please ?).
Scan of release checklist
do you have an idea when 0.5 will get out of beta status? would you say one could recommend it to a noob already?
I am considering writing a bitcoin quickstart page. multibit with encryption currently is pretty much the only thing I would like to recommend.
Hi subSTRATA,
The fees in MultiBit are very basic - just a flat fee. It needs beefing up for the cases you mention. It is on both Mike and I 's list of things that need sorting out. (The full fee knapsack algorithm is not done in bitcoinj yet which would be the general solution. As I am sure you know fee calcs are a bit complicated as adding another fee output changes the size of the transaction)
[...]
just keep it simple. fee calculation in the qt-client is way too complicated. The fees in MultiBit are very basic - just a flat fee. It needs beefing up for the cases you mention. It is on both Mike and I 's list of things that need sorting out. (The full fee knapsack algorithm is not done in bitcoinj yet which would be the general solution. As I am sure you know fee calcs are a bit complicated as adding another fee output changes the size of the transaction)
[...]
Yeah - it is a perfectly valid transaction to send from a wallet back into the same wallet. If you look at the transaction by doing a right click and do 'Show transaction details' have a look at the raw transaction. You typically see a transaction like:
Edit: better example.
You want to send 1 BTC to address 1ABC that is in your own wallet.
You consume an output on 1ABC that has value 2.000 BTC.
To address 1ABC, value 1.000 BTC (the amount you want to send)
To address 1ABC, value 0.999 BTC (the change)
Fee is 0.001 BTC.
When it works out if it is a debit or credit it nets the three amounts and decides it is a debit of 0.001 BTC. It is confusing when you see it as you expect to see the 1.000 BTC somewhere. In effect you have moved BTC from your left pocket to your right pocket and paid a miner for the privilege !
I guess you *might* want to shuffle BTC from one address to another in the same wallet but earlier up the thread someone suggested to put a little note 'you are sending to your own wallet' to catch the case where you accidentally choose the wrong address or do a cut and paste mistake (which would probably be more likely). I think this is a good idea to put it in.
Edit: better example.
You want to send 1 BTC to address 1ABC that is in your own wallet.
You consume an output on 1ABC that has value 2.000 BTC.
To address 1ABC, value 1.000 BTC (the amount you want to send)
To address 1ABC, value 0.999 BTC (the change)
Fee is 0.001 BTC.
When it works out if it is a debit or credit it nets the three amounts and decides it is a debit of 0.001 BTC. It is confusing when you see it as you expect to see the 1.000 BTC somewhere. In effect you have moved BTC from your left pocket to your right pocket and paid a miner for the privilege !
I guess you *might* want to shuffle BTC from one address to another in the same wallet but earlier up the thread someone suggested to put a little note 'you are sending to your own wallet' to catch the case where you accidentally choose the wrong address or do a cut and paste mistake (which would probably be more likely). I think this is a good idea to put it in.
Hi subSTRATA,
The fees in MultiBit are very basic - just a flat fee. It needs beefing up for the cases you mention. It is on both Mike and I 's list of things that need sorting out. (The full fee knapsack algorithm is not done in bitcoinj yet which would be the general solution. As I am sure you know fee calcs are a bit complicated as adding another fee output changes the size of the transaction)
The choice of outputs that are used I would have to look up exactly what the code does - I think from memory it issmallest first the general order of unspent outputs (ie no real order) but will check.
The normal number of nodes it connects to is 4 yes. To save on bandwidth it nominates one (at random) to do the full block downloads from but listens to the others for pending transactions etc. Because MultiBit does not relay transactions it is actually a burden on the network (as it takes up connection slots on each bitcoind it connects to but gives nothing back to the Bitcoin network. This is another reason not to 'overconnect').
The fees in MultiBit are very basic - just a flat fee. It needs beefing up for the cases you mention. It is on both Mike and I 's list of things that need sorting out. (The full fee knapsack algorithm is not done in bitcoinj yet which would be the general solution. As I am sure you know fee calcs are a bit complicated as adding another fee output changes the size of the transaction)
The choice of outputs that are used I would have to look up exactly what the code does - I think from memory it is
The normal number of nodes it connects to is 4 yes. To save on bandwidth it nominates one (at random) to do the full block downloads from but listens to the others for pending transactions etc. Because MultiBit does not relay transactions it is actually a burden on the network (as it takes up connection slots on each bitcoind it connects to but gives nothing back to the Bitcoin network. This is another reason not to 'overconnect').
Thanks !
I must admit I find it handy to send someone '£1' in bitcoin. Surprising how we have wired our brains to think in terms of fiat.
I must admit I find it handy to send someone '£1' in bitcoin. Surprising how we have wired our brains to think in terms of fiat.
Jump to: