Decrits: The 99%+ attack-proof coin

[zerodrama]

Like I said, I thought it was interesting, but out of all the communities actually building anything it looks like Feathercoin is taking the lead.

A hopeful group of a few dozen computer nerds does not a foundation for money make.

Bitcoin has so many critical flaws that perhaps you are not even aware of, so you are willing to champion something that has one or two of the flaws "gussied up" so that you feel like you're accomplishing something. You're falling for the same trick, though.

Your glaring flaw is trying to shove all your fixes under one roof. Once you stop trying to do that and start promoting sanity in the PEOPLE rather than perfection in your SYSTEM, then you realize that half of what you set up is scaffolding and the other 45% is an application of a smaller component.

When you discover what that component is it will be a HUGE way forward.

I didn't set out to fix one problem with bitcoin and currencies in general, I set out to solve them all.

I don't care if it's a ridiculous notion--the point is to move forward, not backwards as bitcoin and its clones would have us do.

Fixing all the thing in all the same time is not a good sign.

[Etlase2]

Your glaring flaw is trying to shove all your fixes under one roof.

Actually, that's bitcoin's flaw. Bitcoin's security, distribution, and monetary schemes are all housed in one system designed to solve the decentralized cash problem. The security, distribution, and monetary schemes in Decrits are three separate entities. One has no control over the other. These are key concepts that I have spent 2 years developing. And it is a paradigm shift.

Once you stop trying to do that and start promoting sanity in the PEOPLE rather than perfection in your SYSTEM,

And again, you missing the real point. The better the system, the more people are willing to use it. Promoting an opportunity to profit off the backs of others for nothing is not going to engender a healthy ecosystem.

then you realize that half of what you set up is scaffolding and the other 45% is an application of a smaller component.

No, every piece has a very specific reasoning. The system, since it is made up of distinct entities, has more avenues of vulnerability. But none of these is as powerful as a 51% attack which can effectively destroy the network. And all difficult problems with the functioning of such a complex network have already been solved by me. I have admitted there may be unforeseen vulnerabilities. I have admitted some foreseen vulnerabilities. They still have nothing on the 51% attack, and I designed a system to respond (section 4) to anything.

Fixing all the thing in all the same time is not a good sign.

The currency is intended to evolve if I screwed up. The platform for evolving is part of the currency. It is an efficient, decentralized, adaptable attempt at making a complete replacement for fiat. Bitcoin and its clones can only replace each other.

[zerodrama]

Your glaring flaw is trying to shove all your fixes under one roof.

Actually, that's bitcoin's flaw. Bitcoin's security, distribution, and monetary schemes are all housed in one system designed to solve the decentralized cash problem. The security, distribution, and monetary schemes in Decrits are three separate entities. One has no control over the other. These are key concepts that I have spent 2 years developing. And it is a paradigm shift.

Now you're getting what I'm getting at. I think these could be presented as independent layers, no? Using the same or a convertible address space?

Once you stop trying to do that and start promoting sanity in the PEOPLE rather than perfection in your SYSTEM,

And again, you missing the real point. The better the system, the more people are willing to use it. Promoting an opportunity to profit off the backs of others for nothing is not going to engender a healthy ecosystem.

Just when I think you're getting it... Sorry but no. People don't care about function, they care about comfort. Smooth wins over cool. Always. Memes win over systems for the same reason. The way to promote health is the Flintstone's vitamins. Food coloring for health. (yes I KNOW LOLOLOL.) But that's your best option because as silly as as it is to think to solve a long term issue with short term thinking, in the end you get a model that adapts to both short term and long term challenges.

then you realize that half of what you set up is scaffolding and the other 45% is an application of a smaller component.

No, every piece has a very specific reasoning. The system, since it is made up of distinct entities, has more avenues of vulnerability. But none of these is as powerful as a 51% attack which can effectively destroy the network. And all difficult problems with the functioning of such a complex network have already been solved by me. I have admitted there may be unforeseen vulnerabilities. I have admitted some foreseen vulnerabilities. They still have nothing on the 51% attack, and I designed a system to respond (section 4) to anything.

So make it a toolbox. The best macro-solution to a 51% attack is forcing the attacker to satisfy all the diversity.

Fixing all the thing in all the same time is not a good sign.

The currency is intended to evolve if I screwed up. The platform for evolving is part of the currency. It is an efficient, decentralized, adaptable attempt at making a complete replacement for fiat. Bitcoin and its clones can only replace each other.

The only way I see to counteract fiat, is to question our universal use of it. There are plenty of off grid solutions as well as diversified economic ecosystems involving small and large scale currencies. You're trying to put a giant manual braking system on a machine that should never have gotten this large in the first place.

I think your concept has merit, but your approach will choke the very energy it needs to function.

[AnonyMint]

The energy efficiency is the key magnificent feature of this design. No need to buy hardware, simply buy some shares and earn a profit. This would be popular.

Bad money drives good money out-of-circulation. Money is supposed to be bad. It is human nature.

You could radically simplify this design and make it popular, if stop trying to end human nature and socialization of money.

Could limit SH, then let shares be sold on the market. Yet another reason to buy shares. Yet another demand for the currency and for a rising currency value. SH get the transaction fees, so their value is related to the expected velocity (usefulness as a medium-of-exchange) for the currency. How do or should try we stop users from sending their transactions only to SH which refund the transaction fees, thus driving down the value of SH shares that don't? Hey if they want to refund them to clients of their cartel, that won't always speed up their client's transactions, unless they own 100% of the shares, unlike the vulnerability I identified for Bitcoin cartelization.

Limiting SH, eliminates the overload problem. Every SH gets a turn within a CB.

A cartel could buy up all the SH, but they can also buy up 51% of the difficulty in Bitcoin. The difference is that unless they buy 100%, the transactions still go through (even though delayed by up to one CB).

Some honest people can buy initial shares and vow to always do good. I will be one of them!

I love it! Super easy to implement. Super popular.

Let's make money, compete with Bitcoin, and provide a better digital currency. How could life be any better?

What about minting? How could we improve on Bitcoin in a way that would be more popular or better performant? In a simplified view of the quantity theory of money, the money supply should increase proportional to the velocity. Since we have mandatory transaction fees, we can measure velocity, something Bitcoin can't do.

Also this design would fix the 10 minute delay for transactions in Bitcoin? Because the signing SH for each TB period is known in advance.

(be a realist)

Above I radically simplified Decrits' design.

The above post improved upon Bitcoin's transaction processing, while providing more early adopter speculator incentive than even Bitcoin's speculator model.

The remaining item was mining for new coins (i.e minting).

I had the thought that the most important function of minting is so users have an realistic option to obtain coins without converting from fiat.

Bitcoin fails miserably at that, because it requires ASICs and long-term capital bets and risks. Users don't want to commit to the long-term risk, just to obtain some coins without having to jump though AML identification checks and when the exchanges are down or just because it provides an alternative to the exchanges.

Find a solution to that, then we've got the winning design that trumps every aspect of Bitcoin.

I agree we need the incentives for speculation. And we need to reward the people who develop it.

And we need it to be as simple as possible. K.I.S.S. (Keep It Simple Stupid) is a famous engineering principle.

You don't need to include the kitchen sink or make a perfect society. You just need to make something that works and is popular. Later someone can make another that adds complexities, if they think the market wants it. Simplify implementation and quicker to market. Incremental development is a superior engineering principle.

As for stable currency, that is an illusion that can only be enforced by the state (until it fails and value goes to 0). Has gold ever been stable in price throughout history? No!

If you attempt something unnatural, you will surely fail.

Details versus big picture again.

The big picture is that bitcoin is a currency pyramid, and any design that copies this is going to meet the same fate.

That's not bitcoin's fault.

You did not understand what I was saying. It is most absolutely bitcoin's fault, not the fault of the infrastructure. Bitcoin is in every way a commodity that can be traded easily. It is not a currency. The mentality of "having to be there first" means that anyone who isn't there first will learn that it is a complete joke. You won't be able to keep finding a new breed of sucker when the presence of something that is actually designed to be a currency stands right next to it.

People are looking for an answer to the problems of modern money. Bitcoin keeps telling them that it is not that answer. That is why the lack of infrastructure you blame does not exist. This community feeds off of itself.

If you took the time to understand the implications of the decrits monetary system, you might actually find it to your liking, regardless of how I might proselytize.

Minting should allow users to moderate the price by creating new coins. The speculation can also go into the SH shares.

Yet minting shouldn't be able to destroy the price and speculation in the price of the coins. Speculation is necessary for price discovery. Return on capital is a necessary feature of money, otherwise no one will hold it (because the universe is always expanding, i.e. deflation is the natural result ... see the Second Law of Thermodynamics that the entropy of the universe trends to maximum, not a localized closed system).

[AnonyMint]

I had the thought that the most important function of minting is so users have an realistic option to obtain coins without converting from fiat.

Bitcoin fails miserably at that, because it requires ASICs and long-term capital bets and risks. Users don't want to commit to the long-term risk, just to obtain some coins without having to jump though AML identification checks and when the exchanges are down or just because it provides an alternative to the exchanges.

To earn minted coins, one has to show some proof of something that can't be created out-of-thin-air, else the earning of coins can be spammed.

The only proposals I know of:

1. Proof-of-Work based on computation, i.e. Bitcoin and Litecoin, which favors specialized hardware
2. Proof-of-Stake, then no one who doesn't own already can earn coins
3. Proof-of-Work based on harddisk space (my proposal), which hopefully puts existing PCs on more level field
4. Decrit's combo of Proof-of-Work with some filtering mechanism that makes no sense to me so far.
5. Proof-of-Reputation (I forget the name), where people give rep power to each other

What should the goal be?

A. Convert fiat to something that will earn coins, minimize risks of new technology voiding the calculated (depreciated NAV) value of the asset.
B. Leverage existing assets that users already own and which are underutilized.

Technology shifts (from CPU to GPU to ASICs) make mining Bitcoin very complex to calculate.

Thus I arrive at my harddisk space proof-of-work as the marriage to Decrit's SH consensus CB block design.

Minting should never stop, but it also shouldn't be able to exceed a reasonable debasement rate, else speculators and adopters may be put off. Gold debases at roughly 1.5 - 2.5% per year.

Let's compare Bitcoin's approximate annual rate of debasement:

2009: infinity (started at 0, thus divide-by-zero)
2010: 100%
2011: 50%
2012: 33%
2013: 12.5%
2014: 11%
2015: 10%
2016: 9%
2017: 4%
2018: 4%
etc.
2033: 0%

Does that look fair to users? They have no way to dislodge value over time from the early adopters. Money must decay in value over time, else the system is fundamentally incongruent with society.

Notice how price has gone phase-change parabolic since the debasement has slowed from 33% last year to 12%-- just after the early adopters got theirs and now the greater fools come in to cash them out.

The problem with Bitcoin that makes it a pyramid that will collapse is that it is too radically frontloaded to the beginning with no concern for the future. Minting becomes exponentially less valuable. This is great for causing a mad rush into, and a mad rush out later, and amplifying the greater fool paradigm.

With the simplified SH limited # of shares proposal I floated, the early adopter insanity can rush into the transactions shares instead of into the minting.

This was the fundamental brilliance of Decrits' design, along with the idea that we don't need to waste proof-of-work on transactions and to separate transactions from minting so that we can be sure transactions go through even if minting is more than 51% monopolized.

I am urging the author of Decrits to have a rethink about the key paradigm shifts he thought of and back away from all the unnecessary complexity he is adding on top of those key paradigm shifts in search of some Utopia that can't exist.

[AnonyMint]

In addition to anonymizing the IP of the injection point using MUTE concepts in every peer that transmits transactions, there is an idea to anonymize the blockchain:

http://blog.cryptographyengineering.com/2013/04/zerocoin-making-bitcoin-anonymous.html

[brenzi]

The only proposals I know of:

1. Proof-of-Work based on computation, i.e. Bitcoin and Litecoin, which favors specialized hardware
2. Proof-of-Stake, then no one who doesn't own already can earn coins
3. Proof-of-Work based on harddisk space (my proposal), which hopefully puts existing PCs on more level field
4. Decrit's combo of Proof-of-Work with some filtering mechanism that makes no sense to me so far.
5. Proof-of-Reputation (I forget the name), where people give rep power to each other

I'd add
6. Proof-of-Burn

Of course, you need to already own coins to be able to burn them. But replacing real-world resource use by virtual resource use makes sense.
PoB is often cited for transfers from one coin to another, but maybe there's also a way to base a currency on it?

[Etlase2]

I am urging the author of Decrits to have a rethink about the key paradigm shifts he thought of and back away from all the unnecessary complexity he is adding on top of those key paradigm shifts in search of some Utopia that can't exist.

Right, because proof-of-work based on storing terabytes of data is a simple affair. Or a somehow more fair affair. (How does this make the network efficient?)

Here's the thing, to make money via the network expansion in decrits, you don't even need to own a computer, you only need to accept and transact with decrits.

I'm not sure how you can rationalize the inherent creation of a cartel of shareholders by saying that we just need to hope one is honest and everything will be ok. What is the long-term benefit here? You claim you'll be honest, but you also want there to be speculation on these shares, as I presume for some return on investment. This places a few in positions of power over the many. One reason for this you mentioned was "overloading" but I have already shown that this is not an issue. Even if there are four hundred thousand shareholders, the network bandwidth and storage requirements will be minimal. This design has a phenomenal chance of scaling up to the population of the Earth without running into problems with computer technology or the hope that it will keep up with network demand.

The more you consolidate the people who have an incentive to use the system, the more you will consolidate the people who use the system. This is pretty KISS. The more you also encourage people to make shitclones because they missed the boat, and the more likely those shitclones are to just debase your currency faster than you expect anyway. Why are you forgetting this? Pandora's box is open. You aren't going to get people to blindly stick with you because you were there first. You need something that has staying power.

It's great and all that you are willing to accept where the ideas will improve upon your design, but it's not so great that you are willing to drop others as overly complex because they don't fit your view of how the currency will be debased. It is terrible that you've used gold as an example, the money that has enslaved more of mankind and for far longer than any other.

As for stable currency, that is an illusion that can only be enforced by the state (until it fails and value goes to 0). Has gold ever been stable in price throughout history? No!

If you attempt something unnatural, you will surely fail.

Resorting to appeal fallacies now? Please take the time to understand the currency system--because you have repeatedly stated that you don't--before passing judgment. If you are as enlightened as you think you are, you should be able to see the magic of it. Otherwise, keep start asking me questions until you do--because you will. This post and this post will get you started.

[Etlase2]

I'd add
6. Proof-of-Burn

Of course, you need to already own coins to be able to burn them. But replacing real-world resource use by virtual resource use makes sense.
PoB is often cited for transfers from one coin to another, but maybe there's also a way to base a currency on it?

brenzi, welcome back. You owe me a reply.

[brenzi]

brenzi, welcome back. You owe me a reply.

Yes I do. But IMHO the moment has come to nail your ideas down. At least as a reference for discussions. If we could move from prosa to math and pseudocode I'd be pleased to help reviewing.

[Etlase2]

Yes I do. But IMHO the moment has come to nail your ideas down. At least as a reference for discussions. If we could move from prosa to math and pseudocode I'd be pleased to help reviewing.

int MBAward = GetNetworkGDP(MAX_CONSENSUS_YEAR) / 12 * 0.0001;
//We take the highest network GDP all-time (in case off-network txes become more popular), divide it into a consensus month, and multiply it by the transaction fee
//Max GDP updates on a rolling, quarterly basis (every 90 CDs)
//Even though a MB is designed to last 7-10 CDs, 30 CDs of tx data is used to make it more difficult to start and/or game a mint block
int TxFreeMoney = MBAward * (5 + GetConsecutiveMBlocks());
int AcctFreeMoney = MBAward * (5 + GetConsecutiveMBlocks()); // = TxFreeMoney;

int TotalAward = MBAward + TxFreeMoney + AcctFreeMoney;

if (GetNetworkTxFees(PRIOR_CONSENSUS_MONTH) < TxFreeMoney) { //This removes incentive to "game" the award
SavedMoney = TxFreeMoney - GetNetworkTxFees(PRIOR_CONSENSUS_MONTH); //We will distribute SavedMoney over time
TxFreeMoney = TxFreeMoney - SavedMoney;
}

MoneySupplyIncrease = TotalAward / GetTotalMoney();
//Should be a pretty small amount until we start getting into 10 or more consecutive blocks


How far do you want me to take this?

[AnonyMint]

I will come back to the proof of minting discussion later, let me make a few quick replies on the transaction processing design...

One reason for this you mentioned was "overloading" but I have already shown that this is not an issue. Even if there are four hundred thousand shareholders, the network bandwidth and storage requirements will be minimal.

I mean the overload of communicating all the TBs when every SH needs to get a turn within on CB, else it can be gamed, because we don't have external entropy to randomize the order.

At least there will hopefully always be at least one good SH, and he will get a turn every CB in my proposed change to your design.

The more you consolidate the people who have an incentive to use the system, the more you will consolidate the people who use the system. This is pretty KISS. The more you also encourage people to make shitclones because they missed the boat,

I think we are agree that minting should be available to as many as possible. I don't see how to make it happen for transaction processing and still get consensus without being energy inefficient and opening to a attack by spamming it with too many SHs. There is simply too much communication overhead and we don't have external entropy in a decentralized consensus (or is there a way, show some math please!).

It's great and all that you are willing to accept where the ideas will improve upon your design, but it's not so great that you are willing to drop others as overly complex because they don't fit your view of how the currency will be debased. It is terrible that you've used gold as an example, the money that has enslaved more of mankind and for far longer than any other.

I am open minded, except that there are certain laws of human nature that can not be changed.

Gold has never enslaved (statist debt implosions have), there is a continual fluctuation in cycles between high rates of debasement and not (via fiat, shaving coins, or whatever). Human nature demands the debasement, because it demands debt, because... (very long discussion not worth making).

As for stable currency, that is an illusion that can only be enforced by the state (until it fails and value goes to 0). Has gold ever been stable in price throughout history? No!

If you attempt something unnatural, you will surely fail.

Resorting to appeal fallacies now? Please take the time to understand the currency system--because you have repeatedly stated that you don't--before passing judgment....

Equilibriums only exist in closed systems.

(you are not calling for a closed system currency, i.e. no conversion to fiat, and remember the universe trends to maximum entropy, thus you can not wall off the evils you are trying to, it will seep in from some aspect of your design you have not proven with math)

Essentially I am citing Coase's Theorem.

[Etlase2]

I mean the overload of communicating all the TBs when every SH needs to get a turn within on CB, else it can be gamed, because we don't have external entropy to randomize the order.

You are going to have to tell me what you mean by overloading, because I don't think I am interpreting it the way you mean it.

You're obsession with randomizing the order is curious. Each SH's signature will be on each CB. That is why the CB period is 10 CDs, that allows for 87,660 people to be SHs without a single one sharing a TB window. There has to be some scalable limitation on how many SHs there are, because at some point we're just inefficiently moving money around. However, there does not need to be a hard limitation. But basing an incentive system around an idea such as 1 SH for every 1000 people can keep this well within any reasonable scalability expectations for the future.

With 400k active shareholders, to keep up with continued consensus, you'd need about 60MB every 10 days (assuming around 150 bytes for CB hash + ongoing hash + signature). That is ridiculously efficient and scalable, even to several million SHs. Each SH getting a turn in 10 CDs is feasible. And I have already said that the efficient way to do this is to have them sign another's block and only add transactions that were missed. That still means you can't deny transactions.

As far as entropy, the time wobble already is sufficient to secure the randomization of the SH order. An evil entity can't control the joining and leaving of SHs. They do not care and do not know the designs of the evil entity. So while the evil entity will be able to see potential futures, it still can do little to change them or force one when anyone out of all the network does something they do not expect, and it completely resets the process.

Regardless, if you think being able to see some potential futures is bad, one possible solution is to have each SH symmetrically encrypt a signed statement with { encryption key, cb hash, signature } and then reveal the encryption key during the next CB period after all have signed who are going to sign. Only one encryption key out of thousands or millions need not be known to EvilCorp and EvilCorp will not be able to predict the outcome of it in any way. Completely random. He can of course choose not to reveal his own keys after everyone else has revealed theirs, but the problem again becomes how many soft strikes will it take, how many deposits lost will it take to affect the outcome to something evilcorp finds beneficial. There will be a very limited number of options. Still none of which could ever deny someone's signature from consensus.

At least there will hopefully always be at least one good SH, and he will get a turn every CB in my proposed change to your design.

You have solved a problem that doesn't exist. And I have already told you as much.

I think we are agree that minting should be available to as many as possible. I don't see how to make it happen for transaction processing and still get consensus without being energy inefficient and opening to a attack by spamming it with too many SHs. There is simply too much communication overhead and we don't have external entropy in a decentralized consensus (or is there a way, show some math please!).

You are going to have to tell me to what attack you are referring, because I don't know what you mean.

Equilibriums only exist in closed systems.

(you are not calling for a closed system currency, i.e. no conversion to fiat, and remember the universe trends to maximum entropy, thus you can not wall off the evils you are trying to, it will seep in from some aspect of your design you have not proven with math)

Oh whatever. Where is your solution again? Hard drive space? You glossed over this part in your "simplification". Yes, I can see that being infallible. All we can do is make better attempts. I'm not sure why my attempt deserves derision via philosophical pedantry any more than say, yours.

[AnonyMint]

You're obsession with randomizing the order is curious. Each SH's signature will be on each CB.

[...]

With 400k active shareholders, to keep up with continued consensus, you'd need about 60MB every 10 days (assuming around 150 bytes for CB hash + ongoing hash + signature). That is ridiculously efficient and scalable, even to several million SHs.

My concern was not about that total, rather the duplication of that total and/or communication overhead in order for every SH to get a turn within the maximum delay allowed for the delayed transactions attack.

Also don't the transactions also have to be transmitted? Even though we are using a hash tree, we need to transmit the new transactions along with the new hash at the top of the tree?

Each SH getting a turn in 10 CDs is feasible. And I have already said that the efficient way to do this is to have them sign another's block and only add transactions that were missed. That still means you can't deny transactions.

We still have the problem that every SH has to see every TB so it can know which transactions weren't included, otherwise we are sending around duplicates. So either we have a mesh network overload, or we have duplication overload. Am I missing something?

I will respond to the rest of your post later.

[AnonyMint]

As far as entropy, the time wobble already is sufficient to secure the randomization of the SH order.

I don't know what time wobble you are referring to, since I saw you first mention it, I don't understand.

Any centralized agreement on time is antithetical to a decentralized system.

An evil entity can't control the joining and leaving of SHs.

I thought we already had this conceptual discussion upthread about being last. They only need to control the last join and game it in order to control the input entropy.

Perhaps you can explain to me what is different in your mind than our prior conclusion.

They do not care and do not know the designs of the evil entity. So while the evil entity will be able to see potential futures, it still can do little to change them or force one when anyone out of all the network does something they do not expect, and it completely resets the process.

Originally I was thinking that too, then we had the discussion about whoever is last, sets the order.

Regardless, if you think being able to see some potential futures is bad

I need to be convinced that if the input entropy can be gamed by the last, then the attacker can not set the order to always go to his SHs.

, one possible solution is to have each SH symmetrically encrypt a signed statement with { encryption key, cb hash, signature } and then reveal the encryption key during the next CB period after all have signed who are going to sign. Only one encryption key out of thousands or millions need not be known to EvilCorp and EvilCorp will not be able to predict the outcome of it in any way. Completely random. He can of course choose not to reveal his own keys after everyone else has revealed theirs, but the problem again becomes how many soft strikes will it take, how many deposits lost will it take to affect the outcome to something evilcorp finds beneficial. There will be a very limited number of options. Still none of which could ever deny someone's signature from consensus.

Can you please explain this more clearly? I can not understand. I have no idea what is being signed and why, etc..

Equilibriums only exist in closed systems.

(you are not calling for a closed system currency, i.e. no conversion to fiat, and remember the universe trends to maximum entropy, thus you can not wall off the evils you are trying to, it will seep in from some aspect of your design you have not proven with math)

Oh whatever. Where is your solution again? Hard drive space? You glossed over this part in your "simplification". Yes, I can see that being infallible. All we can do is make better attempts. I'm not sure why my attempt deserves derision via philosophical pedantry any more than say, yours.

We will get to the minting after the discussion on the transaction processing.

I don't yet understand how your proposed minting works. It is extremely complex, but appears to try to form some kind of equilibrium of value based on some non-existent reference point. I can't say that for sure, because I don't yet understand it. You will need to explain it. The way it is explained in the OP is not clear to me.

[AnonyMint]

It is probably not desirable for the SH private keys to be permanent, because they can be lost or stolen.

The two ways to award SHs is selling them to highest bidder or randomized gift.

The only way I can see to inject randomization decentralized, is Satoshi's proof-of-work. I am awaiting any cogent refutation.

Satoshi randomization (for this purpose of awarding SH) can never be 100% dominated unless the attacker has all the hardware resources and no one else has any.

Randomization is inherently expensive (resource inefficient), because it requires that everyone guess at something, otherwise we end up with someone last in line to sign and they can game the entropy.

Unfortunately even though we shouldn't need to award new SHs as frequently as every TB, this wouldn't be any more more efficient than Bitcoin which computes a proof-of-work at least every 10 minutes, because the next solution is computed from the prior solution, so peers have an incentive to start computing the next immediately no matter how long the period between solutions (set by difficulty).

P.S. for minting, my harddisk proof-of-work concept can not be randomized, but order doesn't matter if all minters will be given a turn (and transaction processing is not done by minters).

[Etlase2]

My concern was not about that total, rather the duplication of that total and/or communication overhead in order for every SH to get a turn within the maximum delay allowed for the delayed transactions attack.

Whatever the communication overhead, logic would suggest that it will be dwarfed by transaction activity. We're talking about 4 signatures every 10 seconds if there are 400k SHs. Use whatever example works. 400k is 1.2 billion decrits in shares. I'm betting there would be at least several hundred transactions per second if that is the case. As SHs should always remain a tiny portion of the transaction total, as long as the network can scale the tx volume, it can scale the SH volume.

Also don't the transactions also have to be transmitted? Even though we are using a hash tree, we need to transmit the new transactions along with the new hash at the top of the tree?

I'm not going to ramble on about the efficiency of using an account ledger. I'm pretty sure I've mentioned some of this in this thread, and I have definitely linked you to another, but with a smart peer protocol, account ledgers allow for 3-6 bytes per duplicated tx. If you think this is impossible, I can drone on about it later.

With a bitcoin tx being 300 bytes on avg and a hash check being 32 or 64 bytes, and a decrits tx being around 100 bytes and a hash check being 3-6 bytes, there is nothing to complain about bandwidth. If too many SHs was really a problem, the network could adapt by extending the CB period a few more days. But it will hardly do anything compared to the total tx volume.

We still have the problem that every SH has to see every TB so it can know which transactions weren't included, otherwise we are sending around duplicates. So either we have a mesh network overload, or we have duplication overload. Am I missing something?

Yes. There is nothing that says they need to be immediately confirming the TB to which they are assigned. They could wait 10 TBs and then do so. It is an implementation detail. Every SH is going to have to see every TB at some point.


Regarding the other two posts, I'm done responding to your egotism. Either change your attitude, or find some other place for your mental masturbation. You are not the only smart person in the world. You have the barest of understandings of this protocol, yet are unwilling to lay off the insulting implications of my missing some catastrophic failure point. I have not. The sooner you get over that, the sooner we can actually have an interesting discussion.

You have designed a completely different system in this post and have set up a straw proposal to attack. I will not spend time defending what you think my proposal is. And I will not respond to another post of you assuming failure and asking me to prove otherwise. Rephrase your questions so that you do not come off as such an ass.

[Etlase2]

I need to be convinced that if the input entropy can be gamed by the last, then the attacker can not set the order to always go to his SHs.

I will respond to this because I don't know how you can still think this. *ALL* SHs will receive a turn in *EACH* CB. You keep changing which attack you want to use when it suits you. If everyone gets a turn, lol data overload. But everyone doesn't get a turn because of data overload (ignoring my responses), so SHs can somehow choose to make other SHs not sign. Wrong. Stop doing this.

Everyone knows who all of the shareholders are, and the order can only determine in what order they sign the CB and create TBs. It can not exclude SHs from signing. This is not a vulnerability. The vulnerability is potentially engineering a bunch of Evil SHs in a row to deny transactions or other TBs or whatnot. We have already gone over this. I am happy to explain further how this can be extremely difficult and costly to game as well since you have not already grasped it, but again, you must stop the insults and assumptions.

Pick one specific item, ask me about it, and stick with it until you are satisfied with the explanation.

[AnonyMint]

Regarding the other two posts, I'm done responding to your egotism. Either change your attitude, or find some other place for your mental masturbation. You are not the only smart person in the world, as hard as it is for you to believe that. You still have the barest of understandings of this protocol, yet are unwilling to lay off the insulting implications of my missing some catastrophic failure point. I have not. The sooner you get over that, the sooner we can actually have an interesting discussion.

Change my attitude? I came here to try to review your system and help you get some feedback. What if anything have I said that has been egotistical or mean-spirited?

I can't understand your description of the minting system. Sounds like a lot of handwaving (because I can't grasp any cogent design for the minting from what you've written in the OP). It is up to you to explain clearly. And I have a very high level of reading comprehension. So it must not only be me. Many upthread have given you the same feedback, that they can not understand your protocol as described in the OP (at least not all of the protocol). I specifically can't understand how the minting will achieve the expectations you claim.

You have designed a completely different system in this post and have set up the strawman to attack. I will not spend time defending what you think my proposal is in your head.

Have you proven a strawman? (let me review your latest technical reply to see if you have)

I asked for help in understanding the design that is in your head. I have not made any conclusions. I have said that I don't favor a complex system, if there is a simple system that can work well as a first starting point. You can always build another system with more complexities on top of that first attempt. If you can explain and justify your system in a reasonably concise document, then I have an open mind. But I can't have an open mind to bunch of incoherent or handwavy claims, or disjoint posts spread out over 11 pages of a thread.

[AnonyMint]

Whatever the communication overhead, logic would suggest that it will be dwarfed by transaction activity.

Only if there is a limit to the number SHs. I was proposing a limit. Now it seems you are agreeing to a limit too.

Also don't the transactions also have to be transmitted? Even though we are using a hash tree, we need to transmit the new transactions along with the new hash at the top of the tree?

I'm not going to ramble on about the efficiency of using an account ledger.

A centralized ledger for a decentralized system?

If too many SHs was really a problem, the network could adapt by extending the CB period a few more days.

Thus further increasing the maximum potential delay in a delay transactions attack.

But it will hardly do anything compared to the total tx volume.

Ditto centralized concern above.

We still have the problem that every SH has to see every TB so it can know which transactions weren't included, otherwise we are sending around duplicates. So either we have a mesh network overload, or we have duplication overload. Am I missing something?

Yes. There is nothing that says they need to be immediately confirming the TB to which they are assigned. They could wait 10 TBs and then do so. It is an implementation detail. Every SH is going to have to see every TB at some point.

Thus further increasing the maximum potential delay in a delay transactions attack.