Decrits: The 99%+ attack-proof coin

[AnonyMint]

The attacks are possible because the input entropy is controlled by the last TB in a CB and the targeted order is known into the distant future of all CBs. Whereas with Bitcoin's Proof-of-Work, the entropy is reset on each TB and all the peers competing anew on each new TB. That is like night versus day in relative security.

but still the last TB can game this function and knows it a priori.

He can "game" it by spending (hundreds of) thousands of decrits. Then he must do this again at the next CB point.

WTF? He only has to spend the normal deposit transaction to position his SH at a desired ordered choice among the available choices given by your function.

Once he has control over a CB, he then has complete control over the options and begin to target consecutive CBs, then has continuous control.

To get his SH to sign all the consecutive TBs in a future CB, choose one in distance future, so have many CB opportunities interim to target that distance CB.

I am assuming of course that SHs are plentiful and there are 100s or 1000s of CBs before a SH gets a repeat turn (unless he leaves and rejoins).

The attacker only needs to target clustering his SHs in a consecutive order

By spending hundreds of thousands of decrits.

Not!

And then what, denying SHs consensus? We've gone over that.

If you control all the TBs, you control what goes in the consensus (as well as getting all the tx fees).

and then once he has all in a CB or nearly all,

With your pompous presumptions that 100% consensus won't be reached each CB.

If you control all the TBs, you control what goes in the consensus (as well as getting all the tx fees).

[1714739812]

1714739812

[1714739812]

1714739812

[Etlase2]

WTF? He only has to spend the normal deposit transaction to position his SH at a desired ordered choice among the available choices given by your function.

Ok, since I really have no idea what argument you are making, let us make this really basic:

1. Imagine there are 10 SHs.
2. Imagine evilguy controls TB number 10, the consensus point.
3. Evilguy adds another SH via a deposit tx during his TB.
4. The SH randomization function is (Put new SH at end of list)
5. There are now 10 SHs in the exact order as before, plus evilguy's second SH at TB 11.
6.
7. Evilguy controls the network

Can you please fill in part 6 for me?

If you control all the TBs, you control what goes in the consensus (as well as getting all the tx fees).

Oh hey look, more ideas from some other design that AnonyMint has in his head that can be attacked, because there just must be a way to attack it, and if the design doesn't have an attack, then we'll add to the design so that it does. You are unbelievably immature.

No one should pay any attention whatsoever to anything you have to say. You are some kind of sociopath.

[sor.rge]

The next one in the order of the random generator, which I a know a prior as you admitted below.

Say you have money to buy 2000 shares and there are 1000 honest ones, so it's a 66% attack. You buy one, the probability of you to not be the next is 1000/1001. If you've lost, you buy another, now the probability is 1000/1002. And so on. How long do you think you're going to hold the TBs on your side?
The answer is 2000 TBs on average: https://ideone.com/qnSuyP
You can play with different values yourself there on that website. After these 2000 TBs, for 10s TBs that's 5.6 hours, you fund is locked, and you can't control the things anymore. What did you gain? If that's the decrits-killing attack, I'm not impressed.

If I can always be next, I will always be next. The more often I am next, the more often I can get the ID that is next (or not so far from next).

No, because you'll quickly deplete your funds, they'll all be locked in shares that you deposited while gaming the order of TBs before. When you'll have no more money, you'll have no further control over the order of TBs, but the honest SHs keep arriving.

Because I know it before I do my deposit transaction, so I can target being next (or not so far from next). The more I populate my SHs nearer together in time, then more I can control the TBs and control my ID and thus control that I am nearly always next with my SHs.

Only assuming the infinite ability to create SHs, which you can't - there's simply not enough money in the system for that, it's a finite amount at given time.
Increasing the share amount and deposit locking time will make the power even more limited.

[AnonyMint]

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?

WTF? He only has to spend the normal deposit transaction to position his SH at a desired ordered choice among the available choices given by your function.

Ok, since I really have no idea what argument you are making, let us make this really basic:

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.

If you control all the TBs [in a CB period], you control what goes in the consensus (as well as getting all the tx fees).

Oh hey look, more ideas from some other design that AnonyMint has in his head that can be attacked, because there just must be a way to attack it, and if the design doesn't have an attack, then we'll add to the design so that it does. You are unbelievably immature.

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).

[digitalindustry]

I have already stated that all it takes is a deterministic function to be applied to the current order of SHs. The only way to affect the outcome of this function is continually add or remove SHs from the equation. Adding costs significant amounts of money, subtracting has penalties in both power over the system and early withdrawals. There is no infinite possibility scenario for the attacker to perform. New joins will be added in a deterministic manner that has nothing to do with the public key.

Sor.rge, do not allow yourself to be derailed by what AnonyMint thinks is necessary due to his lack of competence.

+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 -

 

[AnonyMint]

I have already stated that all it takes is a deterministic function to be applied to the current order of SHs. The only way to affect the outcome of this function is continually add or remove SHs from the equation. Adding costs significant amounts of money, subtracting has penalties in both power over the system and early withdrawals. There is no infinite possibility scenario for the attacker to perform. New joins will be added in a deterministic manner that has nothing to do with the public key.

Sor.rge, do not allow yourself to be derailed by what AnonyMint thinks is necessary due to his lack of competence.

+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 -

 

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.

[AnonyMint]

The next one in the order of the random generator, which I a know a prior as you admitted below.

Say you have money to buy 2000 shares and there are 1000 honest ones, so it's a 66% attack.

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).

You buy one, the probability of you to not be the next is 1000/1001.

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.

If I can always be next, I will always be next. The more often I am next, the more often I can get the ID that is next (or not so far from next).

No, because you'll quickly deplete your funds, they'll all be locked in shares that you deposited while gaming the order of TBs before. When you'll have no more money, you'll have no further control over the order of TBs, but the honest SHs keep arriving.

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.

Because I know it before I do my deposit transaction, so I can target being next (or not so far from next). The more I populate my SHs nearer together in time, then more I can control the TBs and control my ID and thus control that I am nearly always next with my SHs.

Only assuming the infinite ability to create SHs, which you can't - there's simply not enough money in the system for that, it's a finite amount at given time.
Increasing the share amount and deposit locking time will make the power even more limited.

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.

[digitalindustry]

I have already stated that all it takes is a deterministic function to be applied to the current order of SHs. The only way to affect the outcome of this function is continually add or remove SHs from the equation. Adding costs significant amounts of money, subtracting has penalties in both power over the system and early withdrawals. There is no infinite possibility scenario for the attacker to perform. New joins will be added in a deterministic manner that has nothing to do with the public key.

Sor.rge, do not allow yourself to be derailed by what AnonyMint thinks is necessary due to his lack of competence.

+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 -

 

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.

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.

[AnonyMint]

digitalindustry has been placed on ignore due to incoherent posts.

[digitalindustry]

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.

[AnonyMint]

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.

[Etlase2]

6. nothing to do here

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.

this gives power to delay transactions for significant periods of time.

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.

[digitalindustry]

"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.

[sor.rge]

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.

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.

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.

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.

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

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

I already explained how I might gain considerable resources.

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.

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

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.

[sor.rge]

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.

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.

[digitalindustry]

looks like the e-muni dudes are going beta with something like this https://bitcointalk.org/index.php?topic=220530.0 (i signed up to the forum) - i wonder why Anony wasn't spamming them with the "BUT ITS NOT RANDOM!!!!1" over there?  

[AnonyMint]

looks like the e-muni dudes are going beta with something like this https://bitcointalk.org/index.php?topic=220530.0 (i signed up to the forum) - i wonder why Anony wasn't spamming them with the "BUT ITS NOT RANDOM!!!!1" over there?  

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.

6. nothing to do here

Translation: evilcorp can't do anything to modify the result of a deterministic function.

And you continue to entirely miss the point.

this gives power to delay transactions for significant periods of time.

Back to "well they can delay transactions" as if this is somehow even remotely the same as a 51% attack.

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.

A 51% attack in bitcoin allows

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

A 51% attack in decrits means evilcorp can delay transactions, on average, a smidgen longer than a 50% attack.

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.

[AnonyMint]

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.

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.

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

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.

Ok then. Now we need the computation of how much you will gain exactly.

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

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

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

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 already explained how I might gain considerable resources.

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.

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%.

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

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.

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

[AnonyMint]

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.

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.

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%.

[AnonyMint]

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?