Quote from: starspirit on October 20, 2015, 05:59:37 am

Please forgive the simple (stupid?) questions, I've not had the chance to keep up with the forum the last couple of months.

I had 4 different account names to now, 3 in my desktop client, and one in the online wallet, and I have exported keys now from both wallets (using 0.9.3c for the desktop client).
Now I want to put everything in the new web wallet, which I assume is OpenLedger.
The main thing I'm unsure about is whether I need to combine everything under a single account name, or whether I can retain the separate account names going forward.
In OpenLedger, to create an account, it is asking me for an account name. Should I choose one of my existing account names, and is that my only account going forward? Once I've created the account, and import my keys, will the token holdings then fall under separate account names in OpenLedger, or be combined?
I've seen this link http://docs.bitshares.eu/migration/howto-importing-wallet.html#web-wallet, but it seems to presume I know these answers already. So please don't just sen me that link.
Thanks.

Since you already have account names that you want to keep you do not need to create a new account. Click on "Existing Account" instead, create a new wallet with a good password, then import the keys from your old accounts. That wallet will then contain those accounts, and they'll be separate. You can choose to import all balances from those accounts to a single account however, or not as you prefer.

Thanks very much svk.  I've done these imports now, that all seemed to work well.

I also want to import the private key that I exported from the old web wallet. But in OpenLedger, when I try "Import Keys" and point to that file in the box where it asks for the BTS 1.0 Key Export File, it yields an error "JSON Parse Error: Unrecognized token '\' ". So I guess its a different format, and a different method for importing the old web wallet key?

Also, when I try to Create Backup, when I hit the Download button, it just seems to open a new blank tab on my browser (Safari) and I am unsure if it has actually downloaded anything...?

Thanks.

OK, thanks guys, managed to install 0.9.3c and export wallets. I still got the warning that I was replacing my current Bitshares version with an older version, and it still showed November 2014 creation date, but I took a leap of faith and just installed anyway. Now to migrate to 2.0...

Quote from: starspirit on October 15, 2015, 07:39:23 am

Quote from: URSAY on October 13, 2015, 10:57:09 pm

Quote from: starspirit on October 09, 2015, 12:08:24 am

I had a problem with this, specifically in downloading BitShares-0.9.3c.dmg for MAC. The downloaded application turns out to be an old one created on 12 November 2014, so when I try to replace my current version it warns that I am trying to replace with an older version. Can this be checked please?

I just downloaded 9.0.3c to replace 9.0.2 on a Mac.  The newer version appeared correct at startup.

I know BitShares 2.0 is released, but apparently I still need 0.9.3c temporarily in order to export my private keys so that I can eventually claim my MUSE tokens (I hold NOTES) when they launch. So if somebody could still respond as to what I'm doing wrong here I would appreciate it.

I downloaded BitShares-0.9.3c.dmg from here:...https://github.com/bitshares/bitshares-0.x/releases. When I right-click to Get Info on the downloaded application in the .dmg, it says it was last modified 12 November 2014, which would suggest it is not in fact 9.0.3c. And when I try to save the application to my Applications Folder, I get a message saying "A newer item named “BitShares” already exists in this location. Do you want to replace it with the older one you’re moving?". As a result of this warning, I have not installed the downloaded version.

Should I just install it, or am I picking up the incorrect application?

Thanks

maybe pick 0.9.3a or b .. they both have the command line command integrated already .. just not the (correct) menu item

0.9.3a or b are no longer downloadable at that link...

Those that weren’t aware, you should upgrade your BitShares desktop client from 0.9.2 to 0.9.3. The reason being it will be easier to import your private keys to the Graphene chain (MUSE) when the time comes.

I was unable to upgrade to 0.9.3 due to a technical problem. So I am still running 0.9.1. Will this be a major problem?

Just brainstorming here - maybe there is a gap in the market between bitcoin, where there are network constraints, and BTS, which is not widely viewed as an immutable currency due to its history and share-like nature.

1. Create a coin on the bitshares block-chain that offers all of the key currency features of bitcoin that its community wants, but with all the advantages of a superior network. i.e. a coin with a "definitively" fixed (possibly even zero) inflation schedule into perpetuity, super fast and high capacity.

2. Sharedrop a large amount of the coin based on all BTC addresses at a specific date that show evidence of use in the prior year (assuming a drop based on accounts on another network is even possible?). This could favour smaller over larger accounts to decentralise the distribution compared to bitcoin currently, and using a historic date removes the possible manipulation of large BTC holders opening up lots of new smaller accounts.

3. Sharedrop a portion on other selected communities (e.g. Litecoin, Bitshares?).

4. Keep a portion aside for merchants setting up for payments in the coin; a portion for free promotions to the wider public, and a portion paid for use of the coin (the latter to discourage immediate dumping of any sharedrop amount, and encourage familiarity and use).

5. Split the network fees charged on all transactions between the block-producers, and BTS holders as owners of the network.

The problem for mainstream acceptance, at least initially, remains volatility (value uncertainty). But a wallet providing instant locks and unlocks for pegged USD might suffice.

Quote from: starspirit on August 19, 2015, 02:13:56 am

I didn't listen to the hangout, so I'm missing the background on this. But what is the main purpose of BMs proposal? If people are willing to give up some BTS to help prioritise certain projects, why not use all of those BTS for funding the project, rather than locking them up or burning them? That way there might be a much larger funding pool?

No, because then they sell them on the open market and drag the price down defeating the sole purpose of raising the market cap by reducing supply, man.

Using the coin for funding facilitates more value-adding projects, which increases the value of BTS, and demand for it. If the projects are productive, this demand would absorb any selling pressure when the coins re-enter circulation. The value of bitShares rises with the increased capital and utility we build to support it.

The logic of withholding that capital to constrain its use in the hope of increasing scarcity value is highly dubious. In the wider world outside crypto, investors provide capital to ventures that create value. The world ends up with a more valuable economy, and better goods and services, as a result. Capitalists don't then worry that when the employees of those companies spend that money (i.e. "sell" it or convert it for other things they need) the pressure of "selling money" will reduce the value of it. They don't then conclude as a result that everybody would instead be better off hoarding money (presumably to increase its value) rather than investing it so we can all be paper-rich.

Collectively we can burn as much BTS as we like, and it will never increase the value of bitShares in totality. If we burn everything until we have 1 BTS left to split between all of us, that 1 BTS will be worth no more than what all today's BTS are worth, without any increase to the wider market's valuation of the utility of BTS. To me these just seem like convoluted games to distribute BTS within our little collective. What we need to be talking about and promoting and getting excited about are not such games, but real value-add.

Quote from: lil_jay890 on August 13, 2015, 01:41:40 am

Quote from: triox on August 13, 2015, 01:14:52 am

...
I could maybe understand targeting some true community token, if we had anything like that, a'la LTBcoin - at least LTB has strict and known rules on it's releasing. But this "Brownie" nonsense is a centralized private monstrosity doled out by one capricious guy who can recall them from anyone at any point or assign 99% extra supply to himself.

Now this joke of a coin gets a sharedrop from Underwood's project and the gullible idiots are cheering because they feel they're part of the inside club. All this talk about openness and inclusivity and community values  goes out the window when there's a glimmer of chance for some extra cream from some hypothetical vapour of a project.
I've been here for over a year and it's like every step of the way this community is begging to both get themselves fleeced and further tank the project's perception and price.

Agree completely. Dan talked so much of freedom and decentralization... This brownie distribution that he has 100% control of flies in the face of much of what he has preached.

Brownies may have a place for dans or cryptonomex projects, but they should not be considered as a viable target for outside projects.

I think everyone's tune would be much different if bts cap was around the highs.  Some people are so underwater on their bts investment that they would cut off their left ear to get back to even.  These deals represent a light of hope for ill timed investors.  That light seems to be blinding many of their original Bitshares principles.

Since Underwood desires to give extra recognition to boost the enthusiasm of active contributors
And Dan's thank you note ledger is the most comprehensive quantitative documentation of such people that exists
Then it makes total sense for John to make use of that demographic mailing list.

Quote from: Stan on August 12, 2015, 11:27:27 pm

I can't think of a better criteria for who should get a share than those who helped build the ecosystem.
The challenge is in determining how helpful each someone has been to the cause.
This is inherently subjective in any application where there is a wide range of ways in which supporters contribute.
There is no pre-defined formula that is sufficiently complete.

Managers seeking to acknowledge contributors to their mission always have this problem.
The brownie method is more open and quantitative than most performance reviews I have had in my career.

In the end, such things don't have to meet any criteria other than what suits the giver of the gift.
In this case, Underwood decided that Bytemaster's thank you note system was as good a metric as any.

Parable of the Generous Employer

I believe that anybody ought to be able to create whatever token of appreciation they like, and distribute it however they like, as a target for their own gifts or rewards. However, unless such tokens are non-tradeable and non-transferable, it seems that rewards dropped on such a token might spill over to those that have simply bought their way in rather than having made any genuine contribution or even offering any expected future contribution. Ultimately it could just become like any tradeable token as re-distribution in the secondary market over time dominates any initial or primary distribution. However its only early days for BROWNIES yet, so at this stage the distribution is probably very close to initial.

Also, any issuer of a share drop can use whatever system they believe best suits their purpose. However, if the distribution of the target tokens on which the share drop will occur is highly discretionary and controlled by a different entity, there is at least some risk of ending up with distribution outcomes that don't match the original intentions of the share-dropper. It might be best to use a historic date to prevent such unexpected changes. So although there is never a perfect system and some compromise is always necessary, I expect these factors would all be considered carefully.

Quote from: monsterer on July 26, 2015, 10:25:12 am

I'd love to hear what starspirit thinks about the eDollar pegging mechanism, because it's interest rate based, just as his proposal for a peg on bitshares was:

http://forum.makerdao.com/t/how-the-edollar-peg-works/64

paging @starspirit

If I understand it correctly, Rune's proposal appears to use an interest rate to modify supply, while on the long side there is no symmetric mechanism to modify demand. Somebody let me know if this is a wrong interpretation, as I only read Rune's main post.

My personal preference is for a payment system between longs and shorts that modifies both the supply and demand curve. This would lead to greater stability in both total issuance and the interest charged to shorts. For instance, suppose external interest rates rose significantly (e.g. after a Fed hike), and the relative demand for bitUSD fell as a result. Suppose demand at the peg price falls from $10m to $5m. The immediate impact would be a discount as half the current owners try to sell. By charging shorts higher interest as per proposed eDollar, the supply can be contracted to $5m (note this would have happened anyway with settlements, but at least this encourages shorts to act voluntarily). But if instead longs received the interest, a smaller interest rate increase would be required, as this will help lift demand at the same time as reduce supply, meeting somewhere in the middle. [As an aside, somebody might be able to point out to whom Rune intends for the interest to be paid, as I was not clear on this].

Such a transfer scheme is not so easy to implement now in 2.0, because there will no longer be a direct yield mechanism. However, it is possible to do indirectly, which I've been looking at for some time, and it may even be simpler in the end. So for example, suppose we create deposit tokens, where each token represents a notional number of USD that varies over time with regular interest accruals. Longs and shorts maintain a constant exposure to deposit units, but this represents a varying exposure to USD, that is captured in the net asset value of the token. By setting the interest rate with respect to discount or premium to parity (similar to Rune's approach), a mechanism is introduced that tends toward restoring parity over time. For people to be able to spend actual bitUSD in transactions then, one of two approaches are possible. One is to allow conversion of deposit tokens on a 1:1 basis with non-interest paying bitUSD tokens. Parity on the bitUSD is ensured by the 1:1 conversion with deposit tokens. A second approach, which does not require freely held bitUSD, is to allow a mechanism where transactions denominated in bitUSD are always sent and received from deposit reserves, and settled in the appropriate number of deposit tokens. While I expect all this is feasible with Smartcoins, I have to wait and see what practical difficulties there will be with tying together the processes for interest rate formation, feed production, and NAV calculation. I need to speak to the developers more about these things as we get closer to 2.0, but unfortunately am just a bit short of time at the moment.

There are some additional aspects that need to be ironed out though. One problem that Rune identifies is that market shocks can create quite large deviations to parity before the interest rate adjustments have sufficient effect. As a result, he introduces a penalty/reward on settlements. I prefer an approach where the algorithm for adjusting interest rates takes account of the distance from parity, not just the direction. Larger distances can lead to larger rate adjustments, with smaller adjustments as parity is approached. With the algorithm being public and transparent, there ought to be plenty of market-makers willing to step in before such distances get too large, in the knowledge that the rate algorithm will be moving quite responsively to restore parity. In fact, with such an approach, there may not even be a need for settlements at all, adding another great simplification to the structure.

Another problem is the zero-bound on interest rates. Under both Rune's approach and my approach there is likely to an insufficient supply (and persistent premium) if there is insufficient incentive for shorts to participate even at 0% interest. In theory though, it is possible to have negative rates (shorts earn interest from longs), but as a practical issue there is a big question mark around this.

There's more I could add on this wonderful topic, but another time perhaps...