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?
Topic: A Possible Solution To Re-Org Attacks That Isn't Inculudes Checkpoints (Read 369 times)
December 12, 2018, 07:53:45 PM
December 01, 2018, 04:36:07 PM
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. * Block-chain checkpoints are compiled-in sanity checks.
* They are updated every release or three.
*/
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.*
December 01, 2018, 04:04:27 PM
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.
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.
December 01, 2018, 02:03:33 PM
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.
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.
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.
December 01, 2018, 11:48:43 AM
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.
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.
December 01, 2018, 09:20:54 AM
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.
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.
November 29, 2018, 11:44:19 PM
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
Additionally, re-org with low block limit also vulnerable to 51% attack.
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.
November 29, 2018, 07:05:03 PM
Thank you to both of you for replying to my post.
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.
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.
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.
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
Additionally, re-org with low block limit also vulnerable to 51% attack.
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.
November 29, 2018, 02:28:28 PM
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.
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.
November 29, 2018, 12:33:03 PM
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.
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.
Jump to: