Closed XuJiandong closed 3 months ago
HeyΒ @XuJiandong, thank you for publicly expressing your interest in iCKB by reviewing the proposal and L1 scripts source code, I personally appreciate a lot!! π
This is an interesting hypothetical failure mode, pretty neat, keep this kind of issues coming!!
Withdrawal cell 1 could be redirected to user 2, while withdrawal cell 2 could be redirected to user 1.
Since the entire transaction is assembled by the user, it may not be an issue, depending on the specific user scenario.
Exactly, in a non-OTX setting this doesn't represent an issue as you noticed, once both users sign the tx, it's all good.
In a CoBuild OTX scenario, assuming:
Then it would be prevented by the CoBuild OTX validation.
To reply to the updated title:
Can two pair of owned owner cells interfere with each other validation?
Let's take the example you made and split it into two different txs consuming the created cells:
Inputs:
- Nervos DAO phase 1 withdrawal, owned cell 1:
Type: Nervos DAO
Lock: Owned role
- Owner cell 2:
Type: Owner role of owned cell 2
Lock: A lock that identifies the user 2
Inputs:
- Nervos DAO phase 1 withdrawal, owned cell 2:
Type: Nervos DAO
Lock: Owned role
- Owner cell 1:
Type: Owner role of owned cell 1
Lock: A lock that identifies the user 1
Nope. Both Tx A and Tx B would fail validation as the owner metapoint and owned metapoint would differ.
In Tx A the loaded metapoints would be:
Metapoint { tx_hash : Some(TX_HASH), index : 0}
Metapoint { tx_hash : Some(TX_HASH), index : 2}
In Tx B the loaded metapoints would be:
Metapoint { tx_hash : Some(TX_HASH), index : 2}
Metapoint { tx_hash : Some(TX_HASH), index : 0}
So both txs would fail the Mismatch check.
Limit Order Mint and Melt work in the exact same way, except that it's the limit order cell that keeps track of the master cell.
@XuJiandong does all this sound reasonable?
"Owner cell 1" and "Owner cell 2" are identical except for the lock
field. I believe they can be used interchangeably.
I understand, it's not easy to see.
"Owner cell 1" and "Owner cell 2" are identical except for the lock field.
This statement is inaccurate and it's also the root of the current issue.
Given your Mint tx:
Outputs:
- Nervos DAO phase 1 withdrawal cell 1:
Type: Nervos DAO
Lock: Owned role
- Owner cell 1:
Type: Owner role
Lock: A lock that identifies the user 1
- Nervos DAO phase 1 withdrawal cell 2:
Type: Nervos DAO
Lock: Owned role
- Owner cell 2:
Type: Owner role
Lock: A lock that identifies the user 2
They also crucially differ for the outpoints:
Outpoint{tx_hash : TX_HASH, index: 0x1}
Outpoint{tx_hash : TX_HASH, index: 0x3}
I believe they can be used interchangeably.
Nope. The metapoints that I showed you before are calculated from the cells outpoints, that's why they cannot be used interchangeably.
Please, take some time to review owner metapoint and owned metapoint implementations.
At any rate, don't believe me, don't believe the code, try it out with a tx :hugs: (Let me know if I can help on this, ok?)
Side note: metapoint is nice code abstraction and it doesn't appear in the proposal. Metapoint is just an extension of outpoint, where the metapoint can also reference the current tx outputs, hence the use of Option:
My conclusion: This approach works if they are in the same transaction but won't work across different transactions. Let's study my case provided before(in one transaction).
- Nervos DAO phase 1 withdrawal cell 1:
Type: Nervos DAO
Lock: Owned role
This step applies the following setting: metapoint_2_accounting[tx_hash + 0].owned = 1
- Owner cell 2:
Type: Owner role
Lock: A lock that identifies user 2
And this sets: metapoint_2_accounting[tx_hash + 2].owner = 1
- Nervos DAO phase 1 withdrawal cell 2:
Type: Nervos DAO
Lock: Owned role
And this sets: metapoint_2_accounting[tx_hash + 2].owned = 1
- Owner cell 1:
Type: Owner role
Lock: A lock that identifies user 1
Finally, this applies: metapoint_2_accounting[tx_hash + 0].owner = 1
It can pass the following validation:
if metapoint_2_accounting
.into_values()
.any(|a| a.owned != 1 || a.owner != 1)
{
return Err(Error::Mismatch);
}
It doesn't work if 4 cells are split into 2 tx.
Yup yup, that's 100% how this validation works, congrats @XuJiandong! π₯³ππ
While this concept is still hot, you may want to proceed to Limit Order Script.
If you have no more question about this, feel free to close the current issue.
Thank you again @XuJiandong for taking your time to understand and review the iCKB Scripts π
Let's assume we have multiple owned owner cells during the minting stage:
The owner cell 1 and owner cell 2 share same relative index(-1). By intent, withdrawal cell 1 belongs to user 1, and withdrawal cell 2 belongs to user 2. However, during the melting stage, the following can be done:
Withdrawal cell 1 could be redirected to user 2, while withdrawal cell 2 could be redirected to user 1.
Since the entire transaction is assembled by the user, it may not be an issue, depending on the specific user scenario.