My simulation says otherwise.  Simulating an 8TB attack on a 8PB storage (1%), I could get a quorum majority using a 1% attack with only 43.7 trials per participant.  For a 0.1% attack, I need 480 trials per resource.

To avoid this attack, you're going to have to make it so expensive to join that nobody will be able to afford it ;-)

This is not a normal binomial trial, but a process where the attacker chooses *where to withdraw* a participant.  You only control the random placement.

Besides, the whitepaper states that the fee will be returned for well-behaving participants, so the sybil attack is essentially free.  You might want to update that.


I don't see a description of how the quorum works for the tree.  What is described is a gossip protocol, but how will the tree reach *global* consensus on, say, the random generator?



How?  Can you spell out how the honest host will prove this?  I'm saying that an attacker that controls the quorum can redefine what users store so that any proof of storage can be trivially calculated.  For example the attacker simply defines that the users all store a long string of 0s.  Calculating any merkle-tree challenge is then trivial.

Just so I understand, you're doing merkle-tree proofs on the reed solomon parts?



Let me guess... if you still prove 64k blocks, then 700/16 = 44 levels of you have a 60bit addressable storage system (might be a bit excessive?).  If you have something like that, I don't see how that affect my comment.  I'm saying that if you prove 64k out of 8GB, then fetching that 64k must be 125.000 times as expensive as the reward for storing those 64k for the same amount of time.

Let's say a participant can choose to fetch the 64k from some other participant for cost 125.000, or store 64k*125.000 = 8GB for cost 125.000.

Let's assume a user is accessing random blocks, and churning through 8GB of storage once a month.  With a block frequencey of 1/day, there is a 3% chance that the user will fetch the 64k block that is being proven, and where accessing the block must cost > the cost of storing 8GB for the block interval.  So for a block interval of 1/day, the increased cost for this user is 3%/month.

(To offset this, I will do my own 31:30 reed salomon on top of your system so I can avoid touching the "poisoned block" during that day and avoid the cost)

But this assumes that you're only proving 64kB per day.  That's a pretty low figure. 


Sorry, *changing*.  Letting participants leave or join a quorum outside of the quorum protocol itself typically breaks the protocol.

Just read your whitepaper.  I am impressed by the guts, but not by your solution.

Maybe some of these issues have been discussed in this long, long thread, but:

- Your quorum is not a quorum when put in a tree!
-  Assuming that attackers are randomly distributed is nonsense (sorry).  The sybil attack is as old as time.
- Thus your binomal distribution calculations are simply wrong, because the assumptions are wrong (sybil attack).
- The whitepaper does not describe what the consensus tree looks like.  Judging from the calculations in section 10, it seems like it could be a binary tree.
- A honest party cannot prove dishonesty with a properly programmed attacker using a simulated storage and controlling the (attacked) random generator (section 10).
- The number of messages required to keep consensus is very high. 
- Did I mention sybil attacks?  There is no protection!
- Section 6, what the cost of fetching a block from another participant needs to be is completely wrong in the whitepaper.   It is off by 5 orders of magnitude! (by 100.000x!).  This p0wns the consensus protocol, or this will indeed be an incredibly expensive storage platform.
- You allow changing the voter set in the consensus protocol without having consensus it seems.
- The proof of storage algorithm is way too naive when much, better algorithms exist.
- Nothing in the protocol requires a node from EVER SERVING DATA!
- Who is going to "fine" misbehaving nodes?  The only thing you will see are invalid quorums where data is held hostage.

This is like a swiss cheese!  Who reviewed this?

On the ethical side, you need to look at the equilibrium between the cost of electricity and the value paid out to miners.

Let's use CPI, consumer price index as the unit.

If we assume for simplicity that mining power per CPI is flat over time (no new CPU tech), then mining equipment can be bought once and after some time it is the business of converting eletricity to coins.

Therefore it is an equilibrium between the value of electricity and what miners are paid.

In a society where the M1 money supply consists mostly of XMR, spending 1% on miners a year means that of the total money supply, the equivalent to 1% of that money supply is exchanged for electricity, and wasted.

This can be a significant part of the power produced in the world.  Therefore, the ethical solution is not to fix this as a percentage of the total money supply.

There is no logic to having a linear correlation between the value of the money supply and what miners are paid.  Having 100x as many miners does not make the system 100x as secure.  Having 2x the miners and spending 98x on developing mathematical proofs for the code base is probably a much better proposition.

The only sensible action is for miner profits to go down, in percentage of the total money supply, almost to zero.  This is based on the assuption that XMR increases in value.  There is simply no point in having 100k miners to secure the ledger.   That's like chasing insignificant risks when the big elephant in the room is the fact that the code base is written in C++ instead of Haskell.

Add bitcoin to the list.

It doesn't solve distributed consensus.

The equilibrium between energy use in mining and market cap means it cannot scale.  The only way the market cap can grow significantly is by having centralized miners that have access to private energy efficient mining technology, which makes the "distributed" part meaningless.

All in all, it's a total scam.

You should start with some control theory when adjusting difficulty.

I suggest looking at a Kalman filter first.  It is provably the optimum when the noise is random.  It is just a few multiplications and is easy to implement in a few lines of C.

But at a high level, don't try to write this in a small C function.  You have trillions of clock cycles between blocks, fork out some $$$ and write a decent high level implementation.

Why not add something like liboctave or R to the source code?  Then you could use ready-made implementations of these things.

In order to create a kalman filter, you need to create a model of how the dynamics of the system should behave.  If the goal of the control system is to keep the block output at a fixed rate, then the distance from that rate is the error you want to correct.

In addition to this error, you have a noise generator which represents your inability to control correctly.  The kalman filter will over time adjust and learn the standard deviation for the noise and thus apply the optimum error correction (adjustment to difficulty).

What you generally need to estimate is the correlation matrix between the variables in your model.

You want your underlying model to be as simple as possible, but also as correct as possible.  Some variables in a model could for example be:  the % increase in issued coins by a block, the difficulty, the difficulty error (difference from ideal inter-block time), the estimated hashing power of the network (which requires a separate model to estimate), the relative exchange value wrt bitcoin, etc.

You also need to estimate the correlation matrix between these variables, but this is mostly to make the filter more efficient.  You can set the correlations to 0 if you want.


A last point I want to make is that hard forks are not bad.  It has been shown again and again that bitcoin does not solve distributed consensus.  Both because the amount of computing power is unknown, and more politically because hashing power is already too concentrated.  Changing the algorithm on a deployed coin is something the users/developers of the coins control, not the miners, unlike what people tend to believe.  It doesn't matter how much hashing power an attacker has if he refuses to run the same algorithm as the users of a coin requires.

This coin looked really exciting, but after thinking about this for 5 minutes, I have some questions:

1. The VM is too low level, efficient algorithms cannot be used.

It seems that contracts will have to use a fixed number of instructions.  If a contract tries to use any randomized data structure or any structure that is not completely deterministic, then it is vulnerable to DoS.  Any contract that tries to keep some ethers stashed away in order to use algorithms that work well on average is vulnerable to DoS.

This indicates to me that the VM should be at a higher level where concepts such as collections of items, priority queues etc. are available.  The implementation can then use efficient data structures, making contracts more versatile and cheaper for everybody.

This doesn't just move the DoS problem to miners.  Miners can change the implementation of these data structures dynamically or at will.

This inefficiency means that a competing implementation of this idea will have better applications.


2. How are contracts updated when resource pricing changes?

When the developers choose to change the fees, how can contracts be updated?  If a business is started based on a given contract, and the developers change the base fee, the business might be killed.  This makes the setting of the base fee a highly controversial issue, potentially with lawsuits from businesses relying on this.

This is complicated by contracts carrying state.  An incumbent gets an advantage by knowing the current resource prices.

3. Extra pricing for reading foreign memory runs counter to a robust security architecture for contracts.

For complex services implemented as contracts, it would be desirable to isolate subcomponents or services as separate contracts.  The extra cost incurred by doing proper isolation of the memory space means that a competing service with a worse security architecture needs lower fees.  This is bad.

4. Is reliable time available to contracts?

Without reliable time, no specific time can be given for elections, which renders them useless.

Just noting that this now well known paper explains the exact attack I discussed here.

http://bitcoinmagazine.com/7953/selfish-mining-a-25-attack-against-the-bitcoin-network/?utm_source=twitterfeed&utm_medium=twitter

I don't understand your objection.  The coins that are valid on both sides of the fork have nothing to do with each other.  They have no effect on each other.  If you spend 10.000 ?TC of pre-forck ?TCs, it has no effect on your bitcoins.

What you describe is the reason for the eventually consistent chain.  What I am looking for is a reason for not temporary splitting the block chain.

I can see several seemingly profitable temporary attacks.  These are essentially variations of timing attacks on when and in what order to release information to the rest of the network.

Interesting point, and I agree with the wealth distribution argument.  However this can be fixed by not using SHA256 which is not designed to be a technology-neutral algorithm.

Regarding a crypto lottery, where is the collusion-proof cryptographic lottery that is immune to a sybil attack?

This all assumes that the optimal strategy is full propagation.  I fear that miners today already have incentives to prohibit propagation in order to induce the exact same conditions that happen during fast block creation.

This isn't really a big deal, but it doesn't give a predictive income for miners.  If the early Satoshi coins are recycled during one year, it will be an enormous boost for miners and then a gradual drop.  There is no reason to have such an irratic payback curve.  People would invest in rigs like crazy that year and throw the rigs in the garbage the next year.

Fixing the transaction issue can be done by either increasing the transaction costs, or as a general tax, called demurrage.  This depends on whether people think it is ok to have "freeloaders" own bitcoins without paying for the maintainance of the network, or not.

Isn't this more like an continuous integration test?

A solution to this is to apply control theory to the adjustment.

Of course, if you would otherwise use the excess heat produced by your rig, then the energy isn't wasted.   That might have been true for the last months, but not any longer 

But stop thinking about the hashing efficiency.  It has zero effect on the energy usage of the hashing fleet.  When someone finds a way to mine more efficiently, others are forced to do so as well to avoid earning less, but that's the point of this competition.  The energy usage is the number of BTC created per day * USDBTC.

The more general version of "asic-hostile" is minimizing barrier to entry in a market.

Minimizing the barrier to entry is a very good idea, because it increases competition.  If competition is important for the safety of the network, using a problem with the lowest barrier to entry is the best choice.

Low barrier to entry can be translated to "no need to invest in asics or any specialized equipment".

I don't think you should feel bad.  When bitcoin uses too much energy, a more energy efficient version like ppcoin will outcompete bitcoins.

You are helping advance technology and the energy issue will be solved.  It just might be that it won't be called bitcoin, but it will be crypto currency.

Just to give some context.  What scrypt tries to do is to implement a sequential memory-hard function.  The definition is:

a) can be computed by a memory-hard algorithm on a Random Access Machine in T(n) operations; and
b) cannot be computed on a Parallel Random Access Machine with S'(n) processors and S'(n) space in expected time T'(n) where S'(n)*T'(n) = O(T(n)^(2-x)) for any x>0.

where a memory-hard algorithm has the following properties:

A memory-hard algorithm on a Random Access Machine is an algorithm which uses S(n) space and T(n) operations, where S(n) ∈ Ω(T(n)^(1-eps))

From www.tarsnap.com/scrypt/scrypt.pdf

Yes I've read the paper.

Maybe you didn't understand the attack.  The attack is that the escrow service cooperates with a miner to destroy coin days.

In a Proof-of-Stake system similar to bitcoin, a large number of coins could lie dormant and accrue 'coin days'.   If these coins are in escrow, like on Mt.Gox, their 'coin days' could be used to do an attack on the network.

Thus any large escrow service would be a threat to the network, in addition to large miners.

Thus either escrow services must pay interest, or the need for escrow should be eliminated by a better block chain design and p2p exchanges.