Bitcoin Forum
April 16, 2021, 11:02:00 PM *
News: Latest Bitcoin Core release: 0.21.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: A Possible Solution To Re-Org Attacks That Isn't Inculudes Checkpoints  (Read 303 times)
berkhatipoglu
Newbie
*
Offline Offline

Activity: 3
Merit: 9


View Profile
November 29, 2018, 05:33:03 PM
Merited by d5000 (1), ETFbitcoin (1), bones261 (1)
 #1

As we know one of the greatest problem on PoW blockchains is Selfish Mining/Re-Org Attacks. Even it isn't a big problem on Bitcoin because of it's bigger hash power but most of PoW coins are in deep danger.

How is this problem accures?

As we all know, miners gets their information from nodes (nonminer nodes) and nodes are programmed to keep the longest chain with consensus. When selfish miners shares their (most likely reorganized) longer chain to network, nodes accept it and tell that "this chain is longer, so this is the real chain" to all network. So, when all miners start to mine blocks upon this chain because nodes tell them so, this makes the (possibly) reorganized chain as the real chain. We need to create a new rule to stop this from happening whilst keeping it decentralized manner and not remine old blocks again from the last checkpoint.

How can we protect nodes within decentralized manner?

In my opinion we need to build a wall that rejects changes after every recent 8th block (since we need last 7 blocks to changable due to sync reasons).

When a new block added to chain, the recent 8th block should be considered as "confirmed true" by nodes and all changes that are longer than 8 blocks should be automatically rejected. With this, the longer chain (reorganized) that shared by Selfish Mining Attacker will be rejected by default by nodes if their chain is longer than 8 blocks. Since the whole network will get information from nodes with protection, the whole network would consider the chain before attack as the real chain automatically even it's the shorter chain (so this is an active protection that rejects corrupted info, not a checkpoint for remine the whole chain if we need). The longer (reorged) chain that mined with selfish mining will be a (most likely unseccessful) hard fork from Bitcoin. Network and community can decide that if (reorged) chain is the real chain by changing their nodes manually to reorganized chain. With this we are just actively protecting the pure chain from corrupting by attackers with an automatic protection like a wall, the final decide is on network and community.

This protection is only works if attackers mined more than 8 blocks without sharing with network.

In summary, we need to change the "longest chain always wins" rule to "longest chain wins wihtin 8 blocks".

I call this "The Great Wall" because it makes attackers to stay out of our network. And the most famous wall in the world that kept attackers out is The Great Wall as we all know.


I'm not an expert when it comes to development, so there might be lots of problems with this possible solution. Even it might be very stupid idea. I just wanted to share my idea to community and get opinions from every person as possible.
1618614120
Hero Member
*
Offline Offline

Posts: 1618614120

View Profile Personal Message (Offline)

Ignore
1618614120
Reply with quote  #2

1618614120
Report to moderator
1618614120
Hero Member
*
Offline Offline

Posts: 1618614120

View Profile Personal Message (Offline)

Ignore
1618614120
Reply with quote  #2

1618614120
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
d5000
Legendary
*
Offline Offline

Activity: 2786
Merit: 2250


Decentralization Maximalist


View Profile
November 29, 2018, 07:28:28 PM
 #2

This solution is implemented in most Proof of Stake coins (called "decentralized checkpoint" or "reorg limit"). Only that - to my knowledge - no coin has a reorg limit that's so short like in your proposal (8 blocks). Most have limits in the hundreds of blocks (e.g. NXT's was 720 blocks if I remember correctly). However, that's also because these coins mostly combat "long range" attacks with this measure - which are, as one can see easily, "long". To combat selfish mining, as you write, however I guess the smaller the allowed length of a reorg chain, the better - if latency-related orphan chains are not affected, but these are mostly shorter than 8 blocks.

I've always wondered what are possible problems of this measure (and why BTC hasn't implemented it) - as you said, it could make selfish mining much more difficult.


ETFbitcoin
Legendary
*
Offline Offline

Activity: 1834
Merit: 2741


NotYourKeys.org - Not Your Keys, Not Your Bitcoin


View Profile
November 29, 2018, 08:26:37 PM
Last edit: November 30, 2018, 03:49:07 PM by ETFbitcoin
 #3

It's not bad idea, but AFAIK selfish-mining attack (on theory) usually never withhold more than 6 blocks as it's difficult to achieve that, even unless with 51%+ hashrate.

OP, you might want to check this thread Solving Selfish/Colluding Mining

To combat selfish mining, as you write, however I guess the smaller the allowed length of a reorg chain, the better - if latency-related orphan chains are not affected, but these are mostly shorter than 8 blocks.

Additionally, re-org with low block limit also vulnerable to 51% attack.

berkhatipoglu
Newbie
*
Offline Offline

Activity: 3
Merit: 9


View Profile
November 30, 2018, 12:05:03 AM
Merited by DarkStar_ (5), ETFbitcoin (1)
 #4

Thank you to both of you for replying to my post.

 
This solution is implemented in most Proof of Stake coins (called "decentralized checkpoint" or "reorg limit"). Only that - to my knowledge - no coin has a reorg limit that's so short like in your proposal (8 blocks). Most have limits in the hundreds of blocks (e.g. NXT's was 720 blocks if I remember correctly). However, that's also because these coins mostly combat "long range" attacks with this measure - which are, as one can see easily, "long". To combat selfish mining, as you write, however I guess the smaller the allowed length of a reorg chain, the better - if latency-related orphan chains are not affected, but these are mostly shorter than 8 blocks.

I've always wondered what are possible problems of this measure (and why BTC hasn't implemented it) - as you said, it could make selfish mining much more difficult.



AFAIK decentralized checkpoints are saves the chain history to the checkpoint and if an attack accures they use this checkpoint as starting point and remine the blocks after it. On my idea we don't remine any blocks, we just reject corrupted longer chains (if they are longer than 8 blocks). On theory we can implement this without affecting latency-related orphan blocks since Bitcoin network needs 7 blocks to confirm txs (as I know) because of latency-related orphan blocks. I'm not sure that if 8 blocks can work on practice but BCHABC just made their checkpoint on every 10th block, so it can work with 10 blocks.

It's not bad idea, but AFAIK selfish-mining attack (on theory) usually never withhold more than 6 blocks as it's difficult to achieve that, even with 51%+ hashrate.

OP, you might want to check this thread Solving Selfish/Colluding Mining

To combat selfish mining, as you write, however I guess the smaller the allowed length of a reorg chain, the better - if latency-related orphan chains are not affected, but these are mostly shorter than 8 blocks.

Additionally, re-org with low block limit also vulnerable to 51% attack.

On my opinion, it might have never happen or it might be happening right know, the real thing is we can't be sure. Big financial companies like Visa etc. would do everything they can to stop Bitcoin and altcoins. That includes reorging txs with selfish mining and they can afford it. They could be doing selfish mining right now that continued for days, weeks, months or even years (even it's very unlikely) and their chain might be just 1 block longer than from ours since they might have only just a little bit more hashpower (even their chain is only 1 block longer, it changes the blocks after most recent 8th block, so on theory my idea should stop this either). The worst part is we can't know this untill they share their chain to network. I was thinking about this when I got this idea. Small attacks can hurt but bigger attacks like this can totally fuck our network. You know what they can do with months of selfish mining.

Or even our community can be toxic to other coins and do reorg attacks to smaller chains. We all know what BCHABC/BCHSV doing to each other and how Craig Wright is corrupted.

Even it's a very very very low possibility we need to prevent these from happening. I think it's always better to be safe than sorry.

I didn't check any other ideas before writing this and I will check it soon as possible, thank you very much for sharing that thread.
Zin-Zang
Member
**
Offline Offline

Activity: 364
Merit: 11

Killing Lightning Network with a 51% Ignore attack


View Profile
November 30, 2018, 04:44:19 AM
Last edit: November 30, 2018, 04:54:56 AM by Zin-Zang
Merited by ETFbitcoin (1), mixoftix (1)
 #5

It's not bad idea, but AFAIK selfish-mining attack (on theory) usually never withhold more than 6 blocks as it's difficult to achieve that, even with 51%+ hashrate.

OP, you might want to check this thread Solving Selfish/Colluding Mining

To combat selfish mining, as you write, however I guess the smaller the allowed length of a reorg chain, the better - if latency-related orphan chains are not affected, but these are mostly shorter than 8 blocks.

Additionally, re-org with low block limit also vulnerable to 51% attack.


24 blocks is the # of blocks rewritten by a over 51% majority in March 2013.
https://bitcoinmagazine.com/articles/bitcoin-network-shaken-by-blockchain-fork-1363144448/

If someone has 51%, there is no limit on the number of blocks that they can rewrite.
The only thing that would stop a 51% majority is a coded checkpoint in the program or if a rolling checkpoint was added.

Limited reorgs to a specific # is called a rolling checkpoint.

Without checkpoints, nothing is safe from a 51% attack.
And only blocks/transactions past the checkpoint are safe.

The danger with limited reorgs , is if the attacker can split the network by sybil attack or some other way ,
he could basically cause a network fork and since no reorgs below 6 , the network would stay split unless 1 side totally re-synced from scratch.
Which is why most PoS coins only block reorgs after 500 to 720 blocks have passed.

IE: If one could hack the main internet backbone routers and filter or segment btc mining traffic splitting off say China and the UK.
Then after only 6 blocks, both would be on forked blockchain versions with no way to reconnect except a complete resync from scratch.  Tongue


I was Red Tagged because Lauda Blows Theymos to get back on DT
The rest are just lauda's personal butt monkeys=> Hhampuz , Vod, TMAN , achow101
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1834
Merit: 2741


NotYourKeys.org - Not Your Keys, Not Your Bitcoin


View Profile
November 30, 2018, 04:03:30 PM
 #6

On my opinion, it might have never happen or it might be happening right know, the real thing is we can't be sure. Big financial companies like Visa etc. would do everything they can to stop Bitcoin and altcoins. That includes reorging txs with selfish mining and they can afford it. They could be doing selfish mining right now that continued for days, weeks, months or even years (even it's very unlikely) and their chain might be just 1 block longer than from ours since they might have only just a little bit more hashpower (even their chain is only 1 block longer, it changes the blocks after most recent 8th block, so on theory my idea should stop this either). The worst part is we can't know this untill they share their chain to network. I was thinking about this when I got this idea. Small attacks can hurt but bigger attacks like this can totally fuck our network. You know what they can do with months of selfish mining.

Or even our community can be toxic to other coins and do reorg attacks to smaller chains. We all know what BCHABC/BCHSV doing to each other and how Craig Wright is corrupted.

Even it's a very very very low possibility we need to prevent these from happening. I think it's always better to be safe than sorry.

I didn't check any other ideas before writing this and I will check it soon as possible, thank you very much for sharing that thread.

I agree that most big financial company and government doing everything they can to stop, control or limit Bitcoin, even though most of their attempt isn't attacking Bitcoin directly (such as FUD about Bitcoin is only used by criminal or make it illegal).

While selfish mining is quite bad, you need to make sure your solution don't create new attack vector such as possible history/chain manipulation for nodes that isn't online 24/7 (such as people who run full nodes only when they open their wallet). Nodes which online 24/7 would know which chain is real (not manipulated with re-org attack), but otherwise there's almost no way to tell the difference as both of them have high PoW amount. CMIIW.

If someone has 51%, there is no limit on the number of blocks that they can rewrite.
The only thing that would stop a 51% majority is a coded checkpoint in the program or if a rolling checkpoint was added.

Thanks for the correction, i chose different word which have different meaning.

rifiuti
Full Member
***
Offline Offline

Activity: 322
Merit: 101


View Profile
December 01, 2018, 02:20:54 PM
 #7

so checkpoints? Bcash already implemented this to prevent SV re-org the chain.

Take my word with a grain of salt; If you implement checkpoints you compromise from decentralization.
 
The concept of decentralization itself is another thing. After all those years it feels like "decentralization" is a subjective concept. Everyone is defining from different point of perspective.

It's true that someone needs to write the codebase and someone with sufficient knowledge needs to maintain, fix & improve it. It's not a one person job, so a group of people with enough knowledge starts maintaining, fixing & improving. That's already leading to centralization.
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1834
Merit: 2741


NotYourKeys.org - Not Your Keys, Not Your Bitcoin


View Profile
December 01, 2018, 04:00:43 PM
 #8

so checkpoints? Bcash already implemented this to prevent SV re-org the chain.

Take my word with a grain of salt; If you implement checkpoints you compromise from decentralization.
 
The concept of decentralization itself is another thing. After all those years it feels like "decentralization" is a subjective concept. Everyone is defining from different point of perspective.

It's true that someone needs to write the codebase and someone with sufficient knowledge needs to maintain, fix & improve it. It's not a one person job, so a group of people with enough knowledge starts maintaining, fixing & improving. That's already leading to centralization.

That depends on checkpoint usage. On SPV wallet, it's easy and powerful way to prevent manipulation by sending block/transaction information from chain on different chain/network. On full nodes, i agree with you and AFAIK Bitcoin Core already remove checkpoint feature as it's not really useful/provide much security,

But based on my understanding, what OP propose isn't checkpoint, but  feature to reject any blocks/chain which is 8 blocks behind with current block height.

rifiuti
Full Member
***
Offline Offline

Activity: 322
Merit: 101


View Profile
December 01, 2018, 04:48:43 PM
 #9

so checkpoints? Bcash already implemented this to prevent SV re-org the chain.

Take my word with a grain of salt; If you implement checkpoints you compromise from decentralization.
 
The concept of decentralization itself is another thing. After all those years it feels like "decentralization" is a subjective concept. Everyone is defining from different point of perspective.

It's true that someone needs to write the codebase and someone with sufficient knowledge needs to maintain, fix & improve it. It's not a one person job, so a group of people with enough knowledge starts maintaining, fixing & improving. That's already leading to centralization.

That depends on checkpoint usage. On SPV wallet, it's easy and powerful way to prevent manipulation by sending block/transaction information from chain on different chain/network. On full nodes, i agree with you and AFAIK Bitcoin Core already remove checkpoint feature as it's not really useful/provide much security,

But based on my understanding, what OP propose isn't checkpoint, but  feature to reject any blocks/chain which is 8 blocks behind with current block height.

If it would be feasible core devs would have done it already. I doubt if they never thought about this before.
aliashraf
Legendary
*
Offline Offline

Activity: 1316
Merit: 1009

Always remember the cause!


View Profile WWW
December 01, 2018, 07:03:33 PM
 #10

so checkpoints? Bcash already implemented this to prevent SV re-org the chain.

Take my word with a grain of salt; If you implement checkpoints you compromise from decentralization.
 
The concept of decentralization itself is another thing. After all those years it feels like "decentralization" is a subjective concept. Everyone is defining from different point of perspective.

It's true that someone needs to write the codebase and someone with sufficient knowledge needs to maintain, fix & improve it. It's not a one person job, so a group of people with enough knowledge starts maintaining, fixing & improving. That's already leading to centralization.

That depends on checkpoint usage. On SPV wallet, it's easy and powerful way to prevent manipulation by sending block/transaction information from chain on different chain/network. On full nodes, i agree with you and AFAIK Bitcoin Core already remove checkpoint feature as it's not really useful/provide much security,

But based on my understanding, what OP propose isn't checkpoint, but  feature to reject any blocks/chain which is 8 blocks behind with current block height.
If it would be feasible core devs would have done it already. I doubt if they never thought about this before.
I'm afraid It is not feasible to set such an artificial boundary. Actually it has been extensively discussed under the title of finality, bitcoin doesn't support finalization of blocks/transactions, finality. Implementation of checkpoints in client software is not best practice and there is a long history of attempts to avoid it. Basically the only finalized block in bitcoin is genesis block.

A far as I have realised, finalityis a backdoor for centralization and trust and is mostly advocated by PoS enthusiasts who are ready to retreat from cryptocurrency basic features to mitigate crucial PoS problems like nothing-at-stake flaw.

             ▄██▄
   ▄██▄      ▀█▀▀     ▄██▄
   ▀██▀▄  ▄▄█████▄▄  ▐███▀
       ███████████████
      ████████▀▄▄▄▀████
 ▄▄  ▐███▀▄▀██▄▀▀▀▄█████  ▄▄
████▀█████▄███▀▀█████ ██▀████
 ▀▀  ▐███▄███ ██ ████ █▌  ▀▀
      ▀████▄██▄▄███▀▄█▀
    ▄▄ █▀██████▀▄▄▄█▀█ ▄▄
   ████▀   ▀▀▀█▀▀▀   ▐████
    ▀▀       ▄██▄      ▀▀
             ▀██▀
⟩ ⟩ ⟩             ▄▄▄
  ▄▄▄▄▄▄▄▄▄▄█   █▄
 █           ▀▀▀  █
 ▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀
▄▀▀ ▄▄▄▄▄▄▄▄▄▄▄▄ ▀▀▄
█ ▄▀ ▄▄▄▄▄▄▄    ▀█ █
█ █ █       █    █ ▄
█ █ ▄▀▀▀▀▀▀▄▄    █ █
█ █ ▀▄▄▄▄▀▀▄▄▀▀▄ █ █
█ █ █   █  ██  █ █ █
█ █ ▄▀▀▀▀▄▄▀▀▄▄▀ █ █
█ ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ █
 ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
⟩ ⟩ ⟩       ▄████▄  ▄████▄
      ████████████████
      ████████████████
       ██████████████
        ▀██████████▀
██        ▀██████▀        ██
██▌   ▄            ▄   ▐██
███  ███▄          ▄███  ███
▀███▄ ▀███▄      ▄███▀ ▄███▀
  ▀████████      ████████▀
     ▀████▀      ▀████▀
     ▄   ▄▄      ▄▄   ▄
     ▀█████      █████▀
berkhatipoglu
Newbie
*
Offline Offline

Activity: 3
Merit: 9


View Profile
December 01, 2018, 09:04:27 PM
 #11



While selfish mining is quite bad, you need to make sure your solution don't create new attack vector such as possible history/chain manipulation for nodes that isn't online 24/7 (such as people who run full nodes only when they open their wallet). Nodes which online 24/7 would know which chain is real (not manipulated with re-org attack), but otherwise there's almost no way to tell the difference as both of them have high PoW amount. CMIIW.


I though about possible backdoors that can caused by this solution a few days before I open this post and I didn't find any (but there could be). When it comes to offline nodes they should connect to real chain when they need to connect to network because (with adoption of this protection) majority of nodes are keeping the healty chain. Only way to their node connect to a bad chain is that if attackers have more nodes than the whole network (AFAIK it's way harder than have more hash power on Bitcoin). With having more corrupted nodes attackers attack would be successful. This protection only makes the big reorg attacks harder, it can't protect fully.

so checkpoints? Bcash already implemented this to prevent SV re-org the chain.

Take my word with a grain of salt; If you implement checkpoints you compromise from decentralization.
 
The concept of decentralization itself is another thing. After all those years it feels like "decentralization" is a subjective concept. Everyone is defining from different point of perspective.

It's true that someone needs to write the codebase and someone with sufficient knowledge needs to maintain, fix & improve it. It's not a one person job, so a group of people with enough knowledge starts maintaining, fixing & improving. That's already leading to centralization.

This isn't a checkpoint. The exact opposite (on my opinion) this protection makes checkpoints unneccesery for reorg chains caused by selfish mining attacks because it rejects the reorged blocks. So there is no need to remine infected blocks from the last checkpoint. When it comes to decentralization it depends to your defination of it. I don't see any point that hurts the decentralization of network on this protection. If you see any please share with us.
Zin-Zang
Member
**
Offline Offline

Activity: 364
Merit: 11

Killing Lightning Network with a 51% Ignore attack


View Profile
December 01, 2018, 09:36:07 PM
Last edit: December 01, 2018, 09:50:35 PM by Zin-Zang
 #12

AFAIK Bitcoin Core already remove checkpoint feature as it's not really useful/provide much security,

Checkpoint Options:
1.  Checkpoint included in the Program code updated with new releases
     BTC has always used this and still does. Most Crypto coins also use this.
     https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.h
Quote
/**
 * Block-chain checkpoints are compiled-in sanity checks.
 * They are updated every release or three.
 */
   Program Code Checkpoints are very valuable, as they can block even a 51% attack from modifying the chain before the checkpoint.  


2.  Checkpoint Server that runs constantly,
     BTC has Never used this , Coins like Peercoins and some others use checkpoint server
     It centralizes control of the chain to the developer too much for many taste

3.  Rolling Checkpoints
     BTC has Never used this , this is what is being proposed in this topic.
     Coins such as Blackcoin , block reorgs of anything over 500 blocks
     So anything past the 500 can never be changed
     Nxt uses a 720 block rolling checkpoint
     * Advantages, No developer has control over these checkpoints like in a checkpoint server.*

 Cool

I was Red Tagged because Lauda Blows Theymos to get back on DT
The rest are just lauda's personal butt monkeys=> Hhampuz , Vod, TMAN , achow101
mixoftix
Member
**
Offline Offline

Activity: 104
Merit: 150

..


View Profile WWW
December 13, 2018, 12:53:45 AM
Last edit: December 13, 2018, 11:26:40 AM by mixoftix
 #13

there is a rule in my proof protocol that enforces the end user to include & sign the hash value of her/his last known block number - with one zero in its right digit (with some add/subtract) - in the payment order. now, 51% attacker can't use others' legitimate transactions in mempool for block fabrication in his hidden fork, and needs user's private key too (that is impossible, so needs to generate too many valid transactions for himself). therefore, when an invalid fork involves, based on situation, with this rule:

1- BEGIN: nodes could early stop a wrong payment in mempool / and a user understands that she has a wrong chain info
2- WITHIN: miners also could exclude a wrong payment from the process
3- END: receiver of payment also could ignore it, when she can't approve the hash value in her chain

and when a 51% attacker tries to broadcast a longer fork, the protocol checks the sum of coins-in-circulation among two/more forks. with same difficulty, the fake fork still needs to have the more coin-in-circulation to finalize the over-write process.

[this may sound funny, but rich users with just periodic circulating their coins in the blockchain could preserve their assets!! and an attacker with 51% of the hash power and huge amount of coin supply, better to hijack that broken crypto ]

avoiding hard coding of a checkpoint in the application, this would be a kind of decentralized-dynamic checkpoint system that I name it flash-back-field..

is there something wrong with this procedure?


من مست و تو دیوانه، مارا که برد خانه!؟
translation from Persian:
I am drunk and you are insane, who will take us home!? --Rumi
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!