Topic: Increasing outgoing connection limit - page 2. (Read 393 times)

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