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. 

[sumantso]

Seeing as they are still sticking to the hardcoded delegate proposal even in the face of complaints by the community, I am starting to doubt the intentions of these people. Regardless, even if I believe they are good guys I will still call them out as scammers and try and scare off any potential users ("these guys are nice, but don't use their wallet" won't have much of the desired effect).

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.

[xeroc]

The proposal will feel alot less "harmful" if you would publicly discuss running it through a middle man like most devs are doing ..
that way we don't need to trust the same party that has the delegates hard coded in there software ...

please also refrain from an opt-out after funds have been raised and instead go towards an opt-in ..

[Troglodactyl]

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.

Hard coding delegate votes has been discussed before, so even if it was a major flaw (which I don't think it is) it isn't a new one.

In order to hard coded votes to matter, the wallet needs control of private keys controlling significant stake, which requires trust and significant adoption.  In order to get trust and significant adoption, it needs to be open sourced, and the developers need to convince people to trust their work.  If it's open sourced, and the developers try something nasty and unreasonable with hard coded votes, people will fork out the votes.  I don't really see the flaw in the incentive structure here.

[legendface66]

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.

[fuzzy]

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!

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

i am simply saying that reaching out and being active with your investors alllows them to give you input before you make a decision on how to move forward.  If there was more community involvement, they likely would never have let the hardcoded delegates get into the announcement and would have worked with the community to find viable alternatives.

[fluxer555]

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!

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

[fluxer555]

We are always here.
We just learn to keep our mouths shut.

Stan, I'm dying to know your thoughts about bitsapphire's proposal...

[Stan]

We are always here.
We just learn to keep our mouths shut.

[carpet ride]

No wonder the devs aren't active on the forums anymore.

I am not so sure that we have decreasing dev participation

[fuzzy]

We will be having a hangout soon with bitsapphire about this and I look forward to .  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!

Lets keep this going and we can set something up for sometime soon.  Perhaps we can have it on bitshares PLAY's usually date and time since it is a chinese holiday!

[fluxer555]

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.

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.

If I'm understanding correctly, this would mean that in order to vote, the wallet would either need to be a full client, or the light wallet provider would need to know the user's private keys. Since any wallet which exposes private keys to a centralized identity is extremely dangerous, this kind of wallet would be seen as an attack and private-key harvesting malware, and would not make it far in terms of adoption. Any non-light client would also not make it far with the masses, as these are inherently resource intensive and take quite a bit of dedication to run and maintain for the user.

Considering all this, your solution seems to be viable.

Out of curiosity, if this was indeed implemented, how would this affect your proposal?

[bitsapphire]

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.

tonyk this is extremely disrespectful and ignorant of you. The wallet won't have access to any private keys. No wonder the devs aren't active on the forums anymore.

[zerosum]

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.

[bitsapphire]

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.

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.

[fluxer555]

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.

[bitsapphire]

It would only be catastrophic if their startup required signing voting transactions, which seems unlikely.

"We don't stifle innovation and growth... just fill out these papers first and don;t do anything we don't like at the moment" How many times have I heard this from government officials...

[fluxer555]

It would only be catastrophic if their startup required signing voting transactions, which seems unlikely.

[bitsapphire]

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.

Not possible. Even if it is this would be catastrophic for the development of the Bitshares startup ecosystem. This would mean every startup would need a permission to do their thing. That is a toxic environment for companies to be in. Reminds me of bad governments.

[fluxer555]

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

[bitsapphire]

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?

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.

Thank you fluxer, I understand the concern now. So what do you both propose to resolve this? The system is setup so the Nash Equilibrium will actively tend towards the Moonstone setup or similar setups anyway.

Just imagine, this means that Bitshares is extremely easy to destroy, even more so the bigger the user base is! You just put up a few hundred thousand dollar, create a kickass product which everybody uses (preferably the "ignorant non-voters" as fluxer put it, hardcode 20-50 delegates, and launch an attack. Even full node subjectivity wouldn't help much against that. If the attacker was really malevolent they would even use their delegate proceedings or deep pockets to pay off any other delegate who participates in an attack or fork with them.

This problem cannot be solved through active politics or PR, it needs to be solved on the game theoretical systems level through a different incentive setup!

All that said, we obviously don't mean harm to the system. Blocking the proposal and therefore a public good and advancement of the Bitshares ecosystem and hopefully Bitshares' market cap just because an underlying system problem hasn't been resolved is in my opinion counterproductive. This sets an incredibly bad precedent for the startup community as a whole. I mean, we work and talk with dozens of crypto startups and investors every week, If they ask us about Bitshares we would then need to tell them that it has a fatal flaw build in.

We'll be thinking over the coming days about potential Bitshares-level solutions to this problem. However, as it stands now our proposal is still the only one proposed in this thread so far that makes free market and business sense.

I would very much like Bytemaster's thoughts on this.

[blahblah7up]

Thank you very much fluxer555 for expounding on that.  It is a very important idea indeed!

[fluxer555]

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.

[blahblah7up]

I'll just add, that the way this thread is playing out may be, in part, an answer to your question.  Namely, that many participants recognize your proposal as a threat and will shun your project as a result.  But that is valid only in the current state of things.  And the outcome of your current proposal, even if defeated by rational actors wanting to maintain their voting priviledge, is in no way indicative of what will happen at scale.

[blahblah7up]

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.

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)

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?

[bitsapphire]

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.

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)

[Xeldal]

@Xeldal

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

There might be some truth to that, however if there were 50 different projects being developed simultaneously, I'd expect a much higher market cap to attract that kind of attention.  With a higher market cap these projects would not require 3 or more delegate positions.  Each might require 1 or less.  With a *much higher market cap they wouldn't even ask for 1 they would arrange a deal with an existing delegate who sponsors many such projects.

[xeroc]

hm .. paying an increased fee is another alternative .. good idea @shentist!

[bitsapphire]

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?

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)?

Maybe this video helps? I am not the best talker.

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.

I think you misunderstood me. I don't want it to be two-sided because that doesn't scale.

Based on your below response it seems I did misunderstand you. Didn't think of it in terms of main BC and child BC.

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.

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.

Regardless of what the multisig contract says, 51 delegates will always be able to create a fork and change ledger entries. The BC will always be a consensus of at least 51 delegates, can't do more. Technically speaking, without loose external time stamping we actually also know that in fact consensus requires 2/3 rather than 51% (for more see PBFT literature), though that is a different discussion.

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.

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 think we should discuss this over skype and a whiteboard screensharing session if possible. I think we are not too far removed in ur approach. PMing you.

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?

Sure, I would recommend checking out these:
https://bitsharestalk.org/index.php?topic=13965.msg182455#msg182455
https://bitsharestalk.org/index.php?topic=13940.0
https://bitsharestalk.org/index.php?topic=13872.0

[/quote]

Thanks! Reading now!

[cass]

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!

 

[Shentist]

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!

[blahblah7up]

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.

I think the mistake in your logic is the assumption that everyone here is motivated exclusively by profit.

There are other motivating factors in life, and many people here are living proof of that as many of them are essentially working for free.

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.

The first three words of this quote is a slap in the face of logic, given your proposal. But aside from that, this is the usual excuse given to the uproars caused by large internet companies sharing user information with advertising firms or goverment agencies. Here you give it to us preemptively. It is actually why a lot of people are here trying to create a new system.  Your product is not "inherently op-in" as you insist because it is not transparent.  It is manipulative.  And the more polished and convenient it becomes for the average user, the more dangerous it becomes as a tool for manipulation.

Your proposal is the equivalent of undercutting the very foundations of DPOS which is voting and campaigning for voter approval.  It is a hostile takeover as such.  It could actually be regarded as exploiting an attack vector on DPOS.

I would say expect a storm.

I also agree with tonyk2.  It is the most arogant proposal and general posture I have seen to date on this forum.

Your thinking is equivalent to a state-run television network, producing content upfront and then creating laws (in your case hard-coded delegates), requiring people to pay for it.

I'm sure your wallet will be fantastic.  But your approach to Bitshares is hostile as it undermines it's consensus structure and is thus extremely dangerous and suspect.

@Xeldal

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

[arhag]

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?

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)?

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.

I think you misunderstood me. I don't want it to be two-sided because that doesn't scale.

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.

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.

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.

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.

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?

Sure, I would recommend checking out these:
https://bitsharestalk.org/index.php?topic=13965.msg182455#msg182455
https://bitsharestalk.org/index.php?topic=13940.0
https://bitsharestalk.org/index.php?topic=13872.0

[bitsapphire]

[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???

1. That is very presumptuous. The definition of a public good is a good or a service that everybody would benefit from, but nobody has a large enough immediate utility value in it to take on the burden of its production by themselves. As a result the public good gets not produced.

In order for a team to build a good product you need to talk to potential stakeholders, interview them, get their opinion and usage behaviors, map out added value. That is what we have done with PeerTracks and BTSM. We have talked to many others as well, does that mean that the product was build for them? No, it means that they are part of the potential market and therefore need to be taken into consideration. If you ever built a product you should understand what I mean.

2. No. Just liking or loving something is not enough to call it hostage. I would like to fly to the moon, but SpaceX "won;t let me because they are asking for a return on their risk taking". Just because I'd like to have something that does not mean that the counterparty in the trade is holding the thing hostage. It is called a trade.

3. It is called a share buyback or repurchase. A very common occurrence in companies. Because you got 1.1 UIA per USD, and because we buy back at 1:1 the donors get a 10% risk return in an undefined time window. Governments do this and it is called growth bonds, Tesla did it with their fan-shareholders too. The ratio/return is set, but the period is not.

If somebody wants to get out of the UIA position for whatever reason, they can sell the UIAs on the market to any buyer, in which case the buyer could increase his marginal return on his investment in a later buyback round.

[bitsapphire]

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.

Thanks klosure for the rational proposal. My approach on internet forums is always not to feed the trolls and to assume good faith.

I really like your proposal! My only problem with this proposal is, with the GPL version you just created a public good without the public paying for it. Now the team behind the product has two choices: 1) Sell the product (which lowers the adoption to practically zero); and 2) turn the user into the product. Both options are bad in our view. In crypto especially, the code needs to be open source for any trust to exist.

Furthermore, based on our market research the wallet (under the MIT or a proprietary license) would primarily be used by BitShares related startups. These startups have little to no upfront capital and licensing deals are notoriously difficult with startups (we know, we used to work in this industry). Licensing the wallet under a restrictive or even proprietary license to startups would mean stunting the development of the BitShares ecosystem overall. We don't want that.

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.

That's probably our biggest issue right there. People who do the work and actually provide value rarely have the time to stay on the forums long enough and lobby for their position. That's like telling an employee that instead of doing a great job and the market responding, they should convince the shareholders that they are doing a good job. This is not how world changing enterprises happen. This is the reason why most of the core devs aren't that active on the forums anymore.

What's even worse, I know delegates who have been voted in based on very dubious circle-voting private messages on the forums. This is more politics than business. We want to release a public good and get payed by the public for it, however, the voting terms to become a delegate have been (based on our experience since before Bitshares was a whitepaper) very bad.

Think about it this way, there are good reasons why no open source Bitcoin wallet comes even close in terms of User Experience and UI to the VC funded  close source one's.

[zerosum]

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.

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.

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.

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.

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.

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]

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

[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???

[bitsapphire]

just curious about - any progress on forum update etc!?

We haven't made any fuss about it. Security updates, SEO updates (heavy manual stuff, you may have noticed that we appear on google searches much more often and much better), containerization of SMF plugins for security purposes, test implementation of discourse (they haven't upgraded much of the codebase for the newer ruby versions, as a result we were not willing to take on the security risk), several public database backups on archive.org, forum speedup by moving to a dedicated server, and fending off 3 DDOS attacks in less than 6 months. We did more than we promised and decided against a complete forum software switch.

We simply don't make a fuss about it.

[fluxer555]

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.

Or, here's a way to do it could be politically accepted and gives you immense turnouts if your product's visions work, without offloading your risks to certain stakeholders who are either stupid or are willing to "take one for the team" (in the way tonyk described in his first post, which you ignored). I'm not sure if this is ideal though, I'm open to suggestions:

Campaign for 4 normal delegates without hard-coding. Set an agreed date which will be the earliest to lower your delegate pay. When the BTS price skyrockets, there will be talks about lowering delegate pay so that it is more reasonable. If you make a deal with the shareholders that you will only lower your payrate after X date, then if this light-client actually does skyrocket the price, you may be making $130k or more per month with 4 delegates. Depending on the agreed-upon date, and how much the market cap increases, you all could be millionaires. And if you are indeed the reason the market cap multiplies, everyone will be more than happy to keep you voted in.

It seems you are extremely competent. It would be a pity to make the community turn against you.

[bitsapphire]

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.

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.

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.

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.

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.

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.

PS
Just 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. That is everything but a libertarian and/or free market attitude.

[lzr1900]

just curious about - any progress on forum update etc!?

they promised update the forum half year ago,but nothing was delivered.

[Xeldal]

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.

Thats right, this is one approach to skillfully use the existing system and will not be the last.    Going out of your way to start fires over someone bringing  new offerings to the market makes no sense to me.  If you don't like the offering, don't use it.   We havn't even seen the offering yet, if its not good for anything or the cost is too high, it won't succeed, no need to get bent out of shape over it. 

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.

Much respect.  You gained a couple notches in my book.

I'm hoping the discussion can progress, regarding hardcoded delegates, in a less 'burn the witch' manner.  I personally don't have issue with it but suggested a more palatable but risky approach, with optional voting. 

[klosure]

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.

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.

[cass]

just curious about - any progress on forum update etc!?

[bitsapphire]

@bitsapphire, fantastic! Thanks for your responses.

Regarding the OT voting pools with DPOS delegates...

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.

I am a little confused about the 51-of-102 multisig address. First, what is the extra client key?

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?

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.

Effectively, The 101 delegate OT servers would have the private key to the delegate's TITAN public key. Therefore any communication send out from one OT server to the other can be independently verified by each OT server that they do in fact have the delegate "certificate" (TITAN private key of the active delegate that round). This means that anybody could verify whether the OT server actually also is a delegate on BitShares.

OT itself has no blockchain, it only reads the BitShares blockchain, signs multisig transactions, and parses them along to other OT federated servers. Once the multisig threshold is reached, the transaction happens either on the blockchain itself or on a secondary ledger in between the OT servers (think of it as a bugger database/ledger). This is the equivalent of off-chain transactions without counterparty risk and bloat the the BitShares Blockchain. I think this is the way to scale blockchains.

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

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. This would be the equivalent of a 2-of-2 multisig wallet or transaction,with the difference being that for a transaction or trade to occur in between two blockchains both consensuses need to agree. Blockchains without delegates, or at least TTPs (such as Hyperledger) could not do this and there will always be counterparty risk for them (such as the 15 signature threshold for Bitcoin).

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

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.

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.

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.

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?

[zerosum]

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.


PS
Just 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 offer

questions:

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

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.

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

[bitsapphire]

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.

[fluxer555]

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.

[sumantso]

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

[xeroc]

Alternatively you should at least also consider someone else to run the delegates for you and let him pay 95% to you or so..

[xeroc]

maybe we can find a compromise in such that you promise to either set the payrate to 0% or force fire the delegate yourself (which is now possible afaik) once you have reached the funding goal ..

the issue here is bot that people wont donate to the cause but not see a profit from it .. maybe you can sell the rebuy the funding tokens as advertising tokens in the wallet (plus have a payed app for 2-5$) or use the token for adverrisement on peertracks (not sure if that is possible)

[blahblah7up]

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.

[Shentist]

would be nice to see it in action.

1. you made it really complicated and for this reason it is a bad offer

questions:

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

[clayop]

Will you store fund in BitUSD or USD?

[merlin0113]

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.


 

I agree, not to mention bitsapphire has been a recognized contributor always.

[arhag]

@bitsapphire, fantastic! Thanks for your responses.

Regarding the OT voting pools with DPOS delegates...

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.

I am a little confused about the 51-of-102 multisig address. First, what is the extra client key? 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.

[bitsapphire]

Great questions and comments arhag, as always!

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.

We are currently testing the restricted_owner feature, so yes we intend to make that part of Moonstone.

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.

Yes of course. The Angular client confirms once again the transaction details before signing. We are even thinking about an oracle-like setup where the angular app gets the build transaction from a set of trusted servers. If a certain number of transaction builds agree, then the angular app signs one of them. That's our mid term plan/idea.

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.

TITAN address pinning is already done (just like copay). Complaining isn't planned for now beyond bug reporting.

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?

Yes it does. Though our exchange interface is simplified. We plan on releasing an advanced exchange interface sometime later.

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.

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.

[fuzzy]

Its valentines day guys and girls...why the heck are you forcing me to lurk the forums today???

On another note, bitsapphire will be talking about this idea in a hangout soon.  Soooo you will ba able to ask away. 

Thanks, btw, bitsapphire for being so available to our community.  They are the beating heart that drives us forward.

[Xeldal]

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.


 

[arhag]

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.

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.

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?

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.

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:

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

Is this the sort of thing you want as an alternative to MetaExchange and ShapeShift made possible by relying on the delegates to act as oracles? Or are you thinking of something very different?

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.

[bitsapphire]

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.

Considering that we have put our own money and time into it so far without asking for a delegate position, it seems that we did not put any risk on shareholders, we rather took 100% of the risk, more than any delegate did.

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.

We are software developers, we know that project estimates rarely work, especially under R&D conditions. At bitsapphire we are able to work with startups because we insulate them from development risks, take on all the risk ourselves, and therefore ask for risk compensation at the end in return. This has been also our approach in this project.

We view software kickstarter projects as disingenuous if they ask for money to build something. Even producing a proposal or some code for a delegate position makes little sense because R&D estimates and hurdles are unpredictable. I believe the Bitshares community has understood that by now. This is why we took all the risk onto ourselves, build the wallet (it's almost done), and then ask for funds.

Furthermore, the wallet will be released either way. The question is just under what license and what business model. For this to become software reusable by the stakeholders as well as the potential Bitshares startup community it needs to be open source uner a very permissive license, which makes this a public good in a sense.

Therefore the way we look at this fundraiser:
-Don't donate and it becomes a proprietary startup with an integrated wallet and exchange.
-Donate and it becomes a public good with potential upsides for the entire community.

[bitsapphire]

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.

1. No, not a cent. We took all the risk.
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.
3. Agreed. But we view this as a terms of service and fundamentally opt-in, as nobody pushes people to use our wallet as long as there is competition. Therefore we view this as a free market play.

[zerosum]

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.


PS
Just 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?

[fluxer555]

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.

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.

As recently discussed on the last mumble session, the most successful delegate pattern has been:

1. Engage the community, build connections
2. Do work, ask nothing in return
3. Gain shareholder confidence with your demonstrated abilities
4. After everybody sees you are passionate about bitshares and are competent, post a delegate bid

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.

[hpenvy2]

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?

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.

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.

[robrigo]

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?

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.

Thanks... looking forward to more information! As long as someone is considering that piece of the puzzle I am happy. That has been the thing bugging me a bit with the whole concept because there aren't any publicly disclosed fiat onramps into bitassets yet.

[bitsapphire]

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?

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.

[robrigo]

Thanks for the answer. I also agree that hardcoding delegates that cannot have votes removed into the wallet sets a bad precedent and should not be done. Recommending delegates to vote for would be a much better option; the community was up in arms at the suggestion that core devs have their delegates "recommended" (i.e. automatically approved by default) but because your startup is funding its own operations I think it would be ok for you to do that on Moonstone.

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?

[bitsapphire]

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.

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.

[Bitcoinfan]

Are you considering adding Shapeshift API for BTC type wallet?

[bitsapphire]

Aren't there at least to other light wallets in developement: Yunbi and Valentine? Why another one?

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.

We have had extensive experience with Bitcoin wallet architecture and transaction signing models from previous and current Bitsapphire startup clients. We have come to the conclusion that transactions should not be build in the client for two reasons:

• Need to recreate transaction building code for every platform/language.
• Multisig transactions and future contract transactions will need to be signed by more than 1 private key, as a result you either have p2p communication between clients (which is bad), or you have a central but optional server which reads the blockchain, builds transactions according to client needs, and then sends already build transactions to clients to simply sign. This way multiple clients can sign for example multisig transactions without the need to be online all at once for P2P communication. Furthermore transaction signing is considerably simpler than transaction building. This also means that the central server cannot fake your transaction or move your funds.

This way mobile wallet development should be a lot simpler. Furthermore, once BTS is Turing complete, there will be apps our there which want to communicate with BTS without having to download the full blockchain. Imagine your word processor just signing a transaction for notary services on BTS rather than downloading the whole blockchain.

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?

The native client will be a wrapped Angular app just like the current wallet. Therefore both the web and client wallet will be the same with the client wallet having some additional logic in the wrapper.

[fluxer555]

On an unrelated note, unsticky this. Most people are used to ignoring everything stickied here, I almost didn't see this.

[fluxer555]

DecentralizeEconomics (aka 2Kool4Skewl) will go crazy over this if we let it happen. Regardless of what he does, It will be a PR nightmare. We do not want developers holding technology hostage. We want developers proving themselves to be an added asset to the ecosystem, worth more than their delegate pay, and shareholders will vote accordingly.

[Ander]

Instead of hardcoded delegates, how about recommended delegates that the user can vote for by default, but they can turn off?

[fluxer555]

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.

[bitsapphire]

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?

Exactly roadscape! After talking to many potential stakeholders it seems that an MIT license would do the most good, but we need to cover our costs so far. We've been investing most of our company's margin into Moonstone so far.

We hope that with the introduction of a much more user friendly (and modular) wallet, BitShares might increase in market cap pretty quickly. After all, nobody I know with large BTS holdings has used the current wallet due to several issues. Potentially new users are also put off by the current wallet issues. Moonstone is a light wallet, so no blockchain syncing needed.

The hard-coded delegates won't be able to be unvoted on the wallet until our goal is reached. However, anybody could fork the wallet and put it out there without the hard-coded delegates. We believe though that due to our added value such as identity verification for external exchanges, as well as encrypted storage of config and wallet files users would prefer our official version.

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?

Very good question. Once the UIAs are bought back we intend to make the delegate vote opt-out. Any further delegate income will be subject to normal delegate voting.

The hardcoded delegates not making it into the list is a risk, but also an opportunity for the donors. The way we look at this is that the donors would start promoting the wallet and our delegates based on rational self interest. Very much the way Bitshares people promote Bitshares itself. If the delegates don;t make it we will also announce a max buy-back period for the UIA, probably 50 Months or so.

[robrigo]

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?

[santaclause102]

Aren't there at least to other light wallets in developement: Yunbi and Valentine? Why another one?

[xeroc]

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?

[roadscape]

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?

[graffenwalder]

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.

What does this mean. Every chain that wishes to use the wallet, will have to put up 3-5 delegates?

[bitsapphire]

Hello everybody,

At Bitsapphire we have been working tirelessly for the last few months on our own BitShares wallet called Moonstone. You can subscribe for updates on Twitter, Facebook, or Google+. Working with the BitShares Music / Peertracks team has helped us tremendously to advance the Moonstone architecture beyond what we initially planned.

4 developers have been working on the Moonstone full-time so far, while the entire team of 17 people gave regular input to the project.

Intro screen videos will be added to this thread next week. We hope to be able to present the project in a mumble talk and answer any community questions.

We plan on doing a kickstarter-style fundraiser within a few weeks and wanted to get the community’s feedback on our fundraiser approach. We have already recorder the video for the fundraiser and we are working on video editing, etc.

The plan is as follows:

• February: Launch the Moonstone landing page and get the word out.
• March: We’ll do a scaled kickstarter with a minimum of 130,000 USD worth in BTC/BTS and no upper limit. Donation period would be 30 days.
• We’ll map everybody’s public keys and send Bitsapphire UIAs to the corresponding public keys on BitShares. For every USD worth in BTC/BTS you send you’ll get 1.1 Bitsapphire UIAs.
• Once the campaign ends and we reach the sufficient budget, our user friendly wallet will be released under the MIT license (this means that anybody will have the right to use our code also for for-profit reasons). This is especially appealing to projects out there which need lightweight DPOS wallets but don’t want to develop it themselves. Future DPOS forked projects will also be able to easily use the code.
• 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.
• This means that anybody who sent donations will receive 10% more than put in. Depending on the BTS market cap, this means that you’ll effectively get your donation back in 5-30 months (rough calculation based on historical BTS market cap, not binding and dependent on Delegate proceedings).
• If we fail to reach our budget the Moonstone Angular frontend will be released under the more restrictive GPL3 license which makes it impossible to use the code for for-profit reasons. The backend which makes the light client possible remains closed source. Nonetheless, the wallet will be released with the same number of delegates and whatever budget we got will be converted as planned with a 1:1 ratio.

All funds received are considered donations, no actions on our part are binding in any way. However, similar to the BitShares no-force approach 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?