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

Ray Dillinger bear at sonic.net
Fri Feb 23 23:02:25 EST 2018


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.

Moving on to something I CAN solve though:


I have a solid design for a type of block chain with the following
desirable property:

You can check the validity of any proposed transaction by downloading a
subset of the block chain rather than the whole thing.  You will need
something on the order of the fourth root of all blocks, per block that
a txIn being used in the transaction came from, to make sure that it
hasn't been spent since it was created.  And if the tx that created it
had multiple inputs, you will need something on the order of the fourth
root of all blocks *younger* than the block the tx is in, to find each
of those.  Etc.  Until you reach a known block at which a known txOut
set existed. (But building that known block/known txout set still
requires you to traverse the whole block chain up to that point. )

If you know the validity of the previous block, you can easily check the
validity of the current block, as with Bitcoin.  This structure would
have the additional property that in theory you can prove the validity
of the block without starting out knowing the validity of the previous
block and without needing to download the whole block chain.  In
practice, this depends on proving the validity of every transaction in
the block, probably recursively, so you might need to download most of
the chain if the sets of blocks you need to download for each
transaction don't overlap much.

I could even modify it such that miners could work on any of the next
few blocks simultaneously or post them out of sequence, further
splitting up the mining job for the sake of scalability, and it would
still work.  Hmm.  On reflection, the maximum number of blocks this
could be done with would be the fifth root of the current block chain
size. So, when the block height is 100,000, you could start working on
10 blocks at a time, and when the block height is 161,051, you could
start working on 11 blocks at a time.  This would extend the
confirmation depth, but if you really need to form blocks that fast it
wouldn't matter.


				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/20180223/55d3ca56/attachment.sig>


More information about the cryptography mailing list