Decrits: The 99%+ attack-proof coin

[sor.rge]

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.

[1714731972]

1714731972

[1714731972]

1714731972

[digitalindustry]

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.

[AnonyMint]

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.

Are you an idiot? (don't tell me to educate myself, when you can't seem to grasp a very simple concept)

What is so difficult for you to understand that if I pick a seed, and run the random generator on that seed, I get a result that is reproducible every time I feed that same seed to that same random generator. I can precompute this.

So now, I can target my tx deposits to the results of the random generator seed that I want to target.

Then later when my SH is last, I can structure the TB so that the randomization function uses the seed I have targeted.

This is a preimage attack idiot. I have preimaged the chosen SH IDs to a seed I will generate in the future. In other words, the entropy of the system is preimageable.

What can't you understand that Bitcoin's Proof-of-Work can't be preimaged, because there is no one that can compute the result of the next hash faster than the system is. In other words, the entropy of the system is not preimageable.

[AnonyMint]

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.

You can learn to ask questions for that which you do not understand. I have not received one question from you. I have answered every question put forth to me in this thread.

[AnonyMint]

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.

... or be undecided

As I said way upthread and I think the first person to say it, that propagation isn't secure.

Now you guys slowly come to realize it. Sigh.  

[Etlase2]

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?

Unfortunately, the situation here is not as well-defined. I've kind of gone back and forth on this, but honest CNPs will likely drop the section 2 TB data, wait until 10 honest TBs have come, then release the section 1 data so that the forking TB has no effect. If EvilCorp controls some significant amount of SHs in the same area of time, and controls a large percentage of the "trusted" CNPs--CNPs for whom non-connected nodes use as their view, EvilCorp could definitely cause problems. However, EC can't really use this attack to double spend, because anyone accepting a transaction is watching. If they see a block come that ignores the tx, they must wait longer. The longer EC waits before attempting this, the more people care about and have seen what is going on in between.

EC doesn't have to really convince anyone but the person(s) for whom it wants to dupe for this attack to actually accomplish something. After 10 TBs, EC must include the section 1s of the TB(s) it is attempting to reverse, or the counters for untrustworthiness are going to start going apeshit. If EC is trying to dupe someone out of a thousand, they might just wait around for a few minutes. If after a few minutes the tx has been confirmed and re-confirmed by 20 or so SHs, EC must deny 20 SHs per TB, resulting in an "untrustworthiness" counter that jumps by 20 each TB. If EC starts the reversal right away, the person being duped has no confirmation and sees a network split happening, potentially also seeing the bad/double spend in a later TB. This person will refuse the transaction at this point because it is obvious that a double spend is being attempted.

The larger the transaction, the longer you have to wait. And once EC does this once, everyone knows. A double spent transaction is provable, it's just not provable as to which side is honest.

Any CNPs that accepted the original TB in time but then are carrying the bad chain are provably dishonest for those connected to them, and perhaps provably dishonest to those who send the CNP's signatures around on these messages to other people that were watching at the same time. What this means is that anyone who sees it will remove all client-side reputation for that CNP. In fact, there might be a way to extend this further... hmm I think I have the beginnings of a really good idea about this, but I have to think more on it. But essentially, to get people to trust CNPs, they must provide a good view of the network for a long period of time. The client-side portion of these detection algorithms need to be robust. Since CNPs are much less anonymous than IP addresses, any time they perform this attack, they must create new CNPs and regain new trust all over. There might be a provable way to destroy their CNP deposits too, but I have to think on it.

However, the eventual resolution of all this is still murky. If there are no double spent transactions, it is rather easy, I think, but if there are, a potential algorithm must be considered to resolve it, or allow the network to fork on a double spend. EC could control 99% of the SHs, but almost none of the CNPs, and the fork will resolve on its own.

Also, this could lead to a very simple idea of "super CNPs" set up by trusted agencies for people who do not wish to be connected all the time. They could go to them for the answer when they are unsure. The super CNPs can be kept in check by anyone who is monitoring the network. These super CNPs don't even need to be anything other than something set in the client, voluntarily, by each user so that there is no centralizing attack possibility (the super CNPs wouldn't even know..). It is another layer of massive collusion that would be required to even attempt to fool anyone. I believe this is how ripple sort of works, but ripple gateways don't get paid and they hold IOUs like a bank. That would not be the case in decrits.

[AnonyMint]

Etlase2, good to see you are moving away from a decentralized currency. 

[Etlase2]

Etlase2, good to see you are moving away from a decentralized currency.  

Yes, I concede that if 7 billion people are not watching the network, all 7 billion people can't determine who is dishonest for themselves. But I also believe that 7 billion people can watch the network.

[AnonyMint]

For mother of jesus, here we go again in the same circle like a god chasing his tail.

[Etlase2]

Good bye, anonymint. It's been fun.

[Charles999]

one of my favorite to mine at this time.  keep up the good work

[Etlase2]

There might be a provable way to destroy their CNP deposits too, but I have to think on it.

I think there is. Evil CNPs won't fall for it, but it is a huge indication that they are evil, and this still works.

CNPs don't need to sign all communications with all peers--such as regular tx activity, but it will sign the hash of each TB it receives with a timestamp and some indicator of whether or not it believes it has been received in time and whether or not it agrees with that TB's state of the network. This is some algorithm that can be rooted in the 10 TB window or whatever, I don't have the exact mechanism yet.

If a CNP refuses to sign a TB that a client has seen from another CNP or from the shadow peers, the client can essentially immediately ban that CNP.

Hilariously enough, because the honest CNPs will do this, the dishonest network could destroy their deposits in a dishonest half of the network--but this would be a huge indication that the those CNPs are honest. For evilcorp to perform the reverse attack, the attack must be done in secret. On one side, all people watching know, on the other, no one watching knows. There must be a fully connected alternate network operating in secret. If it is a legitimate network split, things are hazier, but not unfixable. Unfortunately it may have to boil down to some kind of voting protocol to accept the network splits back in without penalty. Presuming it was an honest split, which should be so incredibly rare anyway, but the reasoning should be world news, the networks have every incentive to get back together peacefully and without penalty if there is a legitimate reason for the split. The money supply will be doubled if they don't. This applies to SHs too.

It gets back to whether or not EvilCorp can continue to fool everyone over an extended period of time. If someone receiving a tx that is intended to be double-spent, and it has confirmations from CNPs who acknowledge and accept the block the tx is in as the state of the network, the person who is potentially being defrauded has evidence that he is on an honest network. Even if those CNPs are evil and plan to reneg, if they accept some forked chain at a later time and ignore those signatures, their CNP deposits can be destroyed on an honest network.

This makes the CNP portion of the network much more powerful and reliable. I think this can work really well.

[AnonyMint]

sor.rge, so did you finally realize that preimageable entropy is fundamental?

I don't know why it takes you guys so long to figure this out. I knew it and stated it when I first joined this thread.

It is a fundamental mathematical concept. If all you have is deterministic (reproducible) functions, then it is possible to precompute the patterns and attack. I am certain about this.

Bitcoin avoids this because the input entropy is never known until there is a winner for the signer of the TB. Then the competition begins anew for the next TB. The only way to preimage this input entropy is to calculate it faster than all the peers in the system are. But if you can do that, then you have 51% attack capacity any way.

Etlase2 and I discussed upthread if it was possible to randomize the input entropy such that the last SH signer would not have (some degree of) control. I have shown that this is impossible.

The fundamental problem for any non-Proof-of-Work system is that input entropy is controllable by the last peer that gives approval to the system. Whereas with Proof-of-Work the peers compete to be first, and that competition is the uncertainty that makes it is impossible for a peer to control it-- i.e. the input entropy.

This is fundamental and it can not be overcome. It isn't an issue of wanting to be obstinate, nor an issue of wanting to be smarter than others. It is simply a fact.

For those of you who don't understand what the term entropy means. The most general definition is entropy is the number of independent possibilities. The higher the entropy in a system, the more chance and the more Shannon information content.

The problem with a non-Proof-of-Work system is that the uncontrollable entropy is 0, i.e. the independent possibilities are 0 relative to the peer who controls the algorithm by being last.

BIG FAT ZERO. Now wrap your mind around that.

P.S. the decidability of trust for propagation can't be overcome without centralizing the system.

Both of these I stated very far upthread.

Eventually you guys will realize I am correct.

[AnonyMint]

Good bye, anonymint. It's been fun.

I appreciate you helping me determine that there is only one way to proceed, which is Proof-of-Work. It sucks that there can't be another way. But there is no other way that will be both decentralized and secure. I am confident that Satoshi realized this.

I really hate to waste time.

You are of course free to continue trying to design around the fundamental issues I have enumerated, or continue to think they aren't severe or a problem. If I could stop every person from harming himself/herself, there would be no free will and thus the world would have no entropy.

I wished you no ill will, it is simply that I want to determine where to focus my time and effort.

Thank you for the discussion.

I will bow out unless some rebuttal or point arises that is new or worth responding to.

[digitalindustry]

AnonyMint, my love !
Please, don't "bow out", we all be feeling orphaned w/o you !

Oh, i forgot, you are trapped here, because
 you'll be fired by your three-letter bosses,
if you will stop spewing your everyday BS...

you know what i'm 50 50 on that one...

50% - I just think the guy invested so much time into his own weird theory that he couldn't help but just keep coming back- 50%

and

50% Or that yeah....he's a toll sent by the BTC team to hold this project up - 50%

Which will it be >? is there Network entropy here

its huge fail if the second one (not as large as the FTC 5% attack fail but) as eMuni is in its Second Beta off this forum and out of all info control - but also a huge compliment for you Etlas because it meant you had a real innovation - and i hope you get it off the ground , there is plenty of room in the world of Crypto for all these I’m sure.

You are probably better off to wait politically now and see how eMuni goes - perhaps come and sign up at the forum - explain your ideas and contribute - ?

[digitalindustry]

ha na no idea about those - i'd say the BTC guys have a lot to lose here - i just look to the prime motive -

Etlase should wait and see the eMuni play out - get info for that and then decide to proceed or not.

if you think you have something - do what you feel - but you're not even in beta or code yet right ?

if eMuni ends up with holes all though it , i guess we keep our GPu's right ha ha . 

[Etlase2]

if eMuni ends up with holes all though it , i guess we keep our GPu's right ha ha . 

There might be some promise to emunie, but it looks like it is going to require a ton of bandwidth and disk space and a lot of processing power and transaction confirmations that take longer as the network grows, because hatchers will be competing. And very little money or luck is required to start attacking the network with double-spent transactions and so on. Clients won't even be aware of this problem a lot of the time, too, so they could be fooled. I dunno, I'll have to see more about it when it is more public, but it seems like the propagators and network securers are the same entities again which causes problems.

Fuserleer hasn't addressed any of the tough questions in the thread.

[Fuserleer]

if eMuni ends up with holes all though it , i guess we keep our GPu's right ha ha .  

There might be some promise to emunie, but it looks like it is going to require a ton of bandwidth and disk space and a lot of processing power and transaction confirmations that take longer as the network grows, because hatchers will be competing. And very little money or luck is required to start attacking the network with double-spent transactions and so on. Clients won't even be aware of this problem a lot of the time, too, so they could be fooled. I dunno, I'll have to see more about it when it is more public, but it seems like the propagators and network securers are the same entities again which causes problems.

Fuserleer hasn't addressed any of the tough questions in the thread.

BitCoin diskspace - what is it atm? 4GB and rising fast?
Processing power - really?? BTC needs ASICS, GPU farms and more, this doesn't.
Transaction confirmations - BTC is 10mins MINIMUM.

A lot more detail is on our forum should you want to visit.  I refrain from posted detailed info now on here because this is a BTC forum and I don't feel it's just to use is as an eMunie outlet.

That said, none of what you say above is correct, eMunie's transaction times are within seconds and will become LESS with more network competition, the blockchain will not grow as large as fast due to planned delta, compression and consolidate features, and it has better double-spend protection than BTC due to running multiple chains and bi-directional block tree traversal.

You can 75% attack it if you like, but your nodes wont have any trust, so that block chain will just be ignored.

[Etlase2]

BitCoin diskspace - what is it atm? 4GB and rising fast?

You are not going to convince me by comparing to bitcoin. Can your shit scale to visa and the future? Probably not if all history has to be kept.

Processing power - really?? BTC needs ASICS, GPU farms and more, this doesn't.

I would hope that you understand that ASICs and GPUs have nothing to do with the processing power required to run a node. So no red herrings, please. I dunno, you are the one who talks about tree traversals and all that.

A lot more detail is on our forum should you want to visit.  I refrain from posted detailed info now on here because this is a BTC forum and I don't feel it's just to use is as an eMunie outlet.

Uhh, it's a forum, a place for discussing stuff.

That said, none of what you say above is correct, eMunie's transaction times are within seconds and will become LESS with more network competition, the blockchain will not grow as large as fast due to planned delta, compression and consolidate features, and it has better double-spend protection than BTC due to running multiple chains and bi-directional block tree traversal.

These are all just buzz phrases that have no evidence to back them up. I'm not saying that you don't have this, but I don't have any evidence because you elected not to answer any tough questions. "ohh go see my forum" how about no. Does anyone even know what a seeder node is yet?

[AnonyMint]

You can 75% attack it if you like, but your nodes wont have any trust, so that block chain will just be ignored.

(In any non-Proof-of-Work design, ) It is mathematically impossible for there to be external consensus trust of the honest chain if the dishonest chain is controlled by more than 51% of the peers. We've covered some of the scenarios upthread, and it always boils down to that the external viewers can not know who to trust except by trusting the majority of peers.

The only mathematical way around this is to centralize the network, by placing more trust in some peers than others over time.

Indeed long-term reputation is a mathematically viable alternative to Proof-of-Work. This is centralization. There are tradeoffs.

So this is not "7 billion individually watching the network", but rather a fewer # of peers with reputation being trusted. This is just the political power vacuum all over again with its contingent problems of vested interests Olsen power scramble:

https://bitcointalk.org/index.php?topic=226033 (No Money Exists Without the Majority)

Notwithstanding the above, any non-Proof-of-Work system can be attacked with much less than 51% of the peers, due to the fact that the input entropy is preimageable, as I explained upthread. Again the only way to work around this is to trust some established peers to guard against this.