@theoretical: Is there a reason why you (and nikolai and adam.follow-my-vote and nathan hourt and all the init delegates controlled by i3 (aren't they?)) do not produce price feeds?

Speaking for myself only, I plan to start publishing feeds, but with the holidays I haven't had time to get a price feed script up and running.

Add to that:

- I want to fully audit any script written by others before using it, as it will have access to my delegate's private key.
- I don't want to run exactly the same script as everyone else, as the feed will be more robust if each delegate uses their own data sources and methodologies.  Thus, I am copying bits from several different scripts floating around.
- I want to be sure the script is tested and rock solid before I let it run unattended.  Not publishing a feed at all is better than providing incorrect or out-of-date feeds.

You can find more details elsewhere, but yes, if collateral is insufficient to buy back the assets, the system "owes" dollars it doesn't have.

The "correct" thing to do is stop paying yield and use USD from the yield fund to repay the "owed" dollars, i.e.:

- The short auto-buys and burns as many USD as it can with its collateral at the best price
- In this scenario, that won't be enough USD to cover the position
- The system burns additional USD from the yield fund to make up the difference

Thus the amount of the USD burned ends up equal to the USD that were created when the short position was opened.

I'm not sure if this was actually implemented, or if it was only discussed.

Have you read the devshares announcement / mission / directives? https://bytemaster.github.io/update/2014/12/19/The-Value-of-DevShares/

Yes.  From the announcement:

we really do need and want DevShares to have some real value because only through having real value will a distributed user base actively test it; especially the market features. You cannot test BitAssets throughly unless the collateral has value.

Buying and burning DVS ensures that DVS will have non-zero value, because those seeking to get out of DVS will be able to find a buyer (assuming the delegate sells BTS for DVS using a no-reserve auction).

Can we elect a delegate to buy and burn my personal testnet shares?

Yes, provided you have a convincing reason that doing so is a good value proposition for BTS holders.

bytemaster's post outlines some reasons BTS holders want DVS to have value.

Who is DrLTC now?

"theoretical" I believe

that's me -- just look at the mod section of this board if you forget

I think a way for delegate to perform maintenance is needed. This should keep delegate's votes and position but transfer the delegate's slot to another delegate.

I agree this is needful.  A delegate may very well decide to resign from their position and stop being a delegate, due to a change in life circumstances, business circumstances, regulatory / legal issues, etc.  They currently have no way to voluntarily do this except by trying to get in contact with voters and convincing them to vote for someone else.  We need a signed message that says "I no longer want to be a delegate, please do not consider me as a candidate in the delegate election."

Temporary resignation for maintenance should be discouraged; this is what manual failover is for (have client running on two nodes, wait for block, then stop block production on the current node and start it on the backup).  Since this is 2014 (soon to be 2015) and you can rent VPS's by the hour from many providers, the costs of having a backup node online for a few hours while the main node undergoes maintenance is small.

They will get fired automatically in a future release.

So how is automatic failover supposed to work then?  Suppose a backup node loses contact with the main node (the main node doesn't respond to any network service, ping, RPC, ssh, etc.).  Then the backup node can't start producing blocks because it can't distinguish between (a) the main node is down and (b) the network path between the backup node and main node is down.  Thus, producing blocks on the backup node might cause a fork.

I'd like to make the following recommendations for delegates then:

- If running automatic failover nodes, DO NOT start producing blocks unless the main node can be CONFIRMED dead (i.e. you can get into the VPS admin function and tell the machine to reboot, get into SSH and see the process is gone, etc.)

- Best practice is to just have one node with automatic failover wrapper script that monitors the connection and kills / restarts the process, re-unlocking the wallet, if RPC dies.

- Put the client in your /etc/init.d, including putting your wallet password on permanent storage, so rebooting the machine should start the delegate automatically.

Of course this means your key is exposed to anyone who has physical access to the storage.  For this reason:

- Use active key instead of owner key and have a script that withdraws pay several times a day

- Use block production key when that functionality is released

A delegate could use all of their pay to buy dev shares.   Easy.

This gets from me, provided the delegate burns the DVS from a published DVS address allowing anyone to audit that output / input (DVS destroyed / BTS issued) is close to the market DVS / BTS exchange rate.

This is similar to my original proposal for DevShares which had DVS backed by inflationary BTS.  But my proposal divided the BTS among all DVS holders, while bytemaster would only issue it (indirectly via sale) to those trying to get out of DVS.  So his proposal gets much more mileage (in terms of DVS valuation boost) for a given amount of BTS dilution

Of course there is no free lunch and bytemaster's approach sacrifices liquidity (if people are getting out of DVS faster than the delegate can dilute new BTS, the DVS / BTS exchange rate will move, whereas having inflationary BTS reserved for all DVS holders would keep it stable.)

I'm the forum user formerly known as drltc [1].  I'm a full-time I3 team member and I'm seeking to run a 100% delegate, dev0.theoretical.

I've been a member of this forum since early days, participating in multiple pre-launch technical discussions.  One of my proposals eventually evolved into the delegate system, a fundamental part of the BitShares architecture that differentiates us from most of our competitors.

I'm a full stack software developer capable of working on any part of the BitShares client.  I diagnosed stack overflow as the root cause of intermittent crashes and instability in the BitShares client by using GDB to step through assembly instructions one at a time.  I've added several RPC's and some other functionality, audited others' commits, and I've both filed and fixed quite a few Github tickets.  I'm quite comfortable with computer science, mathematics and economics, which helps clarify my thoughts on the theoretical aspects of what we're doing.  I'm also a reasonably competent at JavaScript and web stuff (although I'm not always totally up-to-date on the latest technologies and best practices in the area).

I'm currently focused on testing, in particular addressing technical debt in our testing infrastructure.

My main area of interest is design and implementation of core blockchain features.

The DevShares name and concept was my idea (although what we're actually implementing ended up being a little different from my vision).

I could probably think of some other qualifications I have, but I think that's enough -- if you haven't decided I deserve a 100% delegate by now, I don't think you're going to.

[1] https://bitsharestalk.org/index.php?topic=12367

yup thats what i mean ..! if you deleteyour new account i can rename your old drltc account to theoretical, not a problem, i can change the username ... if i should do .. you'll get a mail, with a new password, afteri have done this ... ping me if i get your GO ...

Pinged, and the name change is implemented and live.  for getting me out of newbie hell (required CAPTCHA and link restrictions for new members)