Some further notes:

One problem is that the price of mining may change (most likely fall). This can occur either due to more efficient mining rigs, or lower electricity costs.

First is the problem of more efficient mining rigs. One way to solve this is to make sure they are already as efficient as possible, choosing a hashing algorithm that has already been fully optimized.

A more sophisticated approach is to use multiple, separate hash functions, such that they are unlikely to optimized at the same time. We could imagine each having their own stable coin (on the same block chain), and when a hash function is about to be or is being optimized, those coins can be destroyed in favor of another hash function until the optimization is done. Since this isn't trading, but conversion, this shouldn't cause any economic problems. (When mining, you are always rewarded in TradeCoin, regardless of the hash algorithm you are using). This would also be interesting in that different blocks would have different proofs of work.

An even more sophisticated modification of the above is for the ER between VolatileCoin and StableCoin to be based on multiple hash functions. When the difficulty of one of the hash function rises rapidly relative to the others, you know that means that it is being optimized, and the network can compensate. Once it stops rising, it can be re-pegged to StableCoin. This has the advantage of having only on StableCoin (a good thing for cold storage users) but the disadvantage of requiring a more complicated algorithm (which may not work as well as a market).

Concerning the multiple StableCoin proposal, you could introduce a third key called the "Conversion Key" that can convert but not spend coins associated with an address. This way for cold storage you only need to keep the private key really secure, since the Conversion Key is a less profitable target.

The harder problem is electricity costs. Although electricity has been better at keeping value than fiat currency, it is still decreasing. One thing one could do is put is hard code a factor to adjust the ER based on how we predict the value of electricity to change, but that is probably hard to predict (it could rise in value once fuel starts running out).

We could try repeating the above perhaps. In addition to an electricity based POW, you could have storage based POW. You can have people sell their disk space, ala Storj and Sia, for TradeCoin. This can help predict the correct ER.

Concerning short term stability ("wiggling in the price") although shorter times between blocks, advanced difficulty adjustment algorithms (maybe something like PID) and lower difficulty uncle blocks can help make sure the ER is up to date, I don't think that is necessary if long term stability is achieved. If the price falls a little bit, no one would sell, since they would just wait for the price to go back up. If the price falls a bit, no one would buy, since they would just wait for the price to go back down. For most assets, like other cryptocurrencies, you don't know if the price will go back up or down, but if long term stability is achieved, you do know. What would happen is that if the ER is adjusted fast enough, VolatileCoin would change in price, not StableCoin. (Again, this paragraph is dependent on the assumption that StableCoin's price is in fact stable (or at least predictable).)

Some currencies have tried to be stable by having a centralized authority which backs up the coin for something of worth. The problem is, sometimes these centralized authority spontaneously evaporate (https://daology.org/proposals/dcda223aa190358023cc066208f820614df3f310).

In https://bitcointalk.org/index.php?topic=1466607.msg14800985, I described an idea for a pegged cryptocurrency, based off another coin for arbitrage. The problem was that getting information from the outside world is really hard. I realized that we do have information from the outside world: the difficulty.

In particular, the difficulty reflects the value of the coin being mined.

Therefore, I propose the following:

There will be two coins, StableCoin (or just SC) and VolatileCoin (or just VC). StableCoin will have a stable price. When there is a price pressure on StableCoin, VolatileCoin's price changes instead.

How is this accomplished? Miners will mine VC, getting some reward each block. They also get transaction fees. The smallest unit of SC is the hash (similar to the satoshi in bitcoin). The average number of hashes miners have to do mine a block can be determined from difficulty. An exchange rate (or ER) is determined, by setting hashes = the miner reward (it's okay if some or all transaction fees are in SC, you just need a little bit of algebra.)

What is the significance of ER?  StableCoin can be converted on the blockchain to VolatileCoin according to the ER, and vice versa, using a special transaction.This isn't simply a trade; if you convert SC to VC, SC is being destroyed, and VC is being created.

What this means is that the actual exchange rate on markets between SC and VC must be ER, or arbitrage will occur to correct it.

A hash will always be equal in value to the amount of electricity required to do a hash (which we presume to be stable). Since a hash is just a unit of SC, that means SC is also stable. The only way for this to fail is if the value of VC falls to *exactly* zero, since this would cause a division by 0 error.

Some notes: You must make sure that no coin is merge mined with VC, or miner reward (in VC) won't equal the number of hashes. One thing you *can* do though is make it so that the hardware used to mine VC can be used to mine other coins (such as BitCoin), but not at the same time. This makes is easier for miners to respond to price changes in VC.

---

So, what do you guys think? Would this work? If not, in what manner exactly would it fail (keep arbitrage in mind). I haven't taken any Econ courses, so I'm wondering what someone who has will think of this idea (I have some ideas about how this coin might fail, but I'm sort of a fish out of water without basic Econ experience.)

Also, if anyone wants to steal this idea, go ahead. If no one does, and no one finds any obvious flaws in this design, I may look into actually starting this coin. Having stability in your currencies value is a huge win, and is necessary both for long term savings and day to day use. Although you can achieve stability by having a big economy, the above shows how you can "cheat" the system and get stability with a relatively small economy potentially. (If you do steal the idea, PM me. I would love to see what actually happens.)

Someone should do a pump and dump (something something education).

Just say you are buying them for $100 each. People will scramble to get them, and you can sell them (under a different name) for $10. 😂

I wonder if it would be possible to draw a giant elliptic curve and do it that way. Elliptic curves probably aren't geometrical for finite fields though.

Okay, so let's say I have flipped a fair coin (on which I've done extensive statistical analysis on (doing the statistics by hand)) 256 times and now have a private key. How would one go about calculating the public key by hand? This way the private key has only gone through one brain, an organic one.

I'm okay with using things like paper and pencil, and even an abacus, but nothing that uses electricity. (Mechanical computers of sufficient complexity should also be avoided. The human mind should be doing the brunt of the work.)

(P.S. If you are actually interested in creating private keys by hand, I would recommend shuffling a deck. A randomly shuffled deck has about 225 bits of entropy. (See en.wikipedia.org/wiki/Shuffling#Research and other sources for random shuffling.) If you want all 256 bits, shuffle the deck again and draw 6 cards. Although you could convert this to a number using a mixed radix method (en.wikipedia.org/wiki/Mixed_radix), its easier to type in the deck and hash it. The advantage of the deck method as opposed to computer based methods is you don't have to worry as much about your entropy source being compromised (its only likely that the NSA has tampered with the thickness or amount of friction between the cards.))

If they pick 0%, *all* of the fees drop the 0%. If a fee is more than p, the miner only gets p of every transaction.

I chose for it to be relative to the transaction because including transactions should be negligible, and the amount of benefit a user gets in proportional to the value of their transactions.

p is a number from 0% to 100% choosen each block by the miner. It is the percentage of each transaction that are sent as fees. This way, within a single block, everyone pays the same rate.

Well sure it will be in the future, but bitcoin is supposed to be futuristic technology. Planning ahead is a good thing.

That is correct. The problem is, limited block space is bad. It limits the throughput of bitcoin.

Tragedy of the Commons (https://en.bitcoin.it/wiki/Tragedy_of_the_Commons) is a problem that bitcoin will face as miner fees decline. Since including a transaction in a block is negligible, miners will accept all transactions with positive fees (no matter how low). Then, users will set their fees to the minimum possible. This in turn leads to less bitcoins going to fees, and less network security (since the cost of 51% attack = cost of mining = revenue of mining = fees at this point).

Many solutions have been proposed, but I don't like any of them (since most of them involve hard coding constants). I have a solution that requires no hard coding of constants!

How it works is that each block specifies a fee percentage (say p), and all transactions are based on that percentage.

If a transaction comes with a fee that is more than p, additional money is refunded back to the user so that it is exactly p.

If a transaction comes with a fee that is less than p, that transaction can't be included in that block.

This means that if a miner selects too low of a p, they will get less money (since all transactions are lowered to that amount), but if they they choose to high of a p, they will get less money (because there will be some transactions they can't include). They have to choose the correct p, which won't approach 0! Users in turn have to include enough fees to get accepted into blocks. In actuality, if there are a bunch of low fee transactions, someone will eventually include them with a low p, since there are so many. So your fee determines basically how soon your transaction gets confirmed.

What do you think?

I just though the word "BitcoinCoins" was funny. Again, this would work with any commodity (or number really. You could make numberOfCloudsCoin, but I don't know why you would want to). I doubt BitcoinCoins would be a thing, but I could definitely see GoldCoins being popular (if my proposal is sound).

I think ideas for pegged currencies have been proposed before, but here is one that I think is novel (tell me if it isn't).

First, choose what you want to peg. It can be gold, USDS (ugh), oil, hours of labor, global economies, stocks, land, bread, electricity, mining rigs, baskets of things, etc...
Let's say we are doing Bitcoins (ironically).

Now, there are two currencies: BitcoinCoins and TradeCoins, supported by the same block chain.

First, develop a decentralized consensus protocol. This means you need to be able to have your blockchain determine a number in the real world. One way I saw to do this is that everyone puts in their answer, and whoever is close to the median gets payed, those that aren't don't. The idea is that everyone will submit the right answer, because they don't want to risk not getting payed.

Now, start your blockchain, and have miners mine TradeCoins. There are no BitcoinCoins yet, and you don't need the consensus protocol yet.

Now, once the TradeCoins start gaining value (maybe they have faster transactions times than other cryptocurrencies, or smart contracts, or something) you start phase 2 (you can hardcode phase 2 to start at a specific time based on when you are pretty sure it will have value).

Use your Consensus protocol to determine the value of TradeCoins relative to Bitcoins (you will be doing this every block for now on). Let's say 10,000 TradeCoins = 1 Bitcoin. (Note that you don't actually need a TradeCoin to Bitcoin exchange to figure this out. You can take TradeCoin to USD to Bitcoin to determine the exchange rate (or through any other commodities)). Now, you can destroy TradeCoins to get BitcoinCoins, and vis-versa. This will make BitcoinCoins equal in value to Bitcoins (or whatever commodity you chose to peg to)!

If BitcoinCoins ever get less valuable than Bitcoins, people will destroy their X BitcoinCoins to create Y TradeCoins and trade them for X Bitcoins. People will even buy BitcoinCoins with this explicit purpose. This will continue until BitcoinCoins raise in value to the value of TradeCoins.

If BitcoinCoins ever get more valuable than Bitcoins, people will trade their X Bitcoins for Y TradeCoins and destory them to create X BitcoinCoins. This increased supply of BitcoinCoins will decrease their value (or Bitcoins will increase in value as people buy them to take advantage of this scheme), until they are equal in value.

In reality, BitcoinCoins will follow the value of Bitcoins.

You could even have multiple commodities. You could have GoldCoins, USDCoins, EuroCoins, BreadCoins, TradeCoinCoins (actually, that would be dumb), etc... All based off exchange rates with TradeCoins.

What do you guys think? Would this work?