Decrits: The 99%+ attack-proof coin - page 7.

sor.rge

newbie

Activity: 42

Merit: 0

Quote from: AnonyMint on June 12, 2013, 03:59:16 PM

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.

Quote

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.

Quote

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.

Etlase2

hero member

Activity: 798

Merit: 1000

Quote from: AnonyMint on June 12, 2013, 04:36:56 PM

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

7. Evilguy controls the network

Can you please fill in part 6 for me?

Quote

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.

AnonyMint

hero member

Activity: 518

Merit: 521

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.

Quote from: Etlase2 on June 12, 2013, 04:27:38 PM

Quote from: AnonyMint on June 12, 2013, 04:16:51 PM

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

Quote from: Etlase2 on June 12, 2013, 04:27:38 PM

Quote

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

By spending hundreds of thousands of decrits.

Not!

Quote from: Etlase2 on June 12, 2013, 04:27:38 PM

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

Quote from: Etlase2 on June 12, 2013, 04:27:38 PM

Quote

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

Etlase2

hero member

Activity: 798

Merit: 1000

Quote from: AnonyMint on June 12, 2013, 04:16:51 PM

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.

Quote

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

By spending hundreds of thousands of decrits. And then what, denying SHs consensus? We've gone over that.

Quote

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.

Sure if you introduce fatal flaws in my design, fatal attacks could be found. Luckily, I know how to design a better system than you.

AnonyMint

hero member

Activity: 518

Merit: 521

Quote from: AnonyMint on June 12, 2013, 03:51:07 PM

Quote from: Etlase2 on June 12, 2013, 03:44:20 PM

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.

Show where the entropy for that function is stored and who is decided that it is stored. Then you will see that you haven't solved the problem. You will see that decision can't be made without having the order randomized in the first place, without opening a hole for gaming. It is a chicken-egg problem.

In order to collect several joins/leaves (deposit transactions) to take away control from the single transaction targeting I have alleged, you would have to have CB, but still the last TB can game this function and knows it a priori. You (and mobodick) alleged upthread that the choices would be so limited so as to not be reasonably gamed, but attacker has many options into the distant future. The attacker only needs to target clustering his SHs in a consecutive order in any future CB so attacker will have numerous opportunities (every CB until that future CB), and then once he has all in a CB or nearly all, he can really take control over this function and assert continuous control.

AnonyMint

hero member

Activity: 518

Merit: 521

I must go to sleep and then will be offline for a day or more.

Have fun wasting your time.

I will be moving forward to making a better Bitcoin that can work and solves the real flaws I enumerated upthread. And it won't take me 2+ years to implement it (and then find out it can't work).

You guys are really slow...

AnonyMint

hero member

Activity: 518

Merit: 521

Quote from: sor.rge on June 12, 2013, 03:53:39 PM

Quote from: AnonyMint on June 12, 2013, 03:46:42 PM

That does not make any difference. I just wait until I can be the ID I need to be next in line.

Which ID do you want? How long do you wish to wait?

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

Quote from: sor.rge on June 12, 2013, 03:53:39 PM

Quote from: AnonyMint on June 12, 2013, 03:46:42 PM

And I do this for every next SH, and as I have more next SH, I gain more ability to do this more often. My attack grows power until I am always next.

No, the rate of honest SHs is fixed and does not depend on how many SHs you possess currently.

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

Quote from: sor.rge on June 12, 2013, 03:39:56 PM

Quote from: AnonyMint on June 12, 2013, 03:46:42 PM

Its output is known for all of future before I choose my ID as stated above. The only way for the output to not be known a priori, is to have some dynamic entropy. You can't escape the fundamental of the lack of ongoing entropy.

Sure it's known, and what? Suppose you know that you'll sign TB#35677 in the next day and TB#22789 in the day after that. What power does that give you compared to the case when you didn't know that? How to exploit that power?

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.

sor.rge

newbie

Activity: 42

Merit: 0

Quote from: Etlase2 on June 12, 2013, 03:44:20 PM

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.

Yes, my argument is exactly the same. Make arbitrary placement of ID cost a lot of money or time.

I just try to understand his point. After all, the issue is very simple. Much simpler than the other outstanding problems, like disconnected nodes.

AnonyMint

hero member

Activity: 518

Merit: 521

Quote from: sor.rge on June 12, 2013, 03:47:27 PM

Until you present a working attack on a very simple, fully specified by now algorithm which per your claim breaks the consensus completely. I want to see it, that's all. I've even offered to code your attack, just describe the algorithm in words.

I already did:

Quote from: AnonyMint on June 12, 2013, 03:46:42 PM

That does not make any difference. I just wait until I can be the ID I need to be next in line. And I do this for every next SH, and as I have more next SH, I gain more ability to do this more often. My attack grows power until I am always next.

sor.rge

newbie

Activity: 42

Merit: 0

Quote from: AnonyMint on June 12, 2013, 03:46:42 PM

That does not make any difference. I just wait until I can be the ID I need to be next in line.

Which ID do you want? How long do you wish to wait?

Quote from: AnonyMint on June 12, 2013, 03:46:42 PM

And I do this for every next SH, and as I have more next SH, I gain more ability to do this more often. My attack grows power until I am always next.

No, the rate of honest SHs is fixed and does not depend on how many SHs you possess currently.

Quote from: sor.rge on June 12, 2013, 03:39:56 PM

Its output is known for all of future before I choose my ID as stated above. The only way for the output to not be known a priori, is to have some dynamic entropy. You can't escape the fundamental of the lack of ongoing entropy.

Sure it's known, and what? Suppose you know that you'll sign TB#35677 in the next day and TB#22789 in the day after that. What power does that give you compared to the case when you didn't know that? How to exploit that power?

AnonyMint

hero member

Activity: 518

Merit: 521

Quote from: Etlase2 on June 12, 2013, 03:44:20 PM

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.

Show where the entropy for that function is stored and who is decided that it is stored. Then you will see that you haven't solved the problem. You will see that decision can't be made without having the order randomized in the first place, without opening a hole for gaming. It is a chicken-egg problem.

sor.rge

newbie

Activity: 42

Merit: 0

Quote from: AnonyMint on June 12, 2013, 03:30:59 PM

You keep trying to pretend there is entropy where there isn't. It is fundamental. More chasing your tail in circles trying to design away from a fundamental concept that can't be designed away from?

I'm not even using the word "entropy".

Quote from: AnonyMint on June 12, 2013, 03:30:59 PM

For how many more posts are you going to waste time talking in circles like a dog chasing his tail?

Until you present a working attack on a very simple, fully specified by now algorithm which per your claim breaks the consensus completely. I want to see it, that's all. I've even offered to code your attack, just describe the algorithm in words. Now you're in position where Etlase2 was some time ago, remember? He managed to give the algorithm after some time.

AnonyMint

hero member

Activity: 518

Merit: 521

Quote from: sor.rge on June 12, 2013, 03:39:56 PM

Quote from: AnonyMint on June 12, 2013, 03:30:59 PM

More circles or are we done yet with this nonsense?

No, we're not done yet, one more circle of nonsense is necessary, I'm afraid. Your SH application will not be accepted if its timestamp falls out of the current TB (how long was that? Make it a minute). And the timestamp doesn't decide your ID, it's the order of the timestamps. So that the earliest timestamp has ID=1, the one after ID=2 etc. If you want to have an ID of 1000000, you'll have to wait a until a million other SHs register, that's quite long.

That does not make any difference. I just wait until I can be the ID I need to be next in line. And I do this for every next SH, and as I have more next SH, I gain more ability to do this more often. My attack grows power until I am always next.

Quote from: sor.rge on June 12, 2013, 03:39:56 PM

If you want to game the system you have to give me the algorithm. You may be forgetting that I chose a very strong cryptographic random number generator which is difficult to "game". And also you'll have to explain what your attack should actually achieve.

Its output is known for all of future before I choose my ID as stated above. The only way for the output to not be known a priori, is to have some dynamic entropy. You can't escape the fundamental of the lack of ongoing entropy.

Etlase2

hero member

Activity: 798

Merit: 1000

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.

sor.rge

newbie

Activity: 42

Merit: 0

Quote from: AnonyMint on June 12, 2013, 03:30:59 PM

More circles or are we done yet with this nonsense?

No, we're not done yet, one more circle of nonsense is necessary, I'm afraid. Your SH application will not be accepted if its timestamp falls out of the current TB (how long was that? Make it a minute). And the timestamp doesn't decide your ID, it's the order of the timestamps. So that the earliest timestamp has ID=1, the one after ID=2 etc. If you want to have an ID of 1000000, you'll have to wait a until a million other SHs register, that's quite long.

If you want to game the system you have to give me the algorithm. You may be forgetting that I chose a very strong cryptographic random number generator which is difficult to "game". And also you'll have to explain what your attack should actually achieve.

Ukigo

jr. member

Activity: 42

Merit: 1000

Quote

It better not be deleted, or I will protest to the moderators. I have very important analysis in this thread, that I need to refer back to.

You can repost your valuable deposits on
ibiblio or whenever you wish...

or can we agree on "locking this thread"
and then starting new one w/o your sweet
presence ?

AnonyMint

hero member

Activity: 518

Merit: 521

Quote from: sor.rge on June 12, 2013, 03:25:41 PM

Quote from: AnonyMint on June 12, 2013, 03:12:22 PM

And who decides who was 1, 2, 3?

Timestamp ordering of the initial SH deposit transaction.

Then I can game the random number generator since the seed is known a priori before I set my timestamp. If you argue that another SH sets my timestamp, I argue that I can send my deposit transaction to one of the SH I control.

You keep trying to pretend there is entropy where there isn't. It is fundamental. More chasing your tail in circles trying to design away from a fundamental concept that can't be designed away from?

I repeat:

Quote from: AnonyMint on June 12, 2013, 03:12:22 PM

You keep pushing the problem to the same problem all over again. I already told you this, but you refuse to listen. See quote of myself below.

Quote from: AnonyMint on June 12, 2013, 01:32:20 PM

Quote from: sor.rge on June 12, 2013, 01:07:44 PM

Quote from: AnonyMint on June 12, 2013, 02:06:57 AM

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

Even if that solution didn't work out, there is no proof of this statement.

The proof is that the only way you get the necessary entropy is by having every peer compete to be first. Everyone other form of entropy has a point of failure that there is no decision, the consensus is required ad infinitum at every point where you design it away to another point.

For how many more posts are you going to waste time talking in circles like a dog chasing his tail? You can't design away the problem of needing consensus on the order but no one can make that decision (without opening a point of failure that can be gamed).

sor.rge

newbie

Activity: 42

Merit: 0

Quote from: AnonyMint on June 12, 2013, 03:12:22 PM

And who decides who was 1, 2, 3?

Timestamp ordering of the initial SH deposit transaction. In case of two peers applying to be an SH in the same nanosecond, lexicographical ordering of a hash of their deposit transactions decides. I believe this could not be an issue because only the same guy could realistically synchronize the timestamps with that precision, so he can only decide the distribution of a continuous sequence of IDs to his own SHs. But if you can exploit that in your attack, you're welcome.

To set the numbers straight, suppose that the honest SH count is a Poisson process such that there is one SH registration expected per hour.

AnonyMint

hero member

Activity: 518

Merit: 521

Quote from: AnonyMint on June 12, 2013, 03:34:35 AM

Quote from: firefop on June 12, 2013, 03:05:17 AM

Changing the proof of work to be asic hostile should be a non-starter, it's doomed to failure by it's very design. Nobody can design any digital process that cannot be accelerated by application specific processes. If you fix the proof of work process then someone is able to design an fpga or asic to follow that process.

Hmmm...(I had been thinking about this point already)

However perhaps we can shift the balance in favor of rewarding large quantity of RAM, so general purpose computers are on a more level playing field. If we can shift the time component to the performance of RAM and away from the CPU, then perhaps we defeat ASICs economically.

I just don't know yet if it is possible to make the random lookup the largest time component of the calculation. I will study more.

May want to stay within the CPUs local cache since it is highest-speed, or a combination of local cache and large RAM bound. Need to look at details of the economics.

Scrypt does what I wrote in bold above:

http://www.tarsnap.com/scrypt.html
http://en.wikipedia.org/wiki/Scrypt

Ukigo

jr. member

Activity: 42

Merit: 1000

@digitalindustry
Etlase will be later here

Don't talk to AnonyMint, he is feeding
dragons !

I got a feeling, that this topic will be
deleted someday... Wink

So read it, while you can.

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