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

[Ray Dillinger]

On 04/05/2018 04:26 AM, Natanael wrote:
> 
> Den lör 24 feb. 2018 08:19Ray Dillinger <bear at sonic.net

>     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. 

I'm listening....

Okay, you assume that this is still a chain where somebody is allowed to
form one block every ten minutes, but the block can be bigger or smaller
depending on demand for bandwidth.  And miners are still competing for a
chance to form the block because they get paid that way.

So the proof-of-work for a bigger block becomes harder - at some ratio
that makes bigger blocks more efficient than more blocks, for processing
the same number of transactions.  IOW, if someone can earn an extra 10%
(in subsidy plus transaction fees) for a block twice as big, we don't
want that twice-as-big block to be more than 10% harder to form, or else
it's to their advantage to work on small blocks rather than handle more
transactions per block.


So it sounds like we should be directly keying the difficulty premium
off tx fees instead of block size.  A percentage "premium" is added to
the difficulty based on the proportion of tx fees to block subsidy.
Spiking a block with a bogus transaction having extra tx fees would make
the block more difficult to solve, for no advantage.  Conversely, if
someone makes a horrible mistake and sends 1000 BTC in transaction fees,
it is significantly difficult to put that into a block and actually make
the block.

It makes decent sense if you still accept the ten minute block as the
basis of transaction processing. So it's still predicated on making the
bandwidth cost an inordinate amount per transaction compared to any
other form of transaction processing.  Which is certainly no worse than
Bitcoin is doing now, so strictly an improvement.


> 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). 

I don't think this is probably viable.  Without being able to see the
actual transactions, nobody other than the people actually making a
transaction can see whether it's valid because they won't know the
provenance of the coins.  Of course those spending the coins got and
added to the provenance when they got them, so it is possible for them
to do.  The issue is that it's not obviously possible for the full nodes
in the network to check.  Unable to tell the difference between a block
containing only valid transactions and a block containing one or more
invalid transactions, it is impossible to tell which of several proposed
extensions to the chain are valid.

And if we do it without creating a situation where people can make
deliberately bogus transactions in order to make subsequent bogus
transactions look legit, then proving the validity of every transaction
means disclosing the exhaustive transaction trail through which every
coin has come, all the way from their creation to the current spend.
The entire history of transactions still has to exist - it's just that
now it's part of the wallet rather than part of the block chain.  And it
has to be disseminated right along with every block, in order that
people can tell that the block is valid.

So while a Merkle root instead of the transactions would technically
shrink the block chain dramatically, it wouldn't shrink the bandwidth
required to form or check the chain by even a little bit.

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

I don't see how LN differs from reserve banking.  Payment channels just
create the near-necessity of consolidating the payment channels into
hubs around a set of entities whose main business that is.  This will
happen for convenience but more importantly because otherwise the
capital bound up in payment channels would be inefficiently deployed.
You want it at a hub so you can pay anybody, not tied up in some stupid
channel where you can only pay a particular person.  So these hub
entities will become economically dominant in the network. And aren't
those entities then taking the role of reserve banks?

So I don't really see much to talk about - they'll just be regulated as
reserve banks.

					Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180408/00a7e76d/attachment.sig>