Moonstone - New Bitsapphire Wallet: Fundraiser proposal

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