btcsuite / btcjson Goto Github PK

If a struct type does not satisify the json.Unmarshaler interface, the json package will attempt to perform the unmarshal itself according to its own internal rules. One of these rules is using strconv.ParseInt to unmarshal a json number (floating point) as an integer. This works for some floating point numbers and not others (for example, 4294967295 and 4.294967295e+09 are both valid responses and the same json number, but the latter fails the integer unmarshal).

When a type is a json.Unmarshaler, its UnmarshalJSON function is used rather than the catch-all unmarshaling logic in the json package. To prevent unmarshaling issues as described above, each concrete result type should satisify this interface and perform the unmarshal to a float64, and then type convert to an go integer type.

reqSig should be reqSigs.

This is currently over in btcws as it was a btcwallet extension that has now been added in a slightly modified form to the reference implementation. Since it's now part of the reference implementation it should be moved from btcws to here.

It's supposed to take 0 ~ 2 parameters. but in btcjson api, 2 params is required.

I'm just wondering if this could be used with their API - I tried, but I'm getting an unmarshalling error, which I assume is some difference between the response and the expectred response.

Error reading json message: Error unmarshalling json reply: unexpected end of JSON input

(from this code)

package main

import (
    "github.com/conformal/btcjson"
    "log"
)

func main() {
    msg, err := btcjson.CreateMessage("getinfo")
    if err != nil {
        log.Fatal(err)
    }
    reply, err := btcjson.TlsRpcCommand(
        "guid-guid-guid-guid",
        "secret password dont tell nobody",
        "rpc.blockchain.info:443",
        msg,
        nil,
        true,
    )
    log.Print(err)
    log.Print(reply)
}

Or I guess it could be because TLS != HTTPS

https://en.bitcoin.it/wiki/Getblocktemplate#How_to_use_it

Please add submitblock support.
submitblock [optional-params-obj]

See discussion in PR #15

These would be useful to have in the btcjson package for reuse and to eliminate magic numbers in btcd, btcwallet, btcgui, etc. The bitcoind error codes can be found in 'src/bitcoinrpc.h' in the RPCErrorCode enum definitions.

Currently some structs returned by ReadResultCmd use by vaule while others are by reference. They should consistently be by reference.

right now we should call the sendmany in this way :1
msg, err := btcjson.createMessage("sendmany", from, to1, amount1,minconf1, comment1, to2, amount2,minconf2, comment2, to3, amount3,minconf3, comment3...)

why not just change it to this way?

type sendDetail struct { to string, amount float64, minconf int, comment string}

msg, err := btcjson.createMessage("sendmany", from, []sendDetail)

I think it's a much simple way. How do you think?

Give Error an Error() func so it can be used as an error.

I am getting an error when I run the following. (note this is against a bitcoind node)

_, err := client.getPeerInfo()
if err != nil {
     log.Fatal(err)
}

Outputs:

Error unmarshalling json reply: json: cannot unmarshal number 0.0000000 into Go value of type int64

Bitcoind reports this when I run bitcoind getpeerinfo:

[    {
        "addr" : "187.74.170.202:32103",
        "addrlocal" : "54.83.21.194:18333",
        "services" : "00000001",
        "lastsend" : 1402588600,
        "lastrecv" : 1402588531,
        "bytessent" : 136226,
        "bytesrecv" : 26327,
        "conntime" : 1402559908,
        "pingtime" : 0.00000000,
        "version" : 70002,
        "subver" : "/Satoshi:0.9.1/",
        "inbound" : true,
        "startingheight" : 262162,
        "banscore" : 0
    },
    {
        "addr" : "131.188.31.107:43447",
        "addrlocal" : "54.83.21.194:18333",
        "services" : "00000001",
        "lastsend" : 1402588523,
        "lastrecv" : 1402588599,
        "bytessent" : 81313,
        "bytesrecv" : 6158,
        "conntime" : 1402582019,
        "pingtime" : 0.00000000,
        "version" : 70002,
        "subver" : "/Satoshi:0.9.99/",
        "inbound" : true,
        "startingheight" : 262207,
        "banscore" : 0
    },
    {
        "addr" : "103.11.49.133:19817",
        "addrlocal" : "54.83.21.194:18333",
        "services" : "00000001",
        "lastsend" : 1402588602,
        "lastrecv" : 1402587587,
        "bytessent" : 77874,
        "bytesrecv" : 2682,
        "conntime" : 1402583641,
        "pingtime" : 0.00000000,
        "version" : 70001,
        "subver" : "/Satoshi:0.8.5/",
        "inbound" : true,
        "startingheight" : 262208,
        "banscore" : 0
    },
    {
        "addr" : "67.243.60.105:19520",
        "addrlocal" : "54.83.21.194:18333",
        "services" : "00000001",
        "lastsend" : 1402588523,
        "lastrecv" : 1402588599,
        "bytessent" : 82146,
        "bytesrecv" : 4181,
        "conntime" : 1402584932,
        "pingtime" : 0.00000000,
        "version" : 70002,
        "subver" : "/Satoshi:0.9.0/",
        "inbound" : true,
        "startingheight" : 262213,
        "banscore" : 0
    },
    {
        "addr" : "89.71.7.139:42372",
        "addrlocal" : "54.83.21.194:18333",
        "services" : "00000001",
        "lastsend" : 1402588523,
        "lastrecv" : 1402588599,
        "bytessent" : 75267,
        "bytesrecv" : 5486,
        "conntime" : 1402586251,
        "pingtime" : 0.00000000,
        "version" : 70002,
        "subver" : "/Satoshi:0.9.1/",
        "inbound" : true,
        "startingheight" : 262215,
        "banscore" : 0
    },
    {
        "addr" : "181.167.146.246:56676",
        "addrlocal" : "54.83.21.194:18333",
        "services" : "00000001",
        "lastsend" : 1402588601,
        "lastrecv" : 1402588618,
        "bytessent" : 72917,
        "bytesrecv" : 984,
        "conntime" : 1402588007,
        "pingtime" : 0.00000000,
        "version" : 70002,
        "subver" : "/Satoshi:0.9.1/",
        "inbound" : true,
        "startingheight" : 262215,
        "banscore" : 0
    },
    {
        "addr" : "72.69.227.25:47786",
        "addrlocal" : "54.83.21.194:18333",
        "services" : "00000001",
        "lastsend" : 1402588615,
        "lastrecv" : 1402588607,
        "bytessent" : 1625,
        "bytesrecv" : 1364,
        "conntime" : 1402588334,
        "pingtime" : 0.00000000,
        "version" : 70001,
        "subver" : "/btcwire:0.1.4/btcd:0.8.0/",
        "inbound" : true,
        "startingheight" : 262217,
        "banscore" : 0
    }
]

It looks like ping time should be a float :-/
This line specifically: https://github.com/conformal/btcjson/blob/master/jsonresults.go#L107

btcjson needs to be pruned of the unnecessary/bad APIs that many keep attempting to use with little success. At a high level, I believe that all the "networking" functions should be removed (this is better left to another client package which can support multiple transport and authentication types, such as btcrpcclient), all of the functions and types that are unnecessitated by the Cmd interface, all result unmarshaling (it's just broken, using the wrong types for many results), and finally all other extraneous "util" functions that have better replacements in other Conformal btc* packages. This will leave btcjson as a package simply for the marshaling and unmarshaling of requests and complex (JSON object) result types and errors.

I propose the following to be marked as deprecated, and to remove any mention of them from doc.go:

• CreateMessage -- Deprecated by New<Method>Cmd.
• CreateMessageWithID -- Deprecated by New<Method>Cmd.
• GetRaw -- Not well named and trivial for any client.
• IsValidIdType -- If a client generates their own IDs, they do not need to check that the known good type is good. And regardless, btcjson IDs work as *interface{}, while this function will always return false for a pointer to the empty interface, regardless of what is packed in that interface value.
• JSONGetMethod -- Poorly named (no need for "JSON"), expensive, and is only called by proposed deprecated functions. The Cmd interface type also includes a Method method which returns the same string for unmarshaled Cmd structures.
• JSONToAmount -- Deprecated by btcutil.NewAmount (high level clients will want to work with Amount, not int64 for monetary values).
• MarshalAndSend -- Is a networking function, name does not indicate this only works for Reply (responses), and passes the Reply by value not pointer.
• Message -- This type is not named accurately (should be "Request"), only is created for a single internal deprecated API (jsonWithArgs), and is unnecessitated by New<Method>Cmd and/or clients creating their own RawCmd structures.
• ReadResultCmd -- Result unmarshaling is broken (uses incorrect numeric types in many situations) and clients should know exactly how to unmarshal the expected response into a known good type.
• RpcCommand -- Is a networking function, makes many assumptions about the authentication model, and uses the broken result unmarshaling codepath.
• RpcRawCommand -- See RpcCommand, the only difference being that this one doesn't try to unmarshal the result.
• RpcSend -- Is a networking function, makes many assumptions about the authentication model, and is poorly named. This one (unlike RpcCommand) actually unmarshals a Cmd.
• TlsRpcCommand -- See RpcCommand.
• TlsRpcRawCommand -- See RpcRawCommand.
• TlsRpcSend -- See RpcSend.

the getwork API should allow 0 parameters or an optional 1 workrequest parameter. Currently, a parameter is required.