v11 - Subscribe to Smart Contract Tx

[patrickdugan]

Chains like Tendermint, Credits, Tau, and so forth can embed complex app logic into smart contracts contained therein. These smart contracts can have a text message inscribed on said chain. We can consider that such a message would be in JSON format and contain 2 fields: an OMNI tx type and a set of parameters, e.g.:

{tx: 56, params: [param1, param2...]}

The Subscribe to smart contract tx would broadcast to the Bitcoin blockchain and propagate via Omnilayer nodes, and then Nodes that are jointly running a given chain's node (e.g. a Tendermint node participating in a given decentralized app) can pick up on if the trigger has been set in a given chain and relay this to some minimum threshold of other nodes (possibly corresponding to the min. 4 validators required in Tendermint, following that example).

Having met this relay threshold to verify that indeed the chain trigger criteria has been met, Omnicore nodes can then validate the contingent transaction from the original subscribe tx.

The format of the subscribe tx would then be:

{chainid: string, message: string, tx: int, params: [params]}

Possibly the message criterion is redundant, or the message indicates that the params would be variable depending on the output on the app chain.

Possible security holes in this approach are almost entirely contingent on the validation component in the other chain, anything else I am missing?

[zathras-crypto]

It sounds like what you are essentially describing is an Oracle, one that watches other chains and then informs the Omni protocol of actions happening on those chains.

This is not solvable in a decentralized manner as you describe I don't think (afaik trusting an Oracle is required) - could you please go into a bit more detail on how you see this functioning?

• Do you see us developing node software that straddles multiple chains?
• How would this off-chain "validation" be verified and secured?
• Is the other-chain validation recorded on the bitcoin chain by the "nodes jointly running a given chains node"?
• Is the requirement for Omni protocol to take action to change the state (such as moving tokens) when the subscribe tx is fulfilled (if so implies that every Omni user has no choice but to trust the validators - ie not optional, may not go down so well)

I'm not really having an easy time following - if we can break it down further perhaps we can flesh it out into something we can work towards implementing - but as it stands now mate I don't think the above is something we can just start work on without further detail.

Thanks :) Z

[patrickdugan]

I think if an interested party is willing to engage the subscribe they are taking on at least a basic trust in the app/contract that is so pledging the reservation of their capital. Different protocols have different methods for validating transactions or the "printing" of some output on their chains, if we simply have an RPC-level to listen to nodes of some other chain, it can be taken that the output is legit in the context of that chain's validation rules.

So specific answers:

1) Could be a less integrated RPC 2) Depends on the chain, Credits relies on federated networks, Tendermint on validators bonding some capital. If we can represent reserved capital on our layer, it could even be possible that said capital is Tether, OMNI ect. 3) Not necessarily but it could be and this may be a way to confirm the output on the other chain via a hash checksum. 4) Yes, but the value at risk would be limited to that affected by Subscribe txs.

[dexX7]

Hey @patrickdugan, could you walk me through one example? Maybe with the potentially new RPCs etc.? When are effects triggered and what effects are there? Unfortunally I'm not familiar with the interface of Tendermind and alike, so I still feel like I'm missing the important piece to grasp the whole concept.

Basically: what are the user actions and what are the expected results in an example scenario?

[patrickdugan]

Hey Dexx!

First about possible app-chains:

http://tendermint.com/posts/cases-for-tendermint/

Credits documentation WIP:

http://docs.credits.works/index.php?title=Main_Page

Meeting them in london on Tuesday.

Ok the first app I want to do is a simple cashflow contract.

I write up some Solidity that runs over the Ethereum VM on Tendermint. Or it could be Tau logic, ect. let's abstract out the concerns about XYZ consensus model and how logics are written, focus on the points touching our protocol.

I decide I want to freeze up a bunch of OMNI by putting them under a cashflow contract.

I subscribe to the Cashflow contract app running on some app chain by broadcasting a tx that says:

listen to chain xyz, for message "ok go!":: triggering Managed Smart Property Grant tx, with params of x contracts to be created, the id of this specific property, and another bitcoin address where the end-point of the contracts will be created.

Based on alterations to the fields for creating smart properties (described here: https://github.com/OmniLayer/omnicore/issues/347), this cashflow contract smart property will be issued to my address when the other chain puts out the go message, and this particular property has the effect of reserving 1 OMNI for every -1 contracts on an address.

Meanwhile the other chain's app parses OMNI RPC (or is lazy and just leans on Omnichest, just kidding, ideally not) for these tx's evoking it, picks up on this one I just broadcast, it's smart contract logic says to output "ok go!" or maybe it'd be proper JSON formatting, but I'm trying to keep the example basic.

Any Omnicore node is set to RPC ping the app chain picks up on this new output, scans pending subscribe tx's in the mempool, checks off that one of them has been hit, relays that now the contingent transaction happens. Then all the other Omnicore nodes pick up that relay as it percolates over the Bitcoin nodes in it's raw data form, consensus emerges, like any other Omni tx.

Essentially this subscribe tx is saying "hey my dudes (Omnicore nodes) this is a tx that will be valid in the future if RPC calls to xyz outside protocol returns 'ok go!'"

I think, given my limited hands on experience doing RPC stuff with this protocol, that we could modify the protocol to route RPC calls to some outside endpoint automatically so inter-chain consensus is guaranteed, giving us results as good as the other chain.

To that point, I want to clear up conceptually that these app-chains are fulfilling the same role as an Oracle, in ways that claim to be fundamentally more robust and decentralizable (though not a priori, that factor would come down to how many validators on the other chain ect.). It's Oracle++ or perhaps something qualitatively superior. That's not for us to judge, we just have a solid protocol that is interop ready for whatever nails it.

Now if Chris de Rose and Junseth are right and everyone else is a dum-dum who doesn't get that blockchains mean Bitcoin maximalism, this is all a waste of time. But, I think this is a more flex way to leverage whatever solid tech is out there.

Back to my app example:

At this point I have locked up capital in Omni layer by telling an app in another protocol to issue a token, the end. Boring. If we have these properties added that cause reservations and/or restrict simple send, that in itself would be a problem because now my OMNI is locked. We want these apps to do more.

It's possible that a tx could embed nested tx's, such that an entire decision tree of contingent transactions is embedded in my signing off on one master subscribe tx.

Then the other chain, parsing layer balances and such via RPC, takes that data as inputs to its app (not necessarily the only inputs, maybe others come from JPMorgan's banking APIs, Internet of things Devices, lots of possibilities) and its logic then produces more outputs on its own chain, which set the fuse on some or all (or perhaps none) of the other subscribed contingency tx's over Omni layer.

If we build a few simple secondary properties as parameter options for our token creation, the signed integers, the reservation properties, optional restrictions of simple send but not Dex or visa versa, we put in some failsafes where one can get their value out if the other chain goes monkey up, provided one controls the counterpart token with the privkey, or can trade for it over the Dex. Doesn't full re-risk the other chain but as stated above, that's really a parallel due dilligence for the user. The apps we do will all be open source, if the app is from Deloitte vis the Nigerian Central Bank or somesuch, people can call them if it breaks. Things will need thorough workout on testnet.

Sidenote: Nesting in general is a very inelegant pattern and there are data limits on Bitcoin. Is there any other way to broadcast complex sets of contigent transactions without resorting to that? What would the limits be there? Marv did a nice pass on enumerating the size of a basic tx, given the room we have in OP_Return how many could fit?

Back to my core example:

let's say we do a compound subscribe, with contingent tx's taking the form of a tree. My cashflow contracts (-1 and +1) come into existence on the address where I broadcast the subscribe and an address in the param field in the grant transaction that is one of three top-level transactions. 1 tx to issue the -1 to address A, 1 ts to issue the 1 to address B (let's say I'm Poloniex and address B is that Polo address where they aggregate all Omni assets) and 1 tx which subscribes me to the next layer deep, which has a couple of tx's.

Now my app chain is parsing for these balances, and does a logic test every time it mints a block: have any of the following Omni smart property ids been sent to the address with the negative contract balance? If yes, it outputs the trigger in its next block that would batch send every property received proportional to that 1 OMNI in reserve at address A, over to address B. So it's doing a bit of math in its Solidity contract or what-have-you in addition too just seeing if anything hit. Maybe I exempt smart property 1 (OMNI) from the checks, because this contract is designed to just pass on OMNI fees but allow people to build their core position - lots of power to create permutations on a design in that code. My Solidity code also accounts to change what address B is based on changes in the positive cashflow contract balance.

Whenever that output is made (e.g "fee distribution hit address A let's send it to address B) then the 2nd layer subscribe tx goes off, pushing as valid the send with updated parameters (such as the new address B if the owner of address B sent those positive cashflow contracts somewhere new) and another subscribe tx, 3rd deep, which itself contains the very same tx as 2nd layer subscription, reinforcing this smart-contract-as-a-service effect of passing cashflow on from negative contracts locking collateral that receives distributions on Omni layer to positive contracts trading over Omni layer.

So I think I just answered my own question about nesting, we need some notation for recursion here, and an optional expiration to a subscription (as an alternative failsafe to the above model where contracts are literal tokens you can trade and/or send away within Omni layer only).

Provided that the params are flexible to whatever the trigger message is a bit of nesting combined with recursion in the top-level subscribe tx can go a long way (hence my suggestion that we make that a standardized JSON formula with "quoted message" for literals and unquotes for variable params).

Now to go deep, deep, and do something like a futures contract, there would be some more layers, as well as the recursion. Possible way to circumvent data limitations in OP_Return would be that nested subscription tx params are left to the app and thus you simply say "hey party people/Omnicore nodes. if chain x says y then validate these transactions: [send n units of xyz to address q, subcribe for another send with params tbs by chain x].

Ok, huge answer, probably more than you expected, hope this flowers rather than derails discussion.

[dexX7]

Thanks for the details!

When stripping some details, to my understanding it comes down to this (please correct me, if I'm wrong):

• On the Omni side there is a not yet validated/broadcasted transaction, say a send or a grant.
• On the other side there is a contract.
• If the contract is executed, it is notable.
• If the contract execution is seen, the Omni transaction goes through.

Would it be possible to work with a secret, which is revealed on the other side? What I was thinking about:

The Omni transaction might be constructed such that it can go through, once the secret revealed, say:

• An Omni send/grant transaction is constructed, which is valid, if x of Hash(x) is given.
• On the other side a contract is created, which reveals x after successful execution.

I'm thinking about a similar mechanism as in atomic cross chain trading.

[patrickdugan]

Dexx, this is a great thought, my understanding of hashes is not perfect, I have considered a situation where multiple parties form a Credits chain as validators using the pubkeys of the Bitcoin addresses which host their bonded capital, and then the subscription hashes are derived from those pubkeys as well, or from something embedded inside the outside system, for example the JVM code executing on Credits could generate a new pair, publish the hashed counterpart on the first block of that app's chain, and sign it off when a block is created that would trigger an Omni tx. The problem with doing this with the pubkey's is that once revealed to trigger, the secret loses its secrecy. Whereas if the generation of hashes and publication of their secrets were something embeddable to the app-chain, it could create a series of such hashes for all relevant subscriptions and trigger transactions freely, as well as renew the hashes for the next app logic cycle in later blocks.

[patrickdugan]

On this note, I think our first Credits app would have to be a money market for bonding assets over Bitcoin to serve as collateral for validating XYZ Credits app.

[patrickdugan]

Ok so, the last remaining question is how to parse for the publication of secrets to the hashes used as the first parameter in subscription tx's.

I supposed the protocol would just parse the Op_Return of each tx in each new block and look for strings of the appropriate length, and then checksum them against any outstanding hashes that are the subscription triggers for Subscribe tx's that are still in the mempool and yet to expire to be validated. Then when such a string does return true for its checksum, you go back to the mempool to see the payload and those tx's become validated as of that block.

In summary, the tx would parameterize like this:

Tx 60: Subscribe to Smart Contract:

Hash: an n-character long string that checksums on n-y character long strings occurring in new Bitcoin blocks, if such returns true then the following params become validated. Payload: An array of Omni tx's or just a single Omni tx (ideally parses for both, no need to warp single tx in array [ ]s.

It really could be just that simple.

[zathras-crypto]

Ok so, the last remaining question is how to parse for the publication of secrets to the hashes used as the first parameter in subscription tx's.

I supposed the protocol would just parse the Op_Return of each tx in each new block and look for strings of the appropriate length, and then checksum them against any outstanding hashes that are the subscription triggers for Subscribe tx's that are still in the mempool and yet to expire to be validated.

The simplest model I think is to have a new tx type - "publish secret" or similar. This only needs a single null terminated string containing the secret as the payload (along with type and version as usual). Anyone can broadcast this, it requires no validation (there's no such thing as an incorrect secret, only secrets that don't match any subscription transactions).

In essence "we don't care where the secret comes from, as long as we know what it is".

Matching these secrets against subscription txs is simple - though FYI we'd never process against mempool transactions, we always require a confirmation before we'll do anything with a transaction. A subscribe tx would need to confirm and be added to the state to be matched against a published secret.

Subscribe TX: "when X is published (by anyone), do Y" Publish TX: "publish X"

(X being the secret)

Seems fairly straight forward in that regard, plus nice and flexible :)

[patrickdugan]

To quote Monty Burns:

Excellent

We should hack a prototype of this as soon as possible.

Then take a week or two as needed to furbish free of killer bugs and it better code form.

And we'll be testing it on testnet and reg with an RC of 0.11 when the trains come in.

[patrickdugan]

There is a security issue of detecting "bad behavior" in terms of a validator on a Credits chain, but I think that can be delegated into the logics on the other chain.

If there is something that is essential to supporting detection of secret publications that are the result of defection from the protocol on a parallel chain, but not consensus changing, we could add it in on the 0.11.1 patch.

Perhaps it's worth considering for this first go, that the publish secret tx also contain at least one other signature, and then a Credits chain where someone has defected and published a secret prematurely or for outsized gain, at least it would have to be done without the other signatures of the 3 other validators, and thus the Credits protocol could penalize the perpetrator. That's the core idea behind byzantine fault tolerance in these proof-of-bond chains (also Tendermint), you require validators to post capital to the level where they cannot profitably cheat.

Thus the app that provides the money market for Omni tokens to be used as collateral for Credits chains would need to have N validators that scale so the capital burden of participating can be distributed as much as possible. Apps could have other hashes that are subscribed to in the payload rather than the header of a subscribe tx, where if the app is attacked, the capital on Omni is subject to a second contract that keeps it reserved and sorts it. Thus the Collateral Market Contract would contain a recovery contract for anyone who cheats to get their capital moved rather than zipped.

Maybe I am seeing nails everywhere, maybe this isn't a scalable model, we will quickly find out in testing.

[zathras-crypto]

If we start requiring signatures from specific validators we're back to Oracles and having to trust some entity(s). The good thing about a secret is that it's entirely trustless - we don't have to trust the source of the secret, only that the secret is valid.

I understand what you're saying but I think the protection against bad actors should happen outside the protocol - it provides the maximum flexibility for integrators and app developers to design their own logic. In the scenario you describe above if you wanted multiple validators on a Credits chain to agree before the secret is published, you would simply only give each validating node a part of the secret. If five validators each have one fifth of the secret, they would all need to agree to reveal their portion of the secret (validate) so that the whole secret could be published on the Omni Layer.

[patrickdugan]

We should try it raw and see what kind of attacks are possible in a testnet environment, then if we need to alter the protocol in a non-consensus changing way to create secondary catches for app developers to work in, we can do it in 0.11.1

[patrickdugan]

Trying to puzzle out how detection of a defector could be handled on the Credits side.

If a secret is published and hasn't yet been inscribed on the app-chain, then there's been a defection, simple enough.

But how to detect who it was?

One idea:

If there are 4 validators, and each has to sign in order to generate the secret, which then is immediately hashed, none of the validators individually could know the secret before the second generation of it.

Is that correct? Could someone hack the client to cheat?

Another issue - parameterizing the secret.

If you have to have the hash to sign up on Omni for what happens later, then the secret used to generate it must be precisely the same as that which follows. This makes it impossible to embed any params based on what happens historically.

So the only thing I can think of there is that the Publish Secret tx allows for a JSON payload to be embedded in it such that Omnicore Nodes, having read the corresponding hash for a Subscribe tx that includes the variable parameters, look for the corresponding JSON payload and push them into the variable slots.

Problem there is, once the secret is published, such as for example on a Credits chain operating an index of futures contract trades, where the final block with the secret includes all the settlement amounts, someone else could jump the gun and publish a tx that contains bad params to pay himself more. So it follows that any Credits nodes depending on Bitcoin interop need to be running Omnicore in parallel and have that broadcast signed on by the validators and pushed with some lead time to the publication on the Credits chain, which can have very fast confirmation times.

This factors the security issues to the outside chain, which adds some developer best practices to the workload of any dApp development, maybe can be solved with modular tools lots of devs can appropriate for their own specific apps. By factoring security issues this way, we minimize prototype time on the Omni side so that's probably a good place to start.

[patrickdugan]

Hmm, if you have to publish a secret to Bitcoin a bit earlier to make sure it propagates before publishing on your own chain, then you can't detect defectors that way, because it's the rule. So, perhaps a simultaneous time-stamped publication on the app-chain and Bitcoin chain, but propagation time uncertainty is an attack window. So do we need logic on our side to detect proximate publications as a possible attack?

[zathras-crypto]

Detecting "defectors" is best left up to the app logic precisely because "defectors" would be a concept in the context of an app, not Omni.

If we wanted Omni itself to have a validation mechanism other than hash/secret, we need to look at a different solution.

In essence we were providing a workflow of:

1) Some entity or application makes available the HASH of SECRET. This obviously assumes the entity or application must know SECRET in order to provide the HASH for it. The entity or application does not reveal the SECRET directly, only the HASH of SECRET. 2) Anyone publishes a SUBSCRIBE to perform ACTION when SECRET to HASH is published. 3) Entity or application from 1) publishes SECRET when whatever its objective (eg validation) has been met 4) Omni Protocol processes ACTIONs from matching SUBSCRIBE txs from step 2

The Omni side of this is quite simple, but the application side (in your example credit chain validation) would likely be quite complex.

Regarding the notions of hacking the client to cheat - the idea is based fundamentally on the fact only the HASH is known to the Omni protocol (and thus any Omni client) when the SUBSCRIBEs are coming in. It's not until some other entity actually publishes the SECRET to the HASH on-chain that the HASH becomes solvable and all matching SUBSCRIBEs that were mined before the SECRET was published then get processed.

[patrickdugan]

Ok I have puzzled out a reasonable compromise.

We have 3 tx types:

SUBSCRIBE

Publish SECRET

Publish HASH

And the first address to Publish HASH becomes the requisite address for publishing the SECRET, errant publications of the SECRET are considered invalid.

The same pubkeys that come together to create the Bitcoin blockchain multi-sig address are the ones used to form the Credits or Tendermint chain initially, with the associated privkeys being used to sign off on validation on the app-chain as well as unanimously publish the SECRET when the time is right. Might less leaky this way, can follow n-of-N logic to handle defection, gives a strong enough tether to Bitcoin to not be prone to attack.

Maybe this is a flag in the Publish HASH tx, and it can also be free-range publishing of the SECRET from any address.

[patrickdugan]

Another optional parameter in Publish HASH, the block height where a SUBSCRIBE to the given HASH ceases to be pending validation upon publication of a SECRET i.e. when the lock-up effect or other pending effect expires.

[patrickdugan]

One last concern, I'm thinking about ASCII notation in the OP_Return, too limited to do anything, can we hash transactions or sets of them in the OP_Return and decipher that elsewhere?

[zathras-crypto]

Sorry, forgot to respond after the meeting, d'oh!

And the first address to Publish HASH becomes the requisite address for publishing the SECRET, errant publications of the SECRET are considered invalid.

This in my opinion defeats the purpose of a HASH/SECRET. If we only allow ADDRESS to give us the HASH and later the SECRET when an objective has been fulfilled, why bother with HASH/SECRET at all? If we're requiring signing from a specific entity that knows both HASH/SECRET then at first glance it seems it provides no more security than ADDRESS simply giving us a signed "objective has been fulfilled" message.

A signing address can be P2SH (m of n signatures required) addressing the requirement for multiple validators to agree.

Another optional parameter in Publish HASH, the block height where a SUBSCRIBE to the given HASH ceases to be pending validation upon publication of a SECRET i.e. when the lock-up effect or other pending effect expires.

Agreed, but I think the 'expiry' parameter should be required for the SUBSCRIBE (prevent people accidentally locking up their tokens forever).

One last concern, I'm thinking about ASCII notation in the OP_Return, too limited to do anything, can we hash transactions or sets of them in the OP_Return and decipher that elsewhere?

Hashing is one way mate, we can't reconstruct a transaction (a chunk of data many hundreds or thousands of bytes) from a 32 byte hash of that data.

NULLDATA (OP_RETURN) is currently 80 bytes max, which is enough for the subcribe TX to contain a standard omni marker & tx/version payload identifying it as subscribe tx along with two 32-byte TXIDs FYI.

We've focused the discussion on how to decide when the 'action' in a subscribe should be fulfilled, what we haven't yet done is looked at what the 'action' can contain, do and its structure, thanks for raising this. Having TXIDs is not a bad idea, but they would need to be special Omni transactions that have been previously broadcast and entered into the state with some kind of tag to mark them as not for processing until a subscribe is fulfilled.

[zathras-crypto]

Hope the above is clear :)

Essentially SUBSCRIBE would become a protocol extension, rather than a specific transaction type. Then any Omni transaction (send, trade, issuance yada yada) could have SUBSCRIBE metadata attached which says "hold this transaction and don't process it until X".

EDIT: actually that wouldn't work, because IIRC you want to reserve funds etc.

[patrickdugan]

If we can chain transactions arbitrarily, by having reference to txids, this could include spawning/sending contract tokens that do reservation as a property of their being held on a given address.

Then the only remaining hazy part is, how to determine tx params at a later date.

Maybe, the subscribe tx is to a template and another subscribe, and that subscribe listens for the settlement params, which is another layer that needs to be controlled by the parallel app-chain.

Why don't we prototype this and then we'll see what we can lego with it in testing for a month or two.

[patrickdugan]

Key question, in the P2SH that stores the subscribe hash, we have 80 bytes, hash is 16 to 34, bitcoin address is 34 usually, I'm thinking we could use non-cryptographic hashes to condense data into a reasonably tight form, for instance tx id format appears to be a hex number, it would be shorted written as base 54 and still retrievable.

If we can cram a subscribe hash, at least 1 transaction id (more than one is better for flexibility's sake) and another subscribe hash, it could support a lot of designs and we'll figure out if they can float security-wise for real scale-financial apps.

[dexX7]

Key question, in the P2SH that stores the subscribe hash, we have 80 bytes, hash is 16 to 34, bitcoin address is 34 usually

Generally, we can store as much data as we want, as this shouldn't be considered as limit (because we also have bare-multisig encoding as fallback etc.). P2SH is not related to the "hash" mentioned above.

[zathras-crypto]

As @dexX7 noted, if we need to push past 80 bytes we can do so with "old-skool" multisig (Class B). Omni Core already selects encoding automatically based on payload size.

FYI a few notes;

P2SH that stores the subscribe hash

P2SH (Pay-To-Script-Hash) is a destination (like an address). Please see https://en.bitcoin.it/wiki/Pay_to_script_hash

hash is 16 to 34

Do you mean transaction hash? If so that's always 32 bytes.

bitcoin address is 34 usually

We only need 20 bytes for a vanilla bitcoin address (160-bit hash)

@dexX7 I wanted to ask if this all made sense to you in terms of translating into a prototype - I'm happy to work on the coding but I'm having difficulty breaking the workflow down into something we can build...

[dexX7]

Essentially SUBSCRIBE would become a protocol extension, rather than a specific transaction type.

Let's keep it simple for a prototype: there could be a mechanism to lock/reserve an amount, which is unlocked, when the secret is somehow provided. It's not very clear to me who does what, i.e. who publishes the secret, but I'm not sure, if this is even very relevant.

[patrickdugan]

Who publishes the secret is extremely relevant, because these proof-of-bond protocols like Credits/Tendermint can only enforce their validation if defectors who have posted collateral and cheat can be detected and penalized by loss of their bonded capital. However in some apps this may not be as essential as in others (such as a futures contract where lots of value is at stake and there's a clear profit motive to cheat).

I've got another issue open where I propose that some smart properties can have the characteristic of bonding N units of xyz other smart property (e.g. 1 unit of the BTC/USD contract token bonds 100 units of Tether, 1 unit of the OMNI/BTC contract bonds 10 units of OMNI ect.).

Ok so let's break down a prototype here:

We've got two versions of this:

Oracle version: a hash is published from an address, possibly multisig, that's a parallel variable in the Bitcoin protocol, and the summary secret publication (or simply a trigger, since the security need for a secret is redundant) triggers whatever transaction payload is associated.

It's A Secret To Everyone Version (any Zelda fans in the audience?): any hash, could even be published on a parallel app-chain, can be subscribed to and its corresponding secret, when published to Bitcoin blockchain, is parsed and triggers the corresponding validation of the transaction payload associated.

Since we're wisely not trying to "jam this in" for v.11 release which we want to get imminently, we're going to have a lot of time to go back and forth with reg/testnet experiments and code iterations on this one.

[msgilligan]

One component that may be useful in this, I believe, is to integrate support for optional output-based balances (i.e. a colored-coins style approach.) We are built on top of Bitcoin and the fundamental unit (atom) of Bitcoin is the UTXO.

The general idea I have is that we can create new property types that are purely output-based but with Omni class C transactions for registering/creating them. We could also allow hybrid properties that have part of their balance address-based and part output-based (UTXO-based). So, for instance you could create a transaction that says, take the following 100,000 SPT and assign them to the Satoshis in the submitted bitcoin transaction. There would also be a way to convert them back. I realize this will complicate consensus accounting, but it may be well worth the benefit.

I should probably open another issue for this. There is Spec issue 189: https://github.com/OmniLayer/spec/issues/189

We might separately want to consider official interoperability with an existing colored-coins protocol. This might allow us to "embrace and extend" some existing colored coins hehe.

[dexX7]

I think it's better to keep track of the specification or feature proposals in the spec repository:

https://github.com/OmniLayer/spec

Please feel free to open a new issue over there.