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

[DISCUSSION] Running Teranode UTXO Lookup for ARC API #770

Open
sirdeggen opened this issue Feb 9, 2025 · 0 comments
Open

[DISCUSSION] Running Teranode UTXO Lookup for ARC API #770

sirdeggen opened this issue Feb 9, 2025 · 0 comments

Comments

@sirdeggen
Copy link
Collaborator

Summary

ARC runs a bunch of microservices, one of them could be the UTXO lookup from Teranode, and perhaps this would need to be configured so that it maintains a history of spendTxids for a long period of time (24 hours or so).

Motivation

We've has issues with people sending transactions which attempt to spend txos which are already spent in mined transactions. Since the tx isn't in the mempool anymore this doesn't raise a mempool conflict and so SV node treats it as an orphan for a little while and eventually ignores it. This is a problem for ARC users who now have a false positive that their tx hasn't been rejected when it should have been.

Description

The idea here is that maintaining a full UTXO lookup was part of the acknowledged long term plan of ARC - partly because EF verification is a LARP if the extended data isn't verified to be accurate. Now that BEEF is a possible format for ARC api to validate it's not as big a deal but that leaves the "already spent" txo problem described above.

Additional References

I'm not sure if this is still how Teranode UTXO lookup works but the idea back in the early days of ARC was to use a hash of the extended data: txid, vout, satoshis, script to check if the utxo still existed in the set. The idea being that if the data was fake then the lookup would be on a key which didn't exist. Then you'd know it was fake data. If it returned something you'd be able to return spendTxid which would allow idempotency, and if it returned the wrong spendTxid you had confirmed a double spend attempt and could reject.

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

1 participant