it's a refund worker...
it doesn't really change anything, just explicitly sets the floor for returning unused budget to the pool, which was never being taken out so far
https://bitshares.org/technology/stakeholder-approved-project-funding/

400k from the reserve fund which was not being spent is now being withdrawn and returned to it each day. This is the "floor" that will pick up the scraps from whatever projects users want to fund.

If you don't like it, reject it. But there is no point to reject it, literally does nothing to the value of BTS, and no one is getting paid from it -- it just makes it easier for when the community does approve workers for there to be this "floor"

This should fix the issue in the repo as of Oct 14th...
https://github.com/cryptonomex/graphene-ui/issues/330

It is running at openledger.  However, the last release v2.15.286 happened on Oct 13th.

Can anyone confirm the fix at open ledger?

there are more recent releases (including 4 hours ago)
https://github.com/bitshares/bitshares-2-ui/releases

the ppa:showard314/bitshares on ubuntu has it and windows/mac binaries are available here:
https://github.com/bitshares/bitshares-2/releases

I have a hard time understanding how the bitshares 2 api works.
For example i want to get the transaction history of an account.
in bts 1:
{"method": "wallet_account_transaction_history", "params": ["myaccount"], "id": "0"}

how does it work in bts 2.0 with get_account_history?

you need the cli_wallet api. so the wallet connects to the witness node, and the curl request will go to the wallet port

http://python-graphenelib.readthedocs.org/en/latest/graphene-api.html

Quote from: fav on October 13, 2015, 03:25:06 pm

Discussed this with @svk already, but I don't want this to get lost in translation.

Please bundle the webwallet for local use! In fact, no need to maintain windows/linux light wallet builds if you have a universal browser version in my opinion!

so we add only our local API connection?

...which is?

You can just open it (e.g., "firefox webwalletdir/index.html") and it will be default use the openledger API connection. You can then change the settings to point to your local witness node if you'd like.

Latest update:

Telegram (primary channel)
There is now a backup alert bot.

Most of the active witnesses (and a few other non-active ones) are registered in both Telegram and Slack, except:

1) pc not in Telegram - I just sent him an invite a moment ago. Waiting for his response
pc has joined both Telegram and Slack
2) Thom not in Slack - He is not accepting it for now
3) Holytransaction not in Slack - I sent him invite earlier. Waiting for his response
3) maqifrnswa not in both - I sent him invite earlier. Waiting for his response
4) delegated-proof-of-steak not in both - (dev)
5) delegate.btsnow not in both (dev)
6) lafona not in Slack (he was missed out)- he has confirmed to join Slack when he is back

i've been in telegram for a week and am using sparkato's bot
my name is "Scott (maqifrnswa)" i'll just change it to maqifrnswa

I agree that the network will have to invest in itself. I don't know if worker proposals are implemented in any wallet yet. The blockchain supports it, so you can manually write your own proposal transactions. However, I don't know how much support wallets have for voting for workers. Feature parity was targeted first, now the new features (like workers) will probably be exposed in a controlled manner.

the question is , how much we can set  short_squeeze_ratio to?
which is better? which is bad?
if witness set it to 1000%, all short position will force margin call, and sell at 10% price. I think it's bad.
if 500% is bad? if 200% is bad? if 150% is bad? what's the rule? do we need to set a hard code limit? what's the value?
will you short bitUSD if there is no limit?
in my opnion, 110% should be the hard code limit, if we don't protect short position, nobody dare to short, bitUSD die.

I don't think there is one economically "correct" answer since it depends on collateralization. Well collateralized markets  can have it set much higher than lower collateralized markets. At this point, you have to go by "feel" and adjust accordingly. Or we can use the price feed script to publish a squeeze ratio that is a function of SWAN or average collateralization for each market.

Maybe 1.25xSWAN is a good number? That means:
1.25xSWAN_PRICE = FEED/SQR
SQR= (FEED/SWAN_PRICE) X .8

yes, you are right.
all witness please think about it,  set short_squeeze_ratio between 1001 to 1100.

my opinion is that higher could be acceptable (and actually preferred), but we are making the ratio to the wrong value (FEED instead of SWAN).
https://bitsharestalk.org/index.php/topic,19102.msg245969.html#msg245969

Since allowing a black swan is worse than allowing margin calls in an artificial short squeeze, I'd suggest a larger short_squeeze_ratio (1100). However, that number is kind of arbitrary since it isn't a function of collateralization.