Agreed all, and emphasize the last sentence.

Note however, that the "adoption" is limited by the dynamic headroom of the initial innovation.

Who is confused?

I am not sure if I agree with you that rpietila destroyed Monero. I think maybe it would have occurred any way without him.

My statement is both true due to a technical fact, and also because group-wise innovation is an oxymoron. Innovation is a very tight incrementalized process that falls away exponentially under high communication load. Group-wise open source is very effective at refinement however. But before refinement, you need innovation. Can't put the cart before the horse.

I suggest a more efficient tool:

/dev/null

Kudos. My understanding of TW was too immature back then. I am catching up.


If they are issued centrally, then it means the coin is not autonomously decentralized. It is antithetical to TacoTime's upthread paranoia about BBR's compression by discarding ring proofs, wherein the only known vulnerability if is the developers can't be trusted and would plant bugs in the open source.

If they are issued by each miner taking a snapshot independently, then as I wrote before, no miner knows if it is part of the majority thus the only way to find out is to attempt to publish a block and see if it stays in the longest fork. Thus independently captured checkpoints works if all clients independently reorganize (rewind) a fork and then vote using PoW. But that is not what you are talking about here. You are talking about the centralized developers issuing an instruction to rewind to a checkpoint and all miners following the instruction because they have copy of the checkpoint. Thus this is really paragraph #1 above.


Exactly, thus they are paragraph #1 above.

And remember my point was that if the transaction activity gets too mixed into a Gordian knot on the attacker's fork, then there might be considerable human political resistance to unwinding that bad fork.

Thus although checkpoints could aid a centralized recovery, we must note they may not always work in every scenario.

Given Monero's very low tx rate, the Gordian knot is unlikely.


The unpublished thing I mentioned to smooth is where I have worked through that logic about automation and I can assure you that reorganizing from longish forks (whether an attack or naturally induced) can not be automated. The only decision you can make is to let the longest fork win and destroy instantly all the conflicting value in the shorter fork, or you can put a maximum fork length rule so that the two forks live on simultaneously and the market decides how to value them.

Fine with me. Probably the best thing that could happen to me.


Shhh. 

Don't kick a sleepingromping dog.

I never said that. Never. I said checkpoints can be an illusion "in some scenarios".

Cool I wanted to see how you reacted to lack of data. Because it seemed you were implying that probing is FUD. Nicholas Taleb made his fortune on the Taleb distribution, which is basically correctly valuing long tail events. You would not be well served to assume just because my probing doesn't find a vulnerability that BCX could attack, that means I never find anything earth shattering.

I am 90% certain that what I wrote exists and doesn't have an error, because it is quite simple, at least on first thoughts.

Thanks for that. When I worked for Mark Zimmer and Tom Hedges at Fractal Design Corporation in the early to mid-1990s on what is now Corel Painter, they were enamored that on my first day of work I had built a test suite for the printer drivers and was isolating bugs in it. Afaik Painter was the first software to come in a paint can, and it was the first commercial software to realistically simulate the effects of real media, such as paper gain, ink bleed, stylus pressure (employing a Wacom pressure tablet), etc.. The core algorithms were often written in Motorola and Intel assembly code and were entirely undocumented. I remember I isolated a bug in the some undocumented, convoluted, nested algorithm which unraveled the paper grain relative to a brush model, and doing so not by understanding what the function was doing precisely but by reverse engineering the state machine (totally in my mind, no written notes) and using induction to narrow possibilities. In short, I often see possibilities that others do not. I am able to build an elaborate imagination of a design or issue in my head. Put it another way, I have a vivid imagination and it is known that my IQ is concentrated in the visual mathematics realm (I loathe details that I can't handle in my head that have to written down).

Here is my photo in 1993 in Aptos, CA at Fractal:

That is a novel attack. Normally verifying each hash of a fork takes much less computational power than was consumed to generate each hash, because at normal difficulty levels it requires 1000s or more of hash computations before a block solution is found but only 1 hash computation to verify the block solution hash. But if you can lower the difficulty to the minimum then each block solution could consume only 1 hash computation and thus verifying would consume as much hash power as generating.

Thus the honest hashrate would be consumed for some duration verifying the extremely long fork of the attacker, while the attacker will be mining nearly exclusively on the honest fork during that delay, so the attacker can rewind some portion of the honest fork before the honest nodes finish verifying and rejecting the attackers diversionary long fork.

The attacker wouldn't necessarily need very much hashrate, rather a lot of time to generate a super long secret fork.

The simple mitigation is to not verify further newly presented forks for which the difficulty drops very significantly below the currently known fork. We assume we don't want to consider too long lived forks any way, so if difficulty drops that much it is very unlikely is rose back up again sufficiently to catch up.


I don't understand how decentralized checkpointing can work because if you don't put them on the block chain, then there is no decentralized record, and nodes don't know if they are part of the majority otherwise. If you put them on the block chain, they can be unwound by an attack.

Do you mean centrally issued checkpoints?

Afaics, smooth is correct. There is no way to build a chain of hashes that has a greater sum of their modular additive inverses than your hashrate can generate, i.e. that metric is invariant w.r.t. to the difficulty level . Thus as long as forks are measured by that metric, the longer one will always be the one with the greater hashrate (except for small probabilities of success with less hashrate) regardless the relative difficulty rates.

It seems you were sort of thinking about the way a selfish mining attack works, c.f. Majority is not Enough: Bitcoin Mining is Vulnerable.

What is your guess about this vaporware below? Don't worry you won't offend me, just be frank.

Does such a credible and correct unpublished white paper exist? Yes or no?

I wouldn't ascribe to such nonsense. I am trying to figure out what form a possible attack could potentially be, so I would know what symptoms to look for if any, and so maybe I could dismiss the entire thing early or increase my expectations.

Also to make sure I have designed around any such possible attack in my own coinz.

Not printing the timestamps far into the future, rather the statistics of the variations in gaps between the timestamps. You could bunch some them closer at a faster rate in time so they are deemed statistical outliers (I presume, haven't seen the math presented in any white paper), so they don't get counted in the computation of the difficulty.

But even this won't matter if the total difficulty of the forks is compared as the sum of modular additive inverses of the block hashes, then there is no way the secret fork can be longer (other than diluting the honest fork's hashrate with DDoS or orphans via selfish mining or block propagation interference).

Thus I rescind my opinion that BCX  is attacking with such a secret fork. He could possibly attack with some other vulnerability (such as my idea about messing with the ROI of miners thus driving network hashrate down), but not this one.

Edit: the ideas about messing with the ROI of the miners remain. If you can push the hashrate up higher than it should be then prevent or delay the readjustment and also selfish mine, you can amplify the ROI pain on the honest miners over selfish mining alone.

I agree if the comparison of two forks is the sum of the modular additive inverses of the block hashes.

In my prior post, I was trying to figure out how it was possible that the secret chain could be "longer" when it has less hashrate. Originally I didn't think it was possible, which is why I ignored the ideas from that thread and had presented other ideas further upthread. Then I reread that thread again.

Perhaps Auroracoin had a bug in that it only compared # of blocks? Or as you say Nite69 seemed to not know what he was talking about. That is what I originally wrote in my prior post, then just before I posted it I changed it because I guess I got confused in my haste as I was trying to figure what the heck those guys (Nite69 et all) were describing.

ETA is Oct. 12, 5 days from now.

Evan claims a KGW exploit was deployed against DRK.

The descriptions of the theory of such an exploit explain the difficulty can be reduced quickly by setting the timestamp of the latest block far into the future for the secret chain so the secret chain is mined with much lower difficulty, and then the secret chain can be brought back to the present time before publishing it, because timestamps that walk backwards in time aren't fully counted.

To compute the relative PoW of a chain, sum the modular additive inverse of each hash (e.g. hash subtracted from 2²⁵⁶). The secret chain can't end up with more blocks thus has a lower sum and isn't chosen as the longest chain. Or what appears to be more correct (what that thread is alleging) is if the longest chain is chosen by the greater number of blocks, the secret chain can mine more blocks since it is at a lower difficulty. The key is being able to mine faster at a lower difficulty by being able to move forward and then backward in time asymmetrically.

KGW offers other vulnerabilities because the secret chain can drop the difficulty, then mine faster without causing a rise of difficulty for up a day or so, by staying under the exponential well trigger threshold.

Clearly you see now the potential problem in Cryptonote with the 20% discard rule. It enables the secret chain to hide a bunch of fast blocks (bunching them together in time) without causing a rise in difficulty. Thus the secret chain can end up the longest chain without needing 50% of the hashrate.

I now change my opinion to very likely that BCX is building a secret chain nowRescinded. How many more days to the 22 day countdown?

Count me as interested.

Edit: it might be the asymmetry of the threshold between increase and decrease (i.e. 100+20 is +20%, but 120-20 is -16.7%). Others had mentioned that already and it is obvious on the chart.

The selfish mining paper shows that above 25%, the attackers % of the hashrate is amplified.

That is assuming you have employed the γ = 0.5 fix suggested in the paper which afaik Bitcoin never did so I assume CN copied the Bitcoin flaw? Otherwise the amplification starts from 0%. See the chart on page 11 of the paper.

So the attacker can selfish mine at the same time, to further amplify his hashrate.

BCX mentioned 20%, so it appears if γ = 0, his would be amplified to 25% and that is not including the KGW exploit.

Any way, it appears you only need enough to get the ball rolling downhill, because your hashrate grows over time as other miners drop off due to the drag on their profitability.

I still agree you need to quantify how much the potential KGW exploit accelerates over the selfish mining by itself. It is already known that all PoW coins in existence can theoretically be destroyed with selfish mining and 25% of the hashrate, but it might take a heck of a long time (perhaps exhausting the attacker's hardware rental capital or the profit he earn from such an attack) depending on if γ = 0 or the hashrate is higher such as 33%.

On KGW, that should take you about 15 minutes if you are really interested. There is your 20% hashrate triggering at less than a day...

http://bitcoin.stackexchange.com/a/22265/3441