Topic: Increasing outgoing connection limit (Read 458 times)

You make it complicated for no reason. This comment from the PR explains how accessible full node operators have priority in propagating transactions. If they get whitelisted by others then even better.
I think it's makes sense that node operators will get something in return, not just the miners. They provide valuable services the community too. Don't you think node operators should be rewarded?

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.

It was introduced here, PR was merged on Oct 14, 2020, that would be 8 months ago.

https://github.com/bitcoin/bitcoin/commit/242d16477df1a024c7126bad23dde39cad217eca

The "and" in that sentence is actually "or". From reading the code it replaced the random delay with constant 2 seconds.

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.

It's a configuration flag, it can only be configured by operators of other nodes by adding --whitelist as i showed you.
There are many ways of testing software that don't require preferential treatment of other nodes.
I get your strategy, just circling the drain until I give up.

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.

Here's how it is configured: https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L471-L473
Just set the NoBan (VIP) for whoever you want.

https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L1054

https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L1062

What am i missing here?


Since it's so useless, would you accept a PR to remove the preferential propagation?
Anyone can add it to their own fork anyway

Because it wouldn't benefit them, it would just waste their bandwidth and cause other participants to banlist them due to wasting their 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.

Also you keep downplaying the transaction delay which is set to 2 seconds for non-preferred nodes
https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L1062
https://bitnodes.io/dashboard/#transactions-propagation
Maybe people sell that whitelisting so whales can have guaranteed service
Can you add a list of preferred wallets too? I think that would be even more popular than preferred addresses

You're missing the point with the extreme numbers, why wouldn't people configure their nodes to have 125 outgoing connections and 8 incoming instead of 8 and 125 respectively. I think it's in order to support the "network", providing services to all those nodes using NAT. It's just like upload/download using P2P file sharing software.
Also you can get a list of nodes from bitnodes.io api so you don't have to waste time crawling

You can't have it both ways, if using outgoing connections & NAT works as well as running a node as far as availability & performance, why would anyone spends money running a full node? Most of them are on hosting providers.
If full nodes have an advantage (maybe higher availability during big market moves), then the privileged access flag is damning.

It also means Bitcoin is very vulnerable to community backlash. If public will pressure AWS, Google Cloud and other hosting providers to kick bitcoin nodes off their services there will not be enough resources to support all those NAT nodes. Most public nodes i can reach are hosted on such services. Amazon is buying carbon credits and touts their ESG goals. Seems hypocritical to me...
5k * 125 incoming connections < 83 * 11 outgoing

Do you think they run their nodes with only 10 peer connections or do they increase the outgoing connection limit?

seems the topic creator wants 'fast' tx relaying so he can gain a vew millisecond advantage to see bitcoin deposits going into exchanges before they are even confirmed

what he doesnt realise is although a whale might be depositing funds into an exchange. it may not result in a on exchange market order that day or week
also the deposit does not reveal if that funds leads to a long or a short order. thus becomes redundant metric to use
lastly that whale tx being relayed may not actually be a deposit resulting in an on-exchange market order. but could also be just the exchange itself re-organising its cold store reserves. thus making analysing the tx relay and blockchain useless for predicting in-exchange activity

i found it myself. depositing funds into an exchange made me flag up as a whale and suddenly i had to fill in some KYC stuff and a 48 hour admin time.. to get level X utility within the exchange.
so the topic creator stressing over a few milliseconds of tx relay wont benefit him in predicting when trades are going to happen because a deposit does not = instant trade on exchange
and a deposit does not reveal which direction a trader wants to swing. (long or short)


the disconnect. search ip list, connect. handshake send tx disconnect cycle of operations wastes more seconds to 83k peers. rather than the time it takes to just pass data through the network the normal way peer-to-peer relay. to 83k

also the peers you wish to connect to must have available slots to even allow the connection to a new peer and also not already ban hammered you with spam connections from previous tries. so its not something that would last long if you were to try it.
you end up just wasting time and bandwidth and eventually treated like a bad node the network refuses to connect with

.. in short the very thought of a max of 6 hops and max of 2 second delay per hop in your scenario is 12 seconds to get from originator to all nodes.
batch connect send disconnect and repeat for all 83k nodes would end up taking over 12 seconds to attempt and still no guarantee you reached all 83k nodes in your attempts. thus redundant

sending a tx 83k time in atleast 12 seconds is more of a waste than peer-to-peer network relay of upto 12 seconds where your node only sends the tx 10 times

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.

Why do most nodes don't accept incoming connections?

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.

Last question for you.. Let's say there are 10,000 nodes in the network all playing by the rules and opening total of 110,000 outgoing connections. How come my node receives 125 connections? Extrapolating that would mean There are 1,250,000 outgoing connections in the network. We somehow have more than 1m unexpected connections. Is it possible others are using unrestricted forks too?
Would love to hear other explanations.

That is by far one of the dumbest things I have ever heard.
Almost no trading is done with live transactions.
Coinbase / Gemini / Binance / etc are where trading happens. You have to have your BTC on an exchange with several confirms before you can sell.
And you have to have your cash sitting there before you can buy.

--Dave

What the heck? In the 2+ years I've been involved in Bitcoin and a whole year of running a node, I have never heard of or even seen people running "privileged nodes".

There is no such thing as privileged nodes. All nodes are solely identifiable by their IP address (some have domain names but as most of those are arbitrary too, that's missing the point). So it would be a PITA for colluding "elite" users to compile and distribute a list of IP addresses and ports to each other, let alone feeding it to the command line or config file using --addnode flags. Hence why nobody does it.

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.

Thanks for reviewing my content, i'll fix the mistakes.

The reference of 10 connections refers to someone launching official software on their computer in order to make a transaction. They can wait until other nodes will connect to them and then submit the transaction or send it to the limited pool of outgoing nodes, thanks for clarifying it's even more restricted than i thought.

81,920 is not a lot. You can just buy it on hosting providers for about 810$/hr. Feeler interval is also very restrictive.

Bitcoin transactions obviously determine prices in other markets and vice versa. So it's not a stock market on it's own yet it's futures are traded in the stock market.

That gives wallet software even lower priority, proving my pecking order right. Also makes my node with 1400 incoming connections receive transactions earlier than the average node.
I'm sure many trade Bitcoin futures using such privileged information or trade Bitcoin using high frequency data from futures market.

The elephant in the room is still with us, why some nodes are preferred and are not subjected to delay?
How do you know who uses that flag and for what?
How are they coordinating the various black lists you mentioned?

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.


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.

Someone can connect to 10,000 nodes, submit a transaction and disconnect. Relaying is optional for this purpose.
Have you heard of https://en.wikipedia.org/wiki/Front_running and https://www.investopedia.com/terms/p/paymentoforderflow.asp ?
Those delays enable exactly that. This is how many rigged markets screw over participants.

That is how some spy nodes operate. Simply by trying to connect to as many nodes as possible for the purpose of deanonymizing them.
You can... Assuming that you actually can do something with that information.

By and large, transactions has no effect on Bitcoin price or at least having immediate knowledge would have had zero difference. It would be good if you could state something that actually affected Bitcoin's price and was advantages to someone who had that information 8 seconds before the others.
Because most of the people have zero use for it. They're just wasting extra resources for something that is so trivial to them. They don't want to saturate their bandwidth and resources by having to respond to every message that their 10,000 nodes send.

Besides, I probably wouldn't recommend anyone to connect to 10,000 nodes. There reaches a point where your node either runs out of resources or starts to have significantly diminishing benefits to that.

becasue your not just connecting to 10k nodes to send 1 transaction a day
your relaying the entire networks transactions and blocks. so very very bandwidth heavy

also every node would have to accept you as their peer.

..
i still cant see why you are so head strong on having a unconfirmed transaction requiring to be seen any faster
its a meaningless effot as your still waiting 10mins to get a confirm

if its because you want to double spend to services that accept zero confirms by playing them
that can be achieved without needing 10,000 peers connected to your node.

Under best case scenario the timeline for my transaction to propagate would be:

10 nodes -> 2 seconds delay -> 100 nodes -> 2 seconds delay -> 1000 nodes -> 2 seconds -> 10,000 nodes

So it would take at least 6 seconds for my transaction to reach all the nodes.
I can configure my wallet to connect directly to 10,000 nodes and immediately get my transaction to all nodes.
Why don't people do that?

i dont want to over complicate something so insignificant .. but if you really want to know

if the network has 83k nodes

imagine it requires 5 hops if you have 9 peers and rest of network defaults as 8
           *8  *8    *8     *8
9        -72-576-4608-36864
hops      1   2     3         4
at the 4th peer its like 36k nodes. still not 83k so needs another hop.. right?
so the very first packet to their very first peer makes it 72k. still not enough
so they milliseconds later send to their 2nd peer and now its like 108k

meaning at the 4th hop to get to 83k network nodes requires all forth hop nodes to send to atleast 1 peer and about a 3rd of them to send to a second peer

so allthough each hop is 2 seconds...  peers within the hop are milliseconds of difference

where as if you have 12 peers and network defaults as 8
           *8   *8   *8     *8
12      -96-768-6144-49152
hops     1    2     3        4
at the 4th hop 49k peers see the tx. so only requiring nother 34k nodes. which is less then a full set of 1 peer
meaning it can reach all 83k nodes in under the first 9peer data packet sends.. thus milliseconds faster

..
yet you are now personally broadcasting 33% more data as you have 12 peers vs 9 but only gaining milliseconds of network reach

also to note. whilst im using a patterned efficient network spread (8degres of separation model) for easy network hop demonstration, where all nodes are uniquely and precisely positioned between their peers to be a 5 hop example.
reality is nodes are randomly connected and preferably connected so its not an even efficient web of layers but clusters and deserts of nodes.
(5k of nodes in one section of the network may be clusterd and double connected within each other.. )
(5k of nodes in another second maybe distantly and singularly distributed)

making all this redundant and meaningless.. hense why its so insignificant to even bother with yourself
the important thing would be if the entire network was to change the defaults
but then thats only going to be a 2 second difference
..

all in all ..miliseconds or 2 seconds is meaningless for unconfirmed receipt.. because unconfirmed tx's are meaningless until confirmed ~10mins later+

...
as for prefered peers. you can white list peers that have stable connections and never cause any issues sending you bad data. whre as normally peers drop and change and just become random connections
by not having requests every milisecond just means your not DDoSing your peer and they not on you.

again miliseconds or seconds of a unconfirmed tx is meaningless of a concern

If I would want to gain an unfair advantage. I could set up a node with --noconnect to just listen, set up several nodes around the world that have the secret node whitelisted.
That way i could see other peoples transactions earlier than the average node. According to this information i can trade. Also i will have a group of nodes that accept and transmit my transaction immediately saving up to 8 seconds. How is that not an unfair advantage compare to just running single node?

It is not milliseconds in terms of the total time for propagation. It is the milliseconds of difference.
The network is quite robust and there is little to no resource strains when we're met with higher transaction rates;  mempool would simply start to reject lower fees transactions in favour of those that has a higher fee rates. Transactions are fairly small in the first place, so there is nothing with regards to that. There has never been any connection problems within the network, it is extremely robust.

It is simply pointless for you to whitelist nodes, you're giving up the builtin DOS protection as well as your privacy as you're having no delays with transaction relaying. What you want to do, is to establish a direct route to the miners as they're ultimately the ones that decide whether your transaction gets included in their blocks or not. Having faster propagation within the node would only be somewhat faster if your exchange or whoever you're sending to actually cares about unconfirmed transactions, which is pretty much never the case.

I don't understand how could it be miliseconds for propagation if every hop delays my transaction by 2 seconds. Can you help me understand?

Also what are whitelisted peers? Isn't it a way to play favorites? Why don't people group together and whitelist each other giving them priority on transaction propagation, and avoid connection problems if network is under load?

(explaining the offtopic question)

non preferred peers are peers not whitelisted.
in another topic i raised a point that by playing around with the code to make delays in when to send out transactions can be used as a pool exploit to bottleneck the blockchain of its competitors.
basically a pool gives itself a headstart on the next block

EG a pool creates a block but does not pre-relay its chosen transactions(pools own utxo spends it doesnt relay). then when solving a block it can send the compact block out and send the network into a frenzy of them requesting the unseen transactions (as the tx's are not in the networks distributed mempools due to no pre relay) (2second delay)

and at the transaction request, the block creator is further delaying supplying the transactions thus delaying the ability for competing pool nodes to validate the block(few more seconds)

giving the pool many seconds of advantage to start their next block while the competitors are in this limbo of waiting for transactions to validate the broadcast compact block

the pool does not need to make a invalid block. it just needs to delay the other pools from building on their own blocks whilst the exploiter pool is making their next block

note: its not a guaranteed strategy as their is risks of a competing pool solving the same blockheight as the exploit pool. thus making the competing block the winner.  
..
anyways on topic
as many posters have said the OP adding more peers does not cause any significant network effect on tx relay speeds. it only causes excess bandwidth utility of the OP node. the time gain is milliseconds/no gain due to the same number of hops other peers and their branches do to relay the OP's tx

imagine there were 83k nodes.. source: luke JR stats
and imagine ALL nodes accepted more peers to reduce the hops
it would require
all nodes with 8 peers (8^6) means 6 hops, as 5(8^5) hops is not a number that goes upto 83k
all nodes with 10 peers (10^5) means 5 hops as 4(10^4) hops is not a number that goes upto 83k
all nodes with 17 peers (17^4) means 4 hops as 3(17^3) hops is not a number that goes upto 83k

so to even get a situation where the OP transaction reaches the entire network faster would require the entire network having more peers per node. which then only results in a few millisecond/seconds difference. but alot more bandwidth per node

Preferred peers are whitelisted peers or outbound peers. I believe the reverse would be simply just inbound peers, makes sense as the purpose of doing so is to enhance the privacy.

Both will propagate to a similar extent and be seen by a miner. The premise of a faster propagation comes with the fact that your peers must not be spying nodes and are not interconnected to a huge extent. It does nothing if you're going to relay to nodes that are mostly interconnected to each other; you might as well just propagate to a few nodes and they'll probably achieve roughly the same rate as well. There is no reason to assume that sending your transactions to more nodes would bring about a faster confirmation as the time it takes for it to be propagated to half of the network stands at 3s in 2017, as seen in a research paper.

So long that you can propagate the transaction to a miner within a reasonable period of time, there is no reason to believe that your transaction will always get confirmed slower. There are still various delays even when it reaches the miners; validating your transaction, pushing your transaction to the miners in the pool, (re)assembling the block headers. The inherent delay would already lower the significance of having 1-2 second advantage over the others. Unconfirmed transactions don't mean much to most exchanges anyways.

Let's say that every node relays your transaction to 7 other nodes with a 2 second delay.

Initially, you send the transaction to 8 nodes.
After 2 seconds, 56 nodes have the transaction.
After 4 seconds, 392 nodes have the transaction.
After 6 seconds, 2744 nodes have the transaction.
After 8 seconds, 19208 nodes have the transaction.

There are about 10000 active nodes according to Bitnodes, so your transaction has been propagated to every node in 8 seconds.

Also, what "financial situation" is being impacted by the 8 second delay?

The propagation delay is insignificant compared to the time it takes for the transaction to become confirmed. If you need super fast transaction times, reducing the propagation delay is not going to help at all. No major services are going to accept unconfirmed transactions, so the delay really comes from waiting for your transaction to be confirmed. That is limited by the block interval of 10 minutes. Even if your transaction could be propagated instantaneously, you still have to wait for a block to be mined.

If you need super fast transaction times you need to use layer 2 solutions like the Lightning Network.

Please look at https://github.com/bitcoin/bitcoin/blob/55a156fca08713b020aafef91f40df8ce4bc3cae/src/net_processing.cpp#L87
/** How long to delay requesting transactions from non-preferred peers */
static constexpr auto NONPREF_PEER_TX_DELAY = std::chrono::seconds{2};

The transaction propagation delay in bitcoin is 2 seconds which could significantly impact the financial situation over server hops.

Therefore, how i see it someone sending a transaction to bitcoin network has two options:
1. Use the official software to send their transaction to limited number of nodes. Hoping that eventually it will propagate and gets in a block.
2. Actively submit the transaction to all nodes increasing the likelihood of acceptance.
 
Why would anyone opt for the inferior #1?

You are forgetting a basic principle of the Peer to Peer networks which is the fact that they usually rely on Gossip Protocol and this doesn't change whether we are in 90's or 2021.
In a P2P network you don't connect and shouldn't connect to every peer to give them your messages, you just connect to a handful of them and rely on them to propagate your messages to their own peers. If each node connected to thousands of others (instead of a handful), it is just wasting its own and their resources.

dont worry about it too much

the theory of 6degree of separation is at play
if you (1) are connected to 6 peers(6^1)=6 nodes see your tx
if those 6 are connected to 6 each (6^2)=36 nodes see your tx
if those 36 are connected to 6 each (6^3)=216 nodes see your tx
if those 216 are connected to 6 each (6^4)=1296 nodes see your tx
if those 1296 are connected to 6 each (6^5)=7776 nodes see your tx
if those 7776 are connected to 6 each (6^6)=46656 nodes see your tx

as you can see your transaction does not require leapfrogging over 46000 hops one by one to get to the entire network
each peer branch of 6 hops it forward through their branch of 6 and within just 6 hops the entire network of 46k nodes has seen it. which is mere seconds. for 6 hops of 6 peer average

increasing the peers at your end doesnt make much difference to the hops needed.
your 1 to 12 peers =12
those 12 still average 6 peers=72
those 72 still average 6 peers=432
those 432 still average 6 peers=2592
those 2592 still average 6 peers=15552
those 15552 still have 6 peers=93332

so as you can see its still 6^6

it may bring it down to 5 hops. which is meer milliseconds of difference. but the downside is you as a relayer of other peoples tx's before you.. will then be sending all their tx's out in more data multipliers thus using more of your bandwidth.


what important is not the number of connections above 10 as that only changes things slightly. its making sure you node is connected to good healthy full node peers that are not just spv/lite leacher wallets that dont relay and just take data and forget without passing it on

basically if all your 6-10 peers are leacher wallets that dont relay. then yea your tx is gonna get stuck
if all your 6-10 peers are full nodes that do relay. then your TX will get sent around the network very quick

its more of a game of who rather than how many
so check the useragents and versions of nodes your connected to to make sure your not connected to any/many leacher nodes
maybe if you know a good popular service that has multiple connections on their side and they are connected to popular services with multiple connections. then you being directly connected in that higher multiplier can help.. but you just doubling your peer count would half the time it takes for tx to get around


i hope this makes sense

Thanks for the reply. The difference is one is active and it's rate can be controlled. I can connect to 1000 nodes per second but i cannot make 1000 nodes connect to me per second. So if i want my transaction announced quickly to the whole network i can connect to many nodes or rely on slow propagation mechanism. 10 outgoing connections total connections is a limitation I'd expect from a P2P software during the 90s, not in 2021. Computers can comfortably handle thousands of concurrent connections. Also this ratio gives a communication advantage to long running nodes that have stable addresses, Especially during times of crisis where resources are limited.

I'm not an expert here, but I believe there is no difference between an incoming and outgoing connection other than who originates the connection. You can change the number of incoming connections using "-maxconnections=N" in the configuration file, but Peter Wiulle recommends against it: https://bitcoin.stackexchange.com/a/8140

It must also be noted that the following statement in that article is false, as Bitcoin transactions have nothing to do with trading or price.

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?
https://galtsubery.substack.com/p/bitcoin-pecking-order