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

There is a new alpha version of MultiBit that supports encrypted wallets available.
This is version 0.5.0alpha.

As this is primarily for people to test out, it is available only at:
https://github.com/jim618/multibit/downloads

There are the usual installers for Windows and Linux and a Mac DMG file. (install help - but use the 0.5.0alpha installers)

The readme.txt is important to read.
It is in the installers/ DMG file but I have included it at the bottom of this post too.

Your feedback is very welcome.


---------------
README.TXT
---------------

MultiBit 0.5.0alpha is a test version of MultiBit that supports encrypted wallets. Please try it out cautiously.

This is NOT production code yet so please read the following notes:

1) The encryption algorithm and/ or wallet persistence format may be improved between now and the production version. Any change will most likely make any wallets you create in MultiBit 0.5.0alpha unreadable by the final 0.5.x release. Older pre-encryption wallets will be read ok. It is just not worth supporting a wallet format that we intentionally improve on during the alpha test period.

It is recommended you create a test directory and save any wallets you create for testing in there. Then if the wallet format/ encryption routines change you can just open the wallets using MultiBit 0.5.0alpha, transfer the bitcoin out and throw the test wallets away.


2) There is a lot of new code that has been added to MultiBit to support encrypted wallets. New code usually means new bugs. For this reason I have temporarily altered the MultiBit build so that MultiBit 0.5.0alpha opens in 'portable mode'. It has its own startup file (multibit.properties) so that it does not open your 'real' MultiBit wallets.

At this stage do not put large amounts of bitcoin in the encrypted wallets just in case there is a bug that zaps your private keys. Do an export of your private keys to be on the safe side. You can probably use the testnet - see the configuration.txt - but I never bother and just use the production network with small amounts of bitcoin.

I have managed to zap my private keys a couple of times in development so please be careful!


3) Let me know if you have any problems even if they are difficult to reproduce or a little vague. Improving the code now may save someone's hard earned bitcoins in the future.


4) Caveats aside - I hope you like the new encrypted wallets functionality. :-)

genius! I vaguely remember an effort to switch fee-burden to recipient via protocol/rule changes. This is so much more elegant and less invasive.

Right. The way I intended chained txns to be used is that buyers pass free transactions to merchants/receivers. The merchant then decides as and when to attach a fee and get confirms. Therefore the only people who pay fees are those receiving coins across a trust boundary. If you trust the sender to not double spend, you don't need to attach a fee (or indeed broadcast at all)

In anticipation of an alpha release of the wallet encryption code, I have tweaked the installer code so that it installs MultiBit in "portable mode".

It loads up wallets as specified in a multibit.properties that is stored in the same directory as the install (rather than the MultiBit user data directory). This is so that your real wallets aren't exposed to the alpha code.

You can see what I mean if you look at the wallet path in this screen shot:




This only affects the 0.5.0alpha code (i.e NOT the download on the website) and I will remove it when the code is a bit more mature.
You will probably need Administrator rights to write wallets to the default install directory but you can always install it somewhere else if that is a problem.

It sounds like whilst it would not work at the moment, it would be handy technique for the future.

If the tx volumes increase I can imagine that the end user might want to send a tx "on the cheap" on the off chance that a miner picks it up. Then later you think, oh, okay I really need that confirmed now and bump the fee up to make it irresistible. It is almost a multi-round negociation between the sender and the miners.

Of course it makes things more complicated but I could imagine a right click on an unconfirmed transaction with a menu option "Increase fee to miner" or similar.

Miners don't do it. This is a suggestion I made some time ago and brought up again recently. Luke has implemented it for his pool and Gavin is working on something similar for the main software. Until that's done attaching fees via dependent transactions won't work well.

Hi Gavin,

Oh I see - chain a tx with a nice fat fee onto the one you want confirmed and a pool will pick the both of them to get both the fees. I did not know they did that but it makes sense from their point of view.

Thanks for the clarification.

That's not quite right.

The protocol supports it-- just take the output of an unconfirmed transaction (paying to you) and then broadcast a send-to-self transaction that uses it as input and has a big, juicy fee.

I think the Eligius mining pool might even notice and confirm both transactions-- Luke DashJr has a pull request to change the reference implementation's transaction selection code to consider fees for sets of related transactions when deciding what to include in a block.

jap, nice chart - for others interested: it's on http://bitcoinstats.org/ and announcement was here

I mean especially at very small transactions it hurts having percentage-fees, also I like using a pool not dropping transactions

another idea, also interesting for business-users I think - i dunno if already possible in bitcoinj

forward transaction/transfer
giving a transaction a time when the client shall send it AND the possibility to cancel it

and
multisend
stack some payments/transfers and send 'em as as one transaction (via gui!) to save fees


..yes, still dreaming of perfect user-experience

It is not calculated yet but that is the medium term plan.
Mike (Hearn) has it on his todo list to add to bitcoinj.

I will then show the recommended fee and I guess people will be able to tweak it at their own risk (but this would possibly involve adding another transaction input and hence the recommended fee!)

At the moment there is no way in the bitcoin protocol to 'add a fee to a stuck transaction' to entice a miner to pick it up which would be handy.

There is a good chart - bitcoinstats.com I think - which shows confirm times for transactions with and without fees.

oh - one still is forced to a preset fee?! or is it calculated..
why not chose-able 0-fee with warning for the user? that would be the most user-friendly I think :\ shure you already had the discussion..
although I appreciate fees as a miner at some point 0-fee will not be reliable any more

Ha ha - yes.

Initially I found it a bit of a chore putting my 'test hat' on and just working through a few simple scenarios but now I don't mind doing it. It is a good real world test.

Today for instance, I had my Linux MultiBit with the fee accidentally set at 0.0001 BTC. This is too low now to reliably get into the next block (which confused me until I realised what I had done). 0.0005 or 0.001 is the minimum now to get into the next block for small BTC transfers.

@jim

you forgot:
update-info in forums - check!

btw:
you're able to write?! I cannot remember not typing

There is a new release of MultiBit at:

http://multibit.org

Version 0.4.6

Enhancements:
+  Better handling of wallet versions from the future


Scan of release checklist

i have to add it was version 0.4.5 ..

I already read the hints in the documentation (found via website) and the problem wasnt csv (just renamed the export to csv because I thougt that might be the internal format, opened in excel and saved after sorting the rest out and deleting temp. data) as I simply copied the timestamp to every key incremented by 1sec - the single problem was file-extension had to be .key otherwise the client ignores the file (not showing up number of keys and the date) although I could select it after entering filename *.csv manually (I think dropdown all files also was available, but didnt help either) . so simply after changing fileextension it worked, and that was a bit odd to me ^^ .

another usecases not covered
delete single/group of selected key(s) from wallet
just for making a paperwallet I could use another wallet, but perhaps I wanna kill some keypair from the current wallet and keep the others without editing some textfile where I cannot identify the private keys due to missing public ones

move key(s) into another wallet
same as above, plus adding to another wallet before deletion

observation of public keys
perhaps one want so watch specific pubkeys .. e.g. the pubkey of my favorite charity or other known ones
(really was a question by user.. for now he was pointed to several website which he didnt like)

I can think more of using this for cold stored keys, thats why:
delete private key, keep public one
would make sense too - or simply make im-/export/deletion selectable if both ones or just private key


sorry for spamming users ideas, caint stop it as we just talked about this ^^

You mentioned that you originally started with a CSV file.
If your file is not being imported, it might be that the format of the private key export file is space-separated, not comma-separated.
The format is specified in detail here:
https://github.com/jim618/multibit/wiki/Export%20and%20limited%20import%20of%20private%20keys

Note that the createdAt date is in a specific UTC format too.

The problem is not selection of the file; i selected it - it just wasnt recognised.

no more I'd like

I do not see any problem - ok, it takes time.. if you can improve this, also ok. But for now I do not see a Tool "rescan chain (from date) ..."

nice ideas from your side, but I really also meant a custom layout of swatches (that could be saved or imported to some shop-system most easily) via some template for making it a better integration in e.g. shops. I imagine something smarty-like (popular with cms using php) as template and outputting them as e.g. html.
An example you showed up yourself: There is a video on youtube where you present the server-version with some made up online-shop (books) and the swatch breaks the layout there by outstanding over right border - such could be avoided by custom layouts. And like you already catched we do not need all as image but the qr-code. The key as Text we need more as text in in shops, e.g. to mark them (via js) or even copy (via flash as js aint allowed due to most browsers security model). Also this would enable to view information on certain gadgets in different form.

I appreciate more non-techies using Bitcoin - thanks also to your client

Hi vv01f,

RE *.key files only accepted.
The import/ export keys started out primarily as a way for users to extract their private keys out of MultiBit and reimport them back in hence the file filter was originally just "*.key".   I will put in a extra row for 'all files' like in the wallet open etc.
Edit: https://github.com/jim618/multibit/issues/43

RE: importing/ exporting single/ group/ specify text keys.
Those are good ideas. If and when I improve the key management side of things I will have a look at implementing those.

Because the blockchain (with all the transactions) is not stored in MultiBit the 'general import' of a key is not one of MultiBit's strong areas - because of the need to replay the blocks. This might change in future if and when Bloom filters are added to the server connection. (This should speed up replay).

It would be good for the user to be able to see/ copy the actual private key values (as text and QR code/ swatch) which I think is your last section's emphasis. I will have a look into this in the next round of UI work I do after the encryption goes in.

Thanks for your ideas.

i figured out for some friends how to import keys from vanity gen..
parsed them with excel and stored in csv again
why the hell is the import (client on win7) only accepting files ending on .key ?

request import single / grou of keys

I'd like some simple function to im-/export a single or group of private keys

I imagine export:
simple selection of adress(es) in the list then tolls/export selected key(s)

and import:
gibe some text field where I can paste some standard-encoded keys (and choose a date from when to recheck the chain, standard should be first block already stored)

swatch in custom layout including text

besides from that only one complain from user-side:
storing the pubkeys as swatch is nice, but the key also should appear in textform on websites - you could provide template-functionality (qr-code, swatch-img are provided via some variable) for custom layouts *edit: e.g. to avoid sth. like this glitch you presented: https://www.youtube.com/watch?v=MnkssdmlaWw#t=17m45s


have fun!

I thought I would give an update on the encryption work.
In the v0.5 branch I now have a version of MultiBit that is feature complete with the encryption i.e. all the UI work is done and you can actually send bitcoin, import keys, export keys etc for real with encrypted wallets. The wallets save and load.

There has been a lot of new code that has been added to MultiBit in the month of July.

• Number of lines of code at beginning of July: 25,000
• Number of lines of code now: 33,700

The test coverage (a measure of how much automated testing there is) has also gone up as I have written more tests:

• Test coverage at beginning of July: 15.0% (this is a bit low TBH)
• Test coverage now: 29.4% (getting better)

For comparison the bitcoinj project - which has a LOT of tests - has a test coverage of 56.5%


I am going to do a maintenance release of the production code (v0.4.6) probably tomorrow - that is the code on the multibit.org website - and then work on getting the v0.5 code good enough for an alpha release maybe by the end of the week. You will able to try the encryption functionality out for yourself. (There will be some caveats and 'alpha-code' warnings that I will explain at release).