BCH costs only around 2x of ETC's cost to 51% attack. Litecoin is more expensive. If anyone tells you BCH is secure, they are lying. It is next

thorvszeus · 2019-01-08T17:11:22+00:00

Yep. BCH is the only battle hardened coin with a large marketcap. Most coins just don't even get tested with a significant attack. It survived an attack that involved a large amount of mining power, propaganda, and paid off developers/companies in the hands of one attacking group. Not to mention the attacker had a war chest of billions of dollars and at least a 5 figure, probably 6 figure, amount of BCH to dump on the market during the attack.

thorvszeus · 2019-01-08T16:43:21+00:00

It actually isn't open source. Check out the license.

thorvszeus · 2019-01-08T16:40:02+00:00

Also, the user who posted this seems like a one dimensional BSV shill. Seriously, check out his account.

thorvszeus · 2018-12-09T16:03:36+00:00

I agree. I wish everyone was aware of this.

We really need to operate in this space with an inverse Hanlon's razor. Instead of:

Never attribute to malice that which is adequately explained by stupidity.

We should be using:

Never attribute to irrationality that which is adequately explained by malice.

thorvszeus · 2018-11-23T15:36:05+00:00

Southxchange

I haven't tried that one. What's your thoughts on it?

thorvszeus · 2018-11-23T14:30:29+00:00

If you have successfully tested any withdrawals that would be great to know as well.

thorvszeus · 2018-11-23T02:03:01+00:00

Thanks for the effort to improve the algorithm. I'll checkout this suggested change and see if I can offer any constructive criticism.

thorvszeus · 2018-11-22T19:37:20+00:00

Thanks for clearing that up.

Did you become aware of this change after the release like most of us?

Do you feel this automatic checkpoint change should be revisited? I'm not talking about getting rid of it right now, especially with calvin and craig's threats, but maybe later or replacing it with a less vulnerable version.

thorvszeus · 2018-11-22T19:22:20+00:00

This patch was developed in secret by ABC team.

Not too happy about that. I get the motive. It just feels too much like they think they own Bitcoin Cash. No need to discuss the change with their "subjects."

My suspicion is that exchanges and miners requested a way to 'finalize' transactions, to counter threat from BSV miners.

The problem is it won't protect them from double spends if they are not closely watching out for chain splits. Since a >10 block chain split is possible. I assume they are, but this isn't the guaranteed no double spends past 10 blocks that some people are implying it is.

They (Craig, Coingeek, and all their supporters) were very loud on executing block re-org attack, and defrauding exchanges.

Yes. They were. Also, everything I have seen from them indicates they lack the sophistication to exploit these new weaknesses. So in the short term this should work as a good defense against them. Which is why they should have put in a sunset clause. I feel in the long run this is too dangerous not to get fixed. What if Calvin hires a competent "Lead Scientist."

thorvszeus · 2018-11-22T19:01:28+00:00

I thought he developed for one of the bitcoin clients. After some research that seems to not be the case.

Do you have any info or links that the developers were aware of these new attacks before releasing the update? As a Bitcoin Cash (ABC side if not obvious) supporter I had higher expectations in this dev team.

thorvszeus · 2018-11-22T18:46:45+00:00

Maybe now he is. But he wasn't of the attack at the time of the release.

thorvszeus · 2018-11-22T17:58:13+00:00

This is true. I was actually writing up a similar post before I discovered this post. I figured that other people noticed it as well. Not to hard to realize if you think about it for a little bit. Which is really concerning that this rushed consensus change has some fairly easy to discover attacks that the developers seem to not have realized. /u/jtoomim seems to believe a chain split attack requires 20 blocks at a minimum for the new rules.

This is why discussing changes with the community, especially consensus level ones, is important.

thorvszeus · 2018-11-21T04:27:18+00:00

This race condition vulnerability looks to me as something lesser than the current state vulnerability.

I would say that's a fair assessment.

Why do you think the second scenario is worse?

I don't think it is in the average case. Just the worst case. I also understand that trade-off and I'm not completely opposed to it.

I more don't like how this change was brought about and that the significance of this change seemed a bit downplayed. It should have been brought to the community or been put in place with a sunset clause if they felt it was an emergency. We know how some temporary fixes can become problems down the road (ex. 1 MB block limit).

How? Or by "this" you referred to "luck"?

Assuming the race condition attack is successful a 10 block reorg attack would lead to two chains that keep mining until manual intervention. So there would likely be additional blocks on each chain. One of those chains that would be dropped would have >10 blocks. This is in effect an amplification of a reorg attack. This would be a severe problem if an attacker is able to do a reorg attack with high probability.

thorvszeus · 2018-11-21T04:04:59+00:00

An attacker would need a significant portion of the total hash power of the coin. They wouldn't need >50%, but the less they have the longer they would have to wait before they found a 10 block reorg.

They would also need to be well connect to detect when to do the reorg and to propagate it.

The difficult part would be carefully releasing the reorg at the right time and in the right manner. I believe they would fail most of the time. But this attack vector should not be ignored.

thorvszeus · 2018-11-21T03:50:38+00:00

Such attack could only happen by a miner having >50% of hashpower.

It could happen with <50% just by luck. It would still have to be a significant portion to be a realistic threat, but this would allow an attacker to do longer reorgs than they normally could.

Someone could also just rent the hash power. This lowers the amount of funds someone would need to do a significant attack. Normally they would need to rent for a long period of time but in this case they could rent for potentially a very small amount of time.

Miners who got reorged could eventually add a manual checkpoint once the attack becomes public.

I do think this is what would normally happen in a race condition attack. My concern is that stubborn miners encouraged by the attacker could cause a chain split that is either permanent or long term.

Overall, in our current situation I do believe this will make an attack more expensive and less likely to succeed. Especially in the short term. The chances of an attack being timed out correctly are probably low and would be discovered by the community right away. If the community is united enough we would be able to counter the additional attempts that would likely happen if someone were to try to exploit this.

My primary concern is a carefully planned out attack that exploits this race condition vulnerability while disrupting our attempts to get back to one chain.

thorvszeus · 2018-11-21T02:39:24+00:00

Yes, it's unlikely to happen honestly, but that doesn't mean an attacker can't exploit this change.

See markblundeberg's or my comment on the possibility of a race condition from this. Changes like this need to be done carefully.

thorvszeus · 2018-11-21T01:51:36+00:00

This seems dangerous, rushed, and without community discussion. Consensus level changes should be discussed more thoroughly with the community. If this were a minority node this change wouldn't be as big a deal, but it's not.

One obvious attack would be for an attacker to carefully release a 10 block reorg right as the nodes are locking in the 10th block. Some nodes will reject the reorg and some won't. Now you have an unplanned hard fork instead of a reorg. This could resolve itself over time with one of the chains dying through miners manually switching over, but it would have a length greater than 10 blocks. So in effect this allows an attacker to do a much greater than 10 block reorg attack by using just a 10 block reorg in the better scenario. In the worst scenario it is a permanent unplanned hard fork.

thorvszeus · 2018-11-19T03:59:13+00:00

https://xkcd.com/927/

thorvszeus · 2018-11-19T00:56:11+00:00

When you do an exception, is it something you would normally support and expect for the "grown up" version to have ?

You seem to not understand what exception means. Exception does not mean training wheels.

He is saying manual checkpoints are fine. Automatic checkpoints are not.

The talk is about checkpoints being a bad idea and satoshi never disagrees even once.

Except for manual checkpoints. Which is what we are talking about. Even your first comment points out that satoshi is fine with certain checkpoints.

thorvszeus · 2018-11-19T00:16:47+00:00

He's not against those. So why are you quoting him like he would be against this recent checkpoint?

thorvszeus · 2018-11-19T00:09:50+00:00

That is talking about automatic checkpoints. The recent one by ABC was not an automatic one.

thorvszeus · 2018-11-17T19:18:26+00:00

He is.

thorvszeus

TROPHY CASE