FAQ
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

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Andrew Gerrand at Apr 4, 2013 at 5:50 am

    On 4 April 2013 16:47, josvazg 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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Donovan Hide at Apr 4, 2013 at 10:02 am
    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.

    On 4 April 2013 06:50, Andrew Gerrand wrote:

    On 4 April 2013 16:47, josvazg 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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ryan Slade at Apr 4, 2013 at 10:45 am
    A Bitcoin exchange, something to compete with MtGox would be interesting
    too. Of course, there would be a lot of red tape involved.
    On Thursday, 4 April 2013 11:02:36 UTC+1, Donovan wrote:

    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.


    On 4 April 2013 06:50, Andrew Gerrand <a...@golang.org <javascript:>>wrote:
    On 4 April 2013 16:47, josvazg <jos...@gmail.com <javascript:>> 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

    --
    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 <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nate Finch at Apr 4, 2013 at 10:56 am
    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.
    On Thursday, April 4, 2013 6:45:39 AM UTC-4, Ryan Slade wrote:

    A Bitcoin exchange, something to compete with MtGox would be interesting
    too. Of course, there would be a lot of red tape involved.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Péter Szilágyi at Apr 4, 2013 at 10:58 am
    Neah, aim big... go after Google :)

    On Thu, Apr 4, 2013 at 12:56 PM, Nate Finch wrote:

    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.

    On Thursday, April 4, 2013 6:45:39 AM UTC-4, Ryan Slade wrote:

    A Bitcoin exchange, something to compete with MtGox would be interesting
    too. Of course, there would be a lot of red tape involved.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Johannes Löthberg at Apr 4, 2013 at 2:40 pm
    That /would/ be pretty ironic ;)

    --
    -K
    On Thursday, April 4, 2013 12:58:38 PM UTC+2, Péter Szilágyi wrote:

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


    On Thu, Apr 4, 2013 at 12:56 PM, Nate Finch <nate....@gmail.com<javascript:>
    wrote:
    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.

    On Thursday, April 4, 2013 6:45:39 AM UTC-4, Ryan Slade wrote:

    A Bitcoin exchange, something to compete with MtGox would be interesting
    too. Of course, there would be a lot of red tape involved.
    --
    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 <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Hotei at Apr 4, 2013 at 5:04 pm
    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...

    On Thursday, April 4, 2013 10:39:57 AM UTC-4, Johannes Löthberg wrote:

    That /would/ be pretty ironic ;)

    --
    -K
    On Thursday, April 4, 2013 12:58:38 PM UTC+2, Péter Szilágyi wrote:

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

    On Thu, Apr 4, 2013 at 12:56 PM, Nate Finch wrote:

    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.

    On Thursday, April 4, 2013 6:45:39 AM UTC-4, Ryan Slade wrote:

    A Bitcoin exchange, something to compete with MtGox would be
    interesting too. Of course, there would be a lot of red tape involved.
    --
    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jlyons at Apr 5, 2013 at 7:42 pm
    But they didn't use tools that AltaVista published to do it. ;)
    On Thursday, April 4, 2013 10:04:26 AM UTC-7, Hotei wrote:

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

    On Thursday, April 4, 2013 10:39:57 AM UTC-4, Johannes Löthberg wrote:

    That /would/ be pretty ironic ;)

    --
    -K
    On Thursday, April 4, 2013 12:58:38 PM UTC+2, Péter Szilágyi wrote:

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

    On Thu, Apr 4, 2013 at 12:56 PM, Nate Finch wrote:

    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.

    On Thursday, April 4, 2013 6:45:39 AM UTC-4, Ryan Slade wrote:

    A Bitcoin exchange, something to compete with MtGox would be
    interesting too. Of course, there would be a lot of red tape involved.
    --
    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Gerard at Apr 12, 2013 at 7:55 am
    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:
    A Bitcoin exchange, something to compete with MtGox would be interesting
    too. Of course, there would be a lot of red tape involved.
    On Thursday, 4 April 2013 11:02:36 UTC+1, Donovan wrote:

    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.

    On 4 April 2013 06:50, Andrew Gerrand wrote:

    On 4 April 2013 16:47, josvazg 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

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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Simon place at Apr 5, 2013 at 5:49 pm
    wont the ASIC's need something networky/parallel to keep them fed?
    On Thursday, 4 April 2013 06:50:04 UTC+1, Andrew Gerrand wrote:

    On 4 April 2013 16:47, josvazg <jos...@gmail.com <javascript:>> 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
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Apr 5, 2013 at 8:02 pm

    On Sat, Apr 6, 2013 at 1:49 AM, simon place 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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Donovan Hide at Apr 6, 2013 at 12:46 pm

    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Roger peppe at Apr 12, 2013 at 10:14 am

    On 6 April 2013 13:46, Donovan Hide 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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Donovan Hide at Apr 12, 2013 at 10:36 am

    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Roger peppe at Apr 12, 2013 at 11:33 am

    On 12 April 2013 11:36, Donovan Hide 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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Donovan Hide at Apr 12, 2013 at 12:14 pm


    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 :-)

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 4, '13 at 5:47a
activeApr 12, '13 at 12:14p
posts17
users13
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase