What is your take on Bitcoin Knotz? Bitcoin node and wallet by Luke Dashjr

[Xun hu]

Strict mempool policy actually filters out a lot of spam transactions which makes running a node long-term a bit easier. i used to think Knots was just about enforcing Luke’s personal ideology but now I see it actually has some real practical benefits.

[ABCbits]

Because the main chain will always be the one with the most nodes to be executed. Because this is the one that miners want to follow in order to be able to maintain the current gains.

Ehhhhh... by tomorrow anyone with an amazon and google cloud account and a bit of money to blow could spin up more nodes than the current entire network following whatever rules they want.

Of course, with no user behind these nodes they're irrelevant, and nothing in bitcoin works by counting nodes.  So attackers don't bother (mostly, their are spies that run thousands of 'nodes'), but they easily could if it mattered.

It reminds me of this old post, https://www.reddit.com/r/bitcoinxt/comments/3iao3i/how_to_run_3000_completely_legit_full_nodes_aka/. This approach could be extended if each port assigned to different proxy IP address.

Strict mempool policy actually filters out a lot of spam transactions which makes running a node long-term a bit easier. i used to think Knots was just about enforcing Luke’s personal ideology but now I see it actually has some real practical benefits.

Do you mind telling us the real practical benefits?

[Xun hu]

Do you mind telling us the real practical benefits?

Oh i was just browsing and stumbled upon a page talking about Bitcoin Knots

something really caught my eye apparently anyone can control which transactions their node relays based on size or fee this seems super practical because it helps manage bandwidth, prevents your node from relaying spammy low-fee transactions and keeps everything running more smoothly. It’s a small tweak but I can see how it really makes running a node easier in the long run.

[ABCbits]

Do you mind telling us the real practical benefits?

Oh i was just browsing and stumbled upon a page talking about Bitcoin Knots

something really caught my eye apparently anyone can control which transactions their node relays based on size or fee this seems super practical because it helps manage bandwidth, prevents your node from relaying spammy low-fee transactions and keeps everything running more smoothly. It’s a small tweak but I can see how it really makes running a node easier in the long run.

1. FYI some control of TX relay also possible on Bitcoin Core. Check https://jlopp.github.io/bitcoin-core-config-generator/ and see "Transaction Relay" section.
2. If miner decide to include TX that deemed spam by you or Knots on their mined block, you can't avoid using some bandwidth and storage space.
3. If you bother to run full node (without putting major limit to internet usage), AFAIK the bandwidth difference would be very small that most people wouldn't notice.

[Xun hu]

1. FYI some control of TX relay also possible on Bitcoin Core. Check https://jlopp.github.io/bitcoin-core-config-generator/ and see "Transaction Relay" section.
2. If miner decide to include TX that deemed spam by you or Knots on their mined block, you can't avoid using some bandwidth and storage space.
3. If you bother to run full node (without putting major limit to internet usage), AFAIK the bandwidth difference would be very small that most people wouldn't notice.

Hmm thanks for breaking it down point by point
i went digging a bit after reading your reply

you’re right Bitcoin Core does have some relay controls. i checked the config generator and saw minrelaytxfee and limitfreerelay those can block low fee or free relay to some extent but it felt to me like Knots offers more granular options almost like a stricter mode compared to Core’s basic control.


That’s true if miners put it in their block i’ll have to download it no matter what no way around that. But from what i read Knots’ strict mempool policy helps at the relay stage by cutting down a lot of junk TX before they even reach my node. so bandwidth savings still exist even if block downloads can’t be avoided.

I kinda agree here too. for people running a node on unlimited broadband the difference might be too small to notice. But for folks on small VPS setups, capped data plans, or weaker connections, apparently it does make a difference. and during spam waves, strict relay policies actually help keep the node from choking too much so that part seemed pretty logical to me.

[d5000]

I don't disagree, but it's one of those things which is more vulnerable to Goodhart's law than most.  So it's kind of a heisen-hint.  It may give a hint at any point in time but as soon as someone starts looking at it or even advocating for it without looking then its value as a hint vanishes.

Yes, I agree here, and in fact I have seen a Reddit thread where a manipulation in favour of Knots was ongoing (with some people launching big Knots farms on VPS platforms ...). The manipulation attempt can even be seen at coin.dance in early September (some of the nodes seem to be offline again now), and after that event the numbers are more or less stagnating. These indicators / hints should be taken always with a grain of salt and never be used in the form of a "threshold" for any decision, but together they can give part of the picture, but probably only if you observe them for longer time periods.

For example, I think the current Knots increase is significant but its magnitude is still not really telling if there is real adoption by node owners not directly participating in the discussion. But if in 4-6 months the number of Knots nodes was still the same or higher, even if the discussion about OP_RETURN had already waned a bit, then it's a hint for real adoption. Often the manipulators want to impress with "explosive" short-term increases, so it is likely for them to run out of steam in a couple of months so the numbers become more credible again.

Edit: Another hint that at least part of the Knots growth is the result of manipulation is that while the number of Core nodes reduced a bit from 20.9k to 18.3k (-2500 nodes), Knots grew from ~800 to 4800 (+4000) between April and October (according to coin.dance). So we could assume that about 2500 new Knots nodes could indeed be people having changed from Core, and 1500 are new Knots nodes spawned from scratch, probably most of them "to make a statement" or "to manipulate". That confirms what I'm thinking: it's adoption is probably significant, but also exaggerated.

Strict mempool policy actually filters out a lot of spam transactions which makes running a node long-term a bit easier.

I wonder what you mean with the "long term" effect. The effect on incentives for NFT creators and similar "spammers"? Because this was already discussed here: the incentives could then switch to use protocols like Stampchain (already > 1.3 million NFTs were created with that method) which use fake public keys on the Bitcoin blockchain to store the data, and that would be even clutter the UTXO set more. As others have written, the resource usage of OP_RETURN based data transactions is much lower.

If your node policies differ much from miners' policies, then you would also be consuming more bandwidth because the compact block mechanism would be less effective.

[Satofan44]

E.g. with this, lots of knots advocacy but apparently eliminating datacenters from the figures drops a vast super-majority of the numbers (per reports, I haven't checked myself) and even what remain-- how many of them are guarding a users funds, were running a year ago or will be running a year from now?    This isn't a knock on knots users at this point but any kind of advocacy will probably scramble the usefulness of it as a hint.   This is particularly true because of how cheap throwing up a 'node' and not using it for anything is...  under normal times you'd expect a large portion of nodes to be "in use" (why run it otherwise),  but when there is a campaign? who knows.

It would be more interesting to track node user agent changes, but for that we need a centralized database that tracks nodes for a long time. For users with changing IP addresses and intermittent uptime it is difficult, but for long running nodes with static IP addresses it could be plausible. If a node on IP address X that has been running Bitcoin Core for 5 years has now changed to Bitcoin Knots that may say something. It also may say nothing. However, random nodes appearing and disappearing in large numbers definitely does not say anything.

Edit: Another hint that at least part of the Knots growth is the result of manipulation is that while the number of Core nodes reduced a bit from 20.9k to 18.3k (-2500 nodes), Knots grew from ~800 to 4800 (+4000) between April and October (according to coin.dance). So we could assume that about 2500 new Knots nodes could indeed be people having changed from Core, and 1500 are new Knots nodes spawned from scratch, probably most of them "to make a statement" or "to manipulate". That confirms what I'm thinking: it's adoption is probably significant, but also exaggerated.

This is exactly what would be worthwhile to track. These nodes can be categorized by age, and the older they are the more "significant" a change would be. I doubt someone has been consistently running many fake nodes on the same IP addresses for a very long time such as 5 to 10 years.

[stwenhao]

OpenTimestamps

They could tweak R-values inside signatures, and become "HiddenTimestamps". Then, it will be impossible to know, how many of them exist in practice, it will be harder to censor them, they would be cheaper, and they wouldn't need any OP_RETURN. I think new systems shouldn't be based on OpenTimestamps, but use more advanced tricks like that. Because OpenTimestamps need just 256-bit value, no matter what message is confirmed. And they could achieve that, without any OP_RETURN, because each and every signature uses 256-bit R-value, that can also commit to any data, if needed.

If a node on IP address X that has been running Bitcoin Core for 5 years has now changed to Bitcoin Knots that may say something.

Changing User Agent is easy, and can be done on-the-fly:

Code:

  -uacomment=<cmt>
       Append comment to the user agent string

Example commands:

Code:

./Bitcoin-Qt -uacomment="Foobar Node v1.2.3" -noconnect
./Bitcoin-Qt -uacomment="Foobar Node v1.2.3" -noconnect -choosedatadir

Example results:

Code:

getnetworkinfo
{
  "version": 280000,
  "subversion": "/Satoshi:28.0.0(Foobar Node v1.2.3)/",
  "protocolversion": 70016,
  "localservices": "0000000000000c09",
  "localservicesnames": [
    "NETWORK",
    "WITNESS",
    "NETWORK_LIMITED",
    "P2P_V2"
  ],
  "localrelay": true,
  ...
}
...
getnetworkinfo
{
  "version": 280100,
  "subversion": "/Satoshi:28.1.0(Foobar Node v1.2.3)/Knots:20250305/",
  "protocolversion": 70016,
  "localservices": "0000000004000c0c",
  "localservicesnames": [
    "BLOOM",
    "WITNESS",
    "NETWORK_LIMITED",
    "P2P_V2",
    "REPLACE_BY_FEE?"
  ],
  "localrelay": true,
  ...
}

It is trivial to change "uacomment" in the source code, and pretend, that you are running Knots, even if you are not. As long as nodes don't accept proofs, that a given code is executed, it is just all about meaningless statistics. It is as reliable, as checking transaction locktime, and guessing, when it was created, based on that. In many cases, users are lazy, and when a lot of people run default settings, it is reliable, but it can be faked, if any decisions would be based on these things.

So, I expect some users really switched to Knots, but I also suspect there is some artificial traffic, just to support Core or Knots, and there are fake nodes, which only advertise a given User Agent, to fight in "stats wars", and see, how charts with client popularity can change, and show their team winning or losing.

I doubt someone has been consistently running many fake nodes on the same IP addresses for a very long time such as 5 to 10 years.

To advertize any User Agent, you don't have to run any node. You can always say to the network: "I have all blocks and transactions". And then, you can store absolutely nothing, and just act as a proxy to other, real nodes. Then, it is much cheaper to run a node, but it puts more pressure on real node operators.

[kano]

Well I think it's more than that... Luke-jr-- already long since burned out on Bitcoin-- lost his coins due to being hacked and his only recovery plan was to start a mining pool company, so he was thrust back in against his own desires.  He created it at the height of the first ordinals and BRC20 floods,  when that trash traffic was being a particularity nuisance.   Spam became a big part of their message and reason for existence.   But as most predicted, fees eventually depleted that traffic and while it still exists it's not a big deal now, not something most bitcoin users were particularly concerned about anymore.

Luke-jr's fixation on meddling with other peoples transactions isn't new ...

Wait - are you saying he blew all the 28000 BTC he had, before that hack?
Seriously?

I looked at this 'apparent' 200 BTC loss as a:
'well whatever, he still has thousands of BTC more, not sure what the problem is other than he clearly did something stupid - which isn't all that unexpected coz he really isn't that smart ...'
... and I make that statement from having to deal with him directly for a while back in the early days.
Him having McDonalds on his cv also says a lot

[Satofan44]

If a node on IP address X that has been running Bitcoin Core for 5 years has now changed to Bitcoin Knots that may say something.

Changing User Agent is easy, and can be done on-the-fly:

I am aware of this. In the context in which we are talking about it does not really matter that much whether someone is really running Knots or simply signalling support for it. In both cases it gives the intent of showing support for Knots, albeit more strongly in the first one.

It is trivial to change "uacomment" in the source code, and pretend, that you are running Knots, even if you are not. As long as nodes don't accept proofs, that a given code is executed, it is just all about meaningless statistics. It is as reliable, as checking transaction locktime, and guessing, when it was created, based on that. In many cases, users are lazy, and when a lot of people run default settings, it is reliable, but it can be faked,

For security and protocol things it matters whether someone is really running Knots or not, but for showing support not as much. It is merely a difference in the degree of support, but it gives you the overall idea in each case.

if any decisions would be based on these things.

No decisions should be taken solely based on such data in any case. It is merely a decent way to show you the sentiment of the situation. If my long running node switches to Knots, it tells you that for whatever reason I am either disapproving of Core's behavior, approving of Knots' behavior or both. The solution does not have to be bulletproof, we are not trying to create a fake decentralized governance system here like most altcoins have. 

[bitmover]

NFT/shitcoin/etc. traffic is lame, but it's clear that its usually fairly well managed by transaction fees through the market for block capacity.  The occasional flare ups and residual traffic are annoying but are the costs of an open system which we should all gladly accept because the alternative is a "bitcoin" that has little reason to exist.

I didn't know about this. Thanks for sharing

this is absolutely insane:

Instead, he proposes the implementation of a multisig quorum on Bitcoin that grants a designated group of people the ability to retroactively alter data that is hosted on the blockchain.

By Dashjr’s description, the trusted multisig committee would review transactions and replace any data it identifies as CSAM with a zero-knowledge proof. Node operators could then remove said data from their nodes – altering their version of the blockchain – while continuing to be able to prove that the transaction that contained the affected data is valid.
https://www.therage.co/leaked-luke-dashjr-bitcoin-hardfork/

I am impressed how a bitcoin developer is proposing something like that. This is against everything bitcoin stands for, and would make bitcoin completely centralized.

This would be just some useless fork like BCH, which just hurts the entire ecosystem.

Well I think it's more than that... Luke-jr-- already long since burned out on Bitcoin-- lost his coins due to being hacked and his only recovery plan was to start a mining pool company, so he was thrust back in against his own desires. -snip-

I think this might explains a lot of stuff

[Wind_FURY]

Well I think it's more than that... Luke-jr-- already long since burned out on Bitcoin-- lost his coins due to being hacked and his only recovery plan was to start a mining pool company, so he was thrust back in against his own desires.  He created it at the height of the first ordinals and BRC20 floods,  when that trash traffic was being a particularity nuisance.   Spam became a big part of their message and reason for existence.   But as most predicted, fees eventually depleted that traffic and while it still exists it's not a big deal now, not something most bitcoin users were particularly concerned about anymore.

Luke-jr's fixation on meddling with other peoples transactions isn't new ...

Wait - are you saying he blew all the 28000 BTC he had, before that hack?
Seriously?

[b{I looked at this 'apparent' 200 BTC loss as a:
'well whatever, he still has thousands of BTC more[/b], not sure what the problem is other than he clearly did something stupid - which isn't all that unexpected coz he really isn't that smart ...'
... and I make that statement from having to deal with him directly for a while back in the early days.
Him having McDonalds on his cv also says a lot

It's probably not a "whatever" sort of loss. He called the FBI to investigate the matter. That's not "whatever I have tens of thousands more Bitcoin".

Plus it's also said that since the hack, Luke Dash Jr. has been recording conversations/interactions that he has been having in conferences.

  👀

[gmaxwell]

Wait - are you saying he blew all the 28000 BTC he had, before that hack?

He said and I believe that it was essentially all of the Bitcoin he had and the vast majority of his assets that was taken.  It left him in the position of needed to find a source of income thus 'restarting eligius'.  But then he immediately went and screwed up it with filtering politics crap.

[apogio]

Does this mean the release for v30 is going to be delayed for some days (or weeks)?

https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3370962466

Since the rc3 has been tagged today, I guess it will take more than a week to tag the final version, or I am completely ignoring how the release schedule works, so if anyone knows, please enlighten me.

There is no secret meaning in my post, I don’t mean the delay is because of the beef that has started, even though it’s obvious I am in favour of Bitcoin Core, personally!

[Wind_FURY]

Does this mean the release for v30 is going to be delayed for some days (or weeks)?

https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3370962466

Since the rc3 has been tagged today, I guess it will take more than a week to tag the final version, or I am completely ignoring how the release schedule works, so if anyone knows, please enlighten me.

There is no secret meaning in my post, I don’t mean the delay is because of the beef that has started[/ ], even though it’s obvious I am in favour of Bitcoin Core, personally!

If there are delays, then that's definitely because of the filtering politics crap that probably some people are spreading/enjoying just to keep the FUD from dying. It's also a "filtering" as protest. Protest against what? Dick pics and fart sounds onchain?

 ¯\_(ツ)_/¯

If the filter boys are very serious about a hard fork, then they should do it as soon as possible, then let the community/market decide.

[Satofan44]

Does this mean the release for v30 is going to be delayed for some days (or weeks)?

No. Where did you get that idea from?

https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3370962466

Since the rc3 has been tagged today, I guess it will take more than a week to tag the final version, or I am completely ignoring how the release schedule works, so if anyone knows, please enlighten me.

After a RC has been tagged it undergoes another round of testing. If there are no significant issues usually within a week or possibly two, then that candidate is the final one. The exact length is not predictable because of this. Some past versions needed fewer RCs than others.

If there are delays, then that's definitely because of the filtering politics crap that probably some people are spreading/enjoying just to keep the FUD from dying. It's also a "filtering" as protest. Protest against what? Dick pics and fart sounds onchain?

 ¯\_(ツ)_/¯

If the filter boys are very serious about a hard fork, then they should do it as soon as possible, then let the community/market decide.

No more than a few "filter boys" want a hard fork. Most of them are serious maxis.

[apogio]

If the filter boys are very serious about a hard fork, then they should do it as soon as possible, then let the community/market decide.

No more than a few "filter boys" want a hard fork. Most of them are serious maxis.

I agree with Satofan44. A hard fork will make it more difficult for them to whine against Bitcoin Core. They'll have a completely different route, whereas now they've simply added some policy adjustments without really messing with the bitcoin's core concesus rules. They have the excuse now, but if they create another hard fork, they'll be completely unattended and left unable to react to Luke's will.

[gmaxwell]

That’s true if miners put it in their block i’ll have to download it no matter what no way around that. But from what i read Knots’ strict mempool policy helps at the relay stage by cutting down a lot of junk TX before they even reach my node. so bandwidth savings still exist even if block downloads can’t be avoided.

I kinda agree here too. for people running a node on unlimited broadband the difference might be too small to notice. But for folks on small VPS setups, capped data plans, or weaker connections, apparently it does make a difference. and during spam waves, strict relay policies actually help keep the node from choking too much so that part seemed pretty logical to me.

I missed this earlier.

It doesn't save you bandwidth.  When a block is found the transactions you already know aren't sent again unless you are missing way too many transactions.  So when your peers deny you knoweldge of a transaction that will eventually get mined you don't save bandwidth.  You may also waste bandwidth when peers do offer it to you and you request it only to rejected it and discard it multiple times.  Since it won't save and can increase the net effect is an increase.

Worse, any time there is a missed transaction in block relay a whole round trip is required which triples (or worse) the amount of time it takes to relay a block plus the added time needed to validate the new transactions (which otherwise would have been already validated).  So it makes your node much less of a contribution to the propagation of new blocks.

If you are really bandwidth constrained and don't care about having a mempool that accurately reflects what is going to get mined (e.g. speeding up block prop or estimating fees) then you can just run blocksonly-- which actually will reduce your bandwidth somewhat as txn will only ever get transferred once when they're mined without any inv overheads.

[ManeIntro]

I see Luke jr is still active in both bitcoin core and bitcoinknots github.

If core devs stop developing because nobody uses their software anymore what would Luke do[/quote]

[Wind_FURY]

If the filter boys are very serious about a hard fork, then they should do it as soon as possible, then let the community/market decide.

No more than a few "filter boys" want a hard fork. Most of them are serious maxis.

I agree with Satofan44. A hard fork will make it more difficult for them to whine against Bitcoin Core. They'll have a completely different route, whereas now they've simply added some policy adjustments without really messing with the bitcoin's core concesus rules. They have the excuse now, but if they create another hard fork, they'll be completely unattended and left unable to react to Luke's will.

Laughable to believe that they don't want a hard fork because "most of them are serious maxis". NO - they won't hard fork because the users, the economic majority, and the miners will follow the Core Developers and leave the filter boys with a shitcoin in their hands.

This drama/debate will not last long from now because soon the users will truly understand the issue, AND will truly understand that filtering is not only useless, it hurts network efficiency as well.