<div dir="ltr"><div>I noticed your mention of a missing pubkey identity capability. </div><div><br></div><div>A censorship-resistant key-based discovery mechanism is available, PKDNS, at <a href="http://github.com/pubky/pkarr">github.com/pubky/pkarr</a> (also /mainline and /pkdns), which essentially provides public-key domains controlled by the keyholder. </div><div><br></div><div>No blockchains, just the largest, oldest, p2p network on earth, Mainline DHT.</div><div><br></div><div>This could be used to dynamically provide or update any endpoint, associate or disassociate keys, or create revokable account-based sessions, etc.</div><div><br></div><div>These links may address peoples' likely counterarguments:</div><div>- <a href="https://medium.com/pubky/public-key-domains-censorship-resistance-explained-33d0333e6123">https://medium.com/pubky/public-key-domains-censorship-resistance-explained-33d0333e6123</a></div><div>- <a href="https://medium.com/pubky/mainline-dht-censorship-explained-b62763db39cb">https://medium.com/pubky/mainline-dht-censorship-explained-b62763db39cb</a></div><div><br></div><div>Maybe this helps you, or others looking for such primitives!</div><div> </div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span style="color:rgb(34,34,34)">--</span><br style="color:rgb(34,34,34)"><div dir="ltr" style="color:rgb(34,34,34)"><div dir="ltr">John Carvalho</div><div dir="ltr">CEO, <a href="http://synonym.to/" style="color:rgb(17,85,204)" target="_blank">Synonym.to</a><br><div><font size="1"><br></font></div><div></div></div></div></div></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, May 27, 2025 at 12:23 PM Peter Todd <<a href="mailto:pete@petertodd.org">pete@petertodd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Recently proponents of transaction "filtering" have started sybil attacking<br> Libre Relay nodes by running nodes with their "garbageman" fork¹. This fork<br> falsely advertise the NODE_LIBRE_RELAY service bit, silently discards<br> transactions that would be relayed by real Libre Relay nodes, and does not<br> provide any. Additionally, they have made clear that they intend to ramp up<br> this sybil attack with the aim of preventing people people from getting<br> transactions that they disagree with mined:<br> <br> The costs will increase even more once Libre Relay’s DoS attacks on<br> bitcoin are countered by enough defensive nodes.<br> -Chris Guida <a href="https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697/4" rel="noreferrer" target="_blank">https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697/4</a><br> <br> They have also put effort into making the attack more than a simple proof of<br> concept, e.g. by adding code that attempts to make it more difficult to detect<br> attacking nodes, by keeping track of transactions received from peers, and then<br> replying to inv messages with those transactions even when they were<br> discarded².<br> <br> With this attack in mind, I thought this would be a good opportunity to review<br> the math on how effective this type of attack is, as well as some of the<br> mitigations that could be implement to defeat sybil attacks on transaction<br> relaying. In particular, I'll present a defense to sybil attacks that is<br> sufficiently powerful that it may even negate the need for preferential peering<br> techniques like the NODE_LIBRE_RELAY bit. <br> <br> Note that I don't deserve credit for any of these ideas. I'm just putting down<br> in writing some ideas from Gregory Maxwell and others.<br> <br> <br> # The Effectiveness of Sybil Attacks on Transaction Relaying <br> <br> Non-listening nodes make a certain number of outgoing, transaction relaying,<br> connections to listening nodes. In the case of Bitcoin Core, 8 outgoing<br> transaction relaying nodes; in the case of Libre Relay, an additional 4<br> outgoing connections to other Libre Relay nodes to relay transactions relevant<br> to them.<br> <br> For a sybil attack to succeed against a non-listing node, every one of the N<br> outgoing connections must be either a sybil attacking node, or a listening node<br> that itself has been defeated by sybil attack. Additionally, Bitcoin Core makes<br> outgoing IPv4 and IPv6 connections to a diversity of address space, so the<br> sybil attacking nodes need to themselves be running on a diverse set of IP<br> addresses (this is not that difficult to achieve with VPS providers these<br> days). Thus if the sybil attacking nodes are a ratio of q to all nodes, the<br> probability of the attack succeeding is q^N.<br> <br> Against Libre Relay, N=4, this means that the attacker needs to be running ~84%<br> of all NODE_LIBRE_RELAY advertising nodes to have an attack success probability<br> of ~50%. Based on information from my Bitcoin seed node, there appear to be<br> about 15 Libre Relay nodes, so for a 50% attack success probability the<br> attackers would need to run about 85 attack nodes. If N was increased to 8, the<br> attackers would need about 172 nodes to achieve the same success rate.<br> <br> Against *listening* nodes a different type of attack is necessary. The reason<br> for this is that defenders can easily defeat sybil attacks against listening<br> nodes by simply connecting to ~all listening nodes at once to ensure that<br> transaction propagation succeeds. Of course, the attacker can in turn do things<br> like attempt to exhaust connection slots of Libre Relay nodes, or simply DoS<br> attack them with packet floods. But those are different types of attack than<br> the sybil attack we are discussing here.<br> <br> <br> # Prior Art: Defeating Block Propagation Sybil Attack<br> <br> Bitcoin Core already includes a defense against sybil attack for block<br> propagation: the feeler node system. Basically, every ~2 minutes an outgoing<br> connection is made to a gossiped address to check if a connection can be made;<br> successful connections are recorded in a table of "tried" addresses. If no new<br> blocks have been received for 30 minutes, these tried addresses are then used<br> every 10 minutes to try to find a peer that does know about a new block. <br> <br> Since this process goes on indefinitely, so long as outgoing connections are<br> themselves not censored (e.g. by the ISP), the node should eventually find a<br> non-sybil attacking node and learn about the true most-work chain. Even in<br> normal operation periods of >30minutes between blocks are fairly common, so<br> this defense will (eventually) work even if a forked chain exists with some<br> hash power extending it.<br> <br> This approach is relatively straightforward for block propagation, as there is<br> a clear metric: the most-work chain. Peers that aren't giving you the most-work<br> chain can be ignored, and new peers found. Proof-of-work's inherently<br> self-validating property means that doing this is cheap and straight forward.<br> <br> <br> # Directionality<br> <br> A subtlety to the information censorship sybil attack is there are actually two<br> different simultaneous attacks: the attack on preventing you from learning<br> about new information, and the attack on preventing you from distribute new<br> information to others.<br> <br> With block propagation, most nodes most directly care about the first class of<br> attack: they want to learn about the most-work chain, and do not want that<br> information censored from them.<br> <br> For miners, in addition to knowing what the most-work chain is, they<br> (typically³) have a strong incentive to get their new blocks to all nodes as<br> quickly as possible. Also, all nodes have at least some incentive to do this as<br> Bitcoin will not function properly if miners are getting censored.<br> <br> These attacks are not the same! The most-work-chain metric is only directly<br> detecting and preventing the first class of attack. It only prevents the second<br> attack indirectly, by making it easier for honest nodes to learn about new<br> blocks and attempt to themselves propagate that information further.<br> <br> <br> # Most Fees Metric<br> <br> For transaction relaying, the moral equivalent to the most-work chain metric<br> are metrics based on the amount of new transaction fees that peers are<br> advertising to you. Unfortunately this isn't as straightforward to implement as<br> the most-work chain metric for a few reasons:<br> <br> 1) Resolution: differences in chain work are very clear, with even a single<br> additional block being a very significant difference. For transaction relaying,<br> we'd like to be able to successfully relay transaction types that only add a<br> small % to total fees.<br> 2) Bandwidth: a chain of 80 byte headers is sufficient to prove most-work;<br> transactions are much larger.<br> 3) Double-spends: mempools are not a consensus. Your peers may have<br> transactions that conflict with your transactions, yet in ways that don't<br> constitute a worthwhile RBF replacement (e.g. two different transactions<br> with the same fees and fee-rate).<br> <br> For example, one straight-forward approach would be to simply keep track of a<br> decaying average of new fees/sec each peer had advertised to you prior to you<br> advertising the transaction to them. Periodically, you could drop the peer with<br> the lowest new fees/sec ranking, and then connect to a new peer.<br> <br> However, it's not clear that this approach has sufficient resolution to<br> actually detect censorship of relatively uncommon transaction types.<br> Additionally, since transaction broadcasting is a one-shot event - we don't<br> have a mempool synchronization mechanism - this approach may not work well if<br> transaction demand is bursty.<br> <br> <br> # Most-Fees Next (Dobule) Block Mempool<br> <br> With the upcoming cluster mempool functionality that is expected to be added to<br> Core in the near future, transactions will be stored in memory in clusters<br> ordered by fees: essentially the order in which optimal blocks would be<br> created. This will make it computationally cheap to determine what the optimal<br> next block (or blocks) will be by simply iterating through transactions in<br> order, and stopping when N weight worth of transactions have been found.<br> <br> Thus nodes can cheaply compute the total fees in the top one or two blocks<br> worth of transactions they currently have in their mempool, and advertise this<br> fact to their peers. Finally, to prevent lying, we can add a mechanism for a<br> peer to get a copy of all these transactions to ensure that they're not missing<br> out on anything paying enough fees to get mined soon.<br> <br> While beyond the scope of this summary, there are many set-reconciliation<br> techniques available to do this in a bandwidth efficient manner. Basically,<br> through the existing transaction relay mechanisms we can expect mempools to be<br> relatively consistent between nodes. Thus, to get all transactions that your<br> peer has for the next block or two that you do not, you just need to transfer<br> the deltas between their next-block(s) mempool and yours.<br> <br> Concretely, suppose we do this with the next two blocks worth of transactions.<br> At worst, each node would need to periodically create a maximum 8MB serialized<br> "double-block", using up to 8MB of ram. Secondly, to apply this to all outgoing<br> connections, you'd need to periodically use a set-reconciliation protocol to<br> download the differences between each of your outgoing peers' double-blocks,<br> and attempt to add any newly discovered transactions to your mempool. At worst<br> for 8 peers this would be 64MB of useless data to download, assuming every<br> single transaction was a conflicting double-spend. Not great. But not that bad.<br> <br> As with the average fees idea, periodically you would drop the peer advertising<br> the lowest double-block of fees, and then connect to a new peer to see if<br> they're better.<br> <br> Now consider what happens if you are sybil attacked. Due to RBF, with<br> synchronous mempools across different nodes with the same standardness policies<br> will have very similar transaction sets; even without active synchronization<br> long-running mempools across different nodes are already very similar in terms<br> of total fees. Thus even a small difference in transaction relay policy will<br> show up as missing transactions. This difference will translate into the sybil<br> attacking node(s) getting dropped, and honest nodes with policy compatible with<br> yours eventually being found.<br> <br> <br> ## Peers With More Liberal Relay Policy<br> <br> If you apply set reconciliation to a peer with a *more* liberal relay policy<br> than you, they'll have transactions that you will not accept. For example,<br> imagine the case of a peer that now accepts a new version number.<br> <br> One way to deal with this could be to just drop peers that give you<br> transactions that you consider non-standard. So long as reconciliation is only<br> applied to a subset of all transaction relaying peers, this is fine. Indeed,<br> even if this is applied to all transaction relaying peers, Bitcoin Core already<br> connects to additional peers in blocks-only mode. So you'll still get send and<br> receive blocks and maintain consensus.<br> <br> <br> ## Privacy<br> <br> Tracking what transactions are in mempools is a potential way for attackers to<br> trace transactions back to their origin. Provided that set-reconciliation is<br> only a secondary transaction relay mechanism, with sufficient time delays, this<br> should not impact privacy as under normal operation transactions will have<br> already propagated widely making the set reconciliation data non-sensitive.<br> <br> <br> # Manual Peering With Known-Honest Friendly Nodes<br> <br> More of a social solution than a technical solution, we should encourage people<br> to manually peer with other nodes they have a personal relationship with. This<br> is a powerful technique against sybil attacks for the simple reason that<br> person-to-person relationships can evaluate honesty in much more powerful ways<br> than any code could possibly do so.<br> <br> At the moment, actually doing this is inconvenient. Ideally we would have a<br> mechanism where node operators could get a simple pubkey@address connection<br> string from their node to tell to their friends, and equally, import that same<br> connection string into their bitcoin.conf. This mechanism should use some kind<br> of node identity to defeat MITM attacks, and also ensure that connection limits<br> are bypassed for friendly nodes. The existing addnode mechanism doesn't quite<br> achieve this. Notably, without a node identity mechanism, there's no way for<br> someone with a static IP address to whitelist a friend's node with a non-static<br> IP address.<br> <br> <br> # Footnotes<br> <br> 1) Chris Guida's "garbageman" branch: <a href="https://github.com/chrisguida/bitcoin/tree/garbageman" rel="noreferrer" target="_blank">https://github.com/chrisguida/bitcoin/tree/garbageman</a>,<br> first presented at the btc++ mempool edition (2025) hackathon<br> 2) <a href="https://github.com/chrisguida/bitcoin/commit/e9a921c045d64828a5f0de58d8f2706848c48fd2?s=09" rel="noreferrer" target="_blank">https://github.com/chrisguida/bitcoin/commit/e9a921c045d64828a5f0de58d8f2706848c48fd2?s=09</a><br> 3) <a href="https://petertodd.org/2016/block-publication-incentives-for-miners" rel="noreferrer" target="_blank">https://petertodd.org/2016/block-publication-incentives-for-miners</a><br> <br> -- <br> <a href="https://petertodd.org" rel="noreferrer" target="_blank">https://petertodd.org</a> 'peter'[:-1]@<a href="http://petertodd.org" rel="noreferrer" target="_blank">petertodd.org</a><br> <br> -- <br> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.<br> To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev%2Bunsubscribe@googlegroups.com" target="_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br> To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/aDWfDI03I-Rakopb%40petertodd.org" rel="noreferrer" target="_blank">https://groups.google.com/d/msgid/bitcoindev/aDWfDI03I-Rakopb%40petertodd.org</a>.<br> </blockquote></div> <p></p> -- <br /> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.<br /> To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br /> To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw%40mail.gmail.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw%40mail.gmail.com</a>.<br />