OK, thanks. Fortunately, there was no BTS lost (other than the registration fee). Should I click Create New Account, or delete something first? I've heard warnings about having two accounts in the same installation instance.

If this delegate "delegate-proposal-proxy-test.misc.nikolai" is not voted in, no differentiation is made between people who completely missed the memo, and active members like Ander who explicitly abstained.

NuBits has the same problem. As more and more diverse holders become absent voters, it becomes more and more difficult to approve anything (which requires 51%). With delegates, at least, you don't need 51% of stake voting "yes" to be approved -- you just need more votes than the other candidates receive.

The idea in this thread is called "motions" in NuBits, and already exists on that blockchain, but with the above-mentioned issue. I would recommend "yes, no, abstain" as three distinct voting states, though then it's not clear how to determine final approval. 3% yes, 1% no, 96% abstain does not sound like the final will of the voters.

That said, the simple fact that this thread exists shows that proposal voting is needed. We're using a delegate to stand in as a proposal to propose proposal voting! 

if everyone's publishing price feeds very frequently, the cost to manipulate the feed is small -- the attacker can simply dump BTS on exchanges, causing a dip in the price feed, then sell much larger BitUSD holdings into margin calls at artificially high prices.

If price feeds are not updated frequently, the cost to attack is even smaller. Simply wait for the feed to get out of sync with the market, and then take advantage of the gap.

I don't think a solution could be less frequent or randomized feeds, because this would make gaps more common.

Does anyone have a historical graph of size over time?

Quote from: Chronos on February 02, 2015, 11:03:32 pm

I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.

If you include 51x more transactions then tx/sec ratio will be the same.

This would still worsen the exchange, because the blockchain frontruns you. See http://bytemaster.bitshares.org/article/2015/01/29/How-BitShares-Prevents-Front-Running/.

Quote from: Troglodactyl on February 02, 2015, 09:32:24 pm

If an honest delegate signs a block that elects one or more new delegates, the newly elected delegates will clearly prefer that fork over the one in which the votes that elected them were ignored.

I suspect this will lead to fragmentation of the network which is very bad because it makes possible to do double-spending almost for free.

Also, this is most possible in a 51 vs 50 scenario. If the attackers had a sizable majority, say 81 vs 20, then it would be very difficult for the 20 to add enough ignored votes to their blocks to elect 31 more delegates and remake a longest chain.

EDIT: It should come as no surprise that 81 delegates can control the chain. What is notable is that 81 delegates can (maybe) control the chain and never be voted out without a hard fork, and that bribery methods can (maybe) turn a delegate majority into a Nash equilibrium outcome.

This looks like a viable attack to me. A disruptive hard fork might be needed to overcome it.

The post-attack scenario is more like a company unable to hire anyone new, with a group of employees that are impossible to fire. Worse, these employees do not have to act in the best interest of the company, but they still receive pay (BTS) no matter their behavior, which they can constantly dump on the market for "real money". Not good, and not anything like today's "centralized" companies.

Also saying that bitassets are repackaged bitshares is totally true (it's the entire point).

Makes sense, but anyway, we're a bit off topic. Here's my question again:

Does this change increase, or decrease, the risk to "normal folks" holding BitUSD, who don't want to mess with suddenly receiving BTS in their wallet instead of BitUSD?