Iguana Notary Dapp Creates A Notarized TX

Retooled the notary tx statemachine to go from doing a BTC tx and independently a KMD tx with the BTC txid, to making a pair of tx using the same nodes for both.

also cleaned up the code to be more modular and extensible in case new features need to be added.

no crashes with the last version, so it is running stable.

reduced the packet traffic required, also added special handling for different nodes starting at slightly different times.

probably still a few issues left but should have a good chance of getting consistent notary tx on both chains. That is the next functionality level that needs to be achieved as then I can switch from the iguana notary dapp to komodod using the dapp data.

the iguana codebase is quite handy for creating crypto based dapp’s as it has all the bitcoin protocol, in addition to a variety of networking, all written from scratch. which means if it doesnt quite do what it needs to do, I can customize it as needed.

I separated out the notary tx dapp into a special standalone iguana, it uses a different port and morphs it functionality to just do what the notary nodes need done, ie. automatically create right size utxo, run a multiparty notary tx creation protocol for a source chain -> dest chain. The txid of the dest chain is added to the source chain tx and it has all the same signers, so all nodes in the source chain wont even have to query the dest chain (they can if they want, but not required to).

I made it so that the iguana notary dapp can be used for KMD -> BTC and the same dapp can also be used for OTHERCHAIN -> KMD. This means without any additional work, assetchains (and any other chain) can create notarized tx, but instead of having to pay bitcoin txfess, only KMD txfees are needed

by minimizing the code that has to go inside komodod, it minimizes the chances of introducing bugs. Since the notary tx is used if and only if it is there, it made sense to encapsulate it into a separate dapp.

Next up is creating the special tx for election results, since it is closest in mental distance to the notary tx dapp. I want to keep the election process open to change, but we need to lock down how to ratify election results. This way, as a community we can adopt sane election process, but regardless of the process there will be consensus on how it is recorded.

I dont expect it to be happening all the time, but only during times of big changes. So maybe just a way for each notary to submit a command to the iguana notary dapp that their node ratifies a specific election result. In the event a majority of notary nodes (or one third + devteam) approves, it goes into the blockchain as a valid result.

Once this is done, then we flip to the komodo side which has to use the data generated to update the current state which is the list of official notaries and the notarized height. What makes it a bit tricky is that each height could potentially have a different list of official notaries and blocks can come in any order. I think I will limit the change of notaries to a 1000 multiple height. That will allow a much more compact indexed data structure to be used.

So far so good:

https://blockexplorer.com/tx/6574307011ed4954ca5056e68bcd91365562b0fc2ed2d24969f0effefa55acc5 <- BTC notarized tx

http://148.251.57.148:3001/tx/baf8255196a245e73634add62f960e4f946f0021a12d166ae8b249c3668bd748 <- KMD tx with BTC txid encoded in it


Bitcointalk Topic Entry

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

5 − 5 =