<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">-- about bitcoin/ledgers --</div><div class="gmail_quote">2015-04-16 13:54 GMT+09:00 Ryan Carboni <span dir="ltr"><<a href="mailto:ryacko@gmail.com" target="_blank">ryacko@gmail.com</a>></span>:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.</blockquote></div><br>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Detaching the ledger from a financial system seems more pure, but it is much harder to provide incentives for participants.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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). </div><div class="gmail_extra"><br></div><div class="gmail_extra">--- about Spinal Ledger (maybe suggest a less nerve-wrecking name?)</div><div class="gmail_extra"><br></div><div class="gmail_extra">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 <i>S</i> affects the time elapsed such that the rate is pleasing in some way (perhaps just time^2). Optionally, <i>S</i> 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).</div><div class="gmail_extra"><br></div><div class="gmail_extra">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)</div><div class="gmail_extra"><br></div><div class="gmail_extra">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".</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">There's probably some errors in this. Let me know! I'm just another idiot on the Internet. I can't bite you.</div></div>