-
Notifications
You must be signed in to change notification settings - Fork 118
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
[Rosetta][Data-API] transaction with stx_unlock op has conflicting transaction hash #760
Comments
This would require changes to the core node which wouldn't happen anytime soon.
Seems like these forged @asimm241 is this something you can take on? |
@zone117x sure. |
# [0.67.0](v0.66.1...v0.67.0) (2021-09-16) ### Bug Fixes * **rosetta:** use coinbase txs hash instead of stx_lock for forged unlock_transaction [#760](#760) ([37adcc7](37adcc7)) * disable http keep-alive for stacks-node /v2 proxied endpoints ([cebeda0](cebeda0)) * increase the 10 second cap on prometheus http metric reporting ([735874e](735874e)) * replicate query optimizations to other asset txs queries ([05c9931](05c9931)) ### Features * automatically generate postman collection from the openapi spec ([5f07d74](5f07d74)) * **rosetta:** support memos in stx token transfer operations [#752](#752) ([6f4f3e2](6f4f3e2))
🎉 This issue has been resolved in version 0.67.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
* develop: (40 commits) feat: added execution cost to block response #735 feat: ability to configure multiple tx broadcast endpoints #765 fix: return the latest name by address #714 fix(rosetta): use coinbase txs hash instead of stx_lock for forged unlock_transaction #760 feat: automatically generate postman collection from the openapi spec fix: disable http keep-alive for stacks-node /v2 proxied endpoints fix: increase the 10 second cap on prometheus http metric reporting chore: update typescript to 4.4.2 feat(rosetta): support memos in stx token transfer operations #752 fix: replicate query optimizations to other asset txs queries fix: optimize query that retrieves txs with asset transfers fix(rosetta): do not assume encoding of delegate-stx `pox_addr` data #732 feat: added a new endpoint fee_rate #729 chore(release): 0.65.0 [skip ci] fix: sql optimizations to speed up various tx queries feat: add execution cost data to transactions feat: token metadata fix: short summaries for BNS endpoints feat: emit prometheus metrics for socket.io fix: added types for search endpoint #645 ...
Context
When Zondax initially added support in Rosetta API for stacking: #613 , "forged" transactions were created with
stx_unlock
operations because there are no actual on-chain transactions to show that accounts' tokens unlocked. This is due CB requiring balance changing events to be on-chain events otherwise addresses will be quarantined.So the solution was to create a transaction to show these operations happened that only shows up in the Rosetta implementation and doesn't actually exist on-chain.
However, the implementation appears to use the transaction hash of the previous
stack_stx
operation for the account that shows up in the firststx_unlock
operation's. This results in a transaction hash being used in two different blocks and causes issues because we can never actually return the "forged" transaction from/block/transaction
.Simple Example
Account
ABC
stacked tokens (stack_stx op
andstx_lock
) inblock 5
. The transaction hash is0x01
Then, Account
ABC
unlocks tokens (stx_unlock
) inblock 10
. The transaction hash for this "forged" transaction shows up also as0x01
. When querying this transaction on/block/transaction
, it shows the transaction that includes thestack_stx
andstx_lock
operations while the "forged" transaction is unable to be queried.Actual Example for Block 6926 in Testnet
Note how
transaction_identifier.hash
matches the first operation'smetadata.tx_id
:But when you try to look up transaction hash
0x7cfac55147759a14d163bd96b89138df090dd730df5fa5c34a086011b5e9621e
onblock/transaction
, the transaction returned is the transaction for the stacking (that happened in block 5757).Request
Could the protocol be able to incorporate an actual on-chain event for the token unlock?
Or if not, could the "forged" transaction use a brand new transaction hash (that only Rosetta would use). The caveat to that would be there still could be a conflict if a future block mined by chance uses that transaction hash in one of the transactions.
The text was updated successfully, but these errors were encountered: