Moonstone - New Bitsapphire Wallet: Fundraiser proposal

[BTSdac]

good idea ,is it easy to get money from Venture?

[bitsapphire]

To everybody following this thread:

This is our new opt-out proposal. Please continue the discussion here.

Thank you everybody for the valuable feedback!

[CLains]

Can't wait to see the wallet 

The difference between hardcoding the vote into the wallet and setting it as default with an unchecking option is absolutely trivial in practical terms. You'll have a few fractions of a cent lazy unchecking, meanwhile if you hardcode you'll have 20ish percent of the crazy fighting your wallet.

Best of luck either way!

[fluxer555]

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.

Considering that any wallet which shares private keys to anyone besides the user would be considered malware, why is this not a viable solution?

[hpenvy2]

"Thank you Empirical. Finally a sane answer."

I don't know if implying all other responses are insane is the best way to gather support. When I see a working product, I will make a decision if it's worth investing any money. With a lightweight client already in development, I just don't see the immediate value at $130,000. I have no issue with anyone making a proposal, best of luck.

[bitsapphire]

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 invalid

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?

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.

Thank you Empirical. Finally a sane answer.

We are currently discussing alternative approaches with the team.

That said, we will also explain our views on the potential attack vector via preset delegates.

[blahblah7up]

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 invalid

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?

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...

Translation:

Everything is OK!

Here are some technical details to blow smoke over the central issues everyone here is worried about and actively discussing!

Despite almost unanimous dissent, we will go ahead as planned and ignore the opinion of the community!


Good Luck!

[blahblah7up]

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.

wtf?

[Empirical1.2]

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 invalid

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?

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.

[sumantso]

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?

'coz you're essentially doing a backdoor entry and making the choice for the users. Maybe you're good, but once precedence is set others will follow and sooner or later there will be somebody putting malware. As a community we wouldn't like users getting into the bad habit of being comfortable with their choice taken away and will do all we can to warn them.

In anycase, forget about all these - go ahead and release it. Lets see if it works in practice, it will be a great test in real life. As far as I can see, this attack is impossible to succeed, but don't take my word for it.

[bitsapphire]

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 invalid

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?

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...

[blahblah7up]

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?

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.

Ok thanks. These are good points.

[sumantso]

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?

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.

[blahblah7up]

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.

But did you read this explanation sumantso?

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.

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.

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?

[fuzzy]

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.

Yes.  Major flaw? Not too sure...theoretically people would vote in times of great discord when their votes count most.  That might even mean simply selling their shares, thus putting them into the hands of someone who still wishes to remain in the system who is far more likely to vote with said stake. 

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.

No.  Once a person sends their funds or spends some of them, they are also "passively voting" stake.  In essence, though they are voting for no one, they are still voting.  A vote not to vote is still a vote.  Will the recipient of these funds turn around and vote?  I guess that is a topic you are trying to wrap your head around with this post. 

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.

First of all "cool" and "not cool" are not necessarily the way to describe it.  The big issue is a lack of communication with the community.  If bitsapphire is wanting to release an announcement about what they are wanting to do, it is a good idea to first get the buy-in of the community to assess what they think.  This gives the community the opportunity to give feedback.  It also gives bitsapphire the ability to explain misunderstandings in their intentions.  Like it or not, a forum is a great place for asynchronous communication but a terrible way to efficiently get feedback.  This is the entire reason why they have a server at their disposal free of charge to them.

Now, to the larger point made above, we first must assume that this wallet will be easier to use than the bitshares wallet, and also easier to use than another light wallet (which may or may not enable its users to vote), and would ultimately need to account for different demographics.  This would require first qualitative research--for instance a user's:
1) socio-economic status
2) gender
3) confidence in ability to adequately use the wallet
4) confidence in ability to adequately vote from the wallet
5) has the user used the wallet?
6) has the user voted from the wallet?

This data would need to be assessed over a number of competitors in addition to Moonstone's wallet.

This would also require gathering of quantitative data most likely in the form of:
1) user surveys with point scales
 1a) 1-10 difficulty measurements
 1b) 1-10 voting interest
 1c) etc...

2) Additional data points that the wallet can passively access to gather:
  2a) Number of shares owned at the time of the survey
  2b) Average number of hours spent using wallet daily (in hours per day)
  2c) How many months the user has had an active account
  2d) How many times has the user used the wallet?
  2e) How many times has the user voted from the wallet?
  2f) etc...

As you can see this is not an easy thing and I have only SCRATCHED THE SURFACE of what would be entailed. 

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.

1) The average initial minimum "value at stake" threshold for a user set must first enable us to define the user set.  Ideally this would actually need to be assessed for multiple user sets. 
2) The Rates at which the "cognitive work diminishes" is something measurable but, again, is very costly and time consuming to attain.  And this isn't even talking about guaranteeing accuracy!  When we get into needing user set(s) (as in the plural) we need to account for all of them across a broad spectrum.
3) That host of other things needs to be defined if we are looking at this from a scientific (and costly) approach.  It gets more confusing NOT defining them. 

¹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.

1) The points you make here kind of call into question whether this is a major flaw at all.  You do see that, right?
2) We cannot be certain that this is true until it is tested.  Many people buy heavily into ecosystems they find valuable for a host of reasons.
3) If speculators tend to hold large sums on the exchange; can they vote?  Maybe they can--this is an honest question.
  3a) Do they have an indifference to the platform?  many speculators are just in it to get more bts in the long run by day-trading..and thus their behavior may not be strange at all to someone well-versed in day-trading.  In fact, their behavior might actually be predictable!
  3b) If they can vote, how many do?  This is actually not unknowable if the exchanges enable voting with stake from the exchange (OR if the exchange has a way for us to gain access to the information regarding who owns which account and who voted with it) 
  3c) They are not necessarily just dark shapes in the water...statistics proves this.
4) This is another place that shows us how powerful it is to get the community together in a place where communication is very efficient (not typed) until a solution is ironed out that most people agree upon.  Wisdom of the crowds man! 

¹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.

1) Squandered might not be the right word to use here as it implies a wasted opportunity that is well within reach given current resources and crypto-landscape.  We are not ethereum with their government grants (aka dark money from goldman sachs and other banking oligarchs, filtered through "legitimate" channels). 
2) I am unsure how payment to a charity of the community's choosing would do anything to get reliable data. 
  2a) given we have not assessed any of the points I made above
  2b) given that we will almost certainly not have 100% consensus on the charity of choice, and therefore it cannot be used to measure anything unless we have an established way of weighting it based on statistical significance gained from quantifiable data on forum votes. 
  2c) a simple forum poll would not give us this data...because it is prone to sock puppet accounts voting more than once.  I personally use the polls...but it is not good if we are going to really consider it truly scientific measurement. 

To begin understanding voting behavior...I believe we need to really start doing a lot of high-quality scientific research.

Hope I'm not sounding like an A-hole...I wouldn't say these things if I didn't think we all needed to recognize them for what they are though.