Topic: On The Longest Chain Rule and Programmed Self-Destruction of Crypto Currencies - page 5. (Read 17957 times)

Look, he made one mistake; we don't have a practical distributed timestamp protocol, so his proposed solution to that one problem doesn't work.

But he's right about there being a security improvement if miners have to know what they're mining on. 

He's also right about the effects of block reward halving on hash power allocation. 

Those are real problems with viable solutions, and we can fix them, so why is everybody focusing on the one thing he got wrong?

Anyone having any significant degree of knowledge in Network Protocols will say that timestamping between trustless nodes is a really bad idea...
The guy who wrote this is definitely not scholar, many words used are **Breaking** category.

Why Satoshi did not use timestamps? Because they are easily faked and there is no way to check them, merkle tree - not so.


While I agree on the mining dependency, the article does not provide any solution to problem.
One solution is per hash merkle trees (so multiple blockchains for each) - and removing the mining replacing it with accounting hubs.

I received this paper earlier today in a Google Scholar Alert. I couldn't spend more than 5 minutes reading it... so many misconceptions and holes in their knowledge of Bitcoin. It's got some interesting graphs though.

Well, I read nearly all of the 46 pages (as much as I could) and I can summarize it in a single sentence:


If the profitability of mining BTC falls (due to a decreasing block reward) low enough such that a competitive currency becomes more profitable to mine, the hash rate will plummet and present an opportunity for a 51% attack.


In my view, this scenario is possible (any scenario is possible), but it is extremely unlikely because of the economics. Furthermore, if it does happen, then the other currency is probably preferred over bitcoin anyway and a switch to the other currency would be a positive result.

The trustless trust is a logical fallacy

I know Nicolas Courtois and had I not seen the paper linked from his web page I would have assumed that someone had just added his name to this rubbish in order to give it some gravitas.

He should have given his old supervisor a red pen (with plenty of ink left ) and asked him to review the paper first. There are portions which are OK but he's certainly gone a long way down in my estimation.

Bytecoin

Steve Martin once lectured on "How to Be a Millionaire and Not Pay Taxes":

"...First, get a million dollars. ..."

Oh, right. There are so many terrible papers floating around it's getting hard to keep track of them all.

No, he had another paper where he 'invented' a number of long used mining optimizations like elimiating the final three rounds, mining from a midstate, and merging adder carries, and then spent the last half ranting about how the geometric subsidy decline doomed Bitcoin to failure with strange all-caps bold words mixed in, and saying that we must adopt his proposal to adjust the subsidy every 600 blocks, while simultaneously ignoring that we made it through one subsidy halving without incident.  On the basis of the prior paper and some comments from people who's opinions I trust who read this one, I've pretty much given this one a pass myself.

His work on the mining optimization stuff, though— I recall it being largely redundant with work already deployed out there— was not unintelligent. The conclusions he was drawing—  well, I think everyone who wanders into Bitcoin experiences at least 20 instances of "Ah ha! it cannot work, I've found the flaw!", some of us just go through it a little more privately than others.

Rather than focusing on what the paper has wrong, it might be more useful to ask what it got right or what interesting questions it poses. Even a completely confused paper can sometimes inspire some interesting questions or approaches. I understand that it makes some pretty concrete fairly near term predictions about dogecoin which will be falsifiable, — and hey, making a falsifiable prediction would put it ahead of a lot of things.

You have to keep in mind that publications (esp pre-prints) are just another communications channel for people. By themselves they don't automatically mean the work is of cosmic importance or even that its intended to be. So if it helps you extract something useful from it you can think of it as a expanded forum post. One virtue of that form is that often forum posts are so incomplete that it's hard to even tell if you can tell what there idea is from the post.  In this case, where the author seems to have some misunderstandings about the non-existence of globally consistent time in a decentralized system, and he failed to actually describe his solution— well at least you could tell what was missing.  Don't let the bombastic language get to you, it's a cultural norm in some places to make every thought sound like some major revelation. Annoying at times, but you do yourself a disservice if you can't learn to ignore it and sieve out the good ideas that might be hiding behind the noise.

The name sounds strangely familiar. Isn't this the same guy who came up with the "selfish mining" nonsense a while ago?

The author is wrong about the proposed timestamp solution, because we don't really have a practical distributed-timestamp scheme.  But there may be a simpler one (not requiring a distributed timestamp) that works.  I'll have to think about it, but it's certainly in the best interests of honest miners and honest transaction makers to provide accurate timestamps if it improves security against dishonest ones, so it isn't hopeless.

The author is right about increasing the security of mining by requiring miners to know both the hash of the current block and the hash of the previous block - the hashing operation they need to do is essentially the same, and making sure miners know what block they're building on would make certain classes of attack (diverting pool miners to another coin, using pool miners to build an unpublished blockchain, etc) which are currently easy to make undetectably, leave incontrovertible evidence.  That is a good idea and we should do it.

It's true that we don't know how to implement some of the author's proposed solutions, but he has a pretty good grasp of some very serious problems.

In particular, he has a good point about what happens when block rewards are multiplied by half.

There's an investment (in ASIC mining equipment) constantly seeking its most profitable allocation.  That allocation is an equilibrium in which each option pays identically.   

At the point where there's a block reward halving, one of the allocation options has its return cut in half, and the equilibrium has to find a new balance point.

If you're UNO, and you cut your block reward in half, the total rate of return is hardly affected at all because you represent such a tiny fraction of the total available income.  The allocation of that investment to mining your blockchain, though, gets cut approximately in half, because that's the point at which the return for mining it remains competitive.

If you're BTC, and you cut your block reward in half, the total rate of return is cut by almost half.  Suddenly, every *other* allocation opportunity is suddenly worth twice as much of the miner's remaining hash power investment as it was before, because that's the rate at which the return for mining it stays competitive with BTC.

Of course, the latter doesn't account for mining rigs that are no longer profitable to run at all.... 

Got it. 

I need to be excused now.  My brain is full.

Correct.  All blocks contain a timestamp, all blocks timestamps are validated by all nodes to ensure they are within an acceptable window.  This is done to "keep miners honest".  Without it miners could use false timestamps to manipulate the 2016 block timespan, lower difficulty, and boost their profits. 

That validation in theory could be exploited to isolate and double spend a node.  The article describes how that attack could be executed.

So they stamp all the blocks which could sort of be exploited for double spends but not really and then the stamp is used for the diff change.

I assume you mean isn't?

The article explains the attack in pretty simple language.  The attacker isolates the node and feeds it incorrect timestamps.  This causes the computed network time on the victim's node to be SLOWER than the rest of the network.  The attacker then creates a block with an incorrect timestamp that is faster than the correct time.  For most of the network although the timestamp is wrong it is still within the validation window and the block is accepted.  The victim's clock however has been slowed down enough that the block is outside the validation window and the block is rejected.

The victim has now been forked off the main network and can be fed false information and double spent at will.

The timestamps validation of blocks is only used to prevent manipulation of difficulty but the fact that nodes validate timestamps is exploited to isolate and attack the node.  In reality this attack would be rather difficult to pull off, is expensive as it requires mining full strength blocks which will be orphaned by the main network, and there are some pretty cheap and easy countermeasures. 


Essentially the target's proper checking of timestamps (to prevent manipulation of difficulty) is used against the target by careful manipulation of timestamps.  I don't believe this is a very effective attack in the real world for a couple of reasons.

Sorry but I am missing something here.

Why is there a possible attack vector if the protocol
is using the time stamps for anything other than
difficulty adjustments? (Using them to validate blocks)

 

The article is saying block timestamps are used to prevent double spends, it is showing how block timestamps can be manipulated to exploit the fact that nodes will validate the timestamp and use that to isolate nodes .   The timestamps are only validated to ensure difficulty can't be gamed.   No other function of the bitcoin protocol relies upon them.  To prevent difficulty from being gamed requires invalidating blocks outside of an acceptable range.  The article is pointing out that the validation of timestamps can be an attack vector for double spends.  The attack vector wouldn't exist if the network didn't validate block timestamps.  Of course if there were no validation of timestamps then there would be no secure provable way of setting difficulty.  It is a catch-22.  The article recommends reducing the window for validating blocks to make this attack more difficult (an attack which has been successfully executed).

Satoshi understood that timestamps are very difficult to authenticate as such limited them to areas where there is no solution which doesn't involve timestamps.

No, I agree we need time stamps for the difficulty change.
However, the article isn't talking about that. 

.

Basically it is talking about double spends, etc. 

I know one shouldn't judge a book by its cover... but just glancing at the abstract one can tell that this isn't serious scholarly work.