You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: