|
I may be wrong, but i think that the best solution would be to implement @kjj's idea with difficulty automatically increasing exponentially if block chain fork is longer than Y blocks.
This is still pure Proof Of Work, not really cementing. It would simply require much more than 51% to fork blockchain after Y number of blocks.
|
|
|
|
Yeah, a fail article. The anti-bitcoin propaganda is coming.
Deliberate or stupid? Perhaps both |
|
|
|
Erm, don't take this the wrong way, but this seems like a strawman to me. If an attacker has you isolated, they can already feed you bogus blocks, and there isn't a damn thing you can do about it. In a parity proof-of-work system, when the isolation is broken, your node will resync with the rest of the world. But the damage (to you) has already been done, it was done when you accepted blocks that you thought were current, but really weren't. Throwing them out and loading the correct blocks doesn't fix anything, and might actually make it harder for you to realize what happened. This is the trade in reality. You get: your node can fix itself when reconnected to the global network. You pay: The entire global network is vulnerable to hidden chains, whatever damage you suffered while disconnected is unchanged, you don't necessarily know that you were attacked. Seems like a terrible trade to me. Seriously though, I don't disagree but moving away from pure PoW is a fundamental design change and we need to consider it carefully to keep disruption and unwanted side-effects at an absolute minimum. If nodes aren't safe when participating in the network then the network is meaningless.
And as mentioned, if we consider majority attack to be plausible we need to protect against rejection attacks, not just double-spending.
The best part of my proposal is that it doesn't change the network rules at all. It is still pure proof of work. The only change is that the burden of proof for a reorganization is higher than it is now, and it scales with the amount of danger than such a reorganization represents. This is not how things work. Let me tell you how you should do it, it you ever want something done (as with my fork I have already learned the hard way how things work in the world). Nobody will do anything for you (for free). If you ever want to get stuff done, you must work hard, do it and code it yourself, test it thoroughly and only then - when you are 100% sure that it works correctly, you can try to convince people to merge it to the client. |
|
|
|
Suppose you're a new node joining the network. Of course you are not cemented on anything. You see some nodes broadcasting a short chain and some an incompatible, longer chain. Who do you believe? If you default to the longer chain, you could fall right into the majority attacker's net. If you use something else you make it easier to carry out an attack without majority hashrate.
How is this different when using cementing ? I mean clients already take longest chain when offered multiple chains or different length. No change here. (Unless you were talking about the majority rule, not cementing itself) Without cementing, new nodes use the longest branch, as do all other nodes. In case there's a majority attacker, he can make attacks but at least the nodes are consistent with each other. With cementing, if a certain attack is executed, new nodes will be detached from the rest of the network (e.g., the veteran network is cemented on a shorter branch, but the new node will join the attacker's longer branch). At the very least it shows that cementing doesn't make the network (where "the network" includes the ability of nodes to join it) immune to such attacks. Wow, I didn't think about that. Thanks for clearing this up, @Meni. This is a very good discussion we are having, i wish I did that more often. |
|
|
|
I more-or-less agree with with the rest of your post, this is the part i have doubts about: Suppose you're a new node joining the network. Of course you are not cemented on anything. You see some nodes broadcasting a short chain and some an incompatible, longer chain. Who do you believe? If you default to the longer chain, you could fall right into the majority attacker's net. If you use something else you make it easier to carry out an attack without majority hashrate.
How is this different when using cementing ? I mean clients already take longest chain when offered multiple chains or different length. No change here. (Unless you were talking about the majority rule, not cementing itself) |
|
|
|
. . . So the only time a block reorg longer than 10 blocks will ever happen is because an advanced double spending attack.
Logically, implementing cementing after Y blocks (where Y = relatively big number, like 15, 20 or 50) should be an absolutely viable solution to our problems . . .
Doesn't this already occur on an ad-hoc basis when new versions of the client are released through the process of creating a "checkpoint"? Exactly. This already happens, but only once every few months. So why not make it more often if there are no known drawbacks ? Simple solutions are not always bad. |
|
|
|
How exactly ?
By running multiple nodes spanned over various IP addresses, of course. Yes, but in no way will this be easy to do. It would require simultaneously VERY significant resources in multiple countries around the world AND >51% Hashing power, AND few million $ to buy Bitcoins to perform an attack. Which makes it infeasible for almost every possible adversary on the planet. Attack like this would be almost impossible to do, even for government of a very rich country (we all know what country I am talking about). Also, if we implement cementing after Y confirmations as a quick fix and set Y to something relatively high (like 20), shouldn't everybody be safe this way ?
Maybe. Let's put it this way - cementing is simple and obvious, if it was that great Satoshi would have implemented it from the start. So we shouldn't do any "quick fix" without a solid understanding of the reasons for the decision and a thorough analysis of the dynamics of the new system. I mean, were there ever blocks reorgs longer than 10 blocks ? Do they even occur naturally?
AFAIK no, and depends on the definition of "naturally" but essentially no. So the only time a block reorg longer than 10 blocks will ever happen is because an advanced double spending attack. Logically, implementing cementing after Y blocks (where Y = relatively big number, like 15, 20 or 50) should be an absolutely viable solution to our problems. Unless there are other drawbacks, not mentioned in this discussion. I surely could use @Gavin's opinion here. |
|
|
|
This is just a form of cementing. The obvious hurdle is that different nodes see things at different times and thus this is not a signal that will converge to universal agreement (unlike vanilla longest-branch). More concretely, a node could be stuck on the wrong version. This can be used only if there is a higher-level signal that can override the cementing. (Currently it's hardcoded checkpoints, but they're too infrequent to be practical).
What if overriding cementing would require some kind of majority vote ? So every time a client receives a new/alternate chain, which overrides something already cemented, it also checks if majority of the network agrees with this ? This could be done by connecting to let's say... 128 randomly selected peers but limited to single node per 65536 IP block (X.X.*.*). Do I make any sense, or is this a stupid idea ? It's not very robust. Even with the IP range restriction it should be easy for an attacker to game this. How exactly ? Also, if we implement cementing after Y confirmations as a quick fix and set Y to something relatively high (like 20), shouldn't everybody be safe this way ? I mean, were there ever blocks reorgs longer than 10 blocks ? Do they even occur naturally? |
|
|
|
It is likely this will never be economically viable.
I am not exactly taking economic viability into equation. I am saying that some entity may execute such attack even if it is totally not economically viable.Why? Because (being only reasonably paranoid) there are and/or there will be organizations which would love nothing more than to kill "our small project". Now we are going slow, but wait till bitcoin capitalization reaches 1.000.000.000$ or 10.000.000.000$ - that is when we will see what Bitcoin really can do. And shit will hit the fan. Hopefully it will be too late for them to try anything. |
|
|
|
Meh. It will converge to near-universal agreement, and the nodes that don't converge to that agreement will know that they need to fix their shit manually. In your terms, the "higher-level signal" would be a human, and I don't see that as a downside. If you assume that an attacker can isolate some subset of the network and feed it garbage, then those nodes will need manual help one way or the other. Why not take the safe and simple measure to protect the rest of the network?
I think you are correct and the main logical reason is that cementing protects 100% of the clients (entire network) at the cost of very small fraction of clients gone bad. So the question we must ask ourselves is: what is more important - (1) protecting the entire network against powerful adversaries, or (2) protecting single (<1%) stranded clients gone wild because of either an attack, or local network malfunction ? For me, the answer will be always (1). |
|
|
|
This is just a form of cementing. The obvious hurdle is that different nodes see things at different times and thus this is not a signal that will converge to universal agreement (unlike vanilla longest-branch). More concretely, a node could be stuck on the wrong version. This can be used only if there is a higher-level signal that can override the cementing. (Currently it's hardcoded checkpoints, but they're too infrequent to be practical).
What if overriding cementing would require some kind of majority vote ? So every time a client receives a new/alternate chain, which overrides something already cemented, it also checks if majority of the network agrees with this ? This could be done by connecting to let's say... 128 randomly selected peers but limited to single node per 65536 IP block (X.X.*.*). Do I make any sense, or is this a stupid idea ? |
|
|
|
It is likely this will never be economically viable.
I am not exactly taking economic viability into equation. I am saying that some entity may execute such attack even if it is totally not economically viable. |
|
|
|
a) What happens to all the transactions from the original chain that happened after the 1.000.000 BTC transaction ? Are they all erased from existence ?
All these transactions will become invalid and will remain so forever (assuming everyone now builds on the attacker's branch and nobody replaces it with yet another one). It's actually worse than what you described because transactions can have multiple inputs. The attacker will get his 1M back, and also all coins which trace back to the original double-spent transaction (which can be much more than 1M, even all coins in existence) will be shuffled around. Then i will expand my thought experiment. Let's say that Bitcoin network has grown, and people use it to trade 100.000.000$ worth of goods & currencies weekly. 1. A powerful adversary spends 50.000.000$ to buy 1.000.000 Bitcoins from MTGOX 2. He builds his alternate double - spending chain for a week, while in the meantime, people buy 100.000.000$ worth of goods & currencies using Bitcoin 3. After a week, adversary introduces his chain fork which double-spends his 1.000.000 BTC to his address 4. At least 100.000.000$ worth of currencies & goods that were bought through the week are lost 5. This causes major havoc in the Bitcoin world, people's trust in the currency is seriously undermined. 6. ?? ?? 7. PROFIT ! So how do we avoid this ? If even I have produced this scenario, it is reasonable to think that powerful adversaries may already be working on it. Also, another logical conclusion of mine is that all alt-currencies like Litecoin are useless, because attack like above can be arranged with ease using little hashing power. I think that if a block is invalidated, all transactions in it which are not double-spent go back to the memory pool and can be included in the next block. Even if not, the client that originally sent the transaction still has it and can rebroadcast it, it is still just as valid.
Yes, but will the client rebroadcast it ? Was such scenario already tested ? c) Will the original chain be erased from every client's database instantly the moment when a longer valid chain is supplied, or is there some other mechanism at work here ?
See a, the client keeps forks, however this might change when pruning enters the picture. Ok, so my logical conclusion is that pruning cannot be implemented, until we solve this problem once and for all. The unconfirmed pool is most likely in memory for all node implementations therefore there remains the chance that valid but unconfirmed transactions will cease at some (long) delay from the memory of the network.
But when they do, there will be no way to fix the mess. |
|
|
|
So i was thinking heavily and it produced questions which will help me (and hopefully some other people) to better understand how the Bitcoin protocol works. If on any level i have made a mistake somebody correct me please. Suppose that somebody (like Botnet, Russian Mafia, Government or FED) has amassed **significant** resources both in money and hashpower (HP > 51%), and following happens. 1. That somebody (let's call im adversary) pays a very large sum of BTC (let's say 1.000.000 BTC) to an exchange 2. Adversary waits for X blocks * (let's say 100 blocks), while secretly building his own alternate (double spending) chain on the side. 2a. Meanwhile, the exchange & people keep moving the Bitcoins , so the original sum of bitcoins gets divided like this:  3. After block 101 passes, adversary introduces his alternate, longer chain which double spends the original 1.000.000 transaction to an address different than the original address, and erases the original chain which divided the sum to multiple addresses from existence. 4. ?? ?? 5. PROFIT ? * - That is possible because he has >51% of HP, so he can always produce chain faster than the rest of the network. Also @see Meni Rosenfeld thread and whitepaper for details. I have following questions: a) What happens to all the transactions from the original chain that happened after the 1.000.000 BTC transaction ? Are they all erased from existence ? b) What happens if the alternate chain completely drops many other (unrelated) transactions that were previously accepted into blocks and received from 1 to 100 confirmations ? Are these transactions completely lost ( I) ? Or perhaps only confirmations are lost, and the transactions are unconfirmed ( II) ? b1) If only the transactions' confimations are erased ( II), will the network re-relay all the 0-confirmation transactions that were done before ? Will the network keep information about unconfirmed transactions which do not exist anymore ? c) Will the original chain be erased from every client's database instantly the moment when a longer valid chain is supplied, or is there some other mechanism at work here ? |
|
|
|
OMG, OPEC LOL ? I hope OP is seriously not serious. This better be trolling.  |
|
|
|
|
So far i keep reading lots of vague information & buzzwords on the net about Ripple, and I still cannot figure what it exactly is and what it will actually do.
Would somebody care to explain it to me in few simple words ?
|
|
|
|
(...) PayPay, VIScAm, Mastercrap, JP Morgue, Western ULose, etc. (...)
Hahaha  Seriously, you made my day. |
|
|
|
Just had a weird realization - right now it costs a not small fortune in fuel costs to go out to space, and is cheaper to stay down here. Once we're more or less space-bound, it will be cheaper to stay in orbit, and cost ridiculous amounts just to come down to visit a planet and come back up.
At some point in the future, it will probably be necessary to leave earth as the sun has a limited amount of years it will exist before it burns out. This is still very far into the future though. Yep, like 5 billion years worth of fuel. So "at some point" is pretty far-fetched. I seriously doubt even our civilization and our bodies will exist in its current or similiar form. We are in trouble before the sun burns out. In 700 million years , as it ages, the sun has bloated enough to make life impossible: scorching hot desserts and evaporating oceans. Mars should be nice if it is terrraformed in time. From what i know, the sun will get bloated and turned into a red giant right before the end of its existence (so still few billions years to go). |
|
|
|
Just had a weird realization - right now it costs a not small fortune in fuel costs to go out to space, and is cheaper to stay down here. Once we're more or less space-bound, it will be cheaper to stay in orbit, and cost ridiculous amounts just to come down to visit a planet and come back up.
At some point in the future, it will probably be necessary to leave earth as the sun has a limited amount of years it will exist before it burns out. This is still very far into the future though. Yep, like 5 billion years worth of fuel. So "at some point" is pretty far-fetched. I seriously doubt even our civilization and our bodies will exist in its current or similiar form. |
|
|
|
Standard disclaimer first: I am often wrong.
But I've got a nagging feeling that all of the pure Proof-Of-X (where X != Work) systems would set up a dynamic of "the rich and powerful get more rich and more powerful."
The more coins you have, the more you get, as far as I can see in all of the proposed schemes (another disclaimer: I only vaguely pay attention to all of the Proof-of-X schemes, so feel free to tell me how I'm wrong). Seems to me that would end up being a destructive feedback loop, where your decentralized currency naturally gets more and more centralized over time.
You are correct, however what other solutions (besides some kind of cementing) can you produce that can mitigate the risk of 51% attack ? Also, i have sent you a PM. |
|
|
|
|
Show Posts
