Decrits: The 99%+ attack-proof coin

[AnonyMint]

Or what you can do is make it easier to dominate than Bitcoin, eliminate anonymity, so that the statism embraces it, but then early adopters might not go for it. Bitcoin seems to have achieved the sweet spot and any way, the funding for mining dies by 2030ish so it will be super cheap for the statism or cartel to dominate it. And users seem to love Bitcoin (gambler's paradise with big hopes).

Don't forget Gresham's Law-- bad money drives good money out-of-circulation.

I don't see a way to win big here.

[1713469820]

1713469820

[1713469820]

1713469820

[1713469820]

1713469820

[1713469820]

1713469820

[Etlase2]

If the wobble is deterministic, it can be gamed. There is no way around the disappointing fact that the input entropy is deterministic.

If the wobble is determined by time (or CB #) plus the public keys of the shareholders, the only way to game it is to add or remove shareholders, neither of which is easy. Adding wastes more of their finite resources, removing some reduces their power. Either way the network "wins."

But you didn't address the problem that too many peers could mean network overload, given a mesh propagation. The attacker can add too many SHs.

I don't think you have really taken the time to understand the implications of the minting system. It is not cartel-friendly. No, it is not impervious to some entity gaining a lot of power, but it is also easy to create another network that does not rely on having any amount of hashing power for its defense.

They could send transactions to themselves to avoid historical analysis detection as rogues. So what is they lose 50% of transaction fees, as they charge these losses to the customers in form of higher prices

The "so what?" is answered by this: it is a profit opportunity for honest people to join as a SH and reduce the evil entity's power.

Dept or other national security budget or even the $5 trillion black budget that is well documented.

I'd rather not devolve into this kind of thing. The network will support any massive fiat buy-in by redistributing it in the form of free decrits. Anyone attempting to do this will lose a massive amount of wealth.

[AnonyMint]

Dept or other national security budget or even the $5 trillion black budget that is well documented.

I'd rather not devolve into this kind of thing. The network will support any massive fiat buy-in by redistributing it in the form of free decrits. Anyone attempting to do this will lose a massive amount of wealth.

Perhaps we should focus on that aspect of your design next, and see if can prevent domination by fiat.

You are correct I haven't taken time to understand that aspect yet.

Is the best possible summary still in the OP?

Note: if fiat can't buy in, there won't be this gambler's euphoria interest that provides Bitcoin its early adopter boost.

[Etlase2]

Is the best possible summary still in the OP?

Probably not.

Note: if fiat can't buy in, there won't be this gambler's euphoria interest that provides Bitcoin its early adopter boost.

I know, it is a necessary failing that the people Decrits will attract are those that are actually interested in furthering the best interests of society as a whole rather than their own personal greed. Once Bitcoin collapses a few more times as it tears itself apart, even the greedy ones will come to realize that this system is better for them too.

[tclo]

99% doesn't sounds that great when your money is at stake.  What % do you think bitcoin is?  Has to be over 99%.

[Etlase2]

99% doesn't sounds that great when your money is at stake.  What % do you think bitcoin is?  Has to be over 99%.

It is 51% in the absolute best-case scenario. Where have you been hiding?

[aaaxn]

It is 51% in the absolute best-case scenario. Where have you been hiding?

In bitcoin it is 51% of hashing power. Decrits is 99%+ resistant but 99% of what?

I would suggest you describe in points what each participant (SH, cnc, cnb, average user making transaction, etc...) do/can do from moment of starting the program to close. You don't need to go too much in details, but should include every important steps.

I strongly suggest you do it. It is required before implementation so it won't hurt anyway.

[gnomicide]

I know, it is a necessary failing that the people Decrits will attract are those that are actually interested in furthering the best interests of society as a whole rather than their own personal greed. Once Bitcoin collapses a few more times as it tears itself apart, even the greedy ones will come to realize that this system is better for them too.

So... early adopters who devote GPU power to the Decrit network won't have a big payoff if it takes off? I don't think we live in a world (yet) where a significant % of the population is willing to do things solely for the common greater good.

It also sounds like there's much less personal benefit towards providing processing power. Or maybe I've misunderstood the random distribution of new currency part. If I drop $ on hardware to "mine" Decrits, I'd expect to have some reasonable expectation of a payback period of say < 1 year.

[Etlase2]

In bitcoin it is 51% of hashing power. Decrits is 99%+ resistant but 99% of what?

To any attack that could invalidate, prevent, or double spend transactions.

I strongly suggest you do it. It is required before implementation so it won't hurt anyway.

I will be working on the wiki soon.

[kokjo]

99% doesn't sounds that great when your money is at stake.  What % do you think bitcoin is?  Has to be over 99%.

It is 51% in the absolute best-case scenario. Where have you been hiding?

51% attacks is possible in your currency too. people can and will ALWAYS disagree.

[Etlase2]

So... early adopters who devote GPU power to the Decrit network won't have a big payoff if it takes off? I don't think we live in a world (yet) where a significant % of the population is willing to do things solely for the common greater good.

For early adopters, my initial idea is to award multiples of coins vs. what would normally be awarded. If the award was 2 decrits, early adopters will receive 10 or 20 decrits instead at the very beginning, with this number reducing over the first 3 years back to the 2 it is supposed to be. Each time the award lowers, if there is any demand, the price should increase closer to the final cost to produce.

It also sounds like there's much less personal benefit towards providing processing power. Or maybe I've misunderstood the random distribution of new currency part. If I drop $ on hardware to "mine" Decrits, I'd expect to have some reasonable expectation of a payback period of say < 1 year.

There won't be any random distribution of currency for the first 3 years (if that is how long the post-live bootstrap is) because there won't be many coins in existence or many transactions to support it.

After the network gains some traction, people will earn money just for being transmitting nodes or for being shareholders. After the bootstrap is over, *everyone* will have an equal opportunity to profit from the network expanding as money will be distributed randomly in addition to the minted currency. It will not require a rat race for who can outspend others on better hardware.

[Etlase2]

51% attacks is possible in your currency too. people can and will ALWAYS disagree.

That's fine, but they're forced to get the f off the network that doesn't want them.

[mobodick]

The order of which SHs are selected to broadcast the periodic (every minute perhaps) TBs is randomized (so as to prevent being gamed by some minority or majority attack). I understood from my own work on a Proof-of-Work using harddisk space (linked up thread), that randomization can't come from the transactions in the TBs, because the last TB can be gamed to achieve any hash desired (assuming it can see all the prior TBs that will be in the CB).

I think you make an error here.
You cannot just achieve any desirable hash without doing incredible amounts of extra work.
It takes the usual ammounts of work to achieve the normal requirements for a hash.
It would take magnitudes of more work to create an arbitrary hash that satisfies both the original requirements and any informational requirements you may want to add to it. You would need ridiculous amounts of computing power to game these hashes. I'm not even sure this computing power is available anywhere in the world.

So i think you haven't thought very well about the implications of what you propose here.
It would just be computationally unfeasable to create these arbitrary hashes.
Any extra requirements you put on top of the hash just increases the difficulty for you.
So unless you know of a weakness in SHA256 or something like that you have no chance of doing this kind of attack.

I did think of this.

The computation of a single hash is not computationally expensive. For Bitcoin difficulty (which you are probably conflating here in your mind), the computational difficulty is exponentially higher, because you must guess which requires computing a huge number of hashes.

What you also fail to factor in is that an attacker is going to have a lot of time and resources to compute with, because of the fact they are dominating the peer resources.

You say you thought of this but you don't offer a solution.
The way i see it is that the party that tries to make a hash with some extra information embedded still needs to look for the hash in a random fashion. They cannot simply extract a hash that satisfies their needs from a valid hash that satisfies the network. They need to find another (but this time a much more specific) hash and that takes extra time.

The attacer won't have the time to do the extra computation because he needs all his power just to keep up and be in the same position he was before. He would need extra time and resources to make the special hashes.
The more extra information you need the hash to contain the more (exponentially) resources you will need to complete the task within some time limit.

[Etlase2]

The attacer won't have the time to do the extra computation because he needs all his power just to keep up and be in the same position he was before. He would need extra time and resources to make the special hashes.
The more extra information you need the hash to contain the more (exponentially) resources you will need to complete the task within some time limit.

The vulnerability is that the hash of all the sigs was being used to generate a random number, but anyone can use a different value for k to create a different signature for the same hash. It's an expensive operation because EC requires a lot of heavy math, but it still offers the last person to sign many options in how to rearrange the network rather than just two.

[mobodick]

The attacer won't have the time to do the extra computation because he needs all his power just to keep up and be in the same position he was before. He would need extra time and resources to make the special hashes.
The more extra information you need the hash to contain the more (exponentially) resources you will need to complete the task within some time limit.

The vulnerability is that the hash of all the sigs was being used to generate a random number, but anyone can use a different value for k to create a different signature for the same hash. It's an expensive operation because EC requires a lot of heavy math, but it still offers the last person to sign many options in how to rearrange the network rather than just two.

But then that person would need to come up with a value of k that would satisfy both the network and their own goals.
They won't be able to come up with a hash to their likings in reasonable time.
Signing one thing is trivial, but coming up with a hash that has extra informational requirements without changing the hahsing algorithm involves trying out random values of k untill the hash satisfies the attacker.

So now i'm wondering, how many bits do you need to be set to a certain value in the final hash to be able to execute such an attack?
This would relate directly to how much extra guessing work you need to do to find the right value of k that will, together with the previous block, form a hash that manipulates the choice of the next signer to be someone you defined.

[Etlase2]

They won't be able to come up with a hash to their likings in reasonable time.

Last words, etc. etc. We are already presuming the attacker has an insane amount of money to bother with this attack, insane hardware to calculate best case scenarios for hurting the network is not much more to ask from a theoretical attack vector.

[mobodick]

They won't be able to come up with a hash to their likings in reasonable time.

Last words, etc. etc. We are already presuming the attacker has an insane amount of money to bother with this attack, insane hardware to calculate best case scenarios for hurting the network is not much more to ask from a theoretical attack vector.

Aah, ok.,
I think its insanely improbable, but you can't rule it out completely i guess.

[Etlase2]

Is it necessary that the designated Shareholder for each block be the ONLY one capable of mining it or would it be OK if just a very small group was eligible, perhaps a rolling group with one added and one removed every block?

There are several reasons why selecting 1 SH per TB is important. 1) Reduction of data usage. The less people creating blocks for a specific window means there is less duplication of data. Even if I have a design to make duplicates use as little as data as possible, this small amount is still multiplied by potentially hundreds of thousands of nodes. 2) Determining the correct order of the network is easy. If 10 or 100 people are competing to make the same block, no one can really be very sure how reliable any block is. Therefore they have to wait for later blocks to accept them or whatnot, and transactions are not very secure in the mean time. 3) Depending on how it is set up, having rolling groups would make it less easy to determine when you need to be online, though having groups could make it less likely that any blocks are missed, but this also comes with 2)'s caveat that blocks are not reliable. Part of the nice thing about the Decrits system is that transactions are irreversible within 5-15 seconds.

And SHs are not mining these blocks like proof of stake, they are assigned and only need to create a block and sign it. Nothing more.

Is it necessary that the random ordering be completely unpredictable or dose it merely need to be proportionally distributed so no one individual can monopolize it?  Dose it need to change every cycle between Consensus blocks, or could the same pattern suffice several times in succession provided that Shareholders were equally represented?

No it is not completely necessary that the order be random, but as I mentioned in another post I was planning on using that randomness for some other features. Oh well, I'll find another way.

Or maybe keep the tree intact and just pick a random point within it to begin the traversal from.

What point?

Infact you could possibly do this with ALL the wallet holders and then get everyone in on the action of being a shareholder and validator, but use some secondary factor to weight the validation privilege on stake, say by traversing the tree in steps of a certain amount of coin balance rather then a certain number of account holders.  Now your change of being picked is proportional to balance and your immune to Sybil attack.

Sorry, but screw proof of stake or similar ideas. It has just as many caveats as proof of work except that it *might* use less energy. Decrits is already immune to a sybil attack. And changes like these will make section 4 impossible to implement, and it is a most necessary part of the proposal (though barely described) because it allows the network to adapt to the future and it allows for a peaceful network split in the case of monetary oppression.

[Etlase2]

Aah, ok.,
I think its insanely improbable, but you can't rule it out completely i guess.

Even if finding the most opportune way to attack is very improbable, the attackers will still be able to check many different outcomes and select the best. This is not good.

But if we continue in theory, the attack is irrelevant because it can be identified long before the attackers would be able to hurt the honest SHs. If Walmart's cartel was controlling a large portion of consensus, everyone would know that Kmart's transaction verification is very slow. Kmart would not be wise to keep something hurting its business a secret.

Since the code that CNPs use to drop TBs is client-side, it could be modified to start being more aware of SHs intentionally dropping valid transactions (perhaps this is something that should be included from the start). Care has to be taken with this though. In the weakest prevention scenario using this type of defense, at the very least Walmart's transactions would start taking longer to approve, and Walmart must start being honest again or it will be in a ridiculous situation.


edit: I mixed up two different attacks there, since there are sort of actually 3 attacks that have been recently discussed and the third is a sort of combination of the other two. It's all starting to run together at this point. Decrits is not weak vs. any of them, though yes a few shenanigans are possible given an entity controls a *very* large portion of consensus. But I don't expect perfection from Decrits, and that is why rather than creating a *crits clone to fix an identified problem, the network could instead adapt, or worst-case split peacefully with each ideal going separate ways. I have some really neat ideas for section 4, but fleshing out 1, 2, and 3 is much more important for now.

[Etlase2]

I think I came up with a cool way to address some of the problems I see with having CNPs drop seemingly valid, but suspicious TBs.

Instead of outright dropping them, honest CNPs will simply delay them significantly. The significance of the delay perhaps depending on the severity of the suspicion. This means that honest CNPs don't even have to be running similar heuristics (this was a worry with dropping TBs, I think it could fracture the CN). During the delay period, the CNP pretends as if this data does not even exist.

I *think* that this can cascade into a brilliant line of defense. If I am right and, for example, 10 SHs in a row attempt to cause the SH before them to get a soft strike, most or all of those 10 SHs will receive soft strikes instead. It requires more thought though. But it's already an idea in my notes with regards to ordinary transactions--holding transactions a CNP believes is either pre- or post-dated because time-honesty is somewhat important to the network, so why not reinforce it.

I believe this will also provide for an easier way to reintegrate from legitimate network splits.