It's difficult to vote for witnesses. I think there could be a list of witnesses already voted in where the user could set order to show choosing witnesses with the smallest amount of missed blocks. I need to have a previous list compiled by me in order to add them. Plus when I go to the Explore/Witnesses menu to check the ones I want to, when I go back, the list of witnesses disappears making me start all over again. This means each time I add one I need to publish changes. Why can't I add all the ones I want first and then publish them?

Exactly same issue for committee members.

This goes in hand with Nielson's 6th Heuristic

Recognition rather than recall
Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

Where will we be in two and a half years?

I agree, we should have a section that actually shows what we have and offer. A video on the index page and a few screenshots. Then maybe later videos with use cases similar to the ones made by Factom that really get users to understand what they could do with the tech with examples. It's easier for them to have the "aha moment"

Market cap of crypto token is one meaningless number.

Not when you depend on it to develop, grow and succeed. Once again people seem to forget who pays for development. If someone needs $50k to develop something at these prices, it will cost the chain 3x more BTS than if the price was at one cent. At the ath of 5cents or with a marketcap similar to what ethereum currently has, we would pay x16 times less!

It matters, whether you want it to or not. We got extremely lucky to have onceuponatime to pay 50k of his own pocket to develop a feature. What would you think it would happen if it was the chain who paid for it?

What do you think it will happen if we keep getting more and more worker proposals? What if we have a total of $100k, $200k? On one side is good we will have development. On the other side, it's not so good because we're walking that thin line at the moment. Too many worker proposals will get BTS diluted which was what caused this whole spiral all the way down.

The fact the chain can pay for development, which really is all of us, doesn't mean we have an infinite amount of money to fund whatever we want. Price matters in BTS because it's directly involved with it's own development.

You dont get worker proposals, you don't get development
You get too many or fail to manage them and it will go down since people hate the idea of dilution and already had a bad experience with it.

BitShares has to walk that thin line until we get to higher levels and we have more money for development. The good news is, if we succeed and go to way higher levels sometime in the future, then we will be able to have even more development made.

Just don't say marketcap is a meaningless number, not for BTS. It depends on it to survive. Unless you can assure me you can find more people like onceuponatime, willing to put money from their own pocket, which was something very very critical at this phase we're in. It was a one in a million luck shot we had. At least that's how I see it. At this moment - even though I don't agree it's the feature that should be developed - it was one of the best things that could have happened to BitShares.

Even with FBAs I doubt shareholders have much more money to throw at it, after all they've been through.

Congratulations! Hope to see a few articles on this! Does it deposit on our BitShares account as soon as CCEDK receives our deposit? Is it automated yet?

I'm of the opinion a user will still use an exchange even if they have to pay a small fee, if they really like it. The exchange just needs to provide services that are worth those same fees. Easier said than done, but I believe user's won't just leave an exchange they like and has given them good support just because of a relatively small fee. I'm not a trader though.

Quote from: Akado on January 21, 2016, 08:21:29 pm

No. I'm talking per account. If an account does what I mentioned above, that account's fees scale or get delayed.

And so the attacker moves accounts and continues his attack?

Depends on the algorithm. Assume the network notices there are 10tx/s at any given moment. It delays transactions spreading them throughout random future blocks and readjusts that according to the amount of transaction each block is having atm. Assume it reaches 10tx/s then it starts readjusting them to the next few blocks, if all those blocks are getting filled with transactions surpassing a given limit it extends the next ones throughout the next blocks and gives priority to accounts with single transactions. It would have to compare the number of all transactions made by all accounts in the last X blocks though, that might cause some performance issues..

Of course I don't know about the feasibility of this. If it notices the same account having multiple transactions on an interval of 5 or 10 blocks then rises the fee for that account. Of course he can do this with more accounts. Then you prioritize accounts with less transactions. Assume there are more 100 accounts doing the same, those would get their transactions delayed in future blocks where normal non-attacker accounts would get their transactions prioritized.

The challenge here is identifying attacking accounts.

Imagine each account being flagged if the number of transactions in any given number of blocks surpasses a pre defined limit. Let's say 100 transactions in 10 blocks or 20 transactions per 3 blocks, whatever number we see fit. If an account hits that, it gets flagged and restricted for the following X blocks. From the moment an account gets flagged, all other accounts get a limited amount of transactions per blocks.

This would mean that if the attacker has 100s of accounts, now instead of for example them being able to do each 100tx per 10 blocks they can only do 10. Normal users don't really need to spam the network with tons of transactions, 1 per block is fine per user I guess?

As for big businesses in the future having the need to do more transactions per block, they get a different flag that allows them to have a bigger or no limit at all.

Just throwing some random stuff there. I think the last example I gave makes more sense.. Then any number of accounts would have their number of transactions restricted. I think you might still argue we're making his job easier, but we really only have to find the right limits from here I think. It can be more, or less. It's "just" a matter of figuring it out.

Once again I'm not a technical guy, just throwing some stuff that makes sense in my head, until you come with a counter argument. If everyone brainstormed we might get something.

I know this wont be a popular comment.

I think you should switch to ethereum honestly .   Much easier for developers to learn and get up to speed on. 

There are very few developers with graphene knowledge except the ones you guys already know about.  What are the reasons to stay with graphene? 

Do you guys have a CTO or someone like it that can advise you?  Maybe ask @toast what he thinks about it.  I see him doing development on ethereum now.

Following your logic, why would anyone use graphene then? Or any other chain that's not ethereum?