monzero-core.git/src/rpc, branch v0.10.0

epee: optionally restrict HTTP service to a configurable user agent

2016-09-18T19:32:02Z

This is intended to catch traffic coming from a web browser, so we avoid issues with a web page sending a transfer RPC to the wallet. Requiring a particular user agent can act as a simple password scheme, while we wait for 0MQ and proper authentication to be merged.

cmake: transitive deps and remove deprecated LINK_*

2016-09-18T06:56:26Z

Keep the immediate direct deps at the library that depends on them, declare deps as PUBLIC so that targets that link against that library get the library's deps as transitive deps. Break dep cycle between blockchain_db <-> crytonote_core. No code refactoring, just hide cycle from cmake so that it doesn't complain (cycles are allowed only between static libs, not shared libs). This is in preparation for supproting BUILD_SHARED_LIBS cmake built-in option for building internal libs as shared.

wallet: transfer_selected_rct now also selects fake outs

2016-08-28T20:30:34Z

rpc: send global indices along with blocks/transacions on refresh

2016-08-28T20:29:38Z

This plugs a privacy leak, where the wallet tells the daemon which transactions contain outputs for the wallet by asking for additional information for that particular transaction. As a nice bonus, this actually makes refresh slightly faster.

mixable transactions must be rct for v3

2016-08-28T20:29:07Z

add rct to the protocol

2016-08-28T20:28:37Z

It is not yet constrained to a fork, so don't use on the real network or you'll be orphaned or rejected.

core: new /getrandom_rctouts.bin binary RPC call

2016-08-28T20:28:16Z

to get random ringct outputs to mix with

remove original Cryptonote blockchain_storage blockchain format

2016-08-28T20:27:32Z

daemon: print time to next fork

2016-08-12T19:32:23Z

Fake outs set is now decided by the wallet

2016-08-11T13:35:27Z

This plugs a privacy leak from the wallet to the daemon, as the daemon could previously see what input is included as a transaction input, which the daemon hadn't previously supplied. Now, the wallet requests a particular set of outputs, including the real one. This can result in transactions that can't be accepted if the wallet happens to select too many outputs with non standard unlock times. The daemon could know this and select another output, but the wallet is blind to it. It's currently very unlikely since I don't think anything uses non default unlock times. The wallet requests more outputs than necessary so it can use spares if any of the returns outputs are still locked. If there are not enough spares to reach the desired mixin, the transaction will fail.