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 ... 17 18 19 20 21 22 23 [24] 25 26 27 28 29 30 31 32
346
General Discussion / Re: Is guestlist or helpdesk DAC possible?
« on: June 17, 2014, 04:54:08 pm »
Quote from: kino on June 17, 2014, 04:23:11 pm
Quote from: toast on June 17, 2014, 04:01:18 pm
I think it is awesome! For a newbie you seem to get how the pieces fit together.
For tickets, it's sort of like ME/Mastercoin/counterparty but with short-term assets. You could theoretically have much lower overhead by pruning events that are no longer active.

For helpdesk, you could implement a natural priority queue based on how much they paid for the helpdesk ticket.

In either case, it is clear where the income is coming from and what service the blockchain provides in exchange.

 +5%

Thanks! :). So is it possible to use the toolkit to create these kinds of DAC? For the helpdesk I'm not sure about prioritization based on the amount paid for the ticket. As far as I know, helpdesk was being paid for by the company to the third party providers now. Perhaps prioritization will be managed once ticket was created by the customer (additional data for prioritization, status, thread replies, etc. - could bloat the blockchain?).

In addition, I was thinking about the shareholder's benefit if coins spent on tokens will be sent to them as dividends or just some part of it (remaining part will can be burned perhaps). In the future, there maybe too much coins available - with coins returning to shareholders as dividends and some being generated via POS. Of course this will depend on the increasing demand for coins by token generators (businesses) using the DAC service to balance the supply/demand ecosystem.
What is being accomplished that Bitshares ME can't do?  As best I can tell this is just 2 applications for how tokens could be used by companies.

Why create a whole separate DAC for helpdesk vs guestlist when both DACs need the same thing: tokens.

How is it a "guestlist" when the guestlist tokens are freely exchangeable and sellable, it's more like entry tickets right?

I feel like by talking about "POS generated coins" you're not fully understanding POS.  It doesn't generate coins in the way mining does; your percent stake typically stays the same over time, it's not about coins but a percentage of the whole.

It doesn't really make sense for these companies to "pay coins" to generate their tokens/coins when issuing a token should be a very low cost thing to do.  Why should they pay you for your "guest list coins" when they can create an asset on bitshares me for next to nothing and use that instead?

347
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 16, 2014, 02:24:43 am »
Quote from: bytemaster on June 15, 2014, 09:41:43 pm
The issue is in tracking total stake that supports them.  That means every 'balance' in the blockchain would have to have N delegates attached to it instead of just 1.   When you spend that balance you subtract from N delegates and reallocate your votes for those shares to M delegates. 
I don't think you need to "subtract from N delegates" each time you spend. 

Stake supports delegates: 1,2, & 3.
transaction says "add delegate 4"
Stake supports delegates 1,2,3, & 4.
transaction "remove delegate 2, add delegate 5"
Stake supports delegates 1,3,4, & 5
transaction "remove all prior delegates, add delegates 6 and 7"
stake supports only delegates 6 & 7.
transaction with no change
Stake continues to support delegates 6 & 7

Quote from: bytemaster on June 15, 2014, 09:41:43 pm
What you are asking for is that each delegate sink or swim based upon an independent election.  This is no longer 'delegation' but rather popularism.
I guess if you make that distinction, then delegation encourages delegates to support the interests of the faction that delegates to them, popularism encourages delegates to appeal to all shareholders and support the interests of the whole DAC.

Quote from: bytemaster on June 15, 2014, 09:41:43 pm
If you require all delegates to get at least 51% net support then you are asking all of the users to evaluate all of the candidates and that is much to high a burden.    If you lower the threshold then it opens the network up to attack by individuals with large minority shares that can move faster than people can 'vote out' their candidates. 

So I see such a system resulting in either no delegates getting to the threshold or an attacker creating 10000 delegates giving them all a bunch of support faster than anyone can vote them all out.  It would become very costly to vote against 10000 delegates produced by the attacker. 
There is no bottom "threshold",  It's basically the 100 accounts that have the most support are active delegates.  So no chance that no one reaches the threshold.  (I said that 50% could be used as a threshold to add additional delegates only in the situation that all active delegates already have over 50% support)

Let's say a big holder, I'll even give him 10%, wants to attack the network by creating 10000 delegates.  Everyone sees this and no one has any incentive at all to vote for those 10000 delegates except for the attacker.  (there are no downvotes, so people don't have to bother voting him down).  The only way his 10,000 delegates get active is if the rest of the 90% of the commmunity can't get it together enough to give 100 delegates more than 10% support each.  People would probably be voting for just about anyone able to run delegates that wasn't one of this ridiculous group of 10,000.   

There is nothing for this attacker to gain by doing this and everything to lose.  He runs the risk of having his giant and otherwise hugely valuable 10% stake be forked out completely by the rest of the community or otherwise become worthless, not to mention wasting a bunch of money registering 10,000 delegates for no reason and looking like a jerk for doing so.

Assuming that running a delegate is a profitable position, rational economic actors operating within the current voting system will end up voting for themselves or for delegates that kickback to them.  The down voting can't stop this behavior.  Anyone trying to be a hero by downvoting will miss his own opportunity to vote for himself or for someone giving him a kickback, he also misses the opportunity to vote for a candidate that is trying to benefit the whole DAC, he also will never be able to stamp out the activity of everyone voting for themselves or giving kickbacks so stopping one of these actors only leaves more spoils for others doing the same thing.  An entity willing to run delegates at a loss and give big kickbacks could quite likely surreptitiously gain over 50% of the delegates over time by appealing to people's profit motive (see GHash.IO as example). This entity need not be heavily invested in the chain.

348
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 15, 2014, 10:30:28 pm »
Quote from: toast on June 15, 2014, 09:54:15 pm
Quote from: Agent86 on June 15, 2014, 09:48:20 pm
To clarify what may be a misunderstanding, I'm am proposing to eliminate the ability to "downvote".  You either support someone to be a delegate or you don't: it's binary. (right now it's positive, neutral, down)
As soon as you see one of your delegates behaving badly you automatically pull support.

If you don't have downvotes you incentivize centralization because a delegate can offer to pay dividends to only his supporters.
Lack of support in a system where there's no cost to supporting someone isn't a punishment

Again, I think you are wrong.  If a delegate is offering to buy votes (pay dividends to supporters) I think they are very unlikely to get the kind of broad support needed to compete as a delegate under my proposal.   As long as they don't reach the level of being an active delegate (perhaps as much as 50% support) than there is no reward to the supporters.  If for some reason more than half the stake still wants this person to be a delegate, after they have offered to buy votes (and probably called out for it on the forums) than so be it.  --But everyone else can jump in and support them too without withdrawing their support for other delegates.  Now this person who is paying dividends only to their "supporters" is paying dividends equally to all shareholders, which is fine and kind of what we wanted to see anyway.

Under the current proposal, someone buying votes could very likely succeed.  They only need support of a very small percentage of the stake to become a delegate (by definition 1% makes them an active delegate but probably a lot less).  Then their supporters (maybe they only need to vote for themselves if they are a big holder) get the kickback that offers no benefit to the rest of the network.  Now you are hoping that others discover this behavior (how?) and use their votes to downvote.  But really their is a huge cost to being the hero that finds out this behavior and downvotes because now you can't vote for the delegate that you want.  So most likely you don't bother and the vote buyer gets away with it.  Not to mention, as I already pointed out, If the vote buyers are colluding they can play cat and mouse and switch their vote to a new delegate that you haven't voted down and then you'll have to track them down again to try to vote them down.  long story short you'll give up.

349
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 15, 2014, 09:48:20 pm »
To clarify what may be a misunderstanding, I'm am proposing to eliminate the ability to "downvote".  You either support someone to be a delegate or you don't: it's binary. (right now it's positive, neutral, down)
As soon as you see one of your delegates behaving badly you automatically pull support.

350
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 15, 2014, 09:28:03 pm »
Quote from: toast on June 15, 2014, 09:03:54 pm
By your proposal, the more people you vote for, the more your vote matters. Someone voting for 100 delegates will have 100x more voting power than someone voting for 1.
That's not true. How so?  You can't vote for the same delegate 100x times.

If you want to throw as much weight as you can behind one candidate you support them exclusively (just denying support to potential competitors).

You could make 1000 delegates and vote for each of them but that gets you nowhere because they still each only have as much support as your personal stake can provide.  No one else has any reason to vote for them.  Other candidates on the up and up will get much more broad support and your delegates will never become delegates.

Quote from: toast on June 15, 2014, 09:03:54 pm
How exactly would you tally votes in this scheme?

You tally votes by simply ranking delegates by total amount of stake that supports them.  Top 97 delegates are active or anyone with over 50% even if that means more than 97 active delegates.

351
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 15, 2014, 09:02:06 pm »
Quote from: bytemaster on June 15, 2014, 08:34:05 pm
Your proposal would require every transaction to update N delegates where N is unbounded. 

Why?  You don't need to update all delegates in each transaction.  The transaction could just specify changes, or no change at all.  You wouldn't necessarily bother to change the delegate elections unless you have a reasonable stake that you intend to keep for a while, then you could send a transaction to yourself specifying new delegate elections and stating all prior delegate elections are void.

Yes, voting for a ton of delegates could make the size of your transaction large and therefore the transaction fee more expensive so you wouldn't be ridiculous with it because you would have to pay for it. (probably no more expensive or large than splitting up your stake/transactions to specify that you are voting for different delegates in current proposal anyway)

352
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 15, 2014, 08:23:09 pm »
Quote from: toast on June 15, 2014, 07:42:51 pm
Quote from: Agent86 on June 15, 2014, 04:02:16 am
I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support.  This will give a much clearer picture of how the community really feels.

This is already how it is, you can split your stake however you like.

There is a qualitative difference between:

1 BTS supports delegate 1
1 BTS supports delegate 2
1 BTS supports delegate 3
1 BTS supports delegate 4
1 BTS supports delegate 5

compared to:
5 BTS supports delegates 1,2,3,4 & 5

I hope you can see the difference here.

It is MUCH easier under the current system for a person with a big stake to vote themselves to be a delegate without appealing for broad community support.
Under my proposal it is possible for a delegate to show that over 50% of stake supports their position as delegate.  Under current proposal this is not possible.
Current proposal appears to me to make buying votes possible.  My proposal I don't believe it is possible.
Downvoting under the current system requires people to remove their support for their desired delegates in order to downvote.  Your client seems like it has to do some complicated analysis to constantly monitor which of your liked delegates need support and which don't.  Why not just allow people to state who they want as their delegates and express that will all their stake?

353
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 15, 2014, 08:17:01 pm »
Quote from: liondani on June 15, 2014, 07:28:50 pm
Quote from: Agent86 on June 15, 2014, 04:02:16 am
I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support.  This will give a much clearer picture of how the community really feels.

 +5% +5% +5%

but with well studied restrictions like...
a)vote for X delegates max.
b)my first voted delegate takes Y points, the second Y-1 points .... etc...
c)make your suggestions...
I think there is diminishing returns in making things more complicated.
You can think of it as a Yes/No question:  Do you want this person to be a delegate?  Do you trust this person as a delegate?
The answer to this question is likely "yes" for more than one delegate.

If you especially like and want to support a particular community member you can choose to support them to have more than one delegate but you would never want one person to control all of them.

354
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 15, 2014, 04:52:49 pm »
Quote from: tonyk on June 15, 2014, 04:22:17 am
I think that if you run under 49% of all delegates and you are doing it under Agent86 you will be safe. Just learn from other people’s mistakes and never post before logging off from the main account…
Quote from: tonyk on June 15, 2014, 06:37:05 am
keep them delegates of yours below 50%, never post before logging off from the main account…
Ok, I guess you're saying I'm a sockpuppet?  Sorry I missed it; not the case.

355
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 15, 2014, 04:45:10 am »
Quote from: tonyk on June 15, 2014, 04:22:17 am
You sound like the most self-doubtful person I have ever met (other than myself).
I think that if you run under 49% of all delegates and you are doing it under Agent86 you will be safe. Just learn from other people’s mistakes and never post before logging off from the main account…
I guess I'm trying to talk more broadly about what method of electing delegates will be most fair, hardest to game etc.  It seems like there may be a lot of people that want to be delegates especially if they are well compensated.

356
General Discussion / Re: Delegated Proof of Stake (DPOS) White Paper
« on: June 15, 2014, 04:02:16 am »
I feel like the current delegate voting system could use "refinement".

The purpose of voting is to try to accurately reflect the views of the stakeholders.  I don't think this is sufficiently accomplished in the current proposal.

I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support.  This will give a much clearer picture of how the community really feels.

In the current system, in order to "downvote" someone who does something like excludes transactions, you unfortunately must withdraw your support for someone you want to support in order to cast your downvote.  It's also a strange balancing act where the vote you would like to cast is dependent on the votes cast by others.  If a candidate has all the votes they need, you need to go find another candidate to vote for.  If a candidate is going to be downvoted out of being a delegate by others, there's no need for you to use your stake to downvote.

I propose you just vote for any delegate you support.  Delegates are selected on how broad their appeal is to stakeholders.  There could be a minimum of 97 delegates but an uncapped maximum where everyone who has over 50% community support is automatically a delegate.  This seems fair to me.  It would be great if all our delegates had over 50% community support backing them (also gets rid of "magic" number of delegates).

If a delegate messes up it's no problem to withdraw your support for that delegate without affecting your support of others.

Delegates could also see if they have lots of community support or if they are "on thin ice".  If a delegate had a ton of community support e.g. 95%, It might be rational for them to decide to run an additional delegate and they could have 2 delegates.  I might be happy to vote for a trusted core developer to run multiple delegates, say 5 delegates, but at some point I'm not willing to vote for their 6th delegate because I think that is starting to get greedy.  So people with lots of community support can gauge that support and potentially run more delegates than someone with less community support.

357
General Discussion / Re: Community Funding
« on: June 15, 2014, 02:31:55 am »
Quote from: tonyk on June 13, 2014, 10:37:59 pm
We can have everything, organized in everyway possible.

Where are you going with this?

[EDIT] Is this testing the waters for the best possible form of AGS 2.0?
No specific agenda.  I think it could have a lot of applications.

358
General Discussion / Re: Community Funding
« on: June 15, 2014, 02:20:06 am »
Quote from: xeroc on June 14, 2014, 09:05:46 am
We should join efforts on a charity fund .. see my thread about " Bootstraping a charity delegate"!

Definitely.  I'd like to.  I'm mulling over some ideas.

359
General Discussion / Community Funding
« on: June 13, 2014, 09:49:51 pm »
I believe there is great power in community controlled "balance sheets."  We are designing DACs that have many parallels to companies but the only real asset and source of liquidity are the shares of the DAC itself.   For a large DAC this may be a plausible source of funds/liquidity for expenses such as development.  However, many smaller organizations could benefit from organizing on a blockchain with a community controlled fund containing a liquid asset (BTSX/BitUSD?) that they can use to advance the goals of the organization. These organizations are more analogous to standard companies organized financially on a blockchain, not necessarily a DAC, but subgroups on a SuperDAC that allows their formation.

Examples:
Imagine instead of donating to a charity, you opened your bitshares wallet and bought shares of the charity and that was the way to donate.  The charity issues new shares and the money you pay for the shares goes into a fund controlled by all shareholders.  Now you didn't just give your money and trust that it is spent well, but you rightly become part of the charity and get a say in how the money is spent.  You can give the shares as a gift if you like or if you lose faith in the direction of the community you can sell your shares.  The mission of the charity can change with the desires of the current stakeholders. For a pure charity you would expect it to continuously issue new shares to raise money that it spends on charitable projects decided by the vote of shareholders.

If you wanted to raise money for your crypto project.  Instead of doing a standard "IPO" where people need to send you money and trust that you are not a scammer, you can form a group that issues new shares for sale and the money goes into the community balance sheet.  The new shareholders of your crypto project can then decide to pay you a salary out of the community fund to pay for your development work over time.  If you abandon the project or don't update your shareholders to show progress, they can pull the plug on you and dissolve the remaining funds to the shareholders, or hire a new paid developer to continue the work.  The shareholders are partners with the dev working on a common goal and share power.

Think of the balance sheet as a large multisig address where each share is a signature and it requires 51% of signatures to send.  These are "majority rules" organizations subject to a 51% attack like anything else.  So you should only buy shares of groups where you either trust the majority owners or feel that the shares are sufficiently distributed to prevent collusion.  A majority that abuses power will generally be abandoned and find their shares worthless.  Small startups short on trust could potentially have the balance subject to spending limits or trusted 3rd party arbitration.

360
General Discussion / Re: ghash.io at 50%+ ?
« on: June 13, 2014, 02:43:42 pm »
Quote from: gamey on June 13, 2014, 11:42:36 am
To me it sounds like we need to ship DPOS and fork BTC like yesterday.  I personally don't see any other solution.

Better to release BTS XT.  The smart people will switch/sell their BTC in favor of a better solution which will eventually catch on.  For instance:

Quote from: BldSwtTrs on June 13, 2014, 12:15:55 pm
Peter Todd sold half of his bitcoins because of this: http://www.reddit.com/r/Bitcoin/comments/281ftd/why_i_just_sold_50_of_my_bitcoins_ghashio/
Our priority should be offering the better solution.

from the linked discussion: "Crazy when you think about it. A multi billion dollar project and a core developer is worried about paying his rent."

BTC has the problem that the people who figure out there is a problem will just sell their BTC for another store of value (a much smarter move and more expedient than trying to undertake the task of saving all the other BTC holders who can't see the problem).  The people with the means and knowledge to save BTC holders will be the first to divest and will have little incentive to take on the undertaking.  BTC holders will end up representing a less informed population and there's really nothing so special and inherently fair about the BTC distribution that it's value must be preserved at all costs.  BTC has no mechanism of leveraging their huge market cap to pay for work on solutions that benefit all BTC holders.  They can barely pay a handful of developers.

BTC needs "DAC employees"
https://bitsharestalk.org/index.php?topic=4660.msg59152#msg59152

Hopefully Bitshares owners will have such a power to promote and protect their interests unlike BTC holders.  BTC holders are powerless and hoping for a charitable savior.  Some are under the misconception that because the BTC market cap is so huge that it acts like a huge company with big resources and they think "someone is taking care of this and looking out for them" - not the case.

Pages: 1 ... 17 18 19 20 21 22 23 [24] 25 26 27 28 29 30 31 32

Page created in 0.048 seconds with 22 queries.