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

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



Severe delays to transactions can cause the masses to go with Bitcoin and be subservient to a 51% attack that does nothing but require some things which the masses agree to (e.g. provide identification and thus enable confiscation the exact thing people are hoping to avoid by using Bitcoin, or in other scenario not stopping the cartelization of only processing transactions for the merchants who pay up to the cartel, which is just credit card fees all over again).

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. 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 (for their cartel) or to the society in general as funded by the government via Homelove Security Dept or other national security budget or even the $5 trillion black budget that is well documented.

A solution has to be able to work always.

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.

In all cases, I am not interested in working on non-solutions that can be foiled by National Security departments with the unlimited fiat resources of the state and the masses who want to tax everyone so they don't have to work (or can't work because they are irrelevant in the hightech age).

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?  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?

If complete unpredictability is not necessary and it is merely proportionality that's needed, then why not set a discrete pattern during the Consensus block, say by creating a hash-tree of all Shareholders and then doing a strict traversal of it.  Use all the interceding transactions between Consensus blocks as well as the balances of the Shareholders to rebuild the tree and create a new strictly ordered and universally visible traversal list.  Or maybe keep the tree intact and just pick a random point within it to begin the traversal from.

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.

Yes, and to prevent joining the queue in order to receive TBs in order, you only need some simple functions to split up new SHs and then add some wobble to the order as a factor of time. The randomization of the order was only nice as an eloquent system, it was never required for SH security.


As I have previously stated, only someone with a huge vested interest in the network could do this. It is better than someone 51% attacking bitcoin because nothing can actually be accomplished of note besides delaying transactions. Dropping transactions can be somewhat objectively determined based on historic figures, and SHs could be penalized that continuously fall too far below the average. But remember, if 1% of the currency is tied up in the SH/CNPs, then the attacker must control some fraction of a percent of all the currency in existence to perform this all-around useless attack.

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.

Indeed appears the weakness is that such a solution (to the non-randomness) can be overloaded. Perhaps the only solution is to split the system into multiple orthogonal forks and have multiple orthogonal consensus.

Set some limit on the number of SH in a consensus fork, and then spillover into a new concurrent consensus. Spenders can choose to send their transaction to any concurrent consensus, and thus the concurrent consensuses must be aware of each other to avoid double-spends.

But there is no way to achieve this interaction without relying on trusted peers to aggregate and coordinate, otherwise it is just all the peers listening to all the peers and network overload again.

I am about to give up on this. It seems that money is a social institution (that can always be gamed by the statism of the dumb masses) and there appears to be no technological solution.

Instead people will try to game the statism by hiding their identity, but the statism will eventually win this battle, because technology does not offer a solution for money that prevents it from being controlled by the state and/or a cartel.

It appears to be fundamental and there is no possible solution. The reason is because randomness means non-deterministic. Thus you must have some input entropy (information) that is not controllable. But the only inputs are the hashs of the peers and the transaction data, both of which are controllable by the peers. Thus the order can be controlled by an attacker. I see no possible solution. Sad to say.


How can you stop a deep pocketed attacker (e.g. a bank which can print money from thin air and buy Decrits via the exchange) from spamming the queue with its own peers in a consecutive order to make the system effectively unusable (huge delays to transactions)?

Divide the CB period by the number of SH to get the TB period? So everybody gets a turn within 1 CB?


Okay I like the idea of allowing multiple SHs to sign in the same TB period, then we aggregate all the transactions for those TBs.

Seems the solution is that all SH get a turn within the CB period, thus the maximum transaction delay is some fraction of a CB?

What are the problems with this? What about network overload?

Seems this design will be subject to DDoS attack by spamming the number of SH, since we have to listen to all, we can't pattern them out.

Hmm, I've spent too much time away from my cryptography study.


All peers will get a turn regardless. The function can only determine the order. If there are more SHs than needed to create 1 TB per 10 seconds, then more than 1 SH will create TBs for the same 10 second period with one having priority in the case of conflicting transactions. Or an approach that is less data but not as nice is to have them just sign someone else's TB and add any transactions missed for that window. But I wanted more than just the order to be able to rely on the random number. Luckily I already had a backup plan for at least one aspect, but I will have to think more on this.

I'm starting to get into this and am trying to understand Etlase2's protocol.  The general outline of Shareholders seems to be this is essentially a quasi-PoS transaction validation system but modified such that it is not vulnerable in the PPCoin manor of saving up a bunch of 'stake days' and splurging them all at once in an attack.  Instead the SH each get narrowly defined windows of time to operate, the narrower and more randomly assigned the better.  It also sounds like your allowing/requiring only large holders of funds to be these Shareholders, much like say the board of directors of a company or something.  Would it not be possible for all wallet holders to be Shareholders?  Could you take the normal PoS system and just add a randomization and window-segmentation layer to that process to prevent the attack?  If you want to incentive the work or punish the failure to do it, then just put in demurrage equal to PoS mining, now everyone must do validation or lose balance over time.

Don't worry, I will soon explain this idea in layman's terms. First I need to make sure I understand it.


Ah, your hash is predetermined from an initial value (modulated by the hashes that SHs choose which drive the hash forward)?

I had already thought of and dismissed this predetermined order in my design, because the SHs can game this when they choose their signature hash so as to place themselves ahead of others in the predetermined order.

Do we need randomization? (I think so) What we want is that all peers get a turn. So what is wrong with a FIFO circular queue? Every peer that joins gets placed at the end of the queue along with those who just recently had their turn.  I guess the problem is that an attacker can add a huge block of peers to get all of its peers to run consecutively, which would delay transactions. Note, this shouldn't cause the consensus fork to be rogue, if the oversight of the CB is not done only by the selected SHs for that CB.

Could we somehow randomize where new peers get placed in a circular queue?

I continue to see the randomization problem as fundamental, unless I've misunderstood you.


I don't mean to imply there are problems with that choice, I should have used the word "discussion" or "decision" or "reasoning" instead of "issues".

I have a feeling that your day is about to get better.

+1 No idea will take off if no single average Joe with IQ ~100 can understand.


We need this concept re-described in plain English!

If there are at least 87.6k SHs, each SH will have to create a TB once every 10 CDs, or about once every 10+ days. They will be aware of when they need to sign in advance, which I will get to in a moment. The deposit does not shrink if the SH does not sign, the deposit is destroyed. If there are a lot of missing TBs, the time before destroying shares can be extended to give a chance for network split SHs to rejoin the network with only a soft strike. Which network takes "priority" can be determined simply by whichever has a greater portion of consensus.


Correct.


CNCs are just lite clients. They don't do anything but use the network and want to receive legitimate data. CNPs are a CNC's connection to the network. A lite client's view is determined by the view provided to him by the CNPs. CNPs are the first line of defense against rogue SHs attempting to divert attention from the legitimate network by creating TBs in secret. A node that has not been connected to the network recently can't know that these blocks were produced in secret, so the CNPs must drop them (and cut communication with nodes that send them). CNPs protect CNCs (and other CNPs) from evil SHs. This protection is not absolutely necessary, but it can resolve evil network splits before they ever have a chance of accomplishing anything.


Egg-fricken-zactly. It's only a matter of timing.


Because it isn't during the current consensus period that the next random number is determined, it is during the prior, but everyone only knows what that number is after everyone signs it, meaning the last guy to create a TB can't know what affect his TB will have on the random number.

For example:

1) CB 1 is transaction blocks 1-1000
2) As each SH creates his TB in CB 1, he signs CB 0 (the genesis block) as well as implicitly signing the ongoing consensus by acknowledging prior TBs and current transactions. But this ongoing consensus is only used to help lite nodes determine with provable accuracy the current state of the network as opposed to the state at the last approved CB (and allow for fast tx confirmations).
3) At some point there is a cutoff, say block 1300, where any SH who has missed creating his TB can still sign the prior CB hash. Any signatures after this point will be refused and shares destroyed.
4) At block 1300, we have the signatures of all the SHs who are going to sign the prior CB, now we give a nice propagation period so that everyone has them before changing the order of SHs. Say block 1700.
5) At 1700, the new order takes effect. The random number is hash(all SH signatures of CB 0's hash). The only way to affect this number is to not sign and lose 3k DCR. The only way to know what affect this might have is to be the very last person to sign the CB (and then you have only 1 of 2 choices, 1 of which causes -3k DCR guaranteed). There is probably a way to fix even this most minor of vulnerabilities, but I haven't yet thought of it.

Depending on how long the window is before TBs will be dropped means that the first X SHs in CB 2 will have to wait until that window closes before signing CB 1. But the signatures themselves do not alter the prior block, they only acknowledge it, so they do not have to wait until block 1300+ or whatever before they can sign it.

In the event of a network split, the network could extend the 300 additional TB period to be much more to prevent honest users from having their shares destroyed due to problems with the internet/government infrastructure. Some trigger figure such as 0.5% or a minimum of X SHs would have to be reached before enabling this mode. The random number last determined could easily keep extending the TB creation order until no longer necessary.


Issues? It is the greatest thing that can possibly be done for cryptocurrency.

In any proposal that attempts to deviate from Bitcoin's computational proof-of-work, has to resolve the fundamental problem of where randomness (entropy) comes from that isn't controllable by a peer.

That is a fundamental problem, and I am leaning to that it is impossible to solve.

In all alternative schemes, some peer is always last to contribute to the computation (and thus can game it).

Bitcoin shifts it to a peer is always first, by forcing all peers to compete for luck.

That is fundamental as far as I can see.

Sorry to ruin our day

Okay this system seems actually quite simple to explain and understand, and I will let the author point out where the following summary misses a crucial design point and why.

The idea is that every transaction processing peer ("SH") is incentivized to sign a periodic (daily perhaps) compilation ("CB") of recent past transactions blocks ("TB"s). The author's proposed incentive is that each SH must make a monetary deposit, and this deposit grows with transaction fees if SH signs and shrinks the SH does not sign.

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 am still not clear on how the randomization is achieved. That will be discussed below.

If a rogue attack attempts to sign a CB that excludes TBs or has TBs which were not broadcast to other non-rogue peers, the non-rogue consensus will add the TBs from the rogue CB to the non-rogue CB but shrink the deposits of those rogue SH, but I am not yet clear on the mechanism for this. Thus, the rogue SH peers eventually end up with 0 deposit in the non-rogue consensus CB fork and thus are banned. The non-rogue SH peers end up with 0 deposit in the rogue CB fork, but because it excludes non-rogue TBs, then it is clearly the rogue CB to all consumers of the information. There is no way to include a forged TB, because each TB must be signed by the private key of the SH which was selected by the randomized ordering (see prior paragraph).

---

Thus I don't yet see the technical need for CNC and CNBs (and I don't even know what they are and do).

The randomization is unresolved in my mind so far. I assume only SH's can sign which have already selected their hash before the signing of the CB commences, so they can not select a hash for themself that causes the randomization to point to an order of their choosing. But how can all SH know what the hashes of all SH are, until they sign? And how can we be sure that the SH which sign are different on each CB? If instead we use the order of signing as the entropy, how can we stop SH from waiting to be last in order to game the final hash result, thus gridlock. The randomization in Bitcoin is being first is luck, and there is an incentive to be first.

Note for the moment I am ignoring issues (reasoning and discussion) about separating minting from transacting and the issue of capital aggregation,as well anonymity. Let's resolve understanding on the above first.

I am also for the moment ignoring the issue of duplicated transactions in TBs, since that seems to be just an implementation detail.

I am an expert programmer (but not much network programmming experience). I will try to digest your latest replies. I think I could significantly boost the capacity to implement, if I can be convinced we have the correct design.

Here's the problem regarding implementation: I am a hobbyist programmer, and I will have a lot of difficulty programming certain aspects of this network, especially regarding the network protocol because I have zero experience in designing such a thing. I have many notes on how it can be efficient once the system is in place, but I would have to spend way too much time learning things that I currently do not know. So priority #1 is to find someone who will agree to code the base network protocol.

Number 2 is someone who is an amazing general programmer who is willing to check my code of the core and help as needed.

Number 3 would be someone who is a database wizard who could help make sure that my design for the consensus block and the changes to it is efficient in that it does not require too many db hits or too much data in memory. I think I have a pretty good plan, but I may be missing some key stuff about keeping a database optimized on a level where even modest computers will need to be able to quickly access and approve vast quantities of small amounts of data while keeping it aligned in a way that makes it easy to hash and reach consensus.

Number 4 is lots of people willing to find edge-case vulnerabilities in the system design that can be fixed by changing some of the constants and/or incentive/disincentive structures. I can't spend too much time deciding on specific constants, I can generalize, then as the network is being developed, people would be able to discuss these things in detail and influence how the final network operates. Part of the pre-live network bootstrapping award would be to give away money to exist on going live for coming up with cases for why doing something one way would be slightly better for the network than another (probably just tokens on a forum that will eventually become decrits). Whether or not enough people would be interested in this community approach remains to be seen, but I will make the attempt if we can get to that point. Additionally, GUI programmers, GPU miner programmers, translators, and so on would be well-rewarded for contributing to those aspects of the project's development.

The next step is the wiki. After that is creating a unit test with a simulated network. Then I will need help. But help coming before that point is always welcome.

It is hard to understand your idea as it is presented now. Maybe you should try to describe it different way.
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.

Maybe it's extra effort, but you need others to understand your system if you want it to be working.

Yes, this is a key point. SHs are penalized for not making TBs because it is an inconvenience to the network. The idea that CNPs will drop poor-quality TBs is a newer one, so I don't have it fleshed out as much. It is possible that there may be a way to fairly penalize a relatively empty TB further down the road. I have mused about potentially reducing the amount of award they will receive, so at least they are less profitable for attacking. But this is a whole other complexity that I just haven't delved into yet.


And I mentioned the defense for this in the post above.

1) Regardless of whether or not the people only see one side of the fork, they *know* another side exists. This is powerful. You can never fool isolated nodes into believing the network is complete.
2) Given a sufficiently large network, it will be impossible for any part of the network to collude in secret, as there will be thousands or tens of thousands or hundreds of thousands that have proof of that collusion. This is because becoming an official transmitting node is cheap but sybil-resistant (150 DCR based on the OP, and rewards based on proven activity), costs are low--bandwidth and storage constraints have been a huge priority in my design, and the pay expands as the network expands, so more people are encouraged to join as is profitable.
3) The system denies access to controlling the money supply in so many ways that for anyone to have much wealth in the system, it must be earned via the system in trade.
4) A significant portion of the total coins in existence will be encouraged to be invested into shares and CNPs. Even if transaction fees have to be higher than 0.01% to keep say 0.25-1% of coins in the network, businesses can buy more shares as a portion of revenue to recoup a decent chunk of those fees. Because this money is "locked", more money will eventually be created to return to the same level of activity, which again is distributed randomly and must be earned in trade. (Which legitimate businesses will have no trouble doing.)
5) There are so few avenues to profit from dishonesty. It is the celebration of the commons rather than the tragedy. Everyone is encouraged to be honest to be the most profitable. Causing the network to fork is going to have to cause a choice to be made, and there is simply no way that an EvilCorp will be able to fool anyone into believing a dishonest network. This would be huge news.

If Walmart and whoever else want to collude to force out small business, everyone can go buy up walmart's stuff on their network, then give them a big fuck you and only accept the small business network afterwards, rendering Walmart's money useless. Same thing if a government would try to force us to pay taxes on their network,* and jail everyone who uses the other network. What power will they have if no one takes their money to enforce this threat? The decision, right then there and now is forced upon everyone. Ok, maybe not at one instant, but the people are going to have to decide how next to proceed, and that is the ultimate power of the system. No longer could we be enslaved by a monetary system as long as we choose not to be.

* - I am not making an anarchist argument about whether or not we should pay taxes. I am saying that the government could try to force its population to use a dishonest network by only accepting tax payments on it.

What r ur plans regarding the implementation? It would be very interesting to see how this works.