Bitcoin Forum
May 28, 2024, 03:24:29 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Tweak protocol, brick Asics - defend attack  (Read 454 times)
VentMine (OP)
Full Member
***
Offline Offline

Activity: 236
Merit: 105


View Profile
January 31, 2017, 02:09:16 AM
 #1

If chains forked, can the same asics mine on either chain? If so, could a majority miner attack the weaker chain? Could the weaker chain modify their own protocol to brick the asics?  Huh  Kiss

1ESSdoVYKm8sNtYMfdkFBajhAe2e6G8keH
DannyHamilton
Legendary
*
Offline Offline

Activity: 3402
Merit: 4656



View Profile
January 31, 2017, 03:58:08 AM
 #2

If chains forked, can the same asics mine on either chain?

That depends on why the chain forked.

If so, could a majority miner attack the weaker chain?

Sure. But to do so, they'd have to abandon mining on the chain that they aren't attacking.  Since they were a "majority miner", that would leave their preferred chain much weaker and open to attack itself.

Could the weaker chain modify their own protocol to brick the asics?  Huh  Kiss

Brick?  You mean damage them?  Probably not.  But they could adopt a protocol that the current bitcoin ASICs would be useless for.  Those ASICs could still be used on any other coins or forks that used bitcoin compatible mining.
franky1
Legendary
*
Offline Offline

Activity: 4228
Merit: 4501



View Profile
January 31, 2017, 03:59:52 AM
 #3

if nodes avoided consensus and put up the ban node barricade to cause an intentional split then,
if you are going to do that, then certainly change the mining algo.
especially if the split you are on is a low hashrate. because by going it alone is not just exposed attack. but also causes the nodes to be waiting alot longer for genuine blocks to be produced due to high difficulty vs low hashrate.



due to intentionally banning nodes there would be 2 sets of data with different chains. because the nodes are no longer cooperating/connecting to eachother to form consensus and orphan the wrong/undesirable blocks.

if you have changed the mining algo and now you have your own altcoin, name it clams 2.0 or another random name but its no longer bitcoin



if however you stuck to the same algo's and wanted to play out pool attack scenarios of what could happen if an opposing pool hopped over to your altcoin... then here goes

opposition with low hashrate (under 50% of your network):
the opposition either has to follow the rules of your altcoin to get accepted into that chain to avoid rejects/orphans means the only attack vector that has consequence is 'empty blocks' to cause a bottleneck of transactions left waiting in mempool, and not be subject to reject/orphan risk.
else not following the rules they would get rejected and the nodes just wait for the next genuine rule following block. (no drama)

medium hashrate over 50%:
same as before but this time there are more empty blocks,

else not following the rules same as before but this time they also may be able to build a heritage of rejects if they manage to be next inline for the following block to. resurrecting their reject now as a parent to then add another block ontop as a child, where both simply get rejected (this is then buzzworded 'orphan')  (no drama)

high hashrate:
same as before but this time there are even more empty blocks,

else not following the rules same as before but this time they also may be able to build a deeper heritage of rejects if they manage to be next inline for the following block and the following block after that. resurrecting the first reject now as a grandparent to then add second reject ontop as a parent and the newest block as the child, where they simply get rejected (this is then buzzworded 'orphan chain') (no drama)



rule following, no reject 'empty block' attack vector.
   if able to be persistent(many weeks) and have high enough hash power.. can also cause the difficulty to rise so that the ethical pool has less chances of having blocks with transactions included.
rule breaking, attack vector.
   if able to be persistent and have high enough hash power.. can also cause nodes to just get spammed with rejects while nodes wait for genuine blocks

now take note of my very first sentence.
there is only 2 chains if the nodes intentionally ban opposing nodes.
just having bad data does not cause long term permanent chains. because eventually it will orphan/reject the bad data out, where the low minority rejecting the high majority(on the one chain) simply end up being spammed with rejects/orphans while waiting for genuine blocks



what i have said in this post is about POOLS hopping over.

however if the opposing NODES hopped over and took over the altcoin chain by a dominant majority amount of nodes (sybil attack) this would allow them to accept the rejected data and build on the chain as acceptable where by the rules change.. leaving the minority stalled and unsynced

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
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!