A few more comments:

1. The paging goes one page too far, to a completely empty page with no cards.
2. If you click the wrong payment method, you have to go all the way back out and start over to switch it.

Quote from: xeroc on July 17, 2015, 08:40:38 am

Quote from: delulo on July 17, 2015, 08:19:11 am

What other than worker proposals which are anyway part of 2.0 would "Follow My Vote tools" allow to vote for?

I think he is talking about the possibilities to vote on-chain in general. Those would also include, witnesses, delegates, and most (when not all) fees of the system ..

^
That is all part of 2.0. I couldnt come up with something BTS stakeholders could vote on other than what you mentioned.

The built in 2.0 voting is all directly chain actionable, but it would be helpful to have easy ways to determine shareholder opinion on more general things also.  It's awkward to use witness or delegate voting to generate consensus on a big picture strategy or vision for the network upon which actionable vote proposals will be based.  Follow My Vote should provide light weight, verifiable shareholder polling and voting to help solve those problems.

Sorry but isn't it more likely that BTS would be re-implemented in NXT?  Not trying to start a flamewar here, just saying they DO have this...   http://nxt.org/about/monetary-system/

The main reason I prefer BTS to NXT is the solid pegging mechanism and yield interest on bitUSD.
I know more than a handful of others that feel pretty much the same way.

If bitUSD is changing, then it changes the whole value proposition in my mind.  Nevertheless that pegging mechanism is essential to widespread adoption.  The yield is admittedly secondary, but I would hold a whole lot less bitUSD if there wasn't a good yield.

Thanks for the info guys, it's helpful!

Does NXT have a way to balance the trustlessness of more decentralization against the cost of additional redundancy intelligently?  That's the core of why I think BitShares has a chance of scaling to handle mainstream adoption.  Without that, I think other networks will choke on success and become either centralized, unprofitable, or both.

Certainly the actual user features are important, but without an economically sustainable core design to carry them, they're wasted.

In its infancy, this network and the community surrounding it has been highly dependent on a few key actors for leadership, growth, and survival.  This is normal and healthy for a developing network, but it would be terribly unhealthy to stagnate in this stage.  I am quite grateful for the dedication, innovation, and vision that has been poured into BitShares by its founders and other early leaders.  I hope they will remain active members and contributors to this community, but with the impending transition to graphene, the time has come to mature our social structure into a more fault tolerant mesh that reflects the elegant design of our network.

To achieve this, I propose the following prioritization strategy:

1. Complete BitShares 2.0 migration
2. Create user friendly Follow My Vote tools to enable stake voting on later proposals
?. Privacy features
?. Bond market
?. Decentralized BitShares ID based communication and social platform to replace centralized forums
?...

As soon as step one is complete, the community can commence a massively parallel marketing campaign using the referral system.  As soon as step two is complete, all remaining development goals can be proposed and sequenced through stakeholder voting.  Developers ideally should maintain multiple links to the community for fault tolerance, rather than relying so much on bytemaster to speak for them.  We need to outgrow dependence on any single individual as a decision making bottleneck.  In the future, good ideas should propagate through our social mesh virally, snowballing stake support as they go.  Where they originate is irrelevant.

This is the last major strategy and vision decision that needs to be pushed through with the current leadership structure.  This will enable them to work themselves out of a job and become just a few more highly respected community members and stakeholders.  With BitShares 2.0 + an FMV stake voting system, I believe this network can begin to grow even beyond the intentions of its founders.

Please state if you agree that using 2.0 and FMV to end BitShares remaining reliance on centralized leadership should be our top priority.  If you disagree, please state your reasoning.  The goal is in sight, but we need all need to be together on this, especially the dev team.

Quote from: Troglodactyl on July 16, 2015, 11:08:35 pm

I've been rolling over my shorts for quite a while with no issues now, so here are a few tips:

1. If you're setting a price limit on your short intending to buy at that exact price, then don't set the quantity.  Instead, manually enter the collateral amount as 2*price limit*desired quantity.  The quantity will display the amount this would collateralize at the current feed, but ignore that.  You can just buy the desired quantity at the price limit you set from your short and the orders will fill each other properly.

2. Expired shorts force a buy order at exactly the feed.  Margin called shorts force a buy at 10% above the feed.  You can see these two orders in the screenshots posted in this thread with their prices in yellow instead of green: The buy at 205 is the expired short order and the buy at 225 is the margin call order.

3. I don't know how much difference it makes, but I always increase my desired number of connections to 45 instead of 20 to try and minimize my latency on receiving new blocks and seeing new orders sooner.

The GUI is sometimes a little weird with my orders showing and hiding as they're in the process of being matched with each other, but if I ignore that it seems to work fine, and the GUI catches up with what actually happened soon after.  The new graphene system should resolve this sort of GUI issue since it pushes updates to the GUI instead of the GUI constantly checking for updated data.

awesome, thank you so much for the pointers, esp with #1. i've had some annoying trades not exactly matched in quantity, but that sounds like a great solution.

for #2, do the 10% over peg orders actually show up on in the order book? both @EstefanTT and i were placing orders for over the max bid in the order book, so they shouldn't have auto executed on us unless there were latent buy orders just not showing up.

I wasn't trading while there were active margin calls, but I did see the +10% order in the order book, and it is displayed in the screenshot.  Note the color coding: regular buys are green, forced buys from short expiration and margin calls are yellow, regular sells are red, and short sells are blue.

EDIT: I just confirmed shorting to myself still works fine.  At the time of execution, call price was about 199.5, lowest sell at 230, highest buy at 225.01, margin call order at 219.4 and expired short order at 199.46.  I shorted to myself at 227.

I've been rolling over my shorts for quite a while with no issues now, so here are a few tips:

1. If you're setting a price limit on your short intending to buy at that exact price, then don't set the quantity.  Instead, manually enter the collateral amount as 2*price limit*desired quantity.  The quantity will display the amount this would collateralize at the current feed, but ignore that.  You can just buy the desired quantity at the price limit you set from your short and the orders will fill each other properly.

2. Expired shorts force a buy order at exactly the feed.  Margin called shorts force a buy at 10% above the feed.  You can see these two orders in the screenshots posted in this thread with their prices in yellow instead of green: The buy at 205 is the expired short order and the buy at 225 is the margin call order.

3. I don't know how much difference it makes, but I always increase my desired number of connections to 45 instead of 20 to try and minimize my latency on receiving new blocks and seeing new orders sooner.

The GUI is sometimes a little weird with my orders showing and hiding as they're in the process of being matched with each other, but if I ignore that it seems to work fine, and the GUI catches up with what actually happened soon after.  The new graphene system should resolve this sort of GUI issue since it pushes updates to the GUI instead of the GUI constantly checking for updated data.

The NOTE UIA is indeed interesting.  It represents shares of the Music chain behind PeerTracks, whatever it will eventually be called.