[Cryptography] Spinal ledger - a finance-free decentralized global ledger?

Lodewijk andré de la porte l at odewijk.nl
Thu Apr 16 09:43:53 EDT 2015


A way of structuring hash-tree's into a proof-of-work global ledger with
very small participation costs, without connecting it explicitly to a
financial system.

I decided this stands a better chance of getting a serious response in a
separate e-mail. I would write this into a paper (better for discussing),
think about it more, let a few others read it selectively to check sanity,
etc, but I know I'll just put it on the TODO list and never ever get to it.
Sorry! I thought about it quite some, and just wrote it out now. I do not
at all guarantee it is any good.

-- about bitcoin/ledgers --
2015-04-16 13:54 GMT+09:00 Ryan Carboni <ryacko at gmail.com>:
>
> Personally, I'd rather spend 10% of GDP on ASICs as opposed to 10% of GDP
> on the financial sector, but that's just me.


Block rewards are going to get significantly smaller, and so will the
"mining sector". It is how it was planned. I think valuation is just way
higher then expected by the original designers, hence the massive costs.
Either that or the desire to not give early investors even more advantage.
Original coins for mining is a thing invented to solve distribution, too.

The selfish mining attack ignores network latency and conscious defense.
I'm far more worried about colluding pool operators. Yet, to rewrite a
significant portion of blockchain history is no small feat and will not go
unnoticed.

The trouble with ledgers is old and bitcoin is a practical if brutal way to
provide a predictable and high level of security. The primary thing it
defends against is double spending, and it does so very well.

Proof of stake is more obvious about it's defects, and vastly cheaper to
maintain. The defect being that the wealthy control the whole thing. The
counter argument is basically that if the wealthy make a mess of things
nobody would value the currency very highly. The problem is that the
wealthy are the ones that value everything, the poor are subject to their
valuations. The poor simply don't have the capital to affect the valuations.

Detaching the ledger from a financial system seems more pure, but it is
much harder to provide incentives for participants.

Bitcoin's 10-minute targeting makes sure that whichever chain is longer
will also have greater difficulty, or be invalid because it's latest blocks
are in the future. You can't make a longer chain with greater spacing (thus
lower difficulty).

--- about Spinal Ledger (maybe suggest a less nerve-wrecking name?)

We could make a system based on a hash-tree that has a "historic tree" and
"active tree(s)". The historic tree starts off with the "genesis hash", of
the lowest order. Any parent hash (that hashes leftChild, rightChild, a
timestamp and a nonce together) must have a higher order than either child
hash. Order should be defined as something like "amount of leading zeroes"
- S("time elapsed since previous hash"). Where *S* affects the time elapsed
such that the rate is pleasing in some way (perhaps just time^2).
Optionally, *S* can depend on the total hashes in the historic tree (to
"retarget"). The tree consists only of the longest hash-chain who's
childmost-node is the genesis hash and who's parentmost node's timestamp
still in the past (and that obeys the order-rule).

The active tree(s), meanwhile, follows no rules. Instead it is maintained
by those that wish to ledger some information, or whatever rules they come
up with. Those that wish to ledger information will want to merge their
tree into the "historic tree", for preservation. It is in these people's
best interest to find a good method of cooperating, as it reduces their
costs for merging into the historic tree. Once they do find such a hash
they'll spread it around and people will accept that hash to be the current
"topmost" hash. (note: an active tree doesn't require timestamps or nonces,
either)

As a convention, think that the genesis hash is the leftmost hash. Then,
every hash that puts an active tree into the historic tree will be called a
"spine hash". These spine hashes connect to one another, the left child
always a spine hash, and the parent always a spine hash. The right child
will be an active tree (messy, orderly, big, small, whatever). Together we
will call the spine hashes simply "the Spine".

A validating participant needs only remember the latest Spine hash. If I
come-a-knocking somewhere and want to show that I had ledger-ed some
information, I need to present those hashes that connect my information's
hash to the Spine. If the other person doesn't have the Spine, I can
provide the Spine too.

So: in order to prove that I have information in the ledger, I need those
hashes that connect my hash to the Spine. It is in the ledger-er's best
interest to remember the connecting hashes.

Sadly, this system is still proof of work. Therefore it is very much
possible some jarhead will ruin the fun by simply throwing more cash
against it. The Spine would fork. The security of your ledger-ed
information is equal to the cost of recreating the Spine from where your
information's hash' parents enter it.

Interestingly enough, selfish mining can only coerce people into joining a
specific active tree. And the more spine hashes stay hidden, the longer it
will take to enter the historic tree with your information. Not nearly as
much fun as with Bitcoin.

Note that this system does not work against double spending, as it includes
only hashes and more hashes. I can definitely prove that I received a
transaction at/before date X, but I cannot check if the transaction's
origin isn't already spent. Perhaps some further tech can make that happen.

Note that any active-tree-group can include it's previous active trees, in
their entirety, in their trees. And other groups' trees too. An arbitrary
addition is only a hash away. Of course, to prove that a hash is in such a
tree, one would need the whole branch, thus making it a bit unfun.


There's probably some errors in this. Let me know! I'm just another idiot
on the Internet. I can't bite you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150416/860ccc10/attachment.html>


More information about the cryptography mailing list