It *could* be, yes. But the attention this drama is getting, combined with my own anecdotal experience of a roughly 60/40 divide in favor of Core, suggests to me that if the spike in total node count was entirely organic, we would see an increase in both Core and Knots users.
But that's not what we see -- there is a very notable spike in node count since June 2025 and it is entirely due to new Knots users, or a sybil, or, more likely, both. So I do not assert that the growth is 100% due to a sybil, but even if only *some* of it is due to a sybil, then there *is* a sybil attack happening, which is precisely what my post is about.
I *am* opposed to spam
> What proof do you have it's a Sybil?
I don't have proof, I am conjecturing based on what I consider most plausible. In logic this is called "Inference to the best explanation."
> Couldn't it be bag holders highly motivated to start to run nodes?
That can partly explain it. But I would be very surprised if the spike was entirely due to *real* new node runners and 100% of them chose Knots over Core. A sybil attack seems more likely, especially when it's so easy to do.
I believe there are new node runners due to this drama. I think I have talked to some of them and I think their existence is good for bitcoin. But I don't think there are so many of them as to account for the spike we see in the charts. The same dynamics that produce more Knots users ought to produce fewer Core users, and we saw that early on, but since June it has largely stopped. The pattern on the charts can be *partly* attributed to new users choosing Knots, and I think that is great, but I think most of it it is likely attributable to someone spinning up fake Knots nodes without the ability to make the Core node count fall.
Allegedly, 19% of the bitcoin network is now running knots
However, I think I have detected evidence of a sybil attack designed to inflate the number of Knots users
I have annoted part of the "historical nodes" chart available at http://coin.dance/nodes/all
Based on this, I suspect the *real* percentage of Knots usage (subtracting probably sybils) is about 12.3% of the total network -- ~2,710 nodes out of 21,950 nodes.
Still a big deal, but not as big as the current numbers seem to suggest

They don't have *those* things in common but they have several other things in common
Robosats is not a p2p exchange
There is a clear middleman who plays the same role as a middleman like coinbase or binance
Underground does not equal p2p
A computer works with no contract, no time limit, no salary, no healthcare, no severance package, and does not complain or protest if summarily dismissed. It ceases to exist when no longer useful.
In short, blaming a human costs money, but blaming a computer is free. The killer app for ai might be pretending it makes all the tough decisions.
If you think about it, all submarine swaps are LN to on chain. Even when one party is going from on chain to LN, the other party is going from LN to on chain.
The problem I see with this design is that the server has to do L1 transaction + commit to locking funds up for possible time period without assurance from user that they will pay lightning invoice. I may be misunderstanding.
These problems could be mitigated with a fee that has to be played before the L1 transaction but I would like to hear your ideas for mitigation nostr:nprofile1qqszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagppemhxue69uhkummn9ekx7mp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsud80st
Thanks! Very interesting idea!
Yup, this is a general unsolved problem with submarine swaps: the party with the timelock path can be grieved by abandoning the swap after the name the L1 deposit. They lose atwo mining fees and make no money.
I think a fidelity bond paid via LN can help here. If you compete the swap, you trust the server to give you the bond money back. If you abandon the swap, the server keeps the bond money to reimburse their two mining fees.
In the future, instead of firing the ceo for bad decisions, when an ai appears to make bad decisions, the board will announce that they will upgrade it to fix the bug, or replace it with a different ai
A human does not want to be held accountable
Therefore a human will make a computer do management decisions 
It sounds like you like it! Consider writing your own version with this improvement implemented. And help me convince nostr:nprofile1qqsqcdcltmv4qanpx3p7svcufdsg9rkk00x7l2sknra4e6whkv59l7cpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtccpdmsw to implement this, or maybe write a real version and compete with them
The name Papa Swap comes from Papa Class, a group of Cold War submarines that included the world’s fastest declassified submarine – the Soviet K-222. As those are the fastest submarines, these are the fastest submarine swaps.
Not needing revealing the preimage is one theoretical advantage, but a bigger advantage is that the user gets full, unilateral control of the money after only 1 tx. They do not need to sweep it, as possession of the secret and a sighash_none sig from the server lets the user send the money wherever the user wants to.
The server, by contrast, is limited: he can only send the money into a traditional submarine swap address, which the user controls too, since the server has to wait 2 weeks to do anything, and the user does not, as the user knows the secret. So the user has full control of the money in the papa swap address in the same sense that a user fully controls their LN balance.
Also, in my implementation, the sig that lets the server move the money into a submarine swap address depends on the existence of a utxo that gets consumed when the user next sends or receives money. Once the user does that, the old sig becomes invalid, so the server cannot even move the money into a traditional submarine swap address.
Yes, a musig would be more efficient. I have never used musig in a demo except a demo of musig itself, because I find it hard to implement and not worth it for a proof of concept. A real implementation should probably use musig for greater efficiency.
The sig from the user is only valid for a tx that puts the money in a regular submarine swap address, so that's the only thing the server can do with the money, whereupon the user has 2 weeks to sweep it back (I use relative timelocks). So the "sad path" is that the server tries to sweep the money, has to wait, and the user recovers it using the secret. Moreover, in my demo implemention, the user's sig also depends on the existence of another utxo which gets spent whenever the user sends or receives money -- so the next time the user does that, the old sig becomes invalid, and the server can't use it.
What makes Papa Swaps interesting, imo, is this: traditional submarine swaps require 2 L1 transactions before the user has full control of the money; Papa Swaps reduce this to 1 L1 transaction. That means blockspace is economized by 50%, fees fall by 50%, and they are 100x faster
Link to repo: https://github.com/supertestnet/papa-swap
I made a chart that compares my new Papa Swap protocol with traditional Submarine Swaps. I also implemented the code in the form of a wallet that works like Muun Wallet, but using Papa Swaps. I plan to present my research and demo my code at Bitcoin++ Istanbul. See you there!

