pts-dpos / pts

PTS DPOS and sharedrop toolkit

PTS (aka The Currency Formerly Known As Bitshares-PTS)

Originally invented as a means to create a fair initial distribution for the BitShares (BTS) DAC, PTS has matured and is now a currency on its own. The objectives and core values of the new PTS are

• simplicity - PTS is delegated proof of stake (DPOS). It is a pure implementation of the core DPOS protocol without the application-specific functionality of the many profitable DACs that will be built on top of it. In this way, PTS is the foundation layer of the BitShares ecosystem.

• openness - PTS is not only open-source, but also open strategy. PTS promotes open development and contribution to the BitShares platform by third party developers and investors. At the same time, PTS is agnostic to the features, technology, and business strategy of any particular DAC that is built on top of it. PTS is the Switzerland of DACs.

• collaboration - PTS will be built with extensibility and collaboration in mind. In addition to serving as the common core of profitable DACs, PTS will also serve as a launching pad and resource for developers of new DACs. In this way, any contribution to PTS is a contribution to the BitShares ecosystem. The mantra of PTS is: easy-to-use, easy-to-build, and easy-to-fork.

• stability - PTS is a stable, non-inflationary, and fairly distributed token. PTS is not a business and is not designed with the objective of maximizing profit. As the business environment changes, application-specific DACs will have to evolve to maintain their competitive advantage. PTS may also evolve, but only with a slow and steady hand that serves the interest of PTS holders and these core values.

pts's Issues

Looking for initial delegates

See http://pts.cubeconnex.com/index.php?topic=48.0

Base off different branch

This may not matter anymore as you may have already deleted the relevant code, but you should base this off of develop or toolkit branch here: https://github.com/BitShares/bitshares/branches/all

develop is where all new development happens and contains no hardfork or other special case code required for the live chain. bitshares and master branches are for the live network and contain all that special code. toolkit is the most recent ancestor between develop and master, and represents the most stable, clean code we have.

Also, I encourage you to submit any bugfixes or other good changes upstream. Thanks!

no-cache in HTTP RPC response

See bitshares#1150

Import remaining keyhotee ids

Manually imported 134 keyhotee ids of 5 or more chars from https://github.com/BitShares/bitshares/blob/dda879480d0477143c514253c31a57ff8d1a5ab6/libraries/blockchain/genesis_bts.json using

head -n 1330 genesis_bts.json | tail -n +544|grep -A 2 '"name": *"[^"]{5}'|cut -d" -f 4|grep -vE '^(--|)$' >/tmp/names+keys
end=; while [ -z "$end" ]; do read name || end=1; read key || end=1; echo wallet_add_contact_account $name P${key#B}; echo wallet_account_register $name misc; done </tmp/names+keys

(google+coffee are reserved, wackou+testz already registered)

TODO: Import remaining names

Create PR for wallet_import_by_signedmsg into upstream

Adjust reg fees for short account names

TBD

API server

We'd like to have a public (or at least open source) API server for accessing the blockchain. This would enable lightweight clients, for example, similar to this: https://bitsharestalk.org/index.php?topic=11902.0

Consensus algorithm updates

https://bitsharestalk.org/index.php?topic=12159.msg160487#msg160487

Increase GENESIS_VOTE_PER_MILLE

...to 80 or so (test before launch)

DNS seeder script publishes private IPs

...from 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
Add a filter.

Pull escrow feature from upstream

Adapt fees for next chain reset (dry run 2?)

blockchain/config.hpp
blockchain/pts_config.hpp

Scanning is very slow

After turning the client off for a while an back on a couple of hours later it quickly loads the missing blocks. But after unlocking the wallet it takes ages to scan the new blocks for relevant txs.
Initial analysis shows that the process is very heavy on IO with lots of sync() calls.

Client tries only on IP initially instead of all seed IPs

See http://pts.cubeconnex.com/index.php?topic=52.msg440#msg440

Apparently this is a regression.