Bitcoin Forum
December 15, 2017, 04:42:35 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Idea: "Superpeers" Bitcoin core/block broadcast should use prioritized peer list  (Read 1317 times)
asperous
Newbie
*
Offline Offline

Activity: 17


View Profile
August 02, 2015, 09:09:29 AM
 #1

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
1513356155
Hero Member
*
Offline Offline

Posts: 1513356155

View Profile Personal Message (Offline)

Ignore
1513356155
Reply with quote  #2

1513356155
Report to moderator
1513356155
Hero Member
*
Offline Offline

Posts: 1513356155

View Profile Personal Message (Offline)

Ignore
1513356155
Reply with quote  #2

1513356155
Report to moderator
1513356155
Hero Member
*
Offline Offline

Posts: 1513356155

View Profile Personal Message (Offline)

Ignore
1513356155
Reply with quote  #2

1513356155
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
klondike_bar
Legendary
*
Offline Offline

Activity: 1652

ASIC wannabe


View Profile
August 02, 2015, 02:52:04 PM
 #2

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)

Quote
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

24" PCI-E cables with 16AWG wires and stripped ends - great for server PSU mods, best prices https://bitcointalk.org/index.php?topic=563461 also selling 6" M-F-M PCIe splitters and PCIe-PCIe
No longer a wannabe - now an ASIC owner!
2112
Legendary
*
Offline Offline

Activity: 1988



View Profile
August 02, 2015, 04:50:00 PM
 #3

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


Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
asperous
Newbie
*
Offline Offline

Activity: 17


View Profile
August 02, 2015, 06:40:05 PM
 #4

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
Newbie
*
Offline Offline

Activity: 17


View Profile
August 02, 2015, 09:01:06 PM
 #5

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)

Quote
- 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
Moderator
Legendary
*
qt
Offline Offline

Activity: 2366



View Profile
August 03, 2015, 08:25:24 PM
 #6

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.

Bitcoin will not be compromised
asperous
Newbie
*
Offline Offline

Activity: 17


View Profile
August 04, 2015, 11:14:52 AM
 #7

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.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!