Don't relay blocks from ViaBTC & Bitcoin.com ?

[doc12]

Hi, is there a possibilty to prevent the block relay of blocks mined by ViaBTC & Bitcoin.com  on a node ?

Could this be a way to slow down the block propagation on the network, if enough nodes dont relay the blocks? And by doing so reduce the precentage of blocks these pools are mining ?  

[1714024962]

1714024962

[1714024962]

1714024962

[1714024962]

1714024962

[1714024962]

1714024962

[tntdgcr]

Hi, is there a possibilty to prevent the block relay of blocks mined by ViaBTC & Bitcoin.com  on a node ?

Could this be a way to slow down the block propagation on the network, if enough nodes dont relay the blocks? And by doing so reduce the precentage of blocks these pools are mining ?  

to what end though? miners vote with mining power.

[doc12]

But if two blocks are mined almost at the same time (by two different pools), then in my understanding the one is going to be accepted which propagates faster across the network.  Or is this BS  ?

[achow101]

But if two blocks are mined almost at the same time (by two different pools), then in my understanding the one is going to be accepted which propagates faster across the network.  Or is this BS  ?

The one that is accepted is the one that other miners build on top of. The propagation does matter, but if no miner builds on top of the block, then even if it has propagated very well, the block can still be orphaned.

In theory you could do this. You would have to modify the block verification logic to check for ViaBTC's addresses or their "signature" in the coinbase script. Then you could reject the block as invalid and thus prevent your node from relaying the block.

[Carlton Banks]

Not worth it IMO. The other pools have an incentive to outcompete both pools, and I doubt that either entity has access to the best tech or even the best price for the tech they can get. If the latter changed, well, it's probably best to go Meni Rosenfeld's route (randomly & periodically changing POW to stacks of serialised hash functions, to disallow ASICs)

[doc12]

OK understand, thx for the answers

[newIndia]

randomly & periodically changing POW to stacks of serialised hash functions, to disallow ASICs

Is it really possible? Because, once all the hash functions are known, ASIC can be built for each... is not it?

[Carlton Banks]

randomly & periodically changing POW to stacks of serialised hash functions, to disallow ASICs

Is it really possible? Because, once all the hash functions are known, ASIC can be built for each... is not it?

That's why I say they are randomly serialised. Today we have a sequence of 2 SHA256 hashes in a row to attempt a block solution, and the ASIC chips are (I believe) designed to perform 2 sequential such hashes only. With the proposed change, a series of 10 or more different hash functions would be used for a single POW calculation, and the combination of hash functions would be changed periodically, like difficulty or block reward adjustments are made now. Meni's original proposal suggested 100 different hash algorithms and 10 functions per series. Making ASICs to account for all possible function combinations ought to be prohibitively expensive, and even if not, just find the point where it is not economical.