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 - theoreticalbts

Pages: [1]
1
DevShares / DevShares ideas to consider before launch
« on: December 17, 2014, 09:25:21 pm »
We're working on implementing DevShares in the near future.  My original proposal for DevShares (under my old account, drltc) had the following two features.  AFAIK these are not currently slated for inclusion in DevShares, but I wanted to bring them up before launch:

 - A terminal block as well as genesis block.  In other words, clients are pre-programmed from Day 1 to halt on a fixed date/time.  The plan is to take a snapshot of the final state and to initialize a new genesis block, and/or hardfork(s) which postpone the halt date.  The reason for this is to have a better end-of-life process allowing the code for retired mechanics to eventually be removed (instead of having to stick around forever in order to correctly interpret older blocks).

- Value backed by inflationary BitShares.  My original proposal had a promise to issue inflationary BitShares to the terminal snapshot with a BitShares hardfork.  For a variety of reasons, I no longer think that is workable.  Perhaps we could simply have a 100% BitShares delegate who promises to run both BitShares and DevShares clients and issues regular distributions to DevShares balances according to some algorithm?

2
First of all, as stated in the sticky title, all delegates should upgrade to release 0.4.27.1.

For increased stability, delegates can download this file into your .BitShares directory before reindexing.  It's at raw.githubusercontent.com/BitShares/bitshares/cp1286500/checkpoints.json on Github, (sorry I can't post a proper link because this account's still newb status).

You can also use the checkpoint file after upgrading to 0.4.27.1 if you reindex manually with the --rebuild-index command line option.

The file contains checkpoints every 1000 blocks for the past few days.  Since 1000 blocks is shorter than the undo buffer in the most recent release, you should be able to recover automatically from any recent fork before block 1286500.

Pages: [1]