return a requested block/transaction. Make this time dependent on the actual block
interval. This should allow the the node to give up and request the block from
another peer before the ~30 second undo interval has passed.
Fix the merkle root calculation to avoid reading
past the end of a vector. Modify the algorithm to do what was likely intended
(this modification is currently disabled because it will yield different results
than the currently-running testnet)
Fix windows build errors.
Rather than using futures and waiting in the destructor, the APIs now
use enable_shared_from_this and the lambda captures a shared pointer to
the API to prevent it from going out of scope. As a result the
destructor can not be called while there is a pending async operation
which removes the need to wait in the destructor and thereby removing
the potential for an exception to be thrown causing this crash.
Delayed node is much like witness_node, except it doesn't have support
for block productuion (thus cannot be a witness) and it is not intended
to use the P2P network. The delayed node requires a trusted node it can
connect to via RPC and download blocks from. The delayed node will only
download blocks from the trusted node if those blocks have received a
configurable number of confirmations.
This commit effectively resolves#237
This call allows wallets to filter the set of keys that may potentially
sign a transaction prior to calling get_required_signatures to get the
minimum subset.
Still need to set expiration, so none of the transactions I broadcast
work yet... :( Sadly there is no testnet so I can't finish this. Oh well.
I'm sure it'll be much easier on Monday.
subscribe_to_objects now returns the initial value of the objects, this
makes it easy for someone to fetch and subscribe in a single atomic step
rather than having to call get and then subscribe which could lead to
some inconsistencies if the object was modified after get but before
subscribe.
When subscribing to markets the callback will now receive something that
looks like this:
[ "REMOVED ID1", "REMOVED ID2", ...,
{ "id": "UPDATED ID3", data... },
{ "id": "UPDATED ID4", data... },
...
[ FILL_OPERATION_TYPE_ID, { fill order operation data } ],
[ FILL_OPERATION_TYPE_ID, { fill order operation data } ],
[ FILL_OPERATION_TYPE_ID, { fill order operation data } ],
[ FILL_OPERATION_TYPE_ID, { fill order operation data } ]
]
When ever an order is removed from the order book, its ID will be
included as a string. When an order is modified the new order data is included as
an object. And the operations describing how orders were matched and
what fees are paid will be included as an operation, aka array.
Also added means to unsubscribe from full account data (issue #166)
When subscribing to an account via the get_full_account API it will
start streaming any object relevant to the account that is added,
removed, or modified.
