Decrits: The 99%+ attack-proof coin

[AnonyMint]

I am trying to coherently visualize a system something like yours, based on some limited ideas I've extracted thus far.

Seems you propose that the transaction peers (SH) put up some capital so they can't be created out of thin air, then they get to sign a 10 second periodic transaction block (TB) in an order determined by the periodic (at CB time) hash of the SHs that have joined. The SH can't game this order, because each SH hash is locked in before the CB ordering hash is determined. You might even modulate this ordering hash by a hash of all transactions in the CB, to provide more entropy in case no new SHs have joined since the prior CB.

This actually solves the #2 problem in my proposal, so I must tip my hat to you (except for the problem below of identifying the good from the bad consensus fork). Indeed grabbing the entropy every day or so at CB time, is much more randomized than grabbing it every TB (even even 1 of the intervening TBs was honest then the hash is randomized, which is why you say 99.9% attack). Kudos! I will link from my proposal to this post.

(note see my later comment, which is why I am not doubting the randomization and have put it in strikethrough above)

Seems these intervening TBs are already a consensus before they are recorded in a CB, because their order was dictated by the prior CB. Only the SHs with the correct private keys can sign the TBs, as dictated by the order determined from this hash of the prior CB. SHs that join since the prior CB aren't included until after the next CB.

So why penalize SHs for not signing a TB, since they can send a TB with no transactions any way?

The idea that some of the SHs will be honest (even if a tiny percent) and want to sign a TB since I assume they get (50% of) the transaction fees. So thus eventually transactions get processed.

I guess you have SHs sign the next CB, as a way of recording a consensus of which SHs exist and to form a consensus on the ordering for the next intervening TBs that follow the consensus signed CB? Any SH that doesn't sign, can't be in the next ordering.

So then if rogue SHs want to sign a rogue CB that excludes TBs signed by other SHs, then they get penalized for not signing in the consensus CB. So they will lose their capital in the consensus CB whereas the honest SHs will lose value in the rogue CB.

It should be clear which is the rogue CB, because it will have less TBs than the honest CB? Incorrect! The rogue SHs can withhold sending their TBs to the honest SHs, so the rogue CB can appear to have more TBs than the honest CB.

So far, I am seeing some merits to your idea, but I get stuck on identifying the good fork from the bad fork.

I am hoping we have the solution to the Bitcoin weakness.

[1446676128]

1446676128

[1446676128]

1446676128

[1446676128]

1446676128

[Etlase2]

There are so many details that you are skipping over here.

Some are explained throughout the thread, but I do tend to be wordy. This is the result of 2 years of ideating, and I had to focus on 4 completely new things, not just one, in the OP. I have around 50 or more pages of notes, and I wanted people to ask good questions and test the system rather than write a 20 or 30 page essay. But I was probably unconsciously obtuse in the OP with regards to section 1 because it is my baby.

Assuming you mean that every SH has to sign to each CB (the one that comes every days and should be a compilation of all intervening TBs), are you assuming that is random because of new SHs entering the SH pool since the prior CB? And so are you saying that each SH chooses a hash for itself when it joins, then it can't game this because it can't know a priori which SHs will enter the SH pool before the deadline of the next CB?

No, it is random because all the TBs are created, then the CB compilation is signed by everyone during the next "potential" CB. There would be a delay of whatever the amount of time is given for SHs who missed their TB to sign the CB before losing their stake, probably around 3 CDs. Until that time is up, the SHs just sign TBs in the already predetermined order. An additional delay after the 3 CD period of perhaps 1 CD can ensure that everyone has all of the signatures who have signed, and at that point the new random number will be used to determine who is making TBs. These are things I don't have *exact* numbers for, but it is just a matter of weighing a few pros and cons when development gets to that point.

If my assumptions above are correct, then it means new SHs can't be selected to sign a TB until after the next CB.

This is correct.

But I am confused because it seems you may be referring to a hash of signatures of SHs which signed the TBs that in the CB? Because why is signing the CB relevant?

The hash just combines all the signatures together for the random number. It has to be the hash of the signatures, otherwise the last person to create the TB can adjust his TB in a million different ways to create a million different random numbers. If it is only a hash of the signatures during the next CB period (for which he has no info), he has only the choice of two, and one will cause him to lose his large deposit.

You need to explain your system much more eloquently and tersely. It is very difficult to grasp the fundamental design in as few words as possible.

Well, it's a big concept, and there are not many people around here willing to think on different terms from bitcoin. That is why I try seeking those people out when I think I see them. Fewer still are going to be able to "get it" even if the OP is 30 pages. I would much prefer people to ask questions so that I can answer them and refer back to the answers for those who think they can spot vulnerabilities.

How do we prove which is the attack chain and which is the honest chain? Please try to be clearer in your writing. Write with the perspective of the reader who has no idea what is in your mind.

This is for the scenario where the attacker doesn't control the CNPs--which should be *significantly* hard. The honest network will add the evil network's TBs to their chain, but with the warning that they have not acknowledged many signatures attempting to achieve consensus. It's not even a warning, it's just something the clients can figure out based on the data. The honest TBs show that these signatures exist and that the evil network has not included them. The evil network can NOT do the reverse because then it is just continuing consensus. Therefore one network has all the signatures--the honest one--and one network has only some of the signatures.

We pay the bankers to enslave us. Don't use capital as a defense, because socialism always gives more capital to the those who will promise everything to the masses.

Capital is a defense because decrits capital cannot be created out of thin air. Someone who attempts to take control of the system must have a massive investment in the system. No early adopter will have power like this because bitcoin has the most retarded currency distribution scheme in the history of money. Decrits money cannot be monopolized by minters or early adopters, and it can't be purchased in massive fiat amounts because new currency will be distributed randomly to bring the price back down. Everything syncs together.

I have no idea what makes a CNP different than a SH. Because your proposal is so complex, it sounds like handwaving.

SHs are section 1, CNPs are section 2. SHs create the network data, CNPs distribute it. The requirements for being a CNP are lighter because each individual CNP is not critical to the network. They won't have to be online at a specific time or risk receiving a soft strike. Yet they still have a say in the network, because honest CNPs will not distribute the TBs of SHs who are being malicious by denying important transactions. This means that taking over the network requires taking over both halves of the network.

Please try to reduce it to simplified first concepts. So we can see what you are actually proposing which is unique and do thought experiments on failure modes.

I am not sure that it is possible to reduce it all that much, because reducing it inevitably leads to accusations of vulnerabilities. While most of us here have a deep understanding behind proof-of-work because we have read lots of things to understand it, it is complete gibberish to most people. I have been asked to write a white paper, but I don't think proof-of-consensus can be proven independently of the surrounding system. Proof-of-work is fairly easy in that regard, but it also leaves gigantic vulnerabilities (51%, etc.) wide open. I suppose a white paper could say that additional SHs can join for a significant number of proof-of-work tokens (decrits), and then that proof-of-work remains as a valid percentage of all proof-of-work unless its creator does something recognizably bad such as approving a bad spend or creating two TBs for one time period. That also demonstrates the energy efficiency of the system.

Okay I like this fundamental conceptual point. Missing signatures apparently is a key aspect of your design. But no where in your original explanation do you start by explaining this. And I still don't understand how technically that can be enforced on a fork.

It can be enforced as a fork because unless the evilcorp killed the people running those SHs, they are still out there transmitting TBs. If a large group is missing, nodes will be massively on-edge trying to find someone transmitting their data. From each client's perspective, if consensus was at 99% yesterday and it is at 90% today, big warning signs should be flashing in the client that something is not right. This is why consensus is infinitely better than proof of work. There is no simple way to know how trustworthy proof-of-work is. Consensus either is or it isn't, and if it isn't, be *extremely* cautious.

At this point, nodes who have not been paying attention to the network will have a tough time deciding which is the real network (but not *that* tough because unless the attacker has been part of the network since its inception and has grown along with it, it will look obvious based on the consensus history which network is the one attacking).

How is that technically identified and please explain it in simple language?

Shareholders sign a ledger that acknowledges the state of existing shareholders (the hash of this ledger) prior to their joining the consensus. This ledger contains the history of shareholders joining and leaving the consensus since the genesis block. Each piece of information is heavily bound by about 100 bytes of data so even many years down the road this block will be a small and easy to transmit. When SHs sign out, they sign this block again, essentially saying that "at this point in time, there are no problems with the network," this is proven because his signature is on the current consensus-approved ledger!--the state at which (almost) all SHs last agreed on consensus.

However, when people do not sign out of the ledger and they do not sign the current consensus, the eventuality of this is a loss of 3k DCR, something that is supposed to represent a significant enough amount of money that people will not lose it lightly.

So, while this next part is not some guaranteed, fool-proof way of identifying a malicious network, it makes a whole lot of common sense: as each shareholder leaves the network to retrieve his 3k DCR back, he signs the block again proving that consensus was reached among the rest of the shareholders currently signed in. If we follow this chain from the genesis block, the evil network must be in place almost throughout the network's history to look as if it has as much of the consensus's agreement as the honest network. The honest network will have the ongoing consensus of the entire network's history on its side. The malicious network will be comprised of mostly newer SHs that have not been seen in consensus with any of the historic SHs.

I made the example of how bad it looks to perform a 51% attack on a network with 100,000 honest SHs in the second half of this post. If the network is at 100% consensus with 100k honest SHs, and 101k evil SHs join up to perform a 51% attack, the evil network will have 0% consensus while the honest network will have 49% consensus.* This is not a realistic attack (you'd have to be incredibly rich and incredibly stupid), but it identifies the mechanism.

* - The 49% figure is actually not correct, it will depend on how many SHs had signed out previously, but it gets the gist across. This is a client-side activity so how it ends up determining these figures is not set in stone. SHs who signed out were not attacked by any of the existing SHs at the time, so their weight is added to those that are still around. This weight continues on until we get to a point where two networks exist, one with far less people having approved of them and there is an *ongoing network attack* that is causing a whole bunch of prior, honestly performing SHs to potentially lose their shares.

Capital can buy many peers. How to identify which ones are the good ones? Especially if the bad ones are only dropping transactions from those not playing by the rules of their cartel which by that time includes most of the popular merchants?

You are coming from a different attack scenario that I can see is based on what you posted about bitcoin. But this really can't apply. The big players can not drown out the small players. Sure, they can delay transactions, but they can't eliminate them. They can't change transaction fees, because that is akin to changing the coinbase reward in bitcoin. It isn't acceptable behavior. They can fail to acknowledge TBs that do not please them, but unless they also control the CNPs, doing this will cause an irreparable fork. At this point, it is up to the people to decide which network they want to use. Would you think perhaps people are more enlightened about money if they are using a system such as this? Would these megacorps be able to convince everyone to use their fork that they created through force? Governments could try, but when it is as simple as clicking a button or two to deny that network all power, it is an awfully big chance to take. If they fail, which is something that can only be decided by the people, they lose the entirety of that stake and massive amounts of power.

You are talking about all things in your mind which the reader has no clue about.

I have explained a lot of these concepts throughout the thread.

The internet can't propagate reliably in 10 seconds. I guess you assume these have to propagate by the next CB?

I haven't devised an exact system. It will be much faster than the next CB though. TBs will have to propagate within perhaps a 10-TB window. Because CNPs will be encouraged to connect to each other in a big hub-and-spoke kind of fashion, propagation time should be very low. The math of this will have to be gone into detail to make it as unlikely as possible for an evil group of SHs to attempt denying an honest SHs TB from being approved within the window. CNPs will be encouraged (via the client software) to drop future TBs that do not acknowledge TBs that it has seen, and this may eventually require user intervention on the CNP's part, or it would require a SH to have missed this chain because of the dropped TBs and include it (for each malicious TB that does not propagate, the window extends another TB). This could cause a mini-fork, and it's a pretty complicated concept that I haven't fully fleshed out to be honest. Worst-case scenario a number of TBs is picked that is fairly resistant to even an 80 or 90% attack because the attackers can't be presumed to control everyone or the network fails on principle. In this instance, the worst the attackers can do is cause a few SHs to receive soft strikes once in awhile. It is an attack vector, but it requires much more than 50% of SH control to perform it at all reliably, and if it takes too long for EvilCorp to get an honest SH kicked out (soft strikes are eventually forgiven), then it can't do anything. They won't be able to target specific SHs, only random ones, so this process will be very difficult and take lots of time in which more honest people can join, or worst-case the ongoing attack is identified and something that isn't automatic is done about it.

So how can we avoid duplicated transactions in the TBs? Or are duplicates okay and somehow they get merged for the CB?

Duplicates are ok, and they don't require much data as I've already pointed out. If a TB is delayed (or the SH fails to create it), the next TB in line can include the transactions for that window so that they are "approved" in a timely manner. However, if this TB is missing, large face-to-face transactions know to wait until the missing block can no longer replace the transactions in the following TB. You might have to wait a few minutes for large purchases, but small purchases have far better security than 0-confirmation bitcoin transactions.

But if there is no consensus until the CB, how does anyone trust a TB until it is in a CB after days?

Based on the current consensus. In addition to signing the CB, the SHs are signing the ongoing changes as well. If the chain of transaction blocks is relatively complete, a network attack/split/whatever is not currently in progress. The one risk you take is that the network may be attacked or split within the next few days. Even then, unless your transactions are being specifically targeted, you are probably completely safe, similar to bitcoin. If your transactions are being targeted, well seeing as how EvilCorp has been handled so far should assure you that your transaction is safe on the honest network. EvilCorp will have to create a network split just to deny your transaction, and then must get the entire world to agree that his view is correct.

If the network split is legitimate--say the government of one country has shut down its peoples' outside access to the internet--everyone knows which network is on the outside, and not to implicitly trust transaction security if you are on the outside too. I don't believe that governments will have this power for long though, as meshnet technology is advancing, and supporting a network like this could be its raison d'etre.

Could you unpack that into english please?

EvilCorp can't perform any useful attack (delaying inevitable transactions is not useful, only annoying) unless they intend on forking the network in which case they will lose all of their money unless they can convince everyone that they are actually honest. The system is undefeatable.

Realize that without peer review, you can't be sure that there are not holes in your design. But if we can't understand what you are saying, we can't review it.

There may be unforeseen attack vectors, but they will be far less powerful than bitcoin's 51% attack. Peer review is unlikely to catch these anyway. A wiki is being set up by Ukigo so I can start explaining this in a drillable-down format so that the answers to advanced questions are easy to find.

[Come-from-Beyond]

This is the result of 2 years of ideating, and I had to focus on 4 completely new things, not just one, in the OP. I have around 50 or more pages of notes, and I wanted people to ask good questions and test the system rather than write a 20 or 30 page essay.

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

[Etlase2]

I guess you have SHs sign the next CB, as a way of recording a consensus of which SHs exist and to form a consensus on the ordering for the next intervening TBs that follow the consensus signed CB? Any SH that doesn't sign, can't be in the next ordering.

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.

It should be clear which is the rogue CB, because it will have less TBs than the honest CB? Incorrect! The rogue SHs can withhold sending their TBs to the honest SHs, so the rogue CB can appear to have more TBs than the honest CB.

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.

[aaaxn]

I have around 50 or more pages of notes, and I wanted people to ask good questions and test the system rather than write a 20 or 30 page essay.

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.

[Etlase2]

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

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.

[AnonyMint]

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.

[AnonyMint]

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.

[AnonyMint]

The only way to get consensus is to give absolute power to a peer to decide for each TB. The author needs to clearly address this fundamental point first.

both face the same problem which is how to select the next peer? Where does the entropy come from that can't be gamed?

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.

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

[Etlase2]

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.

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.

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

Correct.

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

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.

But how can all SH know what the hashes of all SH are, until they sign?

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

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.

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.

I am ignoring issues about separating minting from transacting

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

[NickCoin]

Any TL;DR version? Or something long but for humans with IQ<160?

+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!

[Etlase2]

Sorry to ruin our day

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

[AnonyMint]

Any TL;DR version? Or something long but for humans with IQ<160?

+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!

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

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.

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.

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

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

[Impaler]

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.

[Etlase2]

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.

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

Do we need randomization? (I think so) What we want is that all peers get a turn.

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.

[AnonyMint]

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.

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

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.

Do we need randomization? (I think so) What we want is that all peers get a turn.

All peers will get a turn regardless. The function can only determine the order.

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?

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.

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.

[AnonyMint]

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.

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.

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

[Etlase2]

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?

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.

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.

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.

[Impaler]

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.