Yes, which was released in 0.21 on January 14th, 2021.

https://bitcoincore.org/en/releases/0.21.0/

Search for #19988 in the list at the end.

Sometimes changes are written years before they make it into a release.


The "and" in which sentence?

There is no constant two second delay.  When a peer offers you a transaction if the peer was one you connected out to and you haven't already requested the transaction from someone else you will instantly request it.  If the peer is a peer connecting in to you, you will remember that and start a two second timer. During the timer you will immediately request the txn if a peers you are connecting out to offers it, and if other inbound peers offer it you will remember their offers.  After the two second timer expires, if any peer you are connecting out to has still not offered the the transaction you will randomly select one of the available offers and request the transaction, this fairly seldom happens. There are additional penalties for peers that you have many txn requests already outstanding.  The average effect is just that transactions get requested in a preferred direction across links (because every link has an inbound and an outbound side) without changing the delay much, but it substantially blocks tarpitting attackers since they depend on connecting many times to a target and triggering request timeouts.

Preferred status is set *automatically* by the node. It can also be set as a side effect of the noban permission.  I was attempting to discover if your complaint is about the automatic behavior, which is an important protection against attack, or if your complaint is about the fact that it's also a side effect of noban.  I still don't know, because you seem to just be ignoring that it's also set automatically.

The latter isn't important, except that some tests use noban to eliminate delays that otherwise get in the way of performing some tests. It's not even a documented behavior and could probably just go away except for whatever tests are depending on it.

Anyone could turn off the behavior generally on their own node, but doing so will just reintroduce the tarpitting attack vulnerability (see section 5.3) and reduce their privacy.

It seems to me that ratholed yourself on some extremely minor, relatively newly introduced behavior, that has fairly little effect on transaction propagation overall (except against tarpitting attackers), particular since it's just a control for which peers out of multiple offers you'll request a transaction from. ... and you're continually ignoring that the your fundamental premise that users are somehow disadvantaged by small differences in transaction relay is just false as many people have pointed out.

That it applies to peers automatically.

It's unclear to me what you're asking.

Is your complaint that the 'no ban' whitelist option bypasses some delays? You'd have to figure out how to fix the functional tests that need to bypass the delays for their testing purposes-- which is pretty much why it's there AFAIK.  But who cares if I'd accept it? I am already not whitelisting any peers so it would make no difference.  Outside of testing the whitelist stuff is hardly used, and doesn't generate reports even when it's been broken in various ways.

Or is your complaint just that the transaction download manager treats some peers differently, without any configuration?  That is an important protection against denial of service and for user privacy, and it shouldn't be removed-- and the only reason I could see someone wanting to remove it is if they were a malicious party.

Where is the rest of your response?  We're all still waiting to hear why you believe some disadvantage is created for some user somewhere and why you're obsessed about code that sometimes delays the speed at which you _request_ transactions (vs the speed people offer them) which was released just a couple months ago.

Because it wouldn't benefit them, it would just waste their bandwidth and cause other participants to banlist them due to wasting their bandwidth.

You misunderstand the Bitcoin protocol then.  The protocol is almost completely symmetrical, inbound and outbound connections work the same.  Most of the software doesn't even know which side a connection was initiated from.

To the small extent that they receive different service, nodes de-prefer connections coming into them because they may be attacker chosen, while they choose their own outbound connections.  So your node would receive slightly less preference from its peers if it made mostly outbound instead of mostly inbound connections.

Someone accepting connections doesn't have *anything* to do with running a full node or not.  People run full nodes because running a full node protects their interest by enforcing the rules of Bitcoin for them.

Users listen to provide a service to the network, so that the network can exist (which is good for their interests if they use Bitcoin) and it's relatively cheap to do so. They also directly get the potential for more reliable connectivity, because if they accept connections they can also be directly linked to other nodes which only make outbound connections.


No, most full nodes are not on hosting providers, most *listening* nodes are because hosting providers are not behind NAT and Bitcoin has no nat hole punching by default currently.

This doesn't make any sense. What access flag? Why would it be 'damning', and what does that have to do with full nodes at all?  Anyone can run a full node.

Bitcoin would run fine if kicked off AWS and GCS.  There would be short term congestion for inbound ports which we've had before, long ago, where sometimes nodes would take a while to get connected after restarting while users adapted by increasing their maximum inbound connection count and punching holes through their NATs.


Yes, because they're not NATTed.  They're also popular with spies.  Some people ban connections to/from AWS/GCS/DO/Linnode completely on their nodes.


They don't increase it (I'm sure someone somewhere has done so, but it's very rare... I have very seldom observed a mass connector behind NAT, when they want lots of connections they want inbounds too).   There is no big improvement with increasing your number of outbound connections, it mostly just wastes your bandwidth.

As I explained above, that has absolutely nothing to any of the whitelisting settings, preferred nodes are random peers selected by the software, and not something users can configure.  It doesn't apply to all requests but only some peers, it there because it protects nodes against a tarpitting dos attack where malicious peers offer it transactions but don't reply when they're requested.  It also helps protect nodes privacy by making it less clear to peers if a node already had a transaction which they offered to it.

That particular code wasn't even added until 0.21, which was only release four and a half months ago.

There isn't any whitelisting there the transaction download manager's preferences are its own, your fixation on conspiracy theories appears to be clouding your judgement.

As many people have pointed out here, there is generally no benefit to small differences in transaction relay speed for network participants.  Continually making arguments that only make sense if there were one doesn't cause there to be one, it just makes you look a bit unhinged.

NAT.  For quite a few years Bitcoin hasn't had any automatic hole punching by default, after it got turned off due to repeated vulnerabilities in the standard UPNP library (and the upnp code was determined to be too dubious to keep risking it).

That will likely change somewhat in the next major release as it adds NAT-PMP support (nat-pmp doesn't require a @#$@ XML parser). PMP isn't as widely supported by routers as UPNP, however.

It's also the case that users get some security and privacy advantages in being not connectable, so even when nat isn't an issue some users choose to disable inbound connections, but it's mostly due to the lack of by-default portmapping.

There are a *lot* more than 10k nodes, a good estimate is about 64k nodes.  Most nodes don't accept inbound connections, so the only way you know they are there is when they connect to you.  That means 64k nodes connecting out to 9k or so listeners.  Connections aren't made uniformly either... if you are on a network block with few nodes you'll get more than your fair share (and fewer than if you are on a network with many nodes). There are also a few mass connectors, including "forked.net" which may be making 10-15 connections to you from a single /23, if you don't have them banned.  It's typical to lose 15-20 connections when you apply a banlist.

I'm not super active in moderating there-- I process reports when they come in, but these days I'm not an active enough reader to be highly effective.  It would be useful to have an additional moderator who is active in the subforum.

I don't feel overloaded by report volume, -- though there are a lot of scamcoin mining posts-- but it's always good to have moderators that are regularly reading most of the threads in their subforums and currently I am not.

Indeed. Obtaining 81920 IPs will not allow you to replace all the entries in the table, that itsn't how it works.

In what sense? Node availability changes very slowly.



This isn't meaningful. Bitcoin transactions just move bitcoin, they don't establish prices in any markets.  You're hand waving.



Your post was full of errors wrong, from top to bottom.  But, as I mentioned-- Bitcoin intentionally doesn't relay transactions as fast as possible, and for intentional and good reasons.

Here you're still mistaken.  Wallets originate transactions, they don't pay any attention to transactions other than ones paying them.  A user is not disadvantaged by learning that a payment was made a few seconds later, and if the user cares to know that information they can have the payer tell them directly, which is much faster.


Simply asserting it doesn't make it true.  You seem to think that Bitcoin transactions are spot market trades which offer or establish some price. They are not and do not.  Trades in the spot markets don't require any bitcoin transactions, because they use funds which are in confirmed deposits in exchanges.  Funds which just moved *cannot* be traded, typically not until after 3 or 6 blocks have passed.  Nothing in a bitcoin transaction establishes a price or even indicates an intent to trade.

Moreover, to whatever limited extent that a user might be disadvantaged or traded against based on their transaction -- protecting their privacy is important, which is the primary purpose of relay delays in the first place.

The 'preferred' term doesn't even have anything to do with the noban setting, and it cannot be configured to apply to particular peers.

The 'preferred' term you're discussing comes from heuristics used in selecting which of multiple offering peers to request a transaction from to avoid tar-pitting attacks. A peer could offer you a transaction and then fail to transmit it when you request it, leaving you to wait until the requests times out.  To avoid this, the node will prefer to fetch from a well behaved peer which is less likely to attack.  If the first peer to offer the transaction wasn't one of these preferred peers it will wait up to a small timeout for a preferred peer to offer the transaction, and if the timeout is reached it will pick a source at random from the offering parties.


You could start by reading the PR that introduced the whitelisting a number of years ago...
or simply look at the test suite in bitcoin/test/function where it's used by 18 different tests.


Many people run their own automation to detect abusive nodes (mass connecting spies, dos attackers, and other resource wasters) and banlist them, there is no coordination in that case.

Some people run that automation and publish lists on the internet which other people can adopt if they want.

If you have the bench debug group enabled it's really easy to grep for blocks with just 1 transaction.

grep 'transactions:' debug.log | cut -d':' -f1-3 | grep -B 1 ' 1 trans'

What you find is that they all came very close to the prior block:


2021-05-05T19:38:25.972767Z       - Connect 2809 transactions
2021-05-05T19:38:34.570897Z       - Connect 1 transactions
--
2021-05-06T01:41:17.380671Z       - Connect 1819 transactions
2021-05-06T01:41:18.663782Z       - Connect 1 transactions
--
2021-05-07T07:51:09.129202Z       - Connect 1012 transactions
2021-05-07T07:51:14.330562Z       - Connect 1 transactions
--
2021-05-07T19:48:50.111346Z       - Connect 2083 transactions
2021-05-07T19:48:53.097904Z       - Connect 1 transactions
--
2021-05-07T22:45:39.073813Z       - Connect 1590 transactions
2021-05-07T22:45:47.849924Z       - Connect 1 transactions
--
2021-05-09T11:03:47.903862Z       - Connect 137 transactions
2021-05-09T11:03:49.012120Z       - Connect 1 transactions
--
2021-05-09T15:08:38.912208Z       - Connect 836 transactions
2021-05-09T15:08:50.059076Z       - Connect 1 transactions
--
2021-05-09T15:29:45.090009Z       - Connect 1022 transactions
2021-05-09T15:29:51.787654Z       - Connect 1 transactions
--
2021-05-11T04:24:42.477370Z       - Connect 1265 transactions
2021-05-11T04:24:43.989771Z       - Connect 1 transactions
--
2021-05-11T06:45:07.349646Z       - Connect 1894 transactions
2021-05-11T06:45:08.451109Z       - Connect 1 transactions
--
2021-05-12T12:54:19.522383Z       - Connect 2698 transactions
2021-05-12T12:54:23.530026Z       - Connect 1 transactions
--
2021-05-13T05:45:32.793978Z       - Connect 1378 transactions
2021-05-13T05:45:33.117047Z       - Connect 1 transactions
--
2021-05-13T22:38:09.974322Z       - Connect 1012 transactions
2021-05-13T22:38:11.649618Z       - Connect 1 transactions
--
2021-05-14T23:23:24.842750Z       - Connect 1964 transactions
2021-05-14T23:23:47.495929Z       - Connect 1 transactions
--
2021-05-18T17:47:19.628403Z       - Connect 3164 transactions
2021-05-18T17:49:39.760471Z       - Connect 1 transactions
--
2021-05-19T17:31:36.584356Z       - Connect 2231 transactions
2021-05-19T17:31:37.058632Z       - Connect 1 transactions
--
2021-05-22T10:36:24.375540Z       - Connect 1708 transactions
2021-05-22T10:36:27.893624Z       - Connect 1 transactions
--
2021-05-22T22:19:00.620185Z       - Connect 1623 transactions
2021-05-22T22:19:16.254926Z       - Connect 1 transactions
--
2021-05-23T07:32:16.229073Z       - Connect 357 transactions
2021-05-23T07:32:19.123820Z       - Connect 1 transactions
--
2021-05-23T09:58:10.283078Z       - Connect 2490 transactions
2021-05-23T09:58:11.571934Z       - Connect 1 transactions
--
2021-05-27T02:07:09.620112Z       - Connect 2145 transactions
2021-05-27T02:07:18.611398Z       - Connect 1 transactions
--
2021-05-28T01:37:24.493782Z       - Connect 2135 transactions
2021-05-28T01:37:26.807828Z       - Connect 1 transactions
--
2021-05-29T15:53:09.574103Z       - Connect 196 transactions
2021-05-29T15:53:20.028246Z       - Connect 1 transactions
--
2021-05-29T22:00:58.635862Z       - Connect 3170 transactions
2021-05-29T22:01:01.087364Z       - Connect 1 transactions
--
2021-05-30T03:13:14.704155Z       - Connect 417 transactions
2021-05-30T03:13:22.371535Z       - Connect 1 transactions
--
2021-06-03T19:14:18.999147Z       - Connect 2527 transactions
2021-06-03T19:14:20.161540Z       - Connect 1 transactions
--
2021-06-04T06:00:27.274780Z       - Connect 2128 transactions
2021-06-04T06:00:49.580074Z       - Connect 1 transactions
--
2021-06-04T09:57:56.541947Z       - Connect 2295 transactions
2021-06-04T09:57:58.988411Z       - Connect 1 transactions
--
2021-06-11T19:11:20.520707Z       - Connect 2294 transactions
2021-06-11T19:11:22.028495Z       - Connect 1 transactions
--
2021-06-12T03:30:34.207538Z       - Connect 2369 transactions
2021-06-12T03:30:36.134363Z       - Connect 1 transactions
--
2021-06-12T08:47:34.116659Z       - Connect 1095 transactions
2021-06-12T08:47:36.855799Z       - Connect 1 transactions



Here are the time differences:


8.59813
1.283111
5.20136
2.986558
8.776111
1.108258
11.146868
6.697645
1.512401
1.101463
4.007643
0.323069
1.675296
22.653179
140.132068
0.474276
3.518084
15.634741
2.894747
1.288856
8.991286
2.314046
10.454143
2.451502
7.66738
1.162393
22.305294
2.446464
1.507788
1.926825
2.73914



    Min.  1st Qu.   Median     Mean  3rd Qu.     Max.
  0.3231   1.5101   2.8948   9.8381   8.6871 140.1321


With a 3rd quartile of 8.68 seconds, the idea that these blocks are coming long after prior ones is clearly false.  There is only one case where I observed one more than 30 seconds later-- and that could be a newly restarted miner, or a case where my timestamp wasn't accurate due to connectivity or propagation issues (or, indeed, a miner that ought to be yelled at: it was block 00000000000000000001eab20e0edf01c17bd8522f132b7c1f88449281fffcdc).


There is a PR for wallet support: https://github.com/bitcoin/bitcoin/pull/21365

There are small differences, basically because you control who you outgoing connect to but an attacker controls that they connect in to you,  so outbound connections are somewhat safer against malicious behavior and are slightly preferred in some places.  Overall the protocol is highly symmetrical but where a peers misbehavior could cause delays and it could freely choose between outbound and inbound peers, it will prefer outbound peers.


In the current networking protocol the aggregate cost to the network for transaction relay is multiplied by the connection degree of nodes. Communication cost ~= constant_1 * nodes * degree * transactions + constant_2 * nodes * transactions.   There are proposals to change this, but that is how it is today (and in every other similar system).

Because of outgroup batching making more connections won't significantly speed up your reception, intentionally so, in order to act against transaction surveillance.  -- which is something your post completely fails to mention,  the processing batching isn't some flaw, error, or limitation--  it is an intentional designed functionality which is extremely important for participant privacy.

There are also potential delays in requesting novel transactions which are important for protecting nodes from denial of service attacks.

Your post takes for granted that there is some issue created by transaction propagation taking a couple seconds, but there isn't-- blocks are found with a 600 second expectation (meaning at every instance the mean time to the next block is about 600 seconds from now) and by comparison to this number a couple seconds are close to irrelevant.  For a user these tiny differences in transaction propagation serve them no disadvantage-- if your transaction is propagated now or a second from now it makes no difference. Transaction's aren't a race.  No protocol that depended on transactions being a race could be secure in any case: because an attacker could get extraordinary delay advantages (at considerable cost) through geographic distribution no matter what the node behavior was.

The only place where small transaction delays matter at all is in mining. The gain a miner has in learning of a new transaction is the marginal increase in fees that transaction offers over the worst transaction it was previously going to include and will now leave out.  Because fees are relatively isotropic this improvement is typically very small.  And if a miner does include a transaction which is poorly propagated they do so at great cost:  Block propagation is many times faster when all transactions in the block are known to the recipient, since in that case the propagation can happen without a round trip.

As things are, most mining infrastructure adds considerable delay post block template creation, the average appears to be greater than 30 seconds except when there is a new chain tip.  If miners were concerned about the lost marginal income of the newest transactions that would obviously be the first place to optimize.

Going into more detail-- your specific claims about the operation of the system are false.  If you'd like to suggest improvements it's important to understand what it's actually doing (and why) and not just substitute the actual operation with your assumptions.

False.  Wallet originated transactions are handled like every other received transaction and will eventually be set to every peer with transaction relay enabled, in or out.  (Also, two of those outbound peers will not have transaction relay enabled-- they are block-relay only for anti-topology discovery purposes).


False. Transactions may be relayed instantaneously.  Each node has a number of transmission groups, each transmission group will broadcast all transactions accepted since its last broadcast according to a possion process with an expected time of a few seconds.  All inbound peers share a transmission group so that attackers cannot get increased visibly into transaction propagation by connecting more times.


False. I'd rebut it, but you provided nothing to substantiate or support this claim.  (in fact, your changes de-activate a explicitly introduced denial of service protection!)


Misleading.  Yes, you can configure your node to not discourage specific peers, but discouragement only occurs as a result of violating network validity rules or anti-denial-of-service protections.  Peers cannot just become banned on accident.  The reason that you may wish to exempt your own infrastructure is for testing purposes, because you have downstream software that isn't a node and doesn't understand enough bitcoin rules to avoid doing something wrong and needs your node to act as a filter, or because you have firewalled nodes behind it whos only connectivity is through your public node and you don't want them going down.

Being excepted from discouragement is no advantage in typical usage, and your use of the string "Bitcoin's elite" suggests that there is some shadowy group of parties gaining some kind of advantage from mutual discouragement protection, and yet no such group exists or has any reason to exist.  Outside of testing harnesses the only widespread use of this permission is miners exempted their own front end pool server so that it doesn't get punished if it sends an invalid block to their node.


False.  The misguided claims you are making here are generally novel.


False. You are just as likely to get your transactions across regardless.  Making more outbound connections will not teach you much additional about new transactions.  Running more (apparent) nodes would teach you somewhat more, but the relay process is designed such that the network rapidly transitions from a few nodes knowing to almost all nodes knowing via exponential growth.


I know how many pieces of popcorn are sitting in a bowl in my sink and you do not. Would you say I have an informational advantage over you?

Generally one would not describe knowing something that someone else doesn't as an informational advantage unless the information is a meaningful advantage.  A wallet doesn't have a meaningful advantage over another because it's learned about some random third party transaction first.

The address manager is extremely sophisticated and has been extensively engineered to avoid attacks and it has held up extraordinarily well in practice.  Although many parties have attempted to attack it, I am aware of no successful attacks in the wild-- though it has had a number of fixes over the years they've all been driven by theoretical attacks, and not an in the wild discovered weakness.

Quite the opposite, the software assumes that the attacker controls many addresses and/ore networks and still attempts to narrow the domain of attacker's power. The software never assumed that the attacker had only a single address, and to the extent that sources are considered in Bitcoin they're always handled in terms of network groups, so an attacker with multiple addresses in the same network block (or ASN, if ASNMAP is in use) are treated as one address.



False.  Though it seems your understanding comes from reading an outdated comment rather than reading the code itself or testing.

The total size is currently 81,920 entries.  16384 of them are reserved for addresses that your node has personally confirmed to be working.


Utterly false.

Your entire description shows you haven't even attempted to understand the operation.  It's extremely hard for attackers to replace good entries with junk due to the try before evict logic:  Among other reasons when a known working peer (in the tried table) is evicted, it's simply moved back to new.  When a peer in new is evicted it's queued for interrogation with a feeler connection.  The feeler connection will try these evicted connections and if they're working, re-insert them.

Non-node wallets don't accept connections.  Most find it more effective to first understand Bitcoin before attempting to improve it.

These changes aren't actually sufficient to do what you think they're doing, but in any case, changing like this will end up getting nodes running it places on various permanent ban lists for abusive mass connecting to the whole network.


There are sharply diminishing returns to increasing the size. There aren't that many reachable nodes in the network, so setting a larger addrman beyond a certain point just will leave your tables diluted with junk that the nodes will waste time unsuccessfully attempting to connect.  Moverover, if due to some unknown vulnerability an attacker can replace a the current table then there isn't any particular reason they couldn't replace a larger one-- if that kind of issue were to exist it would need to be solved and just making the tables bigger would hardly help.


Lol.  This doesn't have anything to do with what you think it does.  Instead, if will just make you vulnerable to relay-jamming attacks where malicious peers offer you transactions and then fail to provide them when you request them.

But perhaps more importantly, if you did accomplish your goal on this bullet point you would grievously harm the user's privacy -- a fact your post makes no mention of and some might even assume was your intent (as we know that blockchain spy companies have attempted to sabotage privacy in Bitcoin node software in the past).

No, the preferred status in the code you're changing above doesn't have anything to do with being configured.

That absolutely does not better reflect its purpose, but it's funny that you managed to change it in 100 places where it is completely invisible to the user but didn't change it in the one place where it's user visible.

Uncoordinated use of a service bit will just end up conflicting with other uses and may eventually end up getting peers running this code banned when their use violates its expectations.  Moreover, your changes don't actually do the thing you think they do.


I'd recommend people not.


Maybe someone dosed your punch with blockchain-braindamage-koolaid.  Bitcoin is not a stock exchange. Users are not vulnerable to front running. Even Franky1 pointed this out to you.  It's not clear to me if you've been personally buzzword addled or if you're just trying to dupe buzzword addled users into running some dubious non-peer-reviewed code.

No blocks will be rejected unless they contain an invalid taproot spend after the lock-in height or are a descendant block of a block that has an invalid spend.  By invalid I mean breaks the taproot rules, e.g. last a signature or has one that doesn't pass validation.

The normal construction of softforks tries pretty hard to avoid creating any conflicting chain, as much as is possible.

That isn't true. Segwit increased capacity and as a result lowered fees for everyone, maybe not as much as you would like but that doesn't justify spreading hateful misinformation.

It would be neat if taproot.watch would add a indicator on how low the signaling would have to fall to block it this period.

Unfortunately many people have no idea how close to a total privacy loss using most any light/mobile wallets is (even over tor)... it doesn't help that they've been actively misinformed.  But in general, people seem to have a hard time reasoning about privacy--  they want it, but seem to forget they want it, and give it up easily.  The harms are just too vague and distant sounding much of the time.

It always is, there is no widely used encrypted network protocol that works otherwise.  Even when you authenticate using a static key.


Nah,  encrypted network protocols work through a mechanism like this:

At connect time, each side picks a new random private key and sends the other side the corresponding public key.  Each side uses their private key and the other side's public key to compute a common shared secret S.

Hash1(S) is used to set the encryption keys for the channel. Hash2(S) is available to the user as a session-id, inside the encrypted transport one party can send Hash3(S||"password")✝ as a simple way to authenticate the session, or they could send a digital signature of Hash3(S) to authenticate the session if pubkey key auth is used.  You can't get back to S from any of the different hashes of it, and both parties contribute randomness to S.

So the encryption key is always distinct, and there is no problem authenticating the connection without breaking confidentiality.

One reason this sort of model is pervasive is because for many popular ciphersuites (any "CTR" mode) the security is obliterated if participants ever reuse a key in separate communications, so the keys need to be random and drawn from a space where reuse will practically never occur.

You'd be right if things worked the way you were thinking, but they don't-- people thought through the problems you're thinking of and solved them a long time ago.

✝ technically they should use more complicated schemes which avoid leaking information that could be used to bruteforce the password, but for this discussion the simple version is a good enough example.

Not sure about your operations, but prior tier-1 networks I've worked with, if it's their equipment on both sides of the link they'll get notified when the packet counters on each side differ too much (indication that the link is silently losing or duplicating packets), which they eventually will if you're actively intercepting traffic.

Similarly, if there is actually active equipment on the line there is a non-trivial chance of noticing that you've still got light up when the other side is powered off.  And if you loop the far end and stick an analyzer or OTDR on the path you're going to immediately notice the active device (though, I can think of only twice I've ever stuck an analyzer on a colo cross connect, it does happen from time to time).

And sure there is commercial hardware available to do interception, but it is less expensive and more scalable to just stick in an optical tap, throw an interface in "half-duplex up" mode, and filter packets off to a collector.  Moreover, we know for a fact that the US's pervasive surveillance infrastructure works exactly that way.

(A passive tap isn't invisible to an OTDR, but it's close to it... you probably wouldn't be able to distinguish it from a crappy mid-span patch)

Though less applicable to Bitcoin alone, if you start trying to do key agreements and decryption for all the traffic e.g. on a 8x100G lag it gets extremely costly (and exits the domain of COTS hardware), while fishing through plaintext traffic for simple matches is cheap and commercially available.

Passive monitoring is essentially undetectable, active isn't. And opportunistic encryption is easily upgraded to fully authenticated just by authenticating the session. What serious reason would you have to oppose adding 0.001% cpu usage in order to upgrade from no resistance to some (even if arguably weak) resistance?

You're missing the point where apple gets sued over it, which I can guarantee would happen.  You also miss the point where this would justify people doing the extra work of adding authenticated links which would happen to some degree, if not as much as we might hope.

But if it's literally impossible to detect, none of that will happen.

That isn't how link encryption works.

Every participant uses a key agreement protocol to establish a random secret key between themselves and each of their encrypted peers. So the data sent is some F(data, key) and the key is private to each pair of participants.  As a result, even if you know data later, you can't go looking at other traffic for f(data, key) because you don't know the respective keys.  This is how every encrypted network protocol works.

Edit: On re-read it wasn't clear to me if you were actually talking about sizes as a side channel, rather than matching content.  It's not unusual for encrypted protocols to add padding to weaken traffic analysis.  In Bitcoin many transactions are exactly the same size, and the proposed encrypted transport is carefully designed so that it avoids leaking the size of individual transactions (in so much as it can-- e.g. usually multiple txn are relayed at once and the protocol doesn't leak their individual sizes), and it also supports padding.

I really wanted to merit your post but I can't with that blockchair recommendation,  I would take an extremely sizable bet that blockchair was surveilling users -- It's run by a russian "AML specialist" who removed the AML bragging from his twitter immediately before starting a bizarre campaign against taproot. Blockchair gives the opposite of good advice on txn privacy, it rates poor privacy transactions as good and good privacy transactions as bad.

Even using it via tor there are lots of ways to fingerprint tor browser. It's certainly better than *not* using it.  But I wouldn't recommend contacting a party which is almost certainly secretly surveilling users even with it.

Your other advice to use tor, that's good advice and what I was gonna post except you already did.

This isn't true, FWIW.

Without encryption monitoring can be completely passive: Extremely cheap and totally undetectable (except by leaking monitored data, of course). It can even be hard for a network operator to know that someone is passively monitoring their links.

With encryption, the attack much be active. This makes is much more expensive-- instead of just scanning and logging data you have to get into the protocol, perform encryption/decryption, it scales much more poorly.  The intercept can't be a passive tap, it has to be in the path.  The active interception is always at risk of discovery, potentially after the fact, and when the monitoring would be *unlawful* or contrary to disclosed public policy, getting caught would be bad news.

For Bitcoin, the proposed opportunistic encryption logs an session ID into each side's logs when they connect (and would display in peer stats).  If there is an active MITM these session IDs will not match.  Even if a tiny percentage of users ever look a wide scale MITM would eventually get caught.

Further than that in Bitcoin I also proposed an authentication protocol where a MITM fundamentally cannot tell if authentication is in use, so he cannot selectively MITM non-authenticating users and avoid MITM-ing authenticating users.  Any MITM attempt then has the risk of immediately alerting the user.  This way a small number of authentication users provides herd resistance for everyone else.

Of course, these measures are not perfect-- but nothing in security is perfect.  These measures are about an improvement.  Even just pushing attackers into doing active interception makes targeted dragnet surveillance considerably more expensive.  Of course, if you have stronger measures available you should still use them, but the inherent of complexity of authentication (e.g. what is an 'identity'??) means that often stronger isn't available.  Unencrypted shouldn't be the default, encryption is cheap and even without authentication it can provide strong protection against some attack models even though it is fundamentally limited.  It's not a replacement for an authenticated channel, but it is by no means useless.

The CA model has its own serious flaws.  For example, nation-state adversaries can just arbitrarily print certificates, ... as well as network attackers, pretty much:  If you can active intercept traffic on the path between and public certificate authority and an IP address that a target domain name resolves to, you can get that CA to issue you a certificate.  So in practice, the HTTPS CA model provides almost zero security form active network attackers who are positioned near the webserver.  The unfortunate fact about the HTTPS CA model is that because you need to get a cert to usefully use HTTPS at all, it has to be extremely easy to get a cert, and unfortunately that also makes it easy for some kinds of attackers to get them too.

I'm aware of no SPV wallet that looks to multiple sources, and it would be almost certantly a waste of time to do so--- it's cheap and easy for an attacker to outnumber the honest hosts on the network (that's part of why it's used for consensus!), if an attacker can be one of your peers he can be multiple without much more difficulty.

SPV wallets are strongly predicated that miners validated the block and are honest, to that extent that isn't true, SPV is just not particularly secure.

It's mostly not patches but external mining software. Some of the less good things they do are done because thats whats easy to do outside of the daemon. Not so fun to reimplement consensus rules, so why bother?

The viabtc mining code is public and you can see many such approximations.  E.g. they decide if an incoming block meets the target by the deriving a number of leading zeros off the floating point difficult number rather than an accurate target test.  So if you make a block with a lot of leading zeros but still doesn't meet the target, that code will temporarily switch to it and mine children that will be ignored by every bitcoin node an wallet.   There is no meaningful computational cost in doing the test accurately-- it's just more implementation effort for an external codebase. The fact that it's fairly easy to attack (mining hardware ordinarily returns sub target work, so it would be easy enough to filter that for work that met the relaxed test but not the real target... Presumably they'd fix it once they noticed they lost blocks to it.

One thing to consider is that 2.5% PPS is pretty much guaranteed to go bankrupt per kelly criterion with a reasonable bankroll.  Computationally bounded rationality can be a problem when your system's assumptions depend on rational self interest.

One place where Bitcoin suffers is that it's very stable, and you can keep running old versions. As a result multicryptocurrency pools spend a lot of attention on trashfire altcoins that needs constant emergency fixes, and less on Bitcoin. There have been problems with stuff like newer bitcoin needing a compiler no less than 3 years old but some large miners have much older operating systems.  I don't think there is any real fix except increasing the rate of change-- it's a point I've raised in disagreements that argue that Bitcoin's conservative approach is safer. To a point that's true, but there is a point where being too slow to introduce changes introduces its own risks.

Hopefully taproot marks the end of a one time dry spell and with renewed confidence that clear improvements can be activated without disruption more will be written.

Actual validation typically takes under 50 milliseconds or so-- and even faster on hardware with sha-ni--, typically because almost all the validation is cached. During that amount of time you might as well stay on the prior block because you have a non-zero chance of winning on the prior block anyways in a race, and not including transactions will greatly reduce your income.

But the validation isn't the only, or largest, source of delay.  E.g. constructing a block template takes time.  Miners could instead always mine on already validated tips, but include a very suboptimal block (including empty) on the initial work they generate on a new block, but that would take more work to implement than just monitoring other miners and mining whatever other header they mine on.  It also avoids worrying about various other block propagation DOS vectors.   But it really trashes the security assumptions of SPV pretty bad.

It's kind of a circus, eventually some miner going to do that is going to get a SPV user robbed, and since all the miners are helpfully identifying themselves, they're going to get sued for damages by the robbed user and it's going to turn into a complete circus.  Years ago I talked a major exchange out of attempting to sue miners that mined txns which weren't the same ones the exchange saw first... took some real effort to get them to understand that just because they saw the other spend first that didn't mean the miner did.

Fortunately, you can opt out of the exposure by running your own full node and keeping it up to date, or by treating high value transactions from untrusted parties as unconfirmed until they have a dozen confirmations or so.