Checkpoints are a temporary hack that will go away soon, we hope.

Sure I can, now that I'm at my computer instead of my phone

The miner needs to verify the entire block chain history because otherwise he has no way of knowing if he is actually on a valid chain or not. This has nothing to do with UTXO commitments, rolling root, or any other proposal. It's a basic, fundamental requirement of any consensus system: if the miners themselves operate in SPV mode (which you advocate), then anyone -- no matter their hashrate! -- can trick the network into mining an invalid chain. The attacker does so by mining a fork with invalid history and temporarily (by luck or 51%) overcoming the honest network. New miners coming online, or miners tricked into reseting their state then switch to the invalid chain This completely invalidates the SPV assumption and makes it unsafe for anybody to use the network.

"Rolling root" doesn't even make sense in the context of bitcoin, as has been explained multiple times by multiple people in your own thread. Let's not bring that discussion here. If your goal is to minimize the amount of data required to bring new non-mining nodes online, then that is what UTXO commitments does.

no it's worse than that -- you have to download and process every single block since Genesis. otherwise you may be on an invalid chain and not even know it.

You never ever under any circumstances want to be mining on top of a chain you have not validated the entire history of.

UTXO commitments have always required a soft-fork, whether they are added to the coinbase or separate commitment transactions.

What open data fields in transactions? Do you mean OP_RETURN? If so, see my pull request for a soft-fork change to enable this kind of miner commitments with compact proofs:

https://github.com/bitcoin/bitcoin/pull/3977

I would not put proof of stake anywhere near a consensus system. Not with current designs at least.

Here is something I just posted on a related pull request last night:

There are trustless escrows (c.f. the trustless flipped die protocol). Obviously even more is possible if you are talking about extending bitcoin.

o_O

As I said, protocol change required.

you are only reserving 4% for the founders and developers? are you sure that's going to be imenough incentives?

But the protocol layer can fix that. A block that is just header + coinbase + txid list would be pretty short.

You are talking about the payment protocol, right? That's ready for production, and is the right tool to use here.

He was asking about Zerocash. Zerocash has nothing to do with CoinJoin, and has it's own thread. I'd happy to discuss it there. In very short summary: Zerocash is not and never has been considered for inclusion on the bitcoin block chain. When the author references bitcoin he means the bitcoin protocol generally.

@Michael_S the point is that you multiple mixes, as well as opportunistic mixes each time you transact. Each mix increases the anonymity set. No one is claiming perfect anonymity a la Zerocash.

Size of the merkle hash tree proof is logarithmic not linear.

it is very important to point out that this is not a protocol rule it is just the user interface asking "are you sure you know what you are doing?"

The issues there are not block chain data size, but rather the network sync algorithm. The bitcoind code that is deployed right now uses a rather stupid algorithm for fetching blocks from peers that results in downloading the same block multiple times. There is a developer working on that right now. Block chain size is currently rate limited to about 1MB per 10 minutes, or about 13kbps. It is not at all clear that compressing this data will result in faster syncs, but if that is what interests you then by all means give it a shot.

Note that there is already a Script compressor which is used by the ultraprune code to greatly reduce the size of common bitcoin scriptPubKeys.

anti-scam: off-topic. please use the zerocash thread.

It's called a fail-safe design. Because typically when someone provides a >0.1btc transaction fee, it is because they forgot to include a change output, a very, very common mistake. People have lost lots of bitcoin (>200btc in a single transaction!) due to this mistake in earlier versions of bitcoind.

If you are not linking outputs to inputs in the submission (say, by signing the request containing the outputs with the keys of the inputs), then you are leaving the protocol vulnerable to very easy to execute denial of service attacks. If you do close that DoS hole by signing the outputs with the inputs, then the sever operator at the very least knows the linkages and could log this information.

The solution, as explained in the OP, is blinding: link the inputs to the blinded outputs, and later anonymously reveal the outputs and the unblinded signature from the server. Then the participants know that the output was one of the original blinded outputs (because the server signed it), but they don't know which one. Even in a two-party mix with a facilitating server, the server doesn't know which output belongs to whom. If there is a DoS withholding of a signature at the end, the honest participants can elect to back out and reveal their blinding factors, thereby demonstrating their own linkages and preventing themselves from being DoS banned.

BTW, blinding is super easy to do. Using RSA it like a half-dozen lines of code.


There is absolutely no reason to use fixed units. It adds no anonymity, and increases blockchain traffic.

The fact that wallets are sending round numbers is the flaw. That's what you should be working to fix, not making users transactions even more identifiable.