Looking at this part of the documentation, it's not efficient in terms of TX size.
It have same problem of Ordinal where you need to create 2 TX, where 1st TX create new Taproot address (which have condition to reveal the arbitrary data) and 2nd TX include the arbitrary data.
An Arch Indexer, constantly listening for new bitcoin blocks, checks each transaction in the new bitcoin block to see if it fits within this invocation format:
Code:
OP_FALSE
OP_IF
OP_PUSH "arch"
OP_PUSH "state"
OP_PUSH "insert_state_string_here"
OP_PUSH "psbt"
OP_PUSH "insert_base64_psbt_string_here"
OP_PUSH "inputs"
OP_PUSH "insert_stringified_input_json"
OP_ENDIF
OP_IF
OP_PUSH "arch"
OP_PUSH "state"
OP_PUSH "insert_state_string_here"
OP_PUSH "psbt"
OP_PUSH "insert_base64_psbt_string_here"
OP_PUSH "inputs"
OP_PUSH "insert_stringified_input_json"
OP_ENDIF
It have same problem of Ordinal where you need to create 2 TX, where 1st TX create new Taproot address (which have condition to reveal the arbitrary data) and 2nd TX include the arbitrary data.
You teach me, thanks. I posted the topic because it's one of those being built on Bitcoin that doesn't use Ethereum's virtual machine. Their developers say that with Arch, it's easier to build a protocol with smart contracts on top of Bitcoin because it's UTXO based. I'm not that sure what they meant because if it was easy, would it have been built a long time ago? Or was there simply no motivation to build it?
