Contract Execution Transaction Specification #56
Conversation
|
I'm realizing that the |
| The Offerer/Initiator's output comes first, the Accepter's output comes second. | ||
|
|
||
| Note that this will likely change in the future. | ||
|
|
||
| If either party receives less than the dust limit of `1000 satoshis` for this outcome, then their output is not produced. |
There was a problem hiding this comment.
Should note that both of these are likely to change
There was a problem hiding this comment.
Also, I think this is another good case for where we could use bip-69 for input/output ordering for v0.1
There was a problem hiding this comment.
I think we should discuss if we add CET anchor outputs for v0.1. IMO, as predicting the feerate is even harder to be right for CET given your oracle signatures might be a month from now, network mempools will be far different. With the funding, the feerate negotiated is to be broadcast soon so less likely to be inaccurate.
| - OP_2: 1 byte | ||
| - OP_CHECKMULTISIG: 1 byte | ||
|
|
||
| offer_output: 9 + offer_output_script length bytes |
There was a problem hiding this comment.
Aren't output scripts normalized and thus we know their length ?
There was a problem hiding this comment.
No, there is a final address field in both the offer and accept messages which will specify the SPK used, it does not even have to be segwit.
There was a problem hiding this comment.
p2wpkh is OP_0 <20-byte-hash> vs p2wsh is OP_0 <32-byte-hash>
taproot will be OP_1 <32-byte-pub-key>
|
|
||
| ### Accepter Output | ||
|
|
||
| This output sends funds won by the accepter corresponding to this CET's outcome to the accepter's final address specified in the accept message. |
There was a problem hiding this comment.
Replace address by scriptpubkey. Address are application-level data structs.
There was a problem hiding this comment.
addresses are what are currently specified in the offer and accept messages.
|
|
||
| ### Offerer Output | ||
|
|
||
| This output sends funds won by the offerer corresponding to this CET's outcome to the offerer's final address specified in the offer message. |
There was a problem hiding this comment.
Layout the witnessScript as they're not P2WPKH IIRC?
There was a problem hiding this comment.
not sure what you mean?
There was a problem hiding this comment.
Gotcha, they're freely picked up by offerer/accepter ?
|
|
||
| # Fees | ||
|
|
||
| Fees for the CET are paid for in the Funding Transaction, the following only shows the weight calculation for the largest possible CET. |
There was a problem hiding this comment.
You mean the feerate is the same than the funding transaction ? Might be better like "The fee calculation for CETs is based on the negotiated feerate_per_kw and the expected weight of the transaction."
There was a problem hiding this comment.
No, I mean that the outputs of the CETs are the exact outcome values negotiated and this is accomplished by including their fees in the funding output
There was a problem hiding this comment.
I.e. all fee computation is done when constructing the funding transaction, none is necessary for the CETs/Refund Tx
|
Replaced by #57 |
Took my best shot at specifying the DLC Contract Execution Transaction as things stand right now.
The CET weight has been tested here: https://blockstream.info/testnet/tx/e2678c5646dc79ed0d7e0cc79ef5b0b3539d8ec9e32de1fbb3d854aaab1709f6
Related to #12
Related to #46
TODO: