Change Details

Currently, if a user creates two identical AgoraPartial offers (i.e. same makerPk, same price, same token ID, etc.), an attacker could spend those offers in one single transaction, burning the tokens of one of them. The solution to fix this is to (ab)use the nLockTime field sort-of as a unique identifier, allowing two identical offers to still differ by enforcing a different locktime. This is done by using 9th field (nLockTime) in the BIP143 sighash and byte-comparing it to the locktime specified in the Script. This adds exactly 8 bytes to each script. Using OP_CHECKLOCKTIMEVERIFY doesn't make sense here, as it can only be used for a relation (>) between locktimes, not equality. This gives each offer around 1.2B (past) locktimes to choose from. Users should use `Agora.selectParams` for this, which ensures uniqueness of offers. This means that in practice, users of the ecash-agora library won't have to deal with the locktime value, just like they don't have to deal with the approximated values. We require access to Chronik to select a unique locktime though, therefore this can't be done as part of e.g. AgoraPartial.approximateParams. Another option other than enforcing the locktime would be to enforce the Agora input to always be the first input of the transaction, however, this would clash with potential ad inputs (required by SLP), which are currently already required to be at first position. We could require the Agora input to be last, which would work. The downside however is that each transaction would grow by around 100B to enforce this, as the ANYONECANPAY trick doesn't work anymore. We can just fix this issue in the open, as nobody is using AgoraPartial offers yet. We also don't need an update strategy, because nobody (to our knowledge) made any such transactions on mainnet yet.

Currently, if a user creates two identical AgoraPartial offers (i.e. same makerPk, same price, same token ID, etc.), an attacker could spend those offers in one single transaction, burning the tokens of one of them. The solution to fix this is to (ab)use the nLockTime field sort-of as a unique identifier, allowing two identical offers to still differ by enforcing a different locktime. This is done by using the 9th field (nLockTime) in the BIP143 sighash and byte-comparing it to the locktime enforced in the Script. This (only) adds exactly 8 bytes to each script. Using OP_CHECKLOCKTIMEVERIFY doesn't make sense here, as it can only be used for a relation (>) between locktimes, not equality. This gives each offer around 1.2B (past) locktimes to choose from. Users should use `Agora.selectParams` for this, which ensures uniqueness of offers. This means that in practice, users of the ecash-agora library won't have to deal with the locktime value, just like they don't have to deal with the approximated values. We require access to Chronik to select a unique locktime though, therefore this can't be done as part of e.g. AgoraPartial.approximateParams. Another option other than enforcing the locktime would be to enforce the Agora input to always be the first input of the transaction, however, this would clash with potential ad inputs (required by SLP), which are currently already required to be at first position. We could require the Agora input to be last, which would work. The downside however is that each transaction would grow by around 100B to enforce this, as the ANYONECANPAY trick doesn't work anymore. We can just fix this issue in the open, as nobody is using AgoraPartial offers yet. We also don't need an update strategy, because nobody (to our knowledge) made any such transactions on mainnet yet.

Currently, if a user creates two identical AgoraPartial offers (i.e. same makerPk, same price, same token ID, etc.), an attacker could spend those offers in one single transaction, burning the tokens of one of them. The solution to fix this is to (ab)use the nLockTime field sort-of as a unique identifier, allowing two identical offers to still differ by enforcing a different locktime. This is done by using the 9th field (nLockTime) in the BIP143 sighash and byte-comparing it to the locktime specifienforced in the Script. This (only) adds exactly 8 bytes to each script. Using OP_CHECKLOCKTIMEVERIFY doesn't make sense here, as it can only be used for a relation (>) between locktimes, not equality. This gives each offer around 1.2B (past) locktimes to choose from. Users should use `Agora.selectParams` for this, which ensures uniqueness of offers. This means that in practice, users of the ecash-agora library won't have to deal with the locktime value, just like they don't have to deal with the approximated values. We require access to Chronik to select a unique locktime though, therefore this can't be done as part of e.g. AgoraPartial.approximateParams. Another option other than enforcing the locktime would be to enforce the Agora input to always be the first input of the transaction, however, this would clash with potential ad inputs (required by SLP), which are currently already required to be at first position. We could require the Agora input to be last, which would work. The downside however is that each transaction would grow by around 100B to enforce this, as the ANYONECANPAY trick doesn't work anymore. We can just fix this issue in the open, as nobody is using AgoraPartial offers yet. We also don't need an update strategy, because nobody (to our knowledge) made any such transactions on mainnet yet.