Today I have zero use for BitShares. Let me lend bitUSD to traders on bitshares at 20% annually and I will put $20,000 into bitUSD tomorrow. Let me borrow bitUSD against my bitUSD collateral to buy bitBTC and I will stop using Bitfinex tomorrow.

I don't understand. You want to borrow BitUSD on a BitUSD collateral? How does that make sense?

Are you asking to borrow money from the blockchain that is not more than 100% collateralized? That's a big no no. The blockchain has no ability to force you to pay. The blockchain cannot sue you in court if you refuse to pay your debt. The only thing a blockchain can do is seize the digital assets on the blockchain that you lock up as collateral to back your debt.

Similarly, you can lend BitUSD to other people who do not collateralize their loans (I am not talking about margin trading which is possible with simple tweaks to the BitAsset rules) but when your counterparty is an anonymous person, there isn't much you can do if they refuse to pay the debt. Who are you going to sue? The most you would be able to rely on is hurting the reputation of their pseudonymous identity. No big deal, they just make another one. Until we have identity verification on the blockchain, uncollateralized lending is not interesting.

We will be starting to post only the finalized hangouts.   The team and I have talked about it and think with some of our plans movies forward that it would be best this way.

-5% to that. How is taking away choice the better way? Besides it isn't enforceable since anyone who attends live can record and post the raw recording at virtually no cost.

Why do you want the extra level of indirection in determining block signers?

I would prefer the voting slate associated with each BTS balance to vote for 101 block signers as it currently does (no extra level of indirection required), but to take away the price feed responsibility from that set of 101 block-signers. Instead the 101 block signers (the "delegates") would in turn delegate the task of updating price feeds to another set of accounts (which they can belong in as well if they choose).

Also, these delegates would only be block signers (and the authority to submit and vote on binding proposals, dynamic parameter changes, and updating the price feed authority set and the worker pay list). All other tasks that the shareholders want to see happen for the benefit of the BitShares ecosystem (which would require dilution to pay for) would be implemented through a worker system (my latest proposal on how this worker pay system could be implemented can be found here).

Edit: By the way, I propose the following terminology. The term "active delegate" can be used to describe a member in the set of accounts that are selected via an official (meaning recognized by the blockchain consensus system) BTS stake-based voting system (and therefore the blockchain knows that this set of entities has some authority). The term "candidate delegate" can be used to describe a member of the set of accounts that have registered as candidates who could potentially be voted in as an "active delegate". And "delegate" can either be used to refer to an "active delegate" or "candidate delegate" depending on context (but it should be assumed that it refers to "active delegate" if the context isn't clear). Any other sets or groups of accounts should not be referred to as a "delegate". Other names should be used to describe them, such as block signers, price-feed submitters, workers, board of directors, etc.

Shouldn't your buy table also have entries at 10% above the feed price for the margin-called orders?

Also I think it would look much better if you coalesced orders at the same price together. That means there shouldn't be more than at most two yellow items (one for expired cover orders and one for margin-called cover orders). If a user wants to a see a more detailed break down than that, they always could click the "Margin Orders" button (which I think is misleading and should instead be labelled "Cover Orders").

Uhh... why not just use the BitShares DEX? That's its purpose.

Edit: I just realized the market engine has a matching bug (again ). However, from what I understood, regular BitUSD sell orders (not shorts) would still match with your buy order.

I see absolutely no reason why we should pay an exchange for integrating BTS and/or BitAssets. After all, they're supposed to earn money from trade fees. So they should fund the necessary development themselves. Unless they're repaying the DAC's investment, which I find unlikely.

giving them coin in exchange for enlisting , that's the unwritten common rule for exchanges .

I don't agree with voting in a delegate specifically for an exchange. They are a for-profit business not a public good for the benefit of the BitShares ecosystem. If they are a worthwhile exchange, they shouldn't need an ongoing subsidy.

However, I can understand providing some initial subsidy in the form of helping them out with integrating the BitShares client software with their exchange or even providing an initial subsidy to cover their integration costs to offset their risk of investing time and resources for a coin that may not provide enough volume to provide them profit (of course that assumes that we are confident that the BitShares markets on that exchange will have sufficient volume and liquidity, otherwise it is a waste of our money). The former can be done by having some of our devs help out with the integration process and offering technical support (although the bulk of the work should be done by the exchange's devs or they should pay our devs consulting fees), and in this case the devs are already paid through their own delegates. In the latter case, I think a delegate that is specifically for the purpose of providing small one-time lump sums to different projects in order to bootstrap them (like fund.bitsharesbreakout) is more appropriate. However, I don't like the idea of voting in a delegate specifically for the exchange.

Finally, I really wish we would put more resources into getting a decentralized BTC UIA on the BitShares blockchain so that we can start using our DEX rather than relying on these centralized exchanges (who in theory should be our competitors).

I really think we need improvements to the way we pay delegates and workers. Here is my latest suggestion to get a little closer to the ideal system by making minimal changes.

First, instead of each delegate candidate only having a single pay rate, they would have the following:

• Percentage budget for worker distribution
• Budget limit for self-pay
• Salary

The percentage budget for worker distribution (PBWD) would be a percentage between 0 and 100% (just like the current delegate pay rate) and budget limit for self-pay (BLSP) would be a BTS amount. The actual budget for worker distribution (BWD) for an active delegate, which is in units of BTS, would be calculated by multiplying the delegate's PBWD and the per-delegate BTS allocated for that round (this is the per-block inflation limit as of that round plus any per-delegate fees allocated for distribution in that round). Another important quantity, budget for self-pay (BSP), is defined for each delegate as min(BWD, BLSP). The registration fee for a delegate is based on the BLSP value, not the PBWD value. After registering the delegate, the delegate can not increase the values for PBWD or BLSP, but they can change the Salary however they wish at any time. The PBWD and BLSP can be decreased at any time, however the change to these values do not go into effect until the end of the round.

The salary of a delegate would specify a particular BitAsset type (or alternatively BTS) and provide a quantity in that BitAsset. The idea behind the salary is that the blockchain will multiply the quantity with the latest price feed for the corresponding BitAsset to get an estimated salary per round in BTS units. If that number is larger than the BSP quantity, then the salary will be limited to the BSP quantity. The actual salary (SAL) in BTS units to transfer to the delegate is calculated at the beginning of the round using the latest price feeds at the beginning of the round. If there are no recent price feeds at the beginning of the round for the specified BitAsset, that delegate will simply not be paid in that round.

At the end of the round, the total salary (TOTAL_DELEGATE_SALARY) distributed to delegates that produced blocks is calculated (TOTAL_DELEGATE_SALARY = sum of the SAL for each delegate that produced a block in that round) and the sum of each active delegates' BWD (TOTAL_AVAILABLE_BUDGET) is also calculated. The difference TOTAL_AVAILABLE_BUDGET - TOTAL_DELEGATE_SALARY gives the remaining worker budget (WB). Then, the WB is distributed according to the "worker pay list" as of the end of that round.

The "worker pay list" is a list of the PAY item which is a tuple (BITASSET_QUANTITY, BITASSET_TYPE, ACCOUNT_ID) or the LIMIT item which only has one value BTS_LIMIT_QUANTITY. Similar to delegate pay, the BITASSET_QUANTITY and BITASSET_TYPE together define the pay amount and are converted into the appropriate amount of BTS using the latest price feeds at the time (this time being at the end of the round). So you can think of this process as mapping the list [A] to list [c] with a function f : a -> c which maps PAY (BITASSET_QUANTITY, BITASSET_TYPE, ACCOUNT_ID) to PAY' (BTS_QUANTITY, ACCOUNT_ID) and maps LIMIT (BTS_LIMIT_QUANTITY) to itself. Again, if there is no recent price feed for the specified BITASSET_TYPE of an item, then the BTS_QUANTITY of the mapped tuple of that item is simply set to zero. At the end of the round, the blockchain goes in order through this second list (the [c] list) and if the item is the PAY' type, it pays BTS_QUANTITY to the specified ACCOUNT_ID as long as there is enough value in the WB, which is updated (WB := WB - BTS_QUANTITY) as it goes through the list, and if the item is the LIMIT type it burns (WB - BTS_LIMIT_QUANTITY) amount of BTS (assuming that it is a positive number) and sets WB := min(WB, BTS_LIMIT_QUANTITY) before proceeding with the rest of the list. If it reaches an item in the list where the BTS_QUANTITY exceeds the updated WB at that point, it will simply send WB amount of BTS to the ACCOUNT_ID and stop processing the rest of the list.

The "worker pay list" allows the blockchain to prioritize who to pay when money is tight. A typical set up would be to have multiple rounds of worker pay in the list. For example, if there were 3 workers (A, B, C), one possible "worker pay list" might be the following:

• LIMIT (3500)
• PAY (3, BitUSD, A)
• PAY (1, BitUSD, B)
• PAY (6, BitCNY, C)
• PAY (1, BitUSD, A)
• PAY (1, BitUSD, B)
• PAY (6, BitCNY, C)
• PAY (1, BitUSD, B)
• PAY (6, BitCNY, C)
• PAY (1, BitUSD, B)

So with the above list, if there is enough money to pay the entire list, both A and B would receive 4 USD worth of BTS per round (approximately $125,000 per year) and C would receive 18 CNY worth of BTS per round (approximately $90,000 per year). But let's pretend that money got tight (the price of BTS went down for example) and the DAC would only afford to pay up and including the 6th item of the list fully, the 7th item only partially, and the rest couldn't be paid at all. Let's say approximately $7.25 worth of BTS was available in the worker budget for each round (and let's assume that amount worked out to less than 3500 BTS). In that case, A would get the full 4 USD worth of BTS per round, B would only get half their normal pay or 2 USD worth of BTS per round, and C would perhaps get approximately 7.5 CNY worth of BTS per round. Also the LIMIT could further limit how much each worker gets paid. If the price of BTS were to drop to $0.003/BTS and the WB was 4800 BTS at the very beginning of the list, then if the LIMIT item wasn't there there would be enough BTS in the budget to fully pay the three works (only 4000 BTS would be needed in WB). However, with the LIMIT item at the top of the list, the 10th item would only receive partial pay.

Finally, there needs to be a way to update the "worker pay list" (which is initially set to the empty list). Any active delegate can submit a proposal for a change to the "worker pay list" and they can cancel their submission at any time. If they submit a new proposal when they already have a pending submission, the old proposal will be cancelled and replaced by the new proposal. Each active delegate is also allowed to submit a vote for any delegate's proposal (by submitting their delegate ID) but the vote only counts if it is for a currently active delegate who currently has submitted a proposal. Again, they can cancel this vote at any time and submitting a new vote automatically cancels any previous vote. Also, if the delegate they are voting for cancels their proposal (or it is automatically cancelled by submitting a new proposal), all of the delegate votes voting for that proposal also automatically cancel. If enough active delegates (let's say >=76) vote for the same delegate proposal, that proposal will become ratified. When this happens, the proposed changes from the ratified proposal update the "worker pay list", then the proposal submission is automatically cancelled and all of the active delegate vote submissions are also cancelled.

These proposals consist of a sequence of operations. There are four types of operations: ADD_ITEM, MODIFY_ITEM, REMOVE_ITEM, and REMOVE_ALL. The REMOVE_ALL operation removes all of the items in the current "worker pay list". The ADD_ITEM, MODIFY_ITEM, and REMOVE_ITEM operations require a non-negative integer which specifies the zero-based index of an existing item (and the integer equal to the number of items in the list is also acceptable for the ADD_ITEM operation). REMOVE_ITEM simply removes the item specified by the index from the list (shifting all items coming after it up to close the gap). ADD_ITEM adds an item immediately before the item specified by the index to the list (shifting it and all items coming after it down to make room) or it just adds the item to index 0 if the list was empty. MODIFY_ITEM does not add or remove items but rather simply modifies the values for the item specified by the index. ADD_ITEM and MODIFY_ITEM operations obviously need an additional argument to define the new values of the item which can either be just a BTS_LIMIT_QUANTITY for a LIMIT item or the tuple (BITASSET_QUANTITY, BITASSET_TYPE, ACCOUNT_ID) for a PAY item.

So with the above setup, it would take a super majority of the delegates to make changes to worker pay and even then they could not inflate BTS in each round by more than TOTAL_AVAILABLE_BUDGET which is simply the sum of each active delegate's BWD (which cannot exceed the BWD they were elected with). Also, there is still the hard-coded dilution limits that guarantee that TOTAL_AVAILABLE_BUDGET <= 101 * (hard-coded per-block inflation limit). The idea is that the delegates will listen to the shareholders through future non-binding proposals and make the appropriate changes that the shareholders want. Until the appropriate tools for non-binding proposals are available in the client, the delegates should just do what they think is best for BitShares.

The delegates can still get paid individually even if a super majority is never able to agree to any "worker pay list" so there is no new added risk of delegates not getting paid with this system. The delegates get the convenience of specifying their pay in USD (or other BitAssets), even though they are still actually paid in BTS, which means they do not need to manually burn excess BTS to get paid their fair salary (the blockchain will automatically do it for them). The delegates just need to make sure that the BSP they are elected with is high enough to give them their desired USD salary even as BTS price changes. And if BTS price drops so low that they cannot get their desired USD salary due to BSP limit, they are simply forced to deal with the lower pay as they are now (or maybe they can get a new delegate voted in with a higher BSP).

In my calculation, 5 delegates for 42 months. Baaed on current BTS price.
But here's variables. Bts price can go up during the fundraising, and some people will sell moonfund at discounted price.

Right, so assuming Moonstone will be restricted to only 5 delegates, and assuming the price of BTS does not rise higher than what it is right now in the next 30 days, the cut off must be at least 3 and a half years in the future to have a chance of paying back the 15%. However, if they decide to have the cutoff be 30 months with 5 delegates, the best they can do is 0.81 BTS (not 1.15) for every BTS invested.

That is why it is important to not start the buyback at a 1 MOONFUND = 1 BTS rate, because anyone who moves fast every time more BTS is added to the sell wall will profit at the expense of everyone else. If a continuous buyback is still desired, the appropriate thing to do in that case would be to buyback at a rate of 1 MOONFUND = 0.705 BTS (obviously the exact numbers will change depending on how the price of BTS change over the next 30 days).