Hey guys, that's just not fair that today many bitcoin-focused media are screaming about a "bitcoin alternative made in Go", that is planed to be released "soon", by some Conformal (whoever they are), while my yesterday's announcement has been completely ignored.

What is wrong with you? 
You don't believe me, that my software actually works? It really does - feel free to see for yourself.

Of course my implementation is not a "bitcoind alternative", but only because I am not a kind of person that would be spending his time trying to re-invent a wheel.
I mean: why would I need a bitcoind alternative, if I already have bitcoind?

So my implementation has not much to do with bitcoind, but instead it is focused on fulfilling my own personal needs, which might (by a chance) be similar with your needs - think about it.

And that is, for instance, why my node does not relay transactions.
I know that it is bad for the network, but I am very sorry for having only 1000kbps of upstream at my DSL, and so I am not going to waste 50% of it, plus lots of my CPU, just to relay your satoshidice bets. So I don't - and what can you do about it?

Another feature that I needed, and implemented it into Gocoin, was a cold deterministic wallet, that is based on a password-seed and thus does not require any backups.
My implementation is designed for such a wallet(s), which is of course an opposite of how it is made in bitcoind.

Moreover, Gocoin has an option to limit the bandwidth usage, which was also very important for me.
I do not know if you were checking the actual bandwidth that your bitcoin client takes, but all I can tell you is that my browser stops loading pages, when I have it running and you guys have just mined a new block. So for me a bandwidth limit is not a minor feature.

To wrap it up. I really don't understand why a news about an implementation of bitcoind in Go, that is supposed to be released in some undefined feature, happens to be so much more of a headline than a news about a Go implementation of a bitcoin node with some unique features, that can already be tried. I guess it's because I just don't know the right people in the theater...

Scale, read about it, plus if you had a bitcoind in the language you use most often, you can customize it more to your uses.

Show them your work. Maybe you can get a consultancy gig.

Awesome.  Thanks for bringing Go to Bitcoin.


Re: Go's special channel interfaces.  Any benefit for a Bitcoin client?

Sweet.  I'll take a look.


It would be interesting to see how Go's special benefits could be proven in a bitcoin client.

This is a reasonable, rational and admirable stance.

at least one

this seems a very good ideia. i really like your feature set.
i'm gonna to some more reading and digging around. Hopefully i'm going to try it out soon.

Thanks

A quick update for people interested in this project, if such even exist

Wallet
Considering the Android's RNG incident and the rumors that other systems might also be "NSA friendly", I modified the wallet app in a way that its security does not rely on random number source anymore. Note that it never had for private key calculation (since it uses deterministic wallet driven by a password-seed), but it did for signing, and now it doesn't even for signing.

Client
I ported sipa's secp256k1 lib (the 10x26 option) to Go. It is now a default option for ECDSA signature checks, so there is no need to struggle with C compilers anymore to get a decent performance.
It performs better than the openssl wrapper (so also better than your current satoshi client), though is still like 3-5 times slower from the cgo wrapper using an original secp256k1 lib.
The openssl wrapper is still there, if you prefer to use it (having a security concerns). Same applies for the native ECDSA lib, though this one is still deadly slow.

There were also some fixes around accessing maps from different threads that were not properly protected, which was causing memory leaks - this should be fixed now.

Plus plenty of other things, not really worth mentioning, like a new command to purge orphaned blocks from the database, or replaced block's gzip compression with snappy (performs much better).

Hi Piotr

Thank you for your work on this. I am trying it out, but getting an error on block 00000000000000560719da7088be587ea9c3018cfbbfae2dd2540682185c034b (#233046). It says:

.....
7474.8MB of data processed. We are at height 234765. Processing speed 10.507MB/sec, recent: 12853.3KB/s
7582.1MB of data processed. We are at height 235421. Processing speed 10.510MB/sec, recent: 10967.8KB/s
7710.2MB of data processed. We are at height 236155. Processing speed 10.541MB/sec, recent: 13109.1KB/s
7850.1MB of data processed. We are at height 236949. Processing speed 10.588MB/sec, recent: 14325.8KB/s
7958.2MB of data processed. We are at height 237625. Processing speed 10.586MB/sec, recent: 10700.6KB/s
8087.1MB of data processed. We are at height 238516. Processing speed 10.616MB/sec, recent: 13185.7KB/s
CheckBlock failed: CheckBlock: Block 00000000000000560719da7088be587ea9c3018cfbbfae2dd2540682185c034b hooks too deep into the chain: 233046/238760 000
00000000000e76cddac91bfdbf51a73f31ec740e07d651fba24f381289965

Do you maybe know what could be wrong. Im on windows 8, 64bit golang. I chose not to verify scripts.

Thanks ! : )