bitcoin miners in go

[josvazg]

Does anyone know of any bitcoin miner written in go?

I guess it would be very slow anyway, unless it gets access to C/Assembly code, especially on a GPU.

Thanks in advance!

Jose

[Andrew Gerrand]

On 4 April 2013 16:47, josvazg <jos...@gmail.com> wrote:

Does anyone know of any bitcoin miner written in go?

I guess it would be very slow anyway, unless it gets access to C/Assembly code, especially on a GPU.

There's no point. Even GPUs are getting too slow to sensibly mine bitcoins. These days the market is going to custom chips.

What would be more interesting is bitcoin wallet software written in Go.

Andrew

[Donovan Hide]

Change the request to Litecoin miner and it gets a bit more interesting :-) The current surge in price of Litecoin has all off a sudden made CPU mining of that cryptocurrency worthwhile, although when ASIC's do arrive in force in Bitcoin land, I imagine a lot of GPU miners will move to Litecoin and push the difficulty up further...

The interesting point is that Litecoin uses scrypt (which is partially memory-bound) rather than SHA256 as its proof of work. Go seems to have a pretty good scrypt implementation. It would be a great benchmarking exercise to port/rewrite cpuminer in Go and see if it can mine as fast, if not faster:

https://en.bitcoin.it/wiki/Litecoin#Scrypt_Proof_of_Work

https://code.google.com/p/go/source/browse/scrypt/scrypt.go?repo=crypto

https://github.com/pooler/cpuminer/blob/master/scrypt-x64.S

Another interesting challenge that Go might be good for is the pooling software. A lot of the current stock of pool managers aren't that efficient and dish out duplicate work and/or create stale shares. Seems like ideal Go concurrent territory...

Just some ideas!

Cheers,

Donovan.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ryan Slade]

A Bitcoin exchange, something to compete with MtGox would be interesting too. Of course, there would be a lot of red tape involved.

[Nate Finch]

Should make a new twitter or ebay while you're at it :)  There's a damn lot of typing that has to be done for any website that is a full end user product, and that goes double for a website that deals in financial transactions. It's about 6 steps past non-trivial.

[Péter Szilágyi]

Neah, aim big... go after Google :)

--

[Johannes Löthberg]

That /would/ be pretty ironic ;)

--
-K

[Hotei]

True - but once upon a time a little bity startup company called Google went after the search engine giant DEC/AltaVista.  Everybody thought that was funny too... 

[simon place]

wont the ASIC's need something networky/parallel to keep them fed?

[minux]

On Sat, Apr 6, 2013 at 1:49 AM, simon place <simon...@googlemail.com> wrote:
> wont the ASIC's need something networky/parallel to keep them fed?

no. one stratum work represents ~2^64 hashes, so even controller written in Lua
can keep those ASIC miner fed (of course, this depends on having fast
SHA256 core
in either C or in hardware for the merkle tree root calculation)
before a new work is
pushed by the server.

Also, currently, Go binary is too big to fit on those 4MB flash of
TL-WR703N that control
the ASIC miners (besides there is no MIPS port for the gc toolchain),
even compressed.

As others have said, Go will certainly shine in the pooling and trade
backend software
market.

PS: Go is also not suitable for scrypt (LiteCoin) mining as you will
need to use at least
ATI GPU to be profitable.

[Donovan Hide]

PS: Go is also not suitable for scrypt (LiteCoin) mining as you will
need to use at least
ATI GPU to be profitable.

Well, profitability is a function of both the value of Litecoin and the cumulative hashing power of all other miners (ie. difficulty) and these factors do change over time :-) 

On a related note, I've been playing round with trying to communicate with stratum servers using net/rpc/json, but soon realised that there is no support for notifications in the standard library implementation. The expected response are detailed here:

http://mining.bitcoin.cz/stratum-mining#stratum 

In the section: "Server start sending notifications with mining jobs"

Was there any consideration given to implementing the pubsub pattern in the Go RPC design? It is part of the JSON RPC 2 spec:

http://www.jsonrpc.org/specification#notification

The idea is simple, requests with a null id are notifications, usually prompted by a prior subscription request in the opposite direction. Seems like a lot of previous attempts at doing JSON-RPC have revolved around using HTTP:

https://github.com/ThePiachu/Go-HTTP-JSON-RPC

http://www.gorillatoolkit.org/pkg/rpc/json

but stratum prefers TCP sockets in most pool implementations...

Just wondering if anyone has solved this type of problem before and has some tested code lying around? The JSON/BSON/SOAP Service/RPC/ TCP/HTTP/Websocket matrix has a ridiculous number of standards, none of which any implementation ever seems to fully match :-)

Cheers,

Donovan.

[Gerard]

Well, if you or anyone else want to do it, the time is now. High risk, high gain.

Op donderdag 4 april 2013 12:45:39 UTC+2 schreef Ryan Slade het volgende:

[roger peppe]

On 6 April 2013 13:46, Donovan Hide <donov...@gmail.com> wrote:
>
>> PS: Go is also not suitable for scrypt (LiteCoin) mining as you will
>> need to use at least
>> ATI GPU to be profitable.
>
>
> Well, profitability is a function of both the value of Litecoin and the
> cumulative hashing power of all other miners (ie. difficulty) and these
> factors do change over time :-)
>
> On a related note, I've been playing round with trying to communicate with
> stratum servers using net/rpc/json, but soon realised that there is no
> support for notifications in the standard library implementation. The
> expected response are detailed here:
>
> http://mining.bitcoin.cz/stratum-mining#stratum
> In the section: "Server start sending notifications with mining jobs"
>
> Was there any consideration given to implementing the pubsub pattern in the
> Go RPC design? It is part of the JSON RPC 2 spec:
>
> http://www.jsonrpc.org/specification#notification
>
> The idea is simple, requests with a null id are notifications, usually
> prompted by a prior subscription request in the opposite direction. Seems
> like a lot of previous attempts at doing JSON-RPC have revolved around using
> HTTP:

Interesting, I hadn't seen this in json-rpc before.

Just to check: a "notification" is just a client->server request that
doesn't require a reply, right?

I can't see quite how that would relate to "a prior subscription request
in the opposite direction", which would seem to indicate that
the server is sending requests to the client.

It would not be too hard to change the net/rpc package to allow this,
I think. Perhaps Client.Notify(serviceMethod string, args interface{}) error

The codecs could probably remain the same.

[Donovan Hide]

Interesting, I hadn't seen this in json-rpc before.

Just to check: a "notification" is just a client->server request that
doesn't require a reply, right?

A notification doesn't require a reply and, in fact, cannot by replied to because it does not have an id to reply with. 

 

I can't see quite how that would relate to "a prior subscription request
in the opposite direction", which would seem to indicate that
the server is sending requests to the client.

Stratum flow is:

client sends request "mining.subscribe" to server

server sends reply confirming subscription succeed or fail

server later sends notification(s) indicating new work 

It's just basic pubsub really...

 

It would not be too hard to change the net/rpc package to allow this,
I think. Perhaps Client.Notify(serviceMethod string, args interface{}) error

The codecs could probably remain the same.

I tried using net/rpc/ with a custom codec, but gave up quickly when I realised you cannot have a client and server run on the same socket. Stratum requires requests to be able to go either way. Have ended up with a homespun mux that seems to do the job.

Another issue I encountered was that the model Stratum implementation sends replies as JSON tuples (ie. positional arguments in Python-land) and the encoding/json package does not know about how to unmarshal this type of data structure into a struct. Ended up doing some []interface{} mapping to struct field order, reflect/magic/hack, that does work. Would be nice if there was a positional json tag:

type Example struct{

    First int `json:"0"`

    Second int `json:"1"`

}

 

which could unmarshal

{"test":(123,456)} 

and handle appropriately type mismatches and nested arrays or objects, etc. Have done this myself, but would be nice if it was in the standard library...

Cheers,

Donovan.

[roger peppe]

On 12 April 2013 11:36, Donovan Hide <donov...@gmail.com> wrote:
>
>> Interesting, I hadn't seen this in json-rpc before.
>>
>> Just to check: a "notification" is just a client->server request that
>> doesn't require a reply, right?
>
>
> A notification doesn't require a reply and, in fact, cannot by replied to
> because it does not have an id to reply with.
>
>>
>> I can't see quite how that would relate to "a prior subscription request
>> in the opposite direction", which would seem to indicate that
>> the server is sending requests to the client.
>
>
> Stratum flow is:
>
> client sends request "mining.subscribe" to server
> server sends reply confirming subscription succeed or fail
> server later sends notification(s) indicating new work

that doesn't seem to fit with the description in json.RPC:
"A Notification is a Request object without an "id" member. "
which would seem to indicate that notifications flow from
client to server only (which seems fine).

If the server can asynchronously send notications to the client,
the model is quite different, and incompatible with the way that
rpc usually works. And there are various kinds of potential flow-control
issues.

>> It would not be too hard to change the net/rpc package to allow this,
>> I think. Perhaps Client.Notify(serviceMethod string, args interface{})
>> error
>>
>> The codecs could probably remain the same.
>
>
> I tried using net/rpc/ with a custom codec, but gave up quickly when I
> realised you cannot have a client and server run on the same socket. Stratum
> requires requests to be able to go either way. Have ended up with a homespun
> mux that seems to do the job.

That seems very unusual for an rpc-like protocol. Usually only a single
party initiates requests.

> Another issue I encountered was that the model Stratum implementation sends
> replies as JSON tuples (ie. positional arguments in Python-land) and the
> encoding/json package does not know about how to unmarshal this type of data
> structure into a struct. Ended up doing some []interface{} mapping to struct
> field order, reflect/magic/hack, that does work. Would be nice if there was
> a positional json tag:
>
> type Example struct{
> First int `json:"0"`
> Second int `json:"1"`
> }
>
> which could unmarshal
>
> {"test":(123,456)}
>
> and handle appropriately type mismatches and nested arrays or objects, etc.
> Have done this myself, but would be nice if it was in the standard
> library...

You can unmarshal into a []json.RawMessage and unmarshal
each item individually, but the positional-argument syntax
is an interesting idea - I could have used it myself recently.

[Donovan Hide]

That seems very unusual for an rpc-like protocol. Usually only a single
party initiates requests.

It's actually quite useful. The Stratum server might want to know the client version, and it initiates a request. The Stratum client might want to verify the bitcoin merkle tree data, etc.. I thought it would be a nightmare to implement, but you just need to keep track of incoming and outgoing request ids separately. I extended this further to make a pair of (host,requestid) as an identity, which allows for simultaneous connections to multiple Stratum servers via the same muxer, which makes for very interesting comparisons of mining pools. Multiple connections to the same Stratum server are not possible with this scheme though...

I think the creator of Stratum wanted to avoid two sockets per client connection. The pool in question has 30,000 clients at any one time. Sounds like ideal Go territory to me :-)

> {"test":(123,456)}
>
> and handle appropriately type mismatches and nested arrays or objects, etc.
> Have done this myself, but would be nice if it was in the standard
> library...

You can unmarshal into a []json.RawMessage and unmarshal
each item individually, but the positional-argument syntax
is an interesting idea - I could have used it myself recently.

Example should have been: {"test":[123,456]}

Jumping between JS,Go and Python messes with the syntax part of my brain :-)