Business development delegate

[Thom]

All seed nodes are operational as is the newly created verbaltech2 witness. It has been a very long day but glad to see it pay off with success!

Thanks to everyone for all your hard work and dedication to the cause. As my delegate tools partner wackou says the names that helped along the way are too numerous to list, but I must at least thank Bytemaster for all of his expert assitance which he provided after working hours when he should have been out celebrating with the team.

And to everyone in this community I bid you farewell for now.

[Thom]

While I wait on the 0.9.3c client to finish scanning to get an up-to-date balance, I thought I'd post a quick update here on the progress our delegate has made since wackou posted here last month.

We have both been frantically working our asses off getting ready for the public release of graphene tomorrow, with wackou working on bts_tools and me working on a comprehensive VPS setup script for Ubuntu and Debian Linux. The idea is to bring a brand new bare bones VPS to a common state of readyness to run a full graphene seed or witness, including all updates, packages, tools and graphene itself.

It has been a very intense week of preparations and much testing! I have learned a huge amount just since last Friday alone. I am very confident now in my ability to quickly deploy a graphene node into production.

Wackou and I are fully agreed that deployment of the "small world" backbone architecture will need to come after the rollout, in part b/c the Cyptonomex team has had their hands full and will not be able to add the API call to the codebase until after graphene is live. The C++ API code additions we would like to facilitate a better backbone system were not too difficult to implement, and wackou has already coded them and submitted a pull request to Cryptonomex for inclusion when the dev team can find the time to merge it in. They provide functionality missing in graphene that was present in the 0.9.3c codebase.

I have completed the setup of 4 VPS systems as graphene seed nodes, for use in production starting tomorrow. Once Cryptonomex announces the final "go live" / release version of graphene I will deploy it to those seeds so they are ready for users to connect. They are running on the testnet until then.

That's about it. Both wackou and I will be campaigning for your votes to run a graphene witness to continue our work in making the BitShares network robust, reliable and fault tolerant.

One last note about The BitShares Saga. I had to put work on that project on hold as I just didn't have the time to continue the research, writing and website development AND obsorb all of the new information about graphene, not to mention participate in the forum discussions where various aspects of graphene were conceived and shaped. However, I remain excited and passionate and am looking forward to getting back to continue writing and complete the BitShares Saga book series. If you haven't seen what it is all about go check out the website and read the introduction. Do it now!

Thank you for your support!

[fuzzy]

Should we no longer vote or the delegate  btstools.digitalgaia and put all our support into the verbaltech delegate to continue supporting you?

At this point, I don't recommend to vote for btstools.digitalgaia anymore, as the pay from verbaltech is more than enough to pay for the servers. That shouldn't change anything, though, because I didn't expect my delegate to be voted in before the release of BitShares 2.0 anyway.

In the (unlikely) event it gets voted in, I think I would do a poll like Thom did to ask the community for their opinions, and burn it or redirect it to some other deserving delegates (I can think of a few that are still not voted in but have contributed a lot).

In summary:
 - Thom and I work as a team and are funded by the pay of delegate.verbaltech
 - btstools.digitalgaia is deprecated and people wanting to support me should support delegate.verbaltech.
 - when BTS2.0 is released, we will come up with a unified worker proposal

Great to see yourself and Thom working together on this.

[wackou]

Here comes the current update on the development of the backbone:

I have set up a backbone of 3 nodes already, you can see the details here: http://digitalgaia.io/backbone.html, or can check http://backbone03.digitalgaia.io/backbone to see the current status of the 3rd backbone node and how it is connected to the other ones.

I was planning to set up more with Thom, but I hit kind of a roadblock when implementing the monitoring plugin that allows a delegate to connect only to the backbone, thereby hiding its IP (1). I have a workaround for it, however this requires a lot more setup on the nodes and is only valid until graphene comes out (network api will change and this might not even apply any longer).

So I decided to work on adapting the tools for graphene instead as it is now coming very soon (fingers crossed!) and started runnning a witness in the testnet to be able to do so.

I won't set up more backbone nodes for now, but will leave those already running anyway if people want to use them, or the chain servers on them, for instance.

----

(1) The issue is that the call to "network_set_allowed_peers" expects to be given the peer ids, which is not public info and needs to be obtained from "network_get_info" on the node itself. I could solve it by only exposing access to it (by using my bts_proxy project) but that would involve quite a bit of setup on the nodes for a workaround that won't likely be applicable for graphene, so that seemed quite a waste of time. If this functionality is also missing in graphene and core devs don't have the time or need to do it themselves I might also be able to implement it but let's wait until then.

[wackou]

Just to be clear about something. If we update to the new version, then the delegate using bts_tools automatically will start running through the backbone system that you have running now?

No, at the moment this is only meant for operators of the backbone (Thom and me for now) to allow to set up backbone nodes that behave properly. The next release (likely 0.2.11, I hope to get this in about 2 weeks, but don't take my word for it) will add the possibility for delegates to connect to the backbone automatically. This will be accompanied by a more prominent announcement so that delegates don't miss it. This post was just meant to be an update to the delegate proposal, now that we are voted in.

Do you believe with he two delegates providing 130% total now with the market cap that the funds will be enough to provide enough of a distribution network.. or will there be some kind of option for some delegates to become a part of this backbone where it makes geographic sense?

At the moment, I propose that Thom and I manage the backbone so that it's easier to coordinate. My initial plan was to have 2 nodes in the US, 2 nodes in Europe and 2 nodes in China/Asia. Once it's up and running for some time without glitches, we should open it up to anyone that wants to participate and contribute a node (similar to how people contribute seed nodes).

There is a question of trust involved, though, because the timing attack that allows a peer to detect the IP of delegates--that the backbone is designed to thwart--can still be performed by the operator of a backbone node. So we should make sure that these are trusted community members.

This is the long-term plan anyway, because if people contribute backbone nodes to the network then this doesn't need to be a recurring cost for the blockchain and everyone wins: blockchain doesn't pay for the backbone but everyone benefits from it, and backbone operators get fame and gratitude for the service they give to the network  And if we can find financial incentives to run a backbone node that isn't supported directly by the blockchain, then that would be even better!

[xeroc]

+5

[BunkerChainLabs-DataSecurityNode]

AWESOME!!

I especially like these:

* added monitoring plugins:
  - 'voted_in': monitors when a delegate is voted in or out
  - 'wallet_state': monitors when a wallet is opened/closed and locked/unlocked
  - 'fork': tries to detect when the client is being on a fork and/or out-of-sync

Just to be clear about something. If we update to the new version, then the delegate using bts_tools automatically will start running through the backbone system that you have running now? Or is there a specific configuration that needs to be made in order to enable it? I didn't see anything regarding configurations on this so I just like to have that clarified.. thanks!

Do you believe with he two delegates providing 130% total now with the market cap that the funds will be enough to provide enough of a distribution network.. or will there be some kind of option for some delegates to become a part of this backbone where it makes geographic sense?

Another great delegate project hard at work for BitShares! Long time coming!

[wackou]

An update on the development of the backbone: I just released the 0.2.10 version of the tools that now allow to manage backbone nodes (see http://digitalgaia.io/backbone.html for a description)

Thom and I have already started setting up VPS instances to run those and we will add some more soon and configure them to bring the backbone up.

Next, I will need to update the tools to manage delegates in order for them to only connect to the backbone nodes (hide behind them), and start connecting to other peers (seed nodes, known peers) only when the backbone nodes start to fail. In case of an attack on the backbone, we don't want to leave delegates with no connection at all to the network.

At this point, the backbone will be publically available, and delegates will be able to connect to it in order to protect their IP addresses, while ensuring that the blocks they sign are broadcasted quickly to the other delegates.

Here's the changelog for this release:

Code: [Select]

0.2.10 (2015-09-03)
-------------------

* added support for managing backbone nodes
* new view in menu "network > backbone status" that shows the configured backbone nodes and
  whether we are connected to them or not
* added monitoring plugins:
  - 'voted_in': monitors when a delegate is voted in or out
  - 'wallet_state': monitors when a wallet is opened/closed and locked/unlocked
  - 'fork': tries to detect when the client is being on a fork and/or out-of-sync
* simplified config yaml file: there are now wildcards monitoring plugins you can use for most
  common tasks:
  - for delegate:
    + 'delegate': used to monitor an active delegate. This will activate the 'missed',
      'network_connections', 'voted_in', 'wallet_state', 'fork', 'version' and 'feeds'
      monitoring plugins
    + 'watcher_delegate': used to monitor a watcher delegate, i.e. without publishing
      any info (version, feeds) to the blockchain. This will activate the 'missed',
      'network_connections', 'voted_in', 'wallet_state' and 'fork' monitoring plugins
  - for seed nodes and delegate nodes, you don't have to specify required command-line args or
    monitoring plugins any longer, it is added automatically in function of the node type
* added "bts deploy" command to copy built binary to specified ssh host(s)

[BunkerChainLabs-DataSecurityNode]

Should we no longer vote or the delegate  btstools.digitalgaia and put all our support into the verbaltech delegate to continue supporting you?

At this point, I don't recommend to vote for btstools.digitalgaia anymore, as the pay from verbaltech is more than enough to pay for the servers. That shouldn't change anything, though, because I didn't expect my delegate to be voted in before the release of BitShares 2.0 anyway.

In the (unlikely) event it gets voted in, I think I would do a poll like Thom did to ask the community for their opinions, and burn it or redirect it to some other deserving delegates (I can think of a few that are still not voted in but have contributed a lot).

In summary:
 - Thom and I work as a team and are funded by the pay of delegate.verbaltech
 - btstools.digitalgaia is deprecated and people wanting to support me should support delegate.verbaltech.
 - when BTS2.0 is released, we will come up with a unified worker proposal

Excellent.. thank you!

[wackou]

Should we no longer vote or the delegate  btstools.digitalgaia and put all our support into the verbaltech delegate to continue supporting you?

At this point, I don't recommend to vote for btstools.digitalgaia anymore, as the pay from verbaltech is more than enough to pay for the servers. That shouldn't change anything, though, because I didn't expect my delegate to be voted in before the release of BitShares 2.0 anyway.

In the (unlikely) event it gets voted in, I think I would do a poll like Thom did to ask the community for their opinions, and burn it or redirect it to some other deserving delegates (I can think of a few that are still not voted in but have contributed a lot).

In summary:
 - Thom and I work as a team and are funded by the pay of delegate.verbaltech
 - btstools.digitalgaia is deprecated and people wanting to support me should support delegate.verbaltech.
 - when BTS2.0 is released, we will come up with a unified worker proposal

[Thom]

Welll said Nico. I have already switched the payroll to send you 70% every 2 weeks. Let me know if there is anything else you need. Meanwhile I will continue to help graphene testing where I can.

And yes, thank you everyone for your continued support!

[BunkerChainLabs-DataSecurityNode]

Fantastic 

Just like to get some clarification though on one point.

Should we no longer vote or the delegate  btstools.digitalgaia and put all our support into the verbaltech delegate to continue supporting you?

Thanks so much!

[wackou]

An update on the situation:

I am now back from holidays, and ready to kick into gear for another year!

I have talked with Thom yesterday, and as previously mentioned here, we will now work together with the aim to enhance and improve the BitShares network security. Mostly what this means at the moment is that we will start implementing the backbone proposal as described here: http://digitalgaia.io/backbone.html  and set up various VPS instances spread all over the world, with the aim of getting global coverage, low-latency, strong connectivity and decentralization of the providers to ensure robustness. Thom has already started setting up some nodes, and I will follow suit soon.

The first few things I intend to work on are:
 - adapt the bts_tools to be able to manage backbone nodes
 - setup and configure an actual backbone for BitShares 0.9.x
 - adapt the bts_tools so that delegates managed by it connect exclusively to the backbone, if online (this is the part that provides DDoS protection to the delegates)
 - setup a webpage that show the real-time online status of the backbone nodes

I will be leading the development for the bts_tools, but Thom will help me when/where needed, and will be testing also. Eventually, we will be managing the backbone between the 2 of us, so given that we are in 2 different timezones, this means we can ensure close to 24/7 monitoring of the backbone nodes.

Another task will be to look into graphene, port the bts_tools to be able to work with graphene clients and have them ready for when the official BitShares 2.0 chain launches.

As for the delegate pay, we agreed that Thom will be sending me 70% of the pay from his delegate, and will thus keep 30%. I will use the funds to pay for VPS instances and time devoted, and leftovers (if any) will be kept to run seed nodes / backbones nodes for when graphene is launched.

All in all, this is a rehash of my previous proposal + Thom's previous posts, which shouldn't surprise lots of people. We plan to submit a new, revised joint proposal for when BitShares 2.0 launches, but at the moment we feel like we want to spend more time coding than campaigning for funds, especially given that bts2.0 is not that far away and lots of things are going to change to the delegate/worker structure when it is released. We also have some more ideas that we want to flesh out nicely in a new proposal rather than rush them now. I will post further updates in this thread now that delegate.verbaltech is the delegate funding development, but will still post relevant updates to the bts_tools in my original thread here: https://bitsharestalk.org/index.php/topic,12534

Thank you everyone for the support!

[wackou]

Hi all,

just a quick post to tell everyone that I think the partnership with Thom makes sense to me and we will write a more detailed proposal together. I am still travelling with little internet until next Monday so you won't hear a lot from me until then, but expect more next week when I am back and fully operational again.

[Thom]

I like the idea .. ..
keeping you both on my slate ..