On this site we are more of technocrats than protocol experts so I suggest you post your idea over here: https://groups.google.com/g/bitcoindev the new bitcoin-dev mailing list which is full of actual protocol experts, so that they can give meaningful advice on your proposal and more importantly give it a chance to move forward in case people actually like the idea.
Your idea is a bit complex though, so it would help to break it down into multiple smaller documents in order to get everything pushed incrementally.
Topic: OMNI-UTXO for Bitcoin Network (Read 242 times)
Simply, the legitimacy of all on-chain states and operations can be equivalently verified and recorded simultaneously over different consensus spaces, regardless of where they were initiated. That’s why we call the new token protocol OMNI-UTXO.
In my understanding, the new token protocol "O-UTXO"you elaborated serves same purpose as UTXOs, so my question here is, what different purpose does this new protocol serves, or is it the modification of UTXOs?
And also, is O-UTXOs also stored in chainstate database?
As we forge ahead in this ever-evolving domain of decentralized technologies, the OMNI-UTXO protocol stands out as a beacon of potential, aiming to bolster the BTC network ecosystem significantly. The ambitious undertaking of bridging various blockchain consensus spaces under a unified global token protocol not only enhances the fluidity and accessibility of digital assets but also solidifies their security across multiple blockchain infrastructures. This endeavor aligns seamlessly with the original vision of a decentralized and secure digital currency.
The integration of UTXO models across different blockchains promises to mitigate the prevalent issues of fragmentation and centralized vulnerabilities inherent in current bridging methods. Your approach to creating a synchronized recording mechanism, rather than mere token transfers, ensures that even in the event of disruptions on one chain, the assets remain intact and protected within the Bitcoin network's robust framework. This method not only preserves the integrity of digital assets but also reinforces the trust in decentralized solutions.
By extending the utility of BTC and other cryptocurrencies, enabling them to operate fluidly across a tapestry of blockchain networks, OMNI-UTXO could very well drive greater adoption and utility of blockchain technology. It's a commendable step toward realizing a more interconnected and resilient blockchain ecosystem.
Your focus on ensuring that the legitimacy of all on-chain states and operations can be equivalently verified and recorded, irrespective of their originating blockchain, is a testament to the commitment to maintaining the decentralized ethos that Bitcoin was built upon.
I commend the team behind OMNI-UTXO for their vision and dedication to pushing the boundaries of what's possible within the blockchain space.
#LigoPunks
The integration of UTXO models across different blockchains promises to mitigate the prevalent issues of fragmentation and centralized vulnerabilities inherent in current bridging methods. Your approach to creating a synchronized recording mechanism, rather than mere token transfers, ensures that even in the event of disruptions on one chain, the assets remain intact and protected within the Bitcoin network's robust framework. This method not only preserves the integrity of digital assets but also reinforces the trust in decentralized solutions.
By extending the utility of BTC and other cryptocurrencies, enabling them to operate fluidly across a tapestry of blockchain networks, OMNI-UTXO could very well drive greater adoption and utility of blockchain technology. It's a commendable step toward realizing a more interconnected and resilient blockchain ecosystem.
Your focus on ensuring that the legitimacy of all on-chain states and operations can be equivalently verified and recorded, irrespective of their originating blockchain, is a testament to the commitment to maintaining the decentralized ethos that Bitcoin was built upon.
I commend the team behind OMNI-UTXO for their vision and dedication to pushing the boundaries of what's possible within the blockchain space.
#LigoPunks
Looking at your repository, I find omni interesting as a protocol to bookmark all blockchains, I have a few questions
1. everyone can use the synchroniser, so how is the synchroniser incentivised, as it seems that proof submission requires gasfee
2. you mentioned that btc and evm including polkdot are synchronised at the same time, so I submit a transfer tx on btc and then I have to wait for 10 mins right, isn't that very inefficient of him then
3. also, i have doubts about its security as the sync seems to be run by everyone, so can i run a lot of sync and then do a double spend
There is also the question of whether users need to submit their own nonce if they make a transfer on bitcoin, and then whether this is a bad place to work out because people don't know what the current nonce is, and the nonce overlap or even the transaction will fail. So wouldn't this protocol be very inconvenient to transfer token on bitcoin? Looking forward to your answer.
1. everyone can use the synchroniser, so how is the synchroniser incentivised, as it seems that proof submission requires gasfee
2. you mentioned that btc and evm including polkdot are synchronised at the same time, so I submit a transfer tx on btc and then I have to wait for 10 mins right, isn't that very inefficient of him then
3. also, i have doubts about its security as the sync seems to be run by everyone, so can i run a lot of sync and then do a double spend
There is also the question of whether users need to submit their own nonce if they make a transfer on bitcoin, and then whether this is a bad place to work out because people don't know what the current nonce is, and the nonce overlap or even the transaction will fail. So wouldn't this protocol be very inconvenient to transfer token on bitcoin? Looking forward to your answer.
Hey pc9527zxx,
Nice questions.
1. when submitting the transactions onto different chains, the gas fee is a concerned problem. And this is why we are developing an Execution Layer (zk-based) to make rollups currently. Here we just focus on the protocol itself.
2. basically, the second question is the second point when making a product, an Execution Layer (we may call it a special layer2) will improve. What you concern, the inefficiency, is what we concern too.
3. the double-spend attacks can be detected by verifiable fraud-proof, as once the same input is spent twice associating to different outputs, and as the signature is non-repudiation, it will be detected. But indeed an additional cost is the necessary waiting time.
the last question is about the `nonce`.
if we use the account-based model, the `nonce` is necessary. And this is one of the reasons why now we are trying the UTXO-based version of the protocol instead.
According to your question about the `nonce` itself, as the account-based model is managed by smart contracts, when users submit a new transaction, they can get their working nonce on any chain where the protocol is deployed.
Looking at your repository, I find omni interesting as a protocol to bookmark all blockchains, I have a few questions
1. everyone can use the synchroniser, so how is the synchroniser incentivised, as it seems that proof submission requires gasfee
2. you mentioned that btc and evm including polkdot are synchronised at the same time, so I submit a transfer tx on btc and then I have to wait for 10 mins right, isn't that very inefficient of him then
3. also, i have doubts about its security as the sync seems to be run by everyone, so can i run a lot of sync and then do a double spend
There is also the question of whether users need to submit their own nonce if they make a transfer on bitcoin, and then whether this is a bad place to work out because people don't know what the current nonce is, and the nonce overlap or even the transaction will fail. So wouldn't this protocol be very inconvenient to transfer token on bitcoin? Looking forward to your answer.
1. everyone can use the synchroniser, so how is the synchroniser incentivised, as it seems that proof submission requires gasfee
2. you mentioned that btc and evm including polkdot are synchronised at the same time, so I submit a transfer tx on btc and then I have to wait for 10 mins right, isn't that very inefficient of him then
3. also, i have doubts about its security as the sync seems to be run by everyone, so can i run a lot of sync and then do a double spend
There is also the question of whether users need to submit their own nonce if they make a transfer on bitcoin, and then whether this is a bad place to work out because people don't know what the current nonce is, and the nonce overlap or even the transaction will fail. So wouldn't this protocol be very inconvenient to transfer token on bitcoin? Looking forward to your answer.
First of all, welcome to Bitcointalk forum. If you want more people read your idea, it would be great if you convert markdown to BBcode to make it's easier to see/read.
Is this really for Bitcoin network? Unlike Ethereum which use account-based address, Bitcoin use UTXO-based address.
#### Data structure of O-UTXO
The structure is like this
```js
{
account: ''
amount: ''
}
```
The structure is like this
```js
{
account: '
amount: '
}
```
Is this really for Bitcoin network? Unlike Ethereum which use account-based address, Bitcoin use UTXO-based address.
I will convert to BBcode ASAP.
Yes, this is for Bitcoin. As the titile OMNI-UTXO said, the transactions will be UTXO based.
Code:
{
account: ''
amount: ''
}
account: '
amount: '
}
This is the data structure of an UTXO. The account is changed to address, which may confuse
First of all, welcome to Bitcointalk forum. If you want more people read your idea, it would be great if you convert markdown to BBcode to make it's easier to see/read.
Is this really for Bitcoin network? Unlike Ethereum which use account-based address, Bitcoin use UTXO-based address.
#### Data structure of O-UTXO
The structure is like this
```js
{
account: ''
amount: ''
}
```
The structure is like this
```js
{
account: '
amount: '
}
```
Is this really for Bitcoin network? Unlike Ethereum which use account-based address, Bitcoin use UTXO-based address.
We are trying to build an interesting way called OMNI-UTXO protocol to improve the ecosystem of the BTC network.
Summary
Decentralized ledger techology(DLT) is the foundation of Web3, and now we are considering whether we can build a new kind of decentralized ledger over different consensus spaces of chains. In particular, we define a new global token protocol based on the UTXO transaction model and use the Bitcoin network and other currently stable blockchains as abstract nodes to record the states of the new global decentralized ledger together. As a result, the security of the new kind of token will be guaranteed by both the Bitcoin network and other blockchains like Ethereum, so that users can keep the integrity of their tokens and more diverse applications will be introduced into the BTC ecosystem as the application businesses can be deployed anywhere but the settlements are recorded on BTC.
Simply, the legitimacy of all on-chain states and operations can be equivalently verified and recorded simultaneously over different consensus spaces, regardless of where they were initiated. That’s why we call the new token protocol OMNI-UTXO.
Motivation
We think the first thing to extend the BTC ecosystem is for assets issued on the BTC network to be able to circulate throughout the web3 world. But current methods have some problems.
The core of the OMNI-UTXO protocol is recording synchronized instead of bridging, even if all the other chains break down, as long as the Bitcoin network is still running, the user’s assets will not be lost.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
O-TX
It is short for the transaction of OMNI-UTXO.
Data structure of O-TX
The structure is like this
[/list][/list]
The signature MAY be computed like this
O-TX types
There are 3 types of O-TX
O-TXID
It is short for OMNI-UTXO transaction ID and is generated according to the inputs of O-TX.
O-TXID MAY be generated as following
O-UTXO
O-UTXO is short for the UTXO of OMNI-UTXO.
The UTXO transaction model is used for OMNI-UTXO, namely all tokens are stored in the unspent O-TX outputs. To distinguish the UTXO of OMNI-UTXO from the UTXO of BTC, we call the former the `O-UTXO`. Anyone who has the private key to the O-UTXO can spend it.
Index of O-UTXO
An O-UTXO is indexed by the O-TXID: O-INDEX, in which O-TXID is the id of the O-TX from which the O-UTXO is generated, and the O-INDEX is the index of the O-UTXO in the transaction.
Constraint
The balance amount of inputs MUST be equal to the balance amount of outputs
Execution Layer
The main purpose of the Execution Layer is to guarantee all chains have executed the same transactions and have the same state. In addition, the Execution Layer can batch and execute OMNI-UTXO transactions(o-transactions for short) in a period, generate zk-proof, and commit it together with state changes to chains, to improve the performance of OMNI-UTXO.
Interpreter
An interpreter SHOULD be introduced to execute O-TXs, due to the Bitcoin network not being able to deal with O-TXs. The transaction data that the interpreter executes are all recorded on the Bitcoin network, so anyone can restore the state of OMNI-UTXO tokens, to check if the interpreter functions well.
Rationale
Architecture
Figure.1 Architecture
https://raw.githubusercontent.com/Omniverse-Web3-Labs/Omniverse-DLT-Introduction/main/docs/assets/omni-utxo.png
With the Omni-UTXO protocol, everyone can issue global tokens that can be used on multi-chains by leveraging scripts on Bitcoin, smart contracts, or similar mechanisms on other existing blockchains.
As shown in [Figure.1](#architecture).
- Privacy transactions can be easily supported
- High concurrency, because one transaction can include many inputs and outputs
Workflow
Suppose there is
- If the inputs and outputs of `tx-e` match, the total amount of outputs is 1000
- Smart contracts verify proofs and record new states.
More Information
More information can be found at the GitHub of Omni Labs.
Contact:
Summary
Decentralized ledger techology(DLT) is the foundation of Web3, and now we are considering whether we can build a new kind of decentralized ledger over different consensus spaces of chains. In particular, we define a new global token protocol based on the UTXO transaction model and use the Bitcoin network and other currently stable blockchains as abstract nodes to record the states of the new global decentralized ledger together. As a result, the security of the new kind of token will be guaranteed by both the Bitcoin network and other blockchains like Ethereum, so that users can keep the integrity of their tokens and more diverse applications will be introduced into the BTC ecosystem as the application businesses can be deployed anywhere but the settlements are recorded on BTC.
Simply, the legitimacy of all on-chain states and operations can be equivalently verified and recorded simultaneously over different consensus spaces, regardless of where they were initiated. That’s why we call the new token protocol OMNI-UTXO.
Motivation
We think the first thing to extend the BTC ecosystem is for assets issued on the BTC network to be able to circulate throughout the web3 world. But current methods have some problems.
- The current paradigm(like token bridges) of using a token by wrapped it on multi-chains seperately lead to fragmentation, and may have some centralization and security issues related to the bridge.
- If BTC was transferred to another chain through the current token bridge, and once the target chain breaks down, it will be very hard to correctly get the BTCs back to the users although locked in the bridge account.
The core of the OMNI-UTXO protocol is recording synchronized instead of bridging, even if all the other chains break down, as long as the Bitcoin network is still running, the user’s assets will not be lost.
- The fragment problem will be solved.
- The security of users' multi-chain assets can be greatly enhanced.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
O-TX
It is short for the transaction of OMNI-UTXO.
Data structure of O-TX
The structure is like this
[/list][/list]
Code:
```js
{
deploy: // Only used when deploying an OMNI-UTXO token
{
name: '',
deployer: ''
},
name: "", // Can be absent when deploying
signature: [''],
inputs: [ // Can be absent when deploying
{
txid: '',
index: '',
address: ''
amount: '',
}
],
outputs: [ // Can be absent when deploying
{
address: '',
amount: ''
},
]
}
```
{
deploy: // Only used when deploying an OMNI-UTXO token
{
name: '
deployer: '
},
name: "
signature: ['
inputs: [ // Can be absent when deploying
{
txid: '
index: '
address: '
amount: '
}
],
outputs: [ // Can be absent when deploying
{
address: '
amount: '
},
]
}
```
The signature MAY be computed like this
Code:
sign(keccak256(CONCAT(BYTES(txid), BYTES(index), BYTES(amount))))
O-TX types
There are 3 types of O-TX
- Deploy: Deploy a new OMNI-UTXO token
Code:
```js
{
deploy: {
name: '',
deployer: ''
}
}
```
{
deploy: {
name: '
deployer: ''
}
}
```
- After deployed, the `asset_id` is RECOMMENDED to be created as following:
Code:
keccak256(CONCAT(BYTES(related native transaction hash), BYTES(output index), BYTES(name), BYTES(owner)))
- Mint:
Code:
```js
{
name: ' like: TEST-TOKEN',
asset_id: '',
signatures: [''],
inputs: [
{
txid: 0x00,
index: 0x00,
amount: ''
}
],
outputs: [
{
address: '',
amount: ''
},
]
}
```
{
name: '
asset_id: '
signatures: ['
inputs: [
{
txid: 0x00,
index: 0x00,
amount: '
}
],
outputs: [
{
address: '
amount: '
},
]
}
```
- The `txid` is fixed to `0x00` in `Mint` operation
- The `index` starts at 0, and increase by 1 after every minting
- Spend: Spend O-UTXOs
Code:
```js
{
name: '',
asset_id: '',
signatures: [''],
inputs: [
{
txid: '',
index: '',
address: '',
amount: '',
}
],
outputs: [
{
address: '',
amount: ''
},
]
}
```
{
name: '
asset_id: '
signatures: ['
inputs: [
{
txid: '
index: '
address: '
amount: '
}
],
outputs: [
{
address: '
amount: '
},
]
}
```
O-TXID
It is short for OMNI-UTXO transaction ID and is generated according to the inputs of O-TX.
O-TXID MAY be generated as following
Code:
```js
keccak256(CONCAT(BYTES(inputs[0].txid, inputs[0].index, BYTES(inputs[0].amount),...))
```
keccak256(CONCAT(BYTES(inputs[0].txid, inputs[0].index, BYTES(inputs[0].amount),...))
```
O-UTXO
O-UTXO is short for the UTXO of OMNI-UTXO.
The UTXO transaction model is used for OMNI-UTXO, namely all tokens are stored in the unspent O-TX outputs. To distinguish the UTXO of OMNI-UTXO from the UTXO of BTC, we call the former the `O-UTXO`. Anyone who has the private key to the O-UTXO can spend it.
Index of O-UTXO
An O-UTXO is indexed by the O-TXID: O-INDEX, in which O-TXID is the id of the O-TX from which the O-UTXO is generated, and the O-INDEX is the index of the O-UTXO in the transaction.
Constraint
The balance amount of inputs MUST be equal to the balance amount of outputs
Execution Layer
The main purpose of the Execution Layer is to guarantee all chains have executed the same transactions and have the same state. In addition, the Execution Layer can batch and execute OMNI-UTXO transactions(o-transactions for short) in a period, generate zk-proof, and commit it together with state changes to chains, to improve the performance of OMNI-UTXO.
Interpreter
An interpreter SHOULD be introduced to execute O-TXs, due to the Bitcoin network not being able to deal with O-TXs. The transaction data that the interpreter executes are all recorded on the Bitcoin network, so anyone can restore the state of OMNI-UTXO tokens, to check if the interpreter functions well.
Rationale
Architecture
Figure.1 Architecture
https://raw.githubusercontent.com/Omniverse-Web3-Labs/Omniverse-DLT-Introduction/main/docs/assets/omni-utxo.png
With the Omni-UTXO protocol, everyone can issue global tokens that can be used on multi-chains by leveraging scripts on Bitcoin, smart contracts, or similar mechanisms on other existing blockchains.
As shown in [Figure.1](#architecture).
- The OMNI-UTXO smart contracts and the scripts of Bitcoin are referred to as Abstract Nodes. The states recorded by the Abstract Nodes that are stored on different blockchains respectively could be considered as copies of the global state, and they are ultimately consistent.
- Execution-Layer is an off-chain execution program responsible for receiving Omni-UTXO transactions, executing transactions, and generating proofs to chains.
- The `UTXO transaction model` is mentioned above. There are several advantages to the UTXO transaction model
- Privacy transactions can be easily supported
- High concurrency, because one transaction can include many inputs and outputs
- The Execution Layer increases transaction capacity, saves gas fees, and reduces transaction latency.
Workflow
Suppose there is
- An OMNI-UTXO token O-TOKEN
- A common user `A` has public key pk-A.
- A common user `B` has public key pk-B.
- An O-UTXO `A1` with O-TXID `txid`, O-INDEX 0
Code:
```js
{
address: 'pk-A',
amount: 1000
}
```
{
address: 'pk-A',
amount: 1000
}
```
- `A` signs `A1` and initiates an O-TX `tx-e`
Code:
```js
{
asset_id: '',
signatures: [''],
inputs: [
{
txid: 'txid',
index: 0,
address: 'pk-A',
amount: 1000,
}
]
outputs: [
{
address: 'pk-A',
amount: 500
},
{
address: 'pk-B'
amount: 500
}
]
}
```
{
asset_id: '
signatures: ['
inputs: [
{
txid: 'txid',
index: 0,
address: 'pk-A',
amount: 1000,
}
]
outputs: [
{
address: 'pk-A',
amount: 500
},
{
address: 'pk-B'
amount: 500
}
]
}
```
- `A` sends `tx-e` to the Execution Layer.
- The Execution Layer checks that
- If the inputs and outputs of `tx-e` match, the total amount of outputs is 1000
- The Execution Layer executes `tx-e` after all checks are passed
- Over a while, the Executor Layer batches transactions executed in the period, generates a related zk-proof and pushes transactions and proofs to L1s.
- L1s verify proofs
- Smart contracts verify proofs and record new states.
- Users can query outputs of `tx-e` on all chosen chains.
More Information
More information can be found at the GitHub of Omni Labs.
Contact:
Jump to: