-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(core)!: include issuer public key in contract id hash #4239
fix(core)!: include issuer public key in contract id hash #4239
Conversation
de48edb
to
c10059e
Compare
ef36e04
to
d9b4a43
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have my questions in allowing duplicate contracts.
If this is all the same:
contract_name
contract_issuer
contract_spec
Is it not essentially the same asset, just with a different owner? Do we want to allow this? I am thinking no, why do we want to allow copes of an asset to existing? If you change the name or the spec, it's going to be unique?
Another question I have is, is the contract def UTXO always going to stay static and never change? If it is, it kinda becomes hard to validate contract_id
@SWvheerden There are a few ways to do this, but I dont think we want to tie the contract_id just to the contract_name as that functions as more of a label. This PR is more about tying the contract to a specific UTXO. i.e. you publish a contract utxo and you get a new unique contract_id on-chain. Also removing the need for the issuer to generate a new public key if a contract with the same "label" (contract_name) is used. However, the issuer generating a new key is not unreasonable. I think I will change the PR to only include the definition UTXO data for now as that is not controversial. |
d9b4a43
to
7acae6a
Compare
7acae6a
to
dfc70a8
Compare
Description
and commitmentin contract hashMotivation and Context
The contract ID should be a hash of all contract definition data. Adding the commitment allows contracts with the same name label to exist on the blockchain at the same time.The contract name functions as a label and does not have to be globally unique. This PR essentially makes the
<issuer_pk, contract_name> pair unique.
How Has This Been Tested?
Existing tests, manually