Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - theoretical

Pages: [1] 2 3 4
Technical Support / Why annual memberships are going away
« on: March 10, 2016, 06:50:03 am »
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.

[2] As of this writing, 31 annual membership upgrade operations and 5744 lifetime membership upgrade operations have taken place on the chain.
[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.

General Discussion / Why did we suddnely make two releases in two days?
« on: December 16, 2015, 08:40:09 pm »
Quote from: bytemaster
We have a new release out that addresses some late breaking security concerns issues.  Most exchanges have already been notified.  There have been a series of releases over the past two days.  The most recent release fixes a operation numbering bug and is only necessary for those using operation ids.  Otherwise, the unannounced release made last night is identical to the release made today.   

We apologize for the rapid release (3 updates in 3 days), but would like to thank the community members (you know who you are) who helped us identify and fix a significant security vulnerability before any money was lost.

Today's new release 2.0.151216 is basically the same as yesterday's release 2.0.151215, but 2.0.151216 maintains the numbering used by 2.0.151209 and earlier for 1.11.x objects.

The renumbering in 2.0.151215 was an unintended, accidental side effect of fixing a critical security vulnerability.  Our first awareness of this vulnerability was when technical details of it were publicly posted.

The good news:

  • The exchanges have been informed of the problem and the availability of a fix for about 20 hours now.
  • If an exploit was attempted, it would leave evidence on the blockchain.
  • We looked, and did not find any such evidence; no one has actually attempted to exploit this vulnerability.
  • There has been no loss of funds (that we are aware of).
  • Anyone who didn't get the word and is still running 2.0.151209 or earlier will realize they need to upgrade when they desync due to tomorrow's hardfork.

Some more details about the situation:

  • In a private conversation, I found the longstanding community member who discovered the problem was already aware that security-critical vulnerabilities should not be publicly disclosed until a fix is available.  He simply had not realized the security implications of the problem he'd found -- a totally understandable human mistake, he did nothing wrong.  To his credit, after being apprised, he took it upon himself to delete technical details from his postings.
  • As you can imagine, we felt under great time pressure to produce a fix as quickly as possible.  In addition a key developer had to leave suddenly in the middle of the day.  So we weren't able to test and review the patch as much as we would have liked.
  • The nature of the vulnerability made it much more dangerous to exchanges than normal users.  We wanted to give the exchanges some lead time to upgrade their internal systems, as obviously exchanges are key partners in our community.  So we delayed posting about the release on this forum until we were sure the exchanges had their situation under control.

General Discussion / New release 2.0.151209
« on: December 09, 2015, 11:57:01 pm »
New release 2.0.151209 at

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


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


- 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


- 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.

There are two deployed Graphene-based blockchains in production right now:  Bitshares 2 and Muse.  That number will only grow in the future.  For example, at some point we would like to create a demo network which will be like a testnet, but with interesting stuff like live price feeds and (maybe later) other interesting stuff like market bots.  As things stand now, I'm told it can be tough to get new users when the first thing they hear is "you have to buy lots of BTS to really experience the system."   With a demo net where none of the tokens have real value, we can give away the core token, so everyone can experience how awesome Graphene is and try some of the more advanced features like creating assets, without committing to buy anything until they're ready.

Anyway, we need a way to effectively manage features which may or may not be deployed on each of the branches.  To that end, we've moved to a new forking model:

Be advised the master branch has been force-pushed, as I used the new forking model to help me make sure all the new features were properly tested for today's release, and there wasn't really a simple way to reconcile things without force-pushing to the master branch.  We'll try not to do this often on master (develop is another matter).

The single most important item for community contributors is to please base your commits on stable.

Muse/SoundDAC / MUSE 1.0.151101 released
« on: November 02, 2015, 06:51:18 pm »

Release is available at

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.

General Discussion / BitShares 2.0.151101 released
« on: November 02, 2015, 04:21:15 pm »

The release is available at

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.

EDIT:  If you run a MUSE node, you will need to update MUSE release as well, see

General Discussion / Economics of subsidized mining pool
« on: February 05, 2015, 04:30:55 pm »
For those who haven't been following, the following changes are planned:

- will pay out in BitUSD
- will eliminate its pool fee
- The payout will be subsidized ("juiced") +5% 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 +5% 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 +5% 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 +5% 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).

The "provocative" post [1] raises an interesting point.  Does publishing feeds with high frequency harm the network?

The idea is 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.  A relatively small manipulation -- only needing to clear out the order book depth immediately available on the exchanges -- can be amplified into a much larger manipulation -- margin calls to force covering at inflated prices by the entire short float.

OTOH if you have a random update interval (with some known expected value), the attack is much more expensive.  E.g. if average feed publish interval is 8 hours, then (assuming all delegates are online and honestly reporting prices) it takes 4 hours to update the median feed, so the attacker would have to sustain his dump for 4 hours, making it more expensive.

Also, "reactive" publishing -- publishing after a sudden price movement -- would also have a downside, it would mean a lot of delegates would update at the moment the attack commences.

I think we should consider the possibility that feed updates need to be done more slowly so that traders have time to move funds into / across exchanges and force any dump to break through the all the actively trading capital in the ecosystem, not just whatever happened to be immediately available on the exchange(s) when the dump occurred.

The main cost is that if there's a news event at a single discrete point in time that causes a quick price change, margin positions may not immediately be liquidated and the price would have time to fall further before the feed caught up and the positions started to unwind.





不过,楼主认为这个方法可能有一个缺陷,如果价格变化得太快,空头仓位不能及时被平仓,等缓慢节奏的喂价改变后,这时候空头仓位的抵押品可能就没有那么充足了。 大家有啥想法?

Stakeholder Proposals / DAC organization of chance games
« on: January 31, 2015, 09:26:09 am »
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.

We should have a delegate whose job it is to identify tasks suitable for community contributors.  For example, quickly off the top of my head and going through the issue tracker, the following aren't considered critical enough to spend much core developer time on right now, don't require a thorough understanding of the code, and would be a great place for a new-ish contributor to get their feet wet:

- Write help documents, blog posts, tutorials, etc. explaining a particular screen or click flow
- Implement robohash server natively in the wallet
- Alternate image sets for robohashes
- Testing, testing, testing!  Explain our test frameworks, write better ones, write tests that expose new bugs or reproduce old ones!
- Find a place where double is used in the code, rip it out and use an exact data type instead
- Test various workflows, such as cold storage
- Find and fix the functions that use too much stack space
- Let collateral vote
- IPv6
- Serialization code generation for multiple languages (perhaps by translating FC serialization to protocol buffers or the like)
- Begin to document our almost entirely undocumented homegrown do-everything library, FC
- Allow UNIX sockets to be used, including passwordless authentication based on user ID like Postgresql

Before I became a core developer, I was a community member.  Some of these were fixes I was considering working on.  I didn't want to put forth substantial engineering effort to write a patch without some reasonable expectation of payment, and bytemaster was leery of promising payment for a product that hadn't been created (and I'm sure I3 budget woes due to AGS funds hurting from BTC price decline didn't help the situation).  Now that I'm a core developer, we've solved the impasse, but most of my time is taken up with pressing issues and new feature development / testing.  I haven't even really had time to set up price feeds or a daily pay withdrawal script for my own delegate!

In early days, there were bounties for many tasks, but I believe this was discontinued when it was discovered that managing the bounties was taking too much time away from development.

So I'd like to see a 100% delegate slot used to fund small, self-contained projects like those I listed here.  The delegate maintainer would be responsible for putting together a list of tasks and awarding payment, community members could bid on tasks, and the core team would have the final say on merging pull requests into official releases.

DevShares / Can't connect to DVS default peer, "Operation canceled"
« on: January 09, 2015, 08:48:19 pm »
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:

Code: [Select]
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 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 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 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 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:

Code: [Select]
2015-01-09T20:45:38 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Forcibly disconnecting from handshaking peer 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 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

Stan / bytemaster should publish a budget spreadsheet of how much BitUSD they think is necessary to run core operations for the quarter / year, broken down by TITAN account.

Then, every day a script sends an IOU UIA to each account for each dollar of shortfall between their budget and what they were able to earn directly from the DAC with their delegate(s).

For the paranoid, public information can allow a script to audit that the IOU issuance matches the budget.  The IOU UIA can be issued by a multisig address signed by multiple trusted community members running independent copies of the script.

Then we get one or more new 100% delegate(s) who promise to use their newly created BTS (minus reasonable commission / expenses) to buy BitUSD, then create a buy wall at 1 IOU / BitUSD.  Burning any IOU they obtain (or returning them to the issuer address, I think burning UIA is actually not implemented; see ).

Since the IOU is a UIA, there is no centralization issue simply letting bytemaster inflate as many IOU shares as he wants to and distribute them as he sees fit.  If the shareholders agree that bytemaster's budget is fair and transparent, then they will elect 100% delegates to give the IOU a market valuation backed by the power of the BTS printing press.  If the shareholders don't like the budget, they can simply kick out the delegates that support this scheme.

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.

Stakeholder Proposals / New core developer 100% delegate dev0.theoretical
« on: December 18, 2014, 11:46:19 pm »

I'm the forum user formerly known as drltc [1].  I'm a full-time I3 team member and I'm seeking to run a 100% delegate, dev0.theoretical.

I've been a member of this forum since early days, participating in multiple pre-launch technical discussions.  One of my proposals eventually evolved into the delegate system, a fundamental part of the BitShares architecture that differentiates us from most of our competitors.

I'm a full stack software developer capable of working on any part of the BitShares client.  I diagnosed stack overflow as the root cause of intermittent crashes and instability in the BitShares client by using GDB to step through assembly instructions one at a time.  I've added several RPC's and some other functionality, audited others' commits, and I've both filed and fixed quite a few Github tickets.  I'm quite comfortable with computer science, mathematics and economics, which helps clarify my thoughts on the theoretical aspects of what we're doing.  I'm also a reasonably competent at JavaScript and web stuff (although I'm not always totally up-to-date on the latest technologies and best practices in the area).

I'm currently focused on testing, in particular addressing technical debt in our testing infrastructure.

My main area of interest is design and implementation of core blockchain features.

The DevShares name and concept was my idea (although what we're actually implementing ended up being a little different from my vision).

I could probably think of some other qualifications I have, but I think that's enough -- if you haven't decided I deserve a 100% delegate by now, I don't think you're going to.


General Discussion / drltc's last post
« on: December 17, 2014, 04:24:02 am »

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:


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


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 with better formatting and signature verification. 

How to verify the legitimacy of this post

Download and verify the file:

    wget -O - | tee | sha256sum

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


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).

Pages: [1] 2 3 4