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

Even if you unwind specific transactions without breaking the block headers, you still run into the issues DeathandTaxes mentioned earlier.  Namely, that having a certain number of confirmations won't mean what it used to.

It was there— only the enumerated edits were added which are below the proposed solution.

I imagine you may have limited time to digest a lengthy post, if on first glance you thought it was rehashing an old issue.


That specific threat was paramount in my mind as I was designing my proposal and I think I eliminated it.

The mining nodes reject any double-spend transaction which conflicts with the block chain. The only transactions that can be unwound are those which appear in a competing fork and only when that competing fork does not have enough sustained agreement. The premise is the attacker can't maintain 50+% of the hashrate indefinitely. Essentially what I am proposing is that orphaned chains are not forgotten by the sustained majority when the longer chain temporarily double-spends the orphaned chain, so the sustained majority (eventually) unwinds the temporary attack. The attack is differentiated from the majority because it is not sustained indefinitely. Abstractly I am proposing a smoothing filter on Proof-of-work longest chain rule. The ephemeral attacker is aliasing error.

And I think (perhaps) they can be unwound to eliminate the double-spend, rather than to the ether.

I don't believe your post contained a "proposed solution" when I initially responded, if it did— I missed it.

But it's not a solution, alas. Ignoring other issues, at best it still leaves it at a simple piece of extortion "return most of the funds to me or I will reliably destroy your payment". It that sense pretty much isomorphic to "replace by fee scorched earth". The ongoing effort has other problems— a txout can be spent again immediately in the same block. Imagine it takes months to get the fraud notice out (heck, imagine a malicious miner creating one and intentionally withholding it).  By that time perhaps virtually all coins in active circulation are deprived from the conflicted coins. Now they finally get the notice out (/finally stop hiding it). What do you do?  Nothing? Invalidate _everyone's_ coins? Partially invalidate everyone's coins?  Each option is horrible. Do nothing makes the 'fix' ineffective in all cases: the attacker just always sends the coins to themselves in the same block, the others make the failure propagate— potentially forever, and don't just hit the unlucky merchant with the potentially unwise policy.

(It should be noted that already systems reject from their mempool discard later double-spend transactions from their local perspective, because— duh)

Many places, I'll pick an example from myself— (note the log I reference there 12:37 < gmaxwell> pirateat40: you can have 10% of the hash power and attack.)

I am aware of Meni Rosenfeld's white paper which calculates the probability of winning n blocks with LESS than 50% of the hashrate. But that is an orthogonal issue to one which I raise of sustaining an attack with MORE than 50% (see I wrote "50+%") of the hash power. I propose to defeat the attacker who can't sustain 50+% of the hashrate (up to) indefinitely.

Where was the following discussed before and where was my solution proposed before?

Huh, the fact that someone with <<50% hashpower can successfully double spend has been repeated many many times on this forum, by dozens of people (including myself), along with comments that mining pools or (especially) vertically integrated closed mining operations with double digit percentages of the hashrate are all concerning, even if its not near 50%. The original Bitcoin whitepaper gives the formal for calculating the success rates.

The most important point made in the paper is that an adversary potentially doesn't need to own 50+% of the network hashrate. Rather if sufficient hashrate can be rented then the adversary only needs to double-spend over a small window of time an amount that is more than the mining rental cost, which potentially makes the 50+% double-spend attack much more accessible given that at 25 BTC per block then a 6-confirmation rental cost should be in the range of only 150 BTC.

Another point made is that the double-spends could be spread out over smaller transactions, so large transaction fingerprinting can't be a solution. The point is also that waiting for 6-confirmations doesn't necessary give a high probability of protection against a double-spend (although the attacker wouldn't likely be able to monetize on sufficient scale some types of transactions, e.g. purchasing toddler shoes from a merchant).

The attack works by spending on the public chain fork and simultaneously employing the rented mining hardware to create a secret chain fork which omits or double-spends those spends. Then after the spends have received enough confirmations on the public fork, then publish the secret fork which has a longer block length which orphans the fork with the originating spends.

Proposed Solution

I hereby write down a rough sketch for an idea of a decentralized solution which is based on the attacker not being able to afford to sustain the high hashrate. I don't know if there is a prior art or discussion of this or a similar idea?

a. If a mining node receives a request to add a transaction which double-spends a prior seen transaction, the request is discarded.

b. If a mining node is attempting to add a transaction to the next block it will win and the received winning block double-spends the former, the former is discarded.

c. If a mining node is in possession of an orphaned block chain which contains transactions that are missing or double-spent in a received longer block chain, the mining node broadcasts this fact and all mining nodes which agree (i.e. had seen this fork before it was orphaned) are expected to add this fact to the next winning block which thus marks any double-spent coins as forfeited to the ether (or adds the spends that were omitted).

This accomplishes the following.

1. The more confirmations a merchant waits for, the less probable the typical spender could (after receiving what was paid for) propagate a double-spend to spite the merchant. Todo: quantify the probability.

2. The mining nodes in agreement would continue forever trying to add this forfeiture evidence to the attacker's fork after it is public. Only if they have a minority of the hashrate would they fail. Thus the attacker would need to maintain his 50+% advantage forever (or for a long enough time until those mining nodes in agreement became a minority which could be a significant period of time).

Any holes in my logic?

One issue is honest mining nodes are punished by attacker for as long as the adversary can sustain the 50+% hashrate, the honest miners lose their mining rewards. But they are going to be losing them without my idea if this attack becomes viable. If the attack becomes viable, the network would constantly be under attack (attackers wouldn't hold back to preserve Bitcoin market price due to their competing with each other in a Tragedy of the Commons) and all honest blocks would be orphaned.

(note I only invested roughly an hour into this idea, so I might have missed something obvious)

Edit: this rented 50+% attack is a Tragedy of the Commons, because the attackers would compete to drive rental costs higher and higher, crowding out honest miners. This is potentially a very dangerous risk as more and more mining hardware is put out for rent to obtain market prices. Note this becomes more likely as the trading volume in the exchanges become more liquid as a crypto-currency matures.

Edit#2: note the proposed solution doesn't deal with the issue of during network fragmentation where there are isolated public forks then the spender could issue a double-spend on each fork, because block chain fragmentation is an orthogonal problem (which I think currently has no known solution?).

Edit#3: the attacker must double-spend and not just omit the prior spends in the longer block chain, otherwise the other nodes will remember those spends and re-add them to the longer block chain after it is public.

Edit#4: the only reason I have thought of for not modifying the proposal to reinstate the originating spends instead of declaring the double-spent coins forfeited to the ether, is if the typical spender can somehow spend to himself first then to merchant secondly. Todo: analyze this along with quantifying the probability in #1 above.

Nice paper   It is indeed a complex ecosystem of competing currencies we find ourselves in. 

couple comments:

"Sudden jumps and rapid phase transitions are programmed at xed dates in time and are likely to ruin the life of these currencies"

Participants know in advance about the sudden jumps and value hashpower and currencies accordingly far in advance.  See 1st bitcoin halving.  Will people prefer this to the nondisclosed jumps/transitions in supply and mining rates we have seen in fiat or even gold? 

"We discovered that neither Satoshi nor bitcoin developers have EVER mandated any sort of transaction timestamp in bitcoin software."

I disagree.  Block height is one of the best timestamp mechanisms ever developed.  Second, more conventional dates ARE in the software as they are required to set difficulty properly.  In some commmodities there is not even a public record let alone a great timestamping system.   

"In this paper we show that most crypto curren-cies simply do NOT have ANY protection against double spending."

Participants all know and understand the possibility of a longer-chain or 51% attack and its cost.  We wait for the appropriate number of blocks (confirmations) until we know a double spend effort on a payment we are accepting would be a total loss for the payer.  Pretty good protection against double spend IMHO, especially compared to fiat            

This is work in progress. Thank you all for extremely valuable comments.
The most up to date version of this paper is available at:
http://arxiv.org/abs/1405.0534

It would also make confirmations horribly insecure as you would be reporting confirmation on a minor chain where you may be double spent in the main chain.  Worse it hides this fact from the user by ignoring the main chain because it contains tx "too close together".  It won't be deterministic between nodes until 6 confirmations which makes troubleshooting and analysis far more confusing for users.  Essentially not only are 0-confirm transactions now risk, 1 to 5 confirms are also highly risky too.  6 confirms becomes the new 1 confirm so the "clearing time" goes from 10 minutes to an hou.  

Miners are highly pragmatic they will build off the longest chain as it has the most chance of remaining the longest chain. You can suggest miners not build off the longest chain but unless a super majority of them follow that they simply lose money by doing so, which means they wont.   It is a modified prisoners dilemma where in almost all scenarios breaking from the longest chain is the worse choice.

The post I linked to does not claim to invent a way to fully order all transactions.  It only proposes that nodes (the important ones being miners) reject (not build on top of) blocks that contain transactions that are not only double-spends --  but 20-second-late double-spends (the exact threshold would be determined later).

If they go ahead and build on top of such a block anyway, they risk the rest of the network (miners again) ignoring any block they find.

This would not make all 0-conf transactions safe.  But it could make them a lot safer than today, if a seller waited for example 20 seconds before completing a real-world transaction.

The safest path for a miner would be to NOT mine double spends.  Which of course is the point.  The only risk to a miner who adoped that strategy would be somehow missing a first-spend.

"I found a way to solve the BGP without solving the BGP" is going to be the next generation's perpetual motion hoax.

All those people who make YouTube videos where claim to run a portable generator to electrolyze water which they use to power the generator engine? Soon they'll all switch to inventing new scamcoins.

If you could trust nodes voting you wouldn't need mining to begin with.  There is no guarantee that all nodes know about all transaction at any point in time.  There is no guarantee nodes will learn of transactions with any guarantee on timeliness or nodes will learn of transactions in the same order.   The composition of the network is also continually changing

The network isn't a single unified block of memory it is a coalition of independent systems.   If we could trust anonymous decentralized nodes to "vote" in a secure manner they could simply agree on the ordering of transactions amongst themselves and you wouldn't need blocks and you certainly wouldn't need a proof of work.   The unresolved problem is preventing a sybil attack.  Satoshi saw that in a pseudonymous decentralized network, where an attacker could cheaply create thousands or even hundreds of thousands of nodes, that no vote based on 1 node = 1 vote could be trusted.  The proof of work is a mechanics to force a consensus among nodes which may conflicted views on the ordering of transactions.  Proof of work creates a canonical ordering of transactions and all nodes update their internal ordering to match that.  If nodes could reject blocks based on "incorrect" ordering then it would imply they already know the canonical ordering.  If they know that, they you don't need mining to begin with.

Hand-waving distributed timestamps into existence can't be confused with this idea

 https://bitcointalksearch.org/topic/m.48484

which relies only on nodes' local clocks, and then only on their keeping accurate time over the short term; they don't have to be military-atomic-clock accurate and it doesn't matter what time zone they are in.  Instead of trying to create a distributed time protocol, the existing consensus mechanism is used with nodes simply voting to reject blocks containing double-spends they detect themselves.  They actually already make this decision ... they just don't tell anyone.

Okay, you're getting the problem set up wrong.  As long as bitcoin is dominant, it doesn't lose fully half of its hashing power when it halves its reward. 

Let's say that there is some unit of hashing power that pays 10$ per hour.

If equilibrium has 90% of the effort on BTC at a given moment and 10% on altcoins, then we can conclude that the value of BTC produced by that hashing, per hour, is worth $9 and the value of altcoins produced by that hashing, per hour, is $1. 

Now if BTC cuts its reward by half, suddenly it's producing only $4.50 worth of value per hour for that amount of hashing power.  The total value being produced by that hash power - the new equilibrium rate - is now $5.50 per hour.

Bitcoin at its halved speed produces that value when it gets 9/11 of that amount of that hashing power and the alts, at the same speed as before, produce that value when they get 2/11 of that hashing power.  This is the new point at which the ratio of hashing power to value produced is equal for bitcoin and the alts.

What happens is that the amount of hashing power devoted to the alts nearly doubles, and the reallocation comes out of the amount devoted to bitcoin. 

When he uses UNO as an example, UNO halving its reward has effectively no impact on the rate of value production, so the equilibrium rate is relatively unaffected.  That makes it very simple; At the same rate, half the value produced buys half the hash power. 

Should be fun to watch.

1.  Reward halves.
2.  Half the hashers depart.
3.  Reward per hash on bitcoin network doesn't change.
4.  No change in profit for the half that stay!  (Increase, really, if you count fees).

I wonder how the 50% who leave will make that decision.

Which is dubious in itself but lets assume the network is 450 PH/s the day before the halving and after the halving 50% of miners leave for this non-existent altcoin which is still more profitable than Bitcoin even with the difficulty that comes from 225 PH/s.

Ok so Bitcoin has 225 PH/s worth of miners.
CoinX has 225 PH/s worth of miners.

How exactly is it now trivial to 51% the Bitcoin network?

Yeah you can and with any realistic guesstimates you don't reach the conclusion the author reached.

I don't think anyone is really going to argue that a smoother shift in the block reward would be less preferable than one which halves instantly after a long period of time, but that's just the way Bitcoin is and there are altcoins designed to remedy that issue (I'm guessing that's the issue being discussed, like I said I didn't read the paper properly).

I knew that had to be the case, I thought I was going crazy there for a moment, thanks for clearing that up.

You're probably right about that; it would destroy the value of the sunk-costs in ASICs for starters, which means the miners would scream bloody murder.

His "speculation" is that at least half of miners are willing to switch to mining a different coin if it's more profitable.  The rest is just a math problem about how to optimize profits.  I don't think that's at all in question.

Seriously, you can set this up as an equation.

No he isn't or at least not his conclusions on what "will" happen are just speculation.

The author claims that when the block reward is halved that hashrate will be halved.  That is probably not true unless the operating margin on EXISTING hardware is <0 (or another coin is more profitable) after the halving.  For a user with a 0.5 J/GH rig and $0.10 per kWh electrical rates the 0 operating margin point is ~1 PH per $1 in USD exchange rate.  So at the current exchange rate the network would need to be >450 PH/s for that miner to have a negative operating margin.  The exchange rate would hopefully be higher by 2016.  At the ATM it would require 1,200 PH/s.

The block halving will probably dry up sales of new mining hardware (actually they will dry up months prior in anticipating of the drop) but for a miner who already owns SHA-256 hashing power he essentially has three options

a) continue to mine bitcoin for half the revenue
b) sell the hardware to a miner with lower costs (namely cheaper/free electricity and cool climate)
c) mine an altcoin.

The author jumps right to c.  To date (other than brief periods of pump & dump) no sha256 coin has been more profitable than bitcoin to mine.  The author predicts the hashrate will fall by 50% which would assume that no miners opt for "a" or "b".  Still even if that is true there is no certainty that a halving in hashrate will make Bitcoin vulnerable to a 51% attack.  The hashrate today is 70 PH/s.  For the halving to make the operating margin negative would require a hashrate of 450 PH/s (current exchange rate, $0.10 per kWh, 0.5 J/GH).

So say in 2016 that does happen.  The hashrate drops from 450 PH/s to 225 PH/s which is more than 3x the current hashrate.  The Bitcoin network still has ~50% of the hashrate of known miners.  The idea that it is suddenly trivial to perform a 51% attack is an unsupported conclusion.


Which has nothing to do with the Bitcoin protocol.  The Bitcoin protocol does include information on the prior block in the blockheader.  Some pools use a protocol which ommits that however it is possible for miners in pools to be in control of the blockheader.   Pool mining is a protocol that is built on top of the bitcoin protocol, it isn't part of the bitcoin protocol.  It would be like saying if you made some changes to anti-counterfeiting features on the dollar bill you could reduce credit card fraud.  The credit card network is an independent network built on top of the cash network.


The bitcoin protocol reward is not going to be changed.  Period.  It would be a breaking fork and you will never achieve a super majority to support any fork.  There are already methods which allow a miner to be in control of the blockheader and miners frankly don't really give a crap.  You can't force them.  It is more a social problem then a technological one.