Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Redundancy  (Read 497 times)

Offline mike623317

  • Hero Member
  • *****
  • Posts: 585
    • View Profile
Redundancy
« on: June 03, 2015, 06:40:02 PM »

I'm sure someone has already given this more thought, but i was wondering if BitShares have given any thought how we could keep the system up in the event of trouble in the US or Europe or China. I'm just wondering, given our core devs are in the US, what if there are some type of unforeseen event that caused disruption, how could we keep this distributed system afloat. Is it something that would take care of itself as the system grows and matures and adoption increases or do we need to make concerted efforts later to make sure not too many of our delegates are located in one country? Im trying to understand the robustness of the system that i'm sure will be there once we reach the size of BTC for example.

Be interested to hear what peoples opinions.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 11907
    • View Profile
    • BitShares.Europe
  • BTS: xeroc
  • GitHub: xeroc
Re: Redundancy
« Reply #1 on: June 03, 2015, 06:44:42 PM »
Is it something that would take care of itself
This.

- As for the network, it's the same as for bitcoin, as long as there are enough than 51 active delegates in the world that are voted into the top101 everything is fine.
- Core development happens in Blackburg, but not all devs are in the U.S. there are some in Europe and some others in China. Source code is open source. so development will go on .. maybe not at the current pace .. but it will not die off ..

Some months ago, we tried to setup a "consensus" about the data published by delegates
http://wiki.bitshares.org/index.php/Delegate/PublicData
among which there is a "legal country" and a "location" .. maybe we should push this idea a little more and statistically evaluate the data given by the delegates ..
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu

Offline Method-X

  • Hero Member
  • *****
  • Posts: 1120
  • VIRAL
    • View Profile
    • Dating & Relationship Advice For Smart Women
  • BTS: methodx
Re: Redundancy
« Reply #2 on: June 03, 2015, 08:10:01 PM »
I'm sure someone has already given this more thought, but i was wondering if BitShares have given any thought how we could keep the system up in the event of trouble in the US or Europe or China. I'm just wondering, given our core devs are in the US, what if there are some type of unforeseen event that caused disruption, how could we keep this distributed system afloat. Is it something that would take care of itself as the system grows and matures and adoption increases or do we need to make concerted efforts later to make sure not too many of our delegates are located in one country? Im trying to understand the robustness of the system that i'm sure will be there once we reach the size of BTC for example.

Be interested to hear what peoples opinions.

Keep in mind there is a difference between the location of the physical person and the location of the server. For example, when setting up my (now defunct) delegate marketing.methodx, I chose Singapore as the servers location because of their favourable legal system.

Offline Thom

Re: Redundancy
« Reply #3 on: June 03, 2015, 09:02:05 PM »
Is it something that would take care of itself
This.

- As for the network, it's the same as for bitcoin, as long as there are enough than 51 active delegates in the world that are voted into the top101 everything is fine.
- Core development happens in Blackburg, but not all devs are in the U.S. there are some in Europe and some others in China. Source code is open source. so development will go on .. maybe not at the current pace .. but it will not die off ..

Some months ago, we tried to setup a "consensus" about the data published by delegates
http://wiki.bitshares.org/index.php/Delegate/PublicData
among which there is a "legal country" and a "location" .. maybe we should push this idea a little more and statistically evaluate the data given by the delegates ..

I agree with all but your initial statement. "It will take care of itself" is exactly the kind of casual attitude that could lead to trouble. We need to be proactive in thinking about security, so I give +5% to the OP for raising the question. Wackou is an example of a delegate that thinks seriously about security. I think we need to be more and more security conscious as time passes and the ecosystem grows.

I'm sure someone has already given this more thought, but i was wondering if BitShares have given any thought how we could keep the system up in the event of trouble in the US or Europe or China. I'm just wondering, given our core devs are in the US, what if there are some type of unforeseen event that caused disruption, how could we keep this distributed system afloat. Is it something that would take care of itself as the system grows and matures and adoption increases or do we need to make concerted efforts later to make sure not too many of our delegates are located in one country? Im trying to understand the robustness of the system that i'm sure will be there once we reach the size of BTC for example.

Be interested to hear what peoples opinions.

Keep in mind there is a difference between the location of the physical person and the location of the server. For example, when setting up my (now defunct) delegate marketing.methodx, I chose Singapore as the servers location because of their favourable legal system.

This is also an important question. When I selected my primary and backup VPS  systems I specifically targeted locations besides the U.S. and Singapore, since the majority of delegates were already in those locations. I also think delegates (especially those in the U.S.) should consider how they manage their VPS hosts, and "stealthify" their association to the servers they manage. That is not an easy thing to do. Such efforts may be considered by most delegates to be overkill, especially now with such a small marketcap. Trouble is, once the link between a delegate and the hosts his servers run on is known, the cat is out of the bag so to speak and his network traffic will be there after scrutinized more heavily.

These topics warrant thorough consideration, especially once the details of DPoS 2.0 are fully disclosed and up for discussion.

Offline liondani

Re: Redundancy
« Reply #4 on: June 03, 2015, 09:44:05 PM »
I think the next client version/fork is to the right direction since the block signers will be a dynamic number... so we can have more participants...more difficult to control them.... am I missing something?
  https://bitshares.OPENLEDGER.info/?r=GREECE  | You are in Control | BUY | SELL | SHORT | SWAP | LOAN | TRADE |  

Offline Thom

Re: Redundancy
« Reply #5 on: June 03, 2015, 10:53:09 PM »
I think the next client version/fork is to the right direction since the block signers will be a dynamic number... so we can have more participants...more difficult to control them.... am I missing something?

Cost. You're missing the cost it will take to maintain them.

Going back to the analogy that BitShares is a Company we should be looking to minimize costs and maximize profits for our shareholders. Factors in that formula need to take the marketcap into consideration, it seems to me.

Another perspective is to look at BitShares as a micro economy, which it is. In that way why would we want to control it or regulate it? Shouldn't it be self-regulating, i.e. a free market?

Yet resources like block production and delegate pay must be managed. It is fuel that makes the engine run. But the engine needs many things to keep it running smoothly, and how everything is balanced so it runs efficiently is quite a challenge, a very dynamic challenge, like when our engine is going up hill more fuel and air are required.

How many witnesses / workers / delegates are required? That's a good question, and one that will likely need to have a dynamic answer. What will the algorithm be for setting the right number at any point in time for the factors that affect system efficiency while maintaining system integrity?

These are weighty topics to be figured out, and it's gonna take all of us to do it, including many above my pay grade.

Offline CLains

  • Hero Member
  • *****
  • Posts: 2576
    • View Profile
  • BTS: clains
Re: Redundancy
« Reply #6 on: June 03, 2015, 11:26:12 PM »
If we spend 0.5% of our current marketcap each year we have $80000 to spend on servers, which gets us 300 servers á $22/month. It's always nice to minimize existential risks. I believe the bottle-neck on decentralization right now is the number of actual people in this community who happen to be in different jurisdictions and are willing to set up a 3% witness. Server decentralization should definitely be a public *good* that we all recognize and strive for.

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Re: Redundancy
« Reply #7 on: June 04, 2015, 07:42:08 AM »
Is it something that would take care of itself
This.

- As for the network, it's the same as for bitcoin, as long as there are enough than 51 active delegates in the world that are voted into the top101 everything is fine.
- Core development happens in Blackburg, but not all devs are in the U.S. there are some in Europe and some others in China. Source code is open source. so development will go on .. maybe not at the current pace .. but it will not die off ..

Some months ago, we tried to setup a "consensus" about the data published by delegates
http://wiki.bitshares.org/index.php/Delegate/PublicData
among which there is a "legal country" and a "location" .. maybe we should push this idea a little more and statistically evaluate the data given by the delegates ..

You need just one delegate out of the 101 voted in for "survival" of the network. Voters can always pick another set of 101 delegates if at least 1 (currently voted in) delegate is active.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 11907
    • View Profile
    • BitShares.Europe
  • BTS: xeroc
  • GitHub: xeroc
Re: Redundancy
« Reply #8 on: June 04, 2015, 09:14:23 AM »
Is it something that would take care of itself
This.

- As for the network, it's the same as for bitcoin, as long as there are enough than 51 active delegates in the world that are voted into the top101 everything is fine.
- Core development happens in Blackburg, but not all devs are in the U.S. there are some in Europe and some others in China. Source code is open source. so development will go on .. maybe not at the current pace .. but it will not die off ..

Some months ago, we tried to setup a "consensus" about the data published by delegates
http://wiki.bitshares.org/index.php/Delegate/PublicData
among which there is a "legal country" and a "location" .. maybe we should push this idea a little more and statistically evaluate the data given by the delegates ..

You need just one delegate out of the 101 voted in for "survival" of the network. Voters can always pick another set of 101 delegates if at least 1 (currently voted in) delegate is active.
But then outsidees can know for shure that thay are on the correct fork .. this you need at least N/2 actives delegates at all time ..
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu

Offline puppies

Re: Redundancy
« Reply #9 on: June 05, 2015, 10:29:14 PM »
What if a witness set up a single hidden server, ran it with wallet unlocked, but with block production disabled.  Then set up a dead mans switch, so that in case thier primary, and or secondary servers went down this hidden server would turn on block production, and change the version to something that lets the voters know that this dead mans switch has been triggered. 

What do you think?  overkill?  stupid idea?  applicable to a likely threat vector?

https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline BunkerChain Labs

Re: Redundancy
« Reply #10 on: June 06, 2015, 01:21:33 AM »
What if a witness set up a single hidden server, ran it with wallet unlocked, but with block production disabled.  Then set up a dead mans switch, so that in case thier primary, and or secondary servers went down this hidden server would turn on block production, and change the version to something that lets the voters know that this dead mans switch has been triggered. 

What do you think?  overkill?  stupid idea?  applicable to a likely threat vector?

Why would you want to let voters know?

I think it's better to just have it run on the cloud with redundancy.. if anything happens to the virtual machine its on it moves live to another. Future configurations would include a dedicated cluster configuration with distributed storage with 2 heartbeat locations for an N+2 redundancy with the same configuration. This would work well in a round robin configuration so you don't have wasted 'standby' resources.. active:active:active geo-distribution.

I don't think witnesses are going to be limited to only hosting a wallet in the future. It's going to become far more extensive then just turning a block on block off option I think. At that point we need to consider enterprise level designs like I have briefly described. Note however what I suggested is generic and may not be suitable for what might come. :) .. I have no idea what it might look like in the future or what the requirements might be.
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | World's First Decentralized Tournament Platform Built Entirely on the Blockchain!
+-+-+-+-+-+-+-+-+-+-+

Offline puppies

Re: Redundancy
« Reply #11 on: June 06, 2015, 02:01:01 AM »
What if a witness set up a single hidden server, ran it with wallet unlocked, but with block production disabled.  Then set up a dead mans switch, so that in case thier primary, and or secondary servers went down this hidden server would turn on block production, and change the version to something that lets the voters know that this dead mans switch has been triggered. 

What do you think?  overkill?  stupid idea?  applicable to a likely threat vector?

Why would you want to let voters know?

I think it's better to just have it run on the cloud with redundancy.. if anything happens to the virtual machine its on it moves live to another. Future configurations would include a dedicated cluster configuration with distributed storage with 2 heartbeat locations for an N+2 redundancy with the same configuration. This would work well in a round robin configuration so you don't have wasted 'standby' resources.. active:active:active geo-distribution.

I don't think witnesses are going to be limited to only hosting a wallet in the future. It's going to become far more extensive then just turning a block on block off option I think. At that point we need to consider enterprise level designs like I have briefly described. Note however what I suggested is generic and may not be suitable for what might come. :) .. I have no idea what it might look like in the future or what the requirements might be.

Sorry.  I probably should have stated that I am speaking regarding an action by state actors.  While the OP did not specifically state that he was concerned with state action I beleive it was implied by his concerns.  If his concern is natural disaster, or power outage, or internet outage then we would be almost as safe if we all lived in the same town, as long as we rented servers in different places around the world.

In case of state action those servers might not be safe.  In fact we would have to assume that they would all be compromised.  I think this is the reason that diversifying the physical location of delegates, as well as diverifying the physical location of servers, and the homebase of hosting companies is important. 

I am speaking about an edge case, and that is why I asked if people think this is a threat vector that is not worth protecting against.  Having a backup plan based on a deadmans switch to protect against state action could help the network survive long enough to adapt.  If all of our north american delegates were to go off line, having some of them pop back up with a note that said "dead mans switch triggered, vote me out" while still producing blocks would allow our non north american friends enough time to spin up delegates capable of keeping the network alive. 

Theoretical edge case granted.  Just curious about peoples opinions.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

 

Google+