Regtest wallet will brick after 1000 inscriptions

[elocremarc]

I have been running into an unusable regtest after a few batch inscriptions totaling in thousands of inscriptions. This might be related to 3130

Running on V 0.16 after 1000 inscriptions on the default ord wallet
ord -r wallet --server-url http://localhost:8080 outputs

error: error sending request for url (http://localhost:8080/output/e606c6518bdcfafbb3da7577ea3d20aaf76352a71945d15c3131984cae62f382:226): connection error: Connection reset by peer (os error 54)
because: connection error: Connection reset by peer (os error 54)
because: Connection reset by peer (os error 54)

I can see the output url on the regtest server. Each time I run the command its a new output its erroring on.

I get 1672outputs on the ord wallet using:
bitcoin-cli -regtest -rpcwallet=ord listunspent | jq length

[casey]

This is probably because the wallet makes a request to the server for each output in the wallet, to see which inscriptions it contains. We can make these a single request, which should make it much faster.

[dozer-eth]

I'm hitting this error too on mainnet 0.17.1. Wallet has 1775 inscriptions and I get the connection reset error when doing any wallet command.

Also on 0.16.0 and later, the error originally manifested as "too many open files":

error: error sending request for url (http://127.0.0.1/output/<redacted>): error trying to connect: tcp open error: Too many open files (os error 24)
because: error trying to connect: tcp open error: Too many open files (os error 24)
because: tcp open error: Too many open files (os error 24)
because: Too many open files (os error 24)

I'm on a mac (monterey). A stackoverflow post suggested increasing the open file limit with ulimit -n 10240. That seemed to fix the "too many open files" error, but then I started getting the "connection reset" error.

For now I'm creating a new wallet to do new stuff, and to access my 1775 inscriptions it seems like downgrading to 0.15.0 is the only thing that works (annoying bc there are no runes in <0.17.0!)

[raphjaph]

Yeah, it's definitely the wallet. We'll have to add an RPC endpoint that takes a list of utxos and return information about them in one request. Instead of doing a request for every UTXO.

[dozer-eth]

That makes sense, thanks for the reply. Obviously this is really bad for power ord client users (on macs?), as their wallets are basically bricked in 0.16.0+ :( :( :(

As a temporary workaround I created a new wallet for new things, but would be great to be able to manage my existing assets from 0.16.0+

[bg-bm]

Agree this should be high priority as you cannot run any wallet commands. I cannot transfer my inscribed collection after going over ~200 inscriptions on mainnet. Even ord wallet balance breaks

wonder if executing ulimit -n 1024 will work as a temporary workaround
#3421

default max number of open files for me was:

$ ulimit -a |grep "open files"
open files                      (-n) 256

[bg-bm]

ok this worked for me

Before starting the ord server and before running the ord wallet commands, I ran:

ulimit -Sn 512

recommend including the S in the switch so it only sets the soft limit - allows you to increase it later

[freaktree]

I am getting this same error trying to inscribe on mainnet.

It started after i did a batch inscribe of 1000... Which worked. Now I am unable to inscribe or do anything with that wallet.

ulimit -Sn doesnt fix it.

[10xdegen]

any update on this...? workaround?

[freaktree]

I have found that doing ulimit -n 4096 before running ord server + before running ord commands does help. Any higher doesn't seem to make a difference.. Also make sure u type it in every terminal window before running ord.

But this only works up to a certain amount - seems to be when ord hits around 500+ Disk Threads in Activity Monitor.

Only seems to effect apple silicon devices..

[raphjaph]

0.18.3 brings some improvements to this. Also this pending PR #3655

[cryptoni9n]

As Raph mentioned on twitter, PR #3621 should have also helped to alleviate these issues. @elocremarc @dozer-eth @bg-bm @10xdegen @freaktree - could you please test with 0.18.5 and see if this issue still exists? and if so, is it less severe?

[dozer-eth]

Hm now I'm getting these errors:

error: JSON-RPC error: transport error: Couldn't connect to host: Resource temporarily unavailable (os error 35)

when running ord wallet balance and ord wallet inscriptions (i have ord server running in a separate tab). I am using a plan bitcoin.conf file with no customizations (except txindex=1 and a custom data-dir).

This is concerning bc my previous workaround of downgrading to 0.15.0 will no longer work as I've been airdropped runes on that wallet, so risk accidentally spending those runes if using a runes-unaware version of ord.

Is anyone else also getting the error above with 0.18.5 or just me? @elocremarc @bg-bm @10xdegen @freaktree

[dozer-eth]

I added export RUST_LOG=DEBUG before running ord server and ord wallet balance. At the time I ran this
843196 was the latest confirmed block height. This is what I see:

-> ord server
[2024-05-12T21:22:52Z DEBUG hyper::proto::h1::io] parsed 2 headers
[2024-05-12T21:22:52Z DEBUG hyper::proto::h1::conn] incoming body is empty
[2024-05-12T21:22:52Z DEBUG hyper::proto::h1::io] flushed 361 bytes
[2024-05-12T21:22:53Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockcount []
[2024-05-12T21:22:53Z INFO  ord::settings] Connecting to Bitcoin Core at 127.0.0.1:8332/
[2024-05-12T21:22:53Z INFO  ord::settings] Using credentials from cookie file at `<redacted>`
[2024-05-12T21:22:53Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockchaininfo []
[2024-05-12T21:22:53Z DEBUG bitcoincore_rpc] JSON-RPC request: getnetworkinfo []
[2024-05-12T21:22:53Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockhash [843197]
[2024-05-12T21:22:53Z DEBUG bitcoincore_rpc] JSON-RPC error for getblockhash: RpcError { code: -8, message: "Block height out of range", data: None }
[2024-05-12T21:22:53Z DEBUG ord::index::updater] Outpoint channel closed
[2024-05-12T21:22:58Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockcount []
[2024-05-12T21:22:58Z INFO  ord::settings] Connecting to Bitcoin Core at 127.0.0.1:8332/
[2024-05-12T21:22:58Z INFO  ord::settings] Using credentials from cookie file at `<redacted>`
[2024-05-12T21:22:58Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockchaininfo []
[2024-05-12T21:22:58Z DEBUG bitcoincore_rpc] JSON-RPC request: getnetworkinfo []
[2024-05-12T21:22:58Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockhash [843197]
[2024-05-12T21:22:58Z DEBUG bitcoincore_rpc] JSON-RPC error for getblockhash: RpcError { code: -8, message: "Block height out of range", data: None }
[2024-05-12T21:22:58Z DEBUG ord::index::updater] Outpoint channel closed
[2024-05-12T21:23:03Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockcount []
[2024-05-12T21:23:03Z INFO  ord::settings] Connecting to Bitcoin Core at 127.0.0.1:8332/
[2024-05-12T21:23:03Z INFO  ord::settings] Using credentials from cookie file at `<redacted>`
[2024-05-12T21:23:03Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockchaininfo []
[2024-05-12T21:23:03Z DEBUG bitcoincore_rpc] JSON-RPC request: getnetworkinfo []
[2024-05-12T21:23:03Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockhash [843197]
[2024-05-12T21:23:03Z DEBUG bitcoincore_rpc] JSON-RPC error for getblockhash: RpcError { code: -8, message: "Block height out of range", data: None }
[2024-05-12T21:23:03Z DEBUG ord::index::updater] Outpoint channel closed
[2024-05-12T21:23:07Z DEBUG hyper::proto::h1::conn] read eof

-> ord wallet balance
[2024-05-12T21:22:52Z INFO  ord::settings] Connecting to Bitcoin Core at 127.0.0.1:8332/
[2024-05-12T21:22:52Z INFO  ord::settings] Using credentials from cookie file at `<redacted>`
[2024-05-12T21:22:52Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockchaininfo []
[2024-05-12T21:22:52Z DEBUG bitcoincore_rpc] JSON-RPC request: getnetworkinfo []
[2024-05-12T21:22:52Z DEBUG bitcoincore_rpc] JSON-RPC request: getnetworkinfo []
[2024-05-12T21:22:52Z DEBUG bitcoincore_rpc] JSON-RPC request: listwallets []
[2024-05-12T21:22:52Z DEBUG bitcoincore_rpc] JSON-RPC request: getwalletinfo []
[2024-05-12T21:22:52Z DEBUG bitcoincore_rpc] JSON-RPC request: listdescriptors []
[2024-05-12T21:22:52Z DEBUG bitcoincore_rpc] JSON-RPC request: getblockcount []
[2024-05-12T21:22:52Z DEBUG reqwest::connect] starting new connection: http://127.0.0.1/
[2024-05-12T21:22:52Z DEBUG hyper::client::connect::http] connecting to 127.0.0.1:80
[2024-05-12T21:22:52Z DEBUG hyper::client::connect::http] connected to 127.0.0.1:80
[2024-05-12T21:22:52Z DEBUG hyper::proto::h1::io] flushed 71 bytes
[2024-05-12T21:22:52Z DEBUG hyper::proto::h1::io] parsed 9 headers
[2024-05-12T21:22:52Z DEBUG hyper::proto::h1::conn] incoming body is content-length (6 bytes)
[2024-05-12T21:22:52Z DEBUG hyper::proto::h1::conn] incoming body completed
[2024-05-12T21:22:52Z DEBUG hyper::client::pool] pooling idle connection for ("http", 127.0.0.1)
[2024-05-12T21:22:52Z DEBUG bitcoincore_rpc] JSON-RPC request: listunspent []
[2024-05-12T21:23:07Z DEBUG bitcoincore_rpc] JSON-RPC failed parsing reply of listunspent: JsonRpc(Transport(SocketError(Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" })))
error: JSON-RPC error: transport error: Couldn't connect to host: Resource temporarily unavailable (os error 35)

Let me know if there's any other output I can provide. This is quite urgent as I need to access some assets in here soonish, but don't have a safe way to via ord client atm (I could prob use sparrow but I'm not sure what precautions I need to take with runes?)

[PeakyBlinders52]

Is there any way to find out the best way to get started with wallets and stacking sats I have a project that is all ready for deployment I'm just inexperienced so I am not sure how to push it out there

[dozer-eth]

Thanks to the patience and diligence of Greg from the Ordicord, we were able to figure out that upgrading bitcoin core from 24.0.1 to 27.0.0 fixed it!

ord wallet balance still returns an error initially before the default "ord" wallet is loaded. But after the wallet loaded I called it again and it worked!

Also prior to that, Greg helped manually craft txns with bitcoin-cli to move the inscriptions I needed to move (many thanks!!!).