Satoshi didn't solve the Byzantine generals problem

[TPTB_need_war]

To censor, he has to orphan other miners' blocks that do include the transactions. That is visible.

This requires to assume that we all see and believe this. Right now chinese speculators can bribe a small pool to generate 10 consecutive orphaned blocks and start spreading FUD that someone tried to attack Bitcoin. With intention to buy cheap coins.

Wow, such horrible logic.

You can not know an attack did take place, because the forks could be a ruse, yes.

But you can know that an attack did not take place because there is no such fork anywhere in existence.

Unless you believe that all miners are colluding. I don't believe that. Even then, censorship would leave the censored transactions in the mempool.

@TPTB you are falling into the same logic trap as CfB. Proving an attack is not the same as proving the lack of an attack.

But...we certainly can't know there won't be an attack tomorrow, or the day after, or any other time. That is not only true, but clearly implied by the wording of the white paper.

People need to decide whether they can live with that risk or not.

Sorry smooth. You are going to be embarrassed this time. Get ready.

Hint: mempools prove nothing.

You should have read my Decentralization thread. Obviously you did not.

[TPTB_need_war]

Here is what I taught monsterer before.

Here was some other discussion that linked back to that:

As I explained to monsterer upthread, it is not possible to objectively prove (with cryptography and math) which chain is the honest one and which one is the dishonest one when there are censored transactions.

[...]

Note however that this minority chain is unprovable to a full node that wasn't online as it was occurring (which was my point to monsterer)...

[smooth]

To censor, he has to orphan other miners' blocks that do include the transactions. That is visible.

This requires to assume that we all see and believe this. Right now chinese speculators can bribe a small pool to generate 10 consecutive orphaned blocks and start spreading FUD that someone tried to attack Bitcoin. With intention to buy cheap coins.

Wow, such horrible logic.

You can not know an attack did take place, because the forks could be a ruse, yes.

But you can know that an attack did not take place because there is no such fork anywhere in existence.

Unless you believe that all miners are colluding. I don't believe that. Even then, censorship would leave the censored transactions in the mempool.

@TPTB you are falling into the same logic trap as CfB. Proving an attack is not the same as proving the lack of an attack.

But...we certainly can't know there won't be an attack tomorrow, or the day after, or any other time. That is not only true, but clearly implied by the wording of the white paper.

People need to decide whether they can live with that risk or not.

Sorry smooth. You are going to be embarrassed this time. Get ready.

Hint: mempools prove nothing.

You should have read my Decentralization thread. Obviously you did not.

Mempools only prove nothing if nodes are also conspiring. Someday when (maybe) there are only mining nodes, that might be plausible. Today it is not.

It comes down to

Where's the fork

Show me the fork

If we don't see forks, then there is no majority of CPU power colluding to censor transactions. It doesn't exist. (Unless all miners are part of the collusion, which they are not.)

Also, if there are no forks, then there is no question about "which chain is the 'honest' one" because there is only one chain.

Deviations from this are (at present) easily explainable by propagation.

[TPTB_need_war]

Mempools only prove nothing if nodes are also conspiring

Are you still blind?

Here is what I taught monsterer before.

Here was some other discussion that linked back to that:

As I explained to monsterer upthread, it is not possible to objectively prove (with cryptography and math) which chain is the honest one and which one is the dishonest one when there are censored transactions.

[...]

Note however that this minority chain is unprovable to a full node that wasn't online as it was occurring (which was my point to monsterer)...

Are you blind?

Orphaned chains (not sustained forks!) are a natural and can't be proven to be an attack. Even those longer-con chains which orphan another chain which do not fall within the expected variance due to natural orphan rate can't be distinguished from natural (non-attack) network connectivity issues. Also I already explained upthread that an emphemeral fork (which orphans another chain) can't be blamed for a double-spend or censored transaction, because there is no provable correlation. Seems you've forgotten where I had to teach you in my Decentralized thread why it is impossible for a minority chain to prove anything (because the state of the chain is never absolute w.r.t. to any external chain/clock and is always moving forward). Which is the same analogous mistake enet made upthread.

How many times do I have to say that ephemeral forks are not an indication of an attack. And proving correctness of block chain state between ephemeral forks is impossible. The longest chain rule wins. Period! Damn it!

[smooth]

Mempools only prove nothing if nodes are also conspiring

Are you still blind?

Here is what I taught monsterer before.

Here was some other discussion that linked back to that:

As I explained to monsterer upthread, it is not possible to objectively prove (with cryptography and math) which chain is the honest one and which one is the dishonest one when there are censored transactions.

[...]

Note however that this minority chain is unprovable to a full node that wasn't online as it was occurring (which was my point to monsterer)...

You are still getting the logic backwards. No one is trying to prove a minority chain did anything. They can't because they don't exist (with significant frequency).

As a necessary condition for someone to be 51% attacking to censor transactions is that those minority chains exist at all. If those minority chains don't exist at all, then no one is attacking.

If someone creates fake minority chains (at significant cost), then it could be inconclusive evidence of an attack. We would have to look closer to try to determine if an attack is taking place, which could include keeping a node online, even if you didn't do so normally.

Possibly, you could be fooled (and be unable to determine otherwise) into thinking an attack took place when one really did not. But you can't be fooled into thinking an attack did not take place when one actually did take place, unless someone hides all evidence of the minority chain. That is implausible.

I therefore conclude at present, there is no attack taking place.

[TPTB_need_war]

Why can't you read?

Mempools only prove nothing if nodes are also conspiring

Are you still blind?

Here is what I taught monsterer before.

Here was some other discussion that linked back to that:

As I explained to monsterer upthread, it is not possible to objectively prove (with cryptography and math) which chain is the honest one and which one is the dishonest one when there are censored transactions.

[...]

Note however that this minority chain is unprovable to a full node that wasn't online as it was occurring (which was my point to monsterer)...

Are you blind?

Orphaned chains (not sustained forks!) are a natural and can't be proven to be an attack. Even those longer-con chains which orphan another chain which do not fall within the expected variance due to natural orphan rate can't be distinguished from natural (non-attack) network connectivity issues. Also I already explained upthread that an emphemeral fork (which orphans another chain) can't be blamed for a double-spend or censored transaction, because there is no provable correlation. Seems you've forgotten where I had to teach you in my Decentralized thread why it is impossible for a minority chain to prove anything (because the state of the chain is never absolute w.r.t. to any external chain/clock and is always moving forward). Which is the same analogous mistake enet made upthread.

How many times do I have to say that ephemeral forks are not an indication of an attack. And proving correctness of block chain state between ephemeral forks is impossible. The longest chain rule wins. Period! Damn it!

[smooth]

Well they are indication, just not conclusive evidence, since they can be natural or faked (at a cost)

But lack of ephemeral forks is conclusive evidence of lack of an attack, subject to the (reasonable) conditions I stated above.

[TPTB_need_war]

Well they are indication, just not conclusive evidence, since they can be natural or faked (at a cost)

smooth in Bill Clinton mode.

They can also be an indication of deception to confuse when there are actually attacks ongoing, which was CfB's correct point.

But lack of ephemeral forks is conclusive evidence of lack of an attack, subject to the (reasonable) conditions I stated above.

Wrong again. Example, Finney attack. Example, a double-spend that falls within the expected number of confirmations of normal orphan rate.

And censored transactions with ongoing 51% attack where there are no forks other than normal ones with the expected number of confirmations of normal orphan rate.

[smooth]

Well they are indication, just not conclusive evidence, since they can be natural or faked (at a cost)

smooth in Bill Clinton mode.

They can also be an indication of deception to confuse when there are actually attacks ongoing, which was CfB's correct point.

Good thing we do not have any such confusion then!

It seems no one is interested in spending money to create confusion about attacks they aren't performing.

But lack of ephemeral forks is conclusive evidence of lack of an attack, subject to the (reasonable) conditions I stated above.

Wrong again. Example, Finney attack. Example, a double-spend that falls within the expected number of confirmations of normal orphan rate.

A Finley "attack" does not exist in the system as defined by the white paper, where PoW defines ordering (as opposed to mint timestamps as described in section 2). If people want to be dumb and rely on zero conf in Bitcoin, they are attacking themselves.

[monsterer]

Orphaned chains (not sustained forks!) are a natural and can't be proven to be an attack.

Irrelevant. BGP does not distinguish between attacks and natural faults due to latency

Also I already explained upthread that an emphemeral fork (which orphans another chain) can't be blamed for a double-spend or censored transaction, because there is no provable correlation.

See above.

Seems you've forgotten where I had to teach you in my Decentralized thread why it is impossible for a minority chain to prove anything (because the state of the chain is never absolute w.r.t. to any external chain/clock and is always moving forward). Which is the same analogous mistake enet made upthread.

Fuck man, you can't even keep all the concepts in your head from the past discussions!

I finally see the core of your mistake. You expect the system itself to catalog and prove faults and automatically use this information somehow to give a warning that the byzantine tolerance has been exceeded. However, this is not a requirement in the least - the system will work up until the point it fails, the failure mode is undefined.

The link you reference is concerned with evidence of historical forks in a system with a completely different consensus rule than LCR.

[TPTB_need_war]

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 suggest you also read the paper more carefully. Specifically Section "6. Reliable Systems" which we are referring to.

What it says is that as the hardware fails the outputs can become like traitor inputs to other hardware components causing the cascade to lie, which is precisely the BGP problem and what the solution is modeling by a count of traitors (passing along a traitor's lie doesn't create a new traitor). Even in the case where the derivative computation is corrupted due to the corrupted input, this is still a quantified probability of cascade of traitors obtainable from engineering and math/models applied from hardware MTBF rates. It is more exact science or estimation than not knowing. There is no decentralization, Sybil attacked introduced which otherwise makes the estimation highly unknowable and unmeasurable (science requires measurement to validate that models are predictive).

The examples in the paper are toy examples. Now consider a real system with many interconnected computers each running million or billions of lines of code. Passing along a lie does not create a new traitor, but responding incorrectly to an unexpected input does create new traitors. So it is very difficult to ever know how many Manchurian Candidate traitors exist, ready to be triggered.

Of course you are not omniscient to know this can't be modeled in any applications of the solution. I am quite confident models apply in real world use cases.

Obviously Turing complete (unbounded recursion) outcomes can't be decidable, but dependently typed systems do exist.

Perhaps mission critical hardware controllers, routers, etc..

Byzantine fault tolerance is used because it allows robustness against complex failures to a greater degree than simple majority voting, even when the components are not simple bits of hardware with an easily-quantifiable MTBF (which are often bullshit, BTW).

The Byzantine use case applies when ever there is redundancy of components that form a circuit, but the MTBF of those nodes of the circuit still applies to models of cascaded failure. Byzantine analysis tells us limits on this cascaded failure w.r.t. to the redundancy.

Manufacturer MTBF may be marketing BS but ConsumerLabs (i.e. independent verification) can compile third party stats.

[TPTB_need_war]

monsterer is on Ignore for repeating his same failed argument redundantly after it has already been refuted. Sorry I don't have time to argue with an idiot.

I've been patient enough and I can't allow those who are incapable to steal all my time. Sorry.

I was planning to write some code this afternoon and instead I had to expend the afternoon explaining an issue that should have been clear when I posted the first reply to smooth. Instead those incapable people that take me on a whirlwind of their misunderstandings. I am patient for those who can finally get it. But monsterer has proven that he is so hard-headed that he can't learn new concepts.

In smooth's case, please understand that he hasn't been spending all his time researching the specific area I have been, so this should be no reflection on his abilities. I've just spent more time in this area than he has. I am just joking him about Bill Clinton.

[monsterer]

monsterer is on Ignore for repeating his same failed argument redundantly after it has already been refuted. Sorry I don't have time to argue with an idiot.

When you have to put your fingers in your ears to stop the truth from getting in, it's time to reconsider your motives.

[smooth]

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 suggest you also read the paper more carefully. Specifically Section "6. Reliable Systems" which we are referring to.

What it says is that as the hardware fails the outputs can become like traitor inputs to other hardware components causing the cascade to lie, which is precisely the BGP problem and what the solution is modeling by a count of traitors (passing along a traitor's lie doesn't create a new traitor). Even in the case where the derivative computation is corrupted due to the corrupted input, this is still a quantified probability of cascade of traitors obtainable from engineering and math/models applied from hardware MTBF rates. It is more exact science or estimation than not knowing. There is no decentralization, Sybil attacked introduced which otherwise makes the estimation highly unknowable and unmeasurable (science requires measurement to validate that models are predictive).

The examples in the paper are toy examples. Now consider a real system with many interconnected computers each running million or billions of lines of code. Passing along a lie does not create a new traitor, but responding incorrectly to an unexpected input does create new traitors. So it is very difficult to ever know how many Manchurian Candidate traitors exist, ready to be triggered.

Of course you are not omniscient to know this can't be modeled in any applications of the solution. I am quite confident models apply in real world use cases.

I'm of course not claiming there are no devices that are simple enough to analyze in that manner, but it is a small subset of consensus systems today.

And what we are seeing in the real world more and more is that even safety-critical systems are relying on increasingly-intractable mountains of code, with testing, process certification, redundancy and fault tolerance used to reduce failures to an "acceptable" level.

Anyway, I think we agree for the most part, largely disagreeing on matters of terminology and (in the case of Bitcoin) probability of future failure.

And the discussion has become repetitive.

So, I'll bow out of this thread for now, especially if you are ignoring monsterer who is largely correct (though also may have a slightly different perspective)

[TPTB_need_war]

Well they are indication, just not conclusive evidence, since they can be natural or faked (at a cost)

smooth in Bill Clinton mode.

They can also be an indication of deception to confuse when there are actually attacks ongoing, which was CfB's correct point.

Good thing we do not have any such confusion then!

It seems no one is interested in spending money to create confusion about attacks they aren't performing.

Obviously if block chain observers are using the presence of ephemeral forks (i.e. orphaned chains) which are outside the normal variance threshold window of orphaned chains, then attackers may be financially motivated to created ephemeral forks which are not attacks. How did you measure that an attack is an attack again (you objectively can't!)

And don't tell me that they waste resources, because 1) the profitability or justification for hiding the attack may be sufficient to do so, 2) by doing so gradually they can raise the normal variance threshold (see #c below) thus forcing the system to require more confirmations or rely on less than confirmed probabilities, and even if not then 3) remember they may be able to charge those resources to collective, e.g. how you and I proved recently that the Chinese mining cartel (which control 67% of Bitcoin's hashrate) is lying (and thus we can assume there is some massive high-level corruption going on, possibly stealing Three Gorge's Dam electricity at no cost).

But lack of ephemeral forks is conclusive evidence of lack of an attack, subject to the (reasonable) conditions I stated above.

Wrong again. Example, Finney attack. Example, a double-spend that falls within the expected number of confirmations of normal orphan rate.

And censored transactions with ongoing 51% attack where there are no forks other than normal ones with the expected number of confirmations of normal orphan rate.

A Finley "attack" does not exist in the system as defined by the white paper, where PoW defines ordering (as opposed to mint timestamps as described in section 2). If people want to be dumb and rely on zero conf in Bitcoin, they are attacking themselves.

Several rebuttal points:

a) In fact most of the Bitcoin use relies on 0-confirmations. I've been selling BTC to rebit.ph lately, and the transactions confirm within seconds of the transaction being sent.

b) As I wrote before and you ignored, even relying on multiple confirmations may be within the normal variance window for orphaned chains.

c) An attacker can drive the normal variance window upwards as high as he wants to. This is the analogous mistake/myopia you Monero guys made on your math for what you erroneously claimed fixed the block chain size Tragedy of the Commons.

d) You ignored my point about ongoing 51% attack which is not an ephemeral fork but rather is the longest chain.

Sorry! There is no such objectivity in Satoshi's PoW other than the longest chain rule (LCR). Period!

Eventually you will learn to respect the research I've done on this matter.

[ArticMine]

...
Several rebuttal points:

a) In fact most of the Bitcoin use relies on 0-confirmations. I've been selling BTC to rebit.ph lately, and the transactions confirm within seconds of the transaction being sent.

b) As I wrote before and you ignored, even relying on multiple confirmations may be within the normal variance window for orphaned chains.

c) An attacker can drive the normal variance window upwards as high as he wants to. This is the analogous mistake/myopia you Monero guys made on your math for what you erroneously claimed fixed the block chain size Tragedy of the Commons.

d) You ignored my point about ongoing 51% attack which is not an ephemeral fork but rather is the longest chain.

Sorry! There is no such objectivity in Satoshi's PoW other than the longest chain rule (LCR). Period!

Eventually you will learn to respect the research I've done on this matter.

You have done some valuable research; however in many cases your conclusions simply do not apply. I am going to deal with (c) which in fact relates to the following post:

ArticMine PMed me after I wrote that flaming post, and said he would reply after studying my posts. He has not yet replied. Does that mean I am correct and there is no solution for Monero. I think so.

It is fundamental. Afaics, you'd have to completely rewrite Moaneuro.

Rewrite Monero, is not necessary at all but some documentation on how the Cryptonote adaptive blocksize limits actually work is needed, especially given the formula in section 6.2.3 of the Cryptonote Whitepaper is wrong. https://cryptonote.org/whitepaper.pdf. My response will come in time.

I will start by examining the Cryptonote Penalty Function for oversize blocks. This is critical to understand any form of spam attack against a Cryptonote coin. From the Cryptonote whitepaper I cited above the penalty function is:

Penalty = BaseReward (BlkSize / M_N - 1)²

The new reward is:

NewReward = BaseReward - Penalty

Where M_N is the median of the blocksize over the last N blocks
BlkSize is the size of the current block
BaseReward is the reward as per the emission curve or where applicable the tail emission
NewReward is the actual reward paid to the miner
The Maximum allowed blocksize, BlkSize, is 2M_N
The penalty is only applied when BlkSize > (1 + B_min) M_N Where 0 < B_min < 1 In the Cryptonote whitepaper B_min = 0.1.
 
The error in the Cryptonote Whitepaper was to set NewReward = Penalty

For simplicity I will define:
BlkSize = (1+B) M_N
BaseReward = R_base
Penalty (for a given B) = P_B
NewReward (for a given B) = R_B

The penalty for a given B becomes:
P_B = R_baseB²
While the new reward for a given B becomes:
R_B = R_base(1 - B²)
The first derivative of P_B with respect to B is
dP_B / dB = 2R_baseB

In order to attack the coin by bloating the blocksize the attacker needs to cause at least over 50% of the miners to mine oversize blocks and for an expedient attack close to 100% or the miners to mine oversize blocks. This attack must be a maintained over a sustained period of time and more importantly must be maintained in order to keep the oversized blocks, since once the attack stops the blocks will fall back to their normal size.  There are essentially two options here:

1) A 51% attack. I am not going to pursue this for obvious reasons.

2) Induce the existing miners to mine oversize blocks. This is actually the more interesting case; however after cost analysis it becomes effectively a rental version of 1 above. Since the rate of change (first derivative) of P_B is proportional to B the most effective option for the attacker is to run the attack with B = 1. The cost of the attack has as a lower bound R_base but would be higher, and proportional to, R_base  because miners will demand a substantial premium over the base reward to mine the spam blocks due to the increased risk of orphan blocks as the blocksize increases and competition from legitimate users whose cost per KB for transaction fees needed to compete with the attacker will fall as the blocksize increases. The impact on the coin is to stop new coins from being created while the attack is going on. These coins are replaced by the attacker having to buy coins on the open market in order to continue the attack. The impact of this is to further increase the costs to the attacker.

It at this point where we see the critical importance of a tail emission since if R_base = 0 this attack has zero cost and the tragedy of the commons actually occurs. This is the critical difference between those Cryptonote coins that have a tail emission, and have solved the problem, such as Monero and those that do not, and will in a matter of time become vulnerable, such as Bytecoin.

Afaics, the above does nothing to remove/ameliorate the Tragedy of the Commons in Satoshi's mining algorithm[1], except if viewed as short-term solution while no miners have a significant percentage of the network hash rate.

The problem is that as I explained for Ethereum, as transaction rate scales up and thus the block reward is dominated by fees, then unless there is a uniform distribution of hashrate amongst all full node miners (which is of course impossible since not everyone can locate their mining equipment next to a hydropower plant with 2 - 4 cents electricity or for that matter perhaps free subsidized electricity in corrupt environs such as China), then those miners with more hashrate will have lower costs of verification. Thus they will be more profitable and can buy more hashrate faster than the other miners. Thus mining will entirely centralize over time, because the economics are designed to centralize mining. So since mining will centralize, then attaining 51% of the mining power will be guaranteed and thus the above algorithm can do nothing to stop miners from spamming the block chain size by paying transaction fees to themselves. But of course with 51% of the hashrate, they can do anything they want, except up to the limits of what public perception will tolerate. I am assuming of course that transaction fees in a free market will reflect actual (marginal) costs and that verification cost will be significant relative to other costs such as bandwidth.

There is also afaics a math flaw in ArticMine's analysis. Unless N is very small, then a miner with a significant but less than 51% hashrate is going to win a block in most every N set, and thus they can hit the 2 * M_N hard limit every time (or what ever rate of increase they deem most cost effective according to the Penalty cost being a function of a square), gradually ramping the median block size up over time. Thus the spam attack is not avoided, rather it just takes longer. And again I had pointed out that by shorting the coin, they can potentially recover their lost block rewards and profit. And if N is very small, then the likelihood that a miner can win all N blocks with less than 51% hashrate increases. Also it is not clear to me from ArticMine's specification if N is overlapping meaning a FIFO queue? But I doubt that makes any difference to my conceptual math point (note I have not written down the equations to precisely quantify this alleged flaw).

Also the 2 * M_N hard limit means that block chain can't handle transient spikes in transaction load, e.g. such as would be required by Lightning Networks (which has sort of a garbage collection overhead which manifests has large spikes in transaction load).

Conceptually at the highest-level semantic model of the generalized essence, an anti-aliasing filter on transaction rate can't ameliorate the fact that a spam transaction is indistinguishable from a non-spam transaction.

To solve this problem we need to make the cost of what is burned when submitting a transaction greater than the cost of cumulative network verification costs. That both solves the economics of the first paragraph above and it also removes the need to limit the block size in any artificial way other than the burn cost. But in my design, I don't waste the burn cost and instead apply it to security in the form of unprofitable mining. Note that the only way to limit culmulative network verification costs is to centralize mining. And this is why I wanted to give up, because I didn't see any solution that didn't centralize mining. But then I realized the design I had for intra-block partitions can centralize while remaining controlled by decentralized PoW, thus effectively still decentralized. And this is why I say you will have to completely rewrite Monero (at least the consensus design portion of the block chain code).

[1]	I introduced this concept in 2013 in my thread Spiraling Transaction Fees and I nailed the block size as the fundamental issue in my last post in that 2013 thread.

Bumping up against the hard limit is probably wastefully expensive for this "attack"

What expense?

[...]mining equipment next to a hydropower plant with 2 - 4 cents electricity or for that matter perhaps free subsidized electricity in corrupt environs such as China[...]

You're suggesting mining is (or can be) free? That's absurd. Even if it were free, this attack still costs you the reward.

I am suggesting the State (or those corrupt who control it) can charge the cost of mining to the collective (think the Three Gorges Dam that wrecked environmental devastation downstream, upstream and derivative effects all over China). I have made this point numerous times. And apparently (after everyone said I was crazy), it came true in China and if true was a factor that enabled China to capture an estimated 67% of the mining and 51% attack Bitcoin. Documentation of these statements is in my vaporcoin thread.

If the profit from shorting is greater than the reward, then it doesn't cost you anything. The free mining cost just makes it more likely you can sustain it long enough to reap your reward. How do we know the Chinese won't milk the investors while the block reward is high (mining at near $0 cost charging it the cost to the collective) and then also profit by shorting it all the way down from $1000.

We are bunch of naive geeks who are being reamed (mined) by savvy traders and strategists. These are no different conceptually than Rothschild's and Rockefeller's methods of yore. The players and technological field change, the game remains the same. (Yeah I am crazy conspiracy theorist whose analysis is always wrong)

Edit: haven't you been slightly suspicious of why the MSM publicized Bitcoin so much. That doesn't happen without the approval the global elite.

PoS(hit) can never be secure, because if it has a functioning markets (which it must in order to be widely adopted and liquid), then one can borrow stake, attack the coin (which requires much less than 51% to for example delay transactions by some N blocks where N is a function of percentage of coin supply held), and then pay back the borrowed coin with cheaply bought coin as the price collapses due to attacks. You could simultaneously short it (i.e. which you did when you borrowed the coins, but sell some for fiat before you attack) for profits. Alternatively borrow fiat (or other cryptocoin), buy stake and short to profit and pay back loan. Also PoS can't distribute new coins, thus eventually the coin supply shrinks asymptotically to 0.

With PoW, your borrowed mining hashrate would eventually reach end of contract and the coin would repair itself. And you'd need much closer to 51% to do damage. You would hope to be able to purchase the coin at cheap prices, wait for it to rise back up and then sell it for fiat to pay back your loan. Much less plausible.

However if you are up against the corrupt State that charges cost of PoW mining to the collective, then we're screwed with profitable PoW also, except I have the idea to use the unprofitable PoW of every person's computer in the world (with latency preventing them from farming out to ASIC), which seems might be even too much of an expense for China to hide the subsidization of.

You propose a tragedy of the commons on the premise that the block reward is dominated by fees. When I first read this response I stopped right at that point since a block reward dominated by fees is actually not possible in a Cryptonote Coin short of actually setting the fees in the consensus code. This I thought would be clear from my previous comments, but it appears this needs some clarification. First I refer to both of your 2013 posts in which both the case of a fixed blocksize (with fees theoretically going to infinity, in practice they are bound by transferring the value of the coin to the miners) and an infinite blocksize (fees go to zero) both fail. I do not dispute either of those scenarios, in fact I have no problem giving you credit for them since you came up with them before I did. 

The reason the above two scenarios do not apply to a Cryptonote coin with a tail emission such a Monero becomes apparent when one considers the economics of the total block reward components of fees and base reward (new coin emission). If the total in fees per block significantly exceed the base reward then it becomes economically attractive for miners to burn coins to the penalty by mining larger blocks. The block size rises until the total fees per block fall below a level where it is uneconomic for the miners to pay the penalty by increasing the blocksize. This level is comparable to the base reward. It is at this point where the need for a tail emission becomes clear, since without the tail emission the total block reward (fee plus base reward) would go to zero.

The second claim is that a spam attack by a less that 50% subset of the miners is possible. As I explained I in the original post this is not possible since one has to either to purchase coins on the open market and pay them to other miners to burn them against the penalty or use hashpower to generate the coins and then burn them to the penalty. We are talking about the median not the mean. It is possible for a below 50% hashpower to raise the blocksize slightly by displacing empty blocks but this hardly constitutes a spam attack. The attacker would be spending say 40% of the cost of a 51% attack to raise the blocksize by say 40% and keep it there.

There is a double burn with Cryptonote. The first burn is the proof of work, the second burn is the coins that are paid to the penalty. This is fundamentally different from a coin such as Bitcoin.

Finally I will address the need to respond to changes in network demand, such as for example the Christmas shopping season. Here we are talking of a approximately 10x rise over the annual average a period of a month, with a peak on December 23. VISA has provided data on this. This can be easily be handled by a Cryptonote coin with N =100 and 2 minute blocks such as Monero.

 

[TPTB_need_war]

First I refer to both of your 2013 posts in which both the case of a fixed blocksize (with fees theoretically going to infinity, in practice they are bound by transferring the value of the coin to the miners) and an infinite blocksize (fees go to zero) both fail. I do not dispute either of those scenarios, in fact I have no problem giving you credit for them since you came up with them before I did.  

You clarified and refined the explanation and conceptualization, or at least brought it to my attention again, which is why I credited (and thanked) you for focusing me on that again in my Decentralization thread.

You propose a tragedy of the commons on the premise that the block reward is dominated by fees. When I first read this response I stopped right at that point since a block reward dominated by fees is actually not possible in a Cryptonote Coin short of actually setting the fees in the consensus code. This I thought would be clear from my previous comments, but it appears this needs some clarification.

The reason the above two scenarios do not apply to a Cryptonote coin with a tail emission such a Monero becomes apparent when one considers the economics of the total block reward components of fees and base reward (new coin emission). If the total in fees per block significantly exceed the base reward then it becomes economically attractive for miners to burn coins to the penalty by mining larger blocks. The block size rises until the total fees per block fall below a level where it is uneconomic for the miners to pay the penalty by increasing the blocksize.

If I understand correctly that by "burn coins to the penalty", you mean that miners will create fake transactions to themselves? Thus the cost of the penalty is being charged to the miner who can't generate fees from himself.

But that is incorrect rationale, because your and my entire point has been that the Tragedy of the Commons is due to market demand for scaling, then the block size is unbounded. Your (and my) entire point was that without any bound, then transaction fees would trend towards 0 and thus an oligarchy MUST form because verification is not only not free, but more saliently verification is less profitable any miner that has less hashrate than the other miner who has the most hashrate (since all miners have to verify the entire block chain and thus verification costs are the same for all full nodes and have to amortized over income from blocks).

Thus you've accomplished nothing in terms of the fact that verification will centralize.

I explained in this thread starting from first principles as to why the abstract Byzantine Generals Problem can't be solved decentralized. Period!

Thus that guarantees that it doesn't matter how you try to obfuscate this reality in numerous technobabble. smooth is incorrect to question whether Bitcoin is directly correlated to the BGP. I could explain that too, but I grow weary of foruming.

This level is comparable to the base reward. It is at this point where the need for a tail emission becomes clear, since without the tail emission the total block reward (fee plus base reward) would go to zero.

The base reward not going to zero does nothing to solve the Tragedy of the Commons, as explained innumerable times by me and reexplained again above.

The second claim is that a spam attack by a less that 50% subset of the miners is possible.

No I wrote what a 51% attacker could do to game theory Monero's penalty algorithm and I said otherwise if you make N too small in Monero's penalty algorithm, then a < 50% attacker can win more than N blocks with some probability.

As I explained I in the original post this is not possible since one has to either to purchase coins on the open market and pay them to other miners to burn them against the penalty or use hashpower to generate the coins and then burn them to the penalty.

Again you are not addressing that the Tragedy of the Commons is due to market demand for scaling, not from the miner creating transactions to himself. Thus the rest of your logic is inapplicable.

[TPTB_need_war]

So, I'll bow out of this thread for now, especially if you are ignoring monsterer who is largely correct (though also may have a slightly different perspective)

No he has stated not even an iota of correctness.

monsterer is spreading his dumb shit.

[ArticMine]

..

If I understand correctly that by "burn coins to the penalty", you mean that miners will create fake transactions to themselves? Thus the cost of the penalty is being charged to the miner who can't generate fees from himself.

But that is incorrect rationale, because your and my entire point has been that the Tragedy of the Commons is due to market demand for scaling, then the block size is unbounded. Your (and my) entire point was that without any bound, then transaction fees would trend towards 0 and thus an oligarchy MUST form because verification is not only not free, but more saliently verification is less profitable any miner that has less hashrate than the other miner who has the most hashrate (since all miners have to verify the entire block chain and thus verification costs are the same for all full nodes and have to amortized over income from blocks).

Thus you've accomplished nothing in terms of the fact that verification will centralize.

I explained in this thread starting from first principles as to why the abstract Byzantine Generals Problem can't be solved decentralized. Period!

Thus that guarantees that it doesn't matter how you try to obfuscate this reality in numerous technobabble. smooth is incorrect to question whether Bitcoin is directly correlated to the BGP. I could explain that too, but I grow weary of foruming.

...

I will respond to this because it is the crux of the entire argument. In Cryptonote the blocksize is bounded by the total of what market will pay in total fees for a block vs the base reward because a rational miner will not add transactions to a block that causes a net loss of fees received vs penalty paid. Also if demand falls then the blocksize falls with no recovery of the penalty. So total fees per block cannot fall to zero in the presence of a block reward. If the base reward is zero then yes the blocksize is unbounded.

Edit: Total fees per block can fall to zero only if the blocks are very small, below the minimum threshold, currently 20 KB  (60 KB after the fork to 2 min blocks) for Monero

[TPTB_need_war]

..

If I understand correctly that by "burn coins to the penalty", you mean that miners will create fake transactions to themselves? Thus the cost of the penalty is being charged to the miner who can't generate fees from himself.

But that is incorrect rationale, because your and my entire point has been that the Tragedy of the Commons is due to market demand for scaling, then the block size is unbounded. Your (and my) entire point was that without any bound, then transaction fees would trend towards 0 and thus an oligarchy MUST form because verification is not only not free, but more saliently verification is less profitable any miner that has less hashrate than the other miner who has the most hashrate (since all miners have to verify the entire block chain and thus verification costs are the same for all full nodes and have to amortized over income from blocks).

Thus you've accomplished nothing in terms of the fact that verification will centralize.

I explained in this thread starting from first principles as to why the abstract Byzantine Generals Problem can't be solved decentralized. Period!

Thus that guarantees that it doesn't matter how you try to obfuscate this reality in numerous technobabble. smooth is incorrect to question whether Bitcoin is directly correlated to the BGP. I could explain that too, but I grow weary of foruming.

...

I will respond to this because it is the crux of the entire argument. In Cryptonote the blocksize is bounded by the total of what market will pay in total fees for a block vs the base reward because a rational miner will not add transactions to a block that causes a net loss of fees received vs penalty paid. Also if demand falls then the blocksize falls with no recovery of the penalty. So total fees per block cannot fall to zero in the presence of a block reward. If the base reward is zero then yes the blocksize is unbounded.

Edit: Total fees per block can fall to zero only if the blocks are very small, below the minimum threshold, currently 20 KB  (60 KB after the fork to 2 min blocks) for Monero

Your error is of course as I already stated, that transactions can grow unbounded due to market demand for more transactions, and since the Monero block size limit is bounded by the market demand as you have admitted, then it is unbounded.

Thus fees (not block reward) will trend towards 0 because no miner can enforce a bound on the block size so the miners will compete with each other to provide the lowest fees since there is no limit on the number of transactions a miner can put in a block (i.e. the payer can send a transaction with lower fees and wait some extra confirmations until the miner with lower fees wins the block).

But as I already stated, this means those miners with more hash rate will have higher income than those miners will less hashrate, yet all miners have the same verification costs. Thus mining will centralize to an oligarchy. Satoshi put a 1MB block size limit to keep verification costs much lower than the block reward, so that Bitcoin would not centralize too quickly.

I rest my case. Monero has not prevented the Tragedy of the Commons. Please don't make me explain it again.