Moonstone - New Bitsapphire Wallet: Fundraiser proposal

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