[Cryptography] Proof of Work is the worst way to do a BlockChain

[Natanael]

Den lör 24 feb. 2018 08:19Ray Dillinger <bear at sonic.net> skrev:

> If we want scalability, we need to have the miners able to form blocks
> rapidly when that's needed.  Let's say there's no one-per-ten-minutes
> regulation, and anybody can make a block at any time, whenever they can
> fill one up.  In that case we have to motivate them somehow to NOT make
> blocks for no reason or with no transactions or with meaningless
> transactions. So clearly it couldn't pay a regular block subsidy.
>
> It is really hard to come up with some means of coin creation that isn't
> easily cheated with meaningless transactions by miners who can form
> blocks whenever they want.  If anybody has ideas on that front, let's
> hear 'em.
>

I've already posted my idea to solve exactly this on the Bitcoin
development mailing list. (didn't get much response, though)

Scale difficulty with block size.

Making large blocks makes it more expensive to solve the proof of work.
This is only profitable if creating larger blocks for some reason is
profitable to you.

This requires somehow getting paid for making the blocks larger, typically
meaning that you are including fee paying transactions from *other* people
(fees may be paid via another channel). Bloating it with your own
transactions is then only an accounting trick that still lose you money
because of increased difficulty.

(This doesn't solve the superrational attack by a rich attacker, but
increases the cost.)

The subsidy per block wouldn't necessarily need to scale much. We're still
aiming for a consistent block rate, that now adjusts difficulty based on
both current average block sizes + block rate.

---

Also, my favorite solution for efficient large blocks since I first saw
somebody mention application of Zero-knowledge proofs to Bitcoin is proof
carrying blocks - while the raw blockchain is just as large as before,
regular users don't need to keep anything other than the headers - a simple
Merkle tree hash root with a Zero-knowledge proof of validity, and the
block hash (PoW hash).

All other data is referenced by that Merkle tree hash, and can be served /
fetched as necessary (such as payer -> payee) to show the exact contents.

Also this allows secure checkpointing such that all old still relevant data
(unspent outputs) can be frequently collected into a compressed block with
its own Zero-knowledge proof. This is a safe way to use a rolling
blockchain that in practice only grows approximately logarithmically with
usage, instead of superlinearly.

---

Another sidenote, nobody seems to have mentioned tech like Lightning
Network (LN) yet.

By using a combination of multisignature transactions, time expiration
scripts, notary/relay LN nodes and collateral provided by these nodes, as
well as transaction channels (a protocol for two parties to use a valid but
non-committed "transaction template" as a running tab for payments), it
creates a very robust system with strong theft and abuse resistance
properties.

It's a federated system like email, where instead of paying directly via
the blockchain, you use a node to coordinate a larger number of payments
that then gets routed across the network of relays. These then gets settled
periodically on the blockchain. This reduces the amount of traffic that the
miners need to handle.

---

As mentioned above, I'm a fan of Zero-knowledge proofs. My ideal
cryptocurrency system would essentially be a system that makes LN "native",
supports execution of complex scripts within this system, and which uses
Zero-knowledge proofs to create compressed blocks that represents the full
state of the system.

This would essentially be a stronger version of what Ethereum promises to
be. Programmable money, for real. You would have genuinely smart contracts
that can resolve in seconds. By having everybody provide well structured
data (signed by the respective publishers) into the system, everybody would
have the capabilities that currently only HFT traders and similar has,
where everybody can work with public API:s.

It would even allow you to enforce these complex contracts without
revealing their contents!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180405/bf409951/attachment.html>