Skip to content

Contract and Balance Discrepancies in Block #32861 #818

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

Closed
Jamil opened this issue Oct 22, 2021 · 2 comments · Fixed by #817
Closed

Contract and Balance Discrepancies in Block #32861 #818

Jamil opened this issue Oct 22, 2021 · 2 comments · Fixed by #817

Comments

@Jamil
Copy link

Jamil commented Oct 22, 2021

I noticed two issues on https://stxnft.com (using the Stacks API) which I think can both be traced back to transactions in the same block.

The symptoms are:

  1. Discrepancies in NFT balances between the Stacks and PlanBetter explorers
  2. Discrepancies between the result of contract calls and balances according to the Stacks API

I'll go over the cases here:

Case 1

I noticed that on our marketplace balance, I can see ThisIsNumberOne 129 as belonging to the marketplace, but with no corresponding listing in the contract map. This is (to my knowledge) not possible with the contract is coded. I suspected a bug in the contract, but we can take a look at the transactions a bit further.

Listing transaction, block #32719: https://explorer.stacks.co/txid/0xb5c7d7b01c55e917cc4a583b899553da475936a4ab398712a3bc18a23e880885?chain=mainnet

You can see my-nft::129 was transferred from the owner to the marketplace contract. Everything is fine there.

Purchase transaction, block #32859 according to Stacks Explorer and block #32861 according to PlanBetter (!), https://explorer.stacks.co/txid/0xf04705c8695afc39775a17823dd8491ab9f25544fe037d844be95ae20a9e461a?chain=mainnet
https://explorer.planbetter.org/txid/0xf04705c8695afc39775a17823dd8491ab9f25544fe037d844be95ae20a9e461a?chain=mainnet

Even though this says it is a non-canonical fork, the contract seems to be updated as if the transaction went through successfully. The balances, however, do not reflect the state of the world as if the transaction went through successfully

On PlanBetter you can see that the purchaser does own the NFT they purchased (my-nft) (https://explorer.planbetter.org/address/SP2K3MDQE5YB2PK3BAVJ7C3YM2M48ZFG604EJ57ND) but on Stacks Explorer they don't (https://explorer.stacks.co/address/SP2K3MDQE5YB2PK3BAVJ7C3YM2M48ZFG604EJ57ND).

Either way is fine — whether the transaction went through or not is ok with me, but the weird thing is that the contract acts as if the transaction went through (deleting the entry in the map) while the balances do not (the marketplace still owns the NFT while the contract treats it as sold)

Case 2

I received a message from the owner of FreePunk 9314 saying they tried to list the NFT on our marketplace but couldn't find the asset.

Looking at the account from which the FreePunk supposedly came from, I couldn't find a transaction listing that specific FreePunk on the marketplace: https://explorer.stacks.co/address/SP3RMX8BVN638M2T3E2QNAWXAJ2J19TSG5Q7P5ECW?chain=mainnet

However, again, this is where it gets weird. The contract shows that the FreePunk has been listed on the marketplace, though the marketplace balance doesn't reflect that!

Also, get-owner on the FreePunk returns the marketplace address, whereas the Stacks Explorer shows it as still belonging to the original owner: https://freestxpunks.surge.sh/details/9314

Again, the transaction shows up in the PlanBetter website but not the Stacks Explorer, in block #32861 (the same problematic block as the previous purchase transaction):
https://explorer.planbetter.org/txid/0x139264ec7b6e12fed3349aec88d0cf141428c4edcb4b76ce4bfa0b3f4966dde3?chain=mainnet

Again, the weird thing here is that the contract call acts as if the transaction went through successfully, but the balance does not!

Notes

Here's a link to the offending block on the Stacks explorer. You can see some of the transactions show up as "not found" or show as belonging to an orphaned chain: https://explorer.stacks.co/block/0x2f07bddfb857c4378dd39bf0c11c408c8af41d9e7b6f27f322a0171e8e8cb39e?chain=mainnet

@zone117x
Copy link
Member

Thank you for the detailed report @Jamil. This appears to be the bug fixed in PR #817 -- both txs you mentioned are fixed in my local setup, hopefully we'll have the PR merged and deployed soon.

@zone117x zone117x mentioned this issue Oct 22, 2021
@zone117x zone117x linked a pull request Oct 22, 2021 that will close this issue
blockstack-devops pushed a commit that referenced this issue Oct 22, 2021
## [0.70.1](v0.70.0...v0.70.1) (2021-10-22)

### Bug Fixes

* api versioning ([4ade5ee](4ade5ee))
* microblock related re-org bug causing txs to be incorrectly orphaned [#804](#804) [#818](#818) ([bae619d](bae619d))
@zone117x
Copy link
Member

zone117x commented Nov 2, 2021

Closed by #804

@zone117x zone117x closed this as completed Nov 2, 2021
wileyj added a commit that referenced this issue Nov 16, 2021
* develop: (42 commits)
  feat: rosetta data api and construction validation with rosetta-cli
  feat: stx addr encoding LRU cache
  feat: add nft_custody pg materialized view to speed up nft event lookup
  fix: build/publish Dockerfile python installation issues
  Add utils module with script to display top address balances
  chore: standardize updates between websockets and socket.io
  fix: transaction broadcast log
  chore: change @kyranjamie to @rafaelcr on pr template
  chore: rename github references from blockstack/ to hirosystems/
  chore: fix flaky BNS tests #723
  feat: endpoint for list of transactions #647
  chore: update c32check and cross-sha256 (including transitive) dependencies
  feat: production-capable CPU profiling #641
  chore: add read-only to readme
  fix: export api version variable for resolution
  fix: microblock related re-org bug causing txs to be incorrectly orphaned #804 #818
  fix: api versioning
  fix(docs): ensure naming convention is followed
  fix: rosetta account/balance speed
  feat: add broadcast/confirmed tx logs
  ...
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

Successfully merging a pull request may close this issue.

2 participants