From c8e8071561cb0f657c3728bf781eb25d2ec6021d Mon Sep 17 00:00:00 2001 From: benthecarman Date: Wed, 24 Feb 2021 00:36:29 -0600 Subject: [PATCH] Define input & output ordering (#136) --- Messaging.md | 6 ++++++ Protocol.md | 36 +++++++++++++++++++++++++++++++++--- Transactions.md | 11 ++++------- 3 files changed, 43 insertions(+), 10 deletions(-) diff --git a/Messaging.md b/Messaging.md index da48f26..e4d0dd5 100644 --- a/Messaging.md +++ b/Messaging.md @@ -264,6 +264,7 @@ This type contains information about a specific input to be used in a funding tr 1. type: 42772 (`funding_input_v0`) 2. data: + * [`u64`:`input_serial_id`] * [`u16`:`prevtx_len`] * [`prevtx_len*byte`:`prevtx`] * [`u32`:`prevtx_vout`] @@ -271,6 +272,9 @@ This type contains information about a specific input to be used in a funding tr * [`u16`:`max_witness_len`] * [`spk`:`redeemscript`] +`input_serial_id` is a randomly chosen number which uniquely identifies this input. +Inputs in the funding transaction will be sorted by `input_serial_id`. + `prevtx_tx` is the serialized transaction whose `prevtx_vout` output is being spent. The transaction is used to validate this spent output's value and to validate that it is a SegWit output. @@ -323,6 +327,8 @@ This type contains signatures of the funding transaction and any necessary infor `witness` is the data for a witness element in a witness stack. An empty `witness_stack` is an error, as every input must be Segwit. Witness elements should *not* include their length as part of the witness data. +Witnesses should be sorted by the `input_serial_id` sent in `funding_input` defining these inputs. + ## Authors Nadav Kohen diff --git a/Protocol.md b/Protocol.md index 749b991..913f497 100644 --- a/Protocol.md +++ b/Protocol.md @@ -70,10 +70,13 @@ the funding transaction and CETs. * [`contract_info`:`contract_info`] * [`point`:`funding_pubkey`] * [`spk`:`payout_spk`] + * [`u64`:`payout_serial_id`] * [`u64`:`total_collateral_satoshis`] * [`u16`:`num_funding_inputs`] * [`num_funding_inputs*funding_input`:`funding_inputs`] * [`spk`:`change_spk`] + * [`u64`:`change_serial_id`] + * [`u64`:`fund_output_serial_id`] * [`u64`:`feerate_per_vb`] * [`u32`:`contract_maturity_bound`] * [`u32`:`contract_timeout`] @@ -98,6 +101,15 @@ the sender and `funding_inputs` contains outputs, outpoints, and expected weight of the sender's funding inputs. `change_spk` specifies the script pubkey that funding change should be sent to. +`payout_serial_id` is a randomly chosen number which uniquely identifies the payout output of the offering party. +Outputs in the contract execution transaction will be sorted by `payout_serial_id`. + +`change_serial_id` is a randomly chosen number which uniquely identifies the change output. +Outputs in the funding transaction will be sorted by `change_serial_id` and `fund_output_serial_id`. + +`fund_output_serial_id` is a randomly chosen number which uniquely identifies the funding output. +Outputs in the funding transaction will be sorted by `change_serial_id` and `fund_output_serial_id`. + `feerate_per_vb` indicates the fee rate in satoshi per virtual byte that both sides will use to compute fees in the funding transaction, as described in the [transaction specification](Transactions.md). @@ -114,6 +126,8 @@ The sending node MUST: - set `total_collateral_satoshis` to a value greater than or equal to 1000. - set `contract_maturity_bound` and `contract_timeout` to either both be UNIX timestamps, or both be block heights as distinguished [here](https://en.bitcoin.it/wiki/NLockTime). - set `contract_maturity_bound` to be less than `contract_timeout`. + - use a unique `input_serial_id` for each input + - set `change_serial_id` and `fund_output_serial_id` to different values The sending node SHOULD: @@ -144,6 +158,8 @@ The receiving node MUST reject the contract if: - it considers `feerate_per_vb` too small for timely processing or unreasonably large. - `funding_pubkey` is not a valid secp256k1 pubkey in compressed format. - `funding_inputs` do not contribute at least `total_collateral_satoshis` plus full [fee payment](Transactions.md#fee-payment). + - Any `input_serial_id` is duplicated + - The `fund_output_serial_id` and `change_serial_id` are not set to different value ### The `accept_dlc` Message @@ -158,9 +174,11 @@ and closing transactions. * [`u64`:`total_collateral_satoshis`] * [`point`:`funding_pubkey`] * [`spk`:`payout_spk`] + * [`u64`:`payout_serial_id`] * [`u16`:`num_funding_inputs`] * [`num_funding_inputs*funding_input`:`funding_inputs`] * [`spk`:`change_spk`] + * [`u64`:`change_serial_id`] * [`cet_adaptor_signatures`:`cet_adaptor_signatures`] * [`signature`:`refund_signature`] * [`negotiation_fields`:`negotiation_fields`] @@ -175,6 +193,10 @@ The sender MUST: - set `cet_adaptor_signatures` to valid adaptor signatures, using its `funding_pubkey` for each CET, as defined in the [transaction specification](Transactions.md#contract-execution-transaction) and using signature public keys computed using the `offer_dlc`'s `contract_info` and `oracle_info` as adaptor points. - include an adaptor signature in `cet_adaptor_signatures` for every event specified in the `offer_dlc`'s `contract_info`. - set `refund_signature` to the valid signature, using its `funding_pubkey` for the refund transaction, as defined in the [transaction specification](Transactions.md#refund-transaction). + - use a unique `input_serial_id` for each input + - use a unique `change_serial_id` + - set `change_serial_id` so that it is not equal to the `fund_output_serial_id` + - use a unique `payout_serial_id` The sender SHOULD: @@ -187,8 +209,16 @@ The receiver: - MAY reject the contract. - if `cet_adaptor_signatures` or `refund_signature` fail validation: - MUST reject the contract. -- if `funding_inputs` do not contribute at least `total_collateral_satoshis` plus [fee payment](Transactions.md#fee-payment) - - MUST reject the contract. + - if `funding_inputs` do not contribute at least `total_collateral_satoshis` plus [fee payment](Transactions.md#fee-payment) + - MUST reject the contract. + - if any `input_serial_id` is duplicated + - MUST reject the contract. + - if any `change_serial_id` is duplicated + - MUST reject the contract. + - if any `change_serial_id` is equal to the `fund_output_serial_id` + - MUST reject the contract. + - if any `payout_serial_id` is duplicated + - MUST reject the contract. Other fields have the same requirements as their counterparts in `offer_dlc`. @@ -235,4 +265,4 @@ Nadav Kohen ![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY")
-This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/). \ No newline at end of file +This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/). diff --git a/Transactions.md b/Transactions.md index 2560f43..f86fdb1 100644 --- a/Transactions.md +++ b/Transactions.md @@ -30,9 +30,8 @@ The funding inputs and change output script public keys are negotiated in the of ## Funding Transaction Input and Output Ordering -The Offerer/Initiator's inputs come first and in the order that they were listed in the Offer message, the Accepter's inputs come after this in the order they are listed in the Accept message. The funding output comes first, followed by the Offerer's change output if applicable, and then the Accepter's change output if applicable. - -Note that this will likely change in the future. +The inputs are sorted by each `funding_input`'s `input_serial_id` in ascending order. +The outputs are sorted in ascending order based on their respective `change_serial_id` or `fund_output_serial_id`. ## Funding Inputs @@ -80,9 +79,7 @@ There will be one CET for every possible outcome, the output values correspond t ## CET Outputs -The Offerer/Initiator's output comes first, the Accepter's output comes second. - -Note that this will likely change in the future. +The outputs are sorted by each user's `payout_serial_id` in ascending order. If either party receives less than the dust limit of `1000 satoshis` for this outcome, then their output is not produced. @@ -321,4 +318,4 @@ Nadav Kohen ![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY")
-This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/). \ No newline at end of file +This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).