Decrits: The 99%+ attack-proof coin

[AnonyMint]

Except to perform this attack, EvilCorp must control some significant portion of consensus. It must be able to deny honest TBs from the chain, which it can only do if it controls many TBs in a row. AnonyMint and I went over this in significant detail.

If TB 3 is honest, and TB 4 is evil and he does not include TB 3, and TB 5 is honest, he includes TB 3 and TB 4 and EvilGuy accomplishes absolutely nothing. No fork is created. Trying to create a fork in the open can not work.

This is not the 51% attack that was described in the prior post. In the 51% attack, only the evil peers sign CB and thus only they can sign subsequent TBs in that majority fork. There won't be any honest peers even signed up for the randomized signing selection.

If a large group of SHs collude in secret to create another chain that includes the honest TBs but makes it look as if the honest side is excluding theirs, they must not acknowledge consensus with this collusion of peers for days. You aren't going to do this without the entire network-using population noticing. Then they release their chain with "full consensus" and expect anyone to believe them.

You have not described the previously described 51% attack.

There need not be any withholding of TBs nor CBs for days, merely not allowing any CB signatures (I am not talking about TB signatures!) from honest peers on the evil CB.

And what algorithm can we use to determine that the minority fork with less CB signatures is more honest? I am repeating myself. Please go re-read the prior posts and provide an algorithm.

You keep shuffling around some details which are just repeating the same flawed logic. There is no possible decentralized metric for peers to know which one of these forks is the honest one.

You have presented no algorithm for deciding which fork is the honest one.

How long are you going to play this shell game with us?

It is in the OP and I have reiterated it throughout the thread. CNPs will drop suspicious TBs.

You are not addressing the 51% attack I described. It has nothing to do with the propagation of TBs.

So for someone who is oblivious, I ask again, do they believe Amazon, Best Buy, Walmart and their friends regarding which network is honest, or do they go with the nefarious group that isn't saying anything? The only point that matters for an oblivious person is when they go to pay for something which requires another party. Will this person also be oblivious? How many oblivious people does it take to cause a problem? Can we have an entire network of oblivious people that EvilCorp can fool? Because that's what it takes to be successful in this attack. But they're only fooling oblivious people. And they lost their entire deposit on the honest chain.

The above paragraph is not an algorithm.

[1715468725]

1715468725

[1715468725]

1715468725

[1715468725]

1715468725

[aaaxn]

Hey Etlase,
I think you use word obvious too much? And you say that implementation of what activity is suspicious is trivial... well ask spam filters engineers.
Anyway why don't you cut this misunderstandings once for all and create page with detailed and precise algorithm of your core consensus system? And by algorithm I mean real algorithm which have step by step instruction for every possible case. Can you do it?

And while we all wait for this algorithm I have question that you probably already answered, but ... this algorithm page would be really helpful wouldn't it?

You say SH's take turns to create TB. What happens when some SH makes his TB with large delay or this delay is created during propagation. How long next SH wait before it consider previous TB missing? What happens if he will receive previous SH's TB after he already created his treating previous TB as missing? What does next SH do? What happens if such situation extends to more than one SH and 3rd or 4th SH thinks that previous TB's are missing?

[Etlase2]

This is not the 51% attack that was described in the prior post. In the 51% attack, only the evil peers sign CB and thus only they can sign subsequent TBs in that majority fork. There won't be any honest peers even signed up for the randomized signing selection.

Unless I'm misunderstanding you, it sounds like you are trying to create some attack where the 51% can stop the 49% from signing. This is the exact same attack as trying to drop the TBs of others, because the prior CB is signed in each TB. This will not create a fork unless we get into 99%+ territory or EvilCorp is incredibly, incredibly stupid.

Let's say EvilCorp is incredibly stupid. Let's say evilcorp has all odd SHs and honest guys have all evens. So it's a 50% attack for the sake of argument.

EvilCorp chain: 1->3->5->7->9->etc. - 50% consensus
Good chain: 1->2->4 (acknowledging 3)->6 (acknowledging 5) - 100% consensus

This is the easiest attack to divert. There isn't even any particular defense for it because it is irrelevant. But perhaps I am misinterpreting you. Feel free to clarify.

[aaaxn]

EvilCorp chain: 1->3->5->7->9->etc. - 50% consensus
Good chain: 1->2->4 (acknowledging 3)->6 (acknowledging 5) - 100% consensus

What do you mean by good chain acknowledging evil corp chain TB?
Why cannot evil corp do the same then?

Code:

EvilCorp chain: 1->3 (acknowledging 2)->5 (acknowledging 4)-> 100% consensus

[Etlase2]

EvilCorp chain: 1->3->5->7->9->etc. - 50% consensus
Good chain: 1->2->4 (acknowledging 3)->6 (acknowledging 5) - 100% consensus

What do you mean by good chain acknowledging evil corp chain TB?
Why cannot evil corp do the same then?

Because then they are continuing consensus. That is why in an earlier post I said they have to do it in secret.

If they maintain a separate chain throughout a CB, the good chain is the only chain with 100% consensus. When evilcorp starts signing the next round of TBs with a CB hash of their 50% or 90% consensus, everyone can immediately identify the chain as fraudulent because it is not the hash of the chain with 100%. It is by far the easiest way to lose scads of money.

And can you point me to where I've used obvious recently? I used oblivious...

[aaaxn]

EvilCorp chain: 1->3->5->7->9->etc. - 50% consensus
Good chain: 1->2->4 (acknowledging 3)->6 (acknowledging 5) - 100% consensus

What do you mean by good chain acknowledging evil corp chain TB?
Why cannot evil corp do the same then?

Because then they are continuing consensus. That is why in an earlier post I said they have to do it in secret.

Good chain somehow acknowledges (it's not same as confirming it as I understand?) evilcorp TB without actually confirming it and doesn't loose consensus? Why evil corp cannot do it? And please answer other question (about missing TB) in my previous post.

[Etlase2]

Confirming or acknowledging there is no difference. Each TB is essentially a separate entity that governs a 10 sec window; the chain is required to keep tx times very low as the consensus can only be continuously updated if each new TB has acked all of the changes to the network state as of this moment.

If evilcorp is confirming the TBs of others, it is accepting the network as everyone sees it. There is no way around this. If it is not confirming the TBs of others, they will have a bad consensus block on the next round.

As far as how long to wait... I know you don't want to hear this but it's explained earlier in the thread. I had admitted several times I did not have a fully fleshed out idea for this, and that it would have to be based on running some numbers vs potential attack vectors. However I did post the beginnings of what I think is a really good solution all around... Somewhere.

I am currently posting from a phone and won't have regular Internet again for a few more days, so it's difficult to link and I can't work on the wiki. I *would* like to be able to convince at least one person that the system is viable though before embarking on that.

[aaaxn]

Confirming or acknowledging there is no difference. Each TB is essentially a separate entity that governs a 10 sec window; the chain is required to keep tx times very low as the consensus can only be continuously updated if each new TB has acked all of the changes to the network state as of this moment.

I am confused. Good guys cannot acknowledge evilcorp TB's because they can have tx conflicting with their chain. If block 2 contians tx "send all coins from A to B" and block 3 contains "send all coins from A to C" then branches effectively diverged and cannot acknowledge each others TB.

As far as how long to wait... I know you don't want to hear this but it's explained earlier in the thread. I had admitted several times I did not have a fully fleshed out idea for this, and that it would have to be based on running some numbers vs potential attack vectors. However I did post the beginnings of what I think is a really good solution all around... Somewhere.

I am currently posting from a phone and won't have regular Internet again for a few more days, so it's difficult to link and I can't work on the wiki. I *would* like to be able to convince at least one person that the system is viable though before embarking on that.

I'll look but I think we can agree that in distributed network there is no way to know if node did not receive previous TB on time vs it just acts as it didn't.

[CoinHoarder]

Have you written a white paper, or is the OP the closest thing you have?

I like the idea of innovative currencies, I will be including Decrits in my list of new innovative currencies and (attempting) to explain a little bit about it.

Keep up the good work, the future of crypto currencies depends on people like you.  

[Etlase2]

Ok I'm a tard and even I forget and miss things. There is a deeper issue that Anonymint has raised that isn't as simple as 50% vs 100%. I shouldn't post while distracted. Most of my last couple of posts are not a correct description of how the attack I believe Anonymint/sorrge propose is defended against.

It requires a rehash of several concepts that are in the thread, but I will put something cohesive together later. I apologize for misconstruing it.

Edit: as I said I'm posting from a phone and takes awhile, but you acknowledged the problem ax while I was posting.

[AnonyMint]

Ok I'm a tard and even I forget and miss things. There is a deeper issue that Anonymint has raised that isn't as simple as 50% vs 100%. I shouldn't post while distracted. Most of my last couple of posts are not a correct description of how the attack I believe Anonymint/sorrge propose is defended against.

It requires a rehash of several concepts that are in the thread, but I will put something cohesive together later. I apologize for misconstruing it.

Edit: as I said I'm posting from a phone and takes awhile, but you acknowledged the problem ax while I was posting.

I will wait for you to post on this before commenting further.

Even if there is a 51% attack, that does not destroy the possibility of improving upon Bitcoin.

I thoroughly expect there to be a 51% attack in any form of fungible money. I wrote an entire article to explain why.

No Money Exists Without the Majority

https://bitcointalk.org/index.php?topic=226033.0

[Etlase2]

This idea is still in the formulative stages, so bear with me. I have mentioned it a few times but wasn't totally confident in how it would work--but I also admitted that. This is one of the last ideas I came up with before writing this proposal--and so had the fewest blanks filled in. I'm still not 100% confident in this idea, but it probably has promise as a starting point. The caveat is that it does rely on honest network propagation. But propagation is so cheap in this design and is encouraged in several significant ways, and if the reward is a 99% attack proof network as long as most people pay attention...

Structure of a TB is two sections:
1. (block #, hashes of prior unacked block(s), "potential" CB hash ), signature
2. (part 1, tx activity, ongoing CB hash), signature

I have mentioned previously that TBs are a valid network view within a 10 TB window. As long as TB 54 is acknowledged by TB 64, no transactions in 55-63 can override one in TB 54. This is to allow for quick face-to-face confirmations for small txes. Originally the idea was that a SH would receive a soft strike if his TB was not accepted within that window, and then section 1 only needs to be added to the chain (saves data, section 2 won't affect anything anyway) at a later time to confirm that this SH did indeed sign the potential CB and is agreeing to consensus.

Now, I mentioned this in only one post somewhere, but instead of giving a soft strike then and there, give another 100 TB grace period where only section 1 gets added, but no soft strike. This would essentially allow a 15 or so minute grace period for network propagation. It leads me to come up with a deeper game-theoretic idea for this to deter minor trolling of this mechanic, but it's tangential at the moment. After that point a soft strike will be given. But the same data (section 1) is used to eventually add the signature data to the chain without it being necessary for the SH to do anything. Assuming the network is honest.

The longer this TB has been on the network but has not been acknowledged in the chain, the more untrustworthy the network becomes from the point of view of each node that maintains the consensus (again, 1kB/s @ 5 mil SH--it is the section 1s of the TBs). Want a formula? Fine.

Untrustworthiness = number of TBs since each TB was missed

So if 1 block goes unacknowledged for 100 blocks, it is 100. If 1 block goes unacknowledged for 100, and a second block for 50, the total is 150. Each node will have a slightly different idea of this untrustworthiness. However, the 51% EvilCorp must continue to deny honest SHs because they are acknowledging those section 1 TBs of the portion of the network it is trying to attack.

Say a number of 500 should be ringing all kinds of alarms on all clients paying any whit of attention. (This is something that needs test scenarios.) Then give a number larger than that to allow for others to catch up on untrustworthiness, say 1000, for honest SHs to create a Potential TB. This TB will essentially "call out" the situation and create an honest fork starter point. It will acknowledge the missed TBs--and they will not take soft strikes--and all the other SHs will receive soft strikes in this potential TB. This threshold could be user defined (we couldn't really force it anyway) so that it is more difficult for EvilCorp to even predict how the honest SHs will react.

An honest network must include this into the chain even if the block was maliciously created. Those peers in the block will be given strikes--though most already would have anyway for being missed and arriving late. The honest chain includes an evil PTB but does not accept it.

An evil network must also include it and not accept. And in doing so it can only give those peers strikes, it can't exclude them from consensus. But it could already give them strikes anyway. If the evil network does *not* include it, it is a beacon flashing all over the place to *stay away* for anyone that receives this PTB.

Either way, SHs that agree with the PTB will continue that chain even if they have minor doubts (threshold of say 300--this is still significant). This could be done automagically for the initiating SH with the 1000 point figure as a guideline. At this point the 51% attack must stop, or anyone monitoring the network even for a few minutes knows which chain is honest, because the evil network must keep denying the existence of new honest TBs (in which case the attackers that were used get strikes). Even a threshold of 10 is probably very suspicious, but it is an idea that needs testing. Honest SHs that get caught in the evil network because they were not monitoring long (shame on you) can learn that the evil network is continuing to be evil by denying TBs, and then acknowledge the honest chain in the next CB. All of the evil SHs can too, but the effect can not be used to repeatedly disrupt the network as they are receiving strikes. These strikes will probably be of the "medium" variety. I have been using the term "soft strikes" for minor problems implying that there may be more heavy-handed ones. It is something I need to develop.

So everyone monitoring the network (assuming wide propagation) knows which network is "more honest" by this mechanic. Either everyone gets back together to play nice, or a fork permanently emerges. Honest SHs caught in the dishonest network have a chance to reconcile, so no one honest can be hurt too badly by not sufficiently monitoring the network. And from then on everyone will be on extremely high alert.

Essentially, this system will let a 51% attack get nowhere near that point. To accomplish a true 51% attack, it must be carried out over the full 10 CD consensus period. Throughout this period, the EvilCorp must continue to deny honest SHs, and they continue to add to the untrustworthiness of their network. Unless they can suppress tiny amounts of data in the wild with insane accuracy--in which case they could simply kill the network via that mechanic without needing any SHs if they have so much control over the internet (need meshnets to become a reality to defend against this).

The incentive for a SH to put himself on the line is the fact that the untrustworthiness of the network is so high, if he is honest he is likely to be excluded anyway and receive a strike. Perhaps there could be a specific incentive if his PTB is continued too.

I guess sorrge was right about calling it trust. It is different to get out of my head and into electronic ink. There needs to be an avenue to fork without necessarily causing a catastrophe. This design leaves open the possibility of an undo button. Honest SHs can still come back at the cost of evil ones coming back as well. But  they have not accomplished anything other than receiving a strike and disrupting the network temporarily. The failure is not critical which is critically important. And it is not easily repeatable without significantly more investment. How much will depend on how clever the strike system can be (combined with early withdrawal penalties and other things).

And from the very first minute or two of this attack anyone partaking in a large face to face transaction will know something unusual is up. It depends on how reliable the network is on average. These are things that are really hard to predict ahead of time, but it is important for defining transactional security.

Sorry for the super long post, but I feel like if I don't recap a lot of things, the mechanism will not be clear.

TL;DR VERSION: Each node watching the network keeps an internal idea of how untrustworthy the network is based on TBs it has seen that are not included in the TB chain. At some high trigger point, a SH node will create a different type of TB that will call to exonerate the missed TBs and penalize the offending SHs. This will create two potential future CBs, allowing the network to fork if necessary. If the evil 51% of SHs continue down the forked path, they generate more untrustworthiness that more people will see as the consensus period continues. The fork can be resolved by taking strike penalties. Honest SHs may be unjustly penalized (but not permanently) if they have not been monitoring, but it is the risk they take by not even monitoring the TB section 1 data. Clever penalties can make this attack very costly or ineffective while barely hurting the honest network. This premise does rely on wide propagation of all network data, but the alternative is an attack where EvilCorp has incredible control over the internet and can prevent that propagation, in which case it could simply cause the network to fail anyway without all the shenanigans.

After this, I have slow down the discussion. I really am spending too much time on this. A wiki makes much more sense, and it will allow me to update where vulnerabilities are found, or to make things clearer over time rather than murkying up a thread. There is too much crap jumbled in my head that causes me to make mistakes. And I have the urge to be protective and defensive. Combine these things and well... but there are a whole bunch of other things that still need input too, and I had promised in earlier proposals to promote an open discussion of all the ideas prior to ever launching the currency. Being paranoid is not the way forward, even if AnonyMint has given me some reason to be.

Have you reconsidered at all your opinion of the currency distribution scheme AnonyMint? I made a pretty significant point about purchasing power lost being voluntary. If you want "in", start offering goods and services for decrits. There has to be a stable platform for commerce.

I have briefly looked over your other thread, may comment on it later.

[kokjo]

... snip ...

i call bullshit as always, and reminds you of our bet.

even the tl;dr i say tl;dr to.

how do you identify a bad SH, when the majority is bad? Ask the bad ones? who says what is good and bad in the network? you? me? some heuristic method that can easily be cheated? 

[sor.rge]

I think this is a step forward already.

If we assume reliable propagation of the broadcasts within a certain time limit, then the nodes who are online continuously can indeed distinguish the honest chain in that attack. At the time of CB, they will know who was really on time, i.e. whose TBs appeared within allowed delay. If somebody withholds their TBs and at CB time claims that the others were late, the always-online nodes can compare that with their historical records. If somebody doesn't include the TBs of others, the always-online nodes can check if those TBs were broadcasted in time, in which case the party who omits them is the wrong one.

Some problems still remain with this attack:
1) The assumption of reliable time-bounded propagation. This can be disturbed in various ways by the attacker.
2) Race conditions with the timeouts. The malicious peers can release the critical information when its time is running out, in this way dividing the opinions of the observing nodes. Some of them will believe the message is late, others that it was on time. This confusion potentially will open possibilities for other attacks.
3) The nodes which didn't observe the attack, and only see the resulting fork, will still not know whom to trust. Both parties will claim that the other didn't release their TBs on time or didn't accept legitimate TBs which were released on time.

[aaaxn]

If we assume reliable propagation of the broadcasts within a certain time limit, then the nodes who are online continuously can indeed distinguish the honest chain in that attack. At the time of CB, they will know who was really on time, i.e. whose TBs appeared within allowed delay. If somebody withholds their TBs and at CB time claims that the others were late, the always-online nodes can compare that with their historical records. If somebody doesn't include the TBs of others, the always-online nodes can check if those TBs were broadcasted in time, in which case the party who omits them is the wrong one.

And how these always online nodes are going to prove that they are telling truth?

[sor.rge]

And how these always online nodes are going to prove that they are telling truth?

They aren't. They can only decide the truth for themselves.

[Etlase2]

1) The assumption of reliable time-bounded propagation. This can be disturbed in various ways by the attacker.

Counterpoint: If the attacker already has this type of power, he doesn't need anywhere near 51% to control the network. Compare bitcoin with it's 10-20 nodes with the network view. An attacker need only disrupt a couple of them to cause complete chaos. In Decrits, he will need to disrupt massive portions of the internet.

2) Race conditions with the timeouts. The malicious peers can release the critical information when its time is running out, in this way dividing the opinions of the observing nodes. Some of them will believe the message is late, others that it was on time. This confusion potentially will open the possibilities for other attacks.

You are going to have to be clearer. I can imagine several different things that you mean by "timeouts" so instead of covering them all in a jumbled mess, I'd prefer clarification.

3) The nodes which didn't observe the attack, and only see the resulting fork, will still not know whom to trust. Both parties will claim that the other didn't release their TBs on time or didn't accept legitimate TBs which were released on time.

I explained why this is ok--I'm sure not very well though. A PTB will effectively stop the attack on the network, meaning there will not be any 51% attack, but just an attack on perhaps 5-20 honest SHs (the attack you and anonymint brought up as potentially being more critical--making small forks). But those SHs that were attacked can not be denied consensus, because the evil chain must include the PTB or it is screaming network takeover attempt. A PTB should essentially be thought of as a critical stop to network activity. Until a node sees a chain with it included, it should not transmit that chain, and and anyone using the network should not make transactions until they see a chain with that PTB.

It sort of puts EvilCorp on the spot. Stop the shenanigans or go ahead and fork. Everyone that is currently watching the network will see the fork forming. It won't happen instantly, it has to be as a factor of time. If they continue to fork, more and more people will see the untrustworthy network for what it is. Everyone watching knows of the attack. More will start asking for TB data, more will start seeing the fork.

Even if people are late to the game, they will receive the missing TBs assuming they are not isolated. To actually destroy the shares of the honest network, it must pretend as though the honest SHs refuse to reach consensus. While a TB from 2 hours ago could have been made 10 seconds ago, a new node will keep a counter from the time *it* saw the TB. Honest SHs must still add section 1 to the chain regardless of how late it is (unless it is so late that it is past the absolute deadline where shares are destroyed). This is what brings consensus. So anyone hopping on prior to that deadline will start counters. If there is a fork, the honest half will have all, or mostly all of the signatures in consensus that any node could see (including but not accepting). The dishonest half must exclude those whose shares it wishes to destroy.

If it does not exclude those, they only receive a strike. It is an attack vector, but it is not a critical one as I said. If they include the PTB then start another attack, the untrustworthiness will build more (it would have to go down over time). So if they do not want people to know who all of the dishonest SHs are and provide a long period of time for everyone to find out, they must settle for giving a few, random honest SHs strikes.


I really don't think this can be countered by any "well an attacker can control this or that view of the network". If they have the capability to do something like that, any defense for anything is impossible. It is essentially saying "you have fixed every single thing but complete and utter control. Your currency is 99% attack proof." And I say "thanks, that's what I been sayin brah"

[Etlase2]

Some numbers for perspective:

Assume 4,000 tx/s [visa levels], assume every tx only pays the min tx fee of 0.01 decrits, that is 1.262B DCR per year that runs through the security system. This is not improbable 10 to 20 years from now I don't think. At least for whatever cryptocurrency has become the most popular.

For each SH to receive a 2%, non-compounding, rate of return if a share costs 3,000DCR, there will need to be DCR631m (1.262b/2, since 50% goes to CN) / DCR60 shareholders, or 10.5 m SHs supported by visa-like tx levels. 2% non-compounding is rather low, but the return can be invested in other ways, and that's 10.5 m SHs at minimum tx fees. 10.5 m x 3,000 is 31 billion DCR invested into just the SH side of network security. (As a side note I have considered an algorithm to increase the share price if the SHs total starts getting insane, 7 m or so "should be enough for anybody".)

CNPs will need significant bandwidth to run a visa-like connection (estimated 160Mbit/s, quite reasonable 10 to 20 years from now), but if there are say 1 million CNPs, that is 630 DCR per CY or 53 DCR per month, enough on its own to pay for a high-speed connection today, could easily pay for the costs of upgrading to a top-tier package with some profit on the side. Remember, little to no inflation in decrits, hopefully anyway. Performing a 50% attack on the CNPs would require 150m DCR (assuming 150 DCR deposit), and a 50% attack really is useless against the CNPs. CNPs that are being devious can be pretty damn obvious (to be detailed later), so clients will stop using them and will stop using their ID codes in txes, so they won't get paid, so the attack is nothing more than a waste of time. This is part of the subtle and not so subtle dichotomy between the CNPs and the SHs, and further enhances the network's foundation.

And every single client of the network could still detect any attack on it for about 1-2kB/s of bandwidth--an amount that might be free to everyone by that point if meshnets exist. Anyone who has any value in the network will be incentivized to watch it. And it is very cheap to do so. *Every single person* doesn't have to watch it though, they can be pretty sure if several million other people agree that this happened that it is probably true. If you haven't seen the pyramids in Egypt, does that make you believe that they do not exist? Where are the people who say it isn't true? Employees of the NSA?

Of course when the network is smaller there will not be several million people, but the same rule applies on a smaller scale. Those who have value in the network will be incentivized to watch. Someone can throw away 30 billion USD to try taking it down, but if the people who care are watching, the attack will be ineffective and the network will have gained that value at the very least by redistributing that fiat attack among the decrits users' fiat holdings (by selling some when the price was too high). If it encourages an economic shift towards decrits, then decrits permanently appreciates over fiat.

Efficiency and decentralization is paramount in every aspect of the design. With massive decentralization comes massive resilience. And a sane monetary system controlled by the people to boot.

[Etlase2]

So I'm making a list.  Who are you and what are your qualifications for being a lead dev on an crypto?  Please let us know.

Edit: you can answer here or here. https://bitcointalk.org/index.php?topic=225643.0.

Cheers.

As far as real name, several people already know it (including anonymint), but at this point I don't think it's necessary to make it public. I don't plan on being another satoshi though. There is nothing dishonest about my design that would cause me to need to hide my identity.

As far as qualifications, I've been programming since I was about 12, but only as a hobbyist. After learning about bitcoin I went on a two year study of economics, cryptography, network protocols, byzantine fault tolerance, and so on while discussing and refining the various proposals that have eventually led to this one, the 6th, which I think is as close to perfect as an imperfect system can get. So, no qualifications really. Just a vision with the ability to come up with the design implementation whenever I need to dig further.

Have you written a white paper, or is the OP the closest thing you have?

I like the idea of innovative currencies, I will be including Decrits in my list of new innovative currencies and (attempting) to explain a little bit about it.

Keep up the good work, the future of crypto currencies depends on people like you. 

No white paper... there are many things that have been addressed in various ways that I see as weaknesses in bitcoin or money in general. I'd rather just implement it. Thanks for the support, though.

[AnonyMint]

I wrote briefly about my relative qualifications at the following link:

https://bitcointalk.org/index.php?topic=226033.msg2441624#msg2441624

I will now address all discussion since my prior post in this thread.

1. I thought we already decided that excluding transactions was not a possible attack (unless 100% of peers are evil), because the honest fork would be readily identified as including all transactions (including those from the evil fork). The worst that could happen is a transaction could be delayed by one CB period, if the evil fork withheld propagation of TBs (to non-evil peers) until the CB (where it can't be withheld any more and still be a public fork) or if the evil fork included transactions from the honest fork one CB later (so as to be not readily identified as the evil fork).

This delay could allow for a double-spend, where conflicting forks have different order of which of the double-spend transactions was first.

2. The only attack vector is that evil peers will not let non-evil peers sign their CBs and evil peers could create one or more forks in addition to the honest peers. There might even be multiple factions of evil peers who don't want to share tx revenue and thus exclude other peers. So the problem is how to identify which fork is the consensus in order to properly award tx fees?

In light of the above, the proposal since my prior post appears to distill to that peers who attempt to sign a CB and are ignored by a fork, will see that fork as dishonest if propagation error/delay can be ruled out.

The problems are:

a. Evil forks might occasionally allow other peers to sign, thus obfuscating whether propagation or evilness is the cause of missed CB signatures.

b. The honest peer's opinion is only valid for himself, and can't be proven to the world without 51% consensus.

No matter how you slice it, you can not avoid the 51% Rule of Decentralized Agreement.

This is not a crippling conclusion. We should move forward on improving upon Bitcoin. We will not be able to make a decentralized currency that avoids the 51% attack.