search

hirosystems / stacks.js

JavaScript libraries for identity, auth, storage and transactions on the Stacks blockchain.
https://stacks.js.org
MIT License
944 stars 307 forks source link

Problem with attachment on name-update #1333

Open friedger opened 2 years ago

friedger commented 2 years ago

Description

When I tried to update the zone file of a bns name using connect, the tx was successful, but the attachment didn't make it through to the database of the stacks api node. There was an empty entry in the database when using connect. However, using the rest api directly worked.

Expected behaviour

The tx fails or the attachment is send to a stacks api node

Additional information

Code snippets and more discussions why the error is not in the stacks-blockchain-api: See https://github.com/hirosystems/stacks-blockchain-api/issues/1189

bilalanees98 commented 2 years ago

I have seen this problem taking place on btc.us. There have been cases in which a user has made a name-update call to update their zone file. The zone file was updated but after a few days the zone file became empty. I understand that zone files can only be updated with name-update calls, but this particular user had only one name-update in their transaction history, so there is no question of them making a mistake. This definitely needs to be looked into before this becomes more common. I'll attach the user query here as well for reference, in the hope that its helpful.

Hi there, I was just wondering if anyone can help me understand why the redirect data for my BNS name seems to have vanished? I own udiverse.btc, and I'd set the btc.us URL to redirect to a tweet link (the tweet was to explain that Udi Wertheimer could have the name if he ever wanted it) The redirect was working; visiting udiverse.btc.us would open the tweet just fine - but then it stopped working one day. I've logged in to btc.us, and it seems the redirect info is no longer there. I also listed it on Byzantion for 69,420 stx (as a joke) - but I don't think this is the cause, as the redirect was still working some time after I did this. I'm not concerned about the redirect itself. I'm just curious to know what happened, or if I'm overlooking something. You can see the relevant "name-update" and "list-domain" transactions: https://explorer.stacks.co/address/SP19BP5KSGS0PS6W2NNP9REBNR8DVWJC2B73VNKV3 Any insight would be greatly appreciated. Thank you.

markmhendrickson commented 2 years ago

@kyranjamie @janniks thoughts on whether this is likely a wallet- or stacks.js-borne issue?

kyranjamie commented 2 years ago

No idea, will need to investigate.

fbwoolf commented 1 year ago

@janniks I am not able to pinpoint this as an issue in the wallet, it seems more likely to be an issue in stacks.js?

fbwoolf commented 1 year ago

@markmhx should I move this issue to stacks.js?

markmhendrickson commented 1 year ago

Yep sounds good!

janniks commented 1 year ago

~Looks like an issue in connect + wallet. Is it possible that the attachment was never passed on when using the wallet/connect?~

EDIT: the attachment is also part of the token jwt

fbwoolf commented 1 year ago

Looks like an issue in connect + wallet. Is it possible that the attachment was never passed on when using the wallet/connect?

This is a bit strange bc we have a contract call in our test-app that uses an attachment and it is working for me.

fbwoolf commented 1 year ago

Should this issue be moved to Connect?

janniks commented 1 year ago

Ok, I'll re-check 🤔

pradel commented 1 year ago

Another user affected by this issue https://stacks-node-api.mainnet.stacks.co/v1/names/nickk.btc

janniks commented 1 year ago

Doesn't look like a connect/wallet issue, the attachments make it through...

@rafaelcr could this be on the API/registrar side? Maybe zonefiles come in and are lost / not stored? Is it possible to replay/inspect what made the API show nickk.btc under /names Does that make sense?

rafaelcr commented 1 year ago

This looks like a symptom of this core node issue: https://github.com/stacks-network/stacks-blockchain/issues/3270

TL;DR: Attachments are not currently guaranteed by nodes, causing incorrect responses on names/subdomains if the API does not receive them

pradel commented 1 year ago

@rafaelcr 😢 what would be the best way for a user to unblock this situation?

rafaelcr commented 1 year ago

@pradel there is no workaround at the moment, unfortunately...

The API must receive the attachment through the node RPC messages in order for it to be processed. There is no way to do it manually.

There's also no realistic way for the API to request a missing attachment on-demand because we'd first have to find the node in the Stacks network that actually has the attachment and that is pretty much unfeasible.

pradel commented 1 year ago

Okay, thanks for the answer

janniks commented 1 year ago

Would it make sense to allow pushing a missing attachment? i.e. if a user has the attachment (or access to a node which has it), could then push the attachment to a node that is missing it

This way at the very least users themselves could fix inconsistencies they notice. Just an idea, might not fit into the API architecture

friedger commented 1 year ago

Or something like a crawling service that hops from node to node and finds missing attachments and then delivers as it finds them?

rafaelcr commented 1 year ago

Would it make sense to allow pushing a missing attachment? i.e. if a user has the attachment (or access to a node which has it), could then push the attachment to a node that is missing it

@janniks IIUC this is how the Atlas system works inside the Stacks node, but right now it gives up after a fixed number of tries. Once fixed, this system will retry indefinitely until it makes sure attachments are propagated.