I'm feeling uncomfortable about this.  I think that small stakeholders should be able to have a good chance to mine, as well as a good incentive to keep their nodes up and running.

As I understand it, the only way to earn stake now is to mine a block with one of your own transactions in it.... a transaction which destroys your own CD.  So for a small stakeholder, it's a one-shot deal; you save up your CD, then make a transaction (could be back to yourself), and hope that the CDD earns you the block.

I propose a second metric, Stake Days Destroyed, to go along with CDD.  This would also impact the Difficulty.  As SDD goes up, difficulty goes down.  If I hold 30 shares for 30 days, my SDD is 900.  This is the equivalent of somebody with 900 shares holding for 1 day.  The key part is this: My SDD only drops back to 0 when I actually mine a block.  The SDD essentially help the smaller guys "cut in line" by being able to mine easier when they have been saving up their Stake for a long time.  And since Stake is only reset to 0 when a block is mined, it can be transferred from one address to another without being reset.  The stake travels along with the shares and can be additive.  If I've got 0 stake (I just mined a block with my shares) but I buy shares from you, and your shares have stake built up, I receive that stake when I receive the shares, and my chances of mining a block go up again.

I don't know, I just feel that fundamentally, PoS mining should not result in the large stakeholders getting ALL of the blocks.  The chances should be proportional to the stake held by each.  If I own 1/100,000 of the shares, I should have a 1/100,000 chance of mining a block (unless I do something to ruin my chances somehow, such as not allowing my stake to mature or whatever).

I get the idea of TaPoS as encouraging transactions rather than sitting on shares and never trading with them.  But if the only way to earn PoS is to save up your CD for the big shot transaction which is likely to win a block, and to conduct that transaction once per year, this will incentivize perverse behavior as well.  Just leave your client off most of the time, fire it up once per year, make a transaction from one address to another, and then turn it off until next year.  Doing basically nothing to secure the network.

We want to incentivize making transactions, and also incentivize having client nodes running and mining.  I feel like the system as presently described (as well as I understand it, which granted is not fully) does not incentivize the little guys to mine, which leads to concentration/centralization of mining power, which is exactly what we're trying to get away from by moving from PoW to PoS.

EDIT: To elaborate a little more.  Stake is associated only with the shares, not the shareholder.  If I have 2 shares, I mine a block, they now have 0 stake-days, their stake-days start to build up.  If you transfer to me 2 shares, that have not mined a block in 5 days, they now have 10 stake-days (5 each).  Now I have 4 shares, 2 of which have 0 stake-days, and 2 of which have 10 stake-days.  If I send them all 4 at once, they can act as though there are 10 stake-days destroyed as part of that transaction.  Or if I send 1 share to somebody else, I have to pick whether I want to send a 0-stake-day share or a 5-stake-day share.  The system will, by default, keep my highest stake-day shares and send the lowest stake-day shares.

Even when my stake-days have built up, I am not incentivized to spam the blockchain with transactions sending shares back-and-forth from one address to another in hopes of mining a block, because the CDD still contributes the difficulty, and very small CDD will make the difficulty pretty high.  I am not proposing to eliminate CDD, only augment it with a parallel system that works similarly.

My original idea was for a rather strict character set but this is something that needs to be discussed thoroughly.

You should interpret my post in a way that still makes sense if you actually disallow periods in the name. That is, I was making a general argument about the  role of TLDs and how "avoiding collisions" using TLDs is an artifact and not what would happen naturally if you remove the effect of the laws that are entangled with the current system.

Yes.  But my original reply was not so concerned with the "legalities" of .org vs. .com etc., but moreso that it allowed for a sort of self-sorting and the multiplication of the namespace across however many TLD's there were.  (Which, recall, back in the beginning there were only a few; .com, .net, .gov, .edu, .org, .mil, and .arpa.)  And that there could be multiple entities which would reasonably desire a given domain name, not only for "squatting" purposes.

Let's put it this way: DomainShares-the-namespace needs a name. No matter what, there is one DomainShares-the-namespace, no matter how you slice it.
Bonus challenge: Make it under 4 characters.

Ok, I again suggest:

.nm
.key

I think .nm is pretty recognizable as the root characters of name/nomen/nombre/etc. which means "name" to most Western languages, even non-Romance languages such as German and Russian.  I guess it is a problem in that it is also the abbreviation for a US state (New Mexico) and there already exists the 2nd-level domain .nm.us, which is used by official government entities in New Mexico.  I could see some potential for confusion there.  Perhaps .nom as an alternative?

I also think .key is pretty good, as a tie-in to Keyhotee and the idea that this system is maintained by way of public/private cryptographic keys.  It also has good mental images: a key unlocks a door, etc.  However, it is probably not as internationally oriented as .nm.

EDIT: I will also say, if the topic is "discussed thoroughly" then you might well end up with a design-by-committee, which doesn't work very well.  I would say, either start with the existing DNS rules and relax them somewhat; or allow all of UTF-8, and then restrict it somewhat.  Going a middle route of picking and choosing, and allowing this but not allowing that, is going to lead to nothing but confusion.  Think through all the options, but go with your gut, and don't allow it to get more complicated than you can handle.  Internationalization is notoriously difficult to work on.

TLDs only exist to say, "which rules control this namespace"

I understand, and I get why this is a benefit of decentralized DNS, but my real point was simply to state that conflict over a given name within a given TLD does not merely occur due to "squatting" but can also occur due to legitimate conflicts not predicated upon bad actors.  These conflicts will arise in any system with a single TLD, and the existence of multiple TLD's can mitigate this problem somewhat.  If you've got to have a single TLD, might as well have a few, IMO.

Meaning just "the" Bitshares TLD, or various TLD's that might be useful if implemented?

.nomen
.nm
.key
.ident
.comp

Implementing KGW or changing the retarget interval will require code to be changed, and everybody to download new clients.  Plus the stigma of a "hard fork".

A matching bounty on each block mined, up until the difficulty reset, would require just a bit of accounting work.  (And ~3500 PTS.)  The bounties could even be paid out over time, say every 100 blocks or something.  Pools would have to make some changes, but they would just have to keep track of amounts credited to miners, and double them when they receive the bounty payment.

Of course, that doesn't solve the problem long-term; the next DAC snapshot announcement will undoubtedly bring in a lot of new mining power, and after the snapshot, price will drop and the miners will go away again, and the loyal miners will be stuck with the high difficulty again.

If KGW is flawed, then just change the adjustment period to some lower number of blocks.  It's not exactly hard.  Ideally, the block retarget period would be specified in only one place in the code. 

As an alternative, the coin MazaCoin (MZC) launched with a 4-block retarget, based on the last 90 blocks.  It seems that this would be easier to implement and possibly without the KGW weakness, which seems to be based on the fact that KGW retargets every block, and is based on a smaller number of recent blocks (the most recent 11 blocks, IIRC?).

On the other hand, it seems that the KGW flaw is likely more exploitable in coins with fast block times.  There are lots of scrypt alts employing KGW that have a target block time of 120 or 60 seconds.  So time-malleability (the fact that a later block can have an earlier timestamp) can come into play a lot easier than with a coin with longer block times.

My understanding is that Invictus is going to be posting bounties on a continuing basis.  They are working on multiple DAC ideas which will keep them busy for several years; and all of these ideas will need code, marketing materials, etc.  But even after DACs are launched, they might want more marketing materials, or the creation of an Android wallet, or something else to help grow the ecosystem around that DAC.

All times are in GMT, Greenwich Mean Time.  You can check the current GMT by googling "GMT".  If your PTS ownership, or your AGS donations are reflected in the PTS blockchain or the BTC blockchain as of the last block mined on or before 23:59:59 GMT on February 28th, it will be counted.  If it is in the next block, it will not be counted.

At the time of this post, there are slightly under 20 hours remaining before the snapshot.