backoffice API and interfaces

[InoMurko]

Supported APIs extracted and filtered from Watcher Info

"/account.get_balance"
"/account.get_utxos"
"/account.get_transactions"
"/block.all"
"/deposit.all"
"/transaction.all"
"/transaction.get"
"/block.get"
"/fees.all"
"/stats.get"

As you can notice transaction.create and transaction.submit_typed were removed. "/transaction.submit_typed" can be moved to Watcher Security.

There are no Watcher Security APIs in backoffiice (intentional, we want to push the network to use run their Watcher!). There are also no write APIs.

Backoffice can support an additional "get mempool transaction".
"/account.get_in_flight_transactions" (filtered by account) as we cannot reliably return a ful future block of transactions (64000 transactions in a JSON would be huge). Mempool transactions come directly from the Childchain2 via MQ (RabbitMQ). Backoffice is also responsible for forming blocks.

[InoMurko]

I would also be easly persuaded for us to track all events emitted from plasma contracts (like, BondReturnFailed BountyReturnFailed ExitOmitted IFEBondUpdated PiggybackBondUpdated ProcessInFlightExitBountyUpdated ...). We can then expose the data from the API.
And sell.

[unnawut]

Question to product: How do we encourage more people to run their own watcher security? Could be feature offering wise, relationship management, public communications, etc.

[boolafish]

How do we encourage more people to run their own watcher security?

We byzantine and take all the money out from people who does not run watcher

But a more serious one, how about we enforce regular drill and for those who does not run, we offer our watcher endpoint with money cost that would let them pay a lot for the drill 😛