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

0 Members and 1 Guest are viewing this topic.

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 »