Closed moazzamak closed 3 years ago
Slack log for discussion:
Moon (biz_network) [10:55 PM] Those all generally suffer from weak subjectivity. Also because probability is literally just that - probability - rejecting potentially legitimate chains in the case that you are on the orphan chain will end up downing your node until you manually rebuild to the actual highest chain (at which point you will accept a Sybil'd LRA chain anyway). @mak Basically those are both weak solutions that other chains have considered and those who go with them still have the weak subjectivity issue and new nodes coming online as well as clients are vulnerable to Sybil attacks, at which point you end up centralizing your chain to trusted nodes, killing the point of the chain in the first place. PoW has not been solved yet :grin:
mak [10:57 PM] that's a valid point. Though that's why I include a "trust" parameter that each delegate builds over time for their own chain. I don't know how to solve the sybil attack scenario yet
Moon (biz_network) [10:58 PM] But your individual node is only relevant when the majority of nodes run trusted code. That's the point. You can't just say "lol ignore Sybil attacks" because it's not only easy to do one but it's the fastest and most effective way of wrecking a non-PoW network. You can't just pretend PoS' biggest problem doesn't exist lol
mak [10:58 PM] but quite frankly that's an issue even in the current network and affects exchanges and users
Moon (biz_network) [10:59 PM] PoW doesn't suffer from Sybil attacks because you only need to be fed the honest chain from one node. You don't have to trust that node. The client can do all the verification on its own. Can't do the same with (D)PoS which is the fundamental problem nobody has been able to solve.
mak [10:59 PM] I'm not ignoring sybil attacks. Just saying I don't know how to solve them yet and will spend some time looking into it later.
Moon (biz_network) [10:59 PM] I know. I'm saying attacking the problem WITHOUT considering Sybil attacks is irrelevant. Because all attack vectors for PoS are propagated via Sybil attacks. And Sybil attacks cannot be mitigated with PoS. At the end of the day that is the ultimate problem that needs solving. With PoW one honest node proves the other are dishonest. PoS has no possible way to do that.
mak [11:01 PM] I'm not giving up on that yet I think the issue of Sybil attacks is above the concensus layer
Moon (biz_network) [11:02 PM] It doesn't matter though because you can't prevent them
mak [11:02 PM] and therefore we should be looking at solving it above the concensus layer
Moon (biz_network) [11:02 PM] Don't think so
mak [11:02 PM] via creating the right incentive structure
Moon (biz_network) [11:02 PM] You need to assume that your network is always Sybil'd
mak [11:02 PM] that discourages sybil attacks
Moon (biz_network) [11:02 PM] There's no such thing though How can you discourage taking over the network and controlling it economically?
mak [11:02 PM] i.e PoW discourages sybil attacks via sunk cost due to mining power bills
Moon (biz_network) [11:03 PM] Sybil attacks have nothing to do with mining They're free on BTC too. "free" as in negligible The reason they don't work has nothing to do with cost
mak [11:03 PM] not quite. like you said one honest node can prove all dishonest nodes wrong in PoW
Moon (biz_network) [11:04 PM] You can indeed sybil BTC but it will not lend you any financial gain because you can't overwrite the chain with a Sybil attack In order to make that true on PoS you literally need a PROOF that your chain is better, and WORK is the only tangible thing that can do that.
mak [11:04 PM] with AIP25+27 you can't rewrite the honest chain either
Moon (biz_network) [11:04 PM] You can
mak [11:04 PM] the problem is at exchange and customers end
Moon (biz_network) [11:04 PM] LRA wrecks you. I've been brainstorming a solution for years now and the only reasonable solution I came up with is a hybrid system. It functions with a very low PoW as long as one delegate remains honest.
Jarunik [11:05 PM] the fundamental problem is that you have no proof like the POW difficulty ... so you got nothing unfakable in dpos
Moon (biz_network) [11:06 PM] It's very power efficient and still DPoS. My solution is still technically PoW but it reduces the effectiveness of hash attacks by a factor of 50x But pure (D)PoS cannot solve the problem. Again, if you solve it you will literally become a millionaire and Vitalik will personally be your date to the ball.
Jarunik [11:06 PM] to solve it differently then POW you would have to find something that proofs that it took you time to create a block (whitout the possiblity to fake timestamps and such) (edited)
Moon (biz_network) [11:07 PM] And if it takes time it means someone can use more power instead of time than you to overtake it There's no such thing as real timestamps though :slightly_smiling_face: @Jarunik You can only prove that one thing happened before something else
Jarunik [11:07 PM] yeah that is what i want to say
Moon (biz_network) [11:07 PM] You can't prove it happened at an exact date
Jarunik [11:07 PM] there is not "time" in the logical equation as you can't proof time well at least not directly doh ... you know what i mean
Moon (biz_network) [11:08 PM] I'm happy to discuss ideas on it since this is the area I am most interested in when it comes to blockchains. But in all my research there has been nothing even remotely close that could solve the PoW problem. @mak The best I could get is a hybrid system that leverages the strengths of both. And only requires honest nodes to have 1/50th of the hashpower of dishonest ones
mak [11:09 PM] anyways. I'm still going to be spending time trying to figure out if sybil resistance can be developed without PoW
Moon (biz_network) [11:09 PM] (So 51% attacks must be 99% attacks and you must own a delegate)
mak [11:09 PM] I understand your points
Jarunik [11:10 PM] maybe votes should need POW ^^
mak [11:10 PM] but my point is that even though we can't completely stop sybil attacks if we can make it expensive enough it would serve as a good deterrent
Moon (biz_network) [11:10 PM] Then you give people another attack vector @Jarunik Votes don't do any sort of consensus so it doesn't do much @mak You can't though because no amount of banning matters when MY fake nodes are more than your real ones. My nodes don't adhere to your software rules And normal nodes accept my perfectly valid chain blocks BTC can still be Sybil'd. It is not protected from Sybil attacks It is protected from FINANCIAL damage from Sybil attacks But it would be relatively trivial to actually Sybil Bitcoin
Jarunik [11:12 PM] i think there will never be a "true identity" that can be proofen ... so you can always create sybil attacks
Moon (biz_network) [11:12 PM] Exactly
mak [11:12 PM] and that's exactly what we need for DPoS
Moon (biz_network) [11:12 PM] That doesn't exist lol
mak [11:13 PM] I mean no financial damage
Moon (biz_network) [11:13 PM] Yeah you can't
mak [11:13 PM] as a result of sybil attacks
Moon (biz_network) [11:13 PM] But you cannot stop them, even in PoW So you have to work around the assumption that the network can always be sybil'd BTC doesn't fail in a Sybil attack All (D)PoS does in combination with LRA Whatever solution you want MUST work when any normal node can find the right chain from 0 without trusting others. That solution exists for PoW, but not for any PoS system (edited)
I just realized that if the AIP23 is implemented then the cost of executing a sybil attack is increased significantly because every delegate registered on the Ark main chain's delegate market would be acting as a relay. So as the ecosystem grows and more chains are added and assigned a token value the number of delegates would also increase and therefore the cost of carrying out a sybil attack on main chain as well. As for bridge chains using the delegate markets they can add checkpoints into main chain using liquidity gates to secure themselves.
My summary for more light weight check points which would also address LRA.
We should discuss how to reduce the potential harm of long range attacks. Some regular checkpoints of blocks that are hard-coded in the client could shorten the window of long range attacks to the time frame between the last checkpoint and now. As checkpoints would most likely have to be included in the core code they would create more centralisation. We will not solve weak subjectivity. But a more transparent way to agree on the history through checkpoints might be beneficial.
Stale issue message
Discussion for: AIP 27
Chris asked that I should separate the long range attack additions that were created for AIP 25 as a result of the open discussion should be made into a new separate AIP so here it is. Let me know your thoughts.