We are operating BTSX as a DAC banking firm.  Human participants include depositors (BitAsset holders), shareholders (BTSX holders), and management (delegates).  AFAICT no human has access to a complete and reliable income statement or balance sheet for two of the DAC's main activities (BitAsset yield and interest on shorts; the latter has not yet been launched).  Why this makes me uneasy should be obvious.

To be clear, I do not think BTSX is in danger of insolvency anytime soon [1].  Rather, I think the network is tying up more funds than it needs to, for longer periods than it needs to, with little transparency as to the amount or intended purpose of the funds which are tied up [2] [3].

Sending a bunch of BitUSD into an accounting rabbit hole for a year is not the best use of that BitUSD, compared to the alternatives:  Paying to longs as yield, auctioning off as interest in a BitBond market to tie up a much larger sum of investor BitUSD, or buying up and burning BTSX.

I believe there are two justifications for letting this situation happen:

- It is desirable to hold some BitUSD in reserve for policy purposes, such as buffering yields to make them less "lumpy" in order to cater to BitAsset holders' preferences for stable, accurate yield projections (and defeat certain technical trading strategies), or an FDIC fund to get rid of underwater shorts.
- Implementation is done at the "micro-level" of individual long balances and short positions.  Exact "macro-level" computations which maintain continuously updated sums of the micro-level activity of O(n) positions undergoing O(m) updates using O(m*log(n)) or less computational resources, is a hard technical engineering problem.

To these I would reply:

- Under the current implementation, policy funds may end up grossly under- or over-capitalized with respect to how much is needed to achieve their intended objectives.  Regardless of whether we as policymakers decide a sufficient FDIC would be 1%, 5%, 10%, 20%, or 50% of existing BitUSD, it would be an incredible coincidence if the reserve developed by the yield implementation reached an equilibrium near the desired reserve level under most market conditions.  (Unless the yield fund was specifically designed to do so, of course.)
- In various forum posts and whitepapers, I've published macro-level algorithms that solve the engineering problems of how to implement efficient macro-level computations.

[1] The much-discussed case of "black swan" price movements that put too many shorts too far "underwater" is always a possibility, but I won't discuss that further here.

[2] Specifically, there are gross approximations in the yield fund computations that result in an enormous percentage of the yield fund being untouchable -- BitUSD holders could not access most of the fund even if everyone claimed yield in the next block.  Similar approximations are planned for the currently proposed implementation of shorts paying interest to longs.

[3] A while ago I posted somewhere on this forum some back-of-the-envelope calculations about what the amount of untouchable BitUSD may be for the yield fund.  While the amount of untouchable BitUSD could, in principle, be determined from the blockchain, AFAIK nobody has actually done this calculation and published the result.

The max short holding period [1] will greatly improve the ease of implementation of shorts paying yield to the longs.  Let's discuss my proposed implementation:

Figure out the monthly yield rate r, I will use r = 1% for examples because it is easy to work with.  How the value of r should be determined is a totally separate issue that I will not address in this post.

When a short starts out, its USD liability will internally be set to (1+r) times the BitUSD given to the buyer.  The extra BitUSD will go into a network-controlled "short yield fund".  In exchange, the short position will get a "short yield fund claim note" with a face value equal to the extra BitUSD.  The claim note is a network-enforced promise from the short yield fund with the following terms:

If the attached short position is liquidated after t months, this claim note shall be redeemed for 1-t times its face value.

Shorting 100 BitUSD at 30 BTSX / BitUSD at the minimum collateral ratio would then result in the short position's balance sheet looking like this:

Assets                                          Liabilities
Collateral                  6000 BTSX           Promise to repay        101 BitUSD
Claim note                   1-t BitUSD         Short holder equity     ???

The columns must balance.  This allows us to solve for the short holder's equity:

101 BitUSD + short_holder_equity = 6000 BTSX + (1-t) BitUSD
->           short_holder_equity = 6000 BTSX - (100+t) BitUSD

Moreover the short yield fund's books are very simple.  The decrease over time of the value of claim notes issued by the fund will generate income for the fund.  This income will occur at an easily computable linear rate that only changes when new shorts are executed or existing shorts cover.  This income can go directly into the yield fund payable to longs every block.  No unbacked BitUSD are ever printed; every BitUSD is at all times backed by a collateralized short promise.

It should be emphasized that the short yield fund and claim notes are an internal book-keeping mechanism.  The user interface should simply show the BitUSD required to cover (in the example, 101 BitUSD minus the claim note's current value) at any given time.  So after 0.75 months for example, the user covers with 100.75 BitUSD, the claim note is redeemed for 0.25 BitUSD.  The total of 101 BitUSD then satisfies the Promise to Repay 101 BitUSD.

We may wish to change the margin call price and minimum collateral requirement computations to be based on 101 BitUSD instead of 100 BitUSD, especially if the mechanism for setting r is some algorithm that could potentially set a high value for r.

[1] https://bitsharestalk.org/index.php?topic=9512.0

Anyone who uses the BitShares client is trusting their money to the maintainers' cryptography skills.

Signing releases with MD5 does not inspire confidence in those skills.

For security, it is necessary to use an up-to-date hash algorithm like sha256sum.  MD5 is insecure; it has a history of published vulnerabilities and successful practical collision attacks.

Using an up-to-date algorithm is not sufficient to guarantee security.  An attacker with the capability to replace the binary download with a malicious file would also be able to replace the hash.  The hash MUST be signed with a trusted public key!

Here is how releases should be signed:

$ sha256sum BitSharesX-0.4.18-x64.exe | tee BitSharesX-0.4.18-x64.exe.sha256sum
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  BitSharesX-0.4.18-x64.exe
$ bitshares_client
>>> wallet_sign_hash drltc "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
"20db75781b52d8830b1eb080fc0f130bce8ce76d0cf1b04a4a00a589404085675b2afc812c9847d1656e0504b6bc0a33f2a4f62671a585c1eec6b5f65cb7ef4b1d"

Then publish the two hex values above.  (For convenience, we put the first number in a file.)  To check, you can run:

$ sha256sum -c BitSharesX-0.4.18-x64.exe.sha256sum
BitSharesX-0.4.18-x64.exe: OK
$ bitshares_client
>>> blockchain_verify_signature drltc "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" "20db75781b52d8830b1eb080fc0f130bce8ce76d0cf1b04a4a00a589404085675b2afc812c9847d1656e0504b6bc0a33f2a4f62671a585c1eec6b5f65cb7ef4b1d"
true

Note, "drltc" in the above commands should be replaced with the name of the DACsunlimited release signing account (it is an implementation detail whether to use the main DACsunlimited account for this, or a dedicated sub-account).

The second step is necessary -- an adversary offering a malicious download can compute their own hash, but cannot produce a signature for the malicious hash without access to the private key of the DACsunlimited signing account.  Which can be more thoroughly secured than access to the DACsunlimited Github account (e.g. cold storage).  I was going to post this last night, but I noticed that you can't actually do the last step with the current client version because there is no blockchain_verify_signature command.  I fixed it in this pull request:  https://github.com/BitShares/bitshares_toolkit/pull/822

We should also work on making builds reproducible, so anyone can verify that the released executable was generated from the published source code without any malicious modifications.  But this will likely need more than a single Saturday evening of development time.

The current yield computation is very crude.  The approximations result in a very low yield compared to "exact" computations.

If we pay 0.01% to everybody whenever the yield fund accumulates to a level where we can afford to do so, what would happen?

I have a feeling this would be very easy to implement and keep the level of network equity in the yield fund to a minimum [1] [2].  I think I have a solution to the compounding problem with this scheme as well, but that'll be a separate post.

[1] By "network equity in the yield fund," I mean "if everyone asked for their yield immediately, how much would be left over?"  I think answer to this question will always be "most of the yield fund" in the current implementation.  Meaning we hold BitUSD potential back because we could afford to pay more interest (which would attract more investors).  And we might be setting the stage for a supply-side margin crisis if shorts need to buy BitUSD to cover, but can't because too much BitUSD is tied up in the yield fund.

[2] If we think it's important to keep a reserve for macro-economic purposes other than yield, like buying up underwater shorts, we can simply set up a separate fund, and explicitly set (an algorithm to determine) its desired balance level (e.g. 10% of BitUSD in circulation).  Then divert fee income into that "macro fund" when the fund is below the desired balance, and "change the sign" of this flow when the fund's balance is above the desired level (pay a portion of the fund's balance as fees).

Some users proposed airdropping user-issued BitAsset FREE [1] to some other coin.

I realized it would be technically possible to support "Private airdrops" with some additions to the blockchain code.  Basically this would involve allowing anyone to help fund an airdrop by sending BTSX or BitAsset(s) to what I call a "dividend address" for that airdrop, which is basically a Merkle hash -- a single 20-byte value representing a snapshot of the Dogecoin blockchain (or some other altcoin) at some point in time.

Anyone with a Dogecoin wallet would then be able to publish a proof to the BTSX blockchain showing how much they owned at the snapshot (which we can verify with the Merkle hash).  The proof functions as a claim against the funds sent to the dividend address.  After some pre-set time elapses, like two weeks, the network stops allowing new funds to be sent to the dividend address, and anyone who published a claim can take their share of the airdrop -- proportional only to other claims.

You can read all the technical details in [2], including an extension allowing the transaction fees to be pre-paid by the airdrop, so people with only Doge could publish their claims to the blockchain without having to buy BTSX from an exchange.

[1] https://bitsharestalk.org/index.php?topic=8858.0
[2] https://github.com/drltc/bitbond-proposal/blob/master/airdrop.md

As a result of a market order being filled, I see this in my tx history via wallet_account_transaction_history:

    |2014-09-11T15:34:03 458522    BID-3728b667        MARKET              0.10001000 BTC          pay bid @ 0.000081967213114754 BTC / BTSX   0.00000 BTSX        [6212bd]|

The first thing I noticed is that the time is wrong, for which I've filed an issue already.

My question to this forum is:  What do I do with [6212bd]?  I have tried:

>>> blockchain_get_transaction 6212bd
null
>>> blockchain_get_transaction [6212bd]
0 exception: unspecified
Invalid hex character '['
    {"c":"["}
    th_a  hex.cpp:13 from_hex

    {}
    th_a  common_api_client.cpp:163 blockchain_get_transaction

    {"command":"blockchain_get_transaction"}
    th_a  cli.cpp:537 execute_command

I want to make sure I'm not missing something obvious before I file another ticket and bother the developers.

I have posted at https://github.com/drltc/bitbond-proposal/blob/master/interest-0.4.13.md an analysis of 0.4.13 yield changes, along with a few proposed modifications to the (approximate) 0.4.13 yield algorithm which should make it much less approximate without making the devs work too hard

My most important algorithmic insight, however, is that an implementation of "exact" yield need not be as resource-intensive as bytemaster currently believes.  So I'll copy-paste my explanation in its entirety as the opening post of this thread, in hopes that will make it less likely to be missed (as I can scarcely blame others for failing to read threads beyond the first three pages when I seldom do so myself):

Quote from: bytemaster on September 09, 2014, 09:36:40 pm

Quote from: arhag on September 09, 2014, 09:09:04 pm

Is this because it would take too much time to compute the factor to multiply the BitUSD value by for each transaction? Meaning if each block determines a factor f_i (representing e^y where y is the per block variable yield rate) for each BitAsset, then for each transaction with BitAsset inputs you would need to get all the BitAsset's f_i from block i = m where the transaction was created to block i = n which is the current block where the transaction was spent, and then multiply the BitAsset value by f_m * f_(m+1) * ... * f_n to get its new value with yield.

Yes.  It would greatly increase database size and transaction processing time.  I know how to "do it proper" from the original dividends design for BTSX.  It requires an accumulation table that must be updated every block for 1 years worth of blocks. 

I'm guessing bytemaster wants to save the product between b[m] and b[n] for all pairs of blocks m, n.  I posted how to avoid this earlier in this thread (four word answer: partial sum skip list), but I'll go into more detail since both of you apparently missed (or misunderstood) that post.

I propose using sums of logarithms instead of multiplying (so we can do many-block sequences without worrying too much about various approximation issues).  Then only save partial sums that are aligned power-of-two length.  So you save (in your notation):

Code: [Select]

run(m,  1) = f_m                                     # for all blocks
run(m,  2) = f_m + f_{m+1}                           # for every 2nd block
run(m,  4) = f_m + f_{m+1} + f_{m+2} + f_{m+3}       # for every 4th block
run(m,  8) = f_m + f_{m+1} + f_{m+2} + f_{m+3} + f_{m+4} + f_{m+5} + f_{m+6} + f_{m+7}
                                                     # for every 8th block, etc... for every power of 2

If total number of blocks is N, this data structure needs at most 2N-1 entries (hint: total size is a geometric series).

So if you want to find e.g. the sum of logs from 0x7159 (inclusive) to 0x1258a (exclusive), you can compute that as:

Code: [Select]

run(0x7159, 1) + run(0x715a, 2) + run(0x715c, 4) + run(0x7160, 0x20) + run(0x7180, 0x80) + run(0x7200, 0x200) + run(0x7400, 0x400) + run(0x7800, 0x800) + run(0x8000, 0x8000) + run(0x10000, 0x2000) + run(0x12000, 0x400) + run(0x12400, 0x100) + run(0x12500, 0x80) + run(0x12580, 8) + run(0x12588, 2)

The proper bit twiddling operations to implement this are left as an exercise to the reader.

Updating a block will usually be fast, requiring only the last few blocks.  Block heights divisible by large powers of 2 will happen and reach higher in the blockchain (on an exponentially rare basis), but in all cases at most log(N) values need be saved, each of which requires at most log(N) time.  (I think the actual bound is just log(N) instead of log(N)^2 because you re-use the tail part and only need to reach back one more entry, but log^2(N) is still fast enough.)

I've put my response to bytemaster's latest interest proposal in a whitepaper on Github.  Available at https://github.com/drltc/bitbond-proposal/blob/master/bitbond.md

Basically the conclusions are:

- bytemaster's proposal will sink BitUSD decentralization by making BitUSD non-fungible
- Fixed interest rate on BitUSD is important for marketing reasons
- A mechanism to reverse BitUSD destruction and return BitUSD-denominated fees to circulation is necessary to prevent a margin crisis if we get into a situation where too many BitUSD have been destroyed
- Market-determined variable interest rate (bond market) is necessary to absorb randomness of fees
- Short interest is necessary to guarantee fixed interest rate
- Implementing a bond market is not too hard in practice

To this I will add in a future revision:

- A highly USD-correlated, cryptocurrency-based bond market is a "killer app" that will drive (currently anemic) BitUSD demand through the roof, and BTSX valuation along with it.