Replying to a PM here...
If a malicious entity attacks an individual shareholder, it's far too easy for them to cost that sh a lot of money. This is going to happen, and that is too problematic for me to consider being an sh.
Unless the malicious entity has direct control over the computer in question, they can't cause a SH to lose their share. If they can manage to surround a SH, it is possible to prevent the SH from sending his TB and cause him to receive a soft strike. But with the network having an encrypted handshake process and "public access nodes" that require a deposit, finding a SH will be difficult, and surrounding him even more so. Paranoid SHs might just send their TBs to Shadow Peers only for the first few seconds, then send it to CNPs for wide distribution. This provides quite a bit of unlinkability if most SHs do this.
As far as compromised computers, there may be some software defenses, but I am not sure at this point. However, if people can manage not to freak out about having a significant bounty system, one of the bounties would surely be for developing a piece of USB hardware that could perform the SH duties and therefore be unhackable within reason. It would be fairly easy to adapt said hardware to also being the decrits "debit card". Since an account ledger is used in lieu of a transaction ledger, hardware devices can be much simpler than those required for bitcoin. Tx out information does not need to be kept, only private key information.
I also wondered about the 10s block time due to the nature of cloud distribution but I assume that out of order blocks are ok and some hard limit on how late it can be and how does that system work. Also the cb determines subsequent tb order, but how do we go from the last tb in a block to allowing time for late cb signings to creating the new cb to creating the new tb order. Block 2 tb order needs block 1 to be complete but they will overlap. So block 1 actually has to determine block 3's order, essentially using a double buffer mechanism. In which case, the shareholder system needs to allow for double buffering too because the sh may have dropped out in block 2, but block 3 is already being processed before we know that the sh has dropped out. I guess all it means is that sh's tbs get missed but as the sh has left then they don't lose their shareholding at the next cb
I addressed how this will work
here (towards the end of the post), though the idea about using the signature aggregate of all the SHs to determine the next order is no longer the design case since most sig algorithms are not deterministic. But it explains how the "double buffering" will work on a network level. As far as individual TBs being out of order and whatnot, the design of this is sort of sprinkled throughout the thread and has changed some during that time too. It's something I don't think I'll have a concrete idea for until I run some unit tests with a simulated network, as well as some math done on what the probabilities are of evil SHs having enough control to cause damage to honest SHs. I'm thinking 10 TBs must pass before a missing TB can "replace" later txes, and maybe 100 or more must pass before a SH will receive a soft strike for missing his TB. This would make it very difficult for internet lag or evil SHs to cause problems for honest SHs.
I have a comment on system complexity too. People are saying it's complex because it is multi layered, and there is economic theory involved at various levels. That is tricky to take in and leads to more edge cases than in a simpler system. Having more edge cases is usually, but not always, a sign that a system is flawed. That's why some people have an intuitive problem with it.
So even if it is still a valid design, it's hard for you to convince anyone to make it (hopefully you have tho) and hard to convince people to partake in it. There is a very important human psychology side to these things that gets forgotten about when engineering systems.
I am hoping that the psychology of "free money for anyone who accepts it" will be a powerful motivator. Once many smart people have agreed that the security seems "secure enough", not everyone needs to understand it. Just like very few people really understand bitcoin's security, but they still use it. Same goes for the network dynamics in part 2. The monetary system, at its most basic level, is fairly easy to understand.
And while there may be edge-cases, none of them are critical failures such as the 51% attack. And the network has the ability to coordinate changes via section 4. I don't know how it will work out in reality, but I envision an adaptable system that can only get better over time. I don't want to give up just because it's hard, and there might be problems. I want to try something that has the chance of being fricken amazing, and if it has a few hiccups along the way, it will be fixed. It's not worth the time spent being afraid.
I have the same beef with bitcoin wallets btw and have designed a much better way to handle private keys , addresses and other aspects that account for how 'my dad' works. It should lead to higher adoption (at least for people confused by bitcoin itself), far less lost coins, and far less stolen coins, even on compromised machines. IMHO any lost coins are the fault of the system and not the user unless they have been spectacularly stupid. Bitcoiners are techies so blame the user. This is fundamentally wrong and a serious flaw. Bitcoin banks will solve some of it (and I love the pooling/voting suggestions by the OT guy to keep money safe) but wallets need to be safe too.
Feel free to share.
I intend to have a design from the get-go for deterministic private keys so that money could never be lost due to a hard drive crash or an accidentally deleted file. This doesn't protect compromised computers, but that is a very difficult problem. (Although having a hardware dongle vastly reduces this attack vector, and can be simple to use.) I very much appreciate the fact that cryptocurrency needs to be easier for the end-user. And in some of the other pieces of software I've developed, I have created some insane pieces of code that existed purely to make the user interface just a little bit easier for a wider array of people. I love software that is simple and intuitive--and I have lots of ideas here. But the decrits engine is a much higher priority discussion. There is no point in making it easier to use if it doesn't exist.
Going back to decrits. I don't understand the account system properly but presumably the account ledger is a list of changes in account levels as opposed to transactions? A transaction is processed and the outputs are any changed accounts.
Yes, I should have re-touched on this in the OP, but the account system is one of the first couple of ideas I came up with 2 years ago on a blank sheet of paper. Even though it is a critical part of making this work, it's something I completely take for granted because I spent a lot of time thinking through it in the past. Basically, there is an accepted ledger that maintains a balance for each account, then current activity is stored on a second ledger that proposes changes to that each account's balance using references to transactions in the transaction block chain. I guess there is sort of a third ledger that are changes to be committed, because they won't all be committed at once but over time to spread the load on the databases. Anyways...
this post goes over some of the data benefits of an account ledger.
There is no such thing as interest but there is a lottery with rewards. Would this not be better as interest distributed to every account, or every account used over past consensus block/year if you wanted to prioritise those using the money rather than hoarding it - other currencies will be more commodity based so a reward for use is better. I can see the issue being people creating circular transactions to indicate use, but I wanted to bring up the topic of interest in theory as you'll have had reasons for choosing a lottery approach. I just think interest works better economically and intuitively. If you used money to perform work, you should be rewarded for it. If you didn't use your money then you don't get rewarded. This is the opposite to what banks (supposedly) do, whereby the use your money to perform work and pay you for letting them do that with your money.
Though brenzi has been challenging the deeper aspects of the currency distribution scheme, you are the first to question the most basic, human part of it. There are two reasons why I kind of dropped the "interest" mechanism, because I did actually have this as the noted design for a long time.
1) A *lot* of accounts have to be updated at one time. This could be detrimental to the operation of the network if everyone has to stall for a long period figuring out where money needs to go and applying it to the balance. If you don't update them all at once based on the same set of data, then you are required to keep data longer to keep that state of the network available to continue to award the proper interest over time. It would also be more complex to determine that state as time goes on because you have to walk backwards through history to find it.
2) It won't be a very meaningful amount of money. Sure, interest is great, but if all you're getting is a couple of
decents, how does that really incentivize using or accepting the currency?
However, the decision about point 1 was made with a less-developed system in mind--I think it could be accomplished with the current level of design. I never really came up with an "interest for money used" system in the way you describe. It has interesting implications. However, I think it has the problem of point 2. I like the lottery idea because it keeps the "small guy" on a more level playing field with the bigger guys. I think this will be important for the propensity to use decrits in less developed countries. It also means that just an every day person might have a greater propensity to use it. Or an every day business.
No huge investment in the currency is required to start seeing dividends. I think this will foster its adoption by a multitude of people and will help debase the current monetary infrastructure. Because let's face it, it needs to be debased. Replacing it with a whole new infrastructure of powerful people is not an acceptable alternative.
You really need to diagram this in both simple and complex form. You can't relay your message without doing visual representations of all levels, no exceptions.
After some delays, I think the wiki software being hosted by Ukigo is almost ready. But it is going to be quite awhile before it will have all of the information at all levels. Getting a lot of this discussion out of my notes and into something a little more formal has been very helpful though.