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

First impressions of the paper: there are some good insights, and it's written well.

But... time stamps can be manipulated by dishonest actors (addressed in the CryptoNote whitepaper) and hence can not be trusted to prevent double spending. Which is one motivation behind Nakamoto's development of the Blockchain-by-Proof-of-Work solution to the Byzantine General problem.

Proof-of-work methods had been utilized before for various applications, most notably, to mitigate spam e-mail, but, Nakamoto was the first to solve the problem of coming to a concensus about order-of-events in a distributed, peer-to-peer way without timestamps. Even Nakamoto's solution is not a true solution, but simply a method that converges to a solution probabilistically over time. It's provable that a one-time, 2-General problem requires a countable number of verifications for a closed solution. The only other alternative Blockchain-by-Proof-of-X method that has been proposed since Nakamoto's solution has been Blockchain-by-Proof-of-Stake (and it's variant, the Blockchain-by-Proof-of-Stake-Velocity). Other Proof-of-X methods, such as Proof-of-Burn and Proof-of-Publication, have not been proposed to verify transactions, but to bootstrap value from one cryptocurrency to another and to verify the existence of a file by some point in time on the blockchain, respectively.  If either of these methods can be utilized to verify transactions, no method has been proposed to my knowledge.  

Recent rigorous security analyses of Blockchain-by-Proof-of-Stake methods are troubling: unless some Proof-of-Work component is included, a dedicated attacker can "kill" a coin with no cost http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2393940, but the attack requires a vast amount of capital, requires rational behavior on the part of a market (ha!), and requires the actor to enact a PR campaign trying to kill the coin. It's is unlikely to generate profit for the attacker (i.e. it's a strictly malicious attack). Notice, however, this may not apply to Blockchain-by-Proof-of-Stake-Velocity, I'm not sure. This core solution to generating an order of events without time stamps, the Blockchain-by-Proof-of-Work (BPOW) has essentially remained unchanged since it's original inception by Nakamoto. This is the primary strength of any cryptocurrency protocol. Variants in measuring the blockchain, such as following the heaviest subtree, not the longest chain, have been proposed, and are the best hope at improving that basic piece of the protocol. https://eprint.iacr.org/2013/881.pdf

Hey ad hominem bullshit flows out of your mouth. I can't compensate for your intellectual handicap.


Neither Gmaxwell nor DeathandTaxes have stated that my idea won't work. D&T hasn't even addressed my idea. Gmaxell stated that the existing strategy has the same problem with derivative unwinds as my strategy-- that is not the same as saying my idea won't work. But you aren't even able to comprehend.


And I've addressed all of your posts.


I've put that out there as an open question in my prior post and no one has credibly addressed it yet.

A lot of Anonymint's ideas (Aliasing) are analogies and technobabble, and really have nothing to do with Bitcoin or blockchain technology.

(He should really stop trying to impress everyone with big words and explain his ideas in plain English.)

Anyway, Anonymint, I don't think more devs need to see the proposal.  You've already got Gmaxwell and DeathandTaxes telling you it won't work, what more do you want?  I think I've also given some fairly clear arguments also.  The creativity is appreciated but there doesn't necessarily have to be a "solution" against a 51% attack, and it doesn't mean Bitcoin is toast.

51% attacks done for financial gain are prohibitively expensive and I doubt you can rent half the network power anyway.  Malicious sustained irrational 51% attacks are an extreme scenario that would need an extreme solution such as a fork to an alternative proof of work.

But you did get me thinking about timestamp block validation and whether we do or can limit unwinding of the block chain by a 51% attacker.

How likely is it that 50% of the hashrate will become rentable?

Edit: on the one hand no one should offer for rent that much hashrate because attackers could destroy the value of their hardware if they destroy Bitcoin in a Tragedy of the Commons (assuming no other SHA2 coins to mine at same profitability). But another Tragedy of the Commons is that ASICs owners don't each have 50% of the hashrate so they may not have a coordinated vision.

It also is part of the consensus mechanism and works beautifully due to it's simplicity.
Any added complexity to that rule needs to be considered very carefully and needs
to provably establish consensus as the longest chain rule does.

The hacker and the sustained hashrate are running parallel forks and copying each other's valid transactions whereas the latter continues to unwind the double-spends from the hacker's fork every time the hacker loses a block. The hacker can only defeat this by continuing to maintain > 50% of the hashrate indefinitely.

Nodes who come on to the scene after the fact have a problem of knowing which fork to trust. So if the hacker can maintain the attack for an extremely long duration (so that the majority of the sustained hashrate is from nodes who don't know which fork to trust), then my proposal fails (at least if I try to unwind to the original transaction instead of to the ether). But in that case there is no solution at all in any case (at-risk transaction would be delayed an extremely long duration) and Bitcoin is toast.

Maybe that is why I will decide it must be to the ether. Need to think more on this and would appreciate insight from other astute devs here.

However, that most of the hashrate is in a few pools makes this extremely difficult for the attacker. I tend to think even if mining were more decentralized than currently in Bitcoin, the hashrate will still be concentrated amongst long-lived nodes.

I did answer it. Think deeply.

The only purpose of the longest chain rule is to prevent double-spends, and it seems it continues to serve that function for as long as at-risk transactions wait for enough confirmations to make rentable computer power attacks impractical due to scale (?).

I offer a proposal to shift the cost of that wait to the time between transactions, which is an existing unutilized resource thus mitigating significantly the impact of this wait and also not requiring the user to do anything to institute the wait in many cases. In short, in my proposal the wait comes (in many cases) automatically and at no cost.


I have an idea for a solution to this problem but I am not revealing it now. Gmaxwell was on the correct direction with CoinJoin in terms of separating the anonymity from the linkability of the block chain, but DarkCoin shows that to implement it you end up with centralizing or Sybil attacked master nodes in order to holistically resolve the jammability problem of CoinJoin's two steps. Also the simultaneity requirement of CoinJoin is a problem.

As well my proposal revealed in this thread appears to be incompatible with unlinkable block chains, e.g. Monero/Cryptonote and Zerocash.

you didn't answer the first point I made, so I'm unconvinced.

Correct. The point is to stop the attacker who can't sustain that indefinitely. Eventually the majority sustained hashrate wins, because the attacker has an increasing rental cost over time to maintain the fixed amount of double-spends he earned.

Forget that— even ignoring the scaling they require the participants to be enumerated in advance.  Thats generally a non-starter to begin with for what Bitcoin attempts to achieve.

Hopefully you were just joking? Clearly that is 100% of the sustained hashrate that exists at any point in time, not 100% of the world's electricity production. And of course you don't need 100% of it, just 50+% (> 50%). I was just providing an estimate of the maximum cost to mount the attack, which turns out to be absurdly low.

Edit: The absurd nature of the attack is today probably 50% of the hashrate is not rentable (thus greater than 6 confirmations is probably not necessary now). But this could change over time if the trend is towards getting market prices for ASICs.

An absurd attack deserves an equally absurd defence:  we'll rent 101% of the world's electricity production so that your hashpower will hash in reverse!

I don't know if the hash rate solution to byzantine-generals is in fact the right solution.  In the presence of rentable computer power, it doesn't necessarily fulfil the assumptions that the security of the model is based on.

There are other solutions to byzantine-generals, but they require O(n^2) communication so they're even harder to scale to large numbers of users.

We have Eve, Sybil, and Trent to worry about. 

Eve is eavesdropping on the blockchain to discover where (what IP address) transactions originate.  In addition, she does blockchain analysis to identify actors and associate them with past transactions.  Generally, we tolerate Eve because we can't create a completely opaque Eve-proof system without creating a Trent. 

Sybil can create any number of wallets/accounts at any time, making voting mechanisms useless.  The hash rate consensus mechanism was supposed to counter Sybil, but in the presence of rentable hashing power, Sybil can (if she pays money) subvert this mechanism as well.  Sybil is endemic to anonymous trustless systems. 

Trent is the "trusted" authority - a centralized node whose defection is capable of making the system not work.  We have tried very hard to avoid creating a Trent.  The Zerocoin proposal's main problem is that it requires a Trent to set up the encryption parameters.  If Trent defects, there can be any amount of hidden coins in the blockchain and nobody will be able to show it.   Existing solutions to Sybil attacks require Trent to issue accounts linked to keys so that Sybil can't just make up as many new ones as she wants.   

Anyway:  No way to completely avoid Eve and Sybil without creating Trent.  No way to completely avoid Trent without tolerating Eve and Sybil. 

How do you which is "the next winning block" ?

If it is the very next block after a longest-chain-wins reorg, and the attacker
wins that block , the attacker could exclude it as well.

And if it doesn't have to be the very next block, then the attacker could work
the other side of the attack, create an orphan transaction on purpose and
spring it several blocks after a reorg, thus double spending that way.

EDIT:  Furthermore, even if an honest miner solves the "next winning block"
required to make the honest correction, what is to stop the 51% attacker
from undoing that block as well?  Where does it end?

Nope.

Yes I realize participants can choose their own number of confirmation according to their risk tolerance.
The issue still remains:  an attacker can double spend simply by building a longer chain
that doesn't include the transaction at all, effectively sending the coins back to himself.

Re-read my reply to drawingthesun.

100 confirmations isn't a problem? 

If Bitcoiners are going to wait that long,
you really don't need any special
"unwinding" in the protocol.
 
Miners can just refuse to accept
chains of 100 blocks or more.

In my proposal, if Charlie waits the 100 or so confirmations, he would not be in Block 3 and thus would not experience an unwind.

If in my proposal the sustained majority hashrate unwinds the double-spends to the ether, then both Bob & Charlie don't get 100 BTC from Alice. But Charlie should not have accepted the payment as final, because he has seen the orphaned chain and seen there is a double-spend that will be unwound.

If in my proposal the sustained majority hashrate unwind to the transactions in the orphaned chain, then Bob gets 100 BTC from Alice.

I don't see any problem.

Edit: apply the above to Bitcoin, then Bob's transactions are unwound when they are orphaned. Charlie's send to Alice would probably get propagated to the Chain #2.