You talked, I listened
你说话了，我听

https://bitsharestalk.org/index.php?topic=6647.0

To be clear:  The allocation will never change in a way that takes pre-committed equity away from anyone except delegates. So this is a "one-way" change. MYSTERY sharedrop was not defined so we can take theirs.


New proposal:

20% AGS
20% PTS
5% MYSTERY sharedrop
5% dev preallocation  -  split among 4 or 5 trusted organizations (i3, das, dacsun, bitsuperlab, maybe more)
50% delegates  (about 22.5% in first year, or 45% of remaining pool each year)


Biggest question: Will this be *perceived* as more or less FAIR?

The subsidy is "use it or lose it", meaning it is treated as income and pay rate applies.

Suppose in the first year the average delegate pay rate is 30%.

That means only 1bn would be added, not 3.1bn like the theoretical maximum subsidy.
Furthermore, the 2.1bn are NOT recycled into the delegate pool, so the theoretical max supply drops from 10bn to under 8bn.

Meanwhile the subsidy *rate* has still decreased on schedule, because the amount by which subsidy_pool_remaining decreases is independent of pay rate.

All this means is that early voters have to be proactive about only approving high pay-rate delegates to people or groups which add value and want the DAC to succeed. I know and trust enough AGS whales to think that this is no more dangerous or "unfair" than giving ourselves a huge dev preallocation.

Announcing the Decentralized Namespace Service - get your share by holding PTS before the end of August 21st

Featuring:

.p2p  - .bit killer and DNS cash cow
KeyID - replacing usernames everywhere

Enabling services like

Browsing .p2p websites - no spying, no seizures!
"SignIn with KeyID" - think google/facebook signin only MORE SECURE. OUTRAGEOUSLY SECURE if the website is a .p2p site.
"KeyMail"  -  more on this later... will be a critical piece of infrastructure for BTS ecosystem as a whole


Video (Draft): https://www.youtube.com/watch?v=qeweF05tT50
Webpage: http://dotp2p.io/ (new webpage will be launched soon)


Features ready NOW (test net incoming):
* .p2p Punishing Throttled Auction (with hard-coded throttle) for initial distribution  -  more on this later
* .p2p Sell/Buy embedded market
* .p2p TITAN transfers
* KeyID "points" with upburn/downburn  - how much money will people spend adjusting a meaningless number associated with their account? Probably a bunch!
* Everything in the toolkit except Markets - *maybe* we will add BitUSD far in the future

Features ready at launch at end of august (hopefully, it's just a goal):
* Punishing auction throttle size set by delegates, with fallback to fixed rate
* .p2p "offers" - put up bids before a domain is for sale or before it even exists. Not everyone wants to risk the Punishing Auction.
* SignIn with KeyID  -  we can already do this with ID-to-ID but we want to be able to do ID-to-.p2p because then you can check the site you are logging in to is who you think it is

Features ready after launch:
* DNS servers / browser plugins / "invisible" clients  -  seamless browsing experience
* DNS delegates that act as smart oracles for other decentralized application platforms - ethereum, ripple, etc... KeyID usernames *all over crypto land*.

Allocation:

1bn to AGS
1bn to PTS
1bn MYSTERY sharedrops onto other crypto. Targets might include BTC, NMC, NXT, ETH (snapshot using presale), PPC. They will likely be scaled so that they all give the same price per DNS and all have the same price *disadvantage* compared to PTS - this is why I feel OK not disclosing the exact allocation yet.. UP TO 100m of the sharedrop *might* be reserved for backpay and bounties but I fear the consequences of perceived unfairness and so I'll probably try to avoid this.

7bn delegate subsidy, about 45% of the pool paid out per year. Remember, this is a theoretical maximum! Realistically you will not have 7bn new tokens printed for the delegates!

https://bitsharestalk.org/index.php?topic=6753.0


Delegate subsidy equation (assuming 10 second blocks):
     block_pay = delegate_subsidy_remaining / 5000000
So the *maximum* number of new tokens created after T years is given by:
     5000000000 - (5000000000 * (1 - 1/5000000)^((3153600)*T))
(there are 3153600 blocks per year)


Watch out for:
* PAID positions for content creation and development (web, core client, and DNS infrastructure)
* Instructions for migrating Keyhotee and BTSX names

I have good news for everyone:

* Keyhotee founders who got screwed over by keyhotee blockchain getting superseded by a blockchain with stricter name rules.
* People who want to be "internet famous" but had their name taken by someone who didn't realize names are non-transferrable.

DNS DAC is launching soon.
Our client has support for "login" functionality to websites, sort of like Google or Facebook sign-in but with a saner security model. The DNS DAC has the unique advantage of being able to verify for the user that the site who is asking for login is the real thing. This makes DNS DAC's accounts a better "online ID" DAC than BTSX.

So DNS DAC, like before, will have two namespaces, but now we are branding both instead of just the domains:

*  .p2p domains  - throttled auction for initial distribution, normal marketplace otherwise. Used for locating websites, like a normal domain.
*  KeyID -  Your "account" name for holding funds and such and for authenticated with, just like BTSX names, one of your possibly many "internet IDs" or "named keys".  Used for technologies like "KeyMail" and "Sign In"
  -  KeyIDs are first-come-first-serve and *NOT TRANSFERRABLE* and it will be clear that this is the case. KeyIDs ("accounts") will be about 100x more expensive on this DAC. These are not "commercially valuable" names, those are .p2p names which are used for locating stuff. KeyIDs will have optional proof-of-burn for novelty / status or whatever but otherwise they are about as valuable as having "adam@gmail" vs "adam1@gmail" - nobody cares.

Keyhotee-the-software is pretty much unchanged and could use KeyID as the "root" blockchain, where you can hook in your DACs for other accounts. I don't run keyhotee so I can't promise this but it seems like the natural thing to do.

Notice which namespace we do NOT have in DNS DAC: The "Real World ID" /  proof-of-person-validated / thing that gets passed around government agencies.
This is for a separate DAC (voting++) which will have a separate name registration process. There are many options for how these two can "connect" which can be discussed later.


What you should do
I will initialize the KeyIDs in the genesis block with the following rules:

* If you are a Keyhotee founder with an invalid name, you can change your name.
* If a name is registered as a delegate on BTSX on the DNS snapshot date (not announced... yet) you will be *considered* for inclusion. This means obvious squatters will NOT be included.  ** KeyIDs will not be transferrable **.
* If someone registered your Desired name on BTSX, we MIGHT swap out their keys for yours, if they are a delegate
* Keyhotee founders might get a not-yet-decided Insignificant Perk but no promises

Reply here with your Keyhotee fixes / name squat complains here:
https://bitsharestalk.org/index.php?topic=6170
Do not litter requests in this thread, I will delete them.

The client has support for direct-linking to actions.

Replace "NAME" with an account name.

Anywhere outside of simplemachines forum:

Link to account:
<a href="btsx:NAME">Visit my account page</a>
One-click approve:
<a href="btsx:NAME/approve">Approve my delegate</a>
One-click unapprove:
<a href="btsx:NAME/disapprove">Vote out this bad delegate!</a>

In simplemachines forum (including bitsharestalk.org) or anywhere it hijacks non-http schemes:
(thanks nathanhrout for the redirect idea)
[url=daslab.io/scheme/btsx/NAME]Visit my account page.[/url]
[url=daslab.io/scheme/btsx/NAME/approve]Approve my delegate.[/url]
[url=daslab.io/scheme/btsx/NAME/disapprove]Vote out this bad delegate![/url]


Try it out


Approve my delegate!

Vote out this unreliable delegate!
And this one!
This one too!

(note that the app's thumb does not reflect the true state directly after using approve/disapprove url - we'll fix this for next release)

According to denny. Can't find it in the english version though.