Topic: Idea: "Superpeers" Bitcoin core/block broadcast should use prioritized peer list (Read 1408 times)

The Bitcoin core client sends to peers concurrently? Well that's not quite ideal if you have a limited amount of bandwidth. See this image: http://www.enggpedia.com/images/stories/fdm-tdm-300x205.jpg

For reducing orphan rates, we want to lower latency as much as possible. Therefore putting all of your bandwidth towards sending your discovered block to a fast relay will raise propagation rates more than splitting up your bandwidth with concurrent connections.

It sends to peers concurrently; the relay network gateway is local and turns most blocks into 2 or fewer packets.

Not what I'm thinking At all. I'm not pro-"one big datacenter" approach. I'm talking about relaying blocks through fast relays.

Cool! So Part B] is done. The Bitcoin core client doesn't prioritize peers through (at least as far as I can telling looking through it), so adding that relay network might help or it might not.

You've spend too much time thinking and not enough time reading.

Your idea is already implemented by Matt Corallo under the name "Relay Network".

https://bitcointalksearch.org/topic/how-and-why-pools-and-all-miners-should-use-the-relay-network-766190

I posted this elsewhere, but seems relevant to your idea. (figured its better in full context then to just crop it down to the superpeers/keynodes bits)

One "Disadvantage" to larger block sizes is that miners want to squeeze their blocks onto the network as soon as possible, and larger blocks cause them to orphan more. I was talking to Luke-Jr about IPv6 multicasting, and I was disappointed to find out that in the real world it looks like that won't be happening. But after some thought I realized we can virtualize it with just a fast superhost that turns Unicast into "Virtual" Multicast (by proxying unicast connections) i.e. what happens naturally during block propagation

https://www.reddit.com/r/Bitcoin/comments/3fdvx7/discussion_what_ipv6_means_for_bitcoin_and_the/ctods5w?context=5

Basically instead of doing this:

1. Miner New Block -> Peer 1 (1 MB, 1 second)
2. Miner New Block -> Peer 2 (1 MB, 1 second)
3. Miner New Block -> Peer 3 (1 MB, 1 second)
4. Miner New Block -> Peer 4 (1 MB, 1 second)
5. Miner New Block -> Peer 5 (1 MB, 1 second)
6. Miner New Block -> Peer 6 (1 MB, 1 second)
7. Miner New Block -> Peer 7 (1 MB, 1 second)
8. Miner New Block -> Peer 8 (1 MB, 1 second)

= 8 peers in 8 seconds, 1 peer / second after that (+ P2P exponential peering)

Let's do this:

1. New Block -> "Virtual Multicasting Superhost" (1 MB, 1 seconds)
2. "Virtual Multicasting Superhost" -> Peer 1 (1 MB, .1 second concurrently)
3. "Virtual Multicasting Superhost" -> Peer 2 (1 MB, .1 second concurrently)
4. "Virtual Multicasting Superhost" -> Peer 3 (1 MB, .1 second concurrently)
5. "Virtual Multicasting Superhost" -> Peer 4 (1 MB, .1 second concurrently)
6. "Virtual Multicasting Superhost" -> Peer 5 (1 MB, .1 second concurrently)
7. "Virtual Multicasting Superhost" -> Peer 6 (1 MB, .1 second concurrently)
8. "Virtual Multicasting Superhost" -> Peer 7 (1 MB, .1 second concurrently)
9. "Virtual Multicasting Superhost" -> Peer 8 (1 MB, .1 second concurrently)

= 8 peers in 1.1 seconds, 80 peers / second after that (+ P2P exponential peering)

For those with slow network, using a proxy like this can reduce orphan rates.

As for costs, I'm sure many of the big name bitcoin companies would gladly pick up the tab for a chance to be the first recipient of new blocks.

To be 100% clear here, this is what I'm proposing:

1. Allow miners to add custom peers and have them prioritized when broadcasting blocks
2. Build/Find and advertise super peers that are able to broadcast blocks quickly