OP makes a compelling case.  Will the community rally around this idea?  There is still time for BitShares to become one of the dominant chains alongside Ethereum and Bitcoin, but the window of opportunity is starting to close.

Quote from: bytemaster on June 25, 2015, 12:47:42 pm

The delegates will have to sell this BitUSD on the market to get BTS and then continue to fund the reserve pool.     This is not an ideal situation because it takes the delegates 2 weeks to take any action.  So I was proposing to automate the process of selling the BitUSD and funding the fee pool.

Automation would be ideal. Couldn't the transaction include operations to do the conversion via the market? For example, a fill-or-kill limit order asking for exactly the amount of BTS needed (in exchange for the BitAsset) to pay the transaction fee, where the proceeds from that immediately go to pay the fee. If the liquidity of the market suddenly becomes really bad since the transaction was created such that the full conversion cannot happen within the price limit, then the transaction becomes invalid. If the nodes reject transactions that would not be able to satisfy the fee with the state of the market at the end of the previous block (despite the risk of false positives), it could reduce the amount of invalid transactions that need to be processed in the inner single-threaded engine at the cost that users might need to be willing to accept a slightly higher limit price to get their transaction processed.

The clients could automatically modify any transactions that deal only with BitAssets to add this fill-or-kill limit order operation to pay the fee and make the process entirely transparent to the user. If the user had plain-text BTS in the account (and the client settings were set to prefer it, which would be the default), the client would prefer using BTS directly since it would make the transaction slightly cheaper. Otherwise, it would all still work without the user having to worry about manually converting the BitAssets to BTS.

Furthermore, this could be used as an alternative to the fee pools of privatized BitAssets and UIAs assuming the BTS/{BitAsset,UIA} market had sufficient liquidity. The client could even automatically calculate whether the fee pool conversion ratio set by the issuers was likely to be cheaper or more expensive compared to fill-or-kill limit order method and choose appropriately.

Very thoughtful analysis as usual.  I think it makes sense to give the user options re: paying the fee, but it needs to be transparent or at least trivial to the user by default, otherwise adoption will suffer.

Wow, that was great.  Adam is a top-notch interviewer.  And with limited time to cover a lot of ground, Dan really gave a fantastic overview for anyone newly looking into Bitshares.  Of course it would be great if they could do a follow-up, with a deeper dive into some of the details, perhaps this time with Andreas participating.

A lot of ground has been covered on this thread, and it seems that multiple issues are being conflated.  But let's look at things logically.  For starters, I take it as a given that the devs want BTS to succeed.  I also understand that the devs need to be paid for their work.  And we should be looking to ensure they can devote as much time as possible to continuing the development of Bitshares.  If there are enough funds currently available to sustain every dev, great.  If not, it is understandable that they would need to supplement their incomes.  Whether they do so as individuals or as a company is really none of our business. However, what does NOT seem appropriate is for Cryptonomex to separate the intellectual property from Bitshares considering BTS shareholders have funded the development. Not to mention, in that case we'd have a divergence of interests between the devs and BTS shareholders.  This does not imply there are any nefarious intentions on the part of the devs.  But the realignment of interests would be undeniable and problematic.  I think this should be addressed ASAP as uncertainty around this issue can't possibly be helpful.