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

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.

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.


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.


What point?


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.

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

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.

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.

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.

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.

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

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.


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.

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

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


I will be working on the wiki soon.

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.

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

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

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

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

Probably not.


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.

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.

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


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.


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.


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.

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.

Yes. If you don't have designation, then you don't have consensus. Then you have double-spends.


What you wrote doesn't make sense to us who understand deeply. I would need to take more time to unravel and explain and sorry don't have right at the moment. Maybe someone else can.

You are basically missing the point that anything deterministic can be gamed by an attacker. Your input entropy is not random.