Messages

I designed a mechanism for efficiently determining the price https://github.com/BumblebeeBat/FlyingFox/blob/development/docs/coin_creation.md
That way we can sell unlimited coins at the current price.

I think we have been approaching the POW vs POS problem from the wrong direction. Comparing cost of consensus mechanisms is the wrong way to think about this.

It is bad to connect the consensus mechanism to the coin creation mechanism, because the rate of coin creation should be determined by the demand for new coin.

When the demand for gold goes up, we invest more into mining, and rate of gold production increases to meet demand.
When the demand for bitcoin goes up, we invest more into mining, and the rate of coin production stays static.

Having a fixed unchanging rate of supply is bad. It makes the currency price very volatile.
What we really want is for it to always cost 1000 coins of POW to produce 1000 cryptocoins.

If we disconnect the consensus from coin creation, then we can create something much more elegant. We can sell small amount of coins for small amounts of POW to determine the current exchange rate between coins and POW, then offer to sell any amount of coins at the current exchange rate. The resulting blockchain would be able to grow it's market cap very quickly when it needs to, without changing the price of individual coins.

I agree that POW is a great solution for coin distribution.
I am going to make a fork of Flying Fox that uses POW for coin distribution.
A problem with using POW for consensus is that if 51% of miners switch, they can modify the blockchain software.
It is not good to give miners this power.
Even if POW is used to distribute the coins, we should still use FF-POS to maintain consensus. That way, any >2/3 coalition of coin holders could update the software.

This section describes how changes to the schedule (such as yours) do not remove the need for expensive proof of work: www.truthcoin.info/blog/pow-cheapest/#the-coinbase-rot-paradox-less-is-more

I agree that marketing the initial coins is expensive. And I see how it is like having 1 block with all of the POW at once.

Bitcoin created a lot of coins when the price of a bitcoin was < $0.01
It cost a lot less electricity to produce a bitcoin back then.

If more of the 21 million bitcoins were produced when the price is lower, then the total cost of electricity to produce the bitcoins would be a lot less.

The price is very low at the first block, practically zero. It seems like the most affordable time to create the coins. The least work needs be done.

2) you only consider consensus maintained by the destruction of resources that cost the same amount for both coin-holders, and people who don't own coins. like POW and liquidity and elections. There exists a resource that is affordable for coin-holders, and expensive for non-coin-holders. (the coins)

Again, this is untrue. And furthermore, with a tiny assumption, that users are free to buy and sell coins (ie, that "a price exists", which -by the way- is a necessary assumption to even calculate the PoW expense, as it is defined with Bitcoin numéraire), it is irrelevant.

If an attacker was willing to purchase >2/3 of the coins, he would have control of flying fox the same way someone with >1/2 of bitcoin miners has control of bitcoin.
Flying Fox is only secure to a factor of 2. An attacker willing to destroy 2 of his own coins can also destroy 1 of someone else's coins.

Similarly, the truthcoin oracle is only secure to a factor of 1. An attacker willing to buy >1/2 of the votecoins in a branch can break the outcomes of that branch.

I don't see how this attack is a problem. Could you give more details?

Thank you very much for reading the essay and giving feedback.

I think that you should try to explain what it is about my proof that you don't find convincing, which leads you to reject it and attempt to construct a counterexample.

There are a couple problems with your proof:
1) you assume that only consensus mechanisms that produce coins are viable. If you are right, then bitcoin is on a path of death. Bitcoin is slowing down coin production by half every few years. If Satoshi consensus stops working at some point, then bitcoin might want to switch to Flying Fox consensus. It is optimized for a finite non-growing money supply.
2) you only consider consensus maintained by the destruction of resources that cost the same amount for both coin-holders, and people who don't own coins. like POW and liquidity and elections. There exists a resource that is affordable for coin-holders, and expensive for non-coin-holders. (the coins)

Here is a very simple counterexample: Every coin holder is forced to stay online 24/7. The portion of coins you have is how much control you have to add the next block.
There is no way to force the addition of blocks, or censor a block, unless you are part of a coalition of >51% of coin owners who wants the same thing.
None of the coins are "bonded". you can spend them to whoever you want during any block. We aren't losing value by the interest rate.

The cost of consensus is very low, practically zero, but the cost of owning coins is excessively high. Leaving a computer on 24/7 is unreasonable for most users.

how expensive will the crypto-monetary system be when it is the case that no new coins are created? In Bitcoin, it will be the sum of all transaction fees. Here, presumably it is the same, and the fees go to channel operators.

It is as expensive as the fees yes.
In Flying Fox, the rate of block creation isn't connected to time. It is connected to a certain volume of money. Every time >X coins are ready to be spent, the next block is ready to add to the chain. So the transaction fee is proportional to the amount of money spent.
In bitcoin there is a finite supply of 1 megabyte per 10 minutes, and a variable demand.
In Flying Fox the supply changes to meet demand.

Flying Fox has normal tx fees, the same as bitcoin. It has channel fees on lightning txs, just like the lightning network will on bitcoin. Unlike bitcoin, we don't have to pay miners to waste electricity constantly, instead we pay juries of random coin-holders to vote on the next block. So the block creation fee should be a lot lower, for the same level of security.

Ignoring all of that, the block-creator always gets to exclude transactions which he/she doesn't like. What is the "heaviest chain" rule for selecting a blockchain history, if you wake up and see two blockchains of length 100,000, which forked awhile ago (such that each chain had a group that attempted to prevent members of the rival group from opening channels)?

somewhere in between these 2 rules:
1) the chain that had the most money provably destroyed.
2) the chain that has the most participation from validators.

In Flying Fox it is not possible for the chain to fork the way you describe. If 2 groups of validators were very determined to disagree on a particular block, it is like an auction. Whichever side is willing to throw away more money wins. It is more affordable for the side that has more validating power. The price of "raising" is at least 50% more than the previous raise. So it is a discrete process with exactly one winner. Everyone who stays online 24/7 can be certain that they are on the same chain they started with.

An attacker, instead of buying up tons of miners and wasting electricity, would be buying up lots of coins and provably destroying them. Which makes the rest of the coins more valuable. Flying Fox has anti-fragility built in. Attacking it makes it stronger.

It is possible to get a bunch of old private keys, and start building a fork from an old block.
This result is identical to taking the source code and launching a new chain from genesis block.
You treat it the same as any other altcoin. You go onto coinmarketcap.com or some exchanges to look up the exchange rate.
Either 1) you only have coins on the original chain, or 2) you have coins on both chains, and can't tell which is the original.
Either case is fine.

It cannot be profitable to make a fork by paying the jury of validators to double sign at every height.
The jury loses a safety deposit that is twice as big as the amount of money spent in the block.
The random seed is from a very long time ago. You would need >50% of the money in the blockchain to sustain the attack long enough for the random seed on each side to be different.

It is looking great so far.
I am able to use hivemind-cli to check how many blocks I have, and my balance.

It say "out of sync".
How do I check if I downloaded blocks?
Here is my address if you have test coins: 1L1AsA9AFEGQmR5tDR1x36di7ZaVsJFmSJ

Awesome, thank you very much.

I can't find what you are talking about in the white paper, but I found this stuff Vitalik said and I am so relieved:

Now, there is another kind of counter-coordination that Vlad Zamfir figured out that does work. Essentially, first of all, instead of the naive Schellingcoin mechanism where winners get P and losers get 0, we add the anti-coordination game to at least the extent at which the mechanism always has an equal total revenue, ie. if there are k winners, winners get NP/k and losers get 0. Then, set up the contract C such that:

(i) to join C you need to put down a security deposit
(ii) after you join C, you need to provably vote with a 60% chance of Obama and a 40% chance of McCain (ie. use some common entropy to decide your vote with that probability distribution, eg. vote Obama iff sha3(block hash) % 10 < 6)
(iii) after you join C and get your reward if you vote Obama, you need to equally redistribute the reward that you get, as well as any bribes that you receive, among all participants in C
(iv) if you violate (ii) or (iii) you lose the deposit

The expected collective payoff, assuming everyone joins C, is going to be P * N + (P + ϵ) * N * 0.4 ~= P * N * 1.4. The incentive to join C is that you receive an expected payoff of 1.4 * P instead of P. Once you join, the security deposit bounds you to participate. The key trick here is that the contract allows the participants to provably share the rewards and collect the maximum possible benefit from the entire combined game. The mechanism doesn't inherit the problems of assurance contracts for public goods because you have the ability to exclude non-participants from sharing in the collective gain (namely, the attacker's attempted bribe).

Essentially, this is basically a way of using a version of my decentralized coordination contract from https://www.youtube.com/watch?v=S47iWiKKvLA&feature=youtu.be (52:27) against Andrew Miller's centralized coordination contract.

It is different from buying the coins, because the bribe only gets paid if the attack fails.
It is a conditional bribe.

Reward_______|LIE____|HONEST
attack fails____|1.51___|1.5
attack succeeds|1.5____|0

It needs to be impossible for the members of the oracle to prove how they voted, even after the votes are counted and the winnings are paid out. Otherwise an attacker could make a commitment to pay conditional on: the individual voting wrong, the the attack failing. It could even be from a different blockchain.

If it is possible to prove how you voted, then it is possible for someone to commit to give you money, once you create the proof in the future.
This is similar to voting in the United States. It needs to be impossible for citizens to prove how they voted. Otherwise their boss might say: "Show up tomorrow with proof that you voted for Trump, or you are fired."

If the members of the oracle are capable of cooperating to stop the conditional bribery attack, then that means they are capable of cooperating to break the results of the oracle to cheat in a big gambling market.

We need to put each member's votecoin balance into a zkSNARK. The SVD needs to be inside the zkSNARK.
I am worried that we might not be able to let the members of the oracle look at their own votecoin balance. I don't understand zkSNARKS well yet.

There exists a library for making zkSNARKS. This library is being used in the zerocoin project.
It is in C++, which I do not know. I am considering learning how to make an erlang wrapper for the library so that I can integrate it with Flying Fox.

https://github.com/scipr-lab/libsnark

I am studying the paper: https://eprint.iacr.org/2013/507.pdf

This doesn't work at all. The IRS would just look at the public blockchain and audit everyone who purchased insurance.

I am starting to read the Hawk paper.
https://eprint.iacr.org/2015/675.pdf
I think we might be able to put truthcoin oracles inside of this type of encrypted computation.

I am trying to think up an alternative to truthcoin oracles.
How about every time a bet expires, the blockchain forks into 3 possibilities.
If Hillary won the election, version 1 is valuable.
If Hillary lost the election, version 2 is valuable.
If the question is nonsense, then version 3 is valuable.

If publicly traded exchanges exist, you can look at the difference in price between the different coins to know which blockchain is correct.

As Vitalik explains on his blog: https://blog.ethereum.org/2016/01/15/privacy-on-the-blockchain/
"The requirement of trust on the participants is also an onerous one; note that, as is the case with many other applications, the participants have the ability to save the data and then collude to uncover at any future point in history. Additionally, it is impossible to tell that they have done this, and so it is impossible to incentivize the participants to maintain the system's privacy; for this reason, secure multi-party computation is arguably much more suited to private blockchains, where incentives can come from outside the protocol, than public chains."

Truthcoin oracles will not work. There is an attack that costs very little.
Bribe the oracle participants to lie. Commit to paying them dependent on the attack failing.
They will all lie for you, and you don't have to pay any of them.