Add support for FilteredTransactions to the observable states feature

Description

Having built the crowd funding demo for project Agent, I have a couple of observations (boom!) around the new observable states feature.

The demo can be found here: https://github.com/roger3cev/observable-states and the README.md covers how it all works.

In short, recording all outputs from a transaction is troublesome, because:

  1. It skews the observer's cash balances and breaks generateSpend as those observable states which the observer cannot spend can be chosen for spending

  2. It has privacy implications as perhaps observers only need to see a sub-set of the output states

Solving both issues
Off the top of my head, the obvious solution which solves both points would be to create a new set of flows called `SendTransactionToObserve`, `ReceiveTransactionToObserve` (or something like that) that takes a `FilteredTransaction` and sends it to the other side. The filtering will be done on the senders side as opposed to the receivers side, as is the case now.

We would have to add support for recording filtered transactions as currently we only support the recording of `SignedTransaction`s. Presumably this is easier said than done as we cannot verify parts of transactions we cannot see and `FilteredTransaction`s do not have signatures associated with them. We would need to create a new type `FilteredTransactionWithSignatures` which will allow the observer to verify the signatures are correct. The assumption is that because the actual parties involved have already signed the transaction, presumably it was valid too. In order to verify signatures we would need to expose all the commands on top of the subset of output states.

The above are just cursory thoughts, I haven't put a great deal of thinking into this yet. I guess we need to consider what the real issue is here, privacy or just the logistics around storing observable stuff.

Solving the first issue only
If we don't care about privacy, perhaps we could add a new state status to the vault, OBSERVABLE, to augment the existing CONSUMED and UNCONSUMED statuses. As such, we don't need to use filtered transactions, we simply just add a parameter to `VaultService.recordTransactions` that indicates to the vault that all these states should be observed.

The `FilteredTransaction` approach is probably the better one.

Tagging: for visibility

Assignee

Unassigned

Reporter

Roger Willis

Labels

Sprint

None

Epic Link

None

Priority

Medium

Engineering Teams

Kernel

Fix versions

None

Affects versions

None

Ported to...

None

Story Points / Dev Days

None

Build cut

None

Feature Team

Kernel Group
Configure