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

I just said: this feature was pretty useless.
It wasn't adding any security and was a hell lot a hassle to use it.

I don't see why anyone would want to extract hashes, just to sign numbers instead of the actual transaction file.
And then, to make it even more convoluted, use another tool to put the signatures + pubkeys into the unsigned transaction, before broadcasting.
The wallet can do all this things together, in much more secured way, where you can actually check what you are signing, instead of just signing a meaningless number.
This feature just didn't make any sense to me.

BTW, the latest version of wallet also supports Litecoin (add -ltc switch)
The client node does not, but you can fetch balance of your Litecoin addresses from http://ltc.blockr.io using tool/balio
Then broadcast a signed transaction to Litecoin network using this page: http://ltc.blockr.io/tx/push (or the official litecoin's client sendrawtransaction RPC).

---

From other useful changes in the wallet, now you can just do:
.. to sign all the multisig inputs that the current wallet knows keys for. (previously you had to specify a specific signing address with "-msign")

Sorry I don't know what that message means, but recently I removed support for the "-hashes" and "-hash -sign.." commands.

This signing method wasn't adding any security and required a lot of hassle (e.g. playing with tool/txaddsig).
Moreover, it was not compatible with multisig, after I eventually added support for it at some point.

So I decided to remove this code from the source, because I find it important for the wallet code to be clean, readable and as simple as possible.
Maybe one day I will add it back, but for now it will stay disabled, because each new option complicates the testing.

But if you need these commands, just checkout some previous tag (between 0.9.2 and 0.9.14) and build the wallet executable from it.

Thanks Piotr_n. That's very helpful!

Oh, you mean the lock time.
Yeah, sure that should be easy to add.

FAIK, it's just setting the LockTime to a value other than zero.
You can do it yourself, if you like playing with source code.

Look inside wallet/signtx.go, function make_signed_tx() and change:
... to whatever you need. (like a value read from a command line).

I really encourage people to play with the code - if you are a programmer, especially if you did a lot of C, Go is a really cool language to code in.
I've been coding C all my life, but writing in Go is just so much more pleasant. And it compiles so quickly that at the beginning you cannot even believe it

Of course, there is a testnet switch -t and make sure to use it while you are having fun, to not be sorry at the end.


EDIT:
As for the lock time, I read that in order for it to work, you would also need to set this:
... to a different value.

The most basic application is to make the transaction not redeemable for a given number of blocks. While it's clearly not a feature that will be currently used by many users, there are applications being built on top of the bitcoin blockchain that can take advantage of such features.

In any case, it's good to know that the wallet can be easily modified to support different output scripts.

Well, you can put any kind of scripts into the wallet's code, but without a specific application (a user case), I don't see how I could add anything more.
So far gocoin supports the following output scripts:
* P2KH address (a regular bitcoin address)
* P2SH address (that's for multisig)
* NULL output describing the next one's encrypted constant (for stealth payments)
* NULL output with an arbitrary data (e.g. to attach text messages to transactions)
Adding other kind of output scripts is not really a challenge, but I need a specific application for it, before I can put it in.

As from the node's side.
Gocoin node (unlike bitcoin-qt) does not split transactions into "standard" and "non-standard".
As long as the fee per byte is sufficient (plus some other rules are met), it will get routed, despite of the content of a script.

EDIT:
Personally I think that dividing transaction into "standard" and "non-standard" has been a really stupid idea and I just cannot believe that instead of abandoning it they are just adjusting the rules of the standardness - that's crazy! It would be nice though to measure txs by how much CPU power they require to get verified - and then check the fee not only against the size, but also against the CPU required. But that seems like a too much advanced solution for the mainstream - it will take them at least 5 years to find out that this is an idea worth exploring

Thanks for clarifying regarding unconfirmed transactions.

What I meant about the scripts is to enable transactions that contain bitcoin scripts such as time constraints, and other bitcoin contracts as described here:
https://en.bitcoin.it/wiki/Contracts

I don't think I understand this question, so please precise.

But I have another answer to your previous question - times time a positive one

Actually, it is possible.
It just came to my mind.
The fetchbal tool - it can fetch unconfirmed balance.
And then, having your unconfirmed transaction in the balance folder, you can just use it on the wallet (it won't see a difference).

Do you have any plans to allow scripts in transactions?

cheers

Seems to compile now... Thanks

Thanks for reporting.
It must be specific for your libc, I cannot reproduce it here.
But I've just committed a possible fix - can you try now, please?

Otherwise you can always build it by overwriting membind.go (in qdb) with the one from no_gcc folder.
You just won't be able to enjoy the recent mem usage optimizations, but should build flawlessly then.

When building client or wallet:

membind.go:63: cannot use _Ctype_size_t(v.datlen) (type C.size_t) as type C.ulong in function argument

Wtf?
Make sure you have relatively fresh version of go. I'd advise 1.2 at least, though I think you rather have something pre 1.0

I was doing many changes today - could have broken something. If so, I'll fix it tomorrow.
But i'm pretty sure the last tag should build well, with a proper compiler.

code.google.com/p/snappy-go/snappy - it is some kind of weird URL that go uses to call mercurial.
I dont know how they do it, but it works.

Install Mercurial in your OS and then just execute:
It should call "hg" with a proper arguments, download the package and build it.

It works here.

Also, before "go get", you may want to set env variable GOPATH to point to some user folder (so you don't need a root access to store the files).

I tried to install snappy but the page doesn't exist:

https://code.google.com/p/snappy-go/snappy

Recently I have reorganized the entire repo quite seriously.
The latest tag is 0.9.13.
There should be some performance improvements, because I moved all the EC math to the internal lib, the one based on ported sipa's code (before only EC_Verify was handled by it).

I also added a support for the stealth addresses - feel free to check it out as well, it's a really cool feature:
http://www.assets-otc.com/gocoin/manual/stealth-addresses

As for the rest; kill me, but all I remember is that there were plenty of useful changes and the time was flying when I was making them...

Anyway, I think this code will soon become Gocoin 1.0.0 - finally.
But first I need to test it a bit more, because the recent changes were really huge.
Huge enough to frighten even me.
Still so far it looks well, but if anyone could help me by giving feedback on whether the latest code still works good enough for him, I will really appreciate it.
Just please don't rush it - let it work for at least a day, before saying that it's fine.

Also please be careful - there were changes everywhere, and that includes the wallet part.
Triple check your signed transaction, before broadcasting it, making sure that it actually does what you needed it to do.

Not in the current implementation - not without modifying the source code..

Unless it would be an unspent transaction that you made yourself, using gocoin.