The BitShares 2.0 developers made the design decision that full nodes were expected to be running high-end hardware with good network connectivity.  Most other coins (BitShares 0.x included) keep their indexes on disk, BitShares keeps them in memory.

The hardware doesn't have to be all that impressive.. I think you can get away with 4G if not much else is going on on the system, but it's about the minimum I'd bother trying with.  I often run it on a VM with 6G that is running a few other altcoins.  I usually have to shut something down if I need to do a big compile on that VM. 

The protocol actually does have built-in limits on the maximum size of individual transactions and of blocks.  It encourages smaller transactions by charging a per-kilobyte fee for transactions that exceed the minimum size.  The "create asset" operation that seems to be causing you problems was about a megabyte, so clayop paid the base fee for creating an asset plus about 1000 times the per-kb fee.  The committee can vote to change both the fees and the maximum sizes at any time, and they can vote to increase the per-kilobyte fee to make it more expensive if abuse becomes a problem.  I think the max block size right now is about 2M.

Your OPEN.BTC has been returned.

For deposits, you send use your Steem wallet to send to the "openledger" account, with a memo of "open.steem:my-bts-account-name".  We wanted to use "openledger-wallet" but Steem doesn't allow account names that long.  The web wallet should be updated later today to add this info to the CCEDK tab.

If you're using the Steem cli wallet, the command would be something like:
transfer my-steem-acct openledger "1.000 STEEM" "open.steem:my-bts-acct" true
abit: if the transactions were sent before we enabled STEEM support yesterday, our scanner wasn't looking for them.  PM me the info and I'll check into it.

The OpenLedger gateway is back up and we've processed all transactions from when the gateway was down, sorry for the disruption.

We moved the OpenLedger backend to new hardware yesterday during our scheduled maintenance and all appeared to be going smoothly, but the machine went down several hours later, we're still investigating what happened.

I have checked this api. It is working. Thanks for the help. It gives me input address which I want. I have question in the following request. What is outputAddress?
https://blocktrades.us:443/api/v2/simple-api/initiate-trade
{
  "inputCoinType": "btc",
  "outputCoinType": "bts",
  "outputAddress": "btsnow",
  "outputMemo": ""
}

It is the address that will receive the Bitshares whenever you use the inputAddress that initiate-trade generates.

That call means, "Give me a Bitcoin address where I can send Bitcoin to Blocktrades.  When Blocktrades gets my bitcoin, convert it into Bitshares at the current rate, and send it to the account named btsnow".  In bitshares-speak, you're asking Blocktrades to act as a bridge, doing an instant conversion from Bitcoin to Bitshares.

I have account on https://bitshares.openledger.info. For instance these are the address of my account. How can I deposit to these account?

Symbol	Deposit to
BTC	12NbSB3X25XgrTHT3LFyjWESpe1JZsyDtN
LTC	LQfeVhR1K274zWWr6ym1ZsZxQVbz7DrAub
DOGE	D5CTahPejracpJuDbzBsSRrvp2ZhapJu1o

As I mention above I use initiate-trade api and I am able to generate new input address every time. So I have a question where can I use old input address mentioned above?

These look like addresses you copied from the "Gateway" section of the deposit page.  Those addresses are addresses owned by Blocktrades that are linked to your Bitshares account.  Whenever you send Bitcoin to the address 12NbSB.., it will send the same amount of TRADE.BTC to your account (the account displayed in the left hand side of the screen under the identicon).  You could generate these deposit addresses through the api like this:
{
  "inputCoinType": "btc",
  "outputCoinType": "trade.btc",
  "outputAddress": "my-account-name-here"
}

You can reuse those addresses as many times as you like for as long as you like.  You don't ever *need* to generate a new one, unless you want a new address for accounting reasons.  Even though the wallet only shows you the most recent address, any of the previous addresses will continue to work as well.

I still don't understand why minority fork clients don't just discard whatever short chain they're on and join the main chain where we have >90% delegates participation. We can't rely on checkpoints for long

We only save the undo state for about an hour's worth of blocks (maintaining it is expensive).  For short forks this works out well, but if you get on a fork with >360 blocks on it, you won't have enough undo history available to roll your blockchain back to the fork point, thus you'll never be able to rejoin the main chain even if your client knows it is better and has downloaded all the blocks on the main chain.  If you don't have the undo history to get there, the only other way to get back to the fork point is to reindex or re-download the blockchain from the beginning.  And when re-downloading, as long as there are publicly-accessible nodes out there serving up the wrong blockchain, there's a chance you'll connect to them first and download the wrong blockchain and end up back in the same state, unless you force your client to reject the wrong chain with checkpoints.  Fortunately, as more public clients switch over to the main chain, the chance anyone will end up syncing to a minority fork decreases.

I think this was fixed an hour or two ago in hxxps://github.com/dacsunlimited/bitsharesx/commit/f576715a9787a4a4078aab8d524a9e580342f86f
(fc revision was accidentally bumped when it shouldn't have been, this rolls it back a few commits)

I just downloaded the v0.4.23.1 and synced the full blockchain over the network (after deleting my "%APPDATA%\BitShares X" directory), no problems.

Often when I'm syncing, the status bar at the bottom is amazingly unreliable.  It will say I'm not connected and have no blocks while I am in fact connected and syncing.  Sometimes it will catch up after I'm in sync, often it will claim I'm disconnected until I restart the client.  If it claims no connection, give it a minute or two, then check by running "get_info" in the console and looking at the "network_num_connections".

I don't know how to explain the crash at 81%, unless that only happens with an old database that is corrupted.

>> about
{
  "blockchain_name": "BitShares X",
  "blockchain_description": "Decentralized Autonomous Exchange",
  "client_version": "v0.4.23.1",
  "bitshares_toolkit_revision": "dd761ab7a809fd50548139bfe395847ee9b83992",
  "bitshares_toolkit_revision_age": "15 hours ago",
  "fc_revision": "d1f51dd643bc9063a56bd830208dfb0033cc81be",
  "fc_revision_age": "65 hours ago",
  "compile_date": "compiled on Oct 29 2014 at 19:48:22",
  "boost_version": "1.55",
  "openssl_version": "OpenSSL 1.0.1g 7 Apr 2014",
  "build": "win32 32-bit",
  "jenkins_build_number": 102,
  "jenkins_build_url": "..."
}