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.


Topics - dannotestein

Pages: 1 2 3 [4]
46
Stakeholder Proposals / Voting with the command-line client
« on: January 07, 2015, 04:10:06 pm »
I recently had the need to vote with the command-line client, and I felt that the documentation was a little lacking in this area. I've updated the related pages in the wiki for now, and plan to update the "internal" API documentation in the client itself later, so if you use the command-line client, please review these pages and let me know if there are any points that need clarifying in the procedures for creating a slate or casting a vote:

http://wiki.bitshares.org/index.php/Delegate/PublishSlate
http://wiki.bitshares.org/index.php/DPOS/ApprovalVoting#Your_choices_for_transactions

47
Stakeholder Proposals / 100% Delegates Proposal: BTSNow Developers
« on: January 05, 2015, 10:04:59 pm »
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!

48
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.

49
General Discussion / New fork resolution algorithm in bitshares_toolkit
« on: December 10, 2014, 08:35:08 pm »
Hi sparkles,

I've pushed a rewritten fork resolution algorithm to bitshares_toolkit repo (https://github.com/BitShares/bitshares/commit/96e00d39e8e41163a93310db369cd8c490e74589).

Originally I planned to make patches to the old algorithm, but I found it had serious flaws both in resolving to the longest fork in all cases and in terms of performance, so I went for a clean rewrite. I have performed various manual tests on the new algorithm which all passed fine. Unfortunately, a DPOS chain doesn't present a lot of easy tests for fork resolution code (not many forks get generated), but I still strongly recommend you try the new algorithm on the sparkles blockchain now. Please let me know if you find any problems with the new algorithm and I can assist in resolving them.

Pages: 1 2 3 [4]