bitcoin-cli: Add -ipcconnect option by ryanofsky · Pull Request #32297 · bitcoin/bitcoin

ryanofsky · 2025-04-17T13:55:32Z

This implements an idea from sipa in #28722 (comment) to allow bitcoin-cli to connect to the node via IPC instead of TCP, if the ENABLE_IPC cmake option is enabled and the node has been started with -ipcbind.

This feature can be tested with:

build/bin/bitcoin-node -regtest -ipcbind=unix -debug=ipc
build/bin/bitcoin-cli -regtest -ipcconnect=unix -getinfo

The -ipconnect parameter can also be omitted, since this change also makes bitcoin-cli prefer IPC over HTTP by default, and falling back to HTTP if an IPC connection can't be established.

This PR is part of the process separation project.

DrahtBot · 2025-04-17T13:55:35Z

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32297.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	pinheadmz, enirox001, achow101
Concept ACK	laanwj, jlest01, yancyribbens, shahsb, sipa
Stale ACK	janb84, BrandonOdiwuor

If your review is incorrectly listed, please copy-paste  into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#bitcoin-core/gui/870 ([DRAFT] Expose AssumeUTXO Load Snapshot Functionality To The GUI by D33r-Gee)
#34935 (cli: Return more correct error on -norpccookiefile without -rpcpassword by maflcko)
#34342 (cli: Replace libevent usage with simple http client by fjahr)
#33585 (cmake: Use builtin support for .manifest files by purpleKarrot)
#33117 (Interfaces: Expose UTXO Snapshot Loading and Add Progress Notifications by D33r-Gee)
#32061 (Replace libevent with our own HTTP and socket-handling implementation by pinheadmz)
#28690 (build: Introduce internal kernel library by sedited)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

src/bitcoin-cli.cpp

laanwj · 2025-04-17T14:40:55Z

Concept ACK, it'd be useful to have an utility that can talk to the node through IPC and making bitcoin-cli double for that prevents code duplication.

jlest01 · 2025-04-17T18:28:29Z

Concept ACK, as it can make communication between the CLI and the node simpler and configuration-free.

pinheadmz · 2025-04-17T18:58:45Z

concept ACK, cool idea and will review. Does this close #5029 (adding unix sockets to the bitcoind rpc api) or does it only apply to bitcoin-node? Or is IPC protocol different from RPC and must be defined in the client?

ryanofsky · 2025-04-17T19:16:42Z

concept ACK, cool idea and will review. Does this close #5029 (adding unix sockets to the bitcoind rpc api) or does it only apply to bitcoin-node? Or is IPC protocol different from RPC and must be defined in the client?

It uses capnproto, so it may or may not achieve goals of #5029 depending on what they are. This PR does make it possible to call RPC methods over a unix socket, but in order to do that you need to use capnproto which is not available everywhere. For example there wouldn't be an easy way for our python test framework to use the socket directly unless it depended on https://github.com/capnproto/pycapnp. So another solution that uses a another protocol or just uses http over the socket might be preferable to this approach. But the first commit here could be useful for supporting other approaches as well.

ryanofsky

Updated df40f46 -> 538521a (pr/ipc-cli.2 -> pr/ipc-cli.3, compare) handling -rpcconnect option, adding a test, making various cleanups, adding comments, and fixing CI failures in non-ipc builds
Updated 538521a -> bd29de3 (pr/ipc-cli.3 -> pr/ipc-cli.4, compare) fixing compile error in intermediate commit, https://github.com/bitcoin/bitcoin/actions/runs/14538988101/job/40793056407?pr=32297, fixing functional test failure when socket path is too long https://cirrus-ci.com/task/6103052337283072, and adding new test to cover "bitcoin-cli was not built with IPC support" error

src/bitcoin-cli.cpp

yancyribbens · 2025-04-19T12:37:46Z

Concept ACK

luke-jr · 2025-04-21T22:37:17Z

This looks like it uses JSON-RPC inside Capnproto? Why not just use straight Capnproto?

ryanofsky · 2025-04-21T23:31:42Z

This looks like it uses JSON-RPC inside Capnproto? Why not just use straight Capnproto?

Yes it is skipping the HTTP part of the protocol but keeping the JSON part. The capnproto interface this exposes looks like:

interface Rpc $Proxy.wrap("interfaces::Rpc") {
    executeRpc @0 (context :Proxy.Context, request :Text, uri :Text, user :Text) -> (result :Text);
}

where request and response above are JSON text strings with the expected JSON-RPC fields. The schema could be unwrapped further, or the data could be sent in some binary json format depending on what your goal is but that interface was the simplest way I could think of implementing this feature.

shahsb

Concept ACK

laanwj · 2025-04-24T12:25:16Z

The schema could be unwrapped further, or the data could be sent in some binary json format depending on what your goal is but that interface was the simplest way I could think of implementing this feature.

Right, Say, representing the entire RPC protocol as cap'n'proto structures directly would be interesting (anologous to how c-lightning has a gRPC version of their RPC), but this would be a huge project for which the first step would be the formal definition of the RPC protocol (including specific-enough types) so that that can be automatically generated.

And this would make it harder to make a cli tool, not easier, because the client needs to know the protocol to convert its command line to suitable calls.

So sending the JSON inside the interface seems like a good, low-impact way to implement this tool.

sipa · 2025-04-30T14:45:47Z

Concept ACK

pinheadmz · 2025-05-01T19:23:59Z

While reviewing this I hit some weird behavior where bitcoin-node doesn't fully shutdown.

To reproduce:

In terminal 1: build/bin/bitcoin-node -regtest -ipcbind=unix -debug=rpc -debug=http -debug=ipc

Terminal 2: build/bin/bitcoin-cli -regtest waitforblock 0000000000079f8ef3d2c688c244eb7a4570b24c9ed7b4a8c619eb02596f8862
(this will wait forever)

go back to terminal 1 and ctrl-c. I get Shutdown: done in the output but the process does not quit.

Then funny stuff like this, in Terminal 3:

--> build/bin/bitcoin-cli -regtest getblockcount
error code: -32603
error message:
Node chainman not found

--> build/bin/bitcoin-cli -regtest -getinfo
error code: -1
error message:
Internal bug detected: RPC call "getnetworkinfo" returned incorrect type:
{
    "localservices": "key missing, despite not being optional in doc",
    "localservicesnames": "key missing, despite not being optional in doc",
    "localrelay": "key missing, despite not being optional in doc",
    "timeoffset": "key missing, despite not being optional in doc",
    "connections": "key missing, despite not being optional in doc",
    "connections_in": "key missing, despite not being optional in doc",
    "connections_out": "key missing, despite not being optional in doc",
    "networkactive": "key missing, despite not being optional in doc",
    "relayfee": "key missing, despite not being optional in doc",
    "incrementalfee": "key missing, despite not being optional in doc"
}
Bitcoin Core v29.99.0-9ff5bc75659e
Please report this issue here: https://github.com/bitcoin/bitcoin/issues

I had to use killall -9 bitcoin-node to clean up

sipa

Concept ACK and mild code review ACK.

pinheadmz · 2026-01-22T18:24:48Z

Range diff since last review shows rebase including updating logging calls. Two commits were pulled out, and i think the libmultiprocess fixes were pulled in to master? Is this ready for review again?

ryanofsky · 2026-01-22T18:41:33Z

Yep, it's ready for review. I don't think there have been any real changes. The commits that were dropped just became part of #33201, IIRC

pinheadmz

ACK b23e42a

Built and tested on arm64/macos. Re-reviewed each commit to refresh my memory on how interfaces work. A few questions below, nothing breaking but I am curious about the choice of ExecuteHTTPRPC vs JSONRPCExec().

Show Signature

pinheadmz's public key is on openpgp.org

pinheadmz · 2026-02-17T21:25:56Z

src/httprpc.cpp

 }

-static bool HTTPReq_JSONRPC(const std::any& context, HTTPRequest* req)
+UniValue ExecuteHTTPRPC(const UniValue& valRequest, JSONRPCRequest& jreq, HTTPStatusCode& status)


b56a36a

Looking at this with fresh eyes after some time, and I'm wondering why to expose this to the interface instead of going directly to JSONRPCExec()? Or essentially pull out the chunk of this function starting from // Execute each request .

We shouldn't need HTTP status codes at all for RPC over IPC

re: #32297 (comment)

Reason for calling the HTTP function instead of the JSONRPCExec is just that the HTTP function provides some additional functionality like user authorization and method whitelisting. I imagine in the future it could also provide more functionality like having different default wallets or different settings for different users.

It would be reasonable for the IPC inteface to just expose the JSON-RPC methods without any higher level functionality, but since the IPC interface is used by bitcoin-cli I think it makes sense to provide whatever allows bitcoin-cli to be fully functional.

pinheadmz · 2026-02-18T14:20:25Z

src/interfaces/rpc.h

+} // namespace node
+
+namespace interfaces {
+//! Interface giving clients ability to emulate RPC calls.


d408dc5

nit: "emulate"? Isn't the client literally making a remote procedure call?

re: #32297 (comment)

nit: "emulate"? Isn't the client literally making a remote procedure call?

That's a good point, this should be changed to say HTTP RPC since technically it is making a JSON-RPC call, and technically Cap'n Proto is also an RPC protocol.

Made this change locally so this will be updated if there is another push.

pinheadmz · 2026-02-18T15:04:28Z

src/ipc/interfaces.cpp

            } catch (const std::system_error& e) {
                // If connection type is auto and socket path isn't accepting connections, or doesn't exist, catch the error and return null;
-                if (e.code() == std::errc::connection_refused || e.code() == std::errc::no_such_file_or_directory) {
+                if (e.code() == std::errc::connection_refused || e.code() == std::errc::no_such_file_or_directory || e.code() == std::errc::not_a_directory) {


42b51dc

Kinda surprised this isn't std::errc::filename_too_long

re: #32297 (comment)

Kinda surprised this isn't std::errc::filename_too_long

Interesting, I didn't know about that error code. In theory I think that error might be possible but in practice the maximum socket filename length is shorter than maximum path length on all platforms. The socket filename length error is handled separately below and originates from Bitcoin IPC code rather than from the OS:

bitcoin/src/ipc/process.cpp

Lines 86 to 89 in 9e4567b

if (path_str.size() >= sizeof(addr.sun_path)) {

error = strprintf("Unix address path %s exceeded maximum socket path length", fs::quoted(fs::PathToString(path)));

return false;

}

bitcoin/src/ipc/process.cpp

Lines 106 to 108 in 9e4567b

if (!ParseAddress(address, data_dir, dest_exe_name, addr, error)) {

throw std::invalid_argument(error);

}

ryanofsky

Thanks for the review!

ryanofsky · 2026-02-18T17:14:47Z

src/httprpc.cpp

 }

-static bool HTTPReq_JSONRPC(const std::any& context, HTTPRequest* req)
+UniValue ExecuteHTTPRPC(const UniValue& valRequest, JSONRPCRequest& jreq, HTTPStatusCode& status)


re: #32297 (comment)

Reason for calling the HTTP function instead of the JSONRPCExec is just that the HTTP function provides some additional functionality like user authorization and method whitelisting. I imagine in the future it could also provide more functionality like having different default wallets or different settings for different users.

It would be reasonable for the IPC inteface to just expose the JSON-RPC methods without any higher level functionality, but since the IPC interface is used by bitcoin-cli I think it makes sense to provide whatever allows bitcoin-cli to be fully functional.

ryanofsky · 2026-02-18T17:16:06Z

src/interfaces/rpc.h

+} // namespace node
+
+namespace interfaces {
+//! Interface giving clients ability to emulate RPC calls.


re: #32297 (comment)

nit: "emulate"? Isn't the client literally making a remote procedure call?

That's a good point, this should be changed to say HTTP RPC since technically it is making a JSON-RPC call, and technically Cap'n Proto is also an RPC protocol.

Made this change locally so this will be updated if there is another push.

ryanofsky · 2026-02-18T17:21:39Z

src/ipc/interfaces.cpp

            } catch (const std::system_error& e) {
                // If connection type is auto and socket path isn't accepting connections, or doesn't exist, catch the error and return null;
-                if (e.code() == std::errc::connection_refused || e.code() == std::errc::no_such_file_or_directory) {
+                if (e.code() == std::errc::connection_refused || e.code() == std::errc::no_such_file_or_directory || e.code() == std::errc::not_a_directory) {


re: #32297 (comment)

Kinda surprised this isn't std::errc::filename_too_long

Interesting, I didn't know about that error code. In theory I think that error might be possible but in practice the maximum socket filename length is shorter than maximum path length on all platforms. The socket filename length error is handled separately below and originates from Bitcoin IPC code rather than from the OS:

bitcoin/src/ipc/process.cpp

Lines 86 to 89 in 9e4567b

if (path_str.size() >= sizeof(addr.sun_path)) {

error = strprintf("Unix address path %s exceeded maximum socket path length", fs::quoted(fs::PathToString(path)));

return false;

}

bitcoin/src/ipc/process.cpp

Lines 106 to 108 in 9e4567b

if (!ParseAddress(address, data_dir, dest_exe_name, addr, error)) {

throw std::invalid_argument(error);

}

Add a MakeBasicInit() function so simpler standalone IPC clients like bitcoin-mine in bitcoin#30437 and bitcoin-cli in bitcoin#32297 that only initiate IPC connections without exposing any IPC interfaces themselves can to avoid needing to implement their own specialized interfaces::Init subclasses.

Add ExecuteHTTPRPC to provide a way to execute an HTTP request without relying on HTTPRequest and libevent types. Behavior is not changing in any way, this is just moving code. This commit may be easiest to review using git's --color-moved option.

This allows `bitcoin-cli` to connect to the node via IPC instead TCP to execute RPC methods in an upcoming commit.

This implements an idea from Pieter Wuille <pieter@wuille.net> bitcoin#28722 (comment) to allow `bitcoin-cli` to connect to the node via IPC instead of TCP, if the `ENABLE_IPC` cmake option is enabled and the node has been started with `-ipcbind`. The feature can be tested with: build/bin/bitcoin-node -regtest -ipcbind=unix -debug=ipc build/bin/bitcoin-cli -regtest -ipcconnect=unix -getinfo The `-ipconnect` parameter can also be omitted, since this change also makes `bitcoin-cli` prefer IPC over HTTP by default, and falling back to HTTP if an IPC connection can't be established.

When an invalid socket path is passed to -ipcconnect, either because the path exceeds the maximum socket length, or the path includes a directory component which is not actually a directory, treat this the same as the same as the socket refusing connections or not existing, instead of treating it like a more serious I/O error and throwing a fatal exception. This is needed to avoid CI errors after the following commit which adds a functional test and uses -datadir paths exceeding the maximum socket length when running in CI.

Co-authored-by: Sjors Provoost <sjors@sprovoost.nl>

A missing Init::makeMining implementation was causing internal code using the mining interface (like the `waitforblockheight` RPC method) to not work when running inside the `bitcoin-gui` binary. It was working the other bitcoin binaries ('bitocind`, `bitcoin-qt`, and `bitcoin-node`) because they implmemented `Init::makeMining` methods in commit 8ecb681 from bitcoin#30200, but the `bitcoin-gui` init class was forgotten in that change. This bug was reported by Matthew Zipkin <pinheadmz@gmail.com> bitcoin#32297 (review)

pinheadmz · 2026-03-09T16:08:46Z

src/init.cpp

    argsman.AddArg("-server", "Accept command line and JSON-RPC commands", ArgsManager::ALLOW_ANY, OptionsCategory::RPC);
    if (can_listen_ipc) {
-        argsman.AddArg("-ipcbind=<address>", "Bind to Unix socket address and listen for incoming connections. Valid address values are \"unix\" to listen on the default path, <datadir>/node.sock, or \"unix:/custom/path\" to specify a custom path. Can be specified multiple times to listen on multiple paths. Default behavior is not to listen on any path. If relative paths are specified, they are interpreted relative to the network data directory. If paths include any parent directory components and the parent directories do not exist, they will be created.", ArgsManager::ALLOW_ANY, OptionsCategory::IPC);
+        argsman.AddArg("-ipcbind=<address>", "Bind to Unix socket address and listen for incoming connections. Valid address values are \"unix\" to listen on the default path, <datadir>/node.sock, or \"unix:/custom/path\" to specify a custom path. Can be specified multiple times to listen on multiple paths. Default behavior is not to listen on any path. If relative paths are specified, they are interpreted relative to the network data directory. If paths include any parent directory components and the parent directories do not exist, they will be created. Enabling this gives local processes that can access the socket unauthenticated RPC access, so it's important to choose a path with secure permissions if customizing this.", ArgsManager::ALLOW_ANY, OptionsCategory::IPC);


I might be doing something wrong here, but I am not seeing this help message in bitcoind -h or bitcoin node -h. Stepping through with debugger, the reason seems to be that SetupServerArgs() is called on the NodeContext's interfaces::Init which has canListenIpc() { return false; }

re: #32297 (comment)

Nice find. The current behavior is expected but pointlessly confusing.

The goal of this code is to show -ipcbind help when bitcoin-node -h is run and not show it when bitcoind -h is run, which is what you are observing.

The problem is the bitcoin wrapper prefers to call bitcoind instead of bitcoin-node when no IPC options are specified. So when you run bitcoin node -h you won't see any IPC help. A fix for this would be to make the wrapper prefer bitcoin-node when help is requested like:

--- a/src/bitcoin.cpp +++ b/src/bitcoin.cpp @@ -168,7 +168,7 @@ bool UseMultiprocess(const CommandLine& cmd) // If any -ipc* options are set these need to be processed by a // multiprocess-capable binary. - return args.IsArgSet("-ipcbind") || args.IsArgSet("-ipcconnect") || args.IsArgSet("-ipcfd"); + return args.IsArgSet("-ipcbind") || args.IsArgSet("-ipcconnect") || args.IsArgSet("-ipcfd") || HelpRequested(args); } //! Execute the specified bitcoind, bitcoin-qt or other command line in `args`

Oh gotcha, bitcoin-node vs bitcoin node explains what I had here and not a blocker for this PR

pinheadmz

ACK 4565cff

Minimal diff since last review, fix conflict with change to mining interface.

Another thing i noticed is that -rpcclienttimeout is ignore when connecting by IPC. Not a deal breaker. If we add it back we should avoid libevent and I guess use CScheduler like #32862 ?

Show Signature

pinheadmz's public key is on openpgp.org

enirox001

Tested ACK 4565cff

Built on Fedora with ENABLE_IPC=ON. Ran interface_ipc_cli.py,
all tests pass.

Manually tested the following rpc commands

    bitcoin-node -regtest -ipcbind=unix -debug=ipc
    bitcoin-cli -regtest -ipcconnect=unix -getinfo
    bitcoin-cli -regtest -ipcconnect=unix getblocktemplate '{"rules": ["segwit"]}'

When node is stopped, -ipcconnect=auto correctly falls back to HTTP path.

achow101 · 2026-03-30T21:49:02Z

ACK 4565cff

Sjors · 2026-03-31T12:44:23Z

Given that this PR takes the number of potential unix socket connections well beyond one (in the typical Mining IPC use case), we should introduce something like -maxconnections and use it for min_required_fds.

enirox001 · 2026-04-01T08:36:22Z

Given that this PR takes the number of potential unix socket connections well beyond one (in the typical Mining IPC use case), we should introduce something like -maxconnections and use it for min_required_fds.

Opened #34978 to address this

ryanofsky mentioned this pull request Apr 17, 2025

Multiprocess tracking issue #28722

Open

ryanofsky force-pushed the pr/ipc-cli branch from 0d9473f to df40f46 Compare April 17, 2025 14:02

DrahtBot added the CI failed label Apr 17, 2025

laanwj added the RPC/REST/ZMQ label Apr 17, 2025

laanwj reviewed Apr 17, 2025

View reviewed changes

src/bitcoin-cli.cpp Show resolved Hide resolved

This was referenced Apr 17, 2025

Replace libevent with our own HTTP and socket-handling implementation #32061

Open

ipc: add bitcoin-mine test program #30437

Open

scripted-diff: Use LogInfo over LogPrintf #29641

Merged

multiprocess: Add capnp wrapper for Chain interface #29409

Open

ryanofsky force-pushed the pr/ipc-cli branch from df40f46 to 538521a Compare April 18, 2025 17:21

ryanofsky commented Apr 18, 2025

View reviewed changes

src/bitcoin-cli.cpp Show resolved Hide resolved

ryanofsky force-pushed the pr/ipc-cli branch from 538521a to bd29de3 Compare April 18, 2025 18:09

ryanofsky marked this pull request as ready for review April 18, 2025 18:10

DrahtBot removed the CI failed label Apr 18, 2025

DrahtBot mentioned this pull request Apr 19, 2025

Remove the legacy wallet and BDB dependency #28710

Merged

ryanofsky force-pushed the pr/ipc-cli branch from bd29de3 to 9ff5bc7 Compare April 21, 2025 15:47

DrahtBot mentioned this pull request Apr 22, 2025

multiprocess: Add bitcoin wrapper executable #31375

Merged

shahsb reviewed Apr 23, 2025

View reviewed changes

ryanofsky mentioned this pull request Apr 30, 2025

ipc: add windows support #32387

Draft

sipa reviewed Nov 10, 2025

View reviewed changes

This was referenced Nov 23, 2025

qa: Remove no longer needed feature_dirsymlinks.py #33924

Closed

log: Use more severe log level (warn/err) where appropriate #33960

Merged

DrahtBot mentioned this pull request Dec 15, 2025

refactor: unify container presence checks #33192

Merged

ryanofsky mentioned this pull request Jan 12, 2026

crash during IPC cleanup after interruptWait() is called #34250

Closed

DrahtBot mentioned this pull request Jan 20, 2026

cli: Replace libevent usage with simple http client #34342

Draft

DrahtBot mentioned this pull request Jan 27, 2026

[POC] Full Libevent removal #34411

Draft

DrahtBot mentioned this pull request Feb 6, 2026

mining: add cooldown to createNewBlock() immediately after IBD #34184

Merged

DrahtBot mentioned this pull request Feb 14, 2026

mining: Break compatibility with existing IPC mining clients #34568

Merged

pinheadmz approved these changes Feb 18, 2026

View reviewed changes

ryanofsky commented Feb 18, 2026

View reviewed changes

ryanofsky and others added 7 commits February 27, 2026 19:26

refactor: Add ExecuteHTTPRPC function

df76891

Add ExecuteHTTPRPC to provide a way to execute an HTTP request without relying on HTTPRequest and libevent types. Behavior is not changing in any way, this is just moving code. This commit may be easiest to review using git's --color-moved option.

ipc: Expose an RPC interface over the -ipcbind socket

6a54834

This allows `bitcoin-cli` to connect to the node via IPC instead TCP to execute RPC methods in an upcoming commit.

test: add interface_ipc_cli.py testing bitcoin-cli -ipcconnect

fbea576

Co-authored-by: Sjors Provoost <sjors@sprovoost.nl>

pinheadmz reviewed Mar 9, 2026

View reviewed changes

pinheadmz approved these changes Mar 10, 2026

View reviewed changes

enirox001 reviewed Mar 12, 2026

View reviewed changes

DrahtBot mentioned this pull request Mar 14, 2026

[wip] ignore 2603 ci empty #34726

Closed

DrahtBot mentioned this pull request Mar 28, 2026

cli: Return more correct error on -norpccookiefile without -rpcpassword #34935

Closed

enirox001 mentioned this pull request Apr 1, 2026

init: Reserve file descriptors for IPC connections #34978

Open

bolty-from-atl-bitlab bot mentioned this pull request Apr 3, 2026

Bitcoin Socratic Seminar #49 - Topic Suggestions atlantabitdevs/atlbit.dev#141

Open

	if (path_str.size() >= sizeof(addr.sun_path)) {
	error = strprintf("Unix address path %s exceeded maximum socket path length", fs::quoted(fs::PathToString(path)));
	return false;
	}

	if (!ParseAddress(address, data_dir, dest_exe_name, addr, error)) {
	throw std::invalid_argument(error);
	}

Conversation

ryanofsky commented Apr 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DrahtBot commented Apr 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage & Benchmarks

Reviews

Conflicts

Uh oh!

Uh oh!

laanwj commented Apr 17, 2025

Uh oh!

jlest01 commented Apr 17, 2025

Uh oh!

pinheadmz commented Apr 17, 2025

Uh oh!

ryanofsky commented Apr 17, 2025

Uh oh!

ryanofsky left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

yancyribbens commented Apr 19, 2025

Uh oh!

luke-jr commented Apr 21, 2025

Uh oh!

ryanofsky commented Apr 21, 2025

Uh oh!

shahsb left a comment

Choose a reason for hiding this comment

Uh oh!

laanwj commented Apr 24, 2025

Uh oh!

sipa commented Apr 30, 2025

Uh oh!

pinheadmz commented May 1, 2025

Uh oh!

sipa left a comment

Choose a reason for hiding this comment

Uh oh!

pinheadmz commented Jan 22, 2026

Uh oh!

ryanofsky commented Jan 22, 2026

Uh oh!

pinheadmz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ryanofsky left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pinheadmz left a comment

Choose a reason for hiding this comment

Uh oh!

enirox001 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

ryanofsky commented Apr 17, 2025 •

edited

Loading

DrahtBot commented Apr 17, 2025 •

edited

Loading

ryanofsky left a comment •

edited

Loading

enirox001 left a comment •

edited

Loading