It looks to me like there are at least two contributors to Knots: Luke and Retroplex. I am hoping to find at least 13 more. nostr:nevent1qqsdx7np8y4hnc5nne9du23v4y25edky4gr6xvznadsq06zyhqd966spr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagrqsqqqqqpghe4vy

That does not seem to be true for the reasons I outline in this post: nostr:nevent1qqsdx7np8y4hnc5nne9du23v4y25edky4gr6xvznadsq06zyhqd966spr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagrqsqqqqqpghe4vy

It does not seem to be true. The Knots github lists someone called Retroplex as a contributor other than Luke. It also lists other usernames as code authors, but so far the other ones I've looked at apparently wrote it for Core and then Luke copied their code to Knots too. That's worth something, but in my book it does not count as an intentional Knots contributor unless they looked at Knots while writing it and intended to get it into that codebase.

Retroplex seems to fit that description, which means it is not "just" Luke. I am hoping to find at least 13 additional contributors in the sense which I describe in this post -- that is, people who write code while intentionally thinking about how it would work in Knots and working with Knots to be sure their code will work as intended there.

I found one, a dev with the github username Retroplex contributes to Knots. Can you name any others besides him and Luke?

There is a meme going around that Luke Dashjr is the only maintainer of Bitcoin Knots. This seems implausible to me with all the attention Knots has gotten lately.

Can anyone point to anyone else who works on it? Or step up and say "Luke is not alone, I work on Knots too"?

I don't know much about rugby but I doubt it involves many rugs

indeed, this post is just trolling, it is not serious

1. I don't like handegg (American football)

2. But not because it uses an egg-shaped ball, that's a perfectly reasonable ball shape for this sport, as it has a lot of forward passes, and an egg-shaped ball makes those look cooler

3. The fact that American football (handegg) is a sucky sport is no reason to call soccer football

Since my points did not get much cross-examination in this interview, I also recommend the more recent debate between myself and Bawdy Anarchist, which you can catch here: https://x.com/LayerTwoLabs/status/1945125912191598772 -- listen to both sides and make your own judgments!

It still is called soccer in most of the native-english-speaking world

Australia: soccer

Canada: soccer

USA: soccer

England calls it football, but as I pointed out, that's a poor name for it

America got rich and was suddenly like "wow, you can just do things"

To my non-American friends:

The sport "football" (your version) is misnamed. Unless you play barefoot, your foot never touches the ball. Your *shoes* and *socks* touch it though. Consider renaming it "shoe-and-sock-ball" -- or just "soccer" for short.

Context: this meme

You are ahead of the game, sir! I just got the Send function to work today, and I haven't even coded up a user interface or finished the test suite. I plan to present this new protocol in September at BTC++ in Istanbul. Hopefully the demo client will be ready by then.

I am trying to convince the fine folks at nostr:nprofile1qqsqcdcltmv4qanpx3p7svcufdsg9rkk00x7l2sknra4e6whkv59l7clgcdzj to implement this protocol. They expressed very little interest, but not zero interest. Now that my codebase works, maybe they will take a look and see if they agree with me that this new protocol can slash their costs in half.

layered security is wise. I wrote the above post to highlight that the privacy assumptions at the heart of much of monero's technology (and LN's too) involves trust. I don't think it's possible to completely remove trust, but you can always reduce the trust assumptions, and make things easier for end users.

In many ways I think LN does a better job of this than monero, for example, self-custodial LN wallets -- except Phoenix and Electrum -- use source routing, even on cell phones, and source routing has similar ip-hiding properties as dandelion. But monero wallets, at least on cell phones, don't even *try* to do dandelion. So a typical self-custodial LN wallet is superior to a typical self-custodial monero wallet in this respect.

I don't think LN privacy is "universal and trustless." I just think it's better than monero.

On a related note: with monero, the sender has several options to hide his ip address:

- he can use dandelion to hide it, but that requires trusting the stem nodes not to reveal it

- he can use an rpc connection to hide it, but that requires trusting the rpc node not to reveal it

- he can use a vpn to hide it, but that requires trusting the vpn not to reveal it

- he can use tor to hide it, but that requires trusting his tor relays not to reveal it

Trustlessness is very hard and I don't think either LN or XMR achieves it. Most monero users probably use the second option, an rpc connection, and that is very trusting.

I tried but (1) the numbers I got were probably many miles off the true value, due to incorrect assumptions (2) the code to generate the (bad) data worked in browsers, but only because I used a proxy to get around CORS restrictions, and the proxy I used started blocking my requests, so the code basically no longer gives *any* data -- not even *bad* data. But the repo is here: https://github.com/supertestnet/mint_marketcap

yes, I was talking to someone who claimed that nostr can be censored by ICANN because nostr relays "must" (according to him) have an ICANN-registered domain name, and when a device tries to look up the corresponding IP address, ICANN may simply refuse to say what it is. I told him that relays don't need a domain name, they work fine with a raw ip address, so he asked me to prove it, which is why I did so.

And it really is a cool feature of nostr, imo. It would be neat to see a client designed with the assumption that relays are just random ip addresses, shared with followers via nprofile strings, such that the only time a user interacts with them directly is if they are replacing one that goes down.

I mentioned that an ISP can censor an ip address in their range. It sounds like black-hole-ing is a form of that. Thankfully, at least right now, it's easy to get around such censorship by renting a different ip address, since there are many ip address providers who do not require identity info. But I imagine it is difficult in some countries to rent an ip address without KYC, and if it becomes difficult worldwide, that will suck pretty badly.

I don't know what that term refers to. Do you have a link?

As I understand it, ICANN gives each ISP a range of ip addresses, and they do two things with them: (1) they assign each one to a customer, who effectively rents it (2) they maintain an internal database of which customer rents which ip address.

Suppose Alice uses ISP A and Bob uses ISP B. If Alice wants to send a message to Bob, she sends a query to her own ISP -- ISP A -- containing Bob's ip address. ISP A looks at the first part of the ip address, which identifies ISP B, so ISP A forwards the query to ISP B through wires, radio waves, or both.

Once ISP B has the message, they use their internal database to look up which of their customers rents that IP address to, and forward the message to them in a similar manner (wires, radio waves, or both).

Due to this structure, ICANN cannot block a particular ip address, because ISPs don't query ICANN when resolving a particular ip address. They just look up what range it is in and then forward it to the ISP responsible for that range.

An ISP *could* block a particular IP address, however, by just refusing to provide further service to whatever customer rents that ip address. Thankfully, at least at the present time, it is easy to rent an IP address without KYC, so ISPs do not have identity information on all of their users, making it hard to censor them in this manner. An ISP might block a particular IP address, but you can easily just rent another one, even from the same provider, because they don't have your identity info.

what is noise?

Here's a screenshot of me interacting with an unregistered nostr relay. In the pic, I send it an event and retrieve that event from it.

Proof that nostr works fine without DNS or icann. Stick an unregistered relay in your nprofile and boom: social networking with no DNS.