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

@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'..

Thanks for this. 

I'm not sure about the specific differences between bitcoin and litecoin protocol, but I don't see why it could not be ported.

I believe you can use the default litecoin-qt client and its raw transaction API to sing transactions offline (by another litecoin-qt).
https://en.bitcoin.it/wiki/Raw_Transactions

Unfortunately this probably still requires moving the entire blockchain from the online to the offline PC, since I don't believe "signrawtransaction" will work otherwise.
So (after moving the blockachain), you might just as well make the offline payment using the GIU and then "getrawtransaction" to get the hexdump followed by "sendrawtransaction" in the online to broadcast it.

Remember that your actual wallet is on the offline PC - whatever wallet you have in your online PC should not matter.
Just make sure to not overwrite the wallet.dat when moving the blockchain data.

I'm looking for a safe way to create offline LTC transactions. Could your client be ported to Litecoin to serve this purpose?
If not, do you know a way how to manage this?

Update on the recent development.

The last one (from October) was on version 0.8.0 - now we are on 0.8.5.

Wallet
* Can now decode and sign files containing raw transaction data (either hex-dump or a raw binary format).
* Is able to sign a transaction partially - only signing the inputs that it "owns" (knows a private key for).
* Checks for GOCOIN_WALLET_CONFIG environment variable (useful for a global config file).

Client
* You can include a content of another (watch) wallet inside a wallet file (use "@filename"), so you can have like a sub-wallets and a master wallet that includes them.
* Starting from 0.8.5 switching between wallets should be much quicker, since there is a monitoring (cache) of all the addresses that are not in the currently selected wallet but have been checked for a balance ever since the node was started.
* Inside the payment.zip (the one you download from MakeTx tab) there is additional file tx2sign.txt, which caries the unsigned transaction data - so you can e.g. sign it using a different wallet or give it to someone else for his part of a so-called CoinJoin signing.
* P2SH addresses should now be properly decoded (but that only matters when you view a transaction details).
* Some changes in WebUI's look & feel.

Privacy
* Now you can tell WebUI to broadcast own (locally loaded) tx only to a single random peer.
* Never broadcast own tx to peers that have not sent an inv to us.
* Disconnect peers that are not sending any invs (they are useless for us and might just be there to spy).
* The entire 129.132.230.0/24 network is banned, since I don't know what these guys are up to (sorry).
* fetchbalance (renamed to fetchbal) now supports getting the blanace via tor's socks5 proxy
* A user can setup his node to report any User-Agent he wants (the string that goes out in the "version" message).

have fun