1
DevShares / Re: DevShares ideas to consider before launch
« on: December 17, 2014, 10:43:21 pm »The same as Sparkle one?
Toast is working on the blockchain state dump right now. Perhaps he could give us a block number?
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.
Pages: [1]
Toast is working on the blockchain state dump right now. Perhaps he could give us a block number?
2
DevShares / Re: DevShares ideas to consider before launch
« on: December 17, 2014, 10:15:21 pm »Please allow me to ask one more question. When is the BTS snapshot date? Nov 5, as like AGS and PTS?
December 14.
3
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?
- 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?
4
Stakeholder Proposals / Delegates: Please upgrade to 0.4.27.1; use new checkpoints.json if still stuck
« on: December 17, 2014, 08:52:44 pm »
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.
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.
5
General Discussion / Re: lot of news and no video or explaining letter
« on: December 17, 2014, 08:44:15 pm »There's need to be an official blog post on the site explaining the relationship of these different projects to BitShares. That will help eleviate some of the confusion for newbs (and regulars too)
Yeah, we're starting to be old enough that we have a lot of things which need explaining.
6
General Discussion / Re: Brian Page (MktDirector) Is Moving On
« on: December 17, 2014, 08:42:37 pm »I haven't really been following the marketing side of things, so I'm not sure about the significance of this..
7
General Discussion / Re: October Newsletter - Halloween Edition
« on: December 17, 2014, 08:34:12 pm »It's everyone on Nullstreet, I'm just lucky enough to help pass along the message. We're about 90% done, you can take a look at our work here:
Rough Newsletter PT 1 - Dec 18 Submit
Rough Newsletter PT 2 - Dec 18 Submit
Rough Newsletter PT 3 - Dec 18 Submit
It's hidden behind some subscription wall and apparently registering new users requires a manual step. Can some admin approve me?
8
General Discussion / Re: drltc's last post
« on: December 17, 2014, 08:27:37 pm »Unfortunately it's stuck me in some kind of newb hell until I get more posts. Apparently SMF has no way to disable that unless you lower the global threshold, but spammers will find you quickly...
9
Stakeholder Proposals / Re: --> All Delegates: Please upgrade to 0.4.27 ASAP <--
« on: December 17, 2014, 05:43:39 pm »Sounds juicy!
In this case, it's more of an abundance of caution. I personally don't think this bug is exploitable (or at any rate that exploitation will be able to do anything worse than what's already happening naturally). But we're still waiting until the fix is released to discuss details.
10
Stakeholder Proposals / Re: --> All Delegates: Please upgrade to 0.4.27 ASAP <--
« on: December 17, 2014, 05:22:15 pm »We think we understand what has been causing the network to fork repeatedly over the past 12 hours or so. We're currently working on implementing a fix. We prefer not to publicly explain what's going on until the fix is released.
11
General Discussion / Re: drltc's last post
« on: December 17, 2014, 02:08:56 pm »For the record, I had no idea that drltc was actually dr. ltc - I just assumed it was a string of letters, like someone had mashed the keyboard
As a senior English reader , it is weird that I didn't notice drltc = DR. LTC .........
I had to explain this to bytemaster as well. Maybe the significance of the name is only obvious to fans of Mega Man...
12
General Discussion / Re: drltc's last post
« on: December 17, 2014, 01:16:19 pm »why not just change you forum name here to theoretical isntead of creating a complete new account!?
Because I wasn't aware you could change your username until this post, and I have no idea how to do it. Usually usernames are immutable. And now I wonder if there will be problems because my new account has already registered and started posting?
IMO your should address your drltc posts to theoretical so people can see what you have done and contributed so far... just my 2 cents
How exactly do I do this?
Pages: [1]
