Bitcoin Forum
May 02, 2024, 12:41:18 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Can spanning tree protocol be used in Bitcoin?  (Read 990 times)
g2com (OP)
Sr. Member
****
Offline Offline

Activity: 364
Merit: 255


View Profile
November 28, 2016, 05:10:27 AM
Merited by ABCbits (1)
 #1

Hi, I'm working on a new blockchain proposal right now. My understanding is that gossip is more fault-resistant and topology independent. While spanning tree is faster, it is more fragile as it critically depends on the root node. If the root fails, the entire broadcast tree must be recreated. Is it possible to use tree communication in a peer-to-peer network like Bitcoin?
Even if you use Bitcoin through Tor, the way transactions are handled by the network makes anonymity difficult to achieve. Do not expect your transactions to be anonymous unless you really know what you're doing.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714653678
Hero Member
*
Offline Offline

Posts: 1714653678

View Profile Personal Message (Offline)

Ignore
1714653678
Reply with quote  #2

1714653678
Report to moderator
1714653678
Hero Member
*
Offline Offline

Posts: 1714653678

View Profile Personal Message (Offline)

Ignore
1714653678
Reply with quote  #2

1714653678
Report to moderator
1714653678
Hero Member
*
Offline Offline

Posts: 1714653678

View Profile Personal Message (Offline)

Ignore
1714653678
Reply with quote  #2

1714653678
Report to moderator
ArcCsch
Full Member
***
Offline Offline

Activity: 224
Merit: 117


▲ Portable backup power source for mining.


View Profile
December 05, 2016, 05:25:58 PM
Merited by ABCbits (2)
 #2

An integral part of bitcoin philosophy is that there should not be any centralized "root nodes" and "leaf nodes", the only difference between nodes should be their hashpower.
Also, fault-resistance and topology independence are very important, because the network must be as robust as possible to withstand faults such as a node suddenly failing, also, at least for transactions, speed is of secondary importance, as the confirmation time is much longer than the broadcast time, which is already very fast (a broadcast transaction appears on blockchain.info less than a second after broadcast).
Blocks, on the other hand, could use all the speed-up they can get, as they take 30 seconds to be relayed.
Do blocks have priority over transactions for bandwidth and processor time?
The most certainly should.

If you don't have sole and complete control over the private keys, you don't have any bitcoin!  Signature campaigns are OK, zero tolorance for spam!
1JGYXhfhPrkiHcpYkiuCoKpdycPhGCuswa
g2com (OP)
Sr. Member
****
Offline Offline

Activity: 364
Merit: 255


View Profile
December 05, 2016, 06:34:44 PM
 #3

An integral part of bitcoin philosophy is that there should not be any centralized "root nodes" and "leaf nodes", the only difference between nodes should be their hashpower.
Also, fault-resistance and topology independence are very important, because the network must be as robust as possible to withstand faults such as a node suddenly failing, also, at least for transactions, speed is of secondary importance, as the confirmation time is much longer than the broadcast time, which is already very fast (a broadcast transaction appears on blockchain.info less than a second after broadcast).
Blocks, on the other hand, could use all the speed-up they can get, as they take 30 seconds to be relayed.
Do blocks have priority over transactions for bandwidth and processor time?
The most certainly should.

Excellent analysis. The Bitcoin network uses hash power as leader election, so the network depends on the honesty of the leader
ArcCsch
Full Member
***
Offline Offline

Activity: 224
Merit: 117


▲ Portable backup power source for mining.


View Profile
December 06, 2016, 03:00:55 AM
Merited by ABCbits (1)
 #4

Excellent analysis. The Bitcoin network uses hash power as leader election, so the network depends on the honesty of the leader
Except that the "leader" is "elected" every 10 minutes (on avarage), and must keep hashing to have a chance at being "re-elected".

If you don't have sole and complete control over the private keys, you don't have any bitcoin!  Signature campaigns are OK, zero tolorance for spam!
1JGYXhfhPrkiHcpYkiuCoKpdycPhGCuswa
DannyHamilton
Legendary
*
Offline Offline

Activity: 3388
Merit: 4613



View Profile
December 06, 2016, 03:04:29 AM
Merited by ABCbits (1)
 #5

- snip -
the network depends on the honesty of the leader
Except that the "leader" is "elected" every 10 minutes (on avarage), and must keep hashing to have a chance at being "re-elected".

And the nodes on the network don't trust anything they receive.  They validate EVERYTHING, and therefore don't depend on the honesty of anyone.  If someone is dishonest, every other node will notice and will reject anything they do.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8382



View Profile WWW
December 06, 2016, 04:49:09 AM
Merited by ABCbits (5)
 #6

Hi, I'm working on a new blockchain proposal right now. My understanding is that gossip is more fault-resistant and topology independent. While spanning tree is faster, it is more fragile as it critically depends on the root node. If the root fails, the entire broadcast tree must be recreated. Is it possible to use tree communication in a peer-to-peer network like Bitcoin?

Possible, but not secure. As you noticed, a minimum spanning tree produces graph that is full of points of failure-- almost any dishonest node would cause significant breakage.

For transaction relay I believe I have previously described a class of gossip protocols that should be within a small constant factor of asymptotically optimal without reducing the reliability much below the current setup.

For block relay where the objective is to minimize latency at basically all costs, the state of the art technique uses network coding to achieve latency close to the physical limits-- in the Fibre protocol the source(s) of a block do not send the block data directly. Instead they send error correction code data to their peers who also share this error correction data to their peers.  If the block has size M a node need only receive any M of it it before they can recover the whole block. The process is largely insensitive to link or node outages or delays, and very little redundant data is received. (The actual process is somewhat more complex because it also utilizes the nodes mempools which end up providing most of the block data without every having to transmit it at all.).

(The promiscuous cross forwarding and potential multi-source combining of Fibre depends on all the participants in a single fibre network trusting each other... or otherwise they can trash the recovery.-- this isn't much of problem because fibre is really only needed to get blocks around the world and there can be multiple separate fibre networks)
g2com (OP)
Sr. Member
****
Offline Offline

Activity: 364
Merit: 255


View Profile
December 06, 2016, 05:35:37 AM
 #7

Hi, I'm working on a new blockchain proposal right now. My understanding is that gossip is more fault-resistant and topology independent. While spanning tree is faster, it is more fragile as it critically depends on the root node. If the root fails, the entire broadcast tree must be recreated. Is it possible to use tree communication in a peer-to-peer network like Bitcoin?

Possible, but not secure. As you noticed, a minimum spanning tree produces graph that is full of points of failure-- almost any dishonest node would cause significant breakage.

For transaction relay I believe I have previously described a class of gossip protocols that should be within a small constant factor of asymptotically optimal without reducing the reliability much below the current setup.

For block relay where the objective is to minimize latency at basically all costs, the state of the art technique uses network coding to achieve latency close to the physical limits-- in the Fibre protocol the source(s) of a block do not send the block data directly. Instead they send error correction code data to their peers who also share this error correction data to their peers.  If the block has size M a node need only receive any M of it it before they can recover the whole block. The process is largely insensitive to link or node outages or delays, and very little redundant data is received. (The actual process is somewhat more complex because it also utilizes the nodes mempools which end up providing most of the block data without every having to transmit it at all.).

(The promiscuous cross forwarding and potential multi-source combining of Fibre depends on all the participants in a single fibre network trusting each other... or otherwise they can trash the recovery.-- this isn't much of problem because fibre is really only needed to get blocks around the world and there can be multiple separate fibre networks)

Thanks for the detailed insights! I'm thrilled that my question received attention from a core Bitcoin developer Smiley

So the blocksonly option reduces latency by reducing data size, correct? In my design because the validators vote to pass a block by 2/3 majority, so they need to pass their vote to each other. If gossip does not cause too much overhead I'd love to adopt it.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!