SHAREHOLDER OPERATION (formerly TradeNet)
Buying a share: People who wish to be a Decrits shareholder must buy a share equal to 150,000 times the minimum transaction fee (likely to equal 3,000 decrits for a long time). As a shareholder successfully secures the network, he will earn reputation over time. Each new shareholder starts with a reputation of 1,000, with a maximum of 5,000 reputation attained after 5 years of service to the network (or some similar mix of numbers—like 1 CB is 1 point).
Shareholder profit: The amount of reputation directly correlates to percentage award of the transaction fees earned. While it may seem harsh to award so much more to those who have serviced the network longer, it provides many benefits to the security of the network. Allowing lots of reputation to be purchased easily would allow “evilcorp” to squeeze honest shareholders out by removing their profits. If “evilcorp” does try a takeover, the network can split (see Voting), and Evilcorp’s money will be voided, and they must wait 5 years to try again.
NOTE: The voting system does sort of make an Evilcorp takeover useless, but becoming a shareholder should be a big deal not a quick investment.
Network security: Shareholders are randomly selected in a pre-determined order (based on CB data from the prior day or some such, something where we know close to 100% of the network agrees on) to create a transaction block for each 10 second window in a CB. Individual shareholders will keep track of the average latency between the timestamp of a tx and when they receive it and use this (based on some standard deviations) to determine how long they will wait before sending the TB. For example, 3 standard deviations of transaction latencies fall within 7 seconds, the shareholder will wait 7 seconds after their 10 second window, timestamp the TB and send it. As the network becomes larger, additional shareholders will be chosen to sign these TBs along with transactions that were missed to keep network consensus times reasonable.
NOTE: As long as the transaction blocks are all known up to this point, transactions are bad spend proof (spending more than what is in the account). Double spends are possible if the specific shareholder creates two blocks with different transactions. However, a merchant needs to only wait for the next block and see which block it acknowledges to avoid fraud.
NOTE: If a shareholder has not created a block within the network latency window (perhaps this is a factor that will be averaged based on when shareholders create blocks, multiplied by 2 or 3?), the shareholder who currently has jurisdiction will include transactions for that time frame in their block, and require the shareholder who missed the block to sign that block within a certain time frame (how long is up for debate, it must be reasonable to account for network outages or the like) or they will be booted from the network and lose reputation.
Penalty Reputation: Whenever a shareholder receives a penalty to its reputation, it also receives penalty reputation points. For example, if a shareholder missed his block and did not sign the follow up block in a timely manner, they will be forcibly signed out of the network, lose 10 reputation points, and gain 10 penalty reputation points. When a shareholder signs back in to the network, they must work for nothing for a CB for each penalty point, then when the penalty points expire, they will resume gaining reputation and earning money.
For each CB after a force sign-out that a shareholder does not sign back in, the shareholder will lose another reputation point and gain another penalty point. If penalty points reach 30, the shareholder will lose all reputation and will have his stake removed less a 25% penalty (destroyed).
NOTE: There may need to be another semi-permanent reputation system that is on a yearly basis and does not reset after working off the penalty points. Maybe.
Vacation: Shareholders will be able to voluntarily sign off of the network as long as the total reputation signed in is high (>90%), and they will have a period of several CBs before earning penalty points. Shareholders will probably need to wait until >50% of the network has signed the sign off. If total reputation is below 90%, there will be penalty points involved in signing out. This is actually a somewhat complex issue that will need to be delved into a lot more detail in the coding stages.
NOTE: Shareholders may earn vacation “time” that can be used for up to 14 CBs or something.
Overriding blocks: If a shareholder misses significant transactions (potentially on purpose) such as winning mint blocks or other data that might interfere with a network takeover, there must be some way to respond by honest shareholders and/or CloudNet members that basically says “include this stuff or you’re forking.” It is possible that honest shareholders may miss this message though if a significant number of CN members are also hostile. How can this be resolved? Honest shareholders may miss it and then be booted from the forking, honest network through no fault of their own. Dishonest members could continually DoS the network if they are allowed to “make amends” for missing it and rejoin the honest network. Perhaps require some kind of network-wide block that CN members and shareholders must sign? Keep some kind of running counter going of missed transactions and when it hits a certain number force this block (with a larger number of counts for important network events like shareholder signatures etc.)? Who initially creates it? Perhaps use distributed signatures to keep bandwidth down? Final penalty for this fork might just be the 25% money penalty and loss of all reputation. At least that way, honest but not well connected shareholders are hurt, but do not lose their entire deposit, and the network reputation is cleansed. Honest shareholders should definitely be changing their CN peers all the time to avoid the possibility.

BLOCK CHAIN FEATURES
Script hash storage: A separate CB section for storing script hashes. Fees will be based on a charge to maintain it for 30 CBs which will equal it’s tx fee based on bytes times 2 or 4. If there are functions, the price will probably increase. Should make it work so that people using these can save data if they use the accounts frequently by just referencing the storage instead of repasting the script in each tx.
Account restrictions block: similar to the script hash storage, but for specific account restrictions and does not require a public address to be a script hash. These restrictions can only be bypassed with a “super key.” Examples would be once X coins are transferred from an account in a day, another wallet will have to approve more transactions. These would probably be on a yearly instead of monthly basis, something like 5 enc per year. Option for automatic renewal; option to set how long before a change to the restrictions will take effect (in case somehow both keys are compromised). This service will be free for TN members. Maybe an option for TN members to use a totally different key for signing things on the network.
TradeNet history: A special block for keeping track of tn public keys and the signatures changing them. This should be kept for at least 1 year, maybe significantly more (10 years?). That way a user who has not logged in in a long time can verify new public keys easily without relying on trust.
Proof of work block: possibly a block that stores the best target hashes found to date (and a bunch of recent ones as well) as a way to add security? Might only be a token measure of security as I don't think this will do anything to prevent malicious network splits (and those are covered anyway).

GENERAL FEATURES
TX FEE: Based on bytes. I can’t see a fairer way to do it. Whatever is the standard tx size byte range, use that as a figure to make it 0.02 decrits for that tx size. Also for transactions invovling money transfer, 0.01% of the tx or the tx fee, whichever is greater. This disallows future banks from simply settling up with each other once a day or so in 1 tx and only paying 0.02.
NOTE: Some baseline must adjust over time. The minimum 0.02 fee I think should be this factor. For example, if the minimum fee is only applicable to <10% of transactions, the minimum may need to be raised based on the bottom 10-20% of fees, or whatever seems reasonable to base fee minimums around. This will eventually be used to determine costs for scripted transactions. For example, a certain script has 5 operations, so the fee is 5x the minimum fee (potentially plus a tx fee, and/or bytes fee). The bytes fee will be re-adjusted based on the minimum fee to match up with the most common (? mode?) transaction length.
NOTE: A neat idea would be to rebate transactions falling under the minimum fee by up to 3/4ths of the fee, perhaps allowing for 1% microtransactions CB and rebating at random* (during the CB) some of the fee. Any spam attempt will quickly hit the 1% limit and will cost full price.
* Only if there are more than 1% of transactions that require the minimum fee. Otherwise all will be rebated based on 0.01% of the tx with a 1/4 of minimum tx fee minimum.

SUPPLYNET (SN) OPERATION
Coin Creation Period (CCP): A CCP is a span of time that it takes to create a certain amount of new coins. The number of coins required to finish a CCP is equal to (transaction fees over the last 360 CBs [or most fees over a 360 CB period ever] x 5 [or 10 – this # can be voted on and changed] / 12). If a CCP fails to finish (the pool of users gets too small after missing solution times or signing out), there will be a penalty to all coins minted to date in that CCP.
Queue joining: Before a new CCP has begun, or before 1/3rd of the coins in that CCP have been minted, the charge for joining the SN queue will be a D0.20-valued solution. Between 1/3rd and 2/3rds the fee is D0.15, and after 2/3rds it is D0.10. The CCP will begin when (total CCP coins / 20 <= # of queued SN members). Formula subject to change and will have minimums and maximums.
NOTE: This means there are diminishing returns on using many accounts and attempting to monopolize or whatever else.
NOTE: The number of coins to be mined will be what sets the minimum # of users to be signed in before mining begins. (and there should prob be a min and max minimum.)
SN Groups: At the start of a CCP, 50% of the SN members are selected in groups of 40. Slight payout bonus to the first 10 in each group, no bonus to the next 20 (or slight bonus to first 10 slight penalty to second 10), and a slight penalty to those in the last 10. After each member of the first two groups of 10 finds a solution, they are broken off into new groups with the ungrouped people (there should be some maximum waiting time on this as well, such as 1st bunch will be released to regroup after 0.25 coin hours or so). As members in the second two groups finish, they are added into the ungrouped pool as soon as they finish.
NOTE: If a member does not find a solution within 3 standard deviations, there should be a penalty. Since we know that some GPUs will be below average, some probability math has to be done to determine a safe number of SDs to boot members out who take too long. This is important as it shows there is a risk to running this with botnets or multiple IPs (the fee to join will quickly take a toll).
NOTE: Should each place get a slightly different bonus, e.g. 1st > 2nd? This will encourage more honesty about finishing times (and possibly more controversy—might be more difficult to pull this off). Need to think on the pros and cons of this.
NOTE: Places will be determined by their order of acceptance in the tx block chain. If two or more solutions are within 10 tx blocks, they will be considered a “tie” and broken by the best hash. This is to keep TN peers from cheating for SN friends or themselves.
NOTE: Force inclusion of a recent tx chain hash (at least within 10 mins->10mins of the 50% approval chain, not the most recent) and a hash of all the members in the group, etc. to prevent “pre-imaging” coins. These bytes don’t actually need to be sent (tx chain hash can just be the chain sequence number although that is an extra 4 bytes).
Determining difficulty: Anything longer than 3 standard deviations long (maybe more, dunno yet) is dropped, then the top 25% and the bottom 25% are dropped and the middle 50% are compared to the previous CCPs. Maximum increase in difficulty at maybe 150%? It would only ever get anywhere near that ballpark if there were some new way of hashing. Difficulty will be increased in a weighted fashion based on the number of coins created in this CCP vs. the last X (9?) CCPs.
Awarding coins: During Phase 1, coins will be awarded immediately. Starting with Phase 2, coins will only be awarded after the CCP has finished, and they will be awarded based on the CB they were minted. E.g. if a coin was minted on the 3rd CB after the start of the CCP, it will be awarded on the 3rd CB after the end of the CCP. At this point, the actual amount of coins awarded will be reduced by the increase in difficulty over the last CCP. This allows for an attack on difficulty to net very little money while only affecting the difficulty somewhat.
Coin award & Koomey’s Law: The base coin award for a SN solution is 2 coins. This will be an option that can be voted on (0.5-4 range maybe?). The smaller the number, the more network load; the higher the number, the higher the variance. For Koomey’s Law, if several CCPs in a row have passed with very little difficulty increase, the coin award and difficulty (and total CCP coins) will be reduced to 90% of their original values. If again there is not much difficulty increase, 80%, then 70%, maybe even to 50%. After difficulty starts increasing again, the award will return to normal with the new difficulty multiplied up. This is all a bit hand wavy at the moment, but it is to allow more efficient machines to set the pace. Could this backfire? Limit the maximum difficulty increase to be less than 10% or something? It could possibly be manipulated.
The more I think about this the more I think that more efficient machines will probably just stay with the herd and lower their output accordingly. Full computers will actually have to use less than the % reduction in difficulty to maintain the same profitability because they are always powering extra equipment beyond the GPU that does not reduce in power usage. Maybe make the difficulty a bigger reduction than the coin reduction. If we think of setting your GPU (or other device) output to “this is where I am profitable if it takes X hours to make 1 coin”. X being the average creation time for 1 coin. Since the difficulty updates the coin award afterwards, it won’t hurt anything to make the difficulty lower than normal. But, people could vindictively raise the difficulty or again more efficient machines could just mimic the less efficient ones and nothing is really accomplished.
NOTE: Is there some ingenious way to to increase the difficulty of coin creation to separate the wheat from the chaff, so to speak? As more coins are mined, start increasing difficulty just because (perhaps along with the increasing trade/save coin bonuses) to see how long people will keep mining. Maybe if at least 50% will keep mining, increase the difficulty permanently? This will get the time lengthening effect intended by the Koomey’s law to keep the value more stable. BUT, the efficient miners will have to be rewarded in a way that they will want this. During high demand, this might just unfairly and unreasonably increase difficulty. So nevermind, this exact idea won’t work I don’t think, but maybe something similar will.
NOTE: A significant improvement to the above idea is to simply start increasing difficulty after a certain number of CCPs in a row (starting within 10 CBs perhaps). This would allow for a form of deflation and would likely stabilize the currency quickly in the face of new technology. What kinds of numbers to use here though are very much up for debate and will probably require extensive testing. Do we raise the difficulty more if the difficulty has gone up 5% in each of the last X CCPs? Perhaps at the same time increase the multipliers to savers/transacters? (As mentioned below)
Coin bonus: Coin bonuses will increase in phases like stated in the bootstrapping section. However, once coin bonus is active, if there are CCPs less than 30 (90?) CBs apart, the trading coin bonus (or both) will start increasing above the regular coin bonus. For example, in phase 3 the coin bonus is 1x trade 1x save. If the second CCP in a row starts, the coin bonus will now be 2x trade 1x (or 2x) save. This can continue indefinitely. A CCP amount of money will be determined by highest amount of transaction fees ever recorded over a 360 CB period x X (5? 10?) / 12.
NOTE: As far as transaction awards go, there should always be a negative expectation when making a transaction in the hopes of getting a reward. For example, a 0.02 fee transaction must, on average, only earn 0.019 decrits from transaction bonuses (e.g. for each 101 transactions at 0.02, 1 is awarded 2 decrits). Money that is left over if there are not enough transactions could be stored and doled out as time goes on.


BOOTSTRAPPING
phase 1: helicopter (years 1-3)
* stake price: 2/5x
* coin award: 4-2x or 5-3x changing on a cb to cb basis
* tx fee:
SupplyNet coin awards: After phase 2 in the bootstrap, coins won’t be awarded until after all coins have been minted during a CCP, or after the CCP has failed to complete.

OTHER THOUGHTS
Maximum TradeNet size: some kind of network maximum # of TN peers? around a million or so? after this number is reached, if it goes much higher start lowering tx fees?
Multiple and modular algorithms:  allow user to decide if they want stronger or weaker cryptographhy. weaker will have smaller receiving tx fees. can only really measure bandwidth not cpu usage. along with mod algos, keep track of average standard tx size, if it goes higher start basing tx fees lower around the new higher avg.
HYBRID TX: allow transfers between encoin/bitcoin through the encoin protocol by making a bitcoin contract that involves encoin addresses (this is plausible, I believe, hopefully right now), then when the block this bitcoin trans is in has 6 confirmations, either party can send a special transaction containing enough info (merkle trees etc.) to provably show a secured bitcoin trans, then make the trans on encoin
ALT BLOCK: another block that allows certain “proofs” to be maintained in the network. For example, if an altchain wants to use encoin as its base, there will be a basic option to use hash proof of work and the solution. How to adjust difficulty? Another simple proof is just a timestamp, a hash, and a signature. How to extend this to be useable by things like ripple, open transactions, p2p markets (WoT)?
OOB: Out-of-band support in the client. Allow clients to connect to trusted sites/peers to send or receive tx information. Provide the option to support this within the client itself so a client can be an OOB peer or can send info to an OOB untrusted server to separate IP addr.
NOTE: A whole OOB protocol section of the software for things like getting exchange prices and more. Designed with extensibility in mind.
SHARDS: Allow for “shards” to be made if all the data/tx processing is too much. Vote to “add shard” and split everything in two. Accounts will be split between shards based on modulo 2, tn members split by reputation evenly. A small extra fee for transfers between shards, otherwise merchants can just make another acct in the other shard so no new fees. Perhaps a max of 5 or so shards. Also possible vote to remove. Minimum # of tn members required before allowing vote, like 5k or so.
NOTE: Shards should split between 1, 2, 4, and 8 and that’s it. It will be the easiest to divide apart that way. Make sure splits are random, not just modulo, because otherwise an evil entity could try to take one half more easily. Even at 8, the most a usual tx will need is only 2 shards, so it still saves data even… prob shouldn’t charge any tx fee.
NOTE: Confirming transactions between shards will be tricky. Will need to be some kind of tx chain interweave using hashes between the shards so that all shards are approving all txes. 50% approval needs to be done first in the originating shard, then a special tx will notify the other shard that there is an incoming tx?
PROBLEM: Web of trust groups will have to be broken on sharding? Each TN peer will want to stay on the same shard so it doesn’t have to download 30 days of data for another shard. How do we keep full system integrity? Can we just assume that SOMEONE in the cloudnet will be honest and report a problem? I think so. TN joins and all regular network traffic will have to be approved by everyone.
DATA SAVINGS: Nodes should use timestamp + a 24bit?? Int to keep track of txes already seen or acked between peers, that way only 3 bytes per tx when sending around tx blocks. Prolly timestamp + 8 bytes hash for first time even though 8 is prob overkill
VOTING SYSTEM: options--yes, no, breaking (or some better word) yes, breaking no. Breaking versions would mean those who vote breaking will form a new network if their vote is not in the super-majority. Super majority is required for any vote to pass, 75% of all network reputation. Upon breaking, TN members will be removed from TN at a 25% stake penalty. The two networks will be “copacetic” and stay connected to each other. Each network will send the first transaction from an account to the other network. This transaction will “lock” that account and those funds to whichever network it was transacted on. In other words, it will be deleted from the other network. This will allow the people to choose which network to use, and to disallow double spending. Voting options will include: deprecating/changing hash functions to use for various network aspects; . Voting will have to be by blind signature then revealed after the vote is over. Anyone who doesn’t unblind will face 25% stake penalty and TN removal. Always at least 30 CBs before any vote takes action. Maybe the “copacetic” structure will require a minimum of at least 10% breaking (I say no, I think)? Can a majority vote be filibustered if say, 1% vote breaking the opposite way? It will delay the final vote another 30 CBs. Instead of previous “copacetic” structure, maybe just allow transfers between networks for X amount of CBs (in the years)?
25-75% breaking change: “copacetic” network
10-25% breaking change:
Voting history record maintained for 10 years?
NOTE: if a “no” breaking vote has a significant portion (>10%) this should be the “standard” network and people can move over to the “new” network since it has changed rules.
SETTINGS.INI: There should be a basic “settings” file that allows the commonly voted upon things to be changed (perhaps multiple things in one go, it will update the settings.ini basically and the software will use that to determine how to perform certain network functions). Anyone that “breaks” no on these will be the “new network” because these are basic settings that are changeable.
NOTE: Perhaps whenever anyone on the losing side wants to break, allow a re-vote to avoid creating a small, probably useless network where the breaker would lose all their money on the main network (and thus be unlikely to vote the way they truly feel the first time).
Maybe scratch most of the above. Yes, No, Break (divorce maybe?), break being a secondary vote if at least 5% vote break that will filibuster and force the yes voters to break to a new network if they so choose. New networks can be created as more of a “we’re doing this, who’s coming?” thing instead of a vote. This may make a lot more sense. Any of these options make change very difficult though. Who will volunteer to potentially lose their money? How can this be made to work together? Perhaps the breakers can set an interchange period of many years if they wish where people can send money directly from the old to the new network, but not back.
NOTE: If >50% vote divorcing yes and/or >10% vote divorcing no (w/75% saying yes, maybe only 5%?) then split the two networks evenly with half of accounts going to one and half to the other. Money will be allowed to be transferred inbetween the networks indefinitely until one or the other votes to stop it (with a minimum of 90 CBs or so). Perhaps only allow the first transaction to be a tx to the other network or that money can longer be transferred? Like if someone takes over 50% and divorces yes to a super inflated currency, it could hurt the people who want to stay on the no side. Is there any way to rectify this? Perhaps allow each account to choose? That’s an idea full of problems though. If the outcome is a network split, perhaps have a set bunch of varying options that can be voted on (probably by the ‘no’ votes only since they will lose to whatever option the ‘yes’ wants if it is some kind of attack).
NOTE: Perhaps if there is even 1 divorcing vote allow a network split (or some very small minimum, perhaps 0.5% of the shareholders). All old accounts will not be able to receive transactions, only spend. Spending will require some new tx format that specifies which network will receive the transaction (or an existing format that increments a bit or something to differentiate the networks). Once money is spent to one network, it will stay on that network. This will ultimately allow the clients to choose which network.
NOTE: In addition to the above, there must be some minimum amount of reputation before 75% or 90% votes can take place to protect the userbase.
SPECIAL TX: possibly a blank “to” address for sending a tx that can be filled in by anyone later. Could this possibly be used to aid anonymity somehow? Possibly combine with blind signatures?
CLOUDNET: Find some way to pay cloudnet volunteers. Volunteer, IP gets listed in the CB, then have people connect, send txes, and include an extra 4-5 bytes for a wallet ID? Then give the CN volunteers some portion (perhaps money out of air) payment of what TN members get. Maybe.
NOTE: Perhaps find a way to anonymize this process with encryption and a hop or two? Perhaps allow TN members to connect to any of these peers then give them a nod in a TN block? This would be much easier to abuse though.
NOTE: cloudnet block with 3 byte address (max 16.7 mil CN peers) and payout wallet ID, use the tx system with extra bytes almost exclusively.  Keep count of how many transactions (just a point per tx, nothing special) have a CN peer included, award top 50% in points 5% of the daily fees divided evenly. Simple payout so that no gaming can happen, or it is much more difficult.
Should there be a max number of CN peers based on the number of TN peers? Keep track of an extra pool of “wanna be” peers? Select from them randomly on occasion? Update your status once a CB or you’re removed (at least if no txes selected)?
NOTE: Require an account with at least 1 DCR (50x the minimum tx fee) in it to join the CN. This coin is removed until they sign out. Require CN peers to connect to each other in a distributed way, e.g. each peer needs to be connected to 3 other peers determined by the network (random based on a hash). This way, people can send 1 extra hop encrypted txes to a peer that a CN member is connected to. It isn’t fool proof, but peers will be encouraged to act responsibly with DoS measures (not sending me anything but his own txes? I won’t propagate them.. something like this)
NOTE: Minimum % of txes must be verified by CN member, prob 10% (perhaps based on the # of members?), if they do not verify a tx that they are supposed to they will lose their coin and be kicked off (coin will go to CN pool, not TN). Which txes they verify are based on their CN #.
NOTE: Allow for different types of addresses for CN peers. IPv4, IPv6, .onion, etc.