Bitcoin Forum
December 07, 2024, 02:23:21 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Don't relay blocks from ViaBTC & Bitcoin.com ?  (Read 889 times)
doc12 (OP)
Legendary
*
Offline Offline

Activity: 1284
Merit: 1042


View Profile
October 16, 2016, 07:45:24 PM
 #1

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 ?  

tntdgcr
Full Member
***
Offline Offline

Activity: 219
Merit: 100

Bitcoin Mining Hosting


View Profile WWW
October 16, 2016, 07:47:59 PM
 #2

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.

OregonMines is expanding. Are you expanding with us?
doc12 (OP)
Legendary
*
Offline Offline

Activity: 1284
Merit: 1042


View Profile
October 16, 2016, 07:49:58 PM
 #3

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  Grin?
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3570
Merit: 6914


Just writing some code


View Profile WWW
October 16, 2016, 07:55:13 PM
 #4

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  Grin?
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
Legendary
*
Offline Offline

Activity: 3430
Merit: 3080



View Profile
October 16, 2016, 08:02:02 PM
 #5

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)

Vires in numeris
doc12 (OP)
Legendary
*
Offline Offline

Activity: 1284
Merit: 1042


View Profile
October 16, 2016, 08:58:50 PM
 #6

OK understand, thx for the answers Smiley
newIndia
Legendary
*
Offline Offline

Activity: 2226
Merit: 1052


View Profile
October 16, 2016, 09:50:25 PM
 #7

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

Activity: 3430
Merit: 3080



View Profile
October 17, 2016, 12:40:57 AM
 #8

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.

Vires in numeris
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!