Boolberry is neither dead nor in trouble.
The network difficulties were resolved in a few hours.
Can someone explain what caused the network difficulties? |
|
|
|
Just because you cannot quantify the number of traitors does not mean the system will produce invalid results within the bounds. This is true of any BGP consensus and has absolutely nothing to do with trustless, decentralised solutions.
For Christ's sake, you cause me to repeat all the points I made upthread over and over again. I already explained to you invalid results where the observers can't know whether the state was attacked or not, which is a Byzantine fault! There is no way to compute this risk and in fact the asymptotic risk is 100% (probability = ~1) because all decentralized consensus systems must centralize (which I explained in detail upthread). You keep linking that page, and you keep ignoring the statement on that page that says "assuming there are not too many faulty components" Whereas, with a quantified probability of traitors (e.g. hardware MTBF), the risk of Byzantine fault is computed. Which was the intent of Lamport et al's paper.
That's not really the case. Read the paper more carefully. Simple probabilistic hardware failure is easy to cope with using redundancy and majority voting. The hard problem is failures that are more subtle and complex, which can mimic deception and collusion. The algorithm becomes a tool in a toolbox which is used to improve robustness against certain types of failures, but the robustness is still never absolute, and in real systems the actual probability of failure is still not known. |
|
|
|
I am saying that in a decentralized, trustless, Sybil-attackable scenario, there is also no conditional solution to BGP, because the participants have no way to conjecture the probabilities of 51% attack We'll have to agree to disagree. As long as I can write down a solution, and write down the condition under which it applies, then I consider that a conditional solution. I do not need to state a probability that such a condition will be satisfied. (nor does any solution to BGP provide all participants a consistent, provable observation when the system state is attacked).
I agree with this part. The condition of count of traitors has only utility in applications where the probabilistic rate of traitors can be conjectured. Utility is necessarily subjective. Also, ability to conjecture a probability is subjective. I have also I think argued convincingly that Satoshi's PoW design (and every decentralized consensus design) must trend towards and rely on centralization. Thus the asymptotic probability of 51% attack is ~1.
See there, you just conjectured one! Others likely conjecture a different one. Though Bitcoin does have a somewhat nice recovery property in that the failure only persists as long as 50% of the CPU power is conspiring to attack it. Unlike, an airplane for example. If too many components "temporarily" fail, then it may be catastrophically disassembled before they recover.
I can think of scenarios where that isn't necessarily true. For example, such an attack convinces speculators that the attack can be repeated at-will and so they flee the coin. Crash and burn. The system can still recover. There is no catastrophic disassembly. You will never convince all the speculators to leave either. It is a bit like infinite divisibility. You have infinite reducibility of speculative value. Altcoin at #1000 in market cap still has a (tiny) value, there is still a (tiny) incentive to mine, and its blockchain still functions. |
|
|
|
There is no decentralized solution to the BGP problem. Period.
For a moment, just consider this; you are saying that there is no solution to BGP in trustless anonymous systems, but: If you take a snapshot of the current bitcoin hash rate and equally divide it out between N generals of fixed and equal hash rate, this is now classical BGP. You must be forced to concede that you are in fact saying that there is no solution to BGP at all, which is clearly false. Look he is saying there is no "unconditional" solution, which is absolutely correct. There is a solution, which may work, or may not work, depending on the state of the world when it is applied. That is very much the same as Bitcoin, and stated as such by Satoshi in the white paper. Bitcoin is not unconditionally anything. If a majority of CPU power is conspiring to attack it, then it is failing. Though Bitcoin does have a somewhat nice recovery property in that the failure only persists as long as 50% of the CPU power is conspiring to attack it. Unlike, an airplane for example. If too many components "temporarily" fail, then it may be catastrophically disassembled before they recover. |
|
|
|
The reason why bitcoin's 51% tolerance is controversial in the face of classical BGP is that the ability for the generals to lie is proportional to the hash rate of each general. Their messages are computationally signed against being forged.
They can't be forged, but the sender isn't known either, so the problem specification is different, which is what I've been saying all along. I don't know whether a proper reduction is possible. Maybe that paper from Andrew Miller does something along those lines; I haven't read it yet. As far as proportionality, I don't think that matters. If generals can collude, which must be assumed, then one general with more hash rate is equivalent to many colluding generals each with the same hash rate. |
|
|
|
Thus although the paper is correct to state that BGP is solvable if the 2/3 + 1 of the generals are loyal (i.e. 3m + 1 total generals for m traitors), the only way to know that precondition is for the system to be centralized so that the count of the traitors is known. Thus the white paper is poorly written (w.r.t. this issue) because it does not explain that there is no decentralized, trustless solution to the BGP and insinuates the opposite in the mind of the naive reader.
No loyal general ever knows if the system is loyal or not.
There is no decentralized solution to the BGP problem. Period.
Another poor conclusion. If the set of all traitors was known a priori, the system would be tollerant to any bound! That is the entire point of the problem; the set of traitor generals is unknown. You could specify the number of traitors but not their identities. But I agree with you that is not as useful a problem, in practice. The whole context of the paper and the people writing it was as a metaphor for building reliable distributed computing systems, where the number of failures is not set or known in advance. |
|
|
|
Afaics the paper has an important omission which is that when the disloyal generals (traitors) are not colluding (i.e. can't trust each other) then they have no reliable means to disrupt the loyal consensus.
This is a good observation, the results should differ depending on capabilities of the traitors and some traitors may compete with each other unintentionally helping the good guys. PS: By the way, classical BGP mentions somewhere that traitors collude AFAIK. Unless you specify that they can't, a proper solution (the problem statement uses the word "ensure") has to survive it, so it can be assumed. |
|
|
|
the only way to know that precondition is for the system to be centralized so that the count of the traitors is known
Yes we know this. And the same applies to Bitcoin's CPU power. Thus in some sense the problems are equivalent and the thread topic is incorrect (though I still question whether the problems are in fact equivalent). Just as BGP is solvable conditionally, so is Bitcoin secure conditionally. I call it a condition rather than a precondition because in some setups it is clear that the former is more useful. For example, a safety control system may specify that it continue to function properly as long as <1/3 of its components fail. |
|
|
|
Against a processing fee of 50 XMR (put in place to encourage playing by character), you can deposit any desired amount of XMR, have it converted to CKG (or other items, but please don't buy spoiling items  ) and just sit back for up to the next 7 years and see how it goes. The HODL Fund is coming soon. Stay tuned. |
|
|
|
Yes but Bitcoin already has a number of trusted dice and casinos up so the fact that people exchange for this coin just to play dice seems a bit odd. An unnecessary step so to speak but I guess the staking is alluring.
You forget that just-dice is the oldest and most established dice site at all. So it has many fans already. Using clams is no real hurdle, only exchange on poloniex and that's it. But many hold clams on justdice as investor so they earn from justdice while playing. The liquidity is not that great. Unless you are a small player you will take a significant hit from slippage in both directions. Maybe that is consistent with what dooglas says he wants though, to keep things smaller. Do you speak about the offsite invest or the orderbooks on the exchanges. Im not sure what you mean by offsite invest. I was referring to exchanging, where if you are BTC holder, you will have to exchange your BTC for CLAMs in order to play and then exchange back if you win (or even if you just don't lose all your money). In doing BTC->CLAM you will likely pay above market price for a larger amount and doing CLAM->BTC you will likely sell below market price (in addition to exchange fees). This effect is much more acute for larger amounts (anyone can trade 1 BTC without moving the market much), so this it serves to help keep BTC whales off JD and on other BTC gambling sites, which is what dooglus says he wanted (to keep the site smaller). There is also the effect of longer-term fluctuations if you are investing on the site but as you say even BTC is volatile and it isn't necessarily a given that CLAM would be more volatile (relative to fiat). Over the past few months many alts have tended to trade opposite BTC. |
|
|
|
Thus if you claim it is not solvable, then you have either found an error in their proof, or you have redefined the problem in your own way. I suspect the latter.
As with all such systems, fault tolerance is achieved up to a specified number of faults, and no farther.
If messages of the generals can't be faked then even 99 of 100 traitors is not a problem. I think he didn't redefine the problem, more likely he just forgot to provide some details. EDIT: From that paper: With unforgeable written messages, the problem is solvable for any number of generals and possible traitors. No, he mentioned that in his reply, as I did earlier. .e.g as you say "unless you add externally-assigned identities and unforgeable messages". He just fails to acknowledge that "Byzantine fault tolerance" only succeeds up to a threshold of faults. "Correctly functioning components of a Byzantine fault tolerant system will be able to provide the system's service, assuming there are not too many faulty components" https://en.wikipedia.org/wiki/Byzantine_fault_toleranceYou can specify a high threshold but that greatly constrains the available solutions (in my opinion to largely if not entirely useless ones in the context of cryptocurrencies, but not everyone necessarily agrees). Arguably a low threshold is also largely useless (it seems somewhat fewer, at least within the cryptocurrency community, agree with this statement), which would mean there are no very useful cryptocurrencies possible. That would not surprise me much. |
|
|
|
I have to say on this point your logic is atrocious. If we have synthetic hamburgers and synthetic fish, then it indeed does not matter from the point of view of Malthusian population limits with respect to food that the majority of life in the ocean is wiped out. It may matter for other reasons, but you haven't stated them.
I feel this is one of those Smooth moments questioning what the definition of "is" is. If literally all food is synthetic, that indicates it's become entangled into an increasingly complex chain of specialization of labor, so even if you worked in that industry, you would probably not be able to produce it yourself. That would be an extreme far left viewpoint where individuals are all required to fully integrate with the state to exist at all or you just instantly die. As I tried to tell the Anonymizer, technology solely for the sake of technology is useless because it's not a net gain, it creates a dependency to enslave you at the same time. The ability to become self sufficient, even if you don't exercise it, is far better than piling on endless amounts of unneeded complications into people's lives to entrap them. Am I the only one that doesn't think Ted Kaczynski was completely insane? Maybe you believe that the ability to become self-sufficient is by definition a desirable outcome, but does not mean that lack of self sufficiency means that Malthusian limits will be reached. The counterexample is exactly what has happened for the last century or so. Also, in general terms, specialization increases productivity across the spectrum. Even the least productive have cell phones (etc.) today, which means they are far more productive in absolute rather than relative terms than the least productive in times past. Possibly more than the most productive. You do not understand how gains from trade work. |
|
|
|
Thus per the definition, Satoshi's PoW design is not Byzantine fault tolerant, because the metric of when it is fault tolerant is ill defined (can't be measured). An unknowable state is as reliable (fault tolerant) and a random result, thus no reliability exists.
This is exactly the same as the Byzantine Generals Problem, which is solved up to 1/3 faulty generals (and only then, unless you add externally-assigned identities and unforgeable messages). If there are >1/3 faulty generals, then the honest generals can not determine that they are being tricked, so they will commence a doomed attack and they will all die. This is fault tolerant up to 1/3 traitor generals but not beyond. There is no way for the honest Generals to measure the number of traitor generals. If they could, they would not be tricked into attacking and die. Likewise, in Bitcoin if there is <50%* faulty hash rate, then there is no effective censorship and functional consensus (including on there being no effective censorship). If there is too much faulty hash rate, then the rest of the system can not measure the faulty hash rate and it can not determine that it is being tricked. In both cases, an outside observer who is able to see all the interactions can tell the system has failed. Within the system you can not. Who claimed it is solved with 1/3 of the generals are honest! (<1/3 are dishonest as I wrote above) Lamport et al. "It is shown that, using only oral messages, this problem is solvable if and only if more than two-thirds of the generals are loyal" http://research.microsoft.com/en-us/um/people/lamport/pubs/byz.pdfThat is the statement of the problem. The problem is not fault tolerant!
The only fault tolerant design for a solution is with centralization which obviously doesn't address the requirements of the problem, .e.g as you say "unless you add externally-assigned identities and unforgeable messages".
Thus I wrote upthread there is no solution to BGP. The problem will never be solved as stated.
Thus if you claim it is not solvable, then you have either found an error in their proof, or you have redefined the problem in your own way. I suspect the latter. As with all such systems, fault tolerance is achieved up to a specified number of faults, and no farther. |
|
|
|
Ah we have ArticMine the Malthusian who apparently religiously (irrationally) subscribes to the fable tale fraud of AGW and r0ach the Mathusian who doesn't appear to be aware that we can grow more food in our basements than we need:
I will give you the benefit of the doubt, as I was talking more about scaling the existing American style diet rather than everyone growing fungus or soylent green in the basement. I guess it's possible we will also stop eating real meat and only grow synthetic meat, but I think no matter what technology does, if population stays the same or increases, we will probably do things like wipe out a majority of life in the ocean for example, and you can't just ignore that because we now have synthetic hamburgers and synthetic fish to replace them. I have to say on this point your logic is atrocious. If we have synthetic hamburgers and synthetic fish, then it indeed does not matter from the point of view of Malthusian population limits with respect to food that the majority of life in the ocean is wiped out. It may matter for other reasons, but you haven't stated them. |
|
|
|
Thus per the definition, Satoshi's PoW design is not Byzantine fault tolerant, because the metric of when it is fault tolerant is ill defined (can't be measured). An unknowable state is as reliable (fault tolerant) and a random result, thus no reliability exists.
This is exactly the same as the Byzantine Generals Problem, which is solved up to 1/3 faulty generals (and only then, unless you add externally-assigned identities and unforgeable messages). If there are >1/3 faulty generals, then the honest generals can not determine that they are being tricked, so they will commence a doomed attack and they will all die. This is fault tolerant up to 1/3 traitor generals but not beyond. There is no way for the honest Generals to measure the number of traitor generals. If they could, they would not be tricked into attacking and die. Likewise, in Bitcoin if there is <50%* faulty hash rate, then there is no effective censorship and functional consensus (including on there being no effective censorship). If there is too much faulty hash rate, then the rest of the system can not measure the faulty hash rate and it can not determine that it is being tricked. In both cases, an outside observer who is able to see all the interactions can tell the system has failed. Within the system you can not. |
|
|
|
Again I think this another evidence that Bitcoin was created by the DEEP STATE with evil intentions Another? As far as I know such an argument is the only evidence. |
|
|
|
Bitcoin didn't solve BGP either. Nothing does because the problem is open to Sybil attacks.
What you keep denying is that there are solutions (all solutions, and provably so in the case of BGP) that solve the problem within a specified range. Generally up to 33%-of-generals in the case of BGP and maybe 50%-of-hash rate for Bitcoin. There is no solution that solves the problem up to <100% of participants. If you introduce identities then you have made it worse in a sense because now a failure of just one component -- the certificate authority -- breaks the entire system, instead of many (33%/50%/etc.) failures. On the topic of the thread, I consider Bitcoin and BGP as distinct, but related, problems. The setup is quite different, and I haven't seen anything close to a method (including Satoshi's email) to reduce one to the other. It is possible you can define another related problem that is in turn more useful than both Bitcoin or BGP solutions for some practical application. You still have to overcome Bitcoin's network effect even if your approach is somewhat more useful. |
|
|
|
Yes but Bitcoin already has a number of trusted dice and casinos up so the fact that people exchange for this coin just to play dice seems a bit odd. An unnecessary step so to speak but I guess the staking is alluring.
You forget that just-dice is the oldest and most established dice site at all. So it has many fans already. Using clams is no real hurdle, only exchange on poloniex and that's it. But many hold clams on justdice as investor so they earn from justdice while playing. The liquidity is not that great. Unless you are a small player you will take a significant hit from slippage in both directions. Maybe that is consistent with what dooglas says he wants though, to keep things smaller. |
|
|
|
When you see a corrected design, you will understand why not being able to Sybil attack a frame of reference is what enables establishing blame and making the system Byzantine tolerant.
It won't work - you cannot combine the majority-is-truth rule with something which gives power to the minority, because if you do, any faulty minority will be able to overthrow the majority, which leads to divergent chaos. It may work, up to its specified limits, but then it will fail a different way. |
|
|
|
The system will have failed, but it will have failed because it exceeded stated limits.
The system didn't fail. Who can prove it failed? Someone who attempts to use the service and is unable to do so. You can't require everyone to recognize such a failure because that would be a consensus outcome and now you are relying on a failed consensus system to produce consensus. Consensus only exists within the specified limits. |
|
|
|
|
Show Posts
