I appreciate all that you guys have done. I would also like to meet you all in a Mumble session - but I can understand if that is not practical.

Will be voting for you.

Thanks, we appreciate it!

I'm sure at least some of us will speak on a mumble session at some time (most probably Eric or I, since we're the only two native English speakers). I do listen in on some of the sessions, but I haven't spoke up yet as we're usually working on low-level concerns that aren't of general interest to bitshares users (unless it's a bug they're experiencing, of course).

BTSNow represents four developers from the BitShares team. Our github handles are dnotestein, efrias, gregorsz, and Gandalf-The-Grey. Eric and I (Dan Notestein) are located in Blacksburg, VA, Greg and Gandalf are located in Poland.

We're not the most talkative guys in the forums, so it's probable you will not recognize our names, but we've been with the Invictus/BitShares project since almost the first code was written and I was Dan's first programming hire. ByteMaster and I first met when I was doing consulting work with his previous employer, and after he told me about his early ideas for BitShares, I was excited to join his project. I already had my own company, SynaptiCAD, so we needed to work out details of how this could be achieved, and ultimately that lead me to bring some SynaptiCAD programmers on to the project, and have others take over most of my responsibilities at SynaptiCAD.

During our time in the BitShares ecosystem, we were closely involved in the initial architectural design of the overall bitshares client, and we were entirely responsible for the design and implementation of the peer-to-peer networking code for bitshares, the JSON-RPC API generator that enables developers to rapidly add new API calls, and the test regression system for verifying the functionality of API calls. We've also fixed numerous challenging bugs in the command-line interface and the networking/fiber library "fc" that the entire client depends on heavily, speeded up the processing of transactions during blockchain validation, and most recently rewrote the logic for handling forks in the blockchain. As Bytemaster succinctly put it in today's meeting, we're "the guys that solve hard problems".

We've been operating a private jenkins build server that builds Linux, Mac, and Windows versions of the software, and we've been responsible for creating the windows binary builds that have been published on github for distribution to end users. All recognized BitShares developers will be given accounts on our Jenkins server to aid them in their development work.

We also plan to host the TestNet seed node on an account that will be accessible to all developers, so that they can access the seed node logs for debugging purposes and fire up a new version of the TestNet when they need one.

We're currently concentrating on solidifying the mechanisms needed to support on-ramps/off-ramps for both cryptocurrency and fiat. As part of that work, we also plan to incorporate a new company that will operate an on-ramp/off-ramp for BitShares so that users can easily move money into and out of the BitShares distributed exchange network. Our goal is to have an operational on-ramp/off-ramp within the next 1-2 months, initially supporting only cryptocurrencies, with fiat to follow not too long after. We have two major design goals for our on-ramp/off-ramp: make it as easy to use as possible and even more importantly as secure as possible, since history has clearly established that exchanges are "high-value" targets in the world of cybercrime.

To date, we've been paid by SynaptiCAD, which itself was paid in BTC from AGS funds, then converted the BTC to currencies appropriate to each developer. Like the other developers, we're now switching to a model where we're paid directly by the blockchain instead of via AGS funds. However, we plan to continue using a single company to collect the delegate fees and pay developer salaries, so that the developers are shielded from having to deal with the tax complications individually.

Initially we plan to run 4 delegates to collect fees that will go towards paying the salaries of our developers. This doesn't fully cover our salaries by any means, but SynaptiCAD received a 3 million BTS bonus that will the cover the shortfall for a while. Beyond that point, we hope to begin deriving supplementary income through the operation of the exchange. It's also entirely possible we will need to run more delegates at some point, but only time will tell. Personally, I'm hoping that we'll see a nice rise in the value of BTS as we continue to improve our development and marketing processes and demonstrate the value of the BitShares network to the rest of the world.

Please support us by voting in our delegates:

delegate-dev1.btsnow
delegate-dev2.btsnow
delegate-dev3.btsnow
delegate-dev4.btsnow

Finally, on behalf of our entire team, I want to wish everyone a happy and productive new year in 2015!

As David Brown speculates, the problem is the Qt GUI client is detecting the existence of that lock file, which makes it think there is another copy of the program running. This lock file should be deleted when the program exits normally, but it can stay around if the client terminates improperly. The best way to eliminate this error is to delete the lock file, then launch the client again.

Hotfix release v0.4.27.1 for users that are currently having trouble switching to the correct blockchain fork:
https://github.com/BitShares/bitshares/releases/tag/v0.4.27.1

I strongly recommend that all delegates switch to 4.27.1 ASAP as 4.27 has a known bug that can potentially prevent it from switching back to the proper fork.

@maqifrnswa, Try https://github.com/BitShares/bitshares/releases/tag/v0.4.27.1

Update, use client below for best results:
https://github.com/BitShares/bitshares/releases/tag/v0.4.27.1

Some  (but not all) 4.26 delegates appear to be going off on a minority fork, so please upgrade to 0.4.27 as soon as you're able (especially if you're not on the majority fork).

Also, if you're on the wrong fork, you will probably need to delete your local copy of blockchain and resync.
Also, as per msgs further down in this thread, if you fail to get on correct fork, you can force it using this method from testz:

If as delegate you have a problem to sync to right chain, you should move to 0.4.27.1 and add following lines to checkpoints.json at data directory:
Quote

      ],[
        1279500,
        "488313d2c1c85bdec117bac0379f7b17f7cfbed3"
      ],[
        1283300,
        "cef871ef96c687b4841b02a7643c2a90d6c46bd1"
      ],[
        1283590,
        "d5265058f7be7d5cf1b496bbaa9b9deaf8cfbe00"
      ]


I mark as bold the lines which present in original file.
After this you should re-index the database.

Our delegate is running fine, but it is consuming a lot of virtual memory (2.3GB, but doesn't seem to be increasing) during initial sync. My best guess is that the people with problems are swapping due to insufficient memory. We already suspected a leak in the previous client during syncing (last client required 1.6GB on windows for initial sync).