Topic: MultiBit - page 69. (Read 336316 times)

thanks for awesome reply will look forward and make good deal and safe deal thank you once again

If people send you confirmed coins with a 'minimum or more' fee then you should get your transaction confirmation in a block or two.
(This is regardless of the client software you are using).

I guess the safest thing to do, say for large amounts of BTC, is to only release whatever you are selling when you see the usual 6 confirmations. If you get a transaction and it does not confirm then you are in the 'grey zone' where it could be a genuine delay (as I have described above) or it could be someone trying it on (i.e. the transaction is 'fake' in some way and will never confirm).

An unconfirmed transaction is a bit like someone signing the back of a cheque that someone gave them and saying:
 'This cheque will be fine - trust me. Now if you could just give me that gold bar you are selling me I will be off'.

In this case what you suggest me to do everytime before making any deal ? any information will be good for me thanks what should i tell to buyer and also take care of myself !

If you click on the amount that is 'Available to spend' on the MultiBit screen it takes you to this help page:

http://multibit.org/help_availableToSpend.html

It is the amount that you have in your wallet that has been confirmed by a block.
MultiBit only allows you to spend bitcoin that have been confirmed by the block chain.


If it took 3 days to confirm a transaction then the probably reasons are:

+ the fee for the transaction sent to you was lower than the minimum amount. (Eventally the bitcoin in the transaction 'mature' and the required minimum fee drops and then a miner includes it).
+ one of the amounts that the person sent to you used was unconfirmed and hence your transaction was only put onto a block when the previous transaction confirmed. Some of the other wallets, notably blockchain.info, allows you to spend bitcoin as soon as you receive it (i.e. it does not wait for confirmations).

The transaction confirmation is a bitcoin network thing, not a MultiBit thing.
I personally always set a fee a bit more than I have to to avoid my transactions getting 'stuck' in the system and then the recipient experiences the 'transaction takes ages to confirm' that you have just seen.

yeah it showing me available to spend: 7.3 what the hell is that i got BTC 3 days back and it is much time to get confirmation ! how can i solve this ? any idea mate ?

Mike Hearn mentioned that fees were pretty much at the top of his list of TODOs for bitcoinj so I will track that development. That should enable me to work out the minimum fee for any given transaction and both simplify things and make confirmation by the miners more certain.

It is a bit complicated working out the fees, not least because to pay a fee you might have to add another transaction output to pay for it : but that changes the transaction and hence can change the fee !

Or you can just go to preferences and change it inside the actual program.

+1
Or better yet: allow to edit the fee per transaction, i.e. in the Send dialog (with the default fee, or a dynamic value depending on the transaction size, pre-filled in).

By the way, you can already change the fee manually. Closing MultiBit, edit the file "%appdata%\multibit\multibit.properties" (or the equivalent on Mac or Linux) and look for sendFee=xxxx.


Hmm strange, I personally even tried a fee of 0.0001 for much larger transactions and didn't experience any problems.
Is it possible you still got some of your coins pending? (does it say "available to spend: 7.3" or something?)

i have 11.6995 BTC in my wallet but when i click on send it asked me for 0.0005 fee so i reduce amount to 11.6990 or 11.6980 but i can't send Sad multibit allow me to send only 7.3 BTC right now donno why ?? i got BTC few days back please help me out how can i make this transaction happen

Thank you !!

Feature Request:

Dynamic Fee's based on the transaction size.

Reason being, smaller transactions get quickly confirmed even having a 0 fee, while others, like the one I'm waiting for

http://blockchain.info/tx-index/aa4ddd098dd12d58b26ab8e9f452e4be1937f32106e72944b0b489bbe5aa6935

don't get confirmed quickly, even with a 0.0005 fee.

Mainly in preparation of the wallet upgrade utility I will be writing, I have added a 'Messages' screen to MultiBit.
All the messages that were being put on the statusbar now also go to a store and appear on a screen thus:



It gives a bit more visibility to what is going on.

At the moment it just does 'local' messages but in the future I would like to add the Satoshi network message notifications and also MultiBit specific broadcasts (new versions, emergency announcements etc).

Hi Kazimir,

The wallet storing and loading is isolated in the code so it is very unlikely that an address would be displayed as one thing but actually be another as a result of this change.

Exporting the private keys and putting all of the export file, the wallet file (yourName.wallet) and extra information file (yourName.info) somewhere elsewhere would be a good safety measure before upgrading yes.

I trust the risk of accidentally sending transaction to wrong destination addresses is non-existent?

Cause for insurance reasons I'll just export my private keys and keep them safe, separated from my MultiBit wallet dir. So even if it totally corrupts my wallet or whatever, I could still switch back to the previous version and reimport the keys.

(P.S. sounds like a great improvement!)

Looking for guinea pigs (bleeding edge testers) !

Hi All,

I have just started upgrading MultiBit to use a new format for the wallet, called protobuf.
This format is a lot more compact than the previous one and is more extensible so will make it easier to add features in the future.

In a test I did today an old wallet of size 1.7MB is now only 12KB which is quite an improvement. It is actually the format Google uses for the majority of its machine-to-machine chatter. It can also be read easily by C++ and python code.

Because it is people's BTC we are talking about, I would like to have a few guinea pigs to try it out beforehand to make sure the migration process for the wallets works with zero problems. Obviously this is in addition to the testing I am doing as I work on it.

The testing should be a matter of:
1) backing up your wallets
2) installing a new version of MultiBit (from github, not off the multibit.org website)
3) starting up MultiBit and checking that everything works (send, receive a few transactions etc).
4) stopping MultiBit.
5) restarting it to check all the wallets load ok.

That is pretty much it.

Older versions of MultiBit will not be able to read the new format so it is important it works properly. (I will be putting in an automatic wallet backup in the old format just to be safe).

If you would like to try out the new beta version (which will probably appear later on this week) please post here.  Please also post if you are Win/ Linux/ Mac so that we get good coverage of operating systems. I program on a Mac but it would be good to have independant testers for all three.

Thanks in advance.

Thanks for the clarification Mike.

Pending transactions are written to the wallet. When a new peer connects all pending transactions are announced to it (in the latest versions). So that "queue" already exists, it's in the wallet itself.

I think that code may have been in 0.5, don't recall. So it may require a multibit update.

Hi Kazimir,

Thanks for your suggestions - if I go through them one by one:

1. Good idea. It could go as an extra column in the list of receiving addresses. You would want it optionally on though - it is quite easy to overwhelm new users with too much information.

2. This is actually a bit tricky to implement as a private key might be used for several of the transactions in a wallet - the receipts are ok but with the spends the transaction outputs for the the private key might be used in various transactions. Imagine trying to unpick a web to pull out a particular node.

There is potential to do things like merging wallets but to pick out a particular key from its 'brethren' when you have transaction connecting them all together would be confusing in practice I think.

The export/ reimport keys can also be confusing to people not familiar with the concept of private keys as you can easily get into the situation where the same key is in two wallets.  You have just doubled your bitcoin !   Well of course you have not but for the lay person it looks like you have.

It is a bit of a balancing act to make bitcoin 'look' like regular money and hide away the technicalities.


3a. This is what I am planning to do - encrypt just the private keys so that you can receive BTC and see all the transactions even when the wallet is password protected. There will probably be a password field in the 'Send Confirm' screen, maybe with a timeout so that you do not have to keep entering it everytime.
3b. Yes, this is the plan - one password per wallet.

4. There is definitely potential to improve the UI be able to specify the send and change addresses yes.

5. If you are willing to do a bit of file copying you can do this already: http://multibit.org/help_runFromUSBDrive.html
I would like actually to have a MultiBitPortable which adheres to the PortableApps.com specification so that it can be used in their app launcher. I have looked at the spec and it looks doable but of course it takes time to get it all working and get the build to produce the artifacts etc.   

Relative path support for wallets is a good idea yes. Will look into that.

RE: signing transactions. Bitcoinj (the library behind MultiBit) already has separated out the steps of signing and transmitting.
I am sure there was some discussion on the bitcoinj mailing list about enhancing the network layer to retransmit transactions if the network disappears but I am not sure what the status of it is.

To be honest Armory is doing such a good job of offline transaction support I am concentrating on other areas (there is only so much one person can do.   :-) ).   I am concentrating at the moment on backend improvements, the wallet encryption and a conversion of the wallet format so I expect it will be a while before I get back on pure UI improvements.

Thanks for the input - it gives me ideas for where improvements can be made in the future.

Cheers

 

Oh and while I'm at it:

• 5. Make MultiBit portable, i.e. having a data dir relative to the executable, rather than relying on %appdata%\MultiBit (or the Mac and Linux equivalents of that).
  And in the multibit.properties settings file, allow relative paths (relative to the properties file) for example ".\Wallets\mycoinz.wallet" would refer to a "Wallets" subdir inside the same dir where the .properties file is located.
  
  This will improve security: malware cannot simply scan %appdata%\MultiBit and find references to wallet files. There is no specific path or location where malware can start searching.
  And it also allows MultiBit to completely run on an encrypted location (e.g. truecrypt container). Or from a USB stick. Or both.
  
  Running from a USB stick is quite useful actually: I can choose to only mount it when I need to do some bitcoin business, and together with feature 3b above I could easily access my wallets and just send small transactions from my spare change wallet on my regular PC. And for rare transactions from my big fat savings wallet, I connect it to a separate ultra clean maximum security dedicated bitcoin laptop, and I will only ever enter the password for the savings wallet there.

Also this comes to mind: when MultiBit signs a transaction, does it need to send that transaction to the network immediately, and otherwise it fails? Or could it also sign the transaction (this is the only part that actually requires the private key, and its password it it's encrypted) and then store the signed transaction in some queue to be sent to the network. Normally this occurs instantly (it's being sent right after signing) but in the above scenario, I could also sign transactions on a dedicated ultra secure machine which is never connected to the internet and then later mount my MultiBit USB stick on a normal PC to actually send them to the network.

Some feature requests / suggestions:

• 1. Ability to see how much bitcoins are on each individual address.
  Of course I can do so manually through http://blockchain.info/q/getreceivedbyaddress/MyAddressHere but it'd be nice to have an easy gui feature for this. An extra column or tab or something.
  You might wanna make this optional cause in a way it's 'extra clutter' that may confuse people.
  
  
• 2. Ability to move addresses to other wallets. E.g. select one or several addresses, then right click → move to wallet → New / Wallet 1 / Wallet 2 / etc.
  If you move all addresses out of a wallet, offer the option to delete that wallet, or to auto-generate a new address in it.
  (What would happen if you 'split' two addresses that have been in a single transaction together before: uhm, I guess the same as what happens when you export their private keys and import them to two separate wallets)
  
  
• 3. Encrypted wallets. I know this is already on your wish list, but two extra considerations:
  
  
  • 3a. Only requesting the password to send money (i.e. to sign a transaction), not just to open the wallet and see its contents.
    (Well in a way this is kinda obvious so maybe you were planning to do it like this already, just mentioning )
    
    
  • 3b. Different passwords per wallet. This allows for an "everyday wallet" with just some spare change, and a "savings wallet" with tons of bitcoins, for example.
    The idea here is to enhance security, by spreading the risk so to speak. Even if your system is compromised with a keylogger or whatever, as long as you are paying with your everyday wallet they still won't be able to access your savings account.
    
  
  
• 4. Advanced option when sending payments: ability to specify to what address the change is being returned.
  

Hope this helps! I ♥ MultiBit

Hi Kazimir,

Yes that should work.

The current wallet format is a bit 'bloat-ey' yes. It only contains keys and transactions but not in a very compact format.

The underlying library I use (bitcoinj) has a new wallet format that is a lot more compact (based on protobufs - what Google uses for its machine to machine chatter) and I will be moving to this format probably over the next month or so. That should trim the wallet sizes down quite a lot.

(The format change should be transparent to people).

To keep the label information backed up make sure you copy the .info files (stored in the same directory as the main wallet file) as the labels are in there at the moment.


Preserving anonymity
If you have an address that is publically linked to you (a donation address say) then you can improve your privacy by having two wallets:

+ A 'public' wallet with the donation address in
+ A separate more anonymous wallet with a completely distinct set of keys in.

If you make sure you fund the anonymous wallet "anonymously" then the two sets of transactions in the separate wallets will be completely unconnected.

You could then back them up with two separate private key exports.