I am with the Ergo Foundation.
I wanted to drop an invitation to the BCH developer community to join the UTXO Alliance, a research-oriented group focused on research/collaboration between UTXO blockchains.
Ergo specifically at this point is interested in interop via sidechains, that is one of our development goals in 2022. Let me know if anyone is interested.
To learn a bit more see below.
https://nipopows.com
Interesting, thanks for the links!
Bitcoin Cash is making steps in taking the UTXO model further, and a big step has been made with the 2 upgrades that will be activated in May 2022:
The 2 upgrades are active on testnet4, and there I made an example contract that demonstrates how native introspection opcodes can be used to create a NFT contract, and how weâre still missing something to make that NFT usable.
There are 2 proposals being worked on that would provide the missing piece:
Iâm working on the Group proposal. It would provide the missing piece by providing a TX commitment primitive that could be attached to an UTXO and carried over to descendant outputs. It would allow contracts to prove their genuinity by proving their contract was instanced in the same TX as the commitment and couldnât have been changed since then. Hereâs a mock contract that demonstrates how it could work.
The proposal would extend the outputs with one more field to carry 8 bytes of state accessible through introspection opcodes which could then be used by contracts as an amount, counter, etc. Then, the proposal would natively enforce some essential âcontractsâ to enable P2PKH NFTs, tokens, and satoshi tokens (AKA âcolored BCHâ). This would tick all the boxes of Cardanoâs native tokens, but they could be extended by implementing some contract logic on top of them. Supply could be controlled by a P2SH covenant, while tokens would be âfreeâ P2PKH outputs. Or, we could lock even the token amounts inside the covenant, so all outputs of the group would be P2SH.
Nice to meet you @Armeanio . It will be interesting to see where UTXO Alliance goes. There may be some BCH related organizations or companies who see this and would like to join.
I would be happy to facilitate that for organizations or companies in the BCH community.
I wanted to learn more about UTXO Alliance so I went on to their unofficial Telegram group and started chatting.
I mentioned BCH May '22 upgrade and immediately got back something interesting to read on the subject of introspection:
I think introspection is enabling Turing completeness, as shown in [PDF] Self-Reproducing Coins as Universal Turing Machine | Semantic Scholar , however that does not mean feasibility of certain applications. Sidechaining is another beast, would be good to think jointly what is needed there.
Currently, the alliance consists of Nervos, Cardano, Ergo, Topl, Alephium, and Komodo.
I think theyâre all monolithic projects, but Bitcoin Cash has no single entity representing it so I asked about that:
How would BCH join this alliance when thereâs no âofficialâ entity? Iâm interested as individual. BCH has 6 node teams, I guess any one joining would count as âBCHâ
GRIN raised the same concerns (Nervos and ERGO are PoW btw) - you donât need an official entity in order to join what is mostly a research cooperative
Yes, any of them could join
I also learned thereâs been some work on bridges with Nervos blockchain:
We also have bridged to ETH and BSC. So can move funds across, we have a layer one Cardano bridge in progress too
Similarly to SmartBCH, thereâs a L2 EVM chain, bridged using PoA:
Layer one POW (Mirana), Layer 2 POA (Godwoken) Gaming side chain POA (Axon) (Coming soon). We are a modular system all built by the same team
they all work in unison
After some more talk, got another interesting read, on Nakamoto Consensus:
Checkout the NC max peer related study of the new Satoshi Nakmoto consensus mechanism to discourage selfish miners and limit uncle/orphan blocks
NC-Max: Breaking the Security-Performance Tradeoff in Nakamoto Consensus â NDSS Symposium
More talk, and another great read, on the UTXO blockahin model:
https://zero2ckb.ckbapp.dev/learn
The Nervos team calls UTXOâs âcellsâ and refers to them as containers of blockchain state. The logical framework describing these cells flows well.
To own a cell, you need tokens. The number of tokens equals the size of the cell. 1 CKB = 1 Byte.
nice⌠we kinda have that with the âdust limitâ on UTXOs, but itâs fixed at 546b/UTXO not 1sat/1b as you have there
turns out this is really important to have right incentives
our token UTXOs will still need BCH dust to exist, and that will give incentive to clean up UTXOs of zombie tokens
The answer is simple: code is in another cell!
We know that the data field of the cell can contain arbitrary data, so we can put the real code in the data field of another cell and implement this cell as a dependency to a transaction. This dependency cell is called âdep cellâ.
When unlocking a cell, we simply import the dep cell, and CKB will match the hash of the data in the dep cell with code_hash to find the corresponding code.
amazing, we call this âsidecarâ contract design pattern, only made possible with Mayâ22 upgrade, allows us to emulate OP_EVAL
Then I learned about eUTXO model, âeâ as âextendedâ: The Extended UTXO Model - IOHK Research
In this paper, we answer this question affirmatively. We present Extended UTXO (EUTXO), an extension to Bitcoinâs UTXO model that supports a substantially more expressive form of validation scripts, including scripts that implement general state machines and enforce invariants across entire transaction chains.
Damn, this sounds much like Group Tokens / Unforgeable Categories / CashTokens we have been working on
when I got involved I just wanted tokens but we figured out it solves a more fundamental problem of enforcing those invariants
and another read on the âcellâ model:
Plus, a word on motivation for the alliance:
Thereâs a ton to dive into in regards to UTXO and itâs capacities - hence the alliance
Had some more chat about aims of the alliance and BTC, and finally got one more link, about bridge technology:
My conclusion: this alliance is for real, even though itâs still not clear to me what it means to âjoinâ 
I used the application form and got an automated e-mail back from utxo (at) iohk.io so I guess that is the main organization behind it.
Even if itâs just a marketing effort it could be valuable for BCH image, because I believe that BCH outsiders still think of BCH as âjust pre-segwit BTC, but with big blocksâ and BCH is clearly more than just that, because weâre continuing to develop Bitcoinâs UTXO model - but people donât know what weâre building. For example the Introspection/BigInt enabled so much, and itâll take time until this information will be known by a broader set of people.
Some more info for future reference, other chains mempool features interested me. Apparently Nervos (CKB) supports block header introspection and their mempool code can handle evicting a whole DAG of TXes if an ancestor becomes invalid due to reorg.
matt.bit 
, [12/8/22 7:11 PM]
@bitcoincashautist fyi might have a simple way of doing expiring transactions on ckb
Generalized lock script to check conditions in witness args
Include a block height in witness args, attempt to load the header at that height, if call succeeds revert
bitcoincashautist, [12/8/22 7:12 PM]
oh you can load a header? cool, does it have to be mature or can you like load the header of a previous block?
bitcoincashautist, [12/8/22 7:13 PM]
on bch we canât load headers⌠so the only way to have expiry is to implement a covenant clock, and then there would be a spending path to require spending a clock utxo alongside the input and similarly revert
matt.bit , [12/8/22 7:15 PM]
Nope, no maturity required
matt.bit , [12/8/22 7:15 PM]
Any previous block
bitcoincashautist, [12/8/22 7:15 PM]
right, then I guess your mempool somehow must be handling a reorg, in which case it would have to evict all txes that load the header
matt.bit , [12/8/22 7:15 PM]
Yep
matt.bit , [12/8/22 7:15 PM]
The header loads are included like inputs
matt.bit , [12/8/22 7:16 PM]
Explicit
matt.bit , [12/8/22 7:17 PM]
Actually it might invalidate the txâŚ
matt.bit , [12/8/22 7:17 PM]
Not sure⌠@TannrA was saying you could error handle a failed header load
Tannr, [12/8/22 7:19 PM]
Yeah, if you load a header that doesnât get included, other dependencies that use it are thrown away
bitcoincashautist, [12/8/22 7:20 PM]
right, on bch we stick to a principle: the validity of tx canât change with time. The only TX that could change is the coinbase TX, and to avoid mempool mess we require it to mature for 100 blocks before it can be spent
why we like that principle? because then you can safely build huge unconfirmed chains of TXes⌠now imagine if validity would change, then youâd have to potentially evict a huge number of descendant TXes in the mempool, which would increase complexity and reduce performance
bitcoincashautist, [12/8/22 7:21 PM]
do you allow unconfirmed chains? or does the header-referencing TX have to wait inclusion in a block before another TX can spend its outputs?
Tannr, [12/8/22 7:22 PM]
You can chain together a bunch of unconfirmed txs
bitcoincashautist, [12/8/22 7:23 PM]
so I guess you optimized your mempool code so it can handle an ancestor becoming invalid (because the header it loads got reorged) and so efficiently pop all descendants from the mempool?
Tannr, [12/8/22 7:23 PM]
While it doesnât create need for sort of garbage collection, the dependencies rly just form a simple DAG so it isnât too difficult to clean up
Tannr, [12/8/22 7:23 PM]
Does *
matt.bit , [12/8/22 7:24 PM]
So header deps is referred to by hash
matt.bit , [12/8/22 7:24 PM]
I was thinking you could do by height
bitcoincashautist, [12/8/22 7:24 PM]
yeah, thatâs how Iâd have proposed it for bch⌠reference it by hash
matt.bit , [12/8/22 7:25 PM]
It makes sense
bitcoincashautist, [12/8/22 7:25 PM]
so you guys can handle unconfirmed chains and a whole DAG getting evicted if an ancestor becomes invalid due to reorg, thatâs pretty cool!
