-
Notifications
You must be signed in to change notification settings - Fork 15
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
Conversation
There was a problem hiding this 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
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).
We could, I can add that! |
Done in b9b8397 |
We could add a test with 2 consecutive testnet blocks ? |
Done in 7680d1f, looks like this was indeed using the block hash. |
7680d1f
to
3163708
Compare
Rebased to fix trivial conflict ( |
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.
3163708
to
567bb5d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept ACK.
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. |
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.
It was really footgunny to only use a
ByteVector32
here, as users could use aTxHash
when aTxId
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 aTxHash
on the wire, which will greatly simplify our types. For example, we would definesplice_locked
as:And the codec would convert this to a
TxHash
before encoding its bytes, since lightning wire messages always expect aTxHash
. This way we hide that encoding detail in the codecs, and only deal withTxId
s that we get fromTransaction
objects.