0 Members and 1 Guest are viewing this topic.
The only way I could think of how voting could be cut out from a wallet or other app would be to change the vote registration from normal transactions including it to a special vote transaction which is paid for in transaction fees by the voter. That way voting would be opt-in always. However any wallet could easily have access to the private keys of the user, and therefore still vote the same.
Quote from: bitsapphire on February 16, 2015, 11:53:03 amThanks everybody for the feedback so far!The way we approach everything in live is pretty simple: Do no harm. And treat others as you would like to be treated.One thing I have learned is to change my position if my position has a known logical flaw or does harm.Before I continue I would like to point out how hardcoded delegate voting works on our thin client. At no point does anybody but the users have access to his private keys. The light client does transaction building in two ways: 1) for single signature transactions everything is build in the client. The Angular app would preset those delegates on each transaction. 2) for future multisig transactions the server builds the transaction with the vote pre-set, then sends the build transaction to the client, which then signs the transaction with his private key. The client can independently verify whether the transaction is OK. The server is in this setup only a relay and can never actually change any transaction as the blockchain would not accept such a forged transaction.So far what I have gathered from this discussion:There is a considerable number of people against the hardcoded proposal.I believe that there is a serious problem with the Nash Equilibrium of the DPOS voting system.The proposed fundraiser is in libertarian terms all OK. It is a voluntary trade and risk taking by all invloved parties, and all parties are individuals rather than collectives. Furthermore a public good is created and payed for by the public without the public taking any coerced risk.The people against hardcoded delegates voiced concerns initially based on the potentially exposed flaw in the DPOS voting scheme, but then dismissed this very problem as invalidFrom my perspective, the reasoning behind being against hardcoded delegates has still not been explained by the people who are against it.As I said, we can do the fundraiser differently, but people who are so vehemently against this approach need to please argue why it is so bad. Can somebody please explain to me what the core problem is?My problem is that because the problem with hardcoding hasn't been defined by anybody of the people against, I am unable to formulate an alternative fundraiser approach. I feel like a physician being told by some of the community to do an operation without knowing what the illness is...The problem with hard-coded delegates is similar to Bitcoin mining pools. Because hashers are lazy and want the best/most consistent returns they transfer their power to pools, this centralizes & gives control of Bitcoin to people who may not have the best intentions. In our case users/voters are lazy and want the best/easiest product and may transfer their power to the 'wallet pools', this would centralize BitShares & give control of BitShares to people who may not have the best intentions. With Bitcoin their lack of decentralisation hamstrings their value despite being the market leader and in our case it would be seriously damaging to the BTS price. So while the libertarian free market can create a solution such as yours our free market response to protect the BTS share price would be to take back control of the forum and treat Moonstone like an infected wallet and warn people accordingly. Thereby maintaining market confidence that we are committed to remaining sufficiently decentralised and around delegates who are voluntarily selected. In terms of the problems of voter apathy and incentivising projects like yours...The solution to voter apathy is reward or punishment. The 5% annual fee in the original whitepaper for not voting, which while unpopular would have mostly addressed the issue, was part of the original design & would also have been infinitely more popular than dilution. Combined with transaction fees at a higher CAP, it would have given us comparable funding. (Unfortunately this is out of the question now that we already have a dilution tax, only voter incentives are now an option.) The solution to attracting third parties to do projects like this besides voluntary delegate positions is transaction fees. Perhaps we need to decide on a standard transaction fee and give a percentage back to whichever third party generated the transaction. (With the understanding that if they ever introduced hard-coded delegates they would be treated as a serious and immediate threat to BitShares.) I also think the blockchain can enter into longer term agreements of up to a year, even though the shareholders of tomorrow will not be the shareholders of today. Why? Being able to attract talented developers and significant projects is extremely valuable to BTS. If a delegate pre-stated their work was conditional on a 6 month contract, even though their work might be finished sooner and we agreed & elected them on that basis but shareholders of tomorrow fired him, then unless those BTS shareholders had a very good reason, they wouldn't be able to attract other significant projects and developers as the blockchain's word would count for very little.
Thanks everybody for the feedback so far!The way we approach everything in live is pretty simple: Do no harm. And treat others as you would like to be treated.One thing I have learned is to change my position if my position has a known logical flaw or does harm.Before I continue I would like to point out how hardcoded delegate voting works on our thin client. At no point does anybody but the users have access to his private keys. The light client does transaction building in two ways: 1) for single signature transactions everything is build in the client. The Angular app would preset those delegates on each transaction. 2) for future multisig transactions the server builds the transaction with the vote pre-set, then sends the build transaction to the client, which then signs the transaction with his private key. The client can independently verify whether the transaction is OK. The server is in this setup only a relay and can never actually change any transaction as the blockchain would not accept such a forged transaction.So far what I have gathered from this discussion:There is a considerable number of people against the hardcoded proposal.I believe that there is a serious problem with the Nash Equilibrium of the DPOS voting system.The proposed fundraiser is in libertarian terms all OK. It is a voluntary trade and risk taking by all invloved parties, and all parties are individuals rather than collectives. Furthermore a public good is created and payed for by the public without the public taking any coerced risk.The people against hardcoded delegates voiced concerns initially based on the potentially exposed flaw in the DPOS voting scheme, but then dismissed this very problem as invalidFrom my perspective, the reasoning behind being against hardcoded delegates has still not been explained by the people who are against it.As I said, we can do the fundraiser differently, but people who are so vehemently against this approach need to please argue why it is so bad. Can somebody please explain to me what the core problem is?My problem is that because the problem with hardcoding hasn't been defined by anybody of the people against, I am unable to formulate an alternative fundraiser approach. I feel like a physician being told by some of the community to do an operation without knowing what the illness is...
Thank you fluxer, I understand the concern now.
From my perspective, the reasoning behind being against hardcoded delegates has still not been explained by the people who are against it.
As I said, we can do the fundraiser differently, but people who are so vehemently against this approach need to please argue why it is so bad. Can somebody please explain to me what the core problem is?
Quote from: blahblah7up on February 16, 2015, 08:57:50 amWhat about something really sugar-coated? Imagine a game which functions as a voting wallet on the back end, with hard-coded delegates. Couldn't something like this be effectively used in an attack against DPoS? A sort of zombie consumer attack?If its as easy we would have been seeing more malware containing wallets by now. There is a reason they don't work - users are extra careful in any situation where they have to use their wallet.Can you imagine anything like that gaining traction as soon as the first report comes out that they are using a backdoor? If they are voting without the users knowing whats to say they don't plan to steal the balances outright? I think you are underestimating the cautiousness involved when it comes to money.
What about something really sugar-coated? Imagine a game which functions as a voting wallet on the back end, with hard-coded delegates. Couldn't something like this be effectively used in an attack against DPoS? A sort of zombie consumer attack?
Regarding the attack vector, IMO its non-existent. Users won't be randomly downloading any wallet of the internet and expose their keys to it. Any wallet which has a certain amount of negativity associated with it would be universally shunned.
Quote from: blahblah7up on February 15, 2015, 02:32:23 pmEspecially as a wallet becomes more polished and professional the potential to attract lay-users who are more apathetic increases, making hard-coding ever more dangerous.This is a very important point that I wanted to bring attention to. People will start downloading the wallet, and they won't care how it's voting.People often call 'voter apathy' a problem but as Stan has said in a recent BCT topic of his, people who don't vote are basically delegating their votes to the people that do vote. Usually, people opt to do this when they know that they don't have the knowledge to make informed decisions, and don't have the time to do the research that would allow them to be informed. Let's call this group 'aware non-voters'.Some people don't vote simply just because they are lazy; let's call these people 'the lazies'.There is also a group of individuals that don't even understand or think about voting at all. In this case, they are implicitly doing the same as the knowingly-ignorant, delegating their votes to the people that do vote; let's call this group 'ignorant non-voters'.By hard-coding delegates, you are exploiting the ignorant non-voters and the lazies, inserting them inside the Moonstone matrix, harvesting the votes that they either don't realize they have, or don't care about. While the ignorant non-voters group is currently small, our targeted demographic will most likely bring many, many more of them, to the point where they will outnumber us by a long-shot. They will all be voting for you without understanding that that is what they are doing, and you will be impossible to vote out.We cannot let this happen, or else DecentralizeEconomics is right. The voting power of the voluntary will be stolen.
Especially as a wallet becomes more polished and professional the potential to attract lay-users who are more apathetic increases, making hard-coding ever more dangerous.
Bitsappire has just uncovered a major flaw in the incentive structure that maintains the security of the Bitshares network: there is a threshold below which there is not sufficient value at stake for a holder to expend the cognitive work of voting. This threshold is different for everybody for whom it's value is not zero or infinite. That is to say that some people will vote with the dust in their wallet and some will never vote in spite of very significant investment.
Bear in mind however that (last time I checked) voting must only occur once and is valid until the voted for delegate ceases operation. So the minimum "Value at Stake" threshold must only be exceeded once for the stake to become "Actively Voting Stake". "Passively Voting Stake" would be the kind held in the hypothetical wallet with default voting settings.
Let us say that the wallet appeals to a specific set of Bitshares users with a generally higher "Value at Stake" threshold for active voting to occur because the cognitive work is greater for them (new user). They may also start with a lower stake (new user), putting them under their unique threshold. All stake held by these users will be "Passive Voting Stake" controlled by the developers of the Hypothetical wallet - not cool.
Whether or not this presents a problem depends on the quantity of stake held by the wallet's user set, the average initial minimum "Value at Stake" threshold for that user set, the rate at which cognitive work diminishes due to familiarity with the platform, the rate at which the quantity of stake of the users in the set breaches the "Minimum Value at Stake" threshold and the compensatory behavior of the stake controlled by users outside that set. And probably a host of other things too but there is enough here to get confused about.
1In the real world this is not a disaster because the "Value at Stake" threshold for veteran users is low due to lower cognitive work required and new users hold comparatively little stake. 2People buy in with small amounts to play, explore and as part of that . . . vote. 3Speculators with strange behavior due to indifference to the platform generally hold their stake on exchanges and even many of them may vote. How many? We can't know but they are the only dark shape in the water. 4Bigger players can compensate for strange voting patterns by re-targeting the voting power of their stake and the community can shout down "Default Voting" wallets - as we've seen.
1This presents an opportunity to study voting passivity that should not be squandered. 2I'd like to see The Moonstone wallet default target a single delegate that pays a charity of the forum community's choosing. This way we can begin to gather data on which to base an understanding of the voting behavior of the new wallets users rather than speculate about it.
If I may raise my hand let's be a bit more meticulous here,Bitsappire has just uncovered a major flaw in the incentive structure that maintains the security of the Bitshares network: there is a threshold below which there is not sufficient value at stake for a holder to expend the cognitive work of voting. This threshold is different for everybody for whom it's value is not zero or infinite. That is to say that some people will vote with the dust in their wallet and some will never vote in spite of very significant investment. Bear in mind however that (last time I checked) voting must only occur once and is valid until the voted for delegate ceases operation. So the minimum "Value at Stake" threshold must only be exceeded once for the stake to become "Actively Voting Stake". "Passively Voting Stake" would be the kind held in the hypothetical wallet with default voting settings.Let us say that the wallet appeals to a specific set of Bitshares users with a generally higher "Value at Stake" threshold for active voting to occur because the cognitive work is greater for them (new user). They may also start with a lower stake (new user), putting them under their unique threshold. All stake held by these users will be "Passive Voting Stake" controlled by the developers of the Hypothetical wallet - not cool. Whether or not this presents a problem depends on the quantity of stake held by the wallet's user set, the average initial minimum "Value at Stake" threshold for that user set, the rate at which cognitive work diminishes due to familiarity with the platform, the rate at which the quantity of stake of the users in the set breaches the "Minimum Value at Stake" threshold and the compensatory behavior of the stake controlled by users outside that set. And probably a host of other things too but there is enough here to get confused about.In the real world this is not a disaster because the "Value at Stake" threshold for veteran users is low due to lower cognitive work required and new users hold comparatively little stake. People buy in with small amounts to play, explore and as part of that . . . vote. Speculators with strange behavior due to indifference to the platform generally hold their stake on exchanges and even many of them may vote. How many? We can't know but they are the only dark shape in the water. Bigger players can compensate for strange voting patterns by re-targeting the voting power of their stake and the community can shout down "Default Voting" wallets - as we've seen. This presents an opportunity to study voting passivity that should not be squandered. I'd like to see The Moonstone wallet default target a single delegate that pays a charity of the forum community's choosing. This way we can begin to gather data on which to base an understanding of the voting behavior of the new wallets users rather than speculate about it.Hope all that made sense.
Quote from: fuzzy on February 16, 2015, 01:24:13 amThough i am of the belief that had they reached out earlier, it would have helped prevent a community pr nightmare...at least they are reaching out now!If them reaching out earlier would have swayed more community members that hard-coding votes into their client is a good idea, then I'm glad they didn't.(Just to be clear, I'm only opposed to the idea of hardcoding delegates, not bitsapphire. Bitsapphire seems to be handling this conversation reasonably, and from the little they have showed so far also seem to be competent developers.)
Though i am of the belief that had they reached out earlier, it would have helped prevent a community pr nightmare...at least they are reaching out now!
We are always here.We just learn to keep our mouths shut.
No wonder the devs aren't active on the forums anymore.
Quote from: fluxer555 on February 15, 2015, 11:42:51 pmI can't think of any kind of innovation which is stifled by not allowing voting transactions. In fact, making voting incorruptible makes for a more fertile environment.In BitShares-land, the people who vote are the ones who have control over the direction of the company. Anyone wanting to "do something we don't like at the moment" simply won't get the chance to do it, as they won't be voted in. If they are voted in and "do something we don't like at the moment", we vote them out.Or that's how it should be, and was designed to be, at least. I think moving toward that design is moving in the right direction.The only way I could think of how voting could be cut out from a wallet or other app would be to change the vote registration from normal transactions including it to a special vote transaction which is paid for in transaction fees by the voter. That way voting would be opt-in always. However any wallet could easily have access to the private keys of the user, and therefore still vote the same.
I can't think of any kind of innovation which is stifled by not allowing voting transactions. In fact, making voting incorruptible makes for a more fertile environment.In BitShares-land, the people who vote are the ones who have control over the direction of the company. Anyone wanting to "do something we don't like at the moment" simply won't get the chance to do it, as they won't be voted in. If they are voted in and "do something we don't like at the moment", we vote them out.Or that's how it should be, and was designed to be, at least. I think moving toward that design is moving in the right direction.
So in your wallet access to the private key of the customer is Ok as well. You will not exist long as a bussines in no world other than your own head.
It would only be catastrophic if their startup required signing voting transactions, which seems unlikely.
I don't actually know if this is feasible or makes sense, but is it possible for shareholders to vote and approve wallets, and have the blockchain be aware what wallet is signing transactions, and have delegates only include transactions from approved wallets?Is there any way of doing this while making spoofing an approved wallet a cryptographic impossibility?If this is possible, we could also write the protocol to allow transactions from unapproved wallets as long as there is no voting in the transactions.
Well, your proposal is certainly an effective way of illustrating this potential flaw.I don't have an imediate answer. But it seems to be a real problem and worth much consideration. I'll certainly think more about it.Maybe it merits it's own thread. But maybe it's already been discussed at length?
Quote from: blahblah7up on February 15, 2015, 06:54:28 pmWhat I mean is, I don't think Bitshares can scale this way as it was inteded to be used. Imagine 50 different projects being developed simultaneously with 3 hardcoded delegates each. If the projects gained enormous traction what would be the result? The postion of a campaining delegate would essentially be dead.I think the Nash Equilibrium of the current form of DPOS voting leads to this, yes. This is a potential flaw that has been discussed here and on other mailing lists.For people who have their doubts about this approach, what do you think should be a realistic game theoretical long term plan for these things not to happen? (Serious question)
What I mean is, I don't think Bitshares can scale this way as it was inteded to be used. Imagine 50 different projects being developed simultaneously with 3 hardcoded delegates each. If the projects gained enormous traction what would be the result? The postion of a campaining delegate would essentially be dead.
@Xeldalas Stan always says, I think: You're not thinking big enough.What I mean is, I don't think Bitshares can scale this way as it was inteded to be used. Imagine 50 different projects being developed simultaneously with 3 hardcoded delegates each. If the projects gained enormous traction what would be the result? The postion of a campaining delegate would essentially be dead.
Quote from: bitsapphire on February 15, 2015, 05:19:45 pmYour wallet (installed on your computer) needs its own multisig key to the multisig wallet. so 101 delegates, each with one key plus 1 key for you. Technically you could as well have just the delegates deal with keys, but why take the chance?Sorry, I'm still not getting it. What balances (and on what blockchain) is this 51-of-102 multisig protecting? What is the point of me having a key in the multisig when I still need to get 50 delegates to agree with me anyway (and with just 1 more delegate they can ignore me and take the funds)?
Your wallet (installed on your computer) needs its own multisig key to the multisig wallet. so 101 delegates, each with one key plus 1 key for you. Technically you could as well have just the delegates deal with keys, but why take the chance?
Quote from: bitsapphire on February 15, 2015, 05:19:45 pmI agree. Technically speaking it is one-sided. Everything happens on BitShares and higher layers of the system (i.e. OT). However, It would be possible to have a two sided true side-chain setup whereas two DPOS chains each with a number of delegates (e.g. 101) lock each other's tokens. I think you misunderstood me. I don't want it to be two-sided because that doesn't scale.
I agree. Technically speaking it is one-sided. Everything happens on BitShares and higher layers of the system (i.e. OT). However, It would be possible to have a two sided true side-chain setup whereas two DPOS chains each with a number of delegates (e.g. 101) lock each other's tokens.
Quote from: bitsapphire on February 15, 2015, 05:19:45 pmWhile it sounds nice, 81-of-101 is useless because the underlying consensus is formed by 51-of-101. So regardless, as long as 51 OT servers agree, the transaction can go through on the Blockchain. It doesn't have to, but the 51 can do a fork any time and change the ledger.It doesn't have to be. You could require unanimous consensus among all 101 delegates if you wanted. All it means is that consensus will fail (the blockchain will be frozen) if they do not all agree. I think requiring more than 20% of the delegates to disagree for them to be able to shut down the blockchain is an acceptable amount. That is unlikely to happen (if it does it will require a majority of the stake to reach a quorum on the replacement delegates) and so we can benefit from the added security that 81-of-101 gives in terms of reducing collusion risk. Also, please remember, these are delegates of the child DAC that I am talking about, not the delegates of the parent DAC. The stake that can replace these delegates exist on the blockchain of the parent DAC.
While it sounds nice, 81-of-101 is useless because the underlying consensus is formed by 51-of-101. So regardless, as long as 51 OT servers agree, the transaction can go through on the Blockchain. It doesn't have to, but the 51 can do a fork any time and change the ledger.
Quote from: bitsapphire on February 15, 2015, 05:19:45 pmI proposed a very similar layered setup about a month ago at one of the BitShares Monday meetings. My proposal is that most DAPPs don't need their own consensus mechanism. You can read up on some of my reasoning here. This means that DAPPs as side-chains don;t need their own consensus token, and as such only need an underlying already established consensus to deal with its database ordering (I'm calling it COP = Consensus and Ordering Protocol). For this you wouldn't even necessarily need OT, but OT would bind the underlying blockchain and the above DAPP ledger coherently together into both directions.I think there are three different approaches here that are not mutually exclusive, meaning they are all valuable. One is what I call a child DAC which does have its own consensus token. The token exists on the parent DAC and is used to elect the delegates that run the child DAC's blockchain (they also act as a safeguard to keep the delegates honest, meaning to not steal reserves that exist on the parent DAC). I think it is important for them to have their own token because that means it is a different set of people who are interested in the services this child DAC will provide. Not all BTS owners will be interested in every DAC service that can ever exist. And while Turing complete scripts/DApps (or DAC extensions which I will talk about a little later) help with this, there are still some limitations with that approach: they are still limited by the scripting model imposed by the DAC they operate on, and it requires burdening the full nodes of that DAC with validation of all the DApps that exist on that DAC. The second approach is a DApp running on the main DAC as part of its consensus process. The DApp of course doesn't need its own tokens nor does it need its own set of delegates. It runs on the DAC and is part of the consensus process of the DAC. This is basically the Turing complete script / smart contract / DApp approach that Ethereum is using. While they are very useful and they are trust-free, the problem with this approach is that all full nodes of the DAC need to validate all state transitions of this DApp (as well as other DApps that exist on this DAC) to keep up with the blockchain consensus. Still, this is very useful because it is trust-free and developers will want to create new services without having to bootstrap a new group of equity holders and get them to elect a group of delegates all over again. The third approach is what I am for now calling DAC extensions. These are DApps (quasi-DApps?) as well but DApps that do not need to be validated as part of the blockchain consensus process. Full nodes can validate the state transitions of the quasi-DApps they care about only, or not bother at all. However, the delegates are required to validate all state transitions of each DAC extension (or quasi-DApp) that is registered and accepted into the DAC. The delegates are free to prioritize the DAC extensions by processing the state transitions inter-DAC-extension in any order they wish, but intra-DAC-extension state transitions must happen in a deterministic order however (think of this as an asynchronous model rather than a synchronous model, or also I think the Actor model is a good analogy here). This approach is actually a lot like the child DAC approach, except that each DAC extension does not have its own consensus token or a new set of a delegates (they use the same delegates as the DAC they exist on). This approach has the benefit of not requiring to bootstrap a new group of equity holders and getting them to elect a group of delegates all over again, just like the previous approach, but it has the disadvantage that it is not as trust-free as the previous approach (delegates misbehaving to move funds around in a way that is not compliant with the rules is valid behavior, though hopefully unlikely, and it is not possible to roll back the blockchain). There are lots of ways of implementing these DAC extensions (or quasi-DApps). Open Transaction could play a role. I was thinking Codius could be useful.
I proposed a very similar layered setup about a month ago at one of the BitShares Monday meetings. My proposal is that most DAPPs don't need their own consensus mechanism. You can read up on some of my reasoning here. This means that DAPPs as side-chains don;t need their own consensus token, and as such only need an underlying already established consensus to deal with its database ordering (I'm calling it COP = Consensus and Ordering Protocol). For this you wouldn't even necessarily need OT, but OT would bind the underlying blockchain and the above DAPP ledger coherently together into both directions.
Quote from: bitsapphire on February 15, 2015, 05:19:45 pmLooks like I've got to read up on your forum history a lot more! Any other threads you'd like me to read up on?Sure, I would recommend checking out these:https://bitsharestalk.org/index.php?topic=13965.msg182455#msg182455https://bitsharestalk.org/index.php?topic=13940.0https://bitsharestalk.org/index.php?topic=13872.0
Looks like I've got to read up on your forum history a lot more! Any other threads you'd like me to read up on?
this thread is so meaningless, because your wallet is not out in the open to get used.and the core dev team is also working on a light wallet, so the question is, is your wallet 130.000 USD worth?I am not sure and not qualified to check the technical work, so i could only talk if i can use your wallet.I get a feeling you are not telling everything, so we don't get the big picture.It would be easy to publish your wallet, make it open source and charge a little bit higher transaction fee. You could easily get elected for 1-4 delegates maybe (this will cover your expenses over time)But you didn't choose this road, you choose the "pay me upfron" road, the quick road! From your perspetive the work is done, but from the community perspective this is coming out of the blue. I am undecided!
I see why people get emotional about the hardcoding. However, as a shareholder people should reflect and think what their actions mean for the ecosystem as a whole.
Nothing is mandatory, nobody pushes people to use the Moonstone wallet. Everything is opt-in. Example: If you don't like Dropbox storing your data in the cloud, don't use it. If you don't like Bitcoin being pseudonymous rather than anonymous, don;t use it. It's all inherently opt-in.
[1] You started it but for the last 6 mo. you have worked on their wallet. How much are they paying for it? If nothing why BTS has to pay for it?[2] Holding somebody hostage is also and in its firstmeaning should I add - "Give me money... or you do not get what you like (love) - our wallet!"{3} I continue to not understand how paying 1:1 for just small % of all IOUs at a time is actually buying them 1:1. just a fraction can cash at a time or they will have to take a discount???
You asked for the community's opinion, you are getting it. As you say there is nothing stopping you from doing what you want. But if you are asking the community, I suppose that means that you are aware that alienating your customer base wouldn't be a strategic choice. So it would be a good idea to take into account the quasi-unanimous rejection of the use of hardcoded delegates and find a more politically-correct model of funding your developments.Here is what you can do: do your fundraising but instead of hardcoding delegates to pay back investors, you can go for a combination of regular voted delegates, double licensing GPL3 (free) + MIT (paying customers), and freemium model with a free basic version and a premium version for a fee. If your client is good, and with the right incentive (moving the project to unrestricted MIT license), I see no reason why the shareholder won't want to vote your delegates in. You could even keep the delegates after the payback period is over and use the proceeds to maintain the client and make it evolve.
If your client is good, and with the right incentive (moving the project to unrestricted MIT license), I see no reason why the shareholder won't want to vote your delegates in.
Quote from: tonyk2 on February 15, 2015, 05:05:40 pm I am with you.Their choice of answering only the question that they like last night and completely disregarding my concerns did not help either. Just reconfirmation of their arrogance...I have answered the concerns just above your comment.I see why people get emotional about the hardcoding. However, as a shareholder people should reflect and think what their actions mean for the ecosystem as a whole.You can't control for what developers will come up with in the future. The primary reason why Bitcoin took off and so much capital is flowing in Bitcoin startups is because they did not need to ask anybody for permission to do so. Doing anything but welcoming every new project is counterproductive.With DPOS, for the first time it is possible to fund or compensate public goods without game theoretical problems of apathy and free riders. This system does not however solve the problem of the massive coordination problem of the public. That's generally what board of directors are for in companies. I have never seen a startup become successful if the shareholders decide on the direction of the company rather than a CEO or board. Unfortunately Bitshares does not have that.This is why it is necessary for people to take on risks and then propose the finished solution to the public (what we are doing). Under the current delegate paradigm politics and PR mattered more than results. I know some people would disagree but this is how democracy works.We on the other hand produced a product for market fit, not vote-fit. We believe this is how the market cap of Bitshares will increase in value from now on, not through popular votes but through hard upfront work.In our proposal we took the initial (big) risk, asked for nothing in return, make it possible for visionary individuals to put their money where their mouth is and support us with this fundraiser, and if it works the risk taking individuals get paid off by the public because a public good has been produced.What we are proposing is effectively the crypto equivalent of the highly effective and awesome (and free market libertarian approach) of a Social Impact Bonds, also called Pay For Success Model. Government centric approaches and examples can be seen here.The questions were inflammatory.The alternative proposal by shentist is rational but does not account for the risk setup of this effective trade between the public and a company for the release of a public good.Quote from: tonyk2 on February 14, 2015, 11:23:23 pmInvestors in the IOU: - investing in BTS but being paid in USD, in up to 1-3 years if ever. - how is this 1:1 conversion gonna work? The IOU holders will sell for discount? Good for them.People want to diversify. Not everybody is 100% in BTS. The fundraiser will be both in BTS and BTC. At the end of the day, most people we talked to are interested in getting a return in USD terms, not BTS terms. Delegate reimbursement is a risk the donors take due to their rational calculations. There is no return without risk.BTS and BTC get converted into fiat for our expenditures. On the donation page they get a ticker for the current conversion rate. A UIAs gets sent to their donation private key immediately after 6 BTC confirmations or 101 delegate confirmations. Delegate BTS income gets converted into bitUSD on the system and buys up 1:1 the UIAs.Quote from: tonyk2 on February 14, 2015, 11:23:23 pm BTS holders: - let give some of our BTS to this project so the devs can dumpr them on us right away. - let's have mandatory voting and diluting of our shares. The more sucsesfull the wallet the more wallet users (aka BTS holders) will have forced/no-choice voting.Nothing is mandatory, nobody pushes people to use the Moonstone wallet. Everything is opt-in. Example: If you don't like Dropbox storing your data in the cloud, don't use it. If you don't like Bitcoin being pseudonymous rather than anonymous, don;t use it. It's all inherently opt-in. Quote from: tonyk2 on February 14, 2015, 11:23:23 pmNow I kindly suggest you go and try to sell this to the one who actually ordered it - PeerTracks.If they do so we will not mind using it on BTS for free btw.We started our wallet efforts 2-3 months before Peertracks even was a thing. See this thread. Very inflammatory way of doing discussions might I say.[1]Quote from: tonyk2 on February 14, 2015, 11:23:23 pmPSJust a quick question - What qualities do you think you (and your wallet) have to think that the dev, making the backbone behind your wallet do not deserve to pre-sale their product and to hold BTS hostage but you can/should do so?Invictus did pre-sell both BitShares and and their wallet. Just as we are proposing so too did they promise a potential return to donors who were bold enough to believe in the vision. The end product would also be a quasi-public good. We are not re-using any uniue part of the current BiShares wallet, the architecture choices are just too divergent.Holding something hostage implies that somebody (maybe you?) feel like you are entitled to somebody else's work and time without anything in return.[2] That is everything but a libertarian and/or free market attitude.
I am with you.Their choice of answering only the question that they like last night and completely disregarding my concerns did not help either. Just reconfirmation of their arrogance...
Investors in the IOU: - investing in BTS but being paid in USD, in up to 1-3 years if ever. - how is this 1:1 conversion gonna work? The IOU holders will sell for discount? Good for them.
BTS holders: - let give some of our BTS to this project so the devs can dumpr them on us right away. - let's have mandatory voting and diluting of our shares. The more sucsesfull the wallet the more wallet users (aka BTS holders) will have forced/no-choice voting.
Now I kindly suggest you go and try to sell this to the one who actually ordered it - PeerTracks.If they do so we will not mind using it on BTS for free btw.
PSJust a quick question - What qualities do you think you (and your wallet) have to think that the dev, making the backbone behind your wallet do not deserve to pre-sale their product and to hold BTS hostage but you can/should do so?
just curious about - any progress on forum update etc!?
You asked for the community's opinion, you are getting it. As you say there is nothing stopping you from doing what you want. But if you are asking the community, I suppose that means that you are aware that alienating your customer base wouldn't be a strategic choice. So it would be a good idea to take into account the quasi-unanimous rejection of the use of hardcoded delegates and find a more politically-correct model of funding your developments.
Here is what you can do: do your fundraising but instead of hardcoding delegates to pay back investors, you can go for a combination of regular voted delegates, double licensing GPL3 (free) + MIT (paying customers), and freemium model with a free basic version and a premium version for a fee. If your client is good, and with the right incentive (moving the project to unrestricted MIT license), I see no reason why the shareholder won't want to vote your delegates in. You could even keep the delegates after the payback period is over and use the proceeds to maintain the client and make it evolve.
I see why people get emotional about the hardcoding. However, as a shareholder people should reflect and think what their actions mean for the ecosystem as a whole.You can't control for what developers will come up with in the future. The primary reason why Bitcoin took off and so much capital is flowing in Bitcoin startups is because they did not need to ask anybody for permission to do so. Doing anything but welcoming every new project is counterproductive.
With DPOS, for the first time it is possible to fund or compensate public goods without game theoretical problems of apathy and free riders. This system does not however solve the problem of the massive coordination problem of the public. That's generally what board of directors are for in companies. I have never seen a startup become successful if the shareholders decide on the direction of the company rather than a CEO or board. Unfortunately Bitshares does not have that.This is why it is necessary for people to take on risks and then propose the finished solution to the public (what we are doing). Under the current delegate paradigm politics and PR mattered more than results. I know some people would disagree but this is how democracy works.We on the other hand produced a product for market fit, not vote-fit. We believe this is how the market cap of Bitshares will increase in value from now on, not through popular votes but through hard upfront work.In our proposal we took the initial (big) risk, asked for nothing in return, make it possible for visionary individuals to put their money where their mouth is and support us with this fundraiser, and if it works the risk taking individuals get paid off by the public because a public good has been produced.What we are proposing is effectively the crypto equivalent of the highly effective and awesome (and free market libertarian approach) of a Social Impact Bonds, also called Pay For Success Model. Government centric approaches and examples can be seen here.
we intend on following through with the above steps (unless the community gives us at this point good counter arguments or better proposals).We’d love to get input from the community. What do you think?
I see why people get emotional about the hardcoding. However, as a shareholder people should reflect and think what their actions mean for the ecosystem as a whole.[...]This is why it is necessary for people to take on risks and then propose the finished solution to the public (what we are doing). Under the current delegate paradigm politics and PR mattered more than results. I know some people would disagree but this is how democracy works.
@bitsapphire, fantastic! Thanks for your responses.Regarding the OT voting pools with DPOS delegates...Quote from: bitsapphire on February 15, 2015, 01:13:31 amSure! OT voting pools solve the exchange and deposit problem of crypto tokens. You can read up on it here. The only problem OT pools have is that they are certified through traditional means such as SSL. Therefore OT pools will always be politically centralize (as opposed to blockchain solutions which are politically decentralized). We have come to the conclusion that blockchains primarily solve the issue of political centralization, and with it counterparty risk. By combining OT with DPOS it is possible to "certify" OT nodes with delegate public keys. For every blockchain being bound to OT/Bitshares this way you would need at least one 51-of-102 (plus 1 client key) multisig address who's multisig keys are held by the delegates. To make it possible for the multisig keys to be held by changing delegates we would need to create a special contract on BTS which defines that all currently active delegates' priv keys are viable. Now, this does not solve the multisig key for Bitcoin, but it does for Bitshares and potentially any turing complete chain. Effectively, any chain could become a sidechain of Bitshares. Still, A randomized pool of 15 Bitshares delagates could serve as a bridge between Bitcoin, Bitshares, and therefore any crypto token.The nice thing about this proposal is that the 15 Bitcoin multisig OT/delegate oracles could issue a Gateway IOU on Bitshares representing the BTC, and as such make it liquid and tradable with any asset on Bitshares.I am a little confused about the 51-of-102 multisig address. First, what is the extra client key?
Sure! OT voting pools solve the exchange and deposit problem of crypto tokens. You can read up on it here. The only problem OT pools have is that they are certified through traditional means such as SSL. Therefore OT pools will always be politically centralize (as opposed to blockchain solutions which are politically decentralized). We have come to the conclusion that blockchains primarily solve the issue of political centralization, and with it counterparty risk. By combining OT with DPOS it is possible to "certify" OT nodes with delegate public keys. For every blockchain being bound to OT/Bitshares this way you would need at least one 51-of-102 (plus 1 client key) multisig address who's multisig keys are held by the delegates. To make it possible for the multisig keys to be held by changing delegates we would need to create a special contract on BTS which defines that all currently active delegates' priv keys are viable. Now, this does not solve the multisig key for Bitcoin, but it does for Bitshares and potentially any turing complete chain. Effectively, any chain could become a sidechain of Bitshares. Still, A randomized pool of 15 Bitshares delagates could serve as a bridge between Bitcoin, Bitshares, and therefore any crypto token.The nice thing about this proposal is that the 15 Bitcoin multisig OT/delegate oracles could issue a Gateway IOU on Bitshares representing the BTC, and as such make it liquid and tradable with any asset on Bitshares.
Second, does this exist on blockchains other than the BitShares blockchain? If so, how does it know who the 101 active delegates are when that information is on the BitShares blockchain? Are these blockchains expected to monitor the BitShares blockchain as well as part of their consensus algorithm? The nice thing about the BitShares standard gateway idea I linked to in my previous post is that it doesn't require any modification from the blockchains that will be holding the assets that the BitShares delegates can collectively manage. Even with the annoying ECDSA limitations on threshold signatures, as long as you assume at least 90% of the delegates will cooperate, you can manage funds on Bitcoin or any other ECDSA-compatible coin (no Turing complete scripts or fancy multisig features needed) where the security of those reserves can only be compromised by a colluding group 46 active delegates.
The sidechain idea is also very interesting to me. But the way you described it seems backwards to the way I think of it. I think the delegates of BitShares shouldn't be the ones that have to monitor or be active on the other blockchain at all (with the exception of a few key coins with large network effect, like bitcoin, for which we would want to implement either a BitShares standard gateway or the other escrow-based BitBTC/RealBTC system I described in my previous post). The monitoring and transaction signing should be in one direction only for the sake of scalabilty (this way large number of side DACs can integrate with BitShares without the delegates even needing to do anything extra to accommodate them).
This means instead of sidechains / side DACs, it is more of a parent DAC and child DAC relationship. A child DAC has a special M-of-N multisig account (perhaps 51-of-101, or maybe a stricter 81-of-101 would be better) on the parent DAC's blockchain. Better yet, the account could use Schnorr threshold signatures to save space with smaller transactions that only need 1 signature instead of 81. This special account would be controlled by 81 of the 101 active delegates of the child DAC. As the delegates gradually change, the super majority of the old delegates (who would also still be the super majority of the new delegates) would have to change ownership of the account to another 81-of-101 with the updated set of 101 active delegates. So, the child DAC would be responsible for providing this information to the parent DAC rather than expecting the parent DAC to look at the child DAC's blockchain for this information (otherwise we would have to require all full nodes of the parent DAC to also be full nodes for all C children DACs of the parent DAC).
This special account could hold assets on the parent DAC, such as BitUSD, which it can then use as a reserve to back the assets on the child DAC's blockchain, such as a BitUSD derivative. Finally, the core stake of the child DAC (the one that votes on the 101 delegates) would actually exist in the parent DAC (the child DAC would simply monitor the ownership and slate update changes of the stake in the parent DAC. The reason for this is that it allows the stakeholders to ultimately be in control of the child DAC (and its reserve assets) by forcefully changing the special multisig account if the necessary quorum is reached by the stakeholders (it also allows them push the panic button and stop the super majority of delegates from stealing all the reserves in case they decide to go rogue). You can read more about this proposal here if you are interested.
Very nice scheme...everyone stays to lose but bitsapphire devs.Investors in the IOU: - investing in BTS but being paid in USD, in up to 1-3 years if ever. - how is this 1:1 conversion gonna work? The IOU holders will sell for discount? Good for them. BTS holders: - let give some of our BTS to this project so the devs can dumpr them on us right away. - let's have mandatory voting and diluting of our shares. The more sucsesfull the wallet the more wallet users (aka BTS holders) will have forced/no-choice voting.Now I kindly suggest you go and try to sell this to the one who actually ordered it - PeerTracks.If they do so we will not mind using it on BTS for free btw.[disclosure] I have (will have) slightly bigger stake (percentage wise) in Music than in BTS.PSJust a quick question - What qualities do you think you (and your wallet) have to think that the dev, making the backbone behind your wallet do not deserve to pre-sale their product and to hold BTS hostage but you can/should do so?
would be nice to see it in action.1. you made it really complicated and for this reason it is a bad offerquestions:- you developed it for the MUSIC community and make at also available for BTS, but to use it without restriction you want to get 130.000 USD upfront and why only from the BTS community? Why not wait for the liquidity of NOTES and ask the community for money as well?why not just start with a higher transaction fee and let the community know, if the amount of 130.000 USD is reached you will make it to a MIT license? Is converting to a different license not possible? Do you need this money upfront?
Hardcoded delegates are a strict no-no. I will actively warn anyone from using it and will probably just stop short of calling you a scammer.(I like you guys, just wanted to point out how strong emotions having hardcoded delegates will evoke.)
Quote from: blahblah7up on February 15, 2015, 02:32:23 pmThis is indeed a very bad idea. Hard coded delegates have no place in Bitshares. Perhaps in MUSIC which is slowly becoming a closed source nightmare. Especially as a wallet becomes more polished and professional the potential to attract lay-users who are more apathetic increases, making hard-coding ever more dangerous.I will not only boycott this project, but do my part to actively inform about and lobby against this wallet.
This is indeed a very bad idea. Hard coded delegates have no place in Bitshares. Perhaps in MUSIC which is slowly becoming a closed source nightmare. Especially as a wallet becomes more polished and professional the potential to attract lay-users who are more apathetic increases, making hard-coding ever more dangerous.I will not only boycott this project, but do my part to actively inform about and lobby against this wallet.
If the quality is good I would support some number of delegate positions anyway, hard-coded or not, especially with making it open source. Its a clever way of monetizing it. Nothing is free. It might have a greater effect to give people the option to not vote from the beginning, I think most would simply let it be. I understand there are many options and you have to do what makes the most sense for you and your model. Either way I think it will work out . You'll likely be providing a much needed alternative to the space on various fronts. Thanks for your work. I'm interested in what you have done for making it "modular" , There has been some talk about this and I think its an area of great potential.
Your payback model assumes people will be storing a lot of BTS on your light wallet. What if most of the usage is with BitAssets instead (which have no delegate voting power)? Also, I would expect people would want to store most BTS stake in cold storage and be able to use the restricted_owner feature to update votes from their light wallet (but not be able to spend it from the hot client). So will you support that functionality? That is a good way to get large BTS stake to vote for your 3-5 hardcoded delegates even though they don't actually store most of it on the wallet.
You are verifying that the built transaction provided by the server is correct before signing though, right? Otherwise that is way too much trust given to your servers.
Also, the client should allow pinning contacts to the address book and complain if the transaction that was meant to send funds to that user is instead sending funds to a different public key than the one that was pinned in the address book (trust on first use principle, with added ability for users to manually verify public keys of contacts using out-of-band methods). I've written more about this here.
By the way, does the wallet that you have already written support the exchange/markets functionality of BitShares? If not, do you plan to build support for that in your lightweight client?
Can you please comment more on this?I want to see if we are thinking along the same lines here. Let me quote what I wrote in the nullstreet forums in response to tonyk's BTC on- and off-ramp proposal:Actually, I think you may be talking about multisig voting pools. Meaning the actual BTC being held by a multisig controlled by the delegates? The problem with this is that Bitcoin has strict limits that prevent making this sufficiently decentralized. Threshold signatures help with this, but they also have some annoying limitations when you are forced to use ECDSA. I have discussed this in my post on the "BitShares Standard Gateway". I think this approach has some uses, but as an on- and off-ramp there is even larger counterparty risk with this method than the one described in the quote above.
Yes. However we are using the copay signature transaction and building architecture as inspiration. The angular app does not build any transactions client side, it only receives already build transactions from the server and signes them.
2. Yes, however not like MetaExchange. We think DPOS solves the node certification issue of Open Transactions (OT) voting pool servers. Every DPOS delegate is an already trusted certified node by the stakeholders. Adding an additional layer whereas every delegate is also an OT federated server makes it possible to have counterparty risk-less instant transactions as well as trade any crypto token on the Bitshares decentralized exchange. No more crypto exchanges, no more lost funds. Everything happens through the wallet and the Bitshares decentralized exchange. We are currently waiting for the Monetas people to release the federated server setup to start adapting it for Bitshares.
Alice has BitBTC and wants to exchange it for BTC. Bob has BTC (as well as a little bit of BitBTC already) and wants to exchange it for (more) BitBTC. There is a special BitBTC/RealBTC exchange on the BitShares system. Since the BitShares blockchain cannot actually hold real BTC, the bid orders for BitBTC on this BitBTC/RealBTC exchange are actually requests to buy the BitBTC with real BTC and with some BitBTC provided as a surety bond to ensure payment of the real BTC in a timely manner.Let's say Alice places an ask order for 2 BitBTC at a price of 0.99 BTC/BitBTC and the ask order also has her BTC address (1A...). Bob sees this ask order and matches it with his bid order for 1.5 BitBTC at a price of 0.99 BTC/BitBTC. His bid order includes 0.15 BitBTC to be used as part of the surety bond (let's pretend that the market requires that 10% of the BitBTC quantity of the bid must be posted as the surety bond). Bob's bid order also includes his BTC address (1B...) from which he is expected to send the BTC payment to Alice's Bitcoin address.Once these two orders are matched, Bob's 0.15 BitBTC joins Alice's 1.5 BitBTC and gets locked as collateral in a special escrow contract. At this point, Alice will still have an ask order for 0.5 BitBTC at a price of 0.99 BTC/BitBTC in the order book. This escrow contract requires a delivery confirmation to occur within 24 hours for the entire collateral to be send to Bob. The delegates monitor the Bitcoin blockchain for a total transfer of at least 1.485 BTC (1.5 BitBTC * 0.99 BTC/BitBTC = 1.485 BTC) from 1B... to 1A... between the time the orders were matched until 24 hours after that. If that condition is met, the delegates will sign off on the delivery confirmation for that escrow contract. Once a super majority of the active delegates have signed off on the delivery confirmation of the escrow contract (prior to the 24 hour expiration time), the delivery will be confirmed and all the collateral (1.65 BTC) will be sent to Bob. If this does not happen prior to the 24 hour expiration time, then all the collateral will instead go to Alice.Bob has to put some BitBTC up so that attackers who want to just cause damage to BitBTC sellers are discouraged. If Alice is forced to lock up some BitBTC for 24 hours without getting payment for the promised trade, she will at least be rewarded with 10% profit after the 24 hours. If Bob trusts the delegates to do their job, he should be confident that he will get back his surety bond and will also get the 1.5 BitBTC he was promised as long as he delivers the 1.485 BTC from his 1B... address to Alice's 1A... address within 24 hours (it is best to not leave it to the last hour to ensure the delegates have enough time to sign off on the delivery confirmation).
I think you guys should just apply for the delegates, no funding phase. 4 delegates, one for each developer. If you are confident that your wallet will increase the BTS market cap, then this will pay for itself. No need to offload your risk to the shareholders, you already committed to take on the risk when you committed months to developing this.
Your proposal is uncomfortable and feels hostile because you are holding your work hostage. On top of this, you have the intention to unnaturally get voted in through hard-coded delegates, which also gives the feeling that you are not confident enough in your own abilities and/or the future of bitshares.
1 Has PeerTracks and Play paid for any of the development?2. Is there any plans to integrate some type of BTC wallet or projects like MetaExchange?3. I'm in full support of projects that add to the ecosystem to go after funding,however the idea of hard coded delegates seems like a slippery slope.
I actually agree with this sentiment. However, from this point on it would be a free market for Bitshares wallets. That means that people can choose which wallet they want to use, and they can choose which term of service they are ok with. Furthermore, the risk of donors not to get their money back would most likely be too great.Not to mention that instead of asking for delegate money upfront we almost completely developed the wallet with our own money and then put forth the proposal to the community.
Quote from: robrigo on February 14, 2015, 11:03:54 pmI assume PeerTracks is going to use a custom moonstone wallet to handle all of the users funds. This is slightly off topic but have you made any progress on how users will go from their Credit Card to BitAssets (NoteAssets?) on the PeerTracks system? Is the music team / bitsapphire working on any on ramps or relying on those to be built?PeerTracks using a custom version of our wallet is the plan, yes.Unfortunately I can't disclose anything about PeerTracks (NDAs), however Cob should be able to do a forum or mumble session very soon. March is when everything will be unveiled.
I assume PeerTracks is going to use a custom moonstone wallet to handle all of the users funds. This is slightly off topic but have you made any progress on how users will go from their Credit Card to BitAssets (NoteAssets?) on the PeerTracks system? Is the music team / bitsapphire working on any on ramps or relying on those to be built?
I will boycott and actively lobby against this wallet if there is a hardcoded-delegate version released as the official version.Hardcoding delegates sets a very, very bad precedent. We do not want to walk down that road.
Aren't there at least to other light wallets in developement: Yunbi and Valentine? Why another one?
Step 2 says "Sign up online or install the wallet on your PC". Does that mean moonstone will have a web wallet interface on top of a native client?
Excited to see what you've created!Essentially the $130,000 fundraiser-loan allows the community to "buy" an MIT license. Do I understand correctly?Assuming BTS stays around 1 cent, 4 delegates would make $130k in 25 months.. what are the plans for your delegates at that point?You say hard-coded delegates.. users will still be able to unvote, right?
Nice fundraising ideas with the ious .. as roadscape mentioned .. what will happend after ious are bought back ... or .. what id the hardcoded delegates wont make it into the top 101?
The wallet will have 3-5 hardcoded delegates. All proceedings from the delegates will be converted to bitUSD. 100% of these bitUSD will be used to set 1:1 buy orders for the Bitsapphire UIAs you received.