Skip to main content

dimxy Komodo Team
Antara CC Module Developer

blockchain and cryptoconditions are a great syndicate

Do you have questions for dimxy?

Log in to ask dimxy questions publicly or anonymously.

dimxyKomodo Team
Antara CC Module Developer

Basic validation rules in Antara (cc) development

In each cc module we basically send value from cc inputs to cc outputs.
Cc value lifecycle usually begins when we create cc outputs from normal inputs, then transfer cc value from cc inputs to cc outputs, then cc value can be sent to normal outputs.
It is critical that cc value transfers always go in a controlled way.
It is said very well about this in CCcustom.cpp source file:

IMPORTANT: make sure that all CC inputs and CC outputs are properly accounted for and reconcile to the satoshi. The built in utxo management will enforce overall vin/vout constraints but it wont know anything about the CC constraints. That is what your Validate function needs to do.

Generally speaking, there will be normal coins that change into CC outputs, CC outputs that go back to being normal coins, CC outputs that are spent to new CC outputs.

Make sure both the CC coins and normal coins are preserved and follow the rules that make sense. It is a good idea to define specific roles for specific vins and vouts to reduce the complexity of validation.

So like the built in komodod utxo management ensures tx value flow from inputs to outputs we should provide the same for each cc module. We cannot allow to lose or inject not a satoshi because each cc satoshi might mean a precious resource (if cc tx is a non-fungible token spending for example).

In addition we should remember, that in Antara (cc) modules tx data is usually segregated by an id (aka plan-id or funding-id or also token-id or other kind of id, all of which are usually the txid of the first cc transaction). So we should not allow to accidentally mix cc value from different ids (unless it is done by design).

I would like to propose a basic algorithm to ensure cc value flow in cc txns.

1) function CAmount IsMyCCVout(tx, nvout, evalcode, planid). 'Is my cc vout?' 

This function is for calling when a cc module needs to add cc inputs to a new transaction. IsMyCCVout checks if this nvout in the tx is a valid cc vout, ensuring the following: 

* was the tx validated by the cc module? check if it has a cc vin with this evalcode
* does the tx belong to the planid? check the planid in the tx opreturn
* or is this a first-time creation cc tx? compare its txid with the planid

IsMyCCVout should return the vout amount if it is a valid cc vout, 0 if this is not a cc vout or -1 if it is not my planid.

2) function CAmount CalcCCExactAmount(tx, evalcode, planid). 'Calculate tx cc value balance' 

This function should be called inside the cc validation code. Its task is to calculate total cc inputs value (for cc vins) and total cc output value (for cc vouts) and return the difference to the caller. Good thing is that for checking whether it is my cc input or output this function might call IsMyCCVout function.

So CalcCCExactAmount returns the balance and the validation code should verify that balance to ensure it to the satoshi. For example, if all cc value should go only to cc outputs the returned balance must be checked as 0.

If IsMyCCVout returns '-1' this tx should be rejected as it tries to mix different planids.

This approach allows to handle basic cc value management and could be a core code for all Antara modules. Like the basic komodod code ensures total value flow from inputs to outputs for each transaction, this two functions would allow to do the same for the cc value.

Best Practices
dimxyKomodo Team
Antara CC Module Developer

Using blockchain indexes and coins cache in Antara (cc) validation code

In Marmara cc module I process credit loops organized as a chain of cc transactions. Each subsequent transaction spends a predefined output of the previous transaction.
I have got into problems when in the cc module consensus validation code I enumerated all the transaction in a loop. For enumeration I used spent index to start enumeration with the first tx and find the next one until the spent index would show that no more tx in the loop. The final tx in a loop needed to be just the transaction which was validated.
So the enumerating function worked very well in test chains and in the validation code I always received the complete loop.
But in a big production chain the enumeration function sometimes failed on block synchronization with the remote node and we had forks in the chain.
Studying how the consensus code is called on a block connection I found that the daemon creates a check object for the validation code and put it into a queue. So the check objects are processed in a separate thread. The main thread continues and eventually flushes the updated address and spent indexes to the HDD after which they are available for search. 
Seems, a race condition happened here.
It turned out that it was pretty dangerous to assume that the current tx that is added to a block are updated in the spent index and coins cache and resulted in a very rare occuring error.
I change the validation code to enumerate the loop in backward order from the topmost current tx to the first (for this I did not need to have the current tx in any of indexes or coin cache).
Be carefull with using indexes and coins cache in consensus code: 
I suggest that we never assume that the current validated tx is properly updated in the indexes and cache. Even worse, it might be or not. Use other techniques.

Antara Modules
dimxyKomodo Team
Antara CC Module Developer

Antara modules in simple terms

Antara module development is a core feature of Komodo platform. What is this and what does it allow?

An Antara module is rpc calls plus consensus code. The key technology on top of Antara is built is cryptocondition (cc) library that is embedded into the komodo platform and used to create cc transactions.

A cryptocondition is a logical expression on electronic signatures. For example it allows to spend a transaction output only if the spender's input is signed with a specific pubkey. You might ask that this is a basic feature of any utxo-based blockchain, isn't it? Yes, but cryptoconditions allow something more.  

Any Antara module is assigned a unique eval code that is added to all transaction's input and outputs that is created with the cc library.  

When a transaction cc output is spent with another transaction cc input, the Antara module eval code triggers this module consensus code. The module validation code might check arbitrary rules to allow spending from a cc output in addition to the signature check.

So, your cc transaction is still validated by the basic blockchain rules, but you might also add your module specific validation rules. By that your module's cc transactions become like module data records.  

And indeed any transaction cc output might bear a data payload or you might also store your module data in the last transaction unspendable output marked with OP_RETURN operation code.  

With all this you now have a tool to create your own blockchain applications and have your own application specific consensus mechanisms over basic transactions.  

Isn't that great?

Also, cryptoconditions allow more advanced cryptographic logic than basic blockchain pay-to-pubkey or pay-to-pubkey-hash scripts, like signature thresholds which means that an output could be spent only if M of N keys signed the spending input.

dimxyKomodo Team
Antara CC Module Developer

illegal instruction in GMP lib (solved)

I created a small program to test cryptocondition serialization from json that uses cc_conditionFromJSON function. For this test I built the cc library with the latest secp256k1 lib that now uses GMP lib (for big number). The program worked correctly until I once did shutdown and reboot the VPC where it was installed. After the reboot the program became to be aborted with illegal instruction in some GMP function.

I think the VPC processor architecture was changed (initially it was amd) after that rebooting (evidently the VPC was moved to another host) and GMP code became invalid.
The problem was solved by rebuilding GMP from the configure stage where the arch was redetected.

Could be a problem to use programs with GMP lib in the virtual environments

dimxyKomodo Team
Antara CC Module Developer

CCtxidaddr issue

When working on marmara project where CCtxidaddr function is used a lot I got into issue with cc_conditionFromJSON function which returned NULL when I passed into it a cryptocondition with a public key created with CCtxidaddr (only some of CCtxidaddr pubkeys caused this error). Discovering showed that an internal function in secp256k1 library named secp256k1_ec_pubkey_parse actually failed on such pubkeys. So it could mean that some of the pubkeys created with CCtxidadds could be invalid. The pubkey in ECDSA algorithm is a point on the elliptic curve. As txid is created by a hash function that has nothing to do with ECDSA it could create values that are not on the curve.

There is a discussion here  whether it could be attacks on pubkeys that are not on the curve. It stated that such attacks seemed impractical but it is still advised to use valid key material in applications and check that the used points belong to the curve because this might prevent fault attacks (which is true in our case when a cc library json function fails on invalid pubkeys!). Simple tweaking of any single byte of a txid pubkey allows to quickly and deterministically obtain a valid pubkey. So I suggest making a new version CCtxidaddr_tweak() function and use it further.

I also checked the burn pubkey ("02deaddeaddeaddeaddeaddeaddeaddeaddeaddeaddeaddeaddeaddeaddeaddead") which we use for burning tokens - it is also parsed as invalid. So we can tweak it too and get the valid constant burning pubkey.

No more items...