rfc(0039): Add cheque lock rfc

[duanyytop]

No description provided.

[jordanmack]

I think the CI configure is enough and @jordanmack how do you feel?

Yes, that is adequate. Just add a line that links to this and describes what it is.

[duanyytop]

I think the CI configure is enough and @jordanmack how do you feel?

Yes, that is adequate. Just add a line that links to this and describes what it is.

#308

[jordanmack]

@duanyytop I will be submitting a pull request with some additional suggestions for readability, but first I have some questions.

1.b.i. It loops through all input cells using the current cheque lock script, if any of the inputs' since is not zero, the cheque lock returns with an error state.

Unlock Rules 1.b.i will error if the receiver is valid and a since was used on one of the inputs. It seems like the transaction would still work if a since was included. What is the reasoning for disallowing the since here?

2.b. If the matching input cells with the receiver lock hash are found, it performs the same check as in 1.b.i and 1.b.ii.
2.b.i. It loops through all input cells using the receiver lock hash, if the matching inputs are not found, the cheque lock returns with an error state

Unlock Rules 2.b checks if any input cells are using the receiver lock and then performs validations from steps 1.b.i and 1.b.ii. Then in step 2.b.i it loops through these same input cells using the receiver lock, and checks for what? It sounds like it checks for the receiver lock cells, then loops through these cells to check if it has the receiver lock again. I do not understand this step.

2.b.ii It loops through all input cells using the receiver lock hash, if the first witness of the cheque cell group is empty(the witness is not WitnessArgs or the lock of WitnessArgs is empty)

Unlock Rules 2.b.ii appears to be incomplete. I do not understand this step.

[duanyytop]

Unlock Rules 1.b.i will error if the receiver is valid and a since was used on one of the inputs. It seems like the transaction would still work if a since was included. What is the reasoning for disallowing the since here?

For the receiver, when since is equal to 0, he/she can claim the asset without waiting for a period of time.

Unlock Rules 2.b checks if any input cells are using the receiver lock and then performs validations from steps 1.b.i and 1.b.ii. Then in step 2.b.i it loops through these same input cells using the receiver lock, and checks for what? It sounds like it checks for the receiver lock cells, then loops through these cells to check if it has the receiver lock again. I do not understand this step.

This rule does seem redundant and can be deleted.

Unlock Rules 2.b.ii appears to be incomplete. I do not understand this step.

Indeed, a paragraph should be added at the end: “the cheque lock returns with an error state“

[jordanmack]

@duanyytop I'm rewriting part of the description for clarity. I want to make sure I understand the functionality and intent correctly.

The Cheque Lock can match against a secp256k1-blake2b-sighash-all signature, which means the default lock must be used when a signature is provided to unlock.

The Cheque Lock can also match against a lock hash from the inputs, in which case it can be any form of lock script since it is just a hash that is being checked.

Is the intent here to encourage the use of the default lock only, or should it be stated that smart contracts could also use the Cheque Lock when signatures are not provided?

[duanyytop]

@duanyytop I'm rewriting part of the description for clarity. I want to make sure I understand the functionality and intent correctly.

The Cheque Lock can match against a secp256k1-blake2b-sighash-all signature, which means the default lock must be used when a signature is provided to unlock.

The Cheque Lock can also match against a lock hash from the inputs, in which case it can be any form of lock script since it is just a hash that is being checked.

Is the intent here to encourage the use of the default lock only, or should it be stated that smart contracts could also use the Cheque Lock when signatures are not provided?

The Cheque Lock only supports secp256k1-blake2b-sighash-all signature , so the sender and receiver can only use secp256k1-blake2b-sighash-all lock script to withdraw and claim the assets.

[jordanmack]

The Cheque Lock only supports secp256k1-blake2b-sighash-all signature , so the sender and receiver can only use secp256k1-blake2b-sighash-all lock script to withdraw and claim the assets.

When no witness is provided, it attempts to match against the input lock hashes, as shown here. I do not know if we have an official name for this pattern. I've been calling it an "authorization piggyback". Since it is just matching the lock hash, it could be a lock of any type, including a lock script that is part of a smart contract.

1. Is my understanding of this correct?
2. Should I indicate that Cheque Lock only be used with secp256k1-blake2b-sighash-all to avoid complications, even if it could technically be used with different locks?

[duanyytop]

The Cheque Lock only supports secp256k1-blake2b-sighash-all signature , so the sender and receiver can only use secp256k1-blake2b-sighash-all lock script to withdraw and claim the assets.

When no witness is provided, it attempts to match against the input lock hashes, as shown here. I do not know if we have an official name for this pattern. I've been calling it an "authorization piggyback". Since it is just matching the lock hash, it could be a lock of any type, including a lock script that is part of a smart contract.

1. Is my understanding of this correct?
2. Should I indicate that Cheque Lock only be used with secp256k1-blake2b-sighash-all to avoid complications, even if it could technically be used with different locks?

lock:
    code_hash: cheque lock script
    args: <20 byte receiver secp256k1-blake2b-sighash-all lock hash> <20 byte sender secp256k1-blake2b-sighash-all lock hash>

The Cheque Lock script data structure determines that the lock hash you are talking about can only be secp256k1-blake2b-sighash-all lock hash. And the reason why only secp256k1-blake2b-sighash-all is supported is determined by the requirements at that time.

[jordanmack]

@duanyytop A few more questions in relation to Unlock Rule 2.b.ii:

I see that within claim::validate() it locates the witness for the receiver input cell, but then within helpers::check_witness_args() it does not validate the signature at all, and just ensures that any signature exists.

1. What is the reason for checking that a signature exists, but not actually validating the signature?
   2. Why check for a signature at all when doing an authorization piggyback since you are relying on the logic of the input's lock, and you cannot be certain that the lock is designed to require a signature to unlock?

Edit: I wrote these questions before I saw your previous reply posted. If only secp256k1-blake2b-sighash-all is supported, then question 2 is irrelevant.

[duanyytop]

1. What is the reason for checking that a signature exists, but not actually validating the signature?

If the WitnessArgs is not empty for secp256k1-blake2b-sighash-all, the signature will be verified by the receiver lock script and Cheque Lock does not need to do repetitive things.

[jordanmack]

If the WitnessArgs is not empty for secp256k1-blake2b-sighash-all, the signature will be verified by the receiver lock script and Cheque Lock does not need to do repetitive things.

Yes, this is the crux of my question. The Cheque Lock does not need to do a repetitive signature validation that is already done by the receiver lock script. So why does it check that WitnessArgs is not empty? What is ensured by doing this extra step?

[duanyytop]

If the WitnessArgs is not empty for secp256k1-blake2b-sighash-all, the signature will be verified by the receiver lock script and Cheque Lock does not need to do repetitive things.

Yes, this is the crux of my question. The Cheque Lock does not need to do a repetitive signature validation that is already done by the receiver lock script. So why does it check that WitnessArgs is not empty? What is ensured by doing this extra step?

Because there is no hard-coded secp256k1-blake2b-sighash-all lock information in the contract, that is to say, we cannot guarantee that the user must use the secp256k1-blake2b-sighash-all lock. Checking whether the WitnessArgs is empty can avoid the risk of evil to a certain extent (although it cannot be fundamentally eliminated)

[jordanmack]

I have created a new pull request to @duanyytop's branch with my suggested edits.

Preview: https://github.com/jordanmack/duanyytop-rfcs/blob/add-cheque-lock/rfcs/0039-cheque/0039-cheque.md
Pull Request: duanyytop#4
Commit Details: https://github.com/jordanmack/duanyytop-rfcs/commit/2b6b028ddf8a7df10288760a977e5aa9f1f6a0e4

[duanyytop]

@jordanmack any questions?

[jordanmack]

@jordanmack any questions?

No more questions. Everything should be included in the PR.