Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Troglodactyl

Pages: 1 ... 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 ... 64
376
General Discussion / Re: Consensus on the list of delegates
« on: February 03, 2015, 04:15:56 pm »
Quote from: Come-from-Beyond on February 03, 2015, 04:14:28 pm
Quote from: Troglodactyl on February 03, 2015, 03:55:56 pm
This whole thread has been focused on the implausible scenario in which most delegates are compromised. Exploring handling for such extreme cases is healthy, but it's important to keep the probability context in mind.

Actually the thread was derailed with bribery example. The point was supposed to be - if delegates control the only medium of exchange then this channel cannot be used for sending information that affect the delegates.
That would be true if there was only one delegate.

EDIT: Also nice to confirm that your original purpose here was to attack the system, not to understand it as you said in your OP. :-P

377
General Discussion / Re: Consensus on the list of delegates
« on: February 03, 2015, 03:55:56 pm »
Quote from: Come-from-Beyond on February 03, 2015, 03:27:39 pm
Quote from: bytemaster on February 03, 2015, 03:23:05 pm
Lastly if it is clear there is an attack, and it would be, then it would be TRIVIAL to release a universally accepted hard fork that simply reset the vote on the offending delegates to 0.

How is it trivial?
In context of such an incredibly unlikely situation in which all of the delegates have been hijacked and are persistently rejecting being voted out, such a fork would be an easy and verifiable code change.  In such a situation, I doubt the users would resist accepting the fork as an easy way to end the network disruption.

This whole thread has been focused on the implausible scenario in which most delegates are compromised. Exploring handling for such extreme cases is healthy, but it's important to keep the probability context in mind.

378
General Discussion / Re: BTS is 2nd only to BTC
« on: February 03, 2015, 02:37:33 pm »

379
General Discussion / Re: Consensus on the list of delegates
« on: February 03, 2015, 01:38:53 pm »
Quote from: Come-from-Beyond on February 03, 2015, 01:10:17 pm
Quote from: arhag on February 03, 2015, 10:00:39 am
I assumed that people will update their votes to make sure they can get all 100 evil delegates replaced by good ones so that the honest chain can take over.

Now we need something to distinguish bad and good delegates.

The voters always have to distinguish between delegates who serve their interests and delegates who do not.  That's the whole point of voting.  This sort of scenario makes it pretty clear, as delegates excluding valid votes clearly do not serve the interests of the shareholders.

380
General Discussion / Re: Consensus on the list of delegates
« on: February 03, 2015, 04:40:00 am »
See here: https://github.com/BitShares/bitshares/blob/master/libraries/blockchain/chain_database.cpp#L900

381
General Discussion / Re: Consensus on the list of delegates
« on: February 03, 2015, 04:15:36 am »
Quote from: arhag on February 03, 2015, 03:34:55 am
By the way, I haven't had time to carefully read the entire 8 pages, but I think it is worth commenting on the exchange between Troglodactyl and Come-from-Beyond. This is how I understand the consensus mechanism of DPOS to work (I would appreciate any corrections in my understanding by the devs).

Let's say 100 delegates are colluding to ignore any transactions that update the votes against their favor. They are also ignoring all blocks by the remaining honest delegate. They have 100/101 = 99% delegate participation. People are creating, signing, and broadcasting transactions that changes the vote for their balance away from the evil delegates and to other honest delegates. There exists enough transactions that if included in the blockchain would cause the delegates of the next round to be 101 honest delegates. However, anytime the single honest active delegates includes these transactions, the other delegates ignore his block.

The single honest delegate can wait until a round in which he is one of the last 4 block producers (this happens approximately 4% of the time every 17 minutes, which means it would take 1.5 days for there to be a greater than 99% probability of this opportunity opening up). If the single honest active delegate builds off the longest current chain created by the other colluding 100 evil delegates and includes as many transactions as possible in his block to get as many honest new delegates to replace the other 100 evil delegates, then this honest delegate could create a fork that reaches the next round with (ideally) a set of 101 honest delegates and with anywhere from 0 to 4 blocks less than the original chain created by the 100 evil delegates (which is why clients will ignore this fork for now). In this next round, all of the (ideally) 101 honest delegates in the competing fork each create a valid block (and include other remaining vote update transactions to get the number of honest delegates in the following rounds to 101 if it isn't already). If there were in fact 101 honest delegates in this round, that means they gain a one block advantage compared to the competing fork created by the colluding 100 evil delegates. After four more rounds like this, they will have a longer chain than the chain created by the 100 evil delegates. Even if the first round of the fork does not have 101 honest delegates (because it was impossible to stuff enough transactions in a single block to replace all 100 evil delegates), realistically, it just means that a few more rounds are needed before they have the longest chain. If they can get this longest chain within 16 rounds (before the chain reorganization limit), all live clients will switch over to that new chain run by the honest set of delegates. Clients that were offline during this transition and trying to resync some time later will then (I think?) choose the longest chain which would at that point be the one run by the 101 new honest delegates and not the one by the 100 old evil delegates whose chain would keep falling further behind.

So, if my assumptions about the details of how DPOS works is true, it means that even if one honest delegate remains, it is possible for the network to recover without hard forks in a reasonable amount of time. Now if all 101 delegates are evil and colluding together, then stakeholders have to resort to the hard fork method which I discussed in my previous post.

This is my understanding also, except that I don't know why offline clients would require manual intervention on resyncing.  They should sync to the active network, and may not even be aware that a fork existed unless they are isolation attacked.

I did think delegates could be voted out mid-round, but it looks like you're right on that unless I'm missing something.  I think this is a bug that should be corrected, and that a delegate should not be expected to confirm a block that revokes his active delegate status by voting him out of the top 101.

Issue created: https://github.com/BitShares/bitshares/issues/1344

EDIT: Strikethrough response to ninja edited comments.  :P

382
General Discussion / Re: Consensus on the list of delegates
« on: February 03, 2015, 12:05:59 am »
Quote from: Ander on February 02, 2015, 11:20:20 pm
Hmm,

I feel that BTS with a 10 second block time and the possibility of an avenue of attack that requires users to agree to hard fork to recover is probably better than BTS with an almost 10 minute transaction time but safer from attack.
...

...but recovery wouldn't require a hard fork in the current system, and in a system where the majority of delegates had to sign each block, as CfB is proposing, recovering would require a hard fork if the majority of delegates were hostile.

383
General Discussion / Re: Consensus on the list of delegates
« on: February 02, 2015, 11:13:48 pm »
Quote from: Come-from-Beyond on February 02, 2015, 11:11:12 pm
Quote from: Chronos on February 02, 2015, 11:03:32 pm
I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.

If you include 51x more transactions then tx/sec ratio will be the same.
Also that would make our network almost as painfully slow as Bitcoin.

384
General Discussion / Re: Consensus on the list of delegates
« on: February 02, 2015, 11:12:06 pm »
Quote from: Chronos on February 02, 2015, 11:03:32 pm
Quote from: Come-from-Beyond on February 02, 2015, 10:59:53 pm
The easiest part is to increase interval between blocks 51-fold.
I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.
Yes. This would mess up the markets badly, as well as requiring voters to revote just to keep the network from freezing even when delegates were doing a fine job.  Remember the uproar when having an inactivity fee was proposed? Same thing, plus tragedy of the commons, since the whole network freezes if enough individual voters don't actively keep it alive.

I still don't see any issues this is intended to correct as very serious.

385
General Discussion / Re: Consensus on the list of delegates
« on: February 02, 2015, 10:33:09 pm »
Quote from: Come-from-Beyond on February 02, 2015, 10:24:57 pm
Can't you guys just change the rules slightly and get rid of the issue?
If there is an issue...

What exactly are you suggesting?  You're welcome to pull request a fix yourself, or even campaign for a delegate position and try to either work for our blockchain long term or try to sabotage it. :P

386
General Discussion / Re: Consensus on the list of delegates
« on: February 02, 2015, 10:19:14 pm »
Quote from: Chronos on February 02, 2015, 09:48:04 pm
Quote from: Come-from-Beyond on February 02, 2015, 09:42:52 pm
Quote from: Troglodactyl on February 02, 2015, 09:32:24 pm
If an honest delegate signs a block that elects one or more new delegates, the newly elected delegates will clearly prefer that fork over the one in which the votes that elected them were ignored.

I suspect this will lead to fragmentation of the network which is very bad because it makes possible to do double-spending almost for free.
Also, this is most possible in a 51 vs 50 scenario. If the attackers had a sizable majority, say 81 vs 20, then it would be very difficult for the 20 to add enough ignored votes to their blocks to elect 31 more delegates and remake a longest chain.
Clearly if you somehow managed to get a strong majority of delegates hostile to the network elected, they could seriously disrupt service until they were voted out.   I don't think anyone here is disputing that. What I am disputing is the idea that they couldn't be evicted without a hard fork.

The hostile delegates have no way to maintain their power as long as honest delegates are also active, and the hostile delegates can't get rid of the honest ones. The more they disrupt the network, the faster the voters would respond and vote new honest delegates in on an honest block.

387
General Discussion / Re: Consensus on the list of delegates
« on: February 02, 2015, 09:32:24 pm »
Quote from: Come-from-Beyond on February 02, 2015, 08:17:34 pm
Quote from: Chronos on February 02, 2015, 07:53:39 pm
Come-From-Beyond has been explaining for 6 pages, haha. I'll summarize:

  • 51 of 101 delegates decide they never want to be fired (via bribery, for example).
  • These delegates ignore all blocks from the other 50 delegates. Their chain is longest, so it is accepted. The 50 are powerless.
  • The 51 delegates ignore all transactions that vote them out, but they still produce blocks without these transactions.
  • In the end, the accepted longest chain never votes them out. They can sell all BTS and maintain control of the chain.

Do I understand correctly?

Yes.
No.

The hostile delegates can't prevent the honest delegates from creating blocks. All they can do is ignore those honest blocks.  If an honest delegate signs a block that elects one or more new delegates, the newly elected delegates will clearly prefer that fork over the one in which the votes that elected them were ignored.

388
General Discussion / Re: Consensus on the list of delegates
« on: February 02, 2015, 07:44:41 pm »
Quote from: Chronos on February 02, 2015, 07:38:49 pm
This looks like a viable attack to me. A disruptive hard fork might be needed to overcome it.

The post-attack scenario is more like a company unable to hire anyone new, with a group of employees that are impossible to fire. Worse, these employees do not have to act in the best interest of the company, but they still receive pay (BTS) no matter their behavior, which they can constantly dump on the market for "real money". Not good, and not anything like today's "centralized" companies.
Can you explain how this is viable?

389
General Discussion / Re: Consensus on the list of delegates
« on: February 02, 2015, 06:37:09 pm »
Quote from: Come-from-Beyond on February 02, 2015, 06:23:23 pm
Quote from: Troglodactyl on February 02, 2015, 06:15:57 pm
In the BitShares network, as long as there are some delegates who continue building on the longest valid chain, and including valid transactions, that group will have an advantage over any group that ignores valid blocks. Even if they start out outnumbered, they can replace delegates by including votes, while hostile groups can only ignore honest delegates.

We assume that majority is bribed. Hence even if honest delegates build one chain and dishonest ones build another, the latter will be longer.
OK, what you're missing is that while the dishonest delegates are forced to ignore the honest ones, the honest delegates do not suffer the same disadvantage. The honest delegates can continue dropping honest leaf blocks on the hostile chain for as long as the hostile chain is longest. Eventually one of those leaves will give them the majority they need to permanently banish the hostiles.

390
General Discussion / Re: Consensus on the list of delegates
« on: February 02, 2015, 06:21:13 pm »
Quote from: Come-from-Beyond on February 02, 2015, 06:16:17 pm
Quote from: Troglodactyl on February 02, 2015, 06:05:03 pm
Sure, they'll be excluded from confirmation in the hostile chain, but they'll still be the leaf blocks in that chain after every honest delegate turn.  Each such honest leaf block can include votes that replace the hostile delegates and heal the chain.

...and heal a shorter chain. I don't get why someone would adopt a shorter chain. What lines of the code will make them do so?
If I'm an honest delegate, and I see that the longest chain is the hostile chain, I just have to sign my honest vote including block on the end of that formerly hostile chain, and at that point my honest chain is now the longest chain.

Pages: 1 ... 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 ... 64

Page created in 0.033 seconds with 23 queries.