Author Topic: Revised: Moonstone - New Bitsapphire Wallet: Fundraiser proposal  (Read 9842 times)

0 Members and 1 Guest are viewing this topic.

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
Can you integrate it with BTS login? I hate having to rely on the GUI popping up to sign people in... an online web wallet would be much better, that way I can integrate into my login radius plugin much easier and even get it supported in the backend.
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline CLains

  • Hero Member
  • *****
  • Posts: 2606
    • View Profile
  • BitShares: clains
On the webpage it has a 16 day countdown timer, and it says the crowdfund campaign will launch on the 31st. Those numbers dont add up, they are a week off?

They pushed it back to Tue, 7 April 2015.

zerosum

  • Guest
On the webpage it has a 16 day countdown timer, and it says the crowdfund campaign will launch on the 31st. Those numbers dont add up, they are a week off?

Well, if you run them through the bts market engine you will see that they match perfectly :)

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
On the webpage it has a 16 day countdown timer, and it says the crowdfund campaign will launch on the 31st. Those numbers dont add up, they are a week off?
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline sudo

  • Hero Member
  • *****
  • Posts: 2255
    • View Profile
  • BitShares: ags



Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline D4vegee

  • Full Member
  • ***
  • Posts: 108
    • View Profile


Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
They will always be not just an issue, but the long-term death sentence for any crypto system which does not facilitate native credit creation, which would completely circumvent the whole banking and fiat world. So in a sense, looking at money as primarily a commodity rather than credit (e.g. the Austrian school) is the primary long-term inhibitor and therefore valuation limitor of any DAC. This is so not because commodity money is inherently bad, but because in a free market it game theoretically loses to credit money.

Pulling off credit on the blockchain is tricky. Relying on preserving reputation / credit score as an incentive for debtors to pay back the money they owe only gets us so far. What we would really want are assets representing property rights to be used as collateral for debt (e.g. mortgage-backed securities except implemented with smart contracts that have a lien on the property deed asset and can sell this asset in an open auction on the blockchain to pay back the debt owed). But for these assets to have any value requires an enforcer in the physical world to enforce these property rights. So then we just end up on relying on the reputation of the enforcer and people's belief that this enforcer can (and will) actually enforce the property rights claimed by the virtual asset.

But anyway, even though these things would be really nice to have on a DAC, I don't see how not having it is all that much of a value limiter for the DAC. The credit-based assets and the property rights assets do not directly add any value to the core stake of the DAC (e.g. BTS). Perhaps it would increase adoption and transaction volume and thus increase the revenue of the DAC from transaction fees. But treating BTS as a commodity and using that as the basis to give cryptocurrency, such as BitAssets, value does directly increase the value of BTS as adoption of the cryptocurrency grows.
 

Offline bitsapphire

Thanks for the response.

A DAC where possible may cannibalise others if it may benefit significantly from doing so. Blockchain.info is extremely valuable and earns $250 000+ in revenue per month for the owners. I was wondering if there was a threat to your business model in that BTS may use the delegate system to offer a competitor to Moonstone so that some of the monetisation revenue from a popular wallet flowed into our DAC and to our developers instead of a third party like BitSapphire?

Also BTC38 for example has been wonderful to BTS but because they control a large amount of BTS they are also a potential risk and a valuation limiter - it’s hard to gain value as a decentralized exchange being at the mercy of one centralized exchange. I was wondering if it makes more sense for BTS to build a wallet like Moonstone partly around delegate instead of third party control if this could be a factor?  (I guess you won't be controlling the BTS so probably not.)

I think the project is good though & I wish you luck with it.

Thanks Empirical,

Whenever the discussion arises what a DAC/DAO can and can't do competitively against centralized entities such as Bitsapphire I like to point people to this 1937 essay titled "The Nature of the Firm" by R.H. Coase.

While any DAC or DAO project shareholders could hypothetically incentivize of directly compensate developers or any kind of stakeholders to switch or create a competing product. However the added value and reason for the existence of firms is not funding, it's the added value of coherent resource allocation in a game (e.g. a market). Hence the most a DAC/DAO could do is fund a competitor, but I highly doubt that it will ever be possible for a DAC/DAO to out-do strategic long-term resource allocation as compared to centralized entities.

On the issue of centralized exchanges:
They will always be not just an issue, but the long-term death sentence for any crypto system which does not facilitate native credit creation, which would completely circumvent the whole banking and fiat world. So in a sense, looking at money as primarily a commodity rather than credit (e.g. the Austrian school) is the primary long-term inhibitor and therefore valuation limitor of any DAC. This is so not because commodity money is inherently bad, but because in a free market it game theoretically loses to credit money.

Moonstone won't hold any private keys, hence we won't be able to vote like BTER could have done.
Register and get your personal Moonstone Wallet Beta here: https://moonstone.io/login-register.html

Offline Empirical1.2

  • Hero Member
  • *****
  • Posts: 1366
    • View Profile
I think there is a conflict of interest with you releasing a BTS wallet that may have competitors but also controlling our main information vehicle - the forum. Do you agree?

Blockchain.info earns millions of dollars a year in revenue. Isn't a DAC's optimal strategy to support, promote and build a following for its own wallet or one that gives a good portion of future monetisation revenue to our developers and DAC?

We think it is a problem that we are creating BitShares products which in the long term potentially can become startups and at the same time are in charge of the forum. Keep in mind though that we purposefully took a very laissez faire approach to moderating. The mods did most of the moderation, we only intervened on a technical level and from time to time when a mod overstepped his boundaries.

I personally hope that sooner rather than later we'll be able to use some sort of user friendly decentralized forum. That might be the best long term solution for distributed projects.

I did not get your second question? Could you elaborate?


Thanks for the response.

A DAC where possible may cannibalise others if it may benefit significantly from doing so. Blockchain.info is extremely valuable and earns $250 000+ in revenue per month for the owners. I was wondering if there was a threat to your business model in that BTS may use the delegate system to offer a competitor to Moonstone so that some of the monetisation revenue from a popular wallet flowed into our DAC and to our developers instead of a third party like BitSapphire?

Also BTC38 for example has been wonderful to BTS but because they control a large amount of BTS they are also a potential risk and a valuation limiter - it’s hard to gain value as a decentralized exchange being at the mercy of one centralized exchange. I was wondering if it makes more sense for BTS to build a wallet like Moonstone partly around delegate instead of third party control if this could be a factor?  (I guess you won't be controlling the BTS so probably not.)

I think the project is good though & I wish you luck with it.
If you want to take the island burn the boats

Offline bitsapphire

I think there is a conflict of interest with you releasing a BTS wallet that may have competitors but also controlling our main information vehicle - the forum. Do you agree?

Blockchain.info earns millions of dollars a year in revenue. Isn't a DAC's optimal strategy to support, promote and build a following for its own wallet or one that gives a good portion of future monetisation revenue to our developers and DAC?

We think it is a problem that we are creating BitShares products which in the long term potentially can become startups and at the same time are in charge of the forum. Keep in mind though that we purposefully took a very laissez faire approach to moderating. The mods did most of the moderation, we only intervened on a technical level and from time to time when a mod overstepped his boundaries.

I personally hope that sooner rather than later we'll be able to use some sort of user friendly decentralized forum. That might be the best long term solution for distributed projects.

I did not get your second question? Could you elaborate?

I too am also glad to see that you are open to dialog.

Can a user of the wallet approve 1 out of the 4-5 delegates or is it a all or none deal?

Also can you confirm that you have never received funding from I3 or individual users? Other then your forum pay of course.

Upfront 5 delegates are voted in but you can opt-out with a clearly defined field. Once you open the wallet you'll be able to unvote as many as you want.

We have received about 2k USD in BTC/PTS from Nikolai for the dotp2p website and two BitShares inforgraphics which are still in use today. We have received from Invictus a one time donation of 2k USD when we took over the forum from Amazon. Since then we did not ask for any more donations because it seemed to us we should not be sucking money out of the developers building BitShasres. For the past 6 months we have been running the forum out of our own pocket (Bitsapphire) including server cost, maintenance, and moderation. So no, there is no forum pay, this is a loss business for us at the moment. We hoped that the community would vote one of our delegates in to offset some of our expenses, but because we are simply to busy working and don't have enough time doing PR for our delegate we were not able to keep the delegate position. We might have to add advertisements some time in 1-2 months to the forum if we don't find an alternative approach to funding the forum.
Register and get your personal Moonstone Wallet Beta here: https://moonstone.io/login-register.html

Offline hpenvy2

  • Sr. Member
  • ****
  • Posts: 217
    • View Profile
This proposal is starting to make more sense to me.

Offline Gentso1

  • Hero Member
  • *****
  • Posts: 931
    • View Profile
  • BitShares: gentso
I too am also glad to see that you are open to dialog.



Can a user of the wallet approve 1 out of the 4-5 delegates or is it a all or none deal?

Also can you confirm that you have never received funding from I3 or individual users? Other then your forum pay of course.



Offline Riverhead


Changing your approach based on feedback from the community is fantastic. I will be donating.

Offline Empirical1.2

  • Hero Member
  • *****
  • Posts: 1366
    • View Profile
Sounds good. The easier and clearer the opt out option is at all stages the more support your delegates will probably get from existing BTS shareholders.

I think there is a conflict of interest with you releasing a BTS wallet that may have competitors but also controlling our main information vehicle - the forum. Do you agree?

Blockchain.info earns millions of dollars a year in revenue. Isn't a DAC's optimal strategy to support, promote and build a following for its own wallet or one that gives a good portion of future monetisation revenue to our developers and DAC?
If you want to take the island burn the boats

Offline bitsapphire

So are you saying the method you came up with that I referenced was faulty?

My proposal in the other thread included a DAC change. Even in our proposal the most the server could do would be to not forward the vote-transaction. So the most a server could do would be to deny service. With an oracle setup that would be resolved though, be that with today's setup or with a special vote-transaction.

Why can't you work with the developers that are already making a light wallet?

We talk to them from time to time on the development Skype channel. We have a different architecture vision. Just like there are different technical choices people have made in the Bitcoin wallets, so too you'll see different approaches.

We believe that our approach is much better suited for businesses and heavy users in the future. We also have technical expansion planes for the functionality of the server so building on top of a different setup would complicate things.
Register and get your personal Moonstone Wallet Beta here: https://moonstone.io/login-register.html

clout

  • Guest
Why can't you work with the developers that are already making a light wallet?

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
So are you saying the method you came up with that I referenced was faulty?

Offline bitsapphire



This is my third time asking, can you please answer this?

If developers change the blockchain protocol so that light clients cannot vote without the centralized server(s) having access to the private keys (in the method you described here), how would this affect your proposal?

Voting is part of transaction building which has to be signes by the key that withdraws some amount from an address ... i cannot think of any change that will require a central. server to have your privkey ...

The only thing described by bitsapphire concerns multisig which (may) required a central server to hold the blockchain and send you a preconstructed unsigned transaction for signature ... though still you can change the tx (ie. votes) prior to signing ..

Thats at least my understanding

Xeroc's explanation is spot on. The most a light client server could do is to deny forwarding the signed transaction. With an oracle setup even that would become practically impossible.
Register and get your personal Moonstone Wallet Beta here: https://moonstone.io/login-register.html

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
The only thing described by bitsapphire concerns multisig which (may) required a central server to hold the blockchain and send you a preconstructed unsigned transaction for signature ... though still you can change the tx (ie. votes) prior to signing ..

You wouldn't be able to change the tx if the other party (the server) refuses to sign that modified transaction. But that is basically a denial of service by the server. Which is why you want to make sure multisig is 2-of-3 where you own two of the keys (one is offline), so that if this happens (or if the company just fails and disappears) you can take your funds and go to another light wallet provider.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc


This is my third time asking, can you please answer this?

If developers change the blockchain protocol so that light clients cannot vote without the centralized server(s) having access to the private keys (in the method you described here), how would this affect your proposal?

Voting is part of transaction building which has to be signes by the key that withdraws some amount from an address ... i cannot think of any change that will require a central. server to have your privkey ...

The only thing described by bitsapphire concerns multisig which (may) required a central server to hold the blockchain and send you a preconstructed unsigned transaction for signature ... though still you can change the tx (ie. votes) prior to signing ..

Thats at least my understanding

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
This is my third time asking, can you please answer this?

If developers change the blockchain protocol so that light clients cannot vote without the centralized server(s) having access to the private keys (in the method you described here), how would this affect your proposal?

Offline bitsapphire

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.

How about the following?

If the 130,000 USD budget is not reached, you calculate the deficit D which acts as the principal for a loan with some interest r APR. You release the client with the 5 opt-out delegates under the GPL3 license and do not release the server code. Then any money collected by these delegates is used to pay off the principle + interest of the loan first, before selling for the UIA at a 1:1 ratio. Once the loan is paid off, you re-license the client under the MIT license and you also release the server code under the MIT license. After the loan is paid off, any surplus income from the delegates is used to do the UIA buyback at the 1:1 ratio until all of the UIAs are destroyed. Then after those UIAs are completely destroyed, you retire the 5 delegates.

Another variation would be to require that the loan be paid off before some expiration time (say 2 years after the wallet is released) or else the license remains GPL3, the loan becomes void, and all income from the delegates goes toward the UIA buyback after that point until all of the UIAs are bought back and destroyed, at which point you retire the 5 delegates.

If this sounds reasonable to you, then we just need to see if we can find a compromise value of r that is acceptable to you but also does not damage the kickstarter by much due to the added risk.

Another variation that may be interesting is to adjust the UIAs paid per dollar as the funding campaign progresses. For example, the first $65,000 could offer 1.20 UIA/USD, the next $45,000 could offer 1.15 UIA/USD, and the last $20,000 could offer 1.10 UIA/USD (for an average rate of 1.167 UIA/USD). This provides the extra incentive for donators to contribute early in the campaign despite the greater risk due to the larger uncertainty regarding how large the deficit may end up being (if any).

Edit: I thought of another modification. If there is a deficit, then after the wallet launches you can use the delegate funds collected each week to first buy any UIA sell orders at a price of 1.17 UIA/USD or above, and then use any remaining money to pay off the loan. This delays paying off the loan, but it gives the early donators at the 1.20 UIA/USD price some confidence that they can exit early for smaller profits (2.6% rather than 20%) if they are concerned that the deficit is too large that it may take up to 2 years before they can start earning any returns. It also allows the later donators (those that paid after $65,000 was already raised) to exit at a loss if they lose confidence at the expense of further delaying the loan repayment (potentially so long that it isn't paid off by the 2 year expiration time and the code remains GPL3 licensed).

Thanks for the great ideas!

We're seriously looking into your proposals. I hope we can come up with a simple way to make sure than the donor's actually get their goal of the MIT public good. For now your proposals make sense but might be 1-2 steps too complicated to market properly. If you and others can think of any other such ideas please let us know!
Register and get your personal Moonstone Wallet Beta here: https://moonstone.io/login-register.html

Offline bitsapphire

  • The wallet will have 5 opt-out delegates which can be deselected upon installation.
Unvoting delegates should be possible at any time, not only at installation. People tend to ignore disclaimers, user agreements and so on at the time they install, so limiting opt-out to installation time is the quasi-equivalent of putting hard coded delegates.

Nice catch! I didn't even notice it. Another reason to question the tactics and motives of this group.
or maybe just a flawed translation .. not that this community shouldn't already know about those issues

I meant that delegates can be unvoted at any time. Just lost in translation.
Register and get your personal Moonstone Wallet Beta here: https://moonstone.io/login-register.html

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
  • The wallet will have 5 opt-out delegates which can be deselected upon installation.
Unvoting delegates should be possible at any time, not only at installation. People tend to ignore disclaimers, user agreements and so on at the time they install, so limiting opt-out to installation time is the quasi-equivalent of putting hard coded delegates.

Nice catch! I didn't even notice it. Another reason to question the tactics and motives of this group.
or maybe just a flawed translation .. not that this community shouldn't already know about those issues

Offline blahblah7up

  • Full Member
  • ***
  • Posts: 192
    • View Profile
  • The wallet will have 5 opt-out delegates which can be deselected upon installation.
Unvoting delegates should be possible at any time, not only at installation. People tend to ignore disclaimers, user agreements and so on at the time they install, so limiting opt-out to installation time is the quasi-equivalent of putting hard coded delegates.

Nice catch! I didn't even notice it. Another reason to question the tactics and motives of this group.
« Last Edit: February 17, 2015, 08:30:44 am by blahblah7up »

Offline klosure

  • Full Member
  • ***
  • Posts: 112
    • View Profile
  • The wallet will have 5 opt-out delegates which can be deselected upon installation.
Unvoting delegates should be possible at any time, not only at installation. People tend to ignore disclaimers, user agreements and so on at the time they install, so limiting opt-out to installation time is the quasi-equivalent of putting hard coded delegates.

Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
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.

How about the following?

If the 130,000 USD budget is not reached, you calculate the deficit D which acts as the principal for a loan with some interest r APR. You release the client with the 5 opt-out delegates under the GPL3 license and do not release the server code. Then any money collected by these delegates is used to pay off the principle + interest of the loan first, before selling for the UIA at a 1:1 ratio. Once the loan is paid off, you re-license the client under the MIT license and you also release the server code under the MIT license. After the loan is paid off, any surplus income from the delegates is used to do the UIA buyback at the 1:1 ratio until all of the UIAs are destroyed. Then after those UIAs are completely destroyed, you retired the 5 delegates.

Another variation would be to require that the loan be paid off before some expiration time (say 2 years after the wallet is released) or else the license remains GPL3, the loan becomes void, and all income from the delegates goes toward the UIA buyback after that point until all of the UIAs are bought back and destroyed, at which point you retire the 5 delegates.

If this sounds reasonable to you, then we just need to see if we can find a compromise value of r that is acceptable to you but also does not damage the kickstarter by much due to the added risk.

Another variation that may be interesting is to adjust the UIAs paid per dollar as the funding campaign progresses. For example, the first $65,000 could offer 1.20 UIA/USD, the next $45,000 could offer 1.15 UIA/USD, and the last $20,000 could offer 1.10 UIA/USD (for an average rate of 1.167 UIA/USD). This provides the extra incentive for donators to contribute early in the campaign despite the greater risk due to the larger uncertainty regarding how large the deficit may end up being (if any).

 +5%
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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.

How about the following?

If the 130,000 USD budget is not reached, you calculate the deficit D which acts as the principal for a loan with some interest r APR. You release the client with the 5 opt-out delegates under the GPL3 license and do not release the server code. Then any money collected by these delegates is used to pay off the principle + interest of the loan first, before selling for the UIA at a 1:1 ratio. Once the loan is paid off, you re-license the client under the MIT license and you also release the server code under the MIT license. After the loan is paid off, any surplus income from the delegates is used to do the UIA buyback at the 1:1 ratio until all of the UIAs are destroyed. Then after those UIAs are completely destroyed, you retire the 5 delegates.

Another variation would be to require that the loan be paid off before some expiration time (say 2 years after the wallet is released) or else the license remains GPL3, the loan becomes void, and all income from the delegates goes toward the UIA buyback after that point until all of the UIAs are bought back and destroyed, at which point you retire the 5 delegates.

If this sounds reasonable to you, then we just need to see if we can find a compromise value of r that is acceptable to you but also does not damage the kickstarter by much due to the added risk.

Another variation that may be interesting is to adjust the UIAs paid per dollar as the funding campaign progresses. For example, the first $65,000 could offer 1.20 UIA/USD, the next $45,000 could offer 1.15 UIA/USD, and the last $20,000 could offer 1.10 UIA/USD (for an average rate of 1.167 UIA/USD). This provides the extra incentive for donators to contribute early in the campaign despite the greater risk due to the larger uncertainty regarding how large the deficit may end up being (if any).

Edit: I thought of another modification. If there is a deficit, then after the wallet launches you can use the delegate funds collected each week to first buy any UIA sell orders at a price of 1.17 UIA/USD or above, and then use any remaining money to pay off the loan. This delays paying off the loan, but it gives the early donators at the 1.20 UIA/USD price some confidence that they can exit early for smaller profits (2.6% rather than 20%) if they are concerned that the deficit is too large that it may take up to 2 years before they can start earning any returns. It also allows the later donators (those that paid after $65,000 was already raised) to exit at a loss if they lose confidence at the expense of further delaying the loan repayment (potentially so long that it isn't paid off by the 2 year expiration time and the code remains GPL3 licensed).
« Last Edit: February 16, 2015, 10:44:05 pm by arhag »

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
What if the campaign doesn't bring in $130,000, but the delegates do in the long run? Will it be changed to MIT at that point?

Will you take the delegates in the wallet down once the repaid the 130k? If not what will you do with the revenue?

Once the 130k+15% is payed off to the donors we will remove the delegate opt-out box completely. Any wallets with existing votes will be able to change their vote anyway along the way.

We want everybody to understand the intention of this project: The delegates pay is used simply so the public is able to pay for a public good (i.e. MIT license), while the risk or the wallet production is taken up by individual donors, not the public. We are completely against setups where the public is dragged into risk taking without consent. If the budget is not reached then well, the wallet won't be a public good because the donors did not want to take on the risk.

so, if i understand it correct if you reach 40k it will never be MIT license and the delegates will still be running to pay the donors back? But, why should i vote the delegates in without the chance to get it into MIT over the coming month?

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
What if the campaign doesn't bring in $130,000, but the delegates do in the long run? Will it be changed to MIT at that point?

Will you take the delegates in the wallet down once the repaid the 130k? If not what will you do with the revenue?

Once the 130k+15% is payed off to the donors we will remove the delegate opt-out box completely. Any wallets with existing votes will be able to change their vote anyway along the way.

We want everybody to understand the intention of this project: The delegates pay is used simply so the public is able to pay for a public good (i.e. MIT license), while the risk or the wallet production is taken up by individual donors, not the public. We are completely against setups where the public is dragged into risk taking without consent. If the budget is not reached then well, the wallet won't be a public good because the donors did not want to take on the risk.
+5% Sounds like a solid concept!

Offline CLains

  • Hero Member
  • *****
  • Posts: 2606
    • View Profile
  • BitShares: clains

Offline bitsapphire

What if the campaign doesn't bring in $130,000, but the delegates do in the long run? Will it be changed to MIT at that point?

Will you take the delegates in the wallet down once the repaid the 130k? If not what will you do with the revenue?

Once the 130k+15% is payed off to the donors we will remove the delegate opt-out box completely. Any wallets with existing votes will be able to change their vote anyway along the way.

We want everybody to understand the intention of this project: The delegates pay is used simply so the public is able to pay for a public good (i.e. MIT license), while the risk or the wallet production is taken up by individual donors, not the public. We are completely against setups where the public is dragged into risk taking without consent. If the budget is not reached then well, the wallet won't be a public good because the donors did not want to take on the risk.
Register and get your personal Moonstone Wallet Beta here: https://moonstone.io/login-register.html

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
Will you take the delegates in the wallet down once the repaid the 130k? If not what will you do with the revenue?

Offline roadscape

What if the campaign doesn't bring in $130,000, but the delegates do in the long run? Will it be changed to MIT at that point?
http://cryptofresh.com  |  witness: roadscape


Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc

Xeldal

  • Guest
Good stuff.  This is much better.  +5%
I think you made the right decision.

Offline bitsapphire

Hi everybody,

After quite an interesting discussion on our last thread we convened with the team and tried to come up with an alternative proposal.

Our new fundraiser proposal:
  • 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 will 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.15 Bitsapphire UIAs (we have increased it from 1.1 to 1.15 due to higher risk as a result of opt-out delegates).
  • Once the campaign ends and we reach the sufficient budget, both the frontend and backend of the 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 5 opt-out delegates which can be deselected upon installation and whenever you want. 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. Further monetization efforts will be reviewed later on by Bitsapphire (such as featured assets, markets, etc)
  • This means that anybody who sent donations will receive 15% 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).

What are your thoughts on the improved fundraiser proposal?
« Last Edit: February 17, 2015, 12:23:24 pm by bitsapphire »
Register and get your personal Moonstone Wallet Beta here: https://moonstone.io/login-register.html