This is my personal opinion, not an official Cryptonomex statement on the matter.

Annual memberships are broken [1].  Annual memberships are unpopular [2].  They have been disabled in the GUI for approximately one month [3], and were never implemented in the CLI wallet in the first place.

The developers have already sunk more time into the annual membership feature -- indeed have sunk more time into discussing the potential ramifications of deprecating AM's -- than the feature has ever generated in value for the system.  The code is broken, doesn't do what it's supposed to do, and isn't economically worth fixing (it's actually less complicated to disable the old version of the feature and re-write a new version of it from scratch).

Maybe the idea of pricing tiers and lesser memberships is sound.  Maybe it can be made to work.  That's a larger business / marketing concern, which is not really my area.  My area is code.  And from the standpoint of code, if this is an idea that will ever be made to work, then it will be made to work with different code than what we have.  The existing design and code of this feature is simply too broken [4].

The medium-to-long-term decision about whether we'll retire or re-implement annual memberships is still unsettled.  (Although my personal point of view is that, while marketing theory unequivocally says offering AM's should be beneficial, the data [2] equally unequivocally directly contradicts the theory, and experiment is the ultimate arbiter of truth for any real-world project.  Which is why BitShares, and for that matter the whole blockchain industry, is a grand experiment -- although there are a lot of economic theories out there, you simply can't know for sure how real people will act with real money in real economic systems until they're built and deployed.)  Anyway, whichever way the decision of whether to retire or re-implement annual memberships goes [5], the short-term first steps are the same on either route:

The existing annual membership code must be retired [6].  The existing annual members should be given some non-broken replacement for the broken functionality they received.  By far the simplest, least expensive thing to do is simply give them a lifetime membership -- which is a non-broken thing we already have that is similar to (and actually strictly better than) what they were supposed to get.  So we're planning to upgrade every existing annual member to a lifetime member shortly after the next release.

We've maintained radio silence on this, except for advising the committee that annual memberships should be disabled (by increasing the fee to 1 billion BTS).  For the good and simple reason that we didn't want to encourage buying an AM upgrade as a backdoor route to a cheap LTM upgrade (which it would be, if it had been publicly known that AM's will receive a free LTM upgrade in the near future).  Now that AM's are disabled, we're free to discuss what their future should be.

[1] https://github.com/cryptonomex/graphene/issues/539
[2] As of this writing, 31 annual membership upgrade operations and 5744 lifetime membership upgrade operations have taken place on the chain.
[3] https://github.com/cryptonomex/graphene-ui/issues/730
[4] Why this is much more broken than any other part of Graphene involves a bit of Graphene history, but basically what happened is that the requirements of the referral system gained a lot of complexity over time and co-evolved with the code during Graphene's mid-to-late development, leading to an implementation with a sub-optimal design.  Annual memberships were added last, which meant they both had the most existing constraints/complexity to work with, and the most time pressure (the release date was already starting to loom large at the time they were added.)  If there's a second time around for the annual membership feature, hopefully we'll have a much better idea of exactly what we want to build before we start writing code, not be developing an entire new blockchain implementation alongside it, and not be under the same kind of time pressure, which should lead to much better code.
[5] Because of how broken they are, leaving them unchanged is simply not a viable approach from a technical standpoint -- they don't get what they're supposed to get, and in some cases get nothing!
[6] It can't be totally removed because future releases still have to understand the way past releases handled annual memberships in order to sync from genesis to the current state of the chain.

New release 2.0.151209 at https://github.com/bitshares/bitshares-2/releases

Re-indexing will be required.  Hardfork takes effect at 2015-12-16 at 18:00 UTC.

This release incorporates numerous improvements and fixes.

List of changes
---------------

Market mechanics changes

- Refund order fee on cancellation #445
- Prevent margin call from executing unless feed < call #436

Improvements

- Several API calls added by community members (wackou, Scott Howard) #339
- Add propose_builder_transaction2 RPC

Bugfixes

- Fix referral reward percentages #449 #453 #455
- Improve wallet fee handling #434 #435
- Minor improvements to Javascript integration #439
- Unit testing improvements / bugfixes #413 #437

Cleanup

- Remove unsupported full_web_node and light_client #457

Hardfork #445 changes how we handle the fee paid to create a limit order.  Order objects will now have a deferred_fee field.  For orders created before the hardfork time, fees will be routed as currently and the field will be initialized to 0 to maintain compatibility.  For orders created after the hardfork time, the field will be initialized to the fee.  If the order is cancelled, the fee will be refunded to the order object owner.  If the order is matched, the fee will be routed normally.

Hardfork #436 ensures that you cannot be margin called if the feed says you have sufficient collateral.

This hardfork also retroactively corrects two bugs affecting the referral program.  First, the wallet incorrectly sets the referral percentage, resulting in most accounts referral balances being 1% of
what they should be.  In addition, annual memberships were not being handled correctly.

To ensure that the new code and old code do not split the network, we recommend vesting balance withdrawals should continue to be frozen until the hardfork date passes.

Release is available at https://github.com/peertracksinc/muse/releases/tag/v1.0.151101

All full nodes will need to upgrade to this release by Wed Nov 4 16:00:00 UTC 2015.

- Corrects an issue in the previous release that prevents `PARENT.CHILD` assets from being created #409
- Add the capability for asset owner to claim asset fees #413
- Allow asset issuers to blacklist some accounts from holding a particular asset while maintaining a "default accept" policy for other accounts #415

In addition, numerous bug fixes and wallet enhancements have been included, and reindexing performance has been improved.

Reindexing will be required, and should occur automatically.

For those who haven't been following, the following changes are planned:

- minebitshares.com will pay out in BitUSD
- minebitshares.com will eliminate its pool fee
- The payout will be subsidized ("juiced") by our marketing budget

Essentially, we're allowing people to merge-mine the juice, but only if they use our pool and accept BitUSD payouts.

If our target pool volume is $1000 / day, that works out to $30,000 / month new capital, for which the budget would be funding "juice" at which would be $1500 / month or $50 / day (comparable to a traditional marketing campaign).

I think it would be better to simply split $50 / day among all miners who show up.  If the pool volume is more less than $1000 / day, then they get better than returns.  Since our pool volume is tiny at the moment, this would lead to fantastic returns for people who switch early which would be a great boost to our marketing (we might get several people saying "switch to this pool, I did and quadrupled my returns OMG").  More importantly, if we exceed our target, then we can save a lot of money.  If we hit $2000 / day, then our budget would still be capped at $50 a day and the miners simply get 2.5% instead.

Offering a fixed juice budget is basically a no-reserve single-price auction for the capital inflow, which allows the market to efficiently discover the "right" juice percentage.  Which in theory should be pretty close to zero, i.e. if we're the only pool willing to operate at a loss, we should be able to capture the entire market.

Offering a fixed juice percentage of is still buying capital inflow, but like any scheme where you have a price that doesn't respond to market signals, it's likely the price will be too high (we'd be paying more than we need to, exceeding the target and busting the budget) or too low (we could be offering a higher return and attracting more people while remaining within the budget).

I am posting this in response to bingo branch initiated in the repo.  I think before we make any more implementation effort, we should consider how the DAC will be organized.

I propose to have a separate asset type ("chips") for wagering.  Chips would be backed by BitUSD.  Before we begin bingo operation, chips should be issued or redeemed for $1 / chip, those BitUSD are put aside into the chip backing pool.  When 1000 chips are in existence, the bingo operation begins.  Winning bets are paid in newly created chips, losing bets result in destroyed chips.  The chip redemption value would then fluctuate based on winnings and losses, it would always be equal to the number of chips in existence divided by BitUSD in the backing pool.  This is equivalent to a bingo parlor where the commodity for wagering is equity shares in the bingo parlor.

For risk management purposes, the total of all bingo cards in play at a time can be at most 20% of the chips in existence, and players can bet at most 2% of the chips in existence on a single bingo card.  These numbers are just guesstimates, and should be re-evaluated using the Kelly criterion once a concrete pay table is constructed.

If we want chips to have a pegged redemption value (1 chip = $1), then we can have a separate assets representing equity (receive profits / losses from operations) and debt (chips).  If the house is losing, without an equity pool chips will fall below $1 (winnings paid by inflating chips come from all other players).  With an equity pool, BitUSD will flow into the chip backing pool from the equity pool to prop the value back up.  Investors will voluntarily contribute to the equity pool because the reverse flow is also possible.  If the house is winning, without an equity pool chips will grow above $1 (losses paid by destroying chips will distribute the value to all other players).  With an equity pool, the excess value will flow into the equity pool and be returned to its investors (equity pool shares will be creatable / redeemable for proportional fractions of the backing just like chips).

Current internal discussions at I3 have focused on a bingo DAC with only one investor, the yield pool.  I think bingo will have much more potential to attract new investors if we allow them a way to buy a piece of the house (i.e. put capital into equity), not to mention more capital will allow our payout table to have lower risk (or be able to offer larger prizes).

Also, note that there is nothing specific to bingo here.  We can implement other games of chance.  In fact, if we have only delegates validate chip creation / destruction, new games of chance would only require delegates to upgrade, not normal users (but all nodes would still validate all BitUSD flows and could validate chip creation / destruction from publicly available information).

I'm by no means an expert in the applicable regulatory framework, but I believe the law in much of the US treats games without rake more favorably.  And if we use the first model (where the equity in the bingo parlor is what is wagered) it could certainly be argued that players are playing against each other and the game should be legal for the same reason that private no-rake poker games are legal in many states.

I'm creating a brand new DVS directory, but I can't seem to connect to any peers.  I just have the one default peer.  Maybe the default peer is down, or its max connections are saturated?

Here is my p2p log:

2015-01-09T20:35:44        th_a:?unnamed?        open_database ] old database version, upgrade and re-sync                      chain_database.cpp:84
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_0 tid:140470143198976                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_1 tid:140469758711552                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_2 tid:140469750318848                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_3 tid:140469741926144                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_4 tid:140469733533440                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_5 tid:140469388441344                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_6 tid:140469380048640                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_7 tid:140469371655936                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:Mail client proof-of-work thread tid:140469363263232                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:Mail client indexing thread tid:140469354870528                   thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:p2p tid:140469346477824                   thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:stdin_reader tid:140469338085120                  thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:upnp tid:140468851570432                  thread.cpp:95
2015-01-09T20:36:08 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:36:14 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Forcibly disconnecting from handshaking peer 104.236.44.210:2009 due to inactivity of at least 5 seconds                     node.cpp:1235
2015-01-09T20:36:14 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Peer's negotiating status: connecting, bytes sent: 0, bytes received: 0                      node.cpp:1239
2015-01-09T20:36:14   p2p:connect_to_task           connect_to ] fatal: error connecting to peer 104.236.44.210:2009: 0 exception: unspecified
Operation canceled
    {"message":"Operation canceled"}
    asio  asio.cpp:59 error_handler                     peer_connection.cpp:206
2015-01-09T20:36:14 p2p:delayed_peer_deletion_task              destroy ] Unexpected exception from peer_connection's accept_or_connect_task : {"code":0,"name":"exception","message":"unspecified","stack":[{"context":{"level":"error","file":"asio.cpp","line":59,"method":"error_handler","hostname":"","thread_name":"asio","timestamp":"2015-01-09T20:36:14"},"format":"${message} ","data":{"message":"Operation canceled"}}]}                        peer_connection.cpp:109
2015-01-09T20:36:21 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:36:34 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:36:47 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:37:00 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:37:13 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:37:14 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Forcibly disconnecting from handshaking peer 104.236.44.210:2009 due to inactivity of at least 5 seconds                     node.cpp:1235
2015-01-09T20:37:14 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Peer's negotiating status: connecting, bytes sent: 0, bytes received: 0                      node.cpp:1239
2015-01-09T20:37:14   p2p:connect_to_task           connect_to ] fatal: error connecting to peer 104.236.44.210:2009: 0 exception: unspecified
Operation canceled
    {"message":"Operation canceled"}
    asio  asio.cpp:59 error_handler                     peer_connection.cpp:206
2015-01-09T20:37:14 p2p:delayed_peer_deletion_task              destroy ] Unexpected exception from peer_connection's accept_or_connect_task : {"code":0,"name":"exception","message":"unspecified","stack":[{"context":{"level":"error","file":"asio.cpp","line":59,"method":"error_handler","hostname":"","thread_name":"asio","timestamp":"2015-01-09T20:37:14"},"format":"${message} ","data":{"message":"Operation canceled"}}]}                        peer_connection.cpp:109
2015-01-09T20:37:26 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:37:39 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:37:52 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:38:05 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:38:18 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:38:31 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744

I restarted and got something similar:

2015-01-09T20:45:38 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Forcibly disconnecting from handshaking peer 104.236.44.210:2009 due to inactivity of at least 5 seconds                     node.cpp:1235
2015-01-09T20:45:38 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Peer's negotiating status: connecting, bytes sent: 0, bytes received: 0                      node.cpp:1239
2015-01-09T20:45:38   p2p:connect_to_task           connect_to ] fatal: error connecting to peer 104.236.44.210:2009: 0 exception: unspecified
Operation canceled
    {"message":"Operation canceled"}
    asio  asio.cpp:59 error_handler                     peer_connection.cpp:206
2015-01-09T20:45:38 p2p:delayed_peer_deletion_task              destroy ] Unexpected exception from peer_connection's accept_or_connect_task : {"code":0,"name":"exception","message":"unspecified","stack":[{"context":{"level":"error","file":"asio.cpp","line":59,"method":"error_handler","hostname":"","thread_name":"asio","timestamp":"2015-01-09T20:45:38"},"format":"${message} ","data":{"message":"Operation canceled"}}]}                        peer_connection.cpp:109
2015-01-09T20:45:44 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:45:57 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:46:10 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744


If you like this proposal, please vote for my delegate dev0.theoretical which is currently hanging on at #101.

The BTS delegates have what I call feed authority which means the blockchain enforces margin call and short wall rules based on the median feed value produced by the BTS delegates.

I think anyone should be able to create a market-based UIA and optionally specify a feed authority other than the 101 BTS delegates.

This will democratize BitAsset creation -- instead of requiring all ideas for BitAssets to go through the BTS delegates in order to launch, anyone with an idea and access to a data source will be able to create a market-based BitAsset.

To pay the costs of publishing a feed, we should let the asset owner [1] specify a percentage of asset-denominated fees [2] to go to feed publishers.  Since publishing a feed will produce revenue, feed publishers will be able to sustainably pay their IT costs and transaction fees for publishing without diluting new BTS or touching BTS-denominated transaction fees.

There will probably a "long tail" of experiments and small-scale markets, and a few big winners that end up gaining traction and network effects.  All of them will provide value to BTS shareholders since these assets will tie up collateral BTS equal to the market cap times the required leverage ratio (and of course generate transaction fees from feeds and actual transactions as well).

[1] N.b. the asset owner is not the issuer; new asset quantities are issued in the market by shorting.

[2] Bid-ask overlap and short interest.  Even though this is a BTS-backed market-issued asset, we have to be careful about allowing users to pay tx fees with it.  In particular we must go by the actual collateral backing rather than feed price, because an attacker Eve would be able to create a private EVIL asset with herself as the feed issuer, publish an EVIL feed of 1 EVIL = 0.0001 BTS, short e.g. 100 EVIL into existence with a total of 0.03 BTS collateral, and then set the EVIL feed to e.g. 1 EVIL = 1,000,000 BTS.  If the blockchain uses the feed as the effective exchange rate for fees, Eve would be able to use 100 EVIL to pay 100,000,000 BTS worth of tx fees, even though the total BTS she invested to get to this point was only one UIA registration fee and a few tx fees.  Whereas using the collateral backing for the exchange rate, we know the exchange rate is based on real BTS that actually exist, not a fictional valuation based on a user-initiated black swan.

I have come to the conclusion that my username is undesirable for a variety of reasons:

- As an I3 team member, it seems rather unprofessional to advertise a dying competitor with every post.
- My name implies an academic credential I do not in fact possess.
- There are plans to make short TITAN names expire some time in the distant future unless a heavy fee is paid, and I do not want to pay it.
- When I generated the owner key for the drltc TITAN account, I did not take paranoid security precautions since I was only planning on being a casual user and occasional contributor.  Now that I am planning to be a 100% delegate, creating a new username gives me an opportunity to better secure my owner key.
- I will be stuck with whatever delegate name I choose, unless I want to pay the fee to register a 100% delegate multiple times.

Notwithstanding the implication of my click-baity post title, I'm merely retiring the drltc username.  I'll still be an I3 team member and continue to heavily participate in the community just like before, only I will have a brand new username!

Here it is:

    theoretical

For websites where this username is not available, I will be:

    theoreticalbts

I have already registered TITAN and forum accounts for both of these names.

To prove the legitimacy of this message, I will sign the sha256 of this message with drltc TITAN account.

When I chose the drltc name, I had no idea Bitshares would be as successful as it has been, or that I'd end up playing such a huge role in this project.  At the time, BitShares was just another interesting altcoin along with Litecoin, Primecoin, Dogecoin, etc.  The new name marks an increased level of maturity for both the project and my contributions to it.  Great things are ahead for BitShares in 2015!

    drltc, December 16, 2014

A Markdown version of this post is available at https://github.com/drltc/bitshares_toolkit/blob/drltc-lastpost/drltc-lastpost.md with better formatting and signature verification. 

How to verify the legitimacy of this post
-----------------------------------------

Download and verify the file:

    wget -O - https://raw.githubusercontent.com/drltc/bitshares_toolkit/drltc-lastpost/drltc-lastpost.md | tee drltc-lastpost.md | sha256sum

You should verify the content of `drltc-lastpost.md` created by this command matches the forum post, and the sha256sum will be the following hash:

    489af05fa35a928226294e70b7c458af256479310f70c223c894392fec6b4b7e

Put the hash into this command in any BitShares client:

    blockchain_verify_signature drltc "489af05fa35a928226294e70b7c458af256479310f70c223c894392fec6b4b7e" "1f60baa9b38e1bf4b471700f59f174d09c84ca353a3cd5c674c282eeac31cc8d6054e66ca3b4b5a215b524e23d5067fd04a6ed4fc6072d93097f9dfdf7bfaa9918"

The command returns `true` indicating that the owner of the `drltc` blockchain account has signed the content of this post (the really long hex string starting with `1f` is the signature data).