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

electrum: blockchain.transaction.get verbose transaction is not supported #423

Open
tiero opened this issue Dec 1, 2022 · 4 comments
Open

Comments

@tiero
Copy link

tiero commented Dec 1, 2022

Any reason why the verbose param is not supported? any plan to add it anytime soon? @philippem @shesek

I am getting verbose transactions are currently unsupported

@shesek
Copy link
Collaborator

shesek commented Dec 4, 2022

See Blockstream/electrs#36 (and in particular Blockstream/electrs#36 (comment)).

Can you tell me more about your use case?

@tiero
Copy link
Author

tiero commented Dec 4, 2022

It was to avoid fetching the whole raw block and parsing it on the client side to only get the unix timestamp of a specific tx.

I see your answer and we are ok-ish with this approach, we maybe try to lazy load timestamps in client-side apps, they are not that crucial after all.

@shesek
Copy link
Collaborator

shesek commented Dec 13, 2022

If that helps, you can get the block height (but not block timestamp) via blockchain.transaction.get_merkle.

I could be okay with supporting a minimal version of blockchain.transaction.get with verbose=true that does not attempt to be compatible, where it only returns the fields that cannot be extracted from the raw transaction alone (these related to block inclusion - blockhash, blocktime and confirmations).

However, returning a different json format under the same method name might be confusing for developers, and it may lead to weird behaviors for clients that expects the full json format (they should fail early and relatively cleanly if verbose=true returns an error, while returning a partial json could result in weirder more unexpected behaviors/bugs).

Open to hearing more thoughts on this :)

/cc @greenaddress

@tiero
Copy link
Author

tiero commented Dec 14, 2022

Yes a lot of clients already check for that specific error message. I think it's totally fine to not have it so we do not need to diverge from other ElectrumX servers, we can figure out other ways tho.

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

No branches or pull requests

3 participants
@shesek @tiero and others