Topic: Gocoin - totally different bitcoin client with deterministic cold wallet - page 8. (Read 38679 times)

You're welcome.

Coming back to a malware that would eventually be able to attack the offline wallet.
The only path I see, except exploiting the OS, is some kind of stack-overflow exploit that would be smuggled to the wallet PC, inside one of the balance description files, or the raw transaction file.
If I had screwed up something (which isn't unlikely), the wallet app may crash while parsing a corrupt file, especially if it was corrupt by design...

Though I am not aware of an existence of any possible stack-overflow exploits for software written in Go.
AFAIK, Go's framework is more like Java, having a quite restricting memory manager and thus making a possibility of stack-overflow exploits very unlikely.

But nothing is impossible and I have seen many things in my life, so thanks for your valuable feedback @Tovadnok - it's been taken with a seriousness it deserves.

Thanks, Piotr_n.

I agree that the fact that hash can be substituted by an attacker on the online machine is still a problem. I'll try to think of a way around this issue.
Overall, I think your client probably has the most secure design out there.

I totally don't understand how anyone could develop a malware that would be able to copy itself unnoticed through a several different systems.
The only way stuxnet could spread in the first place was through a 0-day exploit, for which only Windows was vulnerable.

But well, you wanted a functionality to sign a hash - here it comes, though as I had said it isn't quite secured and there is plenty of hassle with it.
Anyway, it is already committed into github - comes with version 0.9.2.

Here is how to use it:

1.
Having the payment.zip created at the online machine, extract it (on whichever machine you want) and being in the payment folder execute:
This will print a hash that needs to be signed and the address that it shall be signed with - one pair for each of the transaction's inputs.

2. Now, on the offline wallet machine, execute such a command for each of the pairs:
Each of this commands will give you a hex dump of the public key and the canonical signature.

3. Now move the key+sig pairs to a PC where you have the unsigned transaction (tx2sign.txt) and use the tool called txaddsig, for each of the tx inputs executing:

The file created after the last step shall contain a fully signed transaction. Before loading it to the node, for broadcasting, you can decode it's content with:

Hi Piotrnar,

I'm not sure that copying several times, using non-root users, etc, will solve the problem. The concern is that someone will develop a new malware targeted specifically at your software. It can then exploit whatever vulnerabilities are currently available and will not necessarily use the same techniques as stuxnet.

Your idea for using a really small storage device makes a lot of sense. That's essentially what happens if a human types the data in -- you're using a very low bandwidth channel.

If you are worried of stuxnet-like malware, just copy your file several times on the way - using different devices, with completely different software.

These days there are plenty of embedded devices (cameras, GPS systems, media players, etc) that can copy data to/from USB disks or memory cards.
No way anyone would be able to create stuxnet-like malware that can infect each possible system.

Basically you can think of many kinds of countermeasures to protect this channel - copying the data at least once on its way is just the first one that comes to my mind.

It is a good idea to not have any GUI at the wallet machine, because AFAIK the stuxnet was infecting windows using an exploit in parsing shortcut/icon files, or something like that...
In other words: make sure to use a system which does not read any data from USB, except the one that you explicitly ordered it to read. Then an infection is pretty unlikely.
And also don't use root/admin account at the wallet machine - this makes infection even less likely.
You can even use an entirely read-only file system there, e.g. by booting it from a CD or a write protected USB medium.

Another trick could be to use a very small medium. For instance if you had a disk/diskette with only 16KB capacity, that should be enough for most transactions, but it's extremely unlikely that any malware (capable of stealing keys from your offline wallet) would fit into it.

@piotr_n you're right about the fact that the has could be modified. That's a very good point.
However, I still think that transferring transactions via a USB drive is very risky.

If bitcoin is valuable, stuxnet-like malware may emerge that travels to the offline machine through a thumbdrive, and then travels back on the same thumbdrive, this time carrying your private keys with it. Once the USB drive is re-inserted into the online machine, the private keys are sent out to a malicious server.

I do think that your software is pretty much the only one out there that one person can read the entire code base and convince themselves that it does what it claims to do. This is a nice side effect of Go.

I guess the real problem to solve here is how to make the transactions themselves transferable to the offline machine without risking compromise of the offline machine.

Awesome client! You did great job! Thanks a lot for making this really cool bitcoin client 

After all, giving it more thought, it seems kind of tricky and I am not sure anymore about an actual usefulness of such a feature.

First of all the Gocoin's security assumes that the online machine is not secured.
This implies that the hash that needs to be signed, since created on the online machine, may be a subject to an attack, giving you a value that describes a different transaction.
That is bad, because having just the hash you cannot verify the content of the transaction at the offline machine, before signing it.

Second thing is that you would need to sign as many hashes, as there are inputs in the transaction. And moreover for each of the hashes you would need to manually specify the actual signing address that shall be used.

And then at the end, having the signature already (and the public key), you need to assemble this data back into a signed transaction, before broadcasting...

That is really a lot of hassle - just typing in the digits seems like a huge waste of time.
So I really don't see anyone using such a complex and unsecured system.
You really want to verify the actual content of the transaction that you are about to sigh at the offline machine, because this is a crucial part of the wallet's security.

That's a great idea, @Tovadnok - thanks!

I will look into it, as soon as I'm back from holiday.

Just a suggestion:

When creating transactions on the online machine, it would be great if it was possible to obtain the hash that needs to be signed directly instead of the transaction zip file. Then, a human can type it in on the offline machine, and then type the signature value back on the online computer.

This removes the need to plug usb drives into the offline device.

you probably have wallet.cfg and it is configured to use testnet
just set it to false or remove wallet.cfg - the default is non-testnet for all I know.


EDIT:
oh sorry - my bad.
it was the wallet.cfg that I committed  to github that has "testnet=true"
I have just fixed it.

Thanks for reporting!

Hi, when I run

> ./wallet -l -v

and enter 1234 as the passphrase, I get the following addresses:

mtMzKRALsjU3QUW9f7mrNdFkKuR32rRVJk TypC 1
ms8dDiiQh92J13Sb5FGxTcLbxfeyKTXAkT TypC 2
mjUi7buZNg93whuD1qeohVm7TKeBgs1G8E TypC 3
mhYcRqxfUJkEMCNQXPZueCJpnWxuGg3m7k TypC 4
mgrkKPPFUppG9WNySxiYtPA77yPVQk4x9j TypC 5
muTGvkfyRDQ1n5otCqukPK5RX1Spnyf5qG TypC 6
n3AgSXhgVt4BuunbzLhjc2bKbdxHmUkGET TypC 7
mzvpZH8jhgYs5JGHSF7HZBnvYudP8xQwWa TypC 8
mofUnUzEJDFNHfhbY51sqRqzKARWbwuEhr TypC 9
moJ4HS4NYtDRd9KqeG282qferp4kXHbbDH TypC 10
mkTDZxJTM6oR88zTtV1gWE6qNnEQvxT5wD TypC 11
mzKNtwNaeScnY71zFqghA69iTTgZX5gh6b TypC 12
mw1JJpDtTLRdkC7akZoYt15wsSifGP89vf TypC 13
moUuYTsFA69LAuwyVSNKJiHrTkGp5XPmPm TypC 14
mpA8fNq4Qt6gd3sPNvoFne85wz7KHHsUb7 TypC 15
mxF4F2V1ySQMrR1tdsA4u5fQdmDdaVgiW5 TypC 16
mgstWQteoRTQnkAMXU2viRmHu1AYXHbBx8 TypC 17
mzkhGFopVmfeLAw84YcVx3uZgfbo3XYmGR TypC 18
mjivnvukgajoHCmJ55dXh1QyN84WhVEVD1 TypC 19
muGkLzrQ4CrBo91ecMdkcjbET4LmB6aYPw TypC 20
mnjxHuncYvNNzr71T1gTKqUE17jHMjUHqz TypC 21
n48TXP4PiRy9wDcZJFKFNNYnPgkss2WAb1 TypC 22
mjX8qm14PQntBqwa2AazzA58hqccpzmHit TypC 23
mgJJQ5QPWYqB1p1KauNtEZUawqBL7JURU5 TypC 24
n26Ncr3fKHNTsANMi1cdDfB4uNyxvXKs7A TypC 25

These are not valid bitcoin addresses. What am I doing wrong?

Getting advantage of the recent malled transactions hysteria (not that I'm behind it), I'd like to use the opportunity to advertise my Gocoin client as a wallet that is 100% resistant for this kind of "attacks". Gocoin really doesn't give a shit of whether anyone wants to alter its transaction before it gets confirmed or not - feel free to alter them all you want!

So, since apparently there are some ongoing disturbances in the network which affect the official wallet, if you don't want to be exposed to them, just know that there are alternative wallets, for which thins kind of problems don't even exist.

To be honest, myself I don't even see it as a problem - and MtGox should be really ashamed that they caused so much panic by literally claiming that there is a problem with a bitcoin protocol. The only problem there is, is inside a lame implementation of the MtGox software. Shame on them, BTW.

0.9.0

The version 0.9.0 (after 0.8.5) brings performance improvements to the block chain parsing.
If you do "client -r", forcing it to re-index UTXO database, it should go much faster now (like below one hour to re-build the entire UTXO DB)


Block-chain downloader

Additionally I created a new tool called downloader.
It speeds up the initial block-chain download, even to one hour or less, depending on your internet speed and performance of your PC.
The main trick is to skip verification of scripts, up to the "trusted" block. Normally the trusted block gets discovered automatically, but to improve security you can use a command line switch, like e.g.:
This would assume all the block up to #282757 as trusted and only all the scripts from further blocks will be verified.

You can also download the blocks without even applying their content to the UTXO database. In such case just use "-b" switch. Then you are basically limited only by the speed of your internet connection. If you do it this way, the UTXO database will be automatically rebuilt after you start the "client" with the new content of the blocks database. As I had said, the full re-indexing usually takes below one hour now, though it does need some system memory, so I recommend at least 8GB of RAM these days.


Other changes

As always, you can see more detailed list of changes/fixes in the README.md


Open issues

Nobody reports any issues, so either nobody even uses this s/w (weird since the github repo already has 68 stars) or you find no issues.
And if you find no issues than you either suck in testing, or this is a really good piece of software
But I also find no issues (except of the ones I fix on daily basis), so who am I to blame you anyway..


Road-map

As for the future of this project.
I have been thinking hard about the part that would need an improvement the most and IMO that would be the UTXO database engine.
The one that I use now, I made myself, but it takes a hell lot of memory and the occupation of the disk is also far from being optimal.
But currently I do not really have any breakthrough idea in how to move it on, maybe except re-writing it from Go to C, which should at least let me to save system memory, though without improving the disk usage.

So if anyone had an idea on improving the UTXO DB engine, please share it - I will surely take it seriously and you can keep the credit for inventing it.
LevelDB is out of the question - I need to be able to browse through all the UTXO records as quickly as possible, so the entire DB index needs to always be in the memory.
Otherwise (if I loose performance just to save memory), it would not have been an improvement to me.

I don't make things that I don't use, so I will make it if I only need it one day.

Can you make it to a multiwallet (you can store different coins not just bitcoin)?

The parts that need to be different for the altcoin of your choice.

If you want a specific answer I'm gonna need a specific question.

Can i use this for any altcoin? If yes what i need to modificate?

nee. sathoshi was a genius - I'm just writing code.
though, I see where you're coming from; the reference industrial benchmark for a development of a bitcoin software is so weak these days that my hobby looks like a master performance next to it
but the truth is that there are thousands of kids out there who can make code even quicker - most of them are like half my age and I would not even dare to compete with them, unless on 'who has a bigger mouth'..