Decrits: The 99%+ attack-proof coin

[AnonyMint]

Can we quantify this probability?

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.

[1715577859]

1715577859

[1715577859]

1715577859

[1715577859]

1715577859

[sor.rge]

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.

[Etlase2]

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.

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.

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.

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

[AnonyMint]

I would very much like to be wrong. It would be wonderful to not waste the resources of Proof-of-Work. It would be wonderful to not have hard failure (fork) at control of 51% of peers. I wish I was wrong, that is why I came over here to learn and analyze after making the conclusion below. But so far, I think the conclusion remains, until someone can show why it does not.

The seed could be the hash of all transaction in the previous CB.

The last SH in that CB thus controls the hash.

I do not think you will be able to find a way that the last SH in an period you choose, does not have control over the input entropy. That is the key distinction from Proof-of-Work, where the peers compete to the first.

This is the point I made very early in my participation in this thread. The key difference is last versus first in terms of where the input entropy comes from. In Proof-of-Work, the input entropy is determining who is first, thus it can't be gamed. In these non-Proof-of-Work systems, the last peer determines the input entropy, and thus I am positing it can always be gamed. I am nearly sure this is correct.

It appears to be fundamental.

I like to reduce complex things to key fundamentals, so that I can understand clearly the differences that matter most when making a critical decision about my efforts.

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.

Incorrect. If my SH controls the transactions in the last TBs for that hash, I can caused the hash to have any value I want (at some cost).

Furthermore, you have very limited control of IDs of your SHs. They're assigned by the order of their appearance.

But if I control the hash, then I have control over which IDs I want to target.

And they're decided before the seed for the next CB is decided.

Not that this is necessary. But still incorrect. If I control the last SH, then I can create SH deposit transactions (create new SHs) before I sign my TB which controls what the hash will be.

Since there is no control of the random generator, you'll have to resort to bruteforcing it.

It has deterministic values from every seed. All I have to do is compute from any seed of my choice, target my SH IDs to those values over any length of time that it takes for me to do so. Then just create that hash seed every time one of my SH is last. Thus disruption.

Additionally, once I do this, I might be able to continuously do it, because I can perhaps always place of my SH last from there forward.

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.

Then I only need to target those known patterns. I have as much time as I need to get my SH's IDs into that pattern.

Sorry but I think the issue of input entropy is FUNDAMENTAL in decentralized cryptography.

I saw this before I came to this thread. I had abandoned my Proof-of-hard disk, because I saw this fundamental problem.

P.S. Satoshi apparently wasn't working alone. I believe he had the resources of the NSA. I think they figured out that only Proof-of-Work was secure (up to 51%). The reasons I believe this are:

* very unlikely for one man to accomplish what he did
* he used military terminology and examples
* he said "we"
* his writing style was uniquely American english, not UK and the way a Japanese would write english
* he remained secret and covered all his tracks perfectly

[Etlase2]

It appears to be fundamental.

Let me start by saying that your "can't do" attitude is reproachful. If I listened to everyone who told me that "you can't do this" over the last 2 years, we wouldn't be here debating the finer points of a system that, on its surface, solves or reduces a hundred different problems with bitcoin. And perhaps fiat too. Bitcoin presumes the financial incentive is not there to attack the network, or that it is difficult to surmount for some entity for which money is little object. There is no lesser presumption in decrits. Your see-sawing between "it's 51% attackable" to "it's completely inept" to "it's not anonymous enough" is a complete waste of everyone's time, including yours. Let me be stupid if you think I'm stupid, but go on your merry fucking way.

If, on the other hand, you are actually capable of changing your opinion, stop acting like a toad and start presenting arguments cohesively and in a focused manner, and perhaps progress could actually be made. Sor.rge and I have had a very productive conversation over PMs without you being the distraction that you have been since you arrived.

Now you may have noticed that I set up a little trap for you "upthread" by asking you what EvilCorp does in step 6 to control the network, and your answer was "well he controls the SHs he controls". We already know this. Yes, he can delay transactions, yes, he can delay other SH TBs if he controls enough in a row, but he does not control the network at 51% or at 90% of the shares.

Now, if this was proof-of-work or proof-of-hard disk, EvilCorp needs only control resources he may already control from say, attacking another network. But the only way to control decrits is to own decrits, something that can not be obtained anywhere else other than from within the network. So even if in the remotest of remote possibilities, someone does take control of the network and destroys it, whatever resources EvilCorp used to take control are now forever gone. He had to spend his fiat, or if a government printed fiat into hyperinflation to perform the attack, that government has essentially been overthrown. No government can stay in power without a sane monetary system. c.f. ROMAN EMPIRE. And now the people can just clone decrits, hell perhaps even agreeing to use the state of the network as it was before EvilCorp destroyed it, and destroy evilcorp's shares, and continue to prosper. No, this is not a simple transition, but it is a permanent fix to a temporary problem. EvilCorp has been eliminated regardless of whether or not the network continues in another form.

So, since EvilCorp/government is unlikely to perform this network destruction attack--as they go down with the ship--they will attempt to control. Except, to attempt the control you describe, they must continue to buy up shares in dramatically larger quantities than honest people. Being the "last TB" is mostly irrelevant. If he doesn't like what he sees, he can make 1 more opportunity for 3,000 DCR. He can make 2 more for 6,000 DCR. He can pick from what a GPU that can hash at 1MHash/s x 10 seconds or 10MHash for 30 billion decrits if a share costs 3,000 DCR. 30 billion decrits versus a millipenny of electricity. Are you going to continue to presume that these have the same difficulty to obtain?

And once he does find something he likes, he can't change the entropy after that unless he can throw another X million or billion decrits into the pool. And the options of what he might like boils down to "what few SHs can I give some strikes to?" He essentially has to buy everyone out of the currency before he can control it. All using a very simple, deterministic function. And he can't just withdraw and try again. Shares are not kept for 1 year as described in the OP except not really ever because then it suits your attack vector. Shares must be kept for 1 year or else you will lose your money. Your money is your control, not your hash power or your hard disk size. If you lose your money, you lose your control. Get it yet? If you don't keep adding or subtracting money from the system, you also lose your control. Get it yet?

This can even be extended to be even more difficult to obtain control of the last TB, if that truly is identified as a weakness. Program the function so that only the oldest 20% of the SHs are capable of creating the last TB. Now using removing money from the shares results in a multi-year penalty for each SH repurchased, or you'll have to control >80% just to have the opportunity to add billions more in shares to control the order. Meaning that adding shares and keeping them longer is the only way. And you must. keep. adding to continue controlling the order at a rate of 3,000 DCR per hash attempt.

[digitalindustry]

P.S. Satoshi apparently wasn't working alone. I believe he had the resources of the NSA. I think they figured out that only Proof-of-Work was secure (up to 51%). The reasons I believe this are:

* very unlikely for one man to accomplish what he did
* he used military terminology and examples
* he said "we"
* his writing style was uniquely American english, not UK and the way a Japanese would write english
* he remained secret and covered all his tracks perfectly

I'm glad that Etlas came to my fundamental argument with regard to the negativity of ideas equation in relation to a low cost.

With regard to your comment above , all the more reason to support a test client , remember this :

---------Federal  Central Bank

------commercial corps

----Government

---Gov agencies


Don't worry I know where it's wrong ; ) 

But where does say the NSA sit ?

So I can conclude that even if you are correct , the NSA saw the future , and created a distraction , I don't believe that's what happened , but I could argue it .  And it would more than justify a beta client,  emuni have done that .

So stop arguing the same point now and help these guys make this beta. If it fails you can say , I told you .

[sor.rge]

Incorrect. If my SH controls the transactions in the last TBs for that hash, I can caused the hash to have any value I want (at some cost).

That cost is going to be very high. Bitcoin is built around the hardness of this task, only they try to find a partial preimage, while we're talking about finding a full preimage. So if you can choose the seed here, you'll have no trouble killing bitcoin as well. For some hashes this has not been accomplished even once: https://en.wikipedia.org/wiki/Preimage_attack
So you don't get to choose your seed.

This is silly, it's like saying "I got this encrypted message, so I can decrypt it by enumerating the key. So the encryption is useless." Yes you can, go on.
If you still find it difficult to understand, play a little game: imagine the seed is MD5 hash (that's a "weak" one), and the transactions are written in ascii text. The first transaction says "Transfer 5 decrits from account 1 to 2." You choose the next transaction(s), concatenate them with that string and compute the MD5. Now try to have the result of all zeroes. If you succeed, post your transaction here.

It has deterministic values from every seed. All I have to do is compute from any seed of my choice, target my SH IDs to those values over any length of time that it takes for me to do so. Then just create that hash seed every time one of my SH is last. Thus disruption.

First, the IDs are chosen, and then you know the seed. Not the other way around.

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.

Then I only need to target those known patterns. I have as much time as I need to get my SH's IDs into that pattern.

Yes. Still it may be very difficult, but it's safer to use the "random" input.

* he remained secret and covered all his tracks perfectly

On wikipedia there's a passage about some patent application: http://en.wikipedia.org/wiki/Bitcoin#Satoshi_Nakamoto
I think these guys are him

[pinarello]

ill give it three days

[digitalindustry]

ill give it three days

only 3 days to get a BETA client out , thats a push , but i suppose its how hard the guys work ?

its good that we are moving forward here !

[AnonyMint]

ill give it three days

only 3 days to get a BETA client out , thats a push , but i suppose its how hard the guys work ?

its good that we are moving forward here !

I think he meant 3 days to attack it.

I will reply later. I see sor.rge has misunderstandings (unless I am missing something in my quick read)

Will be back...

[aaaxn]

But what about these issues with missing TB?
What happens when SH from 1 to K signs TB, but SH K+1 releases his claiming previous K TBs did not arrive on time? And what if this (K+1)th TB contains transactions conflicting with ones in previous K blocks?
Blockchain does not have any data that would allow nodes to tell 'real' course of action and it would always resolve to some kind of voting between SHs?

[AnonyMint]

Incorrect. If my SH controls the transactions in the last TBs for that hash, I can caused the hash to have any value I want (at some cost).

That cost is going to be very high. Bitcoin is built around the hardness of this task, only they try to find a partial preimage, while we're talking about finding a full preimage. So if you can choose the seed here, you'll have no trouble killing bitcoin as well. For some hashes this has not been accomplished even once: https://en.wikipedia.org/wiki/Preimage_attack

You confuse yourself. Bitcoin is a race to compute the next hash solution. There can't be a preimage because every peer is racing to compute it.

So you don't get to choose your seed.

This is silly, it's like saying "I got this encrypted message, so I can decrypt it by enumerating the key. So the encryption is useless." Yes you can, go on.
If you still find it difficult to understand, play a little game: imagine the seed is MD5 hash (that's a "weak" one), and the transactions are written in ascii text. The first transaction says "Transfer 5 decrits from account 1 to 2." You choose the next transaction(s), concatenate them with that string and compute the MD5. Now try to have the result of all zeroes. If you succeed, post your transaction here.

It has deterministic values from every seed. All I have to do is compute from any seed of my choice, target my SH IDs to those values over any length of time that it takes for me to do so. Then just create that hash seed every time one of my SH is last. Thus disruption.

First, the IDs are chosen, and then you know the seed. Not the other way around.

I can choose a seed a priori, run the random generator off that seed, then set my IDs to that seed. Then later when my SH is last, I can add data to the TB to get that seed. Because the random generator is reproducible (deterministic) from any given seed-- there is no entropy added by the random generator.

Geez, that should be obvious to you.

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.

Then I only need to target those known patterns. I have as much time as I need to get my SH's IDs into that pattern.

Yes. Still it may be very difficult, but it's safer to use the "random" input.

You think, but you don't know what you are thinking. I minored in math. Thus I understand the lack of preimagable entropy to be critical and fundamental.

[AnonyMint]

But what about these issues with missing TB?
What happens when SH from 1 to K signs TB, but SH K+1 releases his claiming previous K TBs did not arrive on time? And what if this (K+1)th TB contains transactions conflicting with ones in previous K blocks?
Blockchain does not have any data that would allow nodes to tell 'real' course of action and it would always resolve to some kind of voting between SHs?

This is a very good point.

Yes proof-of-consensus falls apart from many different vectors, because everyone can lie about propagation.

My two points in this thread have been:

1. Lack of non-preimagable entropy (because some peer is always last, instead of competing to be first with proof-of-work)
2. Lack of consensus on propagation

Sorry guys, you can waste time if you want.

[digitalindustry]

But what about these issues with missing TB?
What happens when SH from 1 to K signs TB, but SH K+1 releases his claiming previous K TBs did not arrive on time? And what if this (K+1)th TB contains transactions conflicting with ones in previous K blocks?
Blockchain does not have any data that would allow nodes to tell 'real' course of action and it would always resolve to some kind of voting between SHs?

This is a very good point.

Yes proof-of-consensus falls apart from many different vectors, because everyone can lie about propagation.

My two points in this thread have been:

1. Lack of non-preimagable entropy (because some peer is always last, instead of competing to be first with proof-of-work)
2. Lack of consensus on propagation

Sorry guys, you can waste time if you want.

1. you seemed to have wasted a lot of time for something that you seem to think you are sure of , which means you are not sure of it at all - and you just conceded that "up thread" .

2. eMuni does basically let the network determine the random order - so you probably need to be Johnny on the spot to attack it if/when it releases, they just conducted a Beta test.

i could only invite that because , what is the point of a system running along with a flaw, if you believe it to be there -

[AnonyMint]

I will soon leave your thread, so you can continue to work on this dead-end without my interference. I just wanted to confirm first, that you can't refute my conclusion that it is a dead-end. I wanted to see what is the best logical defense that could be presented. Looks to me, there is no defense.

It appears to be fundamental.

Let me start by saying that your "can't do" attitude is reproachful. If I listened to everyone who told me that "you can't do this" over the last 2 years,

I like to defeat roadblocks, but dead-ends are dead-ends.

we wouldn't be here debating the finer points of a system that, on its surface, solves or reduces a hundred different problems with bitcoin. And perhaps fiat too.

All of that meta BS is irrelevant if the fundamental proof-of-concept for security is inherently and fundamentally insecure as we have explained on this page.

Bitcoin presumes the financial incentive is not there to attack the network, or that it is difficult to surmount for some entity for which money is little object. There is no lesser presumption in decrits.

Bitcoin assumes 51% attack is a major event. Money is the will of society. Society will be involved. See my thread No Money Exists Without the Majority.

Until then, Bitcoin is provable secure.

Your see-sawing between "it's 51% attackable" to "it's completely inept" to "it's not anonymous enough" is a complete waste of everyone's time, including yours. Let me be stupid if you think I'm stupid, but go on your merry fucking way.

As I explained on this page, it is theoretically possible to preimage it and gain complete control with less than 51%.

Also the propagation is also a consensus problem.

I haven't complained about the anonymity.

If, on the other hand, you are actually capable of changing your opinion, stop acting like a toad and start presenting arguments cohesively and in a focused manner, and perhaps progress could actually be made. Sor.rge and I have had a very productive conversation over PMs without you being the distraction that you have been since you arrived.

Technology != politics.

Coherent and concise explanations have been made on this page.

Now you may have noticed that I set up a little trap for you "upthread" by asking you what EvilCorp does in step 6 to control the network, and your answer was "well he controls the SHs he controls". We already know this. Yes, he can delay transactions, yes, he can delay other SH TBs if he controls enough in a row, but he does not control the network at 51% or at 90% of the shares.

Incorrect, he can control the network with less than 51%. I explained on this page.

Now, if this was proof-of-work or proof-of-hard disk, EvilCorp needs only control resources he may already control from say, attacking another network. But the only way to control decrits is to own decrits, something that can not be obtained anywhere else other than from within the network. So even if in the remotest of remote possibilities, someone does take control of the network and destroys it, whatever resources EvilCorp used to take control are now forever gone. He had to spend his fiat, or if a government printed fiat into hyperinflation to perform the attack, that government has essentially been overthrown.

Oh man you make a lot of assumptions about the lack of power of fiat banking.

You assume your system can change everything about history.

Fucking megalomaniac insane.

Socialism fails dude. You can't wall off what people do.

And this meta BS is irrelevant any way. We have already shown on this page that proof-of-consensus is fundamentally insecure. Period. End of story.

So, since EvilCorp/government is unlikely to perform this network destruction attack--as they go down with the ship--they will attempt to control. Except, to attempt the control you describe, they must continue to buy up shares in dramatically larger quantities than honest people. Being the "last TB" is mostly irrelevant.

Incorrect, in theory can preimage the entropy and get his small percent of SHs to repeat continuously in every CB.

Even if you use  the non-randomized ordering, he can buy up contiguous blocks and take control long enough. Remember the fiat powers can stay solvent longer than we can.

This can even be extended to be even more difficult to obtain control of the last TB, if that truly is identified as a weakness. Program the function so that only the oldest 20% of the SHs are capable of creating the last TB. Now using removing money from the shares results in a multi-year penalty for each SH repurchased, or you'll have to control >80% just to have the opportunity to add billions more in shares to control the order. Meaning that adding shares and keeping them longer is the only way. And you must. keep. adding to continue controlling the order at a rate of 3,000 DCR per hash attempt.

This can be controlled as I have explained upthread. I am sorry you can't change nature. The input entropy is mathematically fundamental.

[digitalindustry]

I will soon leave your thread, so you can continue to work on this dead-end without my interference.

Bet i can prove this one incorrect.

[AnonyMint]

birdbrain makes no logical points ever.

[digitalindustry]

birdbrain makes no logical points ever.

Hey I made plenty , now you are the one resorting to names .

I said why not let the natural network decide the random nature , emuni doesn't do this exactly but close enough , you backpeddled on most of the points that you previously claimed you were 100% sure of, so I'm 100% that you are not sure at all, otherwise you would not still be arguing this point.

So why not now help these guys ?

Emuni is already at beta , decrits and emuni seem to have the same basic concept , you attack decrits will you attack emuni ?

[sor.rge]

Sorry AnonyMint, but I think you either don't know what you are talking about or bring confusion on purpose. "preimage the entropy"? "can't be a preimage because every peer is racing to compute it"? What is that supposed to mean?

"I can choose a seed a priori"? I've just proven that this is impossible.

I don't think this will be a productive discussion until you educate yourself enough to understand the arguments. Visit the "preimage attack" wikipedia page that I've linked, play the little md5 seed game. It will help.

[aaaxn]

Sorry AnonyMint, but I think you either don't know what you are talking about or bring confusion on purpose. "preimage the entropy"? "can't be a preimage because every peer is racing to compute it"? What is that supposed to mean?

"I can choose a seed a priori"? I've just proven that this is impossible.

I don't think this will be a productive discussion until you educate yourself enough to understand the arguments. Visit the "preimage attack" wikipedia page that I've linked, play the little md5 seed game. It will help.

Come on people. From the very moment AnonyMint joined this thread it is really hard to follow. Please use this nice ignore option, stop responding and let's hope he'll get bored soon.