Idea: "Superpeers" Bitcoin core/block broadcast should use prioritized peer list

[asperous]

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

[klondike_bar]

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)

IMO, common sense dictates that in 5 years from now, given virtually unlimited space for blocksize growth (with limitations against spam), the blockchain will be ~2TB and the network will look like this:

- A few dozen 'key nodes' that are located in major datacenters with virtually unlimited fiber bandwidth, lots of storage space, and full verification. Some might be hosted by companies such as google or IBM as demonstration of technical ability or involvement in crytocurrency

- thousands of smaller nodes on home computers or businesses that want their own full backend to handle payments. Its likely that many of these will operate pruned nodes or have limited upload capabilities.

- A few dozen major mining companies and pools. There are a lot of datacenters that are set up in locations with good bandwith and cheap power in the 1-20MW range. Most pooled mining servers are located in major datacenters with high bandwith (ideally alongside a 'key node')

- smaller miners (<50kW) will certainly be pooled mining, which removes the need for downloading full blocks or verifying (you just need to receive the nonce info, hash it, and return any valid solutions)

I 100% guarentee that the future of bitcoin will depend on the 'key nodes' (or 'trusted nodes') principal - where major national/trans-oceanic fiberoptic or satellite hubs throughout the world (such as NY, LA, Toronto, London, Paris, Shanghai, Tokyo, etc) are capable of handling PETABYTES of uploads and downloads and could conceivable handle a virtually unlimited blocksize with state of the art systems. The rest of the network would then act as the broader decentralization and secondary validation.

ps: I like 8MB, doubling every 2 years, but I think 4MB doubling every 3 years would be more acceptable to those fighting for a small blocksize. Anything less than that would be insufficient for global usage

[2112]

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://bitcointalk.org/index.php?topic=766190.0

[asperous]

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://bitcointalk.org/index.php?topic=766190.0

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.

[asperous]

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)

- A few dozen 'key nodes' that are located in major datacenters with virtually unlimited fiber bandwidth, lots of storage space, and full verification. Some might be hosted by companies such as google or IBM as demonstration of technical ability or involvement in crytocurrency

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

[gmaxwell]

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.

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

[asperous]

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.

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

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.