In Discover, the reponse was lowercased for comparison. However,
this caused a 404 - Not found when fetching the url provided by
the location header if the url contained uppercase.
ok @owainga
In practise the races caused by not protecting these quite simply didn't
matter, they couldn't actually cause any damage whatsoever. However, I
am sick of hearing about these essentially false positivies whenever
someone runs the race detector (yes, i know that race detector has no
false positives but this was effectively harmess).
verified to shut the detector up by dhill.
If we switch the knuth shuffle to the version that swaps the element
with an element between it and the end of the array, then once we have
gotten to the amount of elements we need they won't change later in the
algorithm. Terminating here means that we only do 23% of the length of
the array worth of random swaps at most.
We make ka.na immutable in the address manager. Whenever we would update
the structure we replace it with a new copy. This beats making a copy of
all addresses once per getaddr command (max is just over 23000 we would
be copying, compared to at most 2000 copies on a new getaddr that has
all addresses we know with newer dates).
On unknown inventory types, handleGetDataMsg would loop forever.
After fixing that, if a getdata request only had unknown inventory
types, it would block forever.
ok @davecgh
The code was updated to automatically handle the transaction count in the
block header without having the additional field some time ago. This
comment was outdated.
Copying the RIPEMD160 after SHA256 hash result into a new stack array
to be used as a map lookup key can be quite expensive, and this should
be avoided if possible on intensive tasks such as rescans. This
change takes advantage of the new Hash160 methods of the
AddressPubKeyHash and AddressScriptHash types to use the address's
underlying hash array directly, rather than creating a copy from the
ScriptAddress result.
Unfortunately, for AddressPubKey, ScriptAddress may return either a
byte slice of len 33 or 65 depending on whether the pubkey is
compressed or not, so no such straightforward optimization is
possible.
As a result of this change, I have seen rescans perform roughly 3.5x
faster than before.
the new function AddUserAgent adds the user agent to the stack
and formats it as per BIP 0014
e.g: "/btcwire:0.1.4/myclient:1.2.3(optional; comments)/"
the validation on UserAgent has been moved to a new function
validateUserAgent
This commit renames the notifyallnewtxs RPC to notifynewtransactions to be
more consistent with the standard RPC names and to more accurately
reflect its intention which is to register for new transactions as they
are accepted to the memory pool. In addition, the notifications produced
have been renamed to txaccepted and txacceptedverbose depending on whether
or not the verbose flag was set when the client registered to receive the
notifications via notifynewtransactions.
This closesconformal/btcd#98.
The websocket extension command to register for notifications when a new
transaction has been accepted to the memory pool and the resulting
notifications have been renamed. This commit catches up to the change.
This commit renamed the notifynewtxs RPC to notifyreceived since it more
accurately reflects its intention which is to register addresses to be
notified about when they receive funds.
This is work towards conformal/btcd#98.
ok @jrick.
Since a chain verification can take a long time depending on the
parameters, this commit adds a debug print to the RPC server at the info
level for how many blocks are being verified and at what level.
The logic was also slightly modified so the number of blocks being checked
can easily be calculated and shown.
This commit extends the RegisterCustomCmd function to also accept a reply
parser which will be invoked for replies to the custom command via
ReadResultCmd. This allows replies to custom commands to be returned a
concrete structs instead of map[string]interface{}.
ok @jcvernaleo, @jrick
This commit moves all of the structs which deal with command results and
related functions to a new file named jsonresults.go.
This is in preparation of allowing custom results to be registered.
ok @jcvernaleo
This commit marks the CreateMessage and CreateMessageWithId functions as
deprecated as they are no longer maintained due to the new concrete
command approach.
It also updates the package documentation to show the new preferred method
as well as add details about btcd.
ok @jcvernaleo
The existing RpcCommand and TlsRpcCommand were build with
CreateMessage(WithID) in mind since they return an already marshalled
command. The approach was changed to use concrete commands created via
the New<command>Cmd family of functions. However, this means the caller
had to manually marshal the command before calling (Tls)RpcCommand which
was not very user friendly.
This commit adds two new functions named RpcSend and TlsRpcSend which
directly accepts a btcjson.Cmd and handles the marshalling itself.
ok @jcvernaleo
The NewTxNtfn notification was previously using a map[string]interface.
This commit modifies it to use the new concrete type
btcjson.ListTransactionsResult instead which allows nicer marshalling and
unmarshalling.
ok @jrick
