Proposed v0 DLC TLV messages and Deterministic Fee Computation

[nkohen]

Begins work on implementing #47, #61, #62, #72, #76

Implements #12

EDIT: Used to implement static test vectors but these have been moved to another PR

[nkohen]

I should note that the type numbers were picked randomly and are likely subject to change

[benthecarman]

I should note that the type numbers were picked randomly and are likely subject to change

Maybe should put that in the doc

[Tibo-lg]

Looks good! I put some comments about things that could likely be optimized, but we can iterate over this in the future.

[nkohen]

The test vector does not pass the spec.
The spec says:

[oracle_info:oracle_info]
[point:funding_pubkey]

But the test vector seems to have the payout scriptPubKey instead after oracle_info.

I don't really know what you're referring to? That spec is for the dlc_offer message and I think you might be talking about the testInputs field which is very much not specified because it is only a test vector thing (where we have priv keys instead)?

[NicolasDorier]

@nkohen I am talking in the TLV offer message of the test vector.

The [ { .offer } ] which is specified in dlc_offer. The byte array I am parsing does not seem to use the same order of field than what is specified here.

[nkohen]

@NicolasDorier Here is my parsing of the first offer in the file:

ByteVector(2 bytes, 0xa71a)
ByteVector(1 bytes, 0x00)
ByteVector(32 bytes, 0x0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206)
ByteVector(84 bytes, 0xfda7105064058b3477561188b9c89a0dbb8a843b797c4f4beb2a21dae4d3a1b54023b89e00000000000000004129cf1ed8463c29956c5edfe9e44de9f8da771f9f9b76f91897791a88bb2826000000000bebc200)
ByteVector(68 bytes, 0xfda71240ce266a66009b7e7b9f39c90ec77b6cc0cd7f58e087ed55c0b019545c44d38e2162fd055478041c159eb0b3b5ce3b9fbe28470522c6ac446873ed27f1c8dcf745)
ByteVector(33 bytes, 0x03efd58eb7b7c79fef1ff1edde8fb0b49c2358020097c016e05c17a129af01940f)
ByteVector(23 bytes, 0x160014c0bb4e0bfb0773843a7b4ff18a4a24e2312c3986)
ByteVector(8 bytes, 0x0000000005f5e100)
ByteVector(2 bytes, 0x0001)
ByteVector(100 bytes, 0xfda7146000520200000001b34e4345b6a07226f1aa91f2515096574fd6099eef1cd9885c8d069e5198cf760000000000000000000100c2eb0b000000001600146dd8f08240e4a3e25bfd3ebe43ae661b9cb3c02e0000000000000000ffffffff006c0000)
ByteVector(23 bytes, 0x160014b94dd1803e840d04b8f52332cff89ac6c42c4364)
ByteVector(8 bytes, 0x0000000000000005)
ByteVector(4 bytes, 0x00000064)
ByteVector(4 bytes, 0x000000c8)

You'll notice the 6th element is a pubkey as expected:

ByteVector(33 bytes, 0x03efd58eb7b7c79fef1ff1edde8fb0b49c2358020097c016e05c17a129af01940f)

[NicolasDorier]

WTF so sorry @nkohen that was actually my implementation that mixed things up... I inverted in my test assertion actual and expected, so I got confused. Sorry for wasting your time :(

[NicolasDorier]

however, @nkohen the parsed version above might be useful to include in the BIP.

[NicolasDorier]

This is quite confusing, in contract_info_v0 we have a single TLV record for many outcomes. Here we have one TLV record for each input.

[nkohen]

This is because contract information follows a uniform type (all outcomes fall under the same version, and if they don't a future version will have separate TLV records) whereas different inputs are independent (e.g. taproot input could be funding_input_v1 and not have prev_tx at the same time as another input is v0)

[NicolasDorier]

in theory not needed, as a parser knows how big is a transaction.

[nkohen]

I assume this is to allow clients which don't have transaction parser to make external calls to one after having parsed the transaction. Regardless of why I have made this record as close to this as possible: https://github.com/niftynei/lightning-rfc/pull/1/files#diff-3369c5aa1774fef2ff1e246979f223eaR169

[NicolasDorier]

Something wrong with vectors, I can't calculate the same temporary_contract_id as the Accept messages. I have the same byte array, tried all endianess possibilities.

The hash of the expected contract offer is different.

[NicolasDorier]

If you don't have anymore that's OK, but it would be useful to get the oracle private key.

[NicolasDorier]

Can you also provide the pre-images of the outcomes?

[nkohen]

Going to merge spec changes only (test vectors now in #100) as these seem to be acked by basically everyone (and of course, we will iterate on the spec in future PRs)