[feat] Implement `txid` function

[TAdev0]

• [x] issue #13
• [x] follows contribution guide
• [x] code change includes tests

Here is a first draft for the implementation of TxId function.

@maciejka i'm not sure the TxId we obtain with this function would be the same as references client implementation, because content of Inputs and Outputs doesn't seem to be the same.

Tbh i'm not entirely clear about how Inputs work.

When looking at this : https://learnmeabitcoin.com/technical/transaction/input/

we can see that all inputs of a transaction include the TxID , but the TxID itselfs is calculated using (among other elements) the inputs data. Its a bit confusing

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
raito	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 16, 2024 3:15pm

[TAdev0]

More context:

here is the Input section of raw transactions:

this Input structure is "repeated for every input being included in the transaction."

but at the same time, txId is defined as

It seems like a circular issue, where each input includes txId but txId computation requires to pass inputs as argument to sha256

Also, should i include VOUT field in the input , although its not in our TxIn struct? I suppose yes. But this means we actually use as Inputs the whole Inputs struct, removing the first field (TxId) because this is what we are calculating...

[TAdev0]

@maciejka just understood that txid in each input it the txid of the tx that generated this input... my bad

[maciejka]

More context:

here is the Input section of raw transactions:

this Input structure is "repeated for every input being included in the transaction."

but at the same time, txId is defined as

It seems like a circular issue, where each input includes txId but txId computation requires to pass inputs as argument to sha256

Also, should i include VOUT field in the input , although its not in our TxIn struct? I suppose yes. But this means we actually use as Inputs the whole Inputs struct, removing the first field (TxId) because this is what we are calculating...

These are not the same TxIds. TxInput contains TxId of a transaction it wants to spend.

[TAdev0]

@maciejka @m-kus ok so i udpated the PR without using double_sha256 given its inputs will change with #50 and i'm not sure using Array is ideal here. (and there is not reason to split in 2 inputs the whole bunch of data to hash)

will work on tests now. I'm not serializing everything to an array of u32 because it doesnt seem to be the best option here. I dont know actually. Using ByteArray is nice given that we have elements with various size (input_count / output_count only 1 byte, locktime 4 bytes, scripPubKey which is of various size (43 bytes in the example on learnmeabitcoin..) Using ByteArray seems easier... waiting for your feedback.

[maciejka]

@maciejka @m-kus ok so i udpated the PR without using double_sha256 given its inputs will change with #50 and i'm not sure using Array is ideal here. (and there is not reason to split in 2 inputs the whole bunch of data to hash)

will work on tests now. I'm not serializing everything to an array of u32 because it doesnt seem to be the best option here. I dont know actually. Using ByteArray is nice given that we have elements with various size (input_count / output_count only 1 byte, locktime 4 bytes, scripPubKey which is of various size (43 bytes in the example on learnmeabitcoin..) Using ByteArray seems easier... waiting for your feedback.

Let's keep ByteArray, we will optimize later if necessary.