Is monero controlled by a 51% attacker? If so, then there is a new attack vector against monero's privacy: shotgun kyc. A 51% attacker can refuse to let any transactions into the blockchain unless their authors identify themselves via a KYC platform

All of the ones I've tried to use on the web regularly fail to deliver content because of a CORS restriction. I think most people who set those up want the "visual" block explorer in the browser but don't care about letting other people "programmatically" access that data from a browser. Even mempool.space and blockstream.info throw cors errors if a web page queries their api endpoints via the `fetch` method, for example

> websockets socket proxy is usually the answer

I think it's part of the solution, except for this: if the user has to run the proxy, it's much less effective as a browser wallet. You might as well just "install" a wallet. That's why I wonder if any bitcoin nodes are running a generic websockets-to-tcp proxy like Websockify in front of their bitcoin node. If they are, then I can design a web wallet which gets block data from *them,* that way the user doesn't need to run a full node -- they'll just download data from other nodes, the same way "thin" bitcoin clients are supposed to do.

I want to build a web wallet that uses Compact Block Filters

To do it, I think I need a reliable way to get data from bitcoin nodes in a web context, particularly (1) block headers (2) compact block filters (3) blocks themselves

Has anyone done any research into this? I found at least one electrum server that exposes its p2p interface via websockets, but I don't know if any bitcoin nodes do that. I thought about getting block headers from electrum servers and then downloading blocks from services like mempool_space and blockstream_info, but I suspect their rate limits would stop me from downloading more than ~100 blocks, and that still leaves me with the problem of finding someone that serves compact block filters in a web-friendly way.

What to do? Has anyone thought about running websockify on top of a bitcoin node to expose its p2p interface to the web? Maybe if a few nodes did that, a directory of web-friendly bitcoin nodes could be created, and web-SPV wallets could download blocks and block filters from them. Is that a good idea? Seeking feedback 🙂

I made Bankify as a POC for how easy it is to receive cashu and convert it to LN: https://github.com/supertestnet/bankify

As usual, I don't recommend using my code directly, but consider reimplementing it. It's not a lot of logic to do this.

What if I am looking for "just" the set of bitcoin nodes that support compact block filters? Or "just" the Libre Relay nodes? Or maybe I'm exploring electrum servers and "just" want to find the ones that support websockets. It would be neat to have a website that makes this easy!

Here's an easy first project for a new bitcoin dev: make a "server explorer" for the various types of servers in bitcoin

Electrum servers, lightning nodes, and bitcoin nodes are all common servers that wallets and exchanges interact with. Lightning explorers are already very common (e.g. https://mempool.space/lightning), and this electrum server explorer already exists: https://1209k.com/bitcoin-eye/ele.php?chain=btc

But it isn't very pretty, and I'm not aware of anything similar for exploring bitcoin nodes and their features. Someone should make one that is beautiful and fun!

Here's an easy first project for a new bitcoin dev: make a "server explorer" for the various types of servers in bitcoin

Electrum servers, lightning nodes, and bitcoin nodes are all common servers that wallets and exchanges interact with. Lightning explorers are already very common (e.g. https://mempool.space/lightning), and this electrum server explorer already exists: https://1209k.com/bitcoin-eye/ele.php?chain=btc

But it isn't very pretty, and I'm not aware of anything similar for exploring bitcoin nodes and their features. Someone should make one that is beautiful and fun!

Found a list: https://silentpayments.xyz/docs/wallets/

Does anyone know a list of bitcoin wallets that support Silent Payments, or have announced future support for it? Here are the ones I know of:

Cake Wallet

Dana Wallet

Silentium Wallet

> wouldn't it cause big problems to sort of scoop up the necessary proof "after the event"

I wonder if there's a nearly ideal setting where you dramatically reduce the size of your utxo set without greatly slowing down block validation. For example, spam outputs of the "fake pubkey" variety will eventually get pruned as they age, because most of those can never be spent -- other than a few proof-of-concept ones where someone used grinding to store data in a pubkey's first few bytes.

You could probably even optimize by whitelisting known exceptions and saying "don't prune these." I suspect there's a way to use techniques like these to prune something like 99.9% of "fake pubkey" outputs without significantly risking a detrimental slowdown of block validation.

Similar techniques can probably be applied to prune most of the 330-sat outputs associated with ordinals, which, once they pass a certain age, seem unlikely to ever be consolidated. Even if many of them *do* get consolidated someday, it wouldn't "stop" you from validating new blocks, it would just slow you down during the consolidation period; and the code can even be updated afterwards to except those ones so that it doesn't affect future users doing IBD.

I came up with a protocol that I think allows a node to prune its utxo set and still count as a fully validating node. So I no longer think it's true that it has to be held in ram -- I don't think it needs to be held at all, though I think the more of the utxo set you "keep around," the faster IBD would be. https://gist.github.com/supertestnet/6aa3dbeb7cb749741c18ed9335a23a81

Yes. This is the first project where vibe coding has proven helpful to me: I used an LLM to implement my protocol for checking if a pruned utxo is unspent, and it seems to work. So now I'm thinking of making a node implementation that lets users prune the utxo set, and when that setting is used, I'm wondering what amount of memory I should allocate to store the most recently created utxos. The more you keep, the less network queries you have to make. Perhaps I should just do some tests with different memory allocations and make a chart to visualize the results.

This protocol would massively slow down IBD if it prunes too aggressively, but I bet it would be a decent tradeoff if the numbers come out to something like, "you need 500 megabytes of memory to store 99% of the utxos that get created and consumed in a given day, and 1% of the time you'll have to do a network query because a pruned utxo got spent."

Does anyone know of research along the lines of the following assumptions? On an average day in bitcoin, I assume most of the utxos consumed are relatively recent, and most of the utxos created are soon consumed. How much memory do you need to store 100% of them? 90%? 80%? 70%?

I believe bitcoin asks 10 nodes for block data: 8 "regular" peers and 2 "blocks only" peers. It thus has an implicit trust assumption that at least one of them will provide data for your node to validate. I suspect the same N can be used in this protocol without any change in the trust assumptions: your only expectation is that one of your peers will provide the data (the proof) if it exists, and you then validate the proof yourself.

Does anyone know of research along the lines of the following assumptions? On an average day in bitcoin, I assume most of the utxos consumed are relatively recent, and most of the utxos created are soon consumed. How much memory do you need to store 100% of them? 90%? 80%? 70%?

Perhaps, I'm not sure. But after posting this, I thought of something that I find very interesting: it's not actually necessary for bitcoin nodes to participate in this protocol or run anything special, because I realized that electrum servers already do something equivalent to the thing I want.

What I mean is, a node that wants to follow this protocol -- let's call it the Pruning Node -- can just pretend to be a "normal" bitcoin node. It can prune its utxo set, but not tell anyone, and peer with "normal" bitcoin peers -- there is no need for them to signal anything special, because the Pruning Node will get the missing utxo data from electrum servers, as I will explain how to do in a moment. The Pruning Node just requests blocks as usual from its normal, standard bitcoin peers, as every node does, and does not act special in any way.

Now suppose one of its peers gives it a new block, and that block contains a transaction P that claims to spend utxo Q, which our Pruning Node pruned. How does it validate transaction P? Instead of asking its *bitcoin peers* for a proof that utxo Q got spent, it asks a random set of "electrum servers" for that proof. Electrum servers can already supply the requisite proof via the following procedure:

Step A. Get the txid and vout of utxo Q. You can get it from the transaction that tries to spend it, i.e. transaction P, because every bitcoin transaction has to say in its inputs section the txid and vout of any transaction it tries to spend.

Step B. Use the txid and vout of utxo Q to query electrum servers for two merkle proofs, which you should validate (note that all electrum servers have methods that return a merkle proof for any transaction you throw at them -- that's a huge part of what they are *for*); the first merkle proof proves that utxo Q was created, and the second one proves that it was spent. The latter one should just be a proof that the transaction you are trying to validate is contained in the block you are currently validating, but if they provide a proof it was spent in some *earlier* block instead, then you are done, because that means the transaction you are validating is invalid.

Note that there is an excellent reason to have confidence that *some* electrum server will give you the data you need if utxo Q was created at some point in the past and then spent in the current block (or a prior one). This is the assumption outlined in Number 1 of my idea: someone in your peer group will always supply you with the block data you need, otherwise bitcoin itself doesn't work. Here, we are treating electrum servers as a kind of peer. So, if no server gives you the data, that means utxo Q was either never created or did not get spent in the current block, and that means the transaction you want to validate is invalid; whereas if they *do* give you the data you expect, that means utxo Q was created in the past and not spent until the current block, so utxo Q was available to spend, and the block is not invalid on those grounds -- meaning you can continue validating.

Voila! Electrum servers already have methods that let you check if a utxo was unspent; if you treat them as bitcoin peers, then per bitcoin's standard trust assumptions, you can have confidence that at least one of them will provide you with the data you need, and then you can simply validate it. If the data checks out, then your node is a fully validating bitcoin node but does not need to store the utxo set; it gets the requisite merkle proofs from electrum servers as needed, validates them using to its local copy of the blockchain headers, and then adds the now-validated block to its chain.

Pruned nodes already avoid signaling certain service bits (e.g. there is one that says a node is willing to share historical blocks, and they don't signal that bit) so just don't have them signal this service bit. Then your node can just ensure it has peers that *do* signal this service bit and it should be happy.

Today I came up with an idea for pruning the utxo set that I think is simpler to implement than utreexo

I outline the idea here: https://gist.github.com/supertestnet/6aa3dbeb7cb749741c18ed9335a23a81

Today I came up with an idea for pruning the utxo set that I think is simpler to implement than utreexo

I outline the idea here: https://gist.github.com/supertestnet/6aa3dbeb7cb749741c18ed9335a23a81