I have a slightly different question, but since there are some real math experts in this topic already, please let me ask it in here.

I need to write a function that recovers a public key from ECDSA signature.
It's the algorithm described in section 4.6.1 of the SEC1 spec - it seems simple, but I guess I am just too stupid to get it

Let's say that we have a signature of:
The 1st byte of this signature is 0x1F, but I don't think it matters at this stage. Actually it does a bit, since it says that bit(0) of Y is 0.

So, the operation I need to do first, is the equivalent of openssl's ec_GFp_simple_set_compressed_coordinates().
It takes X and the parity of Y, and returns some point R - right?
From what I see the actual result, for the example inputs, should be:

Could anyone please tell me how to calculate this R, preferably with some example, in python or whatever..?
I was trying to reverse engineer how openssl does it, but analyzing that code has not got me too far, so far...

Also, if you could please explain me what is an "octet string" and how is it different from a big integer expressed as MSB encoded string of bytes?

They were. Another thing that I found very useful were maps.

Of course - it would be a huge waste to not use such a great feature, and also go routines...
Though not really so much of it, at least at this stage.

If you grep the sources for "chan" or "go", you can find the places.

Thanks for an advise, but I am doing well, not working for a corp that cuts a large part of my work's fruits, to pay for their stupid marketing, just so stupid people could be jumping up an down...

Just a "thanks, I like your client and I actually use it" from a random person - that's all I need as an incentive for my work.

Yeah,  MARKETING – whatever, man.

Both; for the mankind, and for me, marketing is even more useless than re-inventing wheels, so let me just stay away from it, OK?

In the meantime, if you had any questions, or a feedback, about an actually working first bitcoin client written in Go, you know where to find me.

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

If anyone is interested in my original implementation of a full bitcoin client, feel invited to try Gocoin.
Having been disappointed with other alternative implementations of a full bitcoin node you maybe have seen, please be assured that this one actually works!

Pre-compiled binaries for Windows and Linux (amd64) can be downloaded here: https://sourceforge.net/projects/gocoin/files/?source=directory
They are usually not up to date as in general I provide no binaries, but building the client using Go compiler is quite easy and (unlike other bitcoin clients) this one builds in a second.

The project is open source and the code is available at GitHub: https://github.com/piotrnar/gocoin
To build the sources, just follow the instructions from README.md.
Ask if you'd get stuck, but it is pretty straight forward, so you probably won't.

You can find the official webpage of the project at: http://gocoin.pl/ - there is the User Manual and a lot of other info.

There is also a wiki article: https://en.bitcoin.it/wiki/Gocoin although it hasn't been updated for awhile (feel welcome to contribute to it)

---

Note: the info below refers to Gocoin version 1.8.0

General info

• There are no known consensus incompatibilities. Gocoin's consensus lib passes all the recent transaction & script tests (from the core's repo). Gocoin's node passes all the blocks test from TheBlueMatt's test scripts. The node has (an optional) functionality to (cross-) check each new transaction with the core's consensus lib.
• The solution is fully functional, but I like working on it, so please keep in mind that the HEAD is a work in progress and will probably always be. The source code gets tagged regularly, so if anything does not work for you with the latest version, try the previous tag. The database format is not supposed to change.
• You do not need the client (node) in order to use the wallet. In such case use balio tool to fetch the balance of the addresses you own, in order to spend your coins (read more here).
• Works with testnet, so you can start your gocoin adventure from it (use "-t" switch at the command line, for both client and wallet).

Client (the online bitcoin node)

• Has a web interface (WebUI), by default available at http://localhost:8833/ (to access WebUI from a different host, you have to modify the config file first).
• The entire UTXO database is kept in system memory, to maximise performance of verifying transactions and blocks.
• From version 1.7.0 the node monitors balance on all P2SH and P2KH addresses allowing to check (or fetch for spending) the balance of any random address. The wallet's addresses aren't kept in the node's memory, but only in the user's browser.
• The blocks on your disk are compressed, which saves 20-30% of space (comparing to bitcoin core). Additionally there is a tool called bdb that can purge old blocks from the database.

Wallet (secure your money offline)

• It is a separate app meant to be used as a deterministic cold wallet (on an offline PC), though if you don't mind the risks nothing can stop you from using it on the online PC.
• Is console only, does not have any graphical user interface. Any operations on the wallet are driven by command line switches. You can put some defaults in a config file.
• Has very low system requirements (tested working on Raspberry Pi Model A).
• The wallet's security does not rely on any random number source.
• The wallet's private key pool is based on a seed-password, so as long as you remember it you don't need any backups (some people call it a brain-wallet).
• Since the seed-password is basically a straight forward private key of your coins, make sure that it is complex enough and that nobody is able to peek at it.
• If you don't trust your brain to make a password strong enough, use a randomly generated string (e.g. cat /dev/urandom | head -c 20 | xxd -p) as the seed-password.
• By default the wallet works with a pool of 250 deterministic addresses (you can change this value, if you need more).
• In addition to the deterministic key pool, you can import raw private keys generated elsewhere (they need to be in the base58 format).
• Supports (partial) signing of multi-signature transactions.
• Supports Litecoin (allowing spending of litecoins with balio tool).

I prefer 2+Y.Bit(0)

thanks

Sorry for maybe a stupid question, but I have a need to make a reverse operation; compress a key.

So, how do I decide whether to set 02 or 03 in front of the X?

Hehe, nice price

The only explanation that comes to my mind is that it was a wrong price value returned by mtgox API.
Unless your Chrome has problems with parsing JOSN, or floats - but that is less likely.

Whatever was the reason in this specific case, mtgox definitely needs some fixes in their API.
For instance, this url: https://data.mtgox.com/api/0/data/getTrades.php?since=1366455600000000
... should give you some list of transaction, but ATM it just gives an empty array.
But  if you do a slightly different one: https://data.mtgox.com/api/0/data/getTrades.php?since=1366455600000001 - then you get the list.

I believe these are some side effect of them using clouflare for the API distribution.
The bot suffers from it, but unfortunately I cannot do much about it.

excuse me?
there are bugs in the original implementation - and that is why your mod does not work, while the original implementation does...? 
yeah, that makes a lot of sense...

if you find any real bugs, just let me know - I'd be happy to fix them.
but what you've just said is just a baseless insult, and nothing more.

You are welcome. Glad you like it.

As far as I am concerned, the times should be shown only in local time, not in GMT.

Please keep in mind that this was only a proof-of-concept project and since I do not use it myself, I do not plan to add new features, because testing it would need my time, which I cannot afford these days.

But if something stops working I will fix it - just let me know.
It happens because MtGox has a tendency to change their API without worrying about backward compatibility, and usually even without any notice.

Cheers!

A compressed public key contains 02 or 03 at the fist byte, followed by 256-bits of the X.
https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm

How do you calculate the Y, out of it?

I see that the client just calls EC_KEY_set_conv_form with POINT_CONVERSION_COMPRESSED, but since I need to do it in an app which not use OpenSSL, could anyone please refer me to some doc/code explaining the math behind this process?

Someone reported to me that the bot stopped working. I do not use it myself, so I did now know.

Anyway, I think I fixed it - you can update from the web store. You will need to accept new permissions, though.
I did not check if the trading API still work, but getting balance does, so I assume that trading should also work.
If not, please let me know.

I usually compile the client myself since I often have some small patches which I like to use.
I've always been shy to submit any poll request for such, mostly because I'm not really sure how welcome they  to be, and nobody likes being rejected

Let ma give you some example.
From time to time I get requests from people I know who have problems with their wallets and so they want me to fix it.
Usually it's because they used to work with several wallets at the same PC, and so they ended up with transactions that have only a question sign, and zero confirmations...
Normally I just tell them to use the "-rescan" option, but sometimes it doesn't help, because the transaction they have in the wallet was somehow a double-spend, and then the only way to fix their wallet is to remove all the transactions and then do the rescan.
So I have this simple patch in init.c, which goes like this: As you can figure, it basically removes all the local txs from the wallet, if you use both "-rescan" and "-purgetransactions" at the same time.

So: would it be useful enough to bother with a pull request?
And if it would - do I need to add some test cases for it, or what?


Another example, though a bit more complex, would be a possibility to use * as the <fromaccount> for sendmany command.
It's just weird that you cannot specify "any account" there, and I have an application that really sucks because of it.


If such a simple patches are be welcome, I'm more than happy to create some pull requests for them, but if not - no problem, I will just keep patching them in myself.
So please let me know what you think.

But the real world is not as perfect as it should be.
It's all about statistics and chances - probability.

If you have X connections from your node to the network, and you broadcast transaction A to half of them, while at the same time broadcasting transaction B (spending the same 1000 BTC) to the other half - then you have a significant chance that both; A and B will be mined in the alternate branches. And by "significant chance" I mean: significant enough to cause the panic...

I would not mind it, either.

Whatever the community decides, I'm fine with it, as long as it solves the issue of transactions with proper fees waiting hours for the first confirmation.
The network really seems to be getting stuck already and I don't think it will just get better by itself.

Yes, you are right.
I am not saying that it was easy - and that is why we don't know about anyone who was able to take advantage of it, during the incident.
But it was definitely possible - and thus the panic.