PreviousTxID as byte? about go-bt HOT 3 CLOSED

The main reason we chose to use string instead of bytes was so that we abstract away the reversing of the endianness. We previously had it as ba 32-byte slice but it was annoying with extra boilerplate code so we just swapped it out for string to make things easier. Thanks for raising this actually, you made me realise that we're not handling the error returned in some cases. I will add the PreviousTxIDBytes element to sort that out now. We were considering making all struct elements private and making getters and setters for everything to avoid all this - maybe someday we'll do something like that in v2 or something...

from go-bt.

Hey @caevv, just out of curiosity, what would you need that for?

from go-bt.

I'm storing the tx id as a key on a key/value storage, and as the DB will be huge, by storing the key as bytes, instead of a string, it's saving half of the space.

Now I'm doing this:

key, _ := hex.DecodeString(input.PreviousTxID)

But the implementation on the library seems like it's doing the opposite, so just thought it would save a bit of work.

It's not a blocker for me, just a suggestion.

Thanks.

from go-bt.