I believe there is no difference between an incoming and outgoing connection other than who originates the connection.
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.
I think increasing outgoing connection limit from 10 would reduce propagation delay by allowing clients to share transactions with more nodes. What is the reason for this restriction?
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.
When you open a wallet software to send a transaction, it will only be sent to up to those 10 nodes.
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).
Since each node delays your transactions by at least 2 seconds if it forwards it at all
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.
(this behavior) also opens up your node to denial of service attacks, potentially causing outages of service.
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!)
Of course Bitcoin’s elite is immune from random disconnections by configuring each other as privileged
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.
many quickly realize that
False. The misguided claims you are making here are generally novel.
Having more open connections means you are more likely to receive information early and get you transactions across.
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.
informational advantage over a naive wallet node.
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.
simplistic address manager implementation that contains many problems
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.
It presumes a single attacker has only one address, a naive assumption at best or abdication of responsibility at worst.
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.
With total size of 65,536 (1024 * 64), and possibly containing the same address 8 times,
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.
Anyone that spends few dollars to gain access to several hundreds of ips for few minutes can wipe out the whole data structure.
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.
That will make nodes connect to wallets and waste resources.
Non-node wallets don't accept connections. Most find it more effective to first understand Bitcoin before attempting to improve it.
Higher networking limitations, giving you better visibility & priority nodes running official software
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.
Larger address manager to mitigate attacks
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).
The only way to get preferred status is to have other nodes configure your address as such.
No, the preferred status in the code you're changing above doesn't have anything to do with being configured.
Renamed NoBan flag to VIP to better reflect its purpose
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.
Add a new service bit, FAST_RELAY, to announce that we don’t play favorites
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.
Using Elon
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.
