Decrits: The 99%+ attack-proof coin

[aaaxn]

No, that's not so unreasonable. It's not true, of course, it's an assumption, but in a highly connected network the broadcasts are quite reliable. You can try to amuse yourself by computing the probability of a message being not received by a peer when everyone is connected to N other peers, as a function of reliability of a connection and size of the network. Imagine that everyone passes the message to all neighbors once upon receiving it.

Now with not-always-online nodes there may be problems, but again these could be addressed to minimize damage to them.

I thought we are discussing 50+% nodes attack. With more than half nodes not cooperating in broadcast reliability is seriously affected. And reliability of transfer is far far away from time bounded broadcast.

[1715289654]

1715289654

[1715289654]

1715289654

[1715289654]

1715289654

[1715289654]

1715289654

[1715289654]

1715289654

[1715289654]

1715289654

[AnonyMint]

Ludicrous. If everyone could see everyone in the world, then there would be no corruption due to secrets. Now how do we relax that to reality.  

No, that's not so unreasonable. It's not true, of course, it's an assumption, but in a highly connected network the broadcasts are quite reliable. You can try to amuse yourself by computing the probability of a message being not received by a peer when everyone is connected to N other peers, as a function of reliability of a connection and size of the network. Imagine that everyone passes the message to all neighbors once upon receiving it.

Now with not-always-online nodes there may be problems, but again these could be addressed to minimize damage to them.

The point I was making by analogy (was not about the viability of propagating the info to those who are online rather) is the "always-online" is about as far from reality as you can get. There is no way to relax from those who are always online to those who are not always-online being able to know who to believe is telling the truth.

[sor.rge]

I tried explaining this to him, but he adamantly refused to accept it. There is no point in arguing with him.

Well, now there's an algorithm, we can get down to business. Like, calculate what a particular ID allocation strategy could give you, in what time and for how much money
One thing I didn't specify is the random generator to use. Lets settle for HMAC_DRBG from http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf initialized with the first post of this thread as it is now in UTF-8

[AnonyMint]

Randomized in this case means the selection order can't be known a priori when prospective SH peers chose their ID.

So the whole issue is based on the ability of SH to choose their IDs? Let their ID be their number in the SH sequence. So the very first SH has ID=1, the one who registers after him ID=2 and so on.

And who decides who was 1, 2, 3?

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.

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

I hear an echo:

I skipped the rest because it was all based on this.

I tried explaining this to him, but he adamantly refused to accept it. There is no point in arguing with him.

Because it is wrong as explained above.

[sor.rge]

I thought we are discussing 50+% nodes attack. With more than half nodes not cooperating in broadcast reliability is seriously affected. And reliability of transfer is far far away from time bounded broadcast.

Okay, okay, that's an assumption. This assumption is stronger than those made by bitcoin. It's a start. Before, I thought that it's impossible to know the truth at all by passive observation, now it turns out that you need to disrupt the communication severely to prevent that. If broadcast is not working at all, the network is split and the situation is hopeless. If it works, but slower than usual, then we need to evaluate how much slower it can be made, how this could be prevented, etc.

The point I was making by analogy (was not about the viability of propagating the info to those who are online rather) is the "always-online" is about as far from reality as you can get. There is no way to relax from those who are always online to those who not knowing who to believe is telling the truth.

At least there is a grade of how long were you offline. The nodes connecting for the first time ever are the extreme case. A node who missed one message is probably easier to handle.

[AnonyMint]

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

[sor.rge]

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]

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:

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.

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]

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.

[Etlase2]

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.

[AnonyMint]

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.

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.

[sor.rge]

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

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]

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]

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?

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.

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]

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:

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]

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]

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.

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

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.

[AnonyMint]

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]

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.

[Etlase2]

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.

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.

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.