Zarathustra
Well-Known Member
- Aug 28, 2015
- 1,439
- 3,797
I'm not too informed about the whole "Jihan demotion" stuff but afaik Bitmain still sits on a shitload of BCH coins.I count 75% pro SV hash.
and now with prices equilibrating and the jihan demotion, I don't see a war. or at least a long lasting one.
Staying calm is almost always the best option.try to stay calm. there's alot of good that can come out of this.
You misunderstand. There is no possible way to avoid recovery of lost coins by miners. The only question is whether it happens in organized fashion that contributes to security or a disorganized fashion that doesn't.Scary how people in this thread start defending the absolute insanity of "recovering lost coins by miners" just because a certain cocaine addict expressed this idea.
There is also no possible way to avoid double spends and inflation by miners. The only question is whether it happens in organized fashion that contributes to security or a disorganized fashion that doesn't.You misunderstand. There is no possible way to avoid recovery of lost coins by miners. The only question is whether it happens in organized fashion that contributes to security or a disorganized fashion that doesn't.
This is true. The benefit is a continous process where most nodes know most of the other nodes' block candidates. When a block is found, you only have to send the coinbase tx and the header and get a near instant block propagation independent of the block size.You do a full broadcast through TCP, basically
Yes, I'm surprised nobody has done this yet for tx propagation. UDP is great when you don't need to know for sure that the receipient get the data.whereas it is a lot more efficient to do broadcast over a proper broadcast medium like UDP multicast.
Getting rid of block propagation after a block is found, is also beneficial in the scenario where bandwidth is the constriction, right? You don't have the spikes in bandwidth anymore.And in the scenario where block size is constrained by bandwidth economically this will matter.
I can't see how you come to this conclusion. We acknowledge that it's not a complete graph. It's a near complete graph.You also seem to make the mistake of identifying a small-world network with a fully connected graph in your paper with corresponding implications to this being expected to be (not) the best scheme.
The mining nodes of Bitcoin will seek to form a small world network, where each node is directly connected to almost all other nodes of the network.
It should be clear that we don't believe it's a complete graph.IBS is not a block relay method, where a block is transmitted via several hops. Block relay will still be needed occasionally.
Thanks. We're just putting this idea out. If a miner wants this, he can build it.But that all said, I see no reason why you couldn't code this up and test it out. It is a scheme that still seems viable in the sense of getting a block across somehow, so good luck!
"Someone else was going to steal the coins anyway so I thought I would go ahead and steal them first?".i suppose the point was that burnt coins are not really burnt forever, they eventually become re-mineable (their PK becomes crackable by those with sufficient computing power), so the purported economic backing of a token generated by proof of burn is temporary at best.
i do not know how to evaluate that argument but i do know how not to mistake it for FUD.
No, it's not broadcasting. Candidate blocks are only streamed to nodes that has subscribed. Every subscriber will receive the exact same stream. You could actually use TCP multicast to optimize it, but far as I are aware of, multicast routing haven't been implemented on the public Internet and it seems very unlikely it ever will. If a miner wants to distribute their candidate block streaming, they could use multicast or something similar internally.@Norway: You do a full broadcast through TCP, basically - whereas it is a lot more efficient to do broadcast over a proper broadcast medium like UDP multicast.