Adding the nonce also requires adding bandwidth and storage to already wasteful transaction sizes. Although storing the nonce might not be necessary, the bandwidth overhead is still a concern.

Actually, rethinking option 1) there is a vulnerability. This vulnerability only becomes relevant in owning >50% of the consensus in a network that has many multiples of 87.6k SHs.

If a period of the network is overwhelmed by evil SHs, there can be an increasingly long delay before the honest network can put together a legitimate fork. Unless we want CNPs to be able to fracture the network (which is probably a bad idea), the most they can do is delay suspicious looking TBs.

For example, TB 400 is an honest SH sandwiched between 100 evil SHs on both sides. If the SH at 300 did something bad, like not acknowledging a TB or signature that he should have, CNPs can only delay his block, but all the evil SHs don't care because they will add it anyway and will presumably control some portion of the CNPs. Ergo, many people could see a(n evil) network functioning for an extended period without knowing that good people are being dropped.

Essentially, if you have 87.6k*5 SHs, and evilcorp owns half or whatever, evilcorp can keep the honest half from forking for many weeks. Yes, it's still crazy unlikely, but after so much time has passed, how do we prove that they are rejecting honest SHs? Only from honest CNPs, but it is essentially only their word because they do not have two chains to prove an honest and a dishonest half (or a dishonest 80% and an honest 20%). Honest SHs may not keep up with the network and must rely on the only chain they can see.

If the 1% that is honest (if we move to 99/1) is spread thin, they have no power and may not even be aware of what evilcorp is doing. The good guys are left hanging with nobody to back them up. This *could* be addressed by some kind of emergency consensus of honest SHs, but detecting this is tricky, and there is no guarantee that a significant enough portion of honest SHs will be watching. And creating a split from that will be very difficult to do in any kind of organized way. In the 99/1 case, they are still in control of 1% of the 10 CD consensus period. And if 99% does something bad, 1% can chug right alongside it showing what happened and why they split.

I think this is why a reasonable time to guaranteed 100% consensus is important. Even though these situations are crazy unrealistic, there still may need to be considerations in regards to legitimate network splits (government, internet catastrophe, who knows), or even perhaps accidental splits (software bug--hello bitcoin has already shown us to be aware of this).

Yes, something about your thought process distracted me. I thought about it a little more after my reply and got what you were saying.

So you are right, in the case of 5 million SHs, those 5.7 SH/s would be including a lot of the same 3-5 byte hashes for missed transactions. It isn't network breaking, but it is an inefficiency that gets worse as the network gets very large. There are two solutions I see:

1) What you have already suggested in that the entire consensus is not required each CB, as long as we are certain the order can't be gamed.
or
2) Since everyone knows who are the "backup" SHs for each TB, each of those runs a remainder/modulo/hamming distance on each tx to determine which of the backups will include the missed txes divided among that group. Even if the TB is entirely missed, all the txes will be divided up evenly with no duplication. We could even design the system so that the backup SHs automatically do this anyway, effectively adding a maximum of 4 bytes per tx, and have them create backup TBs at the same time as the primary TB without even waiting to acknowledge it.

Both options seem very reasonable. Leaving people out of consensus scares me a little bit though, even if the only vulnerability is EvilCorp controlling a vast majority of the SHs during that CB (87.6k SHs). If they do, then unless we assume they control 80-90%, they will have almost no power in consecutive blocks.

If we took option 1, do we reorder the order every CB (or 10 CD period) or do we just effectively extend the CB process? Do we "commit" everything every 10 CDs to the approved consensus, or do we hold everything until all SHs have signed over however long that takes? I can't think of any vulnerabilities from either scenario, but option 2) above limits the data load to the absolute minimum. I mean if we assume 1 SH for every 1,000 people on earth (and base the incentive system around this), that is 7 million SHs, only slightly above the 1kB/s figure already stated for 5 million. Totally irrelevant in a network that is only the size of visa (of course we expect it to grow much bigger).

As I said, it is only a recommendation so that the network will not be ad-hoc. Robustness is up to the individual CNPs and how far they want to reach.


Will there need to be 1 copy for each node that wants a copy? Yes. This is not a weakness or inefficiency, this is decentralization.


You are teetering away again. When more than one SH is selected for 1 TB, which will always be every 10 seconds, the SH without priority will acknowledge someone else's block.


Instead of misinterpreting this, I'm just going to say I don't understand what you're saying. I think I know what you're saying, but it's probably better to just drop this for now and focus on learning more about other things instead.

It is a distributed, p2p network. All peers that want to see all data will see all data. But because of section 2, the distribution network is anything but ad-hoc, it is rather organized. Some easy simulations can be run to determine the maximum number of hops for a given transaction to reach each CNP (to which SHs, CNCs, and SPs are connected). In fact, similarly to the order of consensus, a rolling CNP order should be maintained as well. This rolling order is a recommendation for who each CNP should connect to (other CNPs), that way there aren't nodes that get too many requests or nodes that get too few. And it also means that transactions will always take the least number of hops to reach wide distribution. And because the transmission protocol will be designed to be excessively efficient, it will be bandwidth cheap to maintain.

Besides the massive efficiency gains in relation to time and bandwidth, it is roughly the same type of network as bitcoin. A sort of distributed copy of an ongoing shared file. I don't believe it is ever common to see a bitcoin transaction take longer than 2 or 3 seconds to go from one side of the network to the other, and that is with a completely ad-hoc network.


The next TB in line does not have to acknowledge the TB directly before it (though an honest one always will if it has seen it). However, I do believe that the vast majority of the time this will be the case.

Now, to explain how a merchant can use the information it receives to determine the risk in accepting a face-to-face transaction. Let's reuse the 10-TB window figure for the longest amount of time before a missed TB can be inserted into the chain. If SH X misses his TB Y, at TB Y+10, his TB can no longer be accepted into the chain and he will receive a soft strike.

So with this knowledge, if TB 1-10 are all acknowledged by TB 11*--where the transaction that a merchant is interested in lies--he knows for certain that the account balance of the sending account is accurate and up-to-date in the ongoing consensus. (This is presuming that the general order of the network is stable; e.g. 20% of the consensus isn't missing.) The merchant doesn't even need to have a copy of the shared consensus, he only needs a CNP to prove it with hash trees (or for decentralized simplicity, invest in the network as a SH and/or CNP and maintain this data as a part of doing business).

* - acknowledged by TB 11 does not mean that they are all repeated, or hashes are all repeated. If TB 10 acks TB 9, and TB 11 acks TB 10, TB 11 implicitly acks TB 9. TB 11 couldn't receive TB 10 without having seen TB 9, because TB 9 had to exist for TB 10 to be transferred around, and so on. No one (in the CNP) can honestly transmit a block that acks another without being able to provide the data of the other block. This, quite literally, means they must be able to provide data in the TB chain *at least* until the last CB. If a CNP doesn't have the evidence and it is honest, it will refuse to transmit it until it does have the evidence. A SH can never be fooled into acknowledging something it doesn't have. The network simply will not transmit this data. I *think* this is what you wanted addressed by still being concerned about data overload.

Now if a TB is missing* in the prior 10, it is possible that the account balance for the customer is not accurate. If TB 12 comes along and acknowledges this missing TB and the merchant's transaction will take the customer's account below 0, the transaction will be denied. If this transaction is for a couple decrits, it is probably hardly worth worrying about. If the transaction is for 50 decrits, the merchant may want to wait an additional 10 or 20 seconds to reduce or eliminate the possibility of TB insertion.

* - unacknowledged

But realistically... this "attack" really requires that person being specifically involved with that SH, or to be that SH, because otherwise the next TBs in line have picked up any distributed txes changing that account's balance. Now at first this sounds like a great attack vector for every SH to hold back a transaction and get away with a free purchase each time his TB arrives, but one must remember this vulnerability is only relevant for face-to-face transactions. If the merchant is even slightly suspicious, your chances of succeeding are drastically reduced.

A quick side note: This is the caveat that comes with using a larger number before TBs can't join the chain. If it is longer, the more potential people that can do this in a specific time window, and over a longer period of time. So picking this number requires some deep discussion. But maybe not that deep, and it is something that will also benefit from knowledge gained in live network testing. A way to significantly reduce this vulnerability is to have CNP heuristics delay TBs that come out of order that have transactions that will cause a double/bad spend. Dick around, and there's a good chance you'll get a soft strike.

Anyways, this opportunity requires this SH-owner to miss his TB, pay, send and have accepted his TB, and leave the merchant's presence within about 100 seconds at one specific time within a 10 day period. Owning 10 SHs in a row does not practically increase this vulnerability because you still have to acknowledge the missing TB or receive a soft strike. Additionally, the double spend attempt is public and a specific SH is tied to it whether or not he has any actual relation to it (the odds of this happening by chance/accident are astronomically low), so if you do get away with attempting it once, do not expect smart clients to advise this as a "low-risk" situation the next time.

Unfortunately we can't award a soft strike here because though the chance/accident rate is super low, the attack rate could be much higher if an attacker was able to isolate a SH.


These issues, if they become relevant, can be addressed by CNP heuristic measures. I don't have the exact answers for this. But if enough CNPs agree to delay propagation of TBs they determine are trolling or whatever, the SHs in question will start receiving soft strikes. Coordinated defenses like this are part of the *cough* intent of the design of section 2, but I am fleshing it out more as the discussion is coming up, so that's a good thing. As far as attempting to DDoS the network, the idea in my notes is to have a maximum amount of transactions per block equal to (network minimum based on scaling up initially to paypal-like levels) or (avg. # of txes per block over the last rolling CY) times 3 or 4.

I'm sorry, I was exasperated and exhausted.


But this would require a significant chunk of all the currency in existence*, and it still does not do anything to the Cloudnet side of the equation. It would require matching the entire honest SHs deposits to cut their profitability in half (100% more for a 50% attack). In the mean time, the opportunity cost of doing this is huge as well. By locking up this money, the EvilCorp loses all ability to use that money to do anything else beneficial. Power over transaction activity increases; power for anything else decreases.

I'm sure you're aware of how important cash flow is for any entity. This puts a distinctive stop to that flow.

* - hand-wavy only because we can't predict how much on-network tx activity will exist, and 0.01% tx fee may be too low. I don't know, I haven't run a slew of numbers on various scenarios because it's something I'd rather let people who enjoy that sort of thing do.


The reliance is on other parts to tolerate those problems. You are dismissing the very ideas that will accomplish fault tolerance as poor design. If you try to rely on tolerance within each system, then that system can be gamed by anyone who has a reasonable control over the majority of the system, as you have been going on and on about.


So you would rather deny the idea on principle than accept that no currency can be perfect? It's not just about forking either, that is just one possibility.


Well debt-based money and fiat money need not exist after decrits. It doesn't matter if voting can be gamed as long as people still have the opportunity to retain value in forking the network, making forking much less painful, making any attempt at controlling the network *much more* painful.


I have tried to address every conceivable thing I could think of, but that still won't be anywhere close to everything. I can't predict the future. I've even considered the rise of quantum computing and I knew that an adaptable protocol for new signature schemes and new hashing schemes must be in from the start so that any transition is as easy as it can be.

Bitcoin proponents claim "we can always fix it" but they never grasp the true difficulty of changing a decentralized system. It is easy with bitcoin, at least for now, as it is highly centralized. But in a system that promotes all sorts of decentralization, and if it is ubiquitous, this will be far more difficult.


It is temporary deflation. The monetary system has a lot of brakes to prevent endless money printing. EvilCorp will not be able to subvert this, and will pay the price in fiat.

No, it isn't. Put all the new joins at the end then mix, it doesn't matter. It doesn't need to be random, it just needs to mix up the current order. Take every second SH in order and put them at the end. Voila, you have a completely new mix of SHs.

How am I supposed to argue with these notions? How can you possibly draw any valid conclusions when the idea you have formulated is something completely other than what the OP states?


There is no bidding described here. No cartel is inherently in this design. And yes, the design is intended to have a fixed cost to purchase a share. Want a share? Buy a share. Perhaps shareholder has a poor connotation, but I admitted I am terrible with terminology. With this settled maybe we can start discussing something closer to a vulnerability in the actual design? I'm sure you have a whole slew of things you can think up for why a fixed price is a bad idea, but I can make cogent arguments since you are using the actual design, for a change.


While I have only probably hinted at addressing this, it is addressed, but it involves going into the monetary system, and I still want to nail down consensus for you first.


Except that part of the design is to foster (peaceful) forking if deemed necessary. That is hardly thinking in a closed system. If the monetary system stops working in a reasonable manner, the people are free to bust it wide open with something new, and retain value from the old, and part of this break has to be denying access to any of the existing SHs who do not wish to switch. But now we're getting deep into section 4, and you still haven't mastered section 1 yet.


Every SH does not need to see the updates as they happen. Even ones around the same time frame do not need to see each other. There is no overload of communication unless you can prove that a steady and predictable 1kB/s at 5 million SHs is impossible to overcome. There is risk in accepting a transaction if you are missing recent blocks, but not much. I don't even remember now who I started explaining this to, but I think it was you, and I don't really feel like explaining it again at the moment. Suffice it to say that I can go much deeper into why transactions are secure when they're secure, and it is easy to identify when a transaction is risky to accept without waiting. Just take it as a given for now because I'm tired.


Yes, we have to multiply the data times the number of connected peers divided by about half, assuming half of the network gets the transactions before you. But lite clients only need to maintain 1kB/s to verify any part of the ongoing consensus. (4,000 tx/s [visa] * 100 + 5.7 SH sigs/s [5 million / 876,600] * 150) = 400,855B/s, times say 100 connected peers, divided by half, is 20MB/s or approximately a 160Mbit connection, or around the very high end of consumer bandwidth available today. And notice that the SH part is still a meaningless amount.


It can't possibly prevent the exchange, but it definitely has a cost. Any drastic uptick in the demand can only be assuaged by higher prices in the short term which means the large exchange is going to have to pay increasingly more fiat to obtain increasingly more decrits. And in the long term, new decrits will be created and distributed throughout the network. The people using decrits will profit off of selling you decrits for much more than their cost to produce, and then the people using decrits will profit again when new coins are distributed to bring the price back down.


This is true, but the economic calculation is much more beneficial to the decrits user.


Based on some assumption that I think the system is closed.


Based on not understanding the topology of a distributed network, I think? I really don't see why you still think SHs need to be artificially limited. They will be limited by the currency required to purchase them.


The order of joins/leaves has little to do with it. The function just needs to mix up the order so that the vulnerability you have fought so fiercely for does not exist. It can be entirely predictable and it still can't be gamed, at least not to any degree of reason. EvilCorp could keep leaving the SHs and rejoining until it has a beneficial lineup for a whole CB, but doing this will cost him as there are penalties for early withdrawal. Shares must be kept for 1 year, or else. And the function just needs to intersperse new SHs throughout the existing order to basically avoid any notion of this possibility too.

And the randomization is not required. So can we end this now?


How can you gather this from an example that talks about shuffling SHs around? There is no computation required at all other than running the function itself. Mix new peers in, reorder them around so that most neighbors do not stay next to each other. Take a step back and reevaluate the situation. If 50% of the SHs are controlled by one entity and they are all in a row and the mixing function is "Move the 10th peer 4 places down" eventually, after many CBs, there would be an equal or at least random (looking) distribution of evil and good SHs. Fortunately, the mixing function does not have to be that stupid.

I do not believe that you can come up with a successful scenario here. Everything you have relies on EvilCorp being able to significantly delay transaction processing. All reality goes against this.

Funny thing about consensus is that a 50% attack works differently. Any percentage attack requires an exponentially increasing stake in the network. If there are 100k honest shareholders, a 50% attack requires a 100% match of the money in the shareholder part of the network. 100k new shares, now 50% control. A 75% attack would require a 300% match. A 90% attack would require a ~1000% match. A bitcoin 50% attack requires 50% of the current total hash power, because they can deny the blocks of others; a 75% requires a 75% match. >50% is only significant because it is enough to always overtake the honest chain eventually, no matter what.

Now that is not to say that the cartel could not start with some percentage of the network already in hand, but the exponential increases over the honest shareholders is still required. Feel free to do the math, but I'm fairly certain a cartel controlling even 50% of the SHs could not delay transactions more than a minute on average (although graphed against the total # of SHs would be interesting), given an ungameable distribution. Annoying, but hardly network breaking; it's still 10 times faster than bitcoin.


It's fairly simple. If you are worried about cartels such as this, start with a higher transaction fee. The transaction fee will ultimately dictate how much of the total money supply is locked in the network, and how much money this cartel must acquire and be willing to lock away to game the network. If 10% were locked in the honest network, the cartel could never go above 90% because the entire money supply would be in shares.


You have missed key points. There is the consensus block, the block to which all shareholders have last agreed is the state of the network, and the ongoing consensus, which is updated every transaction block. Assuming a peer has the vast majority of TBs leading up to the TB it is interested in, and a split is not likely to occur immediately after, his transactions are secure as of that block. They could theoretically be respent within the same block. No 100% consensus is required for this.

As far as limiting the # of SH, if the CB period is 10 CDs, the CB period is 10 CDs and 100% consensus will be reached over that time frame. It does not matter if there are 10 SHs, it does not matter if there are 5 million SHs. More SHs != more delay. It just means there is another 150 byte piece of consensus you need to be sure everyone agrees. I chose 10 seconds and 10 days because 87k is such a large number that it has a vast amount of room to grow into. But growing above it is not problematic because of the efficiency described a few posts above. 5 million x 150 bytes / 10 CDs is less than 1kB/s. SHs not having TB priority will still be able to add transactions. There is no need to limit the consensus. Only design around how much is expected to be needed to be secure. Of course this is only a guess, but you have not once acknowledged section 4's existence, either.


How about by requiring it to cost a lot of money in a currency that has a decentrally managed, incorruptible distribution system?


Sorry, but you are not.


Yes, if we ignore any notion of probability.


Yes, if we ignore any notion of probability (or if we ignore the notion that I have any sense and would allow a group to control the ordering of the network). Those delays that can be created with bitcoin also steal money that people wasted on electricity. It's much easier to get those people to quit when they start falling under the wasted-energy-profitability-curve that does not exist in decrits.


Then, if we want to communicate better, stop skipping to conclusions. Ask questions about what you see as potential vulnerabilities, and allow me to respond before rolling into an essay about the ills of this vulnerability that is not specifically addressed in a proposal that is intended to be a digest only.

Now, as far as the random ordering of shareholders. I can see why you did not take much solace in my "wobble" idea after I quickly dismissed the importance of the vulnerability you exposed in the randomness function I came up with. However, the wobble idea was the prior idea that I had analyzed for vulnerabilities and did not find any significant. But then all kinds of tangents were had and the question regarding this was lost in one line of a page of responses.

With that said, there are a million different ways that a wobble in the order of SHs can be set up. The initial premise is this:

{ current ordered list of shareholder public keys + joins/leaves + something simple like the consensus block number } and crunch this into a function that spits out a new ordered list.

Now, before we even get into what that function might do, you must realize that adjusting the one adjustable part of this input is not simple. Creating a join requires 3k decrits. And, at first thought, creating a join seems like the unlimited options scenario because you can join with whatever public key you like, naively presuming that you have an unlimited amount of options in controlling the next ordered list assuming that no one leaves or joins after you (which is possible if you own the last TB in the CB period).

However, a very simple wobble function defeats that. Start by replacing joins/leaves with each other. Then, divide the network up into an arbitrary number of groups based on the current list, say 10, and distribute all remaining joins among them (if there are a lot of joins, pick some distance factor between them in each division). Then, based on the consensus tick, select 25 or 50% from each division that are not in a row and move their position up or down 1 or 2 or 3 spaces. Do this several times with several groups. To prevent the almost same time frame for each SH's TB, just in case, simply pick a new starting spot.

You could also shuffle two divisions together like cards. Or whatever, all kinds of possible functions. The only thing that matters is that it can't be gamed, not that it isn't random or anything like that. Everybody knows which way the function will wobble, but no one can actually jockey into a better position. Any chance meeting of an attacker's SHs will be gone by the next CB, and there will not be anything he can do about it.


Does this satisfy the security requirements of this most improbable of vulnerabilities?

The second premise is using a symmetric encryption scheme to hide your entropy, but I will wait on explaining that if perhaps you find fault with the wobble.

Ok, I will start with the "data overload" part of the problem because I have fleshed it out much more.

A simple transaction can be described in this format: { timestamp, acct_from, acct_to, amount, misc, signature }
timestamp is your typical 4 byte timestamp
acct_from is the 5 byte account number of the originating transaction
acct_to is the same for the receiver of the transaction
amount is a 4 byte integer (you can send 429k in one simple tx using 4 decimals which I think will be the standard)
misc is other stuff like the CNP code and a message if desired, etc.

The only important things here to identify the transaction are timestamp, acct_from, acct_to, and amount. The only *real* important things to differentiate transactions is the timestamp, the acct_from, and a hash of the remaining important data. With the timestamp as part of the transaction, each account need only check that the hash does not collide among txes with the same timestamp. This is easy, even with a 1 byte hash unless this one account is sending on the order of 200 transactions per second.

Now, CNPs will be designed so that with each connected peer receiving full data, it will store then burst the newest transactions it has not sent this peer about every tenth of a second. Say the network is huge and there are hundreds of transactions per second at this point.

Prior to actually sending the transactions, the CNP will send a list and ask which the peer needs. Say there are 100 transactions for one timestamp, and let's just say they all share 3 bytes of account offset (this would be a span of 65k accounts, 5 bytes acct number - 3 bytes offset).

{timestamp X}
{acct offset Y}
{tx 1: 2 bytes for remaining acct offset, 1 byte hash}
{tx 2-99: "" }

4+3+ 3*100 = 307 bytes to verify if 100 transactions have been received yet or not. That is 3.07 bytes per transaction to avoid sending duplicate data. Of course this is a highly efficient scenario, but the worst case is still 4+5+1, and a really smart protocol could reuse most of the first 9 bytes some of the time by sending the data that is requested in an explicit order. (Can't reuse a generic hash.)

Whenever a transaction has already been seen between peers, they can keep a rolling counter of say 4-bytes that identifies a specific transaction. This can be used to more efficiently refer to transactions in a TB when you know the peer has seen it, but it would not be as efficient to use the account offsets and timestamps. This is the "guaranteed second time" everyone will see a transaction, same as with bitcoin's block chain. You only need to make sure the peer knows what the transaction is and it can fill in the blanks and verify the signature. You do not ever have to send the same transaction to the same peer twice.


Maybe this sounds complicated, but I think it's easy and awesomely efficient. It is also not a requirement of the protocol from the start and is something that can be added down the road.

Regardless, multiple SHs acknowledging the same transaction does not pose a heavy data load on the network. We are still vastly below bitcoin in bandwidth usage.

The limit is based on each person's idea of profitability. I do not make any notions about this. If SHs are making 0.05 decrits per day each, the incentive is much less than if there were 1/4th the SHs making 0.20 per day. Remember, they are putting a significant amount of money on the line for the privilege, and while it is privilege, it is also a job, and there are benefits to doing it well and penalties for doing poorly. And there is also the simple fact that when a banking system is in place, there will be competition for better interest rates.


Bitcoin uses a transaction ledger, decrits will use an account ledger that maintains the balance of each account rather than keeping the history of all transactions. This significantly reduces the storage requirements, and it significantly lowers the bandwidth requirements as any accounts that already exist can be referenced by a 5 byte account integer rather than a tx out address. The Consensus Block, which the entire network has to agree on or the network splits, contains the hash tree of this ledger.


In theory, yes. In practice, the likelihood is still bound by the odds of how many corrupted SHs EvilCorp can get in a row.


I'm not sure I understand your concern about an open consensus. Didn't you just propose a closed one? Shouldn't I be the one concerned about the centralization of your proposed idea?



Ah yes, this is the AnonyMint thread on his proposed currency, I forgot.


I am totally fine with that and I appreciate it. A lot of the ideas in decrits were incorporated from discussions of prior proposals, and a lot of the time I disagreed with the person making those ideas at the time.

What I am not fine with is this:


Not only is it a fallacious argument, but it is also based on a lack of understanding. I know, I know, the proposal is not that clear. But you were coming along just find on understanding the consensus system when you decided to take a nose dive into completely redesigning it because of some weaknesses that are not so weak on further inspection (we can get into this later), and some weaknesses that don't exist at all. Namely SHs being able to prevent others from signing consensus, and/or the data cost that preventing this in an open consensus might take.

Can we say that this is a fairly succinct description of the problem? I'm going to try avoiding gigantic posts so I will continue this in another post.

The vulnerability you keep reiterating is one where SHs will not get a chance to be involved in consensus. This is completely antithetical to the idea of consensus, so I don't know why you've picked up this notion.

I can understand your worry about data usage, and it is a valid concern. But instead of assuming that some SHs won't get to participate in consensus (repeatedly), or that SHs have to be heavily limited, you could have asked how I propose to resolve this to keep the system efficient and decentralized, rather than assuming I have walked into this without any consideration for these things.

So give me a freakin chance to respond and stop making 3 posts in a row that go all over the place with my ideas, your ideas, and NWO.

I will respond in a few hours with why your vulnerability is not there, and I will give you two examples of potential ways to reduce/eliminate gaming of even the order of SH selection.

Let's see... how about completely ripping it apart based on vulnerabilities that you believe exist because you don't understand parts of it, and then reformatting it into something else that you are trying to convince me is the way forward. After I've spent 2 years designing this and you've spent 2 days learning about it.


Fine, but I'm not getting into that with you until you understand the security.


I changed the post to say straw proposal.

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

Where are you getting this from? What have you intuited here that has any relevance to my proposal? This continues throughout that post. You are either telling me how my proposal works (incorrectly) in spite of the discussion so far, or you are basing this off of your redesign. I have no idea.


Then why the hell did you take all of a day before trying to fix something you don't even understand yet?

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.

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.


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.


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.

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.


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


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


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.

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?

brenzi, welcome back. You owe me a reply.