Add some validity checks for offer messages and oracle announcements#193
Add some validity checks for offer messages and oracle announcements#193Tibo-lg wants to merge 1 commit intodiscreetlogcontracts:masterfrom
Conversation
| - set `change_serial_id` and `fund_output_serial_id` to different values | ||
| - use valid [contract descriptor(s)](./Messaging.md#The-contract_descriptor-Type) within `contract_info`. | ||
| - use valid [contract descriptor(s)](./Messaging.md#The-contract_descriptor-Type) within `contract_info` | ||
| - set `cet_locktime` to the earliest `event_maturity_epoch` amongst all `oracle_event` used included in the `contract_info` |
There was a problem hiding this comment.
Is this strictly necessary? I feel like any time before the earliest oracle announcement is fine (including current block height) so as to avoid any UX issues? (I agree that refund_locktime should be about a week after latest contract execution option)
There was a problem hiding this comment.
Good point thanks! Updated to "less than or equal"
| - The `fund_output_serial_id` and `change_serial_id` are not set to different value | ||
| - Any input in `funding_inputs` is not a BIP141 (Segregated Witness) input. | ||
| - invalid [contract descriptor(s)](./Messaging.md#The-contract_descriptor-Type) are used within `contract_info`. | ||
| - `cet_locktime` is not set to the earliest maturity time of all included oracle events. |
There was a problem hiding this comment.
as I said above, I feel like cet_locktime doesn't need to be so strict (and refund locktime should be far enough away from the latest possible execution)
Tibo-lg
force-pushed
the
more-validity-checks
branch
from
f072b0e to
bcb97ba
Compare
| - set `refund_locktime` sufficiently long after the latest possible release of oracle signatures added to all other delays to closing the contract. | ||
| - set `payout_spk` to a previously unused script public key. | ||
| - set `change_spk` to a previously unused script public key. | ||
| - set `refund_locktime` to a value not too big that both party can be expected to be refunded in a reasonable time-frame (recommended not more than latest contract maturity + 86400 * 14 meaning 2 weeks after latest contract maturity). |
There was a problem hiding this comment.
Perhaps it'd be good to have a recommendation for minimum as well (i.e. recommended no less than 2 days after the latest contract maturity) to give the oracle time to attest in case there are any infrastructure issues
There was a problem hiding this comment.
Yep you're right, looks good 👍
4 participants
Title says it all