0 Members and 1 Guest are viewing this topic.
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?
yes pls check www.moonstone.io for further information!
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.
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.
Quote from: Empirical1.2 on February 17, 2015, 08:48:10 pmI 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 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?
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.
So are you saying the method you came up with that I referenced was faulty?
Why can't you work with the developers that are already making a light wallet?
Quote from: fluxer555 on February 17, 2015, 04:04:14 pmThis 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
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?
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 ..
Quote from: bitsapphire on February 16, 2015, 05:42:25 pmIf 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).
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.
Quote from: blahblah7up on February 17, 2015, 08:26:37 amQuote from: klosure on February 17, 2015, 06:39:54 amQuote from: bitsapphire on February 16, 2015, 05:42:25 pmThe 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
Quote from: klosure on February 17, 2015, 06:39:54 amQuote from: bitsapphire on February 16, 2015, 05:42:25 pmThe 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.
Quote from: bitsapphire on February 16, 2015, 05:42:25 pmThe 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.
The wallet will have 5 opt-out delegates which can be deselected upon installation.
Quote from: bitsapphire on February 16, 2015, 05:42:25 pmIf 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).
Quote from: roadscape on February 16, 2015, 06:38:06 pmWhat 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?Quote from: delulo on February 16, 2015, 07:15:30 pmWill 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.
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?