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

You may not be able to control the seed, but you can see what the outcome will be with that seed, which means you can run it many times until you get something that you like. Hashing is a very cheap operation, cheaper still with server clusters targeting such activity. If you can see 4 billion futures, you only need to select the one that pleases you the most. So transaction activity can't be used for determining the next order.


We can't predict the advancement of computing power, we can limit the amount of currency available at any one point.

There is a clear issue I have been avoiding in regards to letting any kind of adjustable seed determine the next order which was the reason I wanted to use deterministic signatures originally and changed from the deterministic function idea that I did have as the earlier design-case. I do not want to go down that path yet because I do have potential solutions, and it does not have anything to do with SH security. But the less futures EvilCorp can see, the better.

In any case, Ed25519 can be required to be the SH signatory function. It has deterministic signatures, and these can be used to generate entropy. Without requiring a deterministic DSA, each SH could include a structure such as this { signature of CB hash, symmetric encryption key }, encrypted with symmetric encryption key. The encryption key is revealed in the next CB, and it is a verifiable, unpredictable entropy unless EC controls 100% of SHs. Even without deterministic signatures, EC is in the same situation where he must exclude his keys to change the order, and this will result in severe penalties and EC has only the limited number of futures equal to the number of shares he controls, and modifying it will cause him to lose money. But this introduces a significant delay...

The seed could be the hash of all transaction in the previous CB. You can't control the value of a hash, that's a major point of hashes: you can't find the content of a transaction which, when concatenated with the other transactions, will result in the given hash value. So you can't control the seed even if you control a part of the transactions.

Furthermore, you have very limited control of IDs of your SHs. They're assigned by the order of their appearance. And they're decided before the seed for the next CB is decided.

Since there is no control of the random generator, you'll have to resort to bruteforcing it. In order to prevent that, I proposed fixing all the seeds completely and not using any "entropy" by your terms. While this complicates the attack significantly, it's still not bulletproof. Maybe it's easier to deal with the possibility of bruteforce search of a favorable seed. If the proportion of shares that you own is p, to have n consecutive TBs you'll have to enumerate (1/p)^n seeds. For n=360, an hour of disruption, and p=0.9, a 90% attack, you will need to enumerate 29695907506101728.772544490140544 seeds on average. We can live with that.

To analyze, we need to know the randomization function.

The trivial randomization function does not randomize and simply places each new SH at the end of the order. Thus obviously the evil SH can add a contiguous block of SHs and cause delayed transactions, but far in the future (not in the next CB).

I suspect that perhaps any randomization function you can think of, will have a pattern that can be exploited similarly. But I am not yet sure of this.

For example, a random number generator that uses the input entropy from current CB as a seed, can thus be gamed by creating a seed which enumerates the dishonest SHs for the next CB, if the dishonest SHs were planted with IDs that enumerate from that seed.

Continuous control? Sure it is possible if this gaming can always place a dishonest SH as last to sign a TB in every next CB, if the randomization function is not the trivial one.

So potentially Decrits could be attacked with a hard fail with less than 51% of the peers being dishonest.

Very far upthread I had accepted Etlase2's contention that a randomization function with the input entropy of SH join/leaves would sufficiently prevent gaming of the order of TB signing. Because I thought that all SHs would chose their ID before the input entropy would be known, thus they could not game the randomization.

However, we come full circle to my original complaint at the start of my participation in the thread, which is that the SH to sign the last TB in a CB will know the input entropy for the randomization function for that CB, and thus can insert SH deposit transactions to alter both that input entropy and add eligible SHs. What mischief can be achieved with this capability?

I assume this randomization function chooses the SH order of TB signing only for the next CB period, and thus the only deterministic outcome that can be controlled is to alter that input entropy (by inserting deposit transactions) to try to maximize the number of dishonest SHs chosen for signing TBs in that next CB period.

Can we quantify this probability?

I obviously misspoke above (because I was tired). At 51%, Bitcoin is a hard fail and can be forked.

And you are apparently correct that there isn't a hard fail fork vulnerability in Decrits. We were wrong about that, see my prior reply to Etlase2.

Nevertheless I don't know if I like the tradeoff that Proof-of-Share presents, with outages (transaction delays) at much below 51%.

I think you are entirely missing the point. I will make another post to describe the attack again.


I can't possibly estimate the limits of for example fractional reserve banking. Apparently runs into the $quadrillions, if you count bond derivatives.


Yup. And that may be just enough to destroy trust in the system and/or leverage up other modes, such as getting others to pay you to not delay their transactions, i.e. cartelization.

It is hard for me to predict the clever ways attackers will leverage this security hole. Surely in more ways than we can enumerate.


I can gain resources outside of the system, not just tx fees.

Plus I don't like have a currency that is subject to mischief of transaction delays by those who can steal Decrits by hacking other accounts, etc..

This is insecurity and at much less than 51%.


You are worried only about continuous control. I am not setting the bar that high. Intermittent outages is very bad for finance.

I don't have time to analyze another non-Proof-of-Work system, but it is great eMunie plans to go live soon, and if it gains any real monetary value, then it will be attacked and so that will confirm the requirement for dynamic entropy in secure decentralized system.

Proof-of-Work is provable secure up to the 51% attack, these other systems are not.


And you continue to entirely miss the point.


I never said it was. Decrits is subject also to minority attacks that can delay transactions and disrupt the system in the ways I have stated upthread.


But less than 51% is provably secure. Decrits is not.


Okay here I must admit an error that I (and sor.rge?) made upthread.

I was thinking (and perhaps sor.rge was similarly confused?) that prospective SH had to sign a CB in order to be eligible to be selected for signing TBs in the next CB. Thus we saw the threat of a 51% attack where the majority fork would not allow any honest SH sign the CB and thus not allow any honest SH ever be eligible to sign TBs in the majority fork.  I was thinking this way perhaps because I was thinking how my Proof-of-hard disk would work in the same conceptual manner (where there is no share to do a deposit tx).

Now I see (obviously) that SHs will send a deposit tx to become eligible to sign TBs and this eligibilty persists for numerous CB periods.

This does not remove my assertion that minority attacks can delay transactions and disrupt as stated.

Is there some other way that a 51% attack can not just delay transactions, but actually fork the blockchain and prevent honest SHs from participating? The 51% can not ignore the TBs from the 49%, because  if the 49% fork will not ignore the TBs from the 51% fork, then it is clear which fork is not honest. And the 51% can not exclude the deposit txs from the TBs of the 49% (because only the TB signer can alter the contents of a TB). Thus there is no way for the 51% attack to exclude the other SHs from joining nor prevent them from signing TBs.

However, I maintain that Proof-of-Share is subject to targeting contiguous blocks of TBs and thus significant delays of transactions by even a small minority of the SHs.

So appears Proof-of-Share trades a complete failure at 51% for partial failure at less than 51%.

I am not convinced that is a good tradeoff.

looks like the e-muni dudes are going beta with something like this https://bitcointalksearch.org/topic/ann-emunie-emu-not-a-bitcoin-forkclone-call-for-beta-testers-220530 (i signed up to the forum) - i wonder why Anony wasn't spamming them with the "BUT ITS NOT RANDOM!!!!1" over there?  

Bitcoin's 51% works like that: you create your own blocks in secrecy, however many you want, while you have the 51% advantage, and then release your chain. It will be longer than the honest one, so all peers will abandon the honest one and take yours, with whatever you put there. Not only you have continuous control of TBs proportional to your hashing power advantage period duration (which is the cost of the attack), but you can reverse the already accepted transactions, which you can't do in your weak attack on decrits.

But we are not in the future, we're now and you said you want to place the next TB under your control. The only way to do this is to spend money or wait. You can't wait because then you'll lose the next TB. So you need to spend money continuously. That little program can simulate that.
If you wait a really long time until the current ID count is favorable, your percentage of the overall SHs will be lower, because all the IDs which you've skipped are not yours.

Ok then. Now we need the computation of how much you will gain exactly. If you come up with precise number, like I can gain this much (percent) for every day of continuous control, we could see how much you'll need to spend to achieve that. Then we will see if there's a situation where the attack is profitable.

Yes, for a limited period of time growing with the cost of the attack.

Not really. You may be able to gain some resources, but how much they are, compared to the considerable cost of an attack, is an open question.

Agreed. But let's assume that the locking time is much greater than the time of possible continuous control. You can't recycle your funds which are being unlocked to prolong the attack.

"Ok why not let the network randomize the order - ?

1. A join has been requested -

2. Signal sent to any online client - "please send a completely random function"

3. Base it on time one time and on the function another time.

4. Out of the response stream have that randomly generate a function.


Plus i have s simple question for you, explain what the worst case scenario is if its not 100% random.."



He didn't seem to like that ?

I got put on the ignore list , couldn't be because now the network decides the order and the point he was trying to control is spread now on all the nodes?

Even if it's essentially meaningless , he still didn't answer it.

Translation: evilcorp can't do anything to modify the result of a deterministic function. Ergo, the entire line of horse doodie about entropy is completely irrelevant. AnonyMint has now admitted he is utterly flawed in his presumptions.


And the circle of troll continues. Back to "well they can delay transactions" as if this is somehow even remotely the same as a 51% attack. A 51% attack in bitcoin allows an evilcorp to delay transactions indefinitely and prevent anyone honest from being able to profit at all from the resources they put in the network. A 51% attack in decrits means evilcorp can delay transactions, on average, a smidgen longer than a 50% attack. It does not have any affect on the profitability of the honest SHs, because--as described in the OP--transaction fees are distributed based on reputation, which can only be gained over time. It has nothing to do with what txes were included in your TB. It also means that if you frequently pull join/leave shenanigans to even attempt to get more TBs in a row, the profitability of evilcorp per amount invested in the network is reduced because because of its lower average reputation (not even considering early withdrawal penalties), and more importantly, the honest SHs are the beneficiaries.

AnonyMint is a gold-standard troll and nothing more.

Both Decrits and Bitcoin are subject to 51% attack, but Bitcoin is not subject to this attack where a minority attacker could gain a contiguous range of TBs and disrupt the network for a period of time. In Bitcoin, the probability of the next TB being an attacker is proportional to the percent of the peers the attacker controls, thus there is never 100% contiguity of control unless attacker controls 100% of the peers.

In an orthogonal attack vector, Etlase2 claims that Bitcoin is vulnerable to disruption by DoS attacks due to the existence of mining pools, but I disputed that upthread.

Fantastic - you know what - that is a win for me.

To the other readers -

I was just thinking to my self , i really want to put this guy on ignore so this project can move forward.

As i said :

always be wary of someone that says  " never , no" to a new idea .

because from a failure will come another idea , that’s how information works.

but i didn't Ignore him because i wanted to see if he said anything different .

but i guess now i can .

but you know what,  i'm still not going to .

i suggest Etlas start to talk about implementation . forget a white paper , try to get someone to make the first blocks.

digitalindustry has been placed on ignore due to incoherent posts.

says the guy that i just read at least 9 pages worth of you saying the same thing... and wanted to try to educated me about the 78 year cycle or some other 1900's style economics.

Ok why not let the network randomize the order - ?

1. A join has been requested -

2. Signal sent to any online client - "please send a completely random function"

3. Base it on time one time and one the function another time.

4. Out of the response stream have that randomly generate a function.


plus i have s simple question for you, explain what the worst case scenario is if its not 100% random.

That 66% is not necessary. I only need to buy a small minority of the SH (if the total # of SH is much larger than the # of TBs in a CB) and place them contiguously in a CB period, to disrupt the network for a significant period of time. During that time, I control the network and I can use that temporary (but significant enough in duration to cause serious pain to) control to leverage up my financial power to gain more control. I can apply that leverage both inside and outside the protocol of Decrits, to game financial opportunities both inside (e.g. take all tx fees during that period) and outside (e.g. charge an extra fee to those who want add a SH or send any transactions during my control period).


Incorrect. No matter what randomization function you choose for #4, I can game it to place my SH in a contiguous order at some CB period in the future. Because the input entropy is deterministic in some way.


I explained in this post and the prior one (in reply to Etlase2) that having contiguous control leads to potential opportunities to gain more income.

Also I explained that just disrupting the network might bring financial return in some other way, such as raising the value of a competing currency or winning a war by shutting down transactions for periods of time.

Also with the power of banking of savings. If I can get other Decrit holders to deposit their Decrits in my bank, I can spend (invest) them interim, while they are not being spent by the owner. The SHs have to profitable and return on investment, else no one will be a SH.


I already explained why I don't need to control all of the SH to disrupt and attack.

I already explained how I might gain considerable resources.

And you can't increase the deposit locking time too much, otherwise honest SHs will be disincentivized from participating.

Your posts are meaningless, because you don't understand the technical issues. You are just adding noise here.

If you don't understand the critical importance of the random input entropy in cryptography, then you have no business posting here about this.

+1 to that

before i slept i was thinking , why does he insist it has to be random .

thanks for the explanation Etlase, so now i know that , the doing of this , i'd like to contribute -

 

When your IQ is only 120 or so, you need a zillion little examples to become convinced of the abstract fundamental that convinced me weeks ago.

How many of your examples will I need to refute, before you will finally understand the fundamental insolubility I explained upthread?


At least you admit you can't think abstractly at my level.

1. Imagine there are 10 SHs.
2. Imagine evilguy controls TB number 10 the consensus point.
3. Evilguy adds another 100 SHs via a deposit tx during his TB.
4. The SH randomization function is (Put new SH at end of list)
5. There are now 110 SHs in the exact order as before, plus evilguy's additional SHs at TB 11 through 110.
6. nothing to do here
7. Evilguy controls the network from TB 11 through 110.
8. During TB 11 through 110, evilguy can deny others from adding SHs, he can use earnings from tx fees (and perhaps extortion due to ability to deny transactions) to add more of his SH from 111 forward, thus increase control of the network.

Even if evilguy does not have complete control of all future TBs and/or lets the order of SH wrap around to revisit others who previously had a turn, he has control over a contiguous block of TBs, and this gives power to delay transactions for significant periods of time. Some competing currency owners or even during a war, someone may have an incentive to disrupt the system even at what appear to be losses in monetary terms.

It doesn't matter how you change #4 the randomization function, I can still find a way to game the input entropy, because it is not randomized but rather deteministic in some other way. This is why only Proof-of-Work has the necessary entropy, where peers compete to be first for each TB anew by (all of them continuously) supplying uncertainty over who will be first.


I am referring to controlling a entire CB block period of TBs so as to have more control over the input entropy to a more sophisticated #4 randomization function you might choose.

With that simple #4 you have above, the evilguy doesn't need to control all of the TBs in a CB period in order to accomplish the attack. If you improve the randomization function in #4, then it gets more difficult to accomplish the attack but it can still be done by exploiting the many opportunities in the future (especially as the # of good and evil SH is 1000+ as this provides more future CBs to target as opportunities for obtaining contiguous blocks).