Pages:
Author

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

hero member
Activity: 798
Merit: 1000
‘Try to be nice’
June 15, 2013, 07:38:10 AM

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.

"up thread" i said that - about 5 pages back - just try to make it - then fix it , if it breaks - more fun aswell.
newbie
Activity: 42
Merit: 0
June 15, 2013, 06:53:18 AM
Ok, now to your question.

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?
My current understanding: through blockchain you can't resolve it. You need to have been online during one of the 1 to K blocks and have seen for yourself that the signatures were indeed broadcasted. Then you can be sure that (K+1)th SH is the liar.
The honest nodes will then take action to suppress the (K+1)th from the network and enforce their opinion. For example, all the communication related to the false chain is not relayed by them. So it's a kind of vote of the whole network.
Now if the attacker has a significant portion of the network as well, he can form an appreciable fork. There it becomes harder, and the users will have to interfere. Those who missed the fork buildup (and therefore don't know the truth) will have to decide which chain they're going to be on. Etlase2 proposed some trust-based solutions. All the real people who are not the attacker will either know the good chain, or be undecided. So you could run a vote among the people whom you believe to be real.

I hope Etlase2 can comment as well.
sr. member
Activity: 359
Merit: 250
June 15, 2013, 06:35:36 AM
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.
newbie
Activity: 42
Merit: 0
June 15, 2013, 06:00:58 AM
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.
hero member
Activity: 798
Merit: 1000
‘Try to be nice’
June 14, 2013, 11:20:21 PM
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 ?
hero member
Activity: 518
Merit: 521
June 14, 2013, 10:33:56 PM
birdbrain makes no logical points ever.
hero member
Activity: 798
Merit: 1000
‘Try to be nice’
June 14, 2013, 10:20:19 PM
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.
hero member
Activity: 518
Merit: 521
June 14, 2013, 10:13:53 PM
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.
hero member
Activity: 798
Merit: 1000
‘Try to be nice’
June 14, 2013, 10:09:24 PM
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 -
hero member
Activity: 518
Merit: 521
June 14, 2013, 09:50:59 PM
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.
hero member
Activity: 518
Merit: 521
June 14, 2013, 09:44:41 PM
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.

Quote
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.
sr. member
Activity: 359
Merit: 250
June 14, 2013, 02:24:18 PM
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?
jr. member
Activity: 42
Merit: 1000
June 12, 2013, 11:56:19 PM
Finally i got it !
I'll share :
AnonyMint is not a human, but a DSC.
That is : Domain Specific Controller.

In my dream i partially reverse-engineered "him".
"he" has amazing design :
In large pool of liquid helium floats main source of his entropy (device/1).
Perhaps "he" has some issues with quality and quantity of entropy produced by device/1,
and we can see this from his postings
( all that talk about "how entropy is important for him").

Then entropy from dev/1 flows straight into
one of "his" three axiomators (meaningless
 axiom generator aka dev/2), outputing up to 5 axioms/min

Then axioms flow into VCTT (vicious circle-jerking thinking tank aka dev/3) and (re)cycle there forever... before going to outposting gun
 (dev/4)

Quite simple (yet powerful) redesign of old-fashioned brainwashing machine...

Also "he" has a minor problem :
"his" IQ-meter has broken scale, and when
 he gauges IQ = 666 this means IQ = 0.666
---------
Now you know the truth, have a nice day !
hero member
Activity: 518
Merit: 521
June 14, 2013, 11:22:11 AM
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...
hero member
Activity: 798
Merit: 1000
‘Try to be nice’
June 14, 2013, 05:13:52 AM
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 !
full member
Activity: 266
Merit: 100
NXT is the future
June 14, 2013, 05:10:27 AM
ill give it three days
newbie
Activity: 42
Merit: 0
June 14, 2013, 05:04:17 AM
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.

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.

Quote
* 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 Smiley
hero member
Activity: 798
Merit: 1000
‘Try to be nice’
June 14, 2013, 02:14:53 AM

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 .
hero member
Activity: 798
Merit: 1000
June 14, 2013, 01:43:30 AM
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.
hero member
Activity: 518
Merit: 521
June 14, 2013, 12:07:19 AM
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
Pages:
Jump to: