search

ordinals / ord

👁‍🗨 Rare and exotic sats
https://ordinals.com
Creative Commons Zero v1.0 Universal
3.85k stars 1.38k forks source link

Node TOO large - The Largest node in the world #4076

Open btcmachineordinals opened 1 week ago

btcmachineordinals commented 1 week ago

Hello!

We have a massive issue with all versions of ord for our node.

We basically have hundreds of thousands of ordinals that we have accumulated since the inception of Ordinals while creating our ecosystem.

These ordinals keep getting airdrops.

We currently have over .4 BTC only in SATS padding these ordinals.

ORD BREAKS completely when trying to run anything.

We are not able to use any inscribe or send functions anymore, it times out.

And running commands like wallet balance or wallet receive will take about 30 minutes.

Many OG devs have looked into this and came to the conclusion that you guys would need to push a custom update to handle extremely large ord nodes.

What should we do? We are currently using custom bitcoin-cli functions to build commands to send ordinals but its getting weird when trying to send runes out of the node

HELP!

so7ow commented 1 week ago

Scammer @cryptoni9n

cryptoni9n commented 1 week ago

3142 was merged earlier this year to deal with this type of an issue. @btcmachineordinals what version of ord are you currently experiencing this issue with? Can you paste the timeout message here so we can get more insight to the problem?

btcmachineordinals commented 1 week ago

All Outputs are above dust limit note: run with "RUST_BACKTRACE=1" environment variable to display a backtrace

this is the error

raphjaph commented 1 week ago

Scammer @cryptoni9n

just banned Elsonbastey from the org

raphjaph commented 1 week ago

3142 was merged earlier this year to deal with this type of an issue. @btcmachineordinals what version of ord are you currently experiencing this issue with? Can you paste the timeout message here so we can get more insight to the problem?

Yes, version would be great to know.

The problem still is that we build the whole wallet state with each wallet subcommand. A quick fix would be to increase the timeout limit and retry in the background. A proper solution would be to put the wallet state into the wallet.redb database and then only update values that have changed. This is what Sparrow and Bitcoin Core do with their respective wallet databases.

btcmachineordinals commented 1 week ago

I am currently on 0.21.1, ill update let me check

raphjaph commented 1 week ago

Could you also provide a bit more information on the size of the wallet, specifically how many outputs?

btcmachineordinals commented 6 days ago

Could you also provide a bit more information on the size of the wallet, specifically how many outputs?

About 96 446

1stBitcoinSent commented 3 days ago

limiting outputs (<1000) per wallet helps

btcmachineordinals commented 1 day ago

Is this something I should be editing on my side? I am truly a newbie here

raphjaph commented 1 day ago

About 96 446

That is a lot of outputs.

This would probably require us to move forward with #3991. ord wallet would then work similar to Sparrow in that it manages a database that loads output information once and then either adds or invalidates outputs when new transactions come in. Tbh, this is not high priority for us at the moment. I can look into it tomorrow and see how much work it would be. If you find someone willing to take the lead on this I'd be happy to help and review PRs though!