Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce TxId and TxHash types #90

Merged
merged 3 commits into from
Sep 13, 2023
Merged

Introduce TxId and TxHash types #90

merged 3 commits into from
Sep 13, 2023

Conversation

t-bast
Copy link
Member

@t-bast t-bast commented Apr 4, 2023

It was really footgunny to only use a ByteVector32 here, as users could use a TxHash when a TxId was expected. Introducing explicit types ensures that functions can clearly specify which one they expect.

Codecs can then decide how to encode that on the wire: this will let us exclusively use TxId in lightning, and encode/decode it as a TxHash on the wire, which will greatly simplify our types. For example, we would define splice_locked as:

data class SpliceLocked(val channelId: ByteVector32, val fundingTxId: TxId)

And the codec would convert this to a TxHash before encoding its bytes, since lightning wire messages always expect a TxHash. This way we hide that encoding detail in the codecs, and only deal with TxIds that we get from Transaction objects.

@t-bast t-bast requested review from sstone and pm47 April 4, 2023 16:23
build.gradle.kts Outdated Show resolved Hide resolved
Copy link
Member

@sstone sstone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can help, though I think that the biggest issue is not the lack of specific types but improper use of tx hash/tx id in many technical docs and specs (not ours :)). For consistency's sake we should also add new block hash/block id types

build.gradle.kts Outdated Show resolved Hide resolved
@t-bast
Copy link
Member Author

t-bast commented Apr 11, 2023

I think that the biggest issue is not the lack of specific types but improper use of tx hash/tx id in many technical docs

That is also an issue, but honestly the lack of type is the biggest issue we've regularly ran into when implementing dual funding / splicing, because we always forget that lightning messages always use the tx hash (whereas using a specific type would force us to think about which one we should use).

For consistency's sake we should also add new block hash/block id types

We could, I can add that!

@t-bast
Copy link
Member Author

t-bast commented Apr 11, 2023

For consistency's sake we should also add new block hash/block id types

Done in b9b8397
I'm not completely sure what to use for hashPreviousBlock, there is no unit test to help me figure it out.
I guess it should use BlockHash, but how can I verify that?

@sstone
Copy link
Member

sstone commented Apr 11, 2023

For consistency's sake we should also add new block hash/block id types

Done in b9b8397 I'm not completely sure what to use for hashPreviousBlock, there is no unit test to help me figure it out. I guess it should use BlockHash, but how can I verify that?

We could add a test with 2 consecutive testnet blocks ?

@t-bast
Copy link
Member Author

t-bast commented Apr 11, 2023

We could add a test with 2 consecutive testnet blocks ?

Done in 7680d1f, looks like this was indeed using the block hash.

@t-bast t-bast force-pushed the clarify-txid-hash branch from 7680d1f to 3163708 Compare April 13, 2023 12:36
@t-bast
Copy link
Member Author

t-bast commented Apr 13, 2023

Rebased to fix trivial conflict (build.gradle.kts).

t-bast added 3 commits August 30, 2023 17:20
It was really footgunny to only use a `ByteVector32` here, as users could
use a `TxHash` when a `TxId` was expected. Introducing explicit types
ensures that functions can clearly specify which one they expect.
It was footgunny to use a `ByteVector32` here as well, as we can easily
mistake one for the other.
@t-bast t-bast force-pushed the clarify-txid-hash branch from 3163708 to 567bb5d Compare August 30, 2023 15:27
Copy link
Member

@pm47 pm47 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK.

@t-bast
Copy link
Member Author

t-bast commented Sep 13, 2023

Added to eclair in ACINQ/eclair#2742 and lightning-kmp in ACINQ/lightning-kmp#524 without any issue, it should be safe to move forward.

@t-bast t-bast merged commit 42039aa into master Sep 13, 2023
@t-bast t-bast deleted the clarify-txid-hash branch September 13, 2023 09:38
dpad85 added a commit to ACINQ/phoenix that referenced this pull request Nov 30, 2023
See for details:
- ACINQ/bitcoin-kmp#90
- ACINQ/lightning-kmp#524

Transaction ids are still stored as byte arrays in the
database (use txId.value to get the raw data), but we
should use the correct types whenever possible.

Use toString() to get the txid as an hexa string.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants