Bitcoin Forum
November 01, 2024, 10:22:37 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 »  All
  Print  
Author Topic: Proof that Proof of Stake is either extremely vulnerable or totally centralised  (Read 11753 times)
stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 506



View Profile
March 03, 2016, 04:14:50 PM
 #61

He can't just sit and produce blocks forever. In order to be able to produce blocks he must keep balances under his control. First he must exclude transactions emptying his cheaply acquired priv keys, then he will probably want to transfer balances from that keys to his own keys, because if he doesn't do that those gullible large stakeholders who sold him their empty keys will be able transfer funds from those keys again to their new addresses. In any case, attacker's fork will look completely different.

In that sense you are correct, yes. But the attacker would be wise to just censor the transactions sending his funds away and just keep on trucking.
He will need to censor also all transactions that depend on transactions sending his funds away, and that will soon be a lot of transactions.

monsterer (OP)
Legendary
*
Offline Offline

Activity: 1008
Merit: 1007


View Profile
March 03, 2016, 04:29:40 PM
 #62

He will need to censor also all transactions that depend on transactions sending his funds away, and that will soon be a lot of transactions.

Not at all. For transaction sequence A->B->C and A is censored, B and C become invalid if they depend on A.
stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 506



View Profile
March 03, 2016, 04:43:29 PM
 #63

He will need to censor also all transactions that depend on transactions sending his funds away, and that will soon be a lot of transactions.

Not at all. For transaction sequence A->B->C and A is censored, B and C become invalid if they depend on A.
They are valid on the main fork.
Even in the case of a very swift attack, as it was mentioned, max reorg depth in NXT is 720 blocks, that's about 12 hours, there will be many transactions that will need to be censored because they depend on transactions transferring funds from the attacker's addresses. And, if you ask me, I can't imagine how it's possible to collect priv keys for stake enough for such attack in such short time frame.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
March 03, 2016, 04:46:37 PM
 #64

max reorg depth in NXT is 720 blocks

Checkpoints are centralization.

For a centralized coin, then anything works, you don't even need PoS nor PoW (except to fool people with).

If we don't have decentralization, then the entire plot has been lost.

Do you need an example? Here you go (remember the Chinese mining cartel allegedly controls 65% of the Bitcoin hashrate):

https://www.reddit.com/r/btc/comments/48nnaw/the_truth_comes_out_core_devs_have_convinced/

monsterer (OP)
Legendary
*
Offline Offline

Activity: 1008
Merit: 1007


View Profile
March 03, 2016, 04:49:47 PM
 #65

They are valid on the main fork.
Even in the case of a very swift attack, as it was mentioned, max reorg depth in NXT is 720 blocks, that's about 12 hours, there will be many transactions that will need to be censored because they depend on transactions transferring funds from the attacker's addresses. And, if you ask me, I can't imagine how it's possible to collect priv keys for stake enough for such attack in such short time frame.

The attack scenario sees the main fork being orphaned. Whether you can't see how its done or not is kind of irrelevant. The risk is there, the cost is virtually zero and chance of success is very high IMO.
stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 506



View Profile
March 03, 2016, 04:50:34 PM
 #66

max reorg depth in NXT is 720 blocks

Checkpoints are centralization.
Mex reorg depth isn't checkpoints.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
March 03, 2016, 04:51:38 PM
 #67

max reorg depth in NXT is 720 blocks

Checkpoints are centralization.
Mex reorg depth isn't checkpoints.

It is if you expect it to be honored objectively by offline nodes (propagation isn't objective proof because it can be Sybil attacked). I will let monsterer explain that to you, if you don't understand.

stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 506



View Profile
March 03, 2016, 04:58:12 PM
 #68

max reorg depth in NXT is 720 blocks

Checkpoints are centralization.
Mex reorg depth isn't checkpoints.

It is if you expect it to be honored objectively by offline nodes (propagation isn't objective proof because it can be Sybil attacked). I will let monsterer explain that to you, if you don't understand.
May be you will explain us what exactly is centralised in a cryptocurrency (doesn't matter PoS or PoW) whose nodes reject reorgs if they are deeper than the max allowed depth?

stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 506



View Profile
March 03, 2016, 05:10:51 PM
 #69

They are valid on the main fork.
Even in the case of a very swift attack, as it was mentioned, max reorg depth in NXT is 720 blocks, that's about 12 hours, there will be many transactions that will need to be censored because they depend on transactions transferring funds from the attacker's addresses. And, if you ask me, I can't imagine how it's possible to collect priv keys for stake enough for such attack in such short time frame.

The attack scenario sees the main fork being orphaned.
Almost all attacks see the main fork being orphaned. Thank you for stating that, captain.
Whether you can't see how its done or not is kind of irrelevant. The risk is there, the cost is virtually zero and chance of success is very high IMO.
"IMO" - yes, this is your opinion.

kokojie
Legendary
*
Offline Offline

Activity: 1806
Merit: 1003



View Profile
March 03, 2016, 09:01:54 PM
 #70

Well you don't need to find historical keys (in order to rewrite the history of PoS block chains), when you can make them for nearly 0 cost.

Simply buy and sell on an exchange, and your cost will only be the spread.

Then short the coin, and start attacking.

Obviously this doesn't apply to illiquid meaningless microfloat altcoins. We are talking about whether PoS is viable for a mainstream decentralized coin. Not.

For a centralized coin, then anything works, you don't even need PoS nor PoW (except to fool people with).

So let's say if Bitcoin was PoS, your attack plan is:
step 1: buy up 50% of all available Bitcoin?

uh good luck with that.

btc: 15sFnThw58hiGHYXyUAasgfauifTEB1ZF6
monsterer (OP)
Legendary
*
Offline Offline

Activity: 1008
Merit: 1007


View Profile
March 03, 2016, 10:44:49 PM
 #71

Almost all attacks see the main fork being orphaned. Thank you for stating that, captain.

Sorry, I fail to see the point of your question if you assume that.
coretechs
Donator
Sr. Member
*
Offline Offline

Activity: 362
Merit: 250



View Profile
March 04, 2016, 12:29:57 AM
 #72

max reorg depth in NXT is 720 blocks

Checkpoints are centralization.
Mex reorg depth isn't checkpoints.

It is if you expect it to be honored objectively by offline nodes (propagation isn't objective proof because it can be Sybil attacked). I will let monsterer explain that to you, if you don't understand.

Nodes can identify themselves by cryptographically linking their IP address with an account (called "hallmarking" in Nxt) which mitigates Sybil attacks.  The client can be configured to only download blocks from a subset of nodes linked with known accounts and/or a minimum stake threshold.  In an attack scenario this would allow offline nodes to filter out malicious nodes and sync with the proper chain.  It's basically an optionally enabled reputation layer for trusting nodes linked to known accounts, not a silver bullet because of the flaws with all reputation systems (long term planned exploit) but still helpful as another layer of security.

https://nxtportal.org/peers  ("weight" is the stake of the account linked to the peer)

Example:
https://nxtportal.org/nxt?requestType=getPeer&peer=192.3.196.10

https://nxtportal.org/nxt?requestType=decodeHallmark&hallmark=65758c584d6eba44d405277a76bd58adb7c3f78744300e61ef4d12136539940a0c003139322e332e3139362e313064000000659e33010257b14003389b2904476641824dd076810210aea2f354d5ade07352a8d636f50974a2dd0641d38d5f3ec819f76d8cfd8ed1faff94112dc1269944a91b90267fe4

https://bitcoindoc.com - The Rise and Rise of Bitcoin | https://blocktap.io - Lightning powered crypto query engine
BARR_Official
Hero Member
*****
Offline Offline

Activity: 686
Merit: 500



View Profile WWW
March 04, 2016, 12:45:52 AM
 #73

The problem with using someone else's privkeys is that they can still have the same privkeys and undo anything you can do.

They also have the same actual coins you'll be using on your fork.
So even if you control enough stake to generate every new block,
there is still equal or greater stake on the main chain that can do the same thing.
You haven't explained how you can use someone else's coins to out-stake them,
when someone else is simultaneously staking the same coins (plus more) on the main chain.

Also, in order to offer $1000 for particular private keys, you would need to make a public offer.
There is no way to make a public offer to buy private keys without raising suspicion,
because everyone knows you could already get as many legitimate private keys as you want for free.
Therefore, everyone would know that you want those specific keys for an illegitimate reason,
and then they would either refuse, or find a way to get your money while anticipating and preventing your attack.

Another problem is that many PoS coins already develop persistent forks that never get resolved.
Just because you can create a fork doesn't mean that all nodes will accept it.

Also, all exchanges could block your forked nodes and resync as soon as they lose coins.  
If anyone wants to trade, they'll have to be on the same fork as the exchanges;
people will do what it takes to get on the same chain as their exchange.

If empty private keys are valuable, then so are offline nodes that haven't seen your attack yet.
The exchanges are already in everyone's peers anyway, while your nodes are not.
The wallet doesn't accept the longest chain in the world, just the longest chain among its own peers.

You'll also need to carefully plan your timestamping -
how many blocks ahead can your fake chain get and still arrive at a matching current time on the network?
Your chain might be longer, but users' wallets just received a new block 30 seconds ago.
They know they're not 12 hours behind, so there's a limit to how far ahead your chain can get.

There are already stake modifiers and multiple safeguards against timejacking/clock drift,
and valid blocks are also required to be within the median time of the most recent blocks.

In order to create a significantly longer chain, you'll have to present a chain of valid blocks that are timestamped to appear faster than the sequence of blocks on the real chain.  Have you run any numbers to estimate how high you'll be driving the difficulty to squeeze those extra blocks into the same period of time?  For your blocks to be valid, you will have to follow the same difficulty adjustments as if you were actually staking on the network with your limited amount of coins and stakeweight.  

Since difficulty would increase with each artificially faster block time,
while your stakeweight would decrease with each block that uses only your coins,
the time it takes you to hash the next block would grow exponentially.
It might take you so long to calculate that you would never catch up with the main chain.

The only way to decrease difficulty would be to put more time in-between your blocks;
but the main chain still has a stable average blocktime, so your chain wouldn't be longer.

And there might be a problem with your idea of "holding the chain ransom" -
if you successfully forked the network and invalidated all the transactions,
then everyone else but you would instantly have all the coin age and stakeweight.
Because you've just made it so that none of their coins have moved since your forked chain began.



Buying At Retail and Restaurants - BarrCryptocurrency.com
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
March 04, 2016, 04:48:11 AM
 #74

max reorg depth in NXT is 720 blocks

Checkpoints are centralization.
Mex reorg depth isn't checkpoints.

It is if you expect it to be honored objectively by offline nodes (propagation isn't objective proof because it can be Sybil attacked). I will let monsterer explain that to you, if you don't understand.

May be you will explain us what exactly is centralised in a cryptocurrency (doesn't matter PoS or PoW) whose nodes reject reorgs if they are deeper than the max allowed depth?

Maybe first you can explain why you are too ignorant to understand what I wrote which thus makes your reply irrelevant noise.

Hint: how can an offline node reject that which it wasn't online to detect? How does an offline know from the history which is presented to it, which chain (past the 720 limit) occurred first? Basic things you need to grasp before you post on this thread. An offline node is ignorant about the propagation order that occurred which the online nodes observed. Those who claim they were online, can be a Sybil attack lie. The only proof is what can be cryptographically stored in the block chain history. I so tired of replying to those who don't know a damn thing about what they are writing about yet are so damn boastful.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
March 04, 2016, 04:56:03 AM
 #75

Well you don't need to find historical keys (in order to rewrite the history of PoS block chains), when you can make them for nearly 0 cost.

Simply buy and sell on an exchange, and your cost will only be the spread.

Then short the coin, and start attacking.

Obviously this doesn't apply to illiquid meaningless microfloat altcoins. We are talking about whether PoS is viable for a mainstream decentralized coin. Not.

For a centralized coin, then anything works, you don't even need PoS nor PoW (except to fool people with).

So let's say if Bitcoin was PoS, your attack plan is:
step 1: buy up 50% of all available Bitcoin?

uh good luck with that.

It is so tiring to reply to the hordes of ignorant trolls.

I wrote upthread that one could buy and sell the coins on an exchange. They would then hold the historic private keys to attack with. This would only cost them the average spread between buy and sell prices, so they don't actually have to buy 50%.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
March 04, 2016, 04:59:57 AM
 #76

Nodes can identify themselves by cryptographically linking their IP address with an account (called "hallmarking" in Nxt) which mitigates Sybil attacks.  The client can be configured to only download blocks from a subset of nodes linked with known accounts and/or a minimum stake threshold.  In an attack scenario this would allow offline nodes to filter out malicious nodes and sync with the proper chain.  It's basically an optionally enabled reputation layer for trusting nodes linked to known accounts, not a silver bullet because of the flaws with all reputation systems (long term planned exploit) but still helpful as another layer of security.

You are trusting those with stake to not lie. But remember they can short the coin and destroy the value of their stake and still profit.

We are interested in trustless, decentralized crypto currency. That is what Satoshi pitched to us in his white paper. Satoshi's design is also flawed though.

Besides this does nothing to stop the attack monsterer outlined. Whose stake is valid? Whose is current, the reorganized block chain or the reorganized one? Which one was the reorganized one? You see proof-of-shit is self-referential and thus can't prove anything about itself.

stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 506



View Profile
March 04, 2016, 08:08:43 AM
 #77

It is so tiring to reply to the hordes of ignorant trolls.

I wrote upthread that one could buy and sell the coins on an exchange. They would then hold the historic private keys to attack with. This would only cost them the average spread between buy and sell prices, so they don't actually have to buy 50%.
Even monsterer doesn't claim that collecting historic priv keys is a viable attack vector. It was explained why it isn't. He claims that it's easy to collect enough priv keys for this attack in a short timeframe.
The attacker buys all keys at once, or very close together as stated in the description.

stdset
Hero Member
*****
Offline Offline

Activity: 572
Merit: 506



View Profile
March 04, 2016, 08:25:50 AM
 #78

max reorg depth in NXT is 720 blocks

Checkpoints are centralization.
Mex reorg depth isn't checkpoints.

It is if you expect it to be honored objectively by offline nodes (propagation isn't objective proof because it can be Sybil attacked). I will let monsterer explain that to you, if you don't understand.

May be you will explain us what exactly is centralised in a cryptocurrency (doesn't matter PoS or PoW) whose nodes reject reorgs if they are deeper than the max allowed depth?

Maybe first you can explain why you are too ignorant to understand what I wrote which thus makes your reply irrelevant noise.
I like to quote such sentences for posterity.

Now on the matter. If your node discovers a fork that is longer that the max reorg depth you can interpret that like if the node rejects to resolve the conflict in automatic manner, it prefers to stay on the fork it was before the conflict was discovered and lets you resolve it manually.
And you can be sure, in the case of such a major attack there will be a lot of forum threads, news, buzz, and it won't be difficult to detect which fork is a legit one.

monsterer (OP)
Legendary
*
Offline Offline

Activity: 1008
Merit: 1007


View Profile
March 04, 2016, 09:22:43 AM
 #79

The problem with using someone else's privkeys is that they can still have the same privkeys and undo anything you can do.

They also have the same actual coins you'll be using on your fork.
So even if you control enough stake to generate every new block,
there is still equal or greater stake on the main chain that can do the same thing.

Of course, but it isn't coordinated. If I have a majority of stake, enough to generate every block I can coordinate my attack much better than the set of uncoordinated honest nodes on the network. I'm fairly sure this is equivalent to a 51% attack and there is nothing which can be done at that point.
 
Therefore, everyone would know that you want those specific keys for an illegitimate reason,
and then they would either refuse, or find a way to get your money while anticipating and preventing your attack.

You're assuming that regular people need to know the inner workings of blockchain consensus - this is not a reasonable thing to expect, IMO.

In order to create a significantly longer chain, you'll have to present a chain of valid blocks that are timestamped to appear faster than the sequence of blocks on the real chain.  Have you run any numbers to estimate how high you'll be driving the difficulty to squeeze those extra blocks into the same period of time?

Timestamps can be faked; as long as the fakery still fits within the acceptability window, online nodes will accept the fork. Offline nodes have no way to tell, and will accept the fake fork regardless.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1010

Newbie


View Profile
March 04, 2016, 09:36:36 AM
 #80

You're assuming that regular people need to know the inner workings of blockchain consensus - this is not a reasonable thing to expect, IMO.

People know that they shouldn't give their Facebook passwords to strangers. They will reflect the same experience to money-on-blockchain. They don't know how blockchain consensus works so they will be afraid that the stranger will know their actual password knowing the old one.
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!