Decrits: The 99%+ attack-proof coin

[Etlase2]

Proof of work produces money, it does not secure the network--so it is not just as bitcoin. I don't know what "ah ha" moment there is to be had here that isn't already explained in the OP.

[kokjo]

Proof of work produces money, it does not secure the network--so it is not just as bitcoin. I don't know what "ah ha" moment there is to be had here that isn't already explained in the OP.

so you are just wasting alot of resources then? good choice!

[brenzi]

It's not really proof-of-burn as described in that wiki page. You aren't giving up any currency, just a smaller proof of work.

To avoid misunderstandings, I'd replace or explain the word "burn" then.

You are building quite a complicated scheme to to avoid a hardware-upgrade race which I'm not convinced that it really works the way you intend it to (ASICs compete with ASICs, GPU with GPU). Being engineer I tend to believe in simple solutions. Complicated solutions usually do not behave well in unforeseen situations. Let them build ASICs. Let them adopt whatever new technology. Just make sure that the energy use stays at a reasonable level. High enough to get your link to real world basket (if it's too low, people might find ways to get the energy "for free", like electricity thefts) , but low enough not to really matter ecologically.

But looking at Decrits potential energy use I fear that the problem I pointed out earlier for the case of bitcoin is not solved entirely by your proposal.

As Decrits shall have a stable value, energy use for mining doesn't rise with the coin's value like in bitcoin's case. Instead, you're proposing to adjust the mining reward (in number of Decrits) to the demand for the coin. So if demand rises, energy consumption rises. Then you propose:

B. Producing Energy Efficient Currency All of the difficulties associated with minting are in place so that new currency is created only when the value of Decrits are profitably above their cost to produce. However, this is not at all energy efficient. To provide energy efficiency in currency creation, free money will be distributed to users of the network (not minters) based on minted money. 5x the MB award will be given to either the sender or receiver of a random set of transactions during a certain time frame before (and potentially after) the MB based on multiples of the tx fee; 5x will be awarded to a random selection of accounts based on each account's percentage of the total amount of currency in existence. If a second MB is started within a time window of the first, these multiples will increase to give out more free money in response to network expansion. More details: at the end of this post and here.

Giving 10x the award to somebody else than the miner is just a leverage ratio to energy use but it scales all the same. But I see you propose to adjust this ratio according to the number of transactions. Can you provide more info on this adjustment algorithm? How can you make sure that energy use stays at reasonable level?

[kokjo]

But looking at Decrits potential energy use I fear that the problem I pointed out earlier for the case of bitcoin is not solved entirely by your proposal.

you can't compare them on that point. bitcoin's consumption of energy is useful and constructive, while Decrits' is just destructive. not good man not good.

[Etlase2]

You are building quite a complicated scheme to to avoid a hardware-upgrade race which I'm not convinced that it really works the way you intend it to (ASICs compete with ASICs, GPU with GPU). Being engineer I tend to believe in simple solutions. Complicated solutions usually do not behave well in unforeseen situations. Let them build ASICs. Let them adopt whatever new technology. Just make sure that the energy use stays at a reasonable level.

It really isn't that complicated when you're talking about devising an efficient system to create currency. The intent isn't that ASICs compete with ASICs and GPUs with GPUs, the intent is to make it so that ASICs are totally, absolutely unprofitable compared to sunk hardware costs. Why? Because as your thread eloquently points out, energy consumption does not depend on efficiency. Why encourage the development of ASICs which will take at least hundreds of thousands, if not millions of dollars in resources wasted to build the machines, and a shelf-life of who knows, maybe 5 years before it enters the trash as a completely useless piece of silicon? It isn't just electricity that is consumed in the process of protecting bitcoin or creating money, it is resources as well, and the only fair way to account for both is how much money is spent.

Let me propose a real-world scenario. I don't have an exact idea of how the numbers will work yet or how much ASICs will cost to produce, so bear with me.

Let's say the total number of decrits is 10 million and the network has seen a big increase in usage that requires 10 million more decrits to bring the price back to its oscillating point (its current trading value is double its cost to create). Let's say the MB award is 50k decrits. That means at the first block, 550k decrits are produced, the second 650k, 750k... 1450k (based on increasing multipliers described here). All in all, minters create 500k decrits while 9.5 million are given away.

If sunk hardware costs of GPUs are creating these decrits, we need only worry about the electricity cost. If a coin sells for $2 and costs $1 in electricity to create, the GPU minters will profit $50k on the first run while the network profits $1000k (free money). Now decrits only sell for 2*10m=x*10.55m or $1.89. In the next block, minters profit $44.5k while the network profits $1,229k. As you can see, profits for minters start dropping while profits for the network increase. The amount over the 10 blocks that minters make in profit should average around $250k (actually less, because of the burn) while the network profited $9.5m. A total of $10 million of value was transferred to the network at the cost of $250k in electricity. Now it's over and the price is stable again near its cost to produce. (Energy usage = 0)

We'll say that 25,000 GPU minters were involved in creating these coins because the award for each person in the MBQ is around 2 decrits (because the block is expected to go around 7-10 days to use a dollar or two of electricity). If 100x faster ASICs cost $1000 and use no electricity, 250 ASICs cost $250k, for the same net profit of $250k. If 10x faster ASICs cost $500, massive net loss. But of course ASICs do use electricity, and plenty of it, and competition will simply raise the difficulty to reduce their profitability.

Now because of the whole "ASICs vs ASICs and GPUs vs GPUs" that I talked about in another post that you referenced, GPUs will still be able to make a profit while the ASICs are doing this, lowering their profitability. ASICs can take the brunt of the more expensive, early burn, while GPUs hop on for cheap. If enough of them do so, the profitability of ASICs is further reduced. This is a "GPU defense" mechanism for the attempt to upset the balance required to produce new money. The point is to make specialized hardware unprofitable so that the resources will not be wasted to make it, because while a GPU's cost can be amortized over its use as a vital computer component, an ASIC has one job before hitting the trash can. A total, absolute waste.

Giving 10x the award to somebody else than the miner is just a leverage ratio to energy use but it scales all the same. But I see you propose to adjust this ratio according to the number of transactions. Can you provide more info on this adjustment algorithm? How can you make sure that energy use stays at reasonable level?

It doesn't scale all the same, because the cost to produce decrits remains unchanged. Bitcoins cost to produce will forever rise to meet a profitability margin (assuming the network expands), and bitcoins must always be produced to secure the network (producing being new currency or tx fees, as the result is identical). The only way to lower bitcoin's energy cost is to reduce transaction fees as the network expands, which requires the people who will profit most to agree to do this, as well as fostering centralization--less profit, less people interested in securing the network. And there is no steady state. When decrits cost about as much as they sell for, no one creates decrits. With bitcoin, coins must constantly be produced or the security of the network is at risk.

The energy usage of decrits is quickly bound by profitability. The longer minters mint, the less profit they can possibly make. And the vast majority of the overall profit of the system goes to the network transferring value from fiat or other forms of wealth into decrits. Once coins are created, they are never "re-energized" again such as is the case with bitcoin. Once there are enough decrits to suit the population that wants to use decrits, the energy use of the system borders on zero--only tx validation and costs of running a node. Bitcoin borders on using enough energy to re-energize all new currency and all tx fees each block at a profit. One system tends to a zero state while one system tends to an extremely expensive, wasteful state.

[brenzi]

Thanks for your detailed explanations.

Let's say the MB award is 50k decrits. That means at the first block, 550k decrits are produced, the second 650k, 750k... 1450k (based on increasing multipliers described here). All in all, minters create 500k decrits while 9.5 million are given away.

I'd appreciate it if you could set up a documentation page/wiki. Your references to other posts tent to be tl;dr. Especially if you only want to reference one sentence out of a long post.
Pseudo-code of your algo would be very nice.

OK, your increasing multipliers indeed address the problem of energy consumption. I didn't get it right before. But if your control algorithm for money supply reacts exponentially to demand, You are very likely to overshoot your target supply.

Let's bring in some control theory (Yes, I love to apply it to economics): A PID controller is very stable, if correctly tuned. As I understand your algo, it compares approximately like this:

P: Not used in your design
I: Is your link to energy use that should stabilize Decrits value in the long run.
D: Is what mainly determines your MB award and giveaway multipliers. As you even put an exponential characteristic to it, you should expect heavy overshoot. As Decrits money supply is monotonically increasing, one cannot really compare it to a control algo, as there will never be a negative delta on money supply. This way your money supply cannot oscillate around the target value but will just be stuck after overshooting and wait for reality to catch up (if it will).

I can't say for sure that it won't work out. But I suggest that you really simulate your money supply algo. If you give me pseudo-code (or write it in octave right away), I might be able to support you with this.

[bce]

The thing with proof of stake coins seems convoluted, encourages wallets to remain online, and that introduces points of failure...  I haven't read all of the pages of text here, but one thing really gets me -

The name:  Decrits.  

"Do you have any credits?  No, I'm all out, but I have some Decrits..."

Decrits.  It's everywhere you want to be!  

Tenebrix or Fairbrix might have been better names than Decrits, but they've got nothing on Litecoin.

Whatever success and merit this coin may have, it'll have been wasted on its name.

Here's a raised glass toasting out to anyone who can do an exact 1:1 copy of the eventual Decrits that has a better name, like any name one could think of that isn't Decrits.  

Eltase2 - even IF this whole thing is a waste of time (the thought you've put into it),  for all of the text you've spent composing here, it'd be good to spend at least some on revising the name before going further (unless making something successful of those Decritss isn't important).

[Etlase2]

I'd appreciate it if you could set up a documentation page/wiki. Your references to other posts tent to be tl;dr. Especially if you only want to reference one sentence out of a long post.
Pseudo-code of your also would be very nice.

Sorry, I thought you had read that post because of the ASIC vs ASIC thing, I must have mentioned it somewhere here or whatever.

OK, your increasing multipliers indeed address the problem of energy consumption. I didn't get it right before. But if your control algorithm for money supply reacts exponentially to demand, You are very likely to overshoot your target supply.

Possibly, probably. This is part of the reasoning behind the initial burn. If 7-8% of the MB award is wasted prior to the award beginning, there is some indication that the supply is too low prior to increasing it.

I can't say for sure that it won't work out. But I suggest that you really simulate your money supply algo. If you give me pseudo-code (or write it in octave right away), I might be able to support you with this.

I will look into this later.



bce: I don't care about the name, just as long as it isn't *COIN LOL. And part of the reasoning behind 10 day consensus periods is so that share wallets do not have to remain online much, just in their window. There is also the noted idea I have for a general "account restrictions" type block, where one could assign a master key to a share or any account that can control/limit what the primary key is able to do--intended for hot wallet design as well.

[Etlase2]

I thought about PM'ing you this brenzi, but this is the real type of discussion I want.

I have not gone into detail and am not really willing to go into detail on some of the numbers behind things like deciding the number of coins in a mint block because these are things I want input on. I *do not* want to make those decisions lightly. **Everything in the following post is an ad-hoc example of how the system could potentially work.**

There are two major scenarios to consider with these magic numbers:
1) When the network is small, all bets are off. We can't make any assumptions about how the network will expand, so we must be ready for anything. One defense for this is to make the post-bootstrap minimum block award fairly high. This should cause a bit of deflation assuming the network sees some kind of demand, but it will protect from overshooting too much.
2) When the network is large, we must be looking to some specific percentage of transaction activity to gauge the number. Being ledger-based, it is fairly easy to keep track of useful network information such as transaction activity over certain periods.

In section 1), overshooting isn't such a terrible thing. People are getting rewarded for using the network. A lot of this depends on how quickly price stickiness might come into play. If the price recovers from 2 early overshoots, people would be unlikely to be afraid of "buying low" on the third overshoot. If there could be a P in the PID, then that would be it: opportunity. Can I guarantee people will think this way? No. Is it worth trying? F*** yes.

In section 2), the stance I think is the most useful to take is to make the free money system random, fair, and meaningful, and extrapolate from there to see where our numbers need to be.

Let's say the "network" GDP (on-network txes) is DCR1billion. 50m txes if the average tx is 20 DCR. Something meaningful must be awarded, let's call it 1 DCR. And we want to award txes within a 30 CD window of the MB, a 1.67m tx window. We want to award 10% of those. 166.7k. If we want to award at least 1 DCR, we must have 166.7k/10 or a 16.7k MB award. We're increasing the money supply 183k/500,000k (huge guess that V = 2, but what else can I do?). 16.7k means about 8-10k minters are ready and willing to create money. Is that too low? 183k/500m is a really small percentage, and 8-10k minters seems low, but if each active decrits user spends 1k decrits a year, that is 1 million users, so the minters are about .8-1%. That seems quite reasonable. How much in transaction volume do we wait before allowing a MB to be created? The same 30 CD period or perhaps a 10 day period as that is about how long a MB is intended to take?

And the function is not exponential. It is quite linear, it just starts off with a boost. 10x additional, followed by 12, then 14, then 16, and so on, assuming my initial figures.

Two new ideas I came up with recently that I have not posted that are related to the multipliers: 1) increase the tx volume required before starting the next mint block by 5 or 10% more for each consecutive block that would cause the multipliers increase. This further puts a brake on money creation if money creation doesn't appear to be needed. 2) Reduce the multipliers back down gradually so as not to have all the minters stop when it gets too high, and wait the amount of time (I was thinking 30 CDs) before the multiplier resets to 10. Instead they may have to wait 10 or 15 CDs after the end of a mint block for each multiplier to go back down. This is to prevent minting abuse rather than overshoots though. It will also allow for a big expansion, a rest period, and another big expansion without too many beats skipped.

I see about a 1% increase in the money supply by block 10 in a row, but I may be starting to fudge all the numbers together. At block 10 it's a 1% increase (well, on the base 500m), plus 1-9 equalling a 4-5% increase in the supply over a 100-150 CD period. That also seems reasonable.

So basic gist:
1) Keep the reward meaningful, random/fair, and plentiful (large percentage of people are awarded)
2) Keep minters to <2% of the population. Otherwise we're probably wasting too much energy.
3) Allow only small movements in the money supply at the beginning and allow it to gradually increase if necessary.

I think even the relatively simple scenario I came up with here is a decent base line where everything fits up reasonably well. Does the money supply increase too slowly though? Is it ok if we go through a semi-extended period of deflation, or at least prices that are well above the cost to produce? (How often is a cryptocurrency likely to double in demand in a year? Fairly likely if bitcoin is any indication.) In return, we should rarely if ever see prices go below the CTP. Maybe the last block will overshoot a little, but most of the minters are likely to hold and wait in this scenario. Or if prices are sticky enough, just use the currency and not worry about its fiat value.

What I think is a neat possibility is post-bootstrap setting the block award high, then if there are not enough txes in the 30 CD window to award 10% 1 DCR--money is left over, hold the rest and continue to award it over time, to encourage further adoption and no "missed opportunity". This is yet another brake and incentive all at the same time.

edit: and for all of that I forgot to take into account tx fee gaming. This is protection I knew was necessary even in the original decrits proposal. So if we award 100x the tx fee, we may only award 1-2% of txes (half go to sender, half to receiver) so that it can't be easily gamed during "expected" periods. If we award most of the money to transactions that occurred prior to the MB, we mostly resolve this issue, but it could get complicated when the network is expanding. Or perhaps not. It is just something to keep in mind.

[Etlase2]

Can we have full-describing paper on Decrits,
or maybe (even better) : dedicated wiki-site,
with all variants of proposal published
separately there ?!

I did a wiki for encoin, though it eventually got taken down. I admit it would be nice, but it's very time-consuming, and I'd really rather like to have discussions such as the one I am having with brenzi before going through the motions only to have to change everything. But I could certainly do an extended proposal type deal like I did with encoin. I don't know, there are too many directions to go, and I have a finite amount of time to spend on this.

[Come-from-Beyond]

Bump to attract more attention to the idea.

[AnonyMint]

The author of this proposal emailed me to ask for a link to my proposal that reduces energy:

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

And asked for my opinion on his proposal.

I can't digest the proposal, because it appears to be (on quick glance) missing some critical details, such as how the next SH for next TB is selected. If you have millions of SH, this is critical as your turn may from a practical stand point never come in time, thus is another vector that can be attacked.

In all my thought experiments, consensus fails because no one can differentiate between the rogues and the accurate baseline. 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. Perhaps if he clearly addresses this, it will become clear to him that I am correct in my assertion.

For example, the author proposes penalty mechanisms to drive consensus, but the problem is how to reach consensus on the recording of penalties? Which fork of the TBs will the people use as the record? The rogues might assess penalties to the good guys claiming that the good guys didn't sign in time. And if the rogues sign TBs but don't put all transactions in them, then control a large % of network, they effectively make undesired transactions incredibly slow (if not forever depending on the ability to game the next SH selection algorithm).

[kokjo]

In all my thought experiments, consensus fails because no one can differentiate between the rogues and the accurate baseline.

this!

[AnonyMint]

Comparing my proof-of-harddisk space work and this proof-of-share, they both have a mechanism for limiting the number of peers to some real resource (harddisk space or money respectively). The peers are rewarded for processing transactions with fees and/or creation of new money.

In addition to the consensus problem I asserted exclusive to the proof-of-share, both face the same problem which is how to select the next peer? Where does the entropy come from that can't be gamed?

See my explanation (see item #2):

https://bitcointalk.org/index.php?topic=160612.msg1955800#msg1955800

[Etlase2]

I can't digest the proposal, because it is missing so many critical details, such as how the next SH for next TB is selected. If you have millions of SH, this is critical as your turn may from a practical stand point never come in time, thus is another vector that can be attacked.

I have mentioned how this works in a post or two in this thread. The hash of the SH signatures signing the CB is used to generate the next random number. At this point there is a slight weakness where the very last person to sign the CB has two options in determining this random number: sign the CB and come what may, or don't sign the CB and lose 3k DCR. The CB will only be signed in the order of SHs, so an attacker will not be able to determine which of his sockpuppets could use this best to his advantage. And in a sufficiently large network, there will probably always be a few stragglers who missed their TB, so the attacker will have to play a dangerous game just to potentially choose one of two outcomes of how CNPs are paid, for example.

In all my thought experiments, consensus fails because no one can differentiate between the rogues and the accurate baseline. 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. Perhaps if he clearly addresses this, it will become clear to him that I am correct in my assertion.

Perhaps you should wait for my reply before asserting your correctness. You claim no one can differentiate rogue and honest peers, I claim you are biased with a bitcoin view of security. In bitcoin, it is not easy to determine which chain might be an attacking one, or even that there is an attack occurring because of the nature of anonymous proof-of-work. With proof-of-consensus, TBs are tied to individual shareholders who can't be drowned out by someone with a bigger piece of hardware. An attacker wanting to "51% attack" the network is going to accomplish nothing better than causing two distinct chains: one that has (100 - attacker's shares)% consensus with (attacker's share)% of consensus provably shown to be working on a different (and incorrect) CB, whereas the attacking network must ignore the honest chain.

A smarter attacker might instead keep his TBs lying in wait in an attempt to make it look like the honest network is the evil network and dropping valid TBs, but there is an easy first line of defense to this: the CNPs. Honest CNPs will not transmit data that is obviously out of order, so not only must an attacker control a large portion of the consensus, but he must also control a large portion of the network itself, akin to controlling the entire internet in a sufficiently large system. Since CNPs are paid for their work, a very large constituency of the honest decrits-using population will be incentivized to be monitoring the network at all times, and this same constituency is providing the view of the network. However, it is, in theory, possible that the attacker does also control a significant portion of the CNPs (at this point this guy somehow controls between 0.25-1% of all the decrits in existence in a system where currency production is unbound and distributed randomly), so there is also the second line of defense.

The second line of defense is that SHs, while generally anonymous in the sense that they can't be easily tied to an identity, are not anonymous in the sense of proof-of-work--this is the flawed view of consensus that the bitcoin proof-of-work security bias engenders. An attacking group of SHs can *not* hide that they are attacking the network because even if they control almost all of the CNPs, everyone still knows that there is a large percentage of the consensus missing because signatures are missing--you can never infer missing proof-of-work. Even the newbiest of newbie nodes can recognize this.

Now, the kicker comes in to play with the fact that no one is forced to accept anyone's view of the network. There is no concept of "there can be only one block chain" because this is a massive vulnerability. An attacker has no choice but to split the network into two groups, honest and dishonest SHs, with each side eventually destroying the shares of the other. 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). However, this is remedied in the easiest of ways: honest merchants and people are all going to claim they are on the honest side, while EvilCorp's massive collusion of SHs will not have many or any everyday merchants or people claiming it is the correct network. Even without this, the attacking network can't do *anything* nefarious because everyone is watching. They could only hope that everyone decides to use their network, *then* pull something nefarious. In the mean time, both networks have to operate fairly identically, or all nodes will be able to identify which one is doing bad things and use the good one.

In the end, sure it may cause some confusion. But to obtain this type of power over the network, nothing can be done in secret. Decrits will have to be purchased in massive quantities, empowering the network and causing more coins to be created and spread out. Once the attack commences and completes, the evil network will lose all of its shares in the honest network and whatever fiat power was used to cause this attack is destroyed and its value is now possessed by the users of Decrits. The attacker cannot simply reconfigure his hashing power attack to stay ahead of developer patches, his attacking power is now completely spent, impossible to use again. He has in fact done the opposite of what he likely intended: caused the power of fiat to weaken versus the power of the Decrits system.

And if the rogues sign TBs but don't put all transactions in them, then control a large % of network, they effectively make undesired transactions incredibly slow (if not forever depending on the ability to game the next SH selection algorithm).

"Incredibly slow" is a matter of opinion. Because TBs are 10 second windows, an attacker must control every TB in a row for which it wants to delay a transaction. Whenever an honest node is in the mix, it will add all transactions that were missed. Even with 50% control, delaying transactions for more than 20 or 30 seconds will be difficult and only random opportunity. Important transactions (such as coin blocks or shareholder joins) can't be delayed or CNPs will start dropping malicious TBs. In the future when/if there are more than 100k SHs (if the CB period is 10 CDs, there are 87.6k SHs required for a 1-1 SH->TB ratio per CB), multiple SHs will create TBs for the same time window with one having priority and future TBs acknowledging all of them, with the priority only being in regards to conflicting txes that would cause a negative account balance if both were allowed to be processed. Otherwise all transactions from all TBs for the same time window will be accepted as part of the consensus (or you try denying ones you don't like and causing a network split and back to the same scenario as before). This doesn't even require much duplication of data, being efficient has always been a key priority of mine--see this post.

[AlternativeCypt]

I have no idea what this is, but I'd mine it. 

[AnonyMint]

I can't digest the proposal, because it is missing so many critical details, such as how the next SH for next TB is selected. If you have millions of SH, this is critical as your turn may from a practical stand point never come in time, thus is another vector that can be attacked.

I have mentioned how this works in a post or two in this thread. The hash of the SH signatures signing the CB is used to generate the next random number. At this point there is a slight weakness where the very last person to sign the CB has two options in determining this random number: sign the CB and come what may, or don't sign the CB and lose 3k DCR. The CB will only be signed in the order of SHs, so an attacker will not be able to determine which of his sockpuppets could use this best to his advantage. And in a sufficiently large network, there will probably always be a few stragglers who missed their TB, so the attacker will have to play a dangerous game just to potentially choose one of two outcomes of how CNPs are paid, for example.

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

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?

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

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?

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.

In all my thought experiments, consensus fails because no one can differentiate between the rogues and the accurate baseline. 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. Perhaps if he clearly addresses this, it will become clear to him that I am correct in my assertion.

Perhaps you should wait for my reply before asserting your correctness. You claim no one can differentiate rogue and honest peers, I claim you are biased with a bitcoin view of security. In bitcoin, it is not easy to determine which chain might be an attacking one, or even that there is an attack occurring because of the nature of anonymous proof-of-work. With proof-of-consensus, TBs are tied to individual shareholders who can't be drowned out by someone with a bigger piece of hardware. An attacker wanting to "51% attack" the network is going to accomplish nothing better than causing two distinct chains: one that has (100 - attacker's shares)% consensus with (attacker's share)% of consensus provably shown to be working on a different (and incorrect) CB, whereas the attacking network must ignore the honest chain.

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.

A smarter attacker might instead keep his TBs lying in wait in an attempt to make it look like the honest network is the evil network and dropping valid TBs, but there is an easy first line of defense to this: the CNPs. Honest CNPs will not transmit data that is obviously out of order, so not only must an attacker control a large portion of the consensus, but he must also control a large portion of the network itself, akin to controlling the entire internet in a sufficiently large system. Since CNPs are paid for their work, a very large constituency of the honest decrits-using population will be incentivized to be monitoring the network at all times, and this same constituency is providing the view of the network. However, it is, in theory, possible that the attacker does also control a significant portion of the CNPs (at this point this guy somehow controls between 0.25-1% of all the decrits in existence in a system where currency production is unbound and distributed randomly), so there is also the second line of defense.

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.

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

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 genuinely hoping you have something good here, but you should be able to explain the essential aspect in a simple way please.

The second line of defense is that SHs, while generally anonymous in the sense that they can't be easily tied to an identity, are not anonymous in the sense of proof-of-work--this is the flawed view of consensus that the bitcoin proof-of-work security bias engenders. An attacking group of SHs can *not* hide that they are attacking the network because even if they control almost all of the CNPs, everyone still knows that there is a large percentage of the consensus missing because signatures are missing--you can never infer missing proof-of-work. Even the newbiest of newbie nodes can recognize this.

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.

Now, the kicker comes in to play with the fact that no one is forced to accept anyone's view of the network. There is no concept of "there can be only one block chain" because this is a massive vulnerability. An attacker has no choice but to split the network into two groups, honest and dishonest SHs, with each side eventually destroying the shares of the other. 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?

However, this is remedied in the easiest of ways: honest merchants and people are all going to claim they are on the honest side, while EvilCorp's massive collusion of SHs will not have many or any everyday merchants or people claiming it is the correct network. Even without this, the attacking network can't do *anything* nefarious because everyone is watching. They could only hope that everyone decides to use their network, *then* pull something nefarious. In the mean time, both networks have to operate fairly identically, or all nodes will be able to identify which one is doing bad things and use the good one.

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?

In the end, sure it may cause some confusion. But to obtain this type of power over the network, nothing can be done in secret. Decrits will have to be purchased in massive quantities, empowering the network and causing more coins to be created and spread out. Once the attack commences and completes, the evil network will lose all of its shares in the honest network and whatever fiat power was used to cause this attack is destroyed and its value is now possessed by the users of Decrits. The attacker cannot simply reconfigure his hashing power attack to stay ahead of developer patches, his attacking power is now completely spent, impossible to use again. He has in fact done the opposite of what he likely intended: caused the power of fiat to weaken versus the power of the Decrits system.

I have no idea how this system works. You are speaking about features which I have no idea how it works technically.

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

And if the rogues sign TBs but don't put all transactions in them, then control a large % of network, they effectively make undesired transactions incredibly slow (if not forever depending on the ability to game the next SH selection algorithm).

"Incredibly slow" is a matter of opinion. Because TBs are 10 second windows,

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

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

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

an attacker must control every TB in a row for which it wants to delay a transaction. Whenever an honest node is in the mix, it will add all transactions that were missed. Even with 50% control, delaying transactions for more than 20 or 30 seconds will be difficult and only random opportunity. Important transactions (such as coin blocks or shareholder joins) can't be delayed or CNPs will start dropping malicious TBs. In the future when/if there are more than 100k SHs (if the CB period is 10 CDs, there are 87.6k SHs required for a 1-1 SH->TB ratio per CB), multiple SHs will create TBs for the same time window with one having priority and future TBs acknowledging all of them, with the priority only being in regards to conflicting txes that would cause a negative account balance if both were allowed to be processed. Otherwise all transactions from all TBs for the same time window will be accepted as part of the consensus (or you try denying ones you don't like and causing a network split and back to the same scenario as before). This doesn't even require much duplication of data, being efficient has always been a key priority of mine--see this post.

Could you unpack that into english please?

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.

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

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