Update on LinkingLion: Reduced activity and a statement by LionLink Networks

Happy Birthday, LinkingLion!
Thursday, March 28, 2024

This is an update on the LinkingLion entity, presumably linking Bitcoin transactions to IP addresses, I published about a year ago. Yesterday, LionLink Networks AS issued a statement on their non-affiliation with the LinkingLion entity and on the same day, LinkingLion activity significantly dropped.


Exactly a year ago, I published about LinkingLion, an entity that’s presumably linking transactions to IP addresses. The entity has been opening hundreds of connections per minute to my monitoring nodes for the last year.

On March 27, 2024, LionLink Networks AS, who are announcing the IP addresses ranges used by the entity, published a statement on LinkingLion.net. In the statement, the LionLink Networks AS denies any involvement with the LinkingLion entity other than announcing the IP addresses ranges. I have no reason to believe that the AS is involved with LinkingLion entity other being the common factor in announcing the IP addresses used by the LinkingLion entity. I understand that the play on words “LinkingLion”, being a combination of LionLink (the AS that announces IP addresses used by LinkingLion), “Linking” as in linking IP addresses to Bitcoin transactions, and Dandelion as privacy protocol helping against transaction linkage of transactions to IP addresses, is, from a public relations standpoint, unfortunately close to their company name.

To clarify, I don’t think the LionLink Networks AS is the LinkingLion entity.

Coincidentally, I’m happy to report that since yesterday (about 2024-03-27 3pm UTC), I’m not receiving connections from two of the three IPv4 ranges anymore, and I am seeing reduced numbers of connections from the third IPv4 range. I currently don’t have data on the IPv6 range at hand. Maybe the LinkingLion entity is switching IP ranges or adapting their strategy or software? Or it’s just a network degradation or outage with coincidental timing?

  • 209.222.252.0/24: no new connections
  • 91.198.115.0/24: no new connections
  • 162.218.65.0/24: reduced connections to ~100/min with previously about 200/min - 400/min
  • 2604:d500::/32: no data
Total new connections from LinkingLion per minute per /24 subnets on 2024-03-27
Total new connections from LinkingLion per minute per /24 subnets on 2024-03-27

On the Bitcoin Core side, there’s work being done by vasild and reviewers to broadcast transactions via short-lived Tor or I2P connections, when possible. This should help against entities like LinkingLion. I personally haven’t been able to take a detailed look at this proposal.

Update 2024-03-29

LinkingLion is opening connections again.

Total new connections from LinkingLion per minute per /24 subnets on 2024-03-29
Total new connections from LinkingLion per minute per /24 subnets on 2024-03-29

OpenSats supports Vasil, myself, and others with a Long-Term-Support grant to work Bitcoin Core and monitoring like these. Consider donating to OpenSats if this is work you find worth supporting. Additionally, the MIT DCI is providing me with server infrastructure that I use to monitor for P2P anomalies and attacks, like, for example, the behavior by the LinkingLion entity.

All text and images in this work are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License Creative Commons License

Next

Image for Mining Pool Behavior during Forks

July 15, 2024

Mining Pool Behavior during Forks

I have recently been looking at mining pool behavior during forks. Which block does a pool choose to mine on during a fork? Do they behave rationally and mine on their own block? In this post, I’ll detail the mining pool behavior during forks and give some recent examples of pool behavior.

Previous

Image for Vulnerability Disclosure: Wasting ViaBTC's 60 EH/s hashrate by sending a P2P message

March 20, 2024

Vulnerability Disclosure: Wasting ViaBTC's 60 EH/s hashrate by sending a P2P message

In January, while investigating a misbehaving client on the Bitcoin P2P network, I found a vulnerability in ViaBTC’s, the fourth largest Bitcoin mining pool, SPV mining code that allowed a remote attacker to waste ViaBTC’s 60 EH/s hashrate by sending a single, crafted Bitcoin P2P message. I responsibly disclosed this to ViaBTC, and they awarded a bug bounty of 2000 USDT.