Topic: Decrits: The 99%+ attack-proof coin - page 11. (Read 45356 times)

I am confused. Good guys cannot acknowledge evilcorp TB's because they can have tx conflicting with their chain. If block 2 contians tx "send all coins from A to B" and block 3 contains "send all coins from A to C" then branches effectively diverged and cannot acknowledge each others TB.


I'll look but I think we can agree that in distributed network there is no way to know if node did not receive previous TB on time vs it just acts as it didn't.

Confirming or acknowledging there is no difference. Each TB is essentially a separate entity that governs a 10 sec window; the chain is required to keep tx times very low as the consensus can only be continuously updated if each new TB has acked all of the changes to the network state as of this moment.

If evilcorp is confirming the TBs of others, it is accepting the network as everyone sees it. There is no way around this. If it is not confirming the TBs of others, they will have a bad consensus block on the next round.

As far as how long to wait... I know you don't want to hear this but it's explained earlier in the thread. I had admitted several times I did not have a fully fleshed out idea for this, and that it would have to be based on running some numbers vs potential attack vectors. However I did post the beginnings of what I think is a really good solution all around... Somewhere.

I am currently posting from a phone and won't have regular Internet again for a few more days, so it's difficult to link and I can't work on the wiki. I *would* like to be able to convince at least one person that the system is viable though before embarking on that.

Good chain somehow acknowledges (it's not same as confirming it as I understand?) evilcorp TB without actually confirming it and doesn't loose consensus? Why evil corp cannot do it? And please answer other question (about missing TB) in my previous post.

Because then they are continuing consensus. That is why in an earlier post I said they have to do it in secret.

If they maintain a separate chain throughout a CB, the good chain is the only chain with 100% consensus. When evilcorp starts signing the next round of TBs with a CB hash of their 50% or 90% consensus, everyone can immediately identify the chain as fraudulent because it is not the hash of the chain with 100%. It is by far the easiest way to lose scads of money.

And can you point me to where I've used obvious recently? I used oblivious...

What do you mean by good chain acknowledging evil corp chain TB?
Why cannot evil corp do the same then?

Unless I'm misunderstanding you, it sounds like you are trying to create some attack where the 51% can stop the 49% from signing. This is the exact same attack as trying to drop the TBs of others, because the prior CB is signed in each TB. This will not create a fork unless we get into 99%+ territory or EvilCorp is incredibly, incredibly stupid.

Let's say EvilCorp is incredibly stupid. Let's say evilcorp has all odd SHs and honest guys have all evens. So it's a 50% attack for the sake of argument.

EvilCorp chain: 1->3->5->7->9->etc. - 50% consensus
Good chain: 1->2->4 (acknowledging 3)->6 (acknowledging 5) - 100% consensus

This is the easiest attack to divert. There isn't even any particular defense for it because it is irrelevant. But perhaps I am misinterpreting you. Feel free to clarify.

Hey Etlase,
I think you use word obvious too much? And you say that implementation of what activity is suspicious is trivial... well ask spam filters engineers.
Anyway why don't you cut this misunderstandings once for all and create page with detailed and precise algorithm of your core consensus system? And by algorithm I mean real algorithm which have step by step instruction for every possible case. Can you do it?

And while we all wait for this algorithm I have question that you probably already answered, but ... this algorithm page would be really helpful wouldn't it?

You say SH's take turns to create TB. What happens when some SH makes his TB with large delay or this delay is created during propagation. How long next SH wait before it consider previous TB missing? What happens if he will receive previous SH's TB after he already created his treating previous TB as missing? What does next SH do? What happens if such situation extends to more than one SH and 3rd or 4th SH thinks that previous TB's are missing?

This is not the 51% attack that was described in the prior post. In the 51% attack, only the evil peers sign CB and thus only they can sign subsequent TBs in that majority fork. There won't be any honest peers even signed up for the randomized signing selection.


You have not described the previously described 51% attack.

There need not be any withholding of TBs nor CBs for days, merely not allowing any CB signatures (I am not talking about TB signatures!) from honest peers on the evil CB.

And what algorithm can we use to determine that the minority fork with less CB signatures is more honest? I am repeating myself. Please go re-read the prior posts and provide an algorithm.



You are not addressing the 51% attack I described. It has nothing to do with the propagation of TBs.


The above paragraph is not an algorithm.

Except to perform this attack, EvilCorp must control some significant portion of consensus. It must be able to deny honest TBs from the chain, which it can only do if it controls many TBs in a row. AnonyMint and I went over this in significant detail.

If TB 3 is honest, and TB 4 is evil and he does not include TB 3, and TB 5 is honest, he includes TB 3 and TB 4 and EvilGuy accomplishes absolutely nothing. No fork is created. Trying to create a fork in the open can not work.

If a large group of SHs collude in secret to create another chain that includes the honest TBs but makes it look as if the honest side is excluding theirs, they must not acknowledge consensus with this collusion of peers for days. You aren't going to do this without the entire network-using population noticing. Then they release their chain with "full consensus" and expect anyone to believe them. It doesn't look like they have the better chain because none of their chain is actually confirmed by the other side, even if it includes the honest sides' signatures. How can those signatures confirm TBs they did not see?

But that rightly only gets us back to there being more than one chain.

So we have one chain made in secret that no one knows about, and one public chain that has been used for days while the evil consensus has built up. Every single person who has monitored the network knows which chain was public and available. Every single person. This requires 1kB/s at 5 million SHs. We are already assuming 5 million SHs, how many more million or billion people are paying attention to the network at this point? No decision needs to be made for them, they already know the honest chain. They will not accept some chain days later that attempts to make what is already public knowledge look as if it was the secret chain.

So the only people we have to worry about are those who have not monitored the network and are completely oblivious to the world's monetary system takeover attempt (hehe). They will be notified any time they go to use the money by everyone who has paid attention. Unless you can get Starbucks, Amazon, Walmart, your local mom & pop store, to all agree to be nefarious and collude against the few people who have been oblivious.


It isn't trust, it is consensus. eMunie is a sybil attack's playground. And "already" implies that it came before decrits, which it did not.


It is in the OP and I have reiterated it throughout the thread. CNPs will drop suspicious TBs. Any honest peer monitoring the network will. Thousands of TBs mysteriously appearing days after their consensus window probably qualifies as suspicious. The exact implementation is just a detail. The network is easy and efficient to monitor. EvilCorp can't fool anyone monitoring the network.

So for someone who is oblivious, I ask again, do they believe Amazon, Best Buy, Walmart and their friends regarding which network is honest, or do they go with the nefarious group that isn't saying anything? The only point that matters for an oblivious person is when they go to pay for something which requires another party. Will this person also be oblivious? How many oblivious people does it take to cause a problem? Can we have an entire network of oblivious people that EvilCorp can fool? Because that's what it takes to be successful in this attack. But they're only fooling oblivious people. And they lost their entire deposit on the honest chain.

Let me recap what I understood so far about the attack resolution.

We (the honest people) know that there is a fork. Suppose we also know that it was created intentionally (although this point can also be attacked). We also know the two sets of peers who disagree. Each party claims that the other didn't sign in time, or didn't sign the right thing. We keep both, as opinions. They must be synchronized to some extent, otherwise we will observe one of them doing something strange, detect the fraud and dismiss their branch (algorithm pending). However they will not be fully synchronized, since in their respective branches they didn't loose the money while their adversary did. So the branches will gradually diverge. But everyone will be cautious to accept the questionable money from the disagreeing peers, because their branch can be eliminated at any time, so the divergence will not be a big problem apparently. It will load the systems though, because they all need to check everything twice for both branches.

The problem, as AnonyMint has already stated, is that there seems to be no way to end the situation. The malicious peers may keep creating branches until they become unmanageable.
I understand the "trusted party" proposal, however it's not a solution because the trust is not formalized within the system. If we are to accept trust-based resolution, then the whole security of the system relies on this trust mechanism, therefore we need to look more into that. BTW there is a proposal for trust-based coin on this board already, it's called eMunie.

You keep shuffling around some details which are just repeating the same flawed logic. There is no possible decentralized metric for peers to know which one of these forks is the honest one.

You have presented no algorithm for deciding which fork is the honest one.

How long are you going to play this shell game with us?


Agreed the system can record multiple ledgers. This is irrelevant. You must address the fundamental issue above.

Except that it solves the propagation weakness. Now there *are* two defined chains, regardless of any evilcorp shenanigans. The second chain will not be lost. If evilcorp controls 90% of the CNPs, that means 1 in 10 of them is carrying the honest chain. It won't take very long for any non-network node to find the missing portion of consensus.

I have some serious game-theory adjustments to the simplistic 90% attack as well to make it far less viable than it even already should seem. But those are details that need not be explained until implementation, because they are not relevant to showing the futility of this attack.


Except that you have refused to see the reasoning behind each aspect until you have discovered the worthiness of it on your own. And you have repeatedly derailed me in trying to get you to see the overall picture. The implementation details are irrelevant until you do. So it is your own fault.


But as long as they can't prevent the fork, they can't take control, so none of this is necessary or worrisome unless you expect evilcorp to control the entire view of the network. With the efficiency of the system, this borders on completely impossible. Even peers who only maintain SH sigs (that 1kB/s for 5 million SHs figure I previously described) will know who caused the fork. On a sufficiently large network, evilcorp will have to fool the entire world.

There are layers of interconnectivity that must be unraveled here. You have tried to reverse engineer the system and have not been successful. I tried to get you to stay on one course and failed because I let you bog me down with less relevant details. I won't make that mistake again.

Evil signing peers may only propagate to their evil CNPs. Thus you've solved nothing. That is why I asked for your specific magic algorithm.

I knew already vaguely what you are proposing and I am asking for the specific algorithm. You force me (and others to waste time) with guessing games. "Playful" is entirely disrespectful of our time.

Basically your idea must have something to do with separating the peers that sign the TBs and CBs from the propagation of them to other peers.

We can require in the protocol that signing peers are not allowed to propagate to other signing peers, thus they can not withhold. All communication must be done through these other CNP-type peers. But we can't stop them from controlling the CNPs they wish to propagate through. And there is no way to require them to propagate through every CNP.

Shuffle the cards incessantly, but there will always be a 51% Rule of Decentralized Agreement.

If I am wrong, prove it by stating an algorithm. I hope I am wrong.

So I'm making a list.  Who are you and what are your qualifications for being a lead dev on an crypto?  Please let us know.

Edit: you can answer here or here. https://bitcointalksearch.org/topic/who-are-you-who-are-your-cryptocoin-devs-225643.

Cheers.

I was intending to be playful and get you to start making the connection yourselves, because it seemed that progress was being made.


51% of the CNPs does not accomplish anything.

Purposefully and arrogantly evasive. Address the specific points.

We have stated why we don't think that matters. And we have asked you to tell us an algorithm that refutes our statements.

As if the cartel can't get 51% of the CNPs or what ever you propose for specific architecture for propagation. Tell us this magic algorithm please?

The next task you gentlemen are realizing is to separate the security from the propagation. Somewhere, I think I mentioned this. Oh yeah, in the OP. Start moving on to that system.

Yes I also had this idea today. It's even worse than a single attack. The evil cartel doesn't need to make a visible "disaster" by dropping a lot of people at the same time. It will just chop them off in small batches, each one too small to be "heard" by the masses.

Ok Etlase2 has clarified that minority forks should be incorporated into an algorithm to decide which is the honest fork.

The only decentralized algorithm I see for potentially detecting this dishonest majority fork is noting it excludes many CB signatures from the minority fork. However the minority fork will also be missing CB signatures from the majority fork. So how do we know algorithmically that the majority is dishonest?

Sorry I just don't see an algorithm here. This is not a hostile intent, I am merely searching for the truth on this matter.

Besides even if you can resolve the above, then I can propose an attack where the majority creates a plurality of minority forks.

Sorry I don't think you can escape from the 51% Rule of Decentralized Agreement.

Okay now we are making progress.


Okay that is a crucial statement.

You propose a system that has multiple truths, thus potentially double-spends. But you propose a resolution below...


Good point, but it requires the minority forks continue to be extended by some peers, otherwise the majority fork could exclude transactions and there would be no minority fork to prove they were excluded.

The evil fork CBs could be withholding TBs from the minority forks or at least the minority forks could be forced to be one CB delayed on including these, and including the TBs from the minority forks. This doesn't refute your point.

Assuming the minority peers can identify the dishonesty of the majority fork (which I questioned in my prior post), the other key question is do the minority peers have an incentive to continue the minority fork?

Detection and incentive may be the same mechanism. If they can try signing the CB of majority fork, and if they are continuously ignored and not allowed to sign the CB that has the most signatures, and if many CB signatures (note I am not referring to TBs here) in the minority fork are not included in the majority fork CB, then they should have an idea that the majority CB is ignoring the minority. Also this means they can't get paid transaction fees (nor minting if we use proof-of-hard disk) in the majority fork, so they must stay with the minority fork to earn anything.

So perhaps there is a decentralized way of finding dishonesty?

But what is the specific algorithm to trigger this decision by autonomous minority peers?


But it would be much better if we don't rely on an external point-of-reference, in fact I assert this is a security attack vector, because it would require the users setting some flag in their peers or some centralized server doing it. What about my decentralized method above for detecting the attack?


Agreed retaining multiple forks is a crucial design statement. Now we need to decide if we can avoid double-spends and mulitple truths in a decentralized algorithm. See above.


So we penalize the evil peers who do not sign the minority fork CB, since they can't all sign it, for if they did, it would no longer be the minority.

So this is the importance of proof-of-share, that we can destroy it as you've stated above and upthread (unlike proof-of-hard asset since the asset can't be destroyed by an algorithm).