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

Okay I worked through all the possibilities as explained upthread and below, and have concluded that Proof-of-Consensus can't work. I will now be stopping all further work on this dead-end. And all those who have a well functioning brain stem will stop this now.

As I wrote from the very beginning of my involvement in this thread (which is why I had stopped work on my Proof-of-Hard Disk version of Proof-of-Consensus on May 13, 2013, before Etlase2 emailed me to check out his idea), there is no way to get the randomized entropy to randomize the order of which peers can sign the TBs. Upthread we had discussed the impossibility (network overload scenarios) of allowing all (potentially unlimited if attacker spams) SHs to sign within a CB, so Etlase2 offered the clever solution of using the signatures on the prior CB to randomize the order and we convinced ourselves that this could not easily be gamed if we used a function to modulate the self-chosen hash keys of the SHs with this random entropy.

But the problem is that there is no way to have consensus on who has signed the CB. If peers (wanting to be SHs on next CB) will separately broadcast their signatures, then who decides which were broadcast within the time limit and compiles it into a CB? If those peers will instead sign a CB that was signed by a prior peer until all who want to sign have signed it (within a deadline), the problem is who decides the order that they sign?

There is no possible solution. This is why only Proof-of-Work is viable for achieving consensus.

So we are done. End of story. STOP.



Along with the need to sign the CB periodically to gain the randomized entropy I mentioned above, I also admitted this possibility of double-spends in my prior post. And both of these reasons are why only the 51% fork can be the consensus. And thus why I have concluded that 51% attack is possible (in any form of P2P decentralized consensus, not just money). But we can't even accomplish the required randomized entropy so as I stated above Proof-of-Consensus does not work. This is a dead end.


Then can't get the randomized entropy for deciding the order of signing.


Those assumptions won't provide the required randomized entropy for deciding the order of signing.

"As far as qualifications, I've been programming since I was about 12, but only as a hobbyist. After learning about bitcoin I went on a two year study of economics, cryptography, network protocols, byzantine fault tolerance, and so on while discussing and refining the various proposals that have eventually led to this one, the 6th, which I think is as close to perfect as an imperfect system can get. So, no qualifications really. Just a vision with the ability to come up with the design implementation whenever I need to dig ."



Nobody I know understands human economics better than I do , so I may be able to help you , sometimes things are hidden right in front of you , I will read the  topic , I will need the binary translated in some parts but.

This.

Also, your assumptions about how this will work are exactly that... assumptions. You dependent on someone everyone not being stupid or malicious enough to legitimately break your system. The primer on how to do it either through buying power or collusion are right there (and both of these scenarios will actively ignore any disincentives).

Bad idea is just bad.

i like what is happeing on this topic - i'm now going to read it -

I will throw some hash poer at this. could be worth a lot

This can be made impossible by spending the money on this wallet and not including this transaction. On block N the attacker broadcasts a transaction which spends all money from his wallet, but doesn't include it in his CB, using 1 CB "grace" period. On block N+1 he announces and includes 10 transactions involving money on the same wallet. The honest guys can't include them since they already confirmed the money spent, and the bad guy wins by 9 transactions. If you didn't observe this happening and you just see the blocks, you can never tell whose version is honest.

Then you'll have to explain how the attack works, under the new set of assumptions, namely: the broadcast delivery is guaranteed in bounded time and everyone is constantly online. Or wait for the system to be implemented and try to implement the attack. At this point I don't see such an attack.

Incorrect, because every fork can pick up this transaction in its next CB. The evil fork has to broadcast the CB else the fork doesn't exist in public view.


This doesn't solve a non-problem that doesn't exist with transactions. It does nothing to solve the 51% attack with signing of the CB. Signing of the CB is necessary to decide the order of peers who can sign TBs.


No it accomplishes nothing as I already explained. We are walking in circles going no where. The 51% attack can not be avoided by any decentralized design.

I want to stop wasting time and move to things we can accomplish on fixing other Bitcoin weaknesses.

Things are as not as simple, because if we count the branch with more transaction as the honest one, then the attacker can introduce his own transaction which wasn't broadcasted, and win. So in practice you don't know whether it's a transaction which has been dropped or added by an attacker. The time limits resolve this.

The proposed resolution of this is by timing. If you introduce some precise time windows when a message must be broadcasted, then the nodes who are always online can decide whether the protocol was followed. The protocol can be modified such that if an SH decides to not include a TB in his CB, he must declare that immediately at the time of that TB. In this way CB is built continuously and not just decided last minute, so there can be no surprises at the time of CB. Therefore anyone who observes the process can decide if TBs are being withheld or being dropped dishonestly. Etlase2 had a more elaborate solution above.

True. But the ability of the honest always-online node to see through 51% attack with just passive observation is already a good start.
Still the assumption of guaranteed broadcast message delivery must be taken.

I wrote briefly about my relative qualifications at the following link:

https://bitcointalksearch.org/topic/m.2441624

I will now address all discussion since my prior post in this thread.

1. I thought we already decided that excluding transactions was not a possible attack (unless 100% of peers are evil), because the honest fork would be readily identified as including all transactions (including those from the evil fork). The worst that could happen is a transaction could be delayed by one CB period, if the evil fork withheld propagation of TBs (to non-evil peers) until the CB (where it can't be withheld any more and still be a public fork) or if the evil fork included transactions from the honest fork one CB later (so as to be not readily identified as the evil fork).

This delay could allow for a double-spend, where conflicting forks have different order of which of the double-spend transactions was first.

2. The only attack vector is that evil peers will not let non-evil peers sign their CBs and evil peers could create one or more forks in addition to the honest peers. There might even be multiple factions of evil peers who don't want to share tx revenue and thus exclude other peers. So the problem is how to identify which fork is the consensus in order to properly award tx fees?

In light of the above, the proposal since my prior post appears to distill to that peers who attempt to sign a CB and are ignored by a fork, will see that fork as dishonest if propagation error/delay can be ruled out.

The problems are:

a. Evil forks might occasionally allow other peers to sign, thus obfuscating whether propagation or evilness is the cause of missed CB signatures.

b. The honest peer's opinion is only valid for himself, and can't be proven to the world without 51% consensus.

No matter how you slice it, you can not avoid the 51% Rule of Decentralized Agreement.

This is not a crippling conclusion. We should move forward on improving upon Bitcoin. We will not be able to make a decentralized currency that avoids the 51% attack.

As far as real name, several people already know it (including anonymint), but at this point I don't think it's necessary to make it public. I don't plan on being another satoshi though. There is nothing dishonest about my design that would cause me to need to hide my identity.

As far as qualifications, I've been programming since I was about 12, but only as a hobbyist. After learning about bitcoin I went on a two year study of economics, cryptography, network protocols, byzantine fault tolerance, and so on while discussing and refining the various proposals that have eventually led to this one, the 6th, which I think is as close to perfect as an imperfect system can get. So, no qualifications really. Just a vision with the ability to come up with the design implementation whenever I need to dig further.


No white paper... there are many things that have been addressed in various ways that I see as weaknesses in bitcoin or money in general. I'd rather just implement it. Thanks for the support, though.

Some numbers for perspective:

Assume 4,000 tx/s [visa levels], assume every tx only pays the min tx fee of 0.01 decrits, that is 1.262B DCR per year that runs through the security system. This is not improbable 10 to 20 years from now I don't think. At least for whatever cryptocurrency has become the most popular.

For each SH to receive a 2%, non-compounding, rate of return if a share costs 3,000DCR, there will need to be DCR631m (1.262b/2, since 50% goes to CN) / DCR60 shareholders, or 10.5 m SHs supported by visa-like tx levels. 2% non-compounding is rather low, but the return can be invested in other ways, and that's 10.5 m SHs at minimum tx fees. 10.5 m x 3,000 is 31 billion DCR invested into just the SH side of network security. (As a side note I have considered an algorithm to increase the share price if the SHs total starts getting insane, 7 m or so "should be enough for anybody".)

CNPs will need significant bandwidth to run a visa-like connection (estimated 160Mbit/s, quite reasonable 10 to 20 years from now), but if there are say 1 million CNPs, that is 630 DCR per CY or 53 DCR per month, enough on its own to pay for a high-speed connection today, could easily pay for the costs of upgrading to a top-tier package with some profit on the side. Remember, little to no inflation in decrits, hopefully anyway. Performing a 50% attack on the CNPs would require 150m DCR (assuming 150 DCR deposit), and a 50% attack really is useless against the CNPs. CNPs that are being devious can be pretty damn obvious (to be detailed later), so clients will stop using them and will stop using their ID codes in txes, so they won't get paid, so the attack is nothing more than a waste of time. This is part of the subtle and not so subtle dichotomy between the CNPs and the SHs, and further enhances the network's foundation.

And every single client of the network could still detect any attack on it for about 1-2kB/s of bandwidth--an amount that might be free to everyone by that point if meshnets exist. Anyone who has any value in the network will be incentivized to watch it. And it is very cheap to do so. *Every single person* doesn't have to watch it though, they can be pretty sure if several million other people agree that this happened that it is probably true. If you haven't seen the pyramids in Egypt, does that make you believe that they do not exist? Where are the people who say it isn't true? Employees of the NSA?

Of course when the network is smaller there will not be several million people, but the same rule applies on a smaller scale. Those who have value in the network will be incentivized to watch. Someone can throw away 30 billion USD to try taking it down, but if the people who care are watching, the attack will be ineffective and the network will have gained that value at the very least by redistributing that fiat attack among the decrits users' fiat holdings (by selling some when the price was too high). If it encourages an economic shift towards decrits, then decrits permanently appreciates over fiat.

Efficiency and decentralization is paramount in every aspect of the design. With massive decentralization comes massive resilience. And a sane monetary system controlled by the people to boot.

Counterpoint: If the attacker already has this type of power, he doesn't need anywhere near 51% to control the network. Compare bitcoin with it's 10-20 nodes with the network view. An attacker need only disrupt a couple of them to cause complete chaos. In Decrits, he will need to disrupt massive portions of the internet.

You are going to have to be clearer. I can imagine several different things that you mean by "timeouts" so instead of covering them all in a jumbled mess, I'd prefer clarification.

I explained why this is ok--I'm sure not very well though. A PTB will effectively stop the attack on the network, meaning there will not be any 51% attack, but just an attack on perhaps 5-20 honest SHs (the attack you and anonymint brought up as potentially being more critical--making small forks). But those SHs that were attacked can not be denied consensus, because the evil chain must include the PTB or it is screaming network takeover attempt. A PTB should essentially be thought of as a critical stop to network activity. Until a node sees a chain with it included, it should not transmit that chain, and and anyone using the network should not make transactions until they see a chain with that PTB.

It sort of puts EvilCorp on the spot. Stop the shenanigans or go ahead and fork. Everyone that is currently watching the network will see the fork forming. It won't happen instantly, it has to be as a factor of time. If they continue to fork, more and more people will see the untrustworthy network for what it is. Everyone watching knows of the attack. More will start asking for TB data, more will start seeing the fork.

Even if people are late to the game, they will receive the missing TBs assuming they are not isolated. To actually destroy the shares of the honest network, it must pretend as though the honest SHs refuse to reach consensus. While a TB from 2 hours ago could have been made 10 seconds ago, a new node will keep a counter from the time *it* saw the TB. Honest SHs must still add section 1 to the chain regardless of how late it is (unless it is so late that it is past the absolute deadline where shares are destroyed). This is what brings consensus. So anyone hopping on prior to that deadline will start counters. If there is a fork, the honest half will have all, or mostly all of the signatures in consensus that any node could see (including but not accepting). The dishonest half must exclude those whose shares it wishes to destroy.

If it does not exclude those, they only receive a strike. It is an attack vector, but it is not a critical one as I said. If they include the PTB then start another attack, the untrustworthiness will build more (it would have to go down over time). So if they do not want people to know who all of the dishonest SHs are and provide a long period of time for everyone to find out, they must settle for giving a few, random honest SHs strikes.


I really don't think this can be countered by any "well an attacker can control this or that view of the network". If they have the capability to do something like that, any defense for anything is impossible. It is essentially saying "you have fixed every single thing but complete and utter control. Your currency is 99% attack proof." And I say "thanks, that's what I been sayin brah"

They aren't. They can only decide the truth for themselves.

And how these always online nodes are going to prove that they are telling truth?

I think this is a step forward already.

If we assume reliable propagation of the broadcasts within a certain time limit, then the nodes who are online continuously can indeed distinguish the honest chain in that attack. At the time of CB, they will know who was really on time, i.e. whose TBs appeared within allowed delay. If somebody withholds their TBs and at CB time claims that the others were late, the always-online nodes can compare that with their historical records. If somebody doesn't include the TBs of others, the always-online nodes can check if those TBs were broadcasted in time, in which case the party who omits them is the wrong one.

Some problems still remain with this attack:
1) The assumption of reliable time-bounded propagation. This can be disturbed in various ways by the attacker.
2) Race conditions with the timeouts. The malicious peers can release the critical information when its time is running out, in this way dividing the opinions of the observing nodes. Some of them will believe the message is late, others that it was on time. This confusion potentially will open possibilities for other attacks.
3) The nodes which didn't observe the attack, and only see the resulting fork, will still not know whom to trust. Both parties will claim that the other didn't release their TBs on time or didn't accept legitimate TBs which were released on time.

i call bullshit as always, and reminds you of our bet.

even the tl;dr i say tl;dr to.

how do you identify a bad SH, when the majority is bad? Ask the bad ones? who says what is good and bad in the network? you? me? some heuristic method that can easily be cheated? 

This idea is still in the formulative stages, so bear with me. I have mentioned it a few times but wasn't totally confident in how it would work--but I also admitted that. This is one of the last ideas I came up with before writing this proposal--and so had the fewest blanks filled in. I'm still not 100% confident in this idea, but it probably has promise as a starting point. The caveat is that it does rely on honest network propagation. But propagation is so cheap in this design and is encouraged in several significant ways, and if the reward is a 99% attack proof network as long as most people pay attention...

Structure of a TB is two sections:
1. (block #, hashes of prior unacked block(s), "potential" CB hash ), signature
2. (part 1, tx activity, ongoing CB hash), signature

I have mentioned previously that TBs are a valid network view within a 10 TB window. As long as TB 54 is acknowledged by TB 64, no transactions in 55-63 can override one in TB 54. This is to allow for quick face-to-face confirmations for small txes. Originally the idea was that a SH would receive a soft strike if his TB was not accepted within that window, and then section 1 only needs to be added to the chain (saves data, section 2 won't affect anything anyway) at a later time to confirm that this SH did indeed sign the potential CB and is agreeing to consensus.

Now, I mentioned this in only one post somewhere, but instead of giving a soft strike then and there, give another 100 TB grace period where only section 1 gets added, but no soft strike. This would essentially allow a 15 or so minute grace period for network propagation. It leads me to come up with a deeper game-theoretic idea for this to deter minor trolling of this mechanic, but it's tangential at the moment. After that point a soft strike will be given. But the same data (section 1) is used to eventually add the signature data to the chain without it being necessary for the SH to do anything. Assuming the network is honest.

The longer this TB has been on the network but has not been acknowledged in the chain, the more untrustworthy the network becomes from the point of view of each node that maintains the consensus (again, 1kB/s @ 5 mil SH--it is the section 1s of the TBs). Want a formula? Fine.

Untrustworthiness = number of TBs since each TB was missed

So if 1 block goes unacknowledged for 100 blocks, it is 100. If 1 block goes unacknowledged for 100, and a second block for 50, the total is 150. Each node will have a slightly different idea of this untrustworthiness. However, the 51% EvilCorp must continue to deny honest SHs because they are acknowledging those section 1 TBs of the portion of the network it is trying to attack.

Say a number of 500 should be ringing all kinds of alarms on all clients paying any whit of attention. (This is something that needs test scenarios.) Then give a number larger than that to allow for others to catch up on untrustworthiness, say 1000, for honest SHs to create a Potential TB. This TB will essentially "call out" the situation and create an honest fork starter point. It will acknowledge the missed TBs--and they will not take soft strikes--and all the other SHs will receive soft strikes in this potential TB. This threshold could be user defined (we couldn't really force it anyway) so that it is more difficult for EvilCorp to even predict how the honest SHs will react.

An honest network must include this into the chain even if the block was maliciously created. Those peers in the block will be given strikes--though most already would have anyway for being missed and arriving late. The honest chain includes an evil PTB but does not accept it.

An evil network must also include it and not accept. And in doing so it can only give those peers strikes, it can't exclude them from consensus. But it could already give them strikes anyway. If the evil network does *not* include it, it is a beacon flashing all over the place to *stay away* for anyone that receives this PTB.

Either way, SHs that agree with the PTB will continue that chain even if they have minor doubts (threshold of say 300--this is still significant). This could be done automagically for the initiating SH with the 1000 point figure as a guideline. At this point the 51% attack must stop, or anyone monitoring the network even for a few minutes knows which chain is honest, because the evil network must keep denying the existence of new honest TBs (in which case the attackers that were used get strikes). Even a threshold of 10 is probably very suspicious, but it is an idea that needs testing. Honest SHs that get caught in the evil network because they were not monitoring long (shame on you) can learn that the evil network is continuing to be evil by denying TBs, and then acknowledge the honest chain in the next CB. All of the evil SHs can too, but the effect can not be used to repeatedly disrupt the network as they are receiving strikes. These strikes will probably be of the "medium" variety. I have been using the term "soft strikes" for minor problems implying that there may be more heavy-handed ones. It is something I need to develop.

So everyone monitoring the network (assuming wide propagation) knows which network is "more honest" by this mechanic. Either everyone gets back together to play nice, or a fork permanently emerges. Honest SHs caught in the dishonest network have a chance to reconcile, so no one honest can be hurt too badly by not sufficiently monitoring the network. And from then on everyone will be on extremely high alert.

Essentially, this system will let a 51% attack get nowhere near that point. To accomplish a true 51% attack, it must be carried out over the full 10 CD consensus period. Throughout this period, the EvilCorp must continue to deny honest SHs, and they continue to add to the untrustworthiness of their network. Unless they can suppress tiny amounts of data in the wild with insane accuracy--in which case they could simply kill the network via that mechanic without needing any SHs if they have so much control over the internet (need meshnets to become a reality to defend against this).

The incentive for a SH to put himself on the line is the fact that the untrustworthiness of the network is so high, if he is honest he is likely to be excluded anyway and receive a strike. Perhaps there could be a specific incentive if his PTB is continued too.

I guess sorrge was right about calling it trust. It is different to get out of my head and into electronic ink. There needs to be an avenue to fork without necessarily causing a catastrophe. This design leaves open the possibility of an undo button. Honest SHs can still come back at the cost of evil ones coming back as well. But  they have not accomplished anything other than receiving a strike and disrupting the network temporarily. The failure is not critical which is critically important. And it is not easily repeatable without significantly more investment. How much will depend on how clever the strike system can be (combined with early withdrawal penalties and other things).

And from the very first minute or two of this attack anyone partaking in a large face to face transaction will know something unusual is up. It depends on how reliable the network is on average. These are things that are really hard to predict ahead of time, but it is important for defining transactional security.

Sorry for the super long post, but I feel like if I don't recap a lot of things, the mechanism will not be clear.

TL;DR VERSION: Each node watching the network keeps an internal idea of how untrustworthy the network is based on TBs it has seen that are not included in the TB chain. At some high trigger point, a SH node will create a different type of TB that will call to exonerate the missed TBs and penalize the offending SHs. This will create two potential future CBs, allowing the network to fork if necessary. If the evil 51% of SHs continue down the forked path, they generate more untrustworthiness that more people will see as the consensus period continues. The fork can be resolved by taking strike penalties. Honest SHs may be unjustly penalized (but not permanently) if they have not been monitoring, but it is the risk they take by not even monitoring the TB section 1 data. Clever penalties can make this attack very costly or ineffective while barely hurting the honest network. This premise does rely on wide propagation of all network data, but the alternative is an attack where EvilCorp has incredible control over the internet and can prevent that propagation, in which case it could simply cause the network to fail anyway without all the shenanigans.

After this, I have slow down the discussion. I really am spending too much time on this. A wiki makes much more sense, and it will allow me to update where vulnerabilities are found, or to make things clearer over time rather than murkying up a thread. There is too much crap jumbled in my head that causes me to make mistakes. And I have the urge to be protective and defensive. Combine these things and well... but there are a whole bunch of other things that still need input too, and I had promised in earlier proposals to promote an open discussion of all the ideas prior to ever launching the currency. Being paranoid is not the way forward, even if AnonyMint has given me some reason to be.

Have you reconsidered at all your opinion of the currency distribution scheme AnonyMint? I made a pretty significant point about purchasing power lost being voluntary. If you want "in", start offering goods and services for decrits. There has to be a stable platform for commerce.

I have briefly looked over your other thread, may comment on it later.

I will wait for you to post on this before commenting further.

Even if there is a 51% attack, that does not destroy the possibility of improving upon Bitcoin.

I thoroughly expect there to be a 51% attack in any form of fungible money. I wrote an entire article to explain why.

No Money Exists Without the Majority

https://bitcointalksearch.org/topic/no-money-exists-without-the-majority-226033

Ok I'm a tard and even I forget and miss things. There is a deeper issue that Anonymint has raised that isn't as simple as 50% vs 100%. I shouldn't post while distracted. Most of my last couple of posts are not a correct description of how the attack I believe Anonymint/sorrge propose is defended against.

It requires a rehash of several concepts that are in the thread, but I will put something cohesive together later. I apologize for misconstruing it.

Edit: as I said I'm posting from a phone and takes awhile, but you acknowledged the problem ax while I was posting.

Have you written a white paper, or is the OP the closest thing you have?

I like the idea of innovative currencies, I will be including Decrits in my list of new innovative currencies and (attempting) to explain a little bit about it.

Keep up the good work, the future of crypto currencies depends on people like you.