I have come to the conclusion that my username is undesirable for a variety of reasons:

- As an I3 team member, it seems rather unprofessional to advertise a dying competitor with every post.
- My name implies an academic credential I do not in fact possess.
- There are plans to make short TITAN names expire some time in the distant future unless a heavy fee is paid, and I do not want to pay it.
- When I generated the owner key for the drltc TITAN account, I did not take paranoid security precautions since I was only planning on being a casual user and occasional contributor.  Now that I am planning to be a 100% delegate, creating a new username gives me an opportunity to better secure my owner key.
- I will be stuck with whatever delegate name I choose, unless I want to pay the fee to register a 100% delegate multiple times.

Notwithstanding the implication of my click-baity post title, I'm merely retiring the drltc username.  I'll still be an I3 team member and continue to heavily participate in the community just like before, only I will have a brand new username!

Here it is:

    theoretical

For websites where this username is not available, I will be:

    theoreticalbts

I have already registered TITAN and forum accounts for both of these names.

To prove the legitimacy of this message, I will sign the sha256 of this message with drltc TITAN account.

When I chose the drltc name, I had no idea Bitshares would be as successful as it has been, or that I'd end up playing such a huge role in this project.  At the time, BitShares was just another interesting altcoin along with Litecoin, Primecoin, Dogecoin, etc.  The new name marks an increased level of maturity for both the project and my contributions to it.  Great things are ahead for BitShares in 2015!

    drltc, December 16, 2014

A Markdown version of this post is available at https://github.com/drltc/bitshares_toolkit/blob/drltc-lastpost/drltc-lastpost.md with better formatting and signature verification. 

How to verify the legitimacy of this post
-----------------------------------------

Download and verify the file:

    wget -O - https://raw.githubusercontent.com/drltc/bitshares_toolkit/drltc-lastpost/drltc-lastpost.md | tee drltc-lastpost.md | sha256sum

You should verify the content of `drltc-lastpost.md` created by this command matches the forum post, and the sha256sum will be the following hash:

    489af05fa35a928226294e70b7c458af256479310f70c223c894392fec6b4b7e

Put the hash into this command in any BitShares client:

    blockchain_verify_signature drltc "489af05fa35a928226294e70b7c458af256479310f70c223c894392fec6b4b7e" "1f60baa9b38e1bf4b471700f59f174d09c84ca353a3cd5c674c282eeac31cc8d6054e66ca3b4b5a215b524e23d5067fd04a6ed4fc6072d93097f9dfdf7bfaa9918"

The command returns `true` indicating that the owner of the `drltc` blockchain account has signed the content of this post (the really long hex string starting with `1f` is the signature data).

for ICQ (not serious, this is a joke)

However, the 3 of us that put together the upgrade all still managed to completely overlook this problem due to the stress of trying to fix the malleability security issue as fast as possible. The moral of the story is--security issue or not--we need a better process for live upgrades:

Quote from: bytemaster on December 12, 2014, 07:14:04 pm

We are reviewing our options, but the conclusion is clear.   DevShares needs to come out as soon as possible because it is the most likely way we would have caught this bug.

This fix was rushed out because once the existence of the security flaw was publicly disclosed, we felt under extreme time pressure because any technically competent attacker reading our public discussions would have been able to use the unpatched flaw to do serious damage.

We need to do a better job of telling all internal developers and community contributors not to discuss security vulnerabilities over public channels until a fix is deployed.  A little more caution along these lines would quite possibly have resulted in a patch developed over a longer time frame, with more thorough testing, under less pressure.

The next time a security vulnerability is disclosed before a patch is available, we need to consider more carefully the risks of a botched fix when deciding how much time to spend writing / testing a patch.  We don't want the fix to cause more damage than the exploit.

We also need to address technical debt in the testing side of things.  DevShares will help; so will more tests and improvements to our testing infrastructure.  I've been working on the latter.

I think there's little value in assigning blame to particular people.  I'm pretty sure that those who screwed up (myself included) have realized it and have figured out what they need to do differently next time.  Overall I'm not even sure we can attribute human error as the root cause, rather it's lack of a well-defined process for dealing with security vulnerabilities.  Also, a  process for code review and testing of release candidates would be useful.

is their  an easy way to tell if you are on the right chain/fork?

You can check block hashes like this:

>>> get_block 1246470
{
  "previous": "68b7e003ca08d50843faaddcf696cfff1954ede3",

>>> get_block 1246901
{
  "previous": "b5214c1bc914ea5da6c1bb8f774d07f12b85dbe2",


There will be a separate bond market for guaranteed returns.

Do we have a spec for this yet?  Will this be a 1.0 feature?

The previous post could be expressed more concisely as follows:  For each balance b_i, we want to keep track of dividends_due(b_i), how much b_i is allowed to receive from the dividend pool.  However, if we do that, for N balances, issuing a dividend will result in O(N) database updates which is way too resource intensive to be practical.

So I propose tracking dividends_paid(b_i) instead, which is cheap since it only updates when the balance owner decides to withdraw the dividend.  With a few macro stats which are also cheap to update, we can then compute dividends_due(b_i) from dividends_paid(b_i).

Quote from: joele on December 02, 2014, 10:51:57 am

Quote from: kokojie on December 02, 2014, 04:18:21 am

Can Issuer pay dividends yet?

Mass payment module.

This would be very expensive to implement a primitive for.   You can send out 1000 transactions or use a "send many" to group them into manageable sizes.   Having an operation do that would be too expensive.

No it wouldn't.  You could do something similar to one of my yield proposals.  For each distribution event, put the BTS / BitAssets being distributed into a "pool" specific to that distribution.  The pool just contains a balance for each BitAsset type being distributed, plus a record of the time at which the distribution occurred and the quantity of UIA in existence at that time.

Then every time a balance moves, you check if there have been any distributions since the last time it moved.  If so, then the transaction's allowed (or perhaps even required) to withdraw funds from the pool equal to the UIA balance which is moving, divided by the total UIA in existence at the time of the distribution event (which was recorded as part of the pool record).

We should make transcripts of the interviews available as well.  The more sources that have high quality text-based information about what we do, the more ways people have to find us by Google.