Moonstone - New Bitsapphire Wallet: Fundraiser proposal

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