Topic: Can spanning tree protocol be used in Bitcoin? (Read 990 times)

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

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.

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)

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.

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

Excellent analysis. The Bitcoin network uses hash power as leader election, so the network depends on the honesty of the leader

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.

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?