Controlling Stream Publish with Transaction Outputs

Question

I'm working on a project that will use Multichain's stream capability to build a history of actions that have been taken by a set of users.  Due to external timing issues, it is possible that two users might attempt to publish mutually exclusive items to the stream.  Since there is no mechanism in Multichain to perform external validation of transactions, I am wondering if it would be possible to use UTXOs from previous transactions to prevent conflicting publishes.  In other words, given a item A in the stream, I'd like to allow only one of item B or item C to be published.  If item B is published, then item C should fail to confirm and vice versa.  

My thought is to use the UTXO from the item A transaction as input to the item B (or C) transaction.  Since UTXOs can only be spent once, the first transaction to get confirmed by the blockchain would stick, and the other would fail with an error.

If this a viable approach for what I'm trying to accomplish?  And if so, what would be the steps required to build these transactions?  I'm assuming that the simple "publish" operation won't cut it.

Answer 1

You could do something like this with a UTXO (see createrawtransaction) so long as you are able to trust your users not to create additional UTXOs they can spend – if so they could insert additional items in unexpected places. I guess you would use a 1-of-2 multisig address that either user could spend.

Another simpler approach would be to define at the application level that the first item with a particular key according to (global) blockchain ordering is considered the authoritative one. You can easily use liststreamkeyitems to pull out that first item.

Comments

We are considering using the UTXO approach as a way to publish an item and insure that the recipient is only allowed to respond once.  Since we are creating the transaction, we would be able to insure it only had 1 UTXO.

We have already defined application level rules that would ignore published items that violate data consistency rules, but were looking at the UTXO approach as a method of preventing the second, illegal transaction from even being added to the chain.  Better to have it fail early than make everyone involved in the code process the item and then discard it.

The big issue would be in enforcing that the follow on transaction must use the UTXO from the original transaction.  It doesn't seem like there is a way to enforce that.

---

There isn't currently a way to do this. Once filters are implemented, as part of the MultiChain 2.0 roadmap, it will be possible. You can have a filter which insists that a transaction cannot write to a particular stream key unless it is spending a UTXO with some particular in-output metadata. And you can restrict who is allowed to create the UTXOs with this metadata.