[dlc-dev] Contract id breaks on any changes to offer serialization

Thibaut Le Guilly thibaut at cryptogarage.co.jp
Mon Feb 7 03:33:46 CET 2022

Hi Chris,

I've tried to consider other approaches than the random temporary contract
id, but it seems to me that it is the best approach. One thing that I found
appealing was simply having a counter between the parties which they would
increment for each contract, but this leads to quite some issues if one
party gets out of sync or misbehaves so I think the random id is just

One thing to note is that this change will also require a change in the
offer message since we will have to include the temporary contract id
inside it (at the moment we don't since it is computed as a hash of the
offer message). If we agree on this I think it would be good to get the
change to the offer message together with the serialization update in #163.



On Wed, Jan 12, 2022 at 11:53 PM Chris Stewart <chris at suredbits.com> wrote:

> For reference of our implementation specific issue, please see
> https://github.com/bitcoin-s/bitcoin-s/issues/3969
> On Wed, Jan 12, 2022 at 8:51 AM Chris Stewart <chris at suredbits.com> wrote:
>> When implementing 163
>> <https://github.com/discreetlogcontracts/dlcspecs/pull/163> inside of
>> bitcoin-s, i discovered that any existing wallets deployed with previous
>> serialization versions will have their contract ids
>> <https://github.com/discreetlogcontracts/dlcspecs/blob/master/Protocol.md#definition-of-contract_id>
>> broken and require database level migrations if you are persisting contract
>> ids.
>> The offer message
>> <https://github.com/discreetlogcontracts/dlcspecs/blob/master/Protocol.md#the-offer_dlc-message>
>> is what contract ids are derived off of. If any of the nested data
>> structures have serialization changes inside the offer, this will break
>> contract ids. Things included in the offer are contract descriptors,
>> announcements etc. Thus if we make any changes to the binary level
>> serialization of the DLC spec, contract ids will break most likely.
>> It was talked about on our open source developer call last night what we
>> can do to prevent this from happening. When we first wrote the DLC spec we
>> tried to copy as much stuff as we could from Lightning with two hopes
>> 1. Learning from their deployment of Lightning
>> 2. Reducing the amount of bikeshedding
>> The equivalent to `temp_contract_id` in Lightning is the
>> temporary_channel_id
>> <https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#definition-of-channel_id>.
>> It appears that they just pick a random nonce now. Here is the relevant
>> section from BOLT2
>> >Prior to channel establishment, a temporary_channel_id is used, which
>> is a random nonce.
>> >Note that as duplicate temporary_channel_ids may exist from different
>> peers, APIs which reference channels by their channel id before the funding
>> transaction is created are inherently unsafe. The only protocol-provided
>> identifier for a channel before funding_created has been exchanged is the
>> (source_node_id, destination_node_id, temporary_channel_id) tuple. Note
>> that any such APIs which reference channels by their channel id before the
>> funding transaction is confirmed are also not persistent - until you know
>> the script pubkey corresponding to the funding output nothing prevents
>> duplicative channel ids.
>> So it appears that they are just randomly generating a 32 byte nonce. It
>> seems we should just do the same. This means that whenever we introduce a
>> binary level serialization change, we don't have to run database migrations
>> to recalculate all contract ids.
>> It does appear that our `contract_id` calculation will work as that is
>> calculated with
>> funding_txid XOR temp_contract_id
>> which seems to adhere to the wisdom on the Lightning RFC. Once we know
>> the funding_txid we have a way to reasonably guarantee unique entropy that
>> leads to a stable contract id identifier, just as lightning can calculate a
>> stable channel_id when they have the funding tx.
>> This seems like an easy backward compatible deployment as well, as we can
>> just assume all existing `temp_contract_id` were randomly generated (even
>> though in reality they are hash(offer_bytes)).
>> -Chris
> dlc-dev mailing list
> dlc-dev at mailmanlists.org
> https://mailmanlists.org/mailman/listinfo/dlc-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20220207/d61c2389/attachment-0001.htm>

More information about the dlc-dev mailing list