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.


Messages - Agent86

Pages: 1 ... 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 23 ... 32
226
KeyID / Re: Alternative DNS White Paper
« on: August 05, 2014, 08:42:35 pm »
Why will domains in your proposal find a fair market rate at the initial auction if bidders aren't incentivised to participate?
Getting the domain is all the incentive needed.  If no one else has tried to register the domain and no one else bid, perhaps that is the "market rate"

The model has a flat registration fee to start an auction but we already have an idea from existing domain systems which names may or are likely to be more popular or valuable so wouldn't it make sense to reference existing domain name valuation systems to derive a fee to register a TOAST domain and start an auction? (I.e. The registration fee for Nike.Tld should be more than Ilovelamp.Tld imo.)
No; this is a ton of unnecessary work.  If Nike.Tld really has value, we will soon find out because people will bid accordingly.

In your model you're really only 'renting' the domain for X period. Then there is a new auction and you have to pay rent for the next rental period at a new rate based on that auction, someone can even force you into a new rental contract at any time? 
Leases can be extended before they near expiration.  If it expires and a new auction happens it means the current holder decided they would rather risk giving up their domain than continue to pay the rate they were paying.  No one can "force you" to lease a domain.

Examples:

Say Bitshares.org is valued at $10 000, I should be able to put in a bid of $5000 knowing that BitShares will more than happily pay the $50 annual rental fee. ($25 to me and $25 to delegates.)

I could bid of $200 000 for a $1 million website 'Y', knowing 'Y' will be happy to pay $2000 rent for the year. (1k easy money to bidder and 1k to shareholders via delegates)
Why should you get paid for harassing people?

But in your model Ethereum can force BitShares to pay $5000-20 000 rent for the next rental period. BitShares will be forced to pay a ridiculous amount for that period & be unfairly punished or lose their site.
It would hurt Ethereum way more to pay bitshares some ridiculous amount to take over our domain name for some period of time.  It would be such a dumb thing to do on their part that they wouldn't do it.  We would take the big payday for a nice profit, redirect traffic for a while, and then end up getting our domain back once Ethereum realizes they can't pay an astronomical price to rent a domain forever that they don't use.  Also, everyone would wonder (including their investors) why they spend their funds this way to be be dumb A-holes who have to resort to such things.

This means you will be punished the more successful your domain is.
There's nothing wrong with shareholders getting a decent payment from someone making a ton of money using our domain service.  No one is forcing them to lease it from us.  Also, companies that perform a useful service or provide useful content for a website have success and value.  Domains are generally a convenient way of accessing that specific company or service.

These types of things were discussed to some degree in parts of this thread: https://bitsharestalk.org/index.php?topic=5357.0

227
KeyID / Re: Alternative DNS White Paper
« on: August 02, 2014, 05:49:48 pm »
To put it another way: what happens when the total required to extend all domains by another year at the current rate is greater than the token supply? This scenario is inevitable if the DAC operates profitably.
My opinion was that "bips" would work (payment is a percentage of whole rather than # of shares).  I feel like it is a reasonable argument to say if the value of the system increases 10x that the value of domains on the system is also increasing by a similar amount (due to increased exposure and adoption of the system).  I think we have to realize that no one should be paying a ton to lease a domain name on a system no one uses yet.  Also, if it is big and established the price of stake should be more stable and you're not likely to see 10x swings.

228
KeyID / Alternative DNS White Paper
« on: August 02, 2014, 03:55:10 pm »
The following white paper is a description of an alternative decentralized DNS system.  My opinion is that this proposal is far better and more useful than any current proposals.  I had hoped to get this out before DNS snapshots were announced.  I apologize for the length; there is a fair amount of background information included.  Many of the specifics are in the parameters section.

It is available in pdf format here: https://docs.google.com/file/d/0B44pzrE52xGjcTE5V05jeGZqUjA/edit


The Path to a Decentralized DNS,
Overcoming Adoption Challenges, Domain Squatting, and Group Trap in Decentralized Systems

Agent86.BTS@gmail.com
8-2-2014

Introduction:


Domain name registry has become a controversial topic in recent times.  The internet namespace is relied on by the public across the globe. Control over this critical infrastructure must be considered carefully.  Events such as Edward Snowden's revelations about NSA spying have increased calls to move the domain name system out of the hands of ICANN and out of the control and jurisdiction of any single government. There is significant demand for a decentralized DNS managed in an incorruptible, transparent, and publically auditable manner.  The current marketplace for domain ownership is also costly and inefficient.  Domain squatting and domain sales remain sources of added cost and profiteering.  Domain ownership disputes may be settled with costly litigation; a system not equally accessible to all market participants.  The fair allocation of domains and avoidance of cybersquatting also presents a significant challenge to any replacement system.  Despite demand, no new DNS system outside of ICANN has achieved broad use or adoption.  In this paper a system is proposed to meet this market demand and overcome challenges to adoption.


Learning from the Past:

The concept of a decentralized DNS is not new.  One prominent attempt is a project called "Namecoin." Namecoin is a DNS based heavily on the technology behind Bitcoin (1).  Bitcoin introduced a novel method for a decentralized network to come to consensus on a shared ledger.  A shared, publicly auditable ledger, beyond the control of any single institution or government, is a desirable system on which to implement a publically auditable DNS.

Despite creating such a transparent domain name registry, Namecoin has failed to gain traction with the public for a number of reasons.  Firstly, Namecoin suffers from a lack of resources and economic incentives needed for growth and promotion.  There is no mechanism to effectively direct sufficient resources to developers and promoters.  Charitable donations toward these expenses are not sufficient.  Secondly, a primary flaw in the Namecoin model is the lack of a system to address domain name squatting.  While cybersquatting is a problem in our current system, there are some tools in place to address it.  These tools include trademark disputes, litigation, and administrative actions.  The problem of squatting is greatly amplified in systems that provide no feasible mechanism to address the issue.  Finally, the consensus mechanism for the Namecoin ledger, adopted from Bitcoin, is not ideal and suffers from a tendency toward centralization over time.

Bitcoin demonstrated that a decentralized ledger can be used to track ownership rights.  This concept has applications that go beyond tracking "coin" ownership as a form of money.  Dan Larimer, who founded the BitShares project, made the observation that ownership stake tracked on a decentralized ledger is similar to "shares" of a decentralized company (2, 3).  With this analogy in mind, we can more easily analyze the economic incentives for a decentralized system that provides a service.  Typically, the ownership stake of the system acts as an internal currency for services provided and thus creates demand for shares.  Payments to all shareholders are accomplished via destruction of shares such that each shareholder's percentage ownership is increased.  In this case, the service provided is a domain name registry.

A DNS must be useful to website owners and the general public to be successfully adopted.  Memorable domain names are a limited and valuable resource.  Users expect a domain name system in which memorable domains have useful and appropriate content.  Website owners want the ability to secure memorable and appropriate domain names at fair and competitive prices.  Users and website owners both benefit from websites free from censorship, confiscation, and "man in the middle" attacks.  Decentralized DNS models have an added market advantage of providing increased privacy to domain holders.

The BitShares analogy allows us to design a shareholder owned decentralized DNS service that provides for these market demands while financially rewarding shareholders for developing, maintaining and promoting the system.  This system can be designed to solve the problems hindering Namecoin and other DNS alternatives.


Squatters:

The concept of domain name ownership should be explored carefully.  The shareholders of a decentralized DNS may claim ultimate ownership interest of their namespace as they are burdened with maintaining it and promoting its widespread adoption.  Shareholders are incentivized to maximize the utility and value of the namespace for all parties.

A simple system for domain name registration is a "first come first served" model with a fixed registration fee per domain and a nominal annual renewal fee.  This is the model proposed by Namecoin.  This model is grossly insufficient to prevent domain name squatting.  When a system allows domain names to be purchased and held indefinitely at little cost it incentivizes early adopters to purchase large numbers of domain names with the hope of reselling some names at a profit to later adopters.  This practice discourages real website developers from buying domains by driving up acquisition costs and creating a difficult, unpredictable, and frustrating purchasing process.  These barriers ensure the system will never be broadly adopted or useful.

Rather than a simple "first come first served" model, it is possible to use an auction to initially award domains. This can also be followed by nominal renewal fees.  While this may generate more value for shareholders, it does not solve the problem of squatting.  Domains will still be bid on in mass for speculative value.  This leaves the cost and aggravation for future buyers who must negotiate directly with domain squatters.

A recently proposed solution to domain name squatting has been documented within the BitShares community (4, 5).  This system uses a modified initial auction format.  The system rewards bidders who are outbid during an auction.  The intention is to incentivize otherwise disinterested parties to bid up auction prices to ensure a "market rate" is reached.  The author makes an unsupported assumption that speculators would bid above the long-term speculative value of the domain and that this will alter resale behavior as speculators are “incentivized to sell back bad bets at a loss” (4).   There are also auction incentives that are hoped to encourage bidders to initially bid at the price they are willing to pay.  This complex proposal offers very little improvement over a standard auction.  The proposed system also does not address the root cause of squatting behavior which is the low cost to hold domains over time.

These deficiencies in addressing squatting behavior destroy the utility of all currently proposed decentralized DNS systems.  Our current domain name system, while costly and inefficient, has tools to address squatting including litigation and administrative procedures.  Without a system to address these challenges it is not plausible for an alternative DNS to compete for adoption.  While it is conceivable that shareholders of a decentralized system could set up an analogous dispute resolution process such as voting on domain disputes, these processes tend to be costly, time consuming, and unpredictable.

Distribution of valuable and memorable domain names must be perceived as fair, broadly accessibly, transparent, and must promote utilization.  A key to avoid abusive squatting is to make holding unused domains costly.  Shareholders can retain ownership of the namespace while leasing domains at market determined prices.  This tends to make it more profitable for speculators to hold shares of the DNS rather than squat domain names.  Lease terms must be fair and respect the needs of website owners who are likely to make significant investments over time into their chosen domains.


Parameters:

The following system parameters are designed to maximize utility and fairness:

A new domain can be registered for an initial 30 day trial and used immediately.  This is a benefit to users who want quick access to a domain. Doing so initiates a 30 day auction for a 1 year lease of the domain. The original auction initiator has access to the domain for the period of the auction. Parameters for the initial auction should be fair, easy to understand, and reduce the need for complex bidding strategy. 

Suggested auction parameters:

1)   30 day auction - ensures visibility of the auction so interested parties are unlikely to miss it.
2)   Bids must be 10% above prior bid to be accepted - easy to remember and reduces back and forth.
3)   Auction stays open after 30 days until there is 24 hours of inactivity - reduces desire to place a bid in the last minutes of the auction deadline. Auction is unlikely to remain open long after 30 days because the selling price would double at least every week (1.1^7 = 1.95).

After acquiring a lease, a domain holder may extend the lease at any time up to the max lease length.  The max lease length is defined by the formula: initial_lease_length +  time_domain_held = max_lease_length.  Domains acquired from the auction process have an initial lease length of 1 year.

A domain name holder may post a sale offer for the remainder of their lease.  They may set a price and an optional time delay to allow for transition.  Selling at a price above their current lease rate sets a new higher market rate for the domain.  Selling at a loss will not lower the future lease rate for the domain.  The only way the shareholders will accept a lower lease rate on a domain is if the lease comes to the expiration date and a new 30 day auction is initiated.  The current lessee may initiate a new auction within the last 30 days of their lease and also bid in the auction if they choose.  They would retain control of the domain during the auction.  Keep in mind, a lease should not get close to expiration unless it is overpriced as it can be extended at any time up to the max lease length.

Whether or not a domain is posted for sale, a party interested in acquiring a currently leased domain may place an upfront deposit on that domain at a rate at least 10% above the current lease rate for the full length of the current lease. At this point the current domain holder may:

1)   Extend their lease at the higher market rate (this relinquishes the deposit back to the bidder)
2)   Hold the lease until the expiration date.  At this point the domain is relinquished to the higher bidder and the bidder takes over the lease with an initial term equal to the lease they bought out.
3)   "Sublease" the domain to the higher bidder at any time before the lease expiration.  Subleasing gives a profit to the original domain holder by the formula (higher_rate - rate_paid) * time_remaining_on_original_lease.  The new holder always takes over the domain with a lease term equal to the length of the lease they bought out.

When bidding on a currently leased domain, the funds of the high bidder are tied up and only released back to them in the event the current holder extends their lease at the higher market rate or if the bidder is outbid for the domain.  The high bidder may acquire control of the domain for the full amount of their deposit either through a sublease or the current lease expiration.

There may be times when a high bidder gets "buyer’s remorse" and would prefer to remove their offer to recover the deposit.  An advanced option can allow a bidder in this situation to offer a "buyout incentive."  This incentive is paid to anyone who takes action that releases them from their bid obligation.  It is either paid to the current domain holder if they extend their lease at the higher market rate or it is paid to anyone who outbids them for the domain.


Turning Squatters into Sales People:

The previously outlined parameters describe a system in which domains have a market based "carrying cost.”  Any individual who purchases a domain for the purpose of speculating on its future value must contend with this carrying cost.  Speculators cannot afford to pay the same costs to carry a domain as someone with a legitimate use for the domain.  Carrying costs motivate price speculators to promote names for a quicker sale; it turns squatters into sales people.  An apt analogy is "house flipping" where carrying costs, such as property taxes, motivate the flipper to promote the home and sell quickly.

Carrying costs also make it prohibitively expensive to lease domains desired by competitors or adversaries in order to deny use of the domain.  It is simply too expensive to maintain payments at high market rates for a multitude of unused domains.

Domain name holders who establish long term ownership interest in their domain are rewarded with very long lease options to have the certainty of future ownership.  They are also rewarded with a much greater profit opportunity in the event a buyer is interested in the domain.  As the system matures, long established leases may be available for purchase to those willing to pay the additional cost.


Group Trap:

A major barrier to adoption of a system such as Namecoin is the lack of resources and financial incentives for those who are promoting and developing the system.  All current systems of decentralized ownership tracking, often grouped under the term "crypto-currencies" (which includes Bitcoin) suffer from a problem of "group trap."  Group trap can be defined by the observation that working as a group toward a common goal may dilute the incentive for individual effort.  Essentially, these decentralized systems have no mechanism to effectively centralize the resources needed to incentivize developers and promoters of the system.  While those with stake in a particular currency have some motivation to promote it, the value of the work performed is diluted across all shareholders.  A developer or promoter working hard for such a system personally incurs the cost of that labor while other shareholders do not.  The shareholders who do not incur these extra costs derive comparatively better returns from their investment.

Many such systems begin with large stakeholders who work hard to promote and develop the system.  As they begin to sell stake to cover costs it becomes apparent that the work is not adequately rewarded.  Many of these projects leave investors holding stake in abandoned and underdeveloped projects.  Some projects raise initial capital from investors who are then granted stake.  This money is used on the honor system to develop the project.  This starting capital is inherently limited, it is not controlled and directed by shareholders proportional to stake, and it is not a sustainable funding method for long term project costs.

The solution to this "group trap" is shareholder directed reinvestment or distribution.  Following the BitShares analogy of shares in a profitable company we can see that shareholders can be given voting rights to direct capital.  These systems can be structured in a way that generates profit for shareholders.  For instance, a domain holder can pay a certain amount of stake to the network to lease a domain.  This stake is destroyed, increasing the percent ownership of all stakeholders.  The stakeholders can then sell that additional stake back to customers who use it to pay to lease domains on the network and the stake is again destroyed.  Destroyed stake is essentially "income" to the shareholders.  While destroyed shares are income, shareholders can pay expenses via creation of new shares.

A method to accomplish this is the election by popular vote of "workers" who are paid via the issuance of new shares.  Workers can be elected by a method called "approval voting."  Approval voting allows any stakeholder to approve or not approve of any candidate worker.  These approvals are weighted by ownership stake.  Workers with over 50% approval by stake become active and are paid a salary in newly issued shares.  This salary could be specified by the worker as part of their candidacy.  It is also possible to allow shareholders additional control of salary by approving a percentage of the requested salary during voting.  This percentage could be above or below the requested salary and a median can be taken to determine the actual paid salary.  This system allows shareholders to hire executives, developers, and promoters and appropriately incentivize them to work in the interests of the system.

A domain registration system is the type of system that requires a large network effect.  Utility of the system and adoption of the system are interdependent and each is reinforced by the other.  Promoting the system to the point that a network effect is established may require a large initial investment.  It is quite likely that expenses for development and promotion would outweigh income in the early stages of the system.  For this reason the system may create more shares than it destroys in early stages.  The system would grow in value by increasing adoption and attracting new investment capital to buy the newly created shares.


Consensus:

A final barrier to the long term success of Namecoin is the choice of consensus algorithm.  A detailed technical discussion of consensus algorithms is beyond the scope of this paper; however a useful overview can be given.

Namecoin uses a "proof of work" algorithm whereby adding a block of transactions to the shared ledger requires a solution to a difficult and computationally intensive problem.  This mathematical problem is difficult to solve but easy to check.  The network builds off and forms consensus on the ledger that represents the most verified "computational work."  The idea is that in order to control the ledger an entity must perform more computational work than the rest of the network combined.  This work is rewarded with the issuance of new shares or "coins."  Although Namecoin is secured via the same work and computers that secure the Bitcoin network (it does not require significant additional resources) this type of competitive computation inevitably leads to centralization.  Motivated by profit, specialized hardware is developed to reduce costs.  Due to economies of scale, only the largest and most efficient operations can profitably participate.  The computational energy required for proof of work is also unnecessarily wasteful when compared to other options for consensus.

A much improved algorithm for consensus is "proof of stake."  A specific form of proof of stake called "delegated proof of stake" (DPOS) has advantages over other implementations (6).  DPOS allows the election of representatives called “delegates” to validate transactions on the network.  This work is verifiable, and if not performed, delegates are removed.  Proof of stake rests power over the ledger ultimately in the hands of those with ownership stake.  Proof of work gives power over the ledger to those with access to the most computational resources.  Delegated proof of stake allows a more sustainable, cost efficient, and secure shared ledger than proof of work can provide.


Conclusion:

This paper has outlined a structure for a decentralized DNS which may overcome current barriers and create the right incentives for broad adoption.  A sustainable funding and economic incentive model has been proposed.  Market parameters have been outlined that promote utility and fairness and discourage domain squatting.  A decentralized DNS can provide transparency and accessibility.  It can reduce costs and reduce the opportunity for any single entity or government to exercise control over the public DNS system.


References:

1)   Double, Chris. May 2011. “Namecoin - A DNS alternative based on Bitcoin.” http://bluishcoder.co.nz/2011/05/12/namecoin-a-dns-alternative-based-on-bitcoin.html

2)   Larimer, Stan. September 2013. “Bitcoin & the Three Laws of Robotics.” http://bitshares.org/bitcoin-the-three-laws-of-robotics/

3)   Larimer, Dan. November 2013. “DAC Revisited.” http://bitshares.org/dac-revisited/

4)   Mushegian, Nikolai, June 2014. “DNS .p2p Auction Specification.” https://github.com/BitShares/bitshares_toolkit/wiki/DNS-.p2p-Auction-Specification

5)   Mushegian, Nikolai, April 2014. “Whitepaper Draft.” https://github.com/nmushegian/dns/blob/master/whitepaper-draft.md

6)   Larimer, Dan. April 2014. “Delegated Proof of Stake.” http://bitshares.org/delegated-proof-of-stake/

229
General Discussion / Pic from Chicago Bitcoin conference
« on: July 27, 2014, 11:10:43 pm »

From left to right: Vitalik, Bo Shen, Super3, Agent86

230
General Discussion / Re: Approval voting = delegation voting
« on: July 26, 2014, 06:24:34 pm »
I think you guys are talking past each other a little.  In the most pure form of approval voting you could have an unbounded number of votes and the number of delegates wouldn't be fixed.  i.e.  all delegates over a threshold (such as 50%) are in and everyone else is out.  In that case the number of votes you cast really has no impact on how heavily "weighted" your positions is.

However when you have a fixed number of delegates that are going to get in no matter what and there are less than that number of trusted people to perform the job, it is better if they run multiple delegates rather than let those open positions be filled up by untrusted scragglers with no real support.  I brought this up on the mumble.

231
Well, I won't be voting for any delegate that publishes a "slate" of other delegates to vote for.  Delegates should be campaigning for the approval of shareholders not campaigning for the approval of a cabal of other delegates who all add each other to their slates.

I encourage any shareholder that cares about this stuff for the long term to take the same stance.

232
If I vote for you 'Agent86 delegate' & you have 'Gamey delegate' on your slate & Gamey turns out to be bad so you remove him from your slate, because I voted for you doesn't it mean that my shares also stop voting for Gamey? If so that is good. Or have I misunderstood?

Edit: oh ok if it is like you're saying I have misunderstood
No your shares wouldn't stop voting for Gamey in that scenario.  It wouldn't be good to implement it the way you are thinking.

233
Ok I can see the need for something like this now that I'm thinking of voting myself.

I like to keep a portion of my stuff in cold storage & I don't want to have to access my funds just to change my vote every few weeks. Voting for a few people I really trust that maintain good slates passes the burden to my favourite delegates to actively police the system and as a result I'd only have to get involved in an ermegency. (Also it's unlikely an avg. shareholder can be expected to form an opinion on more than +-15 candidates I would guess.)

Though I agree with Gamey that from a marketing perspective it 'feels' like a negative. (Also enjoying reading your thoughts Gamey on how it could change the incentives.)

Personally I'd like to be able to actively change votes of BTSX I have in cold storage but it doesn't seem like that would be technically possible.
Empirical, you are not understanding the proposal.  You still can't change your votes without making a transaction.  You vote for a particular slate but if the person whose slate you chose changes their preferred slate, the slate you voted for does not automatically update.  You would have to vote again.

If the proposal allowed you to just defer your voting to someone else and let them vote on your behalf it would be an even worse idea than it is already.

Edit: sorry I don't mean to be short.  I think I'm just feeling frustrated and wish I had a little more control over some of these decisions.

234
General Discussion / Re: POS vs. DPOS
« on: July 25, 2014, 12:50:44 am »
Ok, I also wrote this complaint about NXT forging on the NXT site:

Aren't forging pools a threat to NXT/centralization?  For instance, I say "lease your forging power to me and I will send back 90% of the fees relative to the stake you leased so you don't need to bother with it."  Even if you limit it by address, I can set up multiple addresses to accept leased forging.  I can also set up pools that don't appear to be under the same ownership but actually are.

The even more sinister attack is I set up a pool that actually returns even more than 100% of fees.  I basically pay people to give me power over the network.  You have to rely on people being altruistic to avert this attack.  People have to reject the short term financial gain for the greater good of the NXT network... That's asking A LOT!
IMO these are BIG security advantages of DPOS over NXT forging.  APPROVAL VOTING solves these problems in DPOS and creates the right incentives. This allows us the advantages of some centralization for high transaction volume/scalability/efficiency without the security risks of poorly incentivized centralization.

235
General Discussion / Re: POS vs. DPOS
« on: July 25, 2014, 12:04:24 am »
Ok, I also wrote this complaint about NXT forging on the NXT site:

Aren't forging pools a threat to NXT/centralization?  For instance, I say "lease your forging power to me and I will send back 90% of the fees relative to the stake you leased so you don't need to bother with it."  Even if you limit it by address, I can set up multiple addresses to accept leased forging.  I can also set up pools that don't appear to be under the same ownership but actually are.

The even more sinister attack is I set up a pool that actually returns even more than 100% of fees.  I basically pay people to give me power over the network.  You have to rely on people being altruistic to avert this attack.  People have to reject the short term financial gain for the greater good of the NXT network... That's asking A LOT!

236
General Discussion / Re: POS vs. DPOS
« on: July 24, 2014, 11:41:15 pm »
Decided to register to thank you for crossposting this to our forums :)

Always good to have intercoin discussions!
Welcome Damelon!  I just made my first post to the NXT forum (I registered a couple months back), so + 1 for intercoin discussion!
https://nxtforum.org/general-discussion/nxt-pos-vs-bitshares-dpos/msg70361/#msg70361

237
I agree with you on the two classes with different thresholds of approval.   

The only tweak I would have is that you require 50% of "active shares" vs 50% of all shares.    Active means any share that is voting for someone.  Inactive are shares that don't vote for anyone.
I agree with you except for the definition of "active" shares.  Shares that have not moved in over 1 year (paid inactivity fee) are inactive and should be removed from all voting algorithms.  People who choose to abstain are voluntarily inactive.  Not voting for someone should not automatically disqualify your shares from the voting algorithm. The act of not voting is the way that one opposes all current candidates.

238
Basically we got two unintended, inevitable consequences of DPOS:

1. People can delegate the job of voting to a slate.
2. Delegates can pay the individuals who vote for them.

We are now mitigating the risks these schemes pose.

Like Delulu I am most concerned about the Cynical Economy Threat: People will vote for delegates and slates that pay the most for individual votes (not via burn that appreciates everyone, but directly).
Clains, both of these "inevitable" consequences have already been addressed by using approval voting.
Approval voting removes the incentive for vote buying and it won't happen or be rewarded.
There is also no incentive for "political party slates"
Quote
We are complicating things because we are overpaying delegates.  There is no reason to give fees for things like registering an asset to the delegate that processed that block.  Delegates should be paid a fair amount for the service provided.

What does it have to do with the delegate pay?
Delegate pay is relevant because if it is excessive then voters have to balance voting for delegates they trust to perform the job of delegate (easy to do) vs. keeping track of how all the delegates spend money (hard to do)

Bytemaster, I honestly don't understand how one minute you're acting like people don't have time to evaluate delegates for the simple task of writing blocks, and the next minute you want to give delegates the additional power of spending all the profit.  If voters are lazy, don't force them scrutinize delegate spending!! KEEP IT SIMPLE.  Don't overcharge users for delegate profit!!  Our system is truly way cheaper than Bitcoin.  We want to encourage use of the system with low fees.   We could compete in 3rd world and micropayment applications.

I've said it before and I'll say it again, reinvestment through control of dilution and profit spending requires a separate class called "workers" where the "real money" goes and those people need 50%+ support.  A worker could even give prizes to the delegates with best uptime for the month.

239
I don't think "political parties" are at all inevitable with pure approval voting; I don't see the incentives for them.

Voting for delegates should be easy because delegates have a VERY simple and verifiable job.  It's not rocket science; vote for a bunch of people who come across as trustworthy and if you pick a bad one it's no big deal as it will soon be apparent.

We are complicating things because we are overpaying delegates.  There is no reason to give fees for things like registering an asset to the delegate that processed that block.  Delegates should be paid a fair amount for the service provided.

240
I think not knowing who to vote for is not the reason for low participation; I suspect it's people haven't even got the wallet yet or imported private keys.   People with a huge stake are not attacking the chain.

With RDPOS I can already see the horsetrading between delegates:  You add me to your slate and I'll add you to mine, I'll only add you to my slate if you help me fund my "pet project" etc... 

Anyone is free to make recommendations or publish a list but encouraging people to vote blindly for a list they haven't looked at doesn't help.  There are other ways of making the process easy.

Pages: 1 ... 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 23 ... 32