Quote from: d5000 on September 09, 2018, 11:10:40 PM

Quote from: Zin-Zang on September 09, 2018, 08:38:58 AM

but if the Proof of stake coin uses coin age he also has to wait for the maximum coin age, so time wise he has to wait anywhere from 20 to 90 days for maximum coin weight for his next attempt.[...]
But unlike PoW , what he can Never do , is maintain 51% control and block transactions from being added to the blockchain indefinitely.

If his attempt fails, his stake won't be blocked, because his chain wouldn't be selected at all. It's as if the attack didn't happen. So he doesn't have to wait.

Valid Point , But he is failing so no one cares.

If he does succeed , then he has to wait 20 to 90 days before another optimal window is open to try again, if coin age is involved.
Giving the community time to take steps to block future attempts, thru required increased confirmations or rolling checkpoints (decentralized) or even a checkpoint server (centralized) depending on their opinion of the value of decentralization.

PoW miner has no such wait period and can run continuous succeeding attacks with no wait time.
Unless the PoW community required increased confirmations or rolling checkpoints (decentralized) or even a checkpoint server (centralized).
But the PoW attacker can get in many more attacks before a PoW community could protect itself.

Quote from: d5000 on September 09, 2018, 11:10:40 PM

Where you're right is that with a majority as low as 51% it is probably difficult to control a chain permanently.
But that only applies if the other 49% all mint actively. With two thirds of the active stake it should be possible to control the chain permanently and censor transactions, regardless of dormant periods.

It does not have to be all of the other 49%, with every stake , more of our attacker coins go dormant until whatever the other amount is, exceeds his.
He can not indefinitely block transactions unless he owns all of the coins, which if he did no one else would care, as no one else owns any.

I don't care if the guy own 80% of a proof of stake coin, by combining all of my coins into a single block, and using max coin age, I could get 1 block added per dormant period and he can't stop me therefore including my transactions in the blockchain.
He has to spread his coins thin trying to block every single opportunity , and all I have to do is focus all of my coins into a single block that can pierce his efforts, with the help of coin age.

Quote from: d5000 on September 09, 2018, 11:10:40 PM

Now even with "only" 51% the attack can do a lot of harm. The attacker can try to attack/double-spend again and again. No exchange would be safe, and so the coin would be probably delisted from all exchanges until the 51% scenario ceases - or exchanges would have to set, as you wrote, the confirmation threshold to 100% of the reorg limit, which are typically days. If the attacker doesn't sell his coins because his intention is to destroy it (e.g. because he short-sold coins before) then the only way to stop that scenario (that makes the coin de facto unusable) is a complicated hard fork "tainting" all UTXOs that have been part of the attack and block all tainted UTXOs.

Not really,
Bottlecaps is a prime example, it was 51% attacked multiple times,
all they did was reimburse Cryptopia for the double spend coins, and as of today it is still trading there,
with increased required confirmations to 200 and running a checkpoint server.
(They could have done a rolling checkpoint and stayed decentralized, but they choose a centralized solution.)

Quote from: d5000 on September 09, 2018, 11:10:40 PM

Quote from: Zin-Zang on September 09, 2018, 08:38:58 AM

To be honest , all PoS coin could institute a 1 hour rolling checkpoint and be guarantee no doublespend after 1 hour.
(Ending the only threat a 51% attack poses toward a PoS coin.)

At a first glance this approach looks good - but why is no PoS coin doing that? I think that it's possible this approach could add attack vectors for limited short-range attacks using network disruptions to confuse badly-connected nodes.

I think the fear is that an attacker could focus his attack specially trying to fork the network into more than one branch.
Without the ability to reorg , all of the ones caught on the wrong fork , would have to redownload a blockchain, kind of a pain.
Easy ways to mitigate this is choose random times or allow set times in the wallets to block reorgs between a time range of between 1 hour to 2 days.
This way the attacker has no idea where to focus a fork splitting attack. Also the wallet designer could include a manual Allow Reorg Button , that lets the client reorg from any time, if they were forked so they don't have to redownload the blockchain from scratch. Wink

*FYI: Blackcoin choose ~8.3 hours for their no reorg limit.*
Currently the lowest one, AFAIK.

Quote from: d5000 on September 09, 2018, 11:10:40 PM

Quote from: Zin-Zang on September 09, 2018, 08:38:58 AM

However it still would not protect a PoW coin from a 51% attack where the attacker goal was blocking new transactions from entering the chain.

A miner with 51% of the hashrate would not get all blocks, so he also cannot censor transactions.

http://redpinata-development.com/bitcoin-academy/index.php/reader/items/non-technical-overview.html

Quote

Since the network always accepts the longest chain, he would end up in creating every new confirmation and getting full control over the blockchain.
But what harm can he possibly do?
He now has the power to successfully exercise double spending attacks and to censor transactions.

If a block gets added with a transaction , he does not like, he just overwrites the block by not including it in his longer chain.

Look at the video : VIDEO: Nightmare of 51% Attack - part 2 in the above redpinata link.
PoW 51% Attacker can exclude all transactions.

PoS 51% Attacker can not because of the built in dormant period.

Bitcoin itself had 24 blocks (6 hours) overwritten by a over 51% consensus in March 2013.
https://bitcoinmagazine.com/articles/bitcoin-network-shaken-by-blockchain-fork-1363144448/
Article by Vitalik Buterin

Quote

safe mode alerted us theres a problem

Interesting enough Bitcore devs killed the alert system, so the alert that warned everyone in March 2013 is no longer possible.