If you build the UI app from source, and you upgrade all your node modules (including electron), you may not be able to find your wallet the next time you start because the electron data directory changed

It used to be
$XDG_CONFIG_HOME/BitShares2-light
now is

$XDG_CONFIG_HOME/chromium/BitShares2-light

(on linux $XDG_CONFIG_HOME is typically  ~/.config/)

TO FIX:
import a backup
OR
just cp your original
~/.config/BitShares2-light
to the new location
~/.config/chromium/BitShares2-light

More info:
https://github.com/cryptonomex/graphene-ui/issues/508


Full Story:
The UI app is really just a lightweight chromium browser configured as a node module. The browser module is called "electron" (http://electron.atom.io/). The browser module itself changed where it saves its data:
https://github.com/atom/electron/commit/83ae9f8d71007944b9f9e5b631740ea7a416e1b9#diff-f61b360ad8984d98baba4d962bf4d259R70

which means bitshares changed where it saved it's data.

Introduction:

BitShares 2 separates responsibilities and incentives activities that are beneficial to the network, thus acknowledging different skill sets and interested community members to have incentives to contribute in the most appropriate way.

• Witnesses are paid for maintaining the back-bone of the network.
• Committee members are unpaid volunteers that organize the community and propose changes to the network.
• Marketers are paid in referral fees.
• Workers are paid for whatever they propose and do.

Each of the above (except Marketers) requires users to vote for the people, proposals, and/or changes. Those with sufficient approval will be compensated.

Workers are the "catch all" group where if you have an idea for something that could improve the network, you can get "paid" by the network to do it. Organizing meet-ups, developing a new tool or feature for the community, and maintaining websites and infrastructure (e.g. the mumble server team or linux distribution) are all examples of things workers may do.

---

How to Create a Worker

Workers are currently created with the cli_wallet with the following command syntax
create_worker owner_account work_begin_date work_end_date daily_pay name url worker_settings broadcastexample, awesomebitsharer is creating a one day worker starting Oct 28 and will get paid 1 BTS/day (vesting in 1 day) to make an android app. The first command won't broadcast, this will just check:
create_worker "awesomebitsharer" "2015-10-28T00:00:00" "2015-10-29T00:00:00" 100000 "BitShares Android App Development" "http://bitsharesandroid.org/worker_proposal.html" {"type" : "vesting", "pay_vesting_period_days" : 1}Notes:
the url should point to something describing your proposal: what will you do, by when, and for how much?
for the worker properties you can choose:
"type" can be "refund" (return your pay back to the pool to be used for future projects), "vesting" (pay that you pay yourself), or "burn" (destroys your pay thus reducing share supply, equivalent to share buy-back of a company stock)
"pay_vesting_period_days" is the integer number of days you set for vesting. Some people don't want workers to withdraw and sell large sums of BTS immediately, as it puts sell pressure on BTS. Also, if you require vesting, you have "skin in the game" and thus an incentive to improve BTS value.
Pay is pay per day (not hour or maintenance period) and is in units of 1/100000 BTS (the precision of BTS)

To generate a worker proposal, add the word "true" to the end of the command as in:
create_worker "awesomebitsharer" "2015-10-28T00:00:00" "2015-10-29T00:00:00" 100000 "BitShares Android App Development" "http://bitsharesandroid.org/worker_proposal.html" {"type" : "vesting", "pay_vesting_period_days" : 1} true

---

How to see proposals on the chain

Since there is no support in the UI yet, go to http://cryptofresh.com/ and look at the worker proposal chart.
You also can inspect all the objects 1.4.* (e.g. "get_object 1.4.0")
unlocked >>> get_object 1.14.4
get_object 1.14.4
[{
    "id": "1.14.4",
    "worker_account": "1.2.22517",
    "work_begin_date": "2015-10-21T11:00:00",
    "work_end_date": "2015-11-21T11:00:00",
    "daily_pay": 1000000000,
    "worker": [
      1,{
        "balance": "1.13.235"
      }
    ],
    "vote_for": "2:73",
    "vote_against": "2:74",
    "total_votes_for": "14632377015617",
    "total_votes_against": 0,
    "name": "bitasset-fund-pool",
    "url": "https://bitsharestalk.org/index.php/topic,19317.0.html"
  }
]

---

How to Vote for a Worker

Currently the GUI doesn't have an interface, but you an vote using the CLI:
update_worker_votes your-account {"vote_for":["proposal-id"]} truefor example:
update_worker_votes "awesomebitsharer" {"vote_for":["1.4.0"]} trueyou can also vote against or abstain (remove your vote for or against)
update_worker_votes your-account {"vote_against":["proposal-id"]} true
update_worker_votes your-account {"vote_abstain":["proposal-id"]} true

---

How Workers Get Paid

Every hour the worker budget is processed and workers are paid in full order of the number of votes for minus the number of votes against. The last worker to get paid will be paid with whatever is left, so may receive partial payment. The daily budget can be estimated by inspecting the most recent budget object 2.13.*
for example:
new >>> get_object 2.13.361
get_object 2.13.361
[{
    "id": "2.13.361",
    "time": "2015-10-28T15:00:00",
    "record": {
      "time_since_last_budget": 3600,
      "from_initial_reserve": "106736452914941",
      "from_accumulated_fees": 15824269,
      "from_unused_witness_budget": 2250000,
      "requested_witness_budget": 180000000,
      "total_budget": 1520913100,
      "witness_budget": 180000000,
      "worker_budget": 1340913100,
      "leftover_worker_funds": 0,
      "supply_delta": 1502838831
    }
  }
]

So the daily budget is worker_budget*24=1340913100*24=32181914400 (in units of 1/100000 BTS, or 321,8191.44 BTS). There is currently a maximum daily worker pay of 500k BTS, and this can be found using the "get_global_properties" command in the cli_wallet

Here are the full details
Every second, [ 17/(2^32) * reserve fund ] is allocated for witnesses and workers. The reserve fund is maximum number of BTS available less those currently in circulation. This is defined in:
https://github.com/cryptonomex/graphene/blob/f85dec1c23f6bf9259ad9f15311b2e4aac4f9d44/libraries/chain/include/graphene/chain/config.hpp

Every hour the total available reserve fund is calculated by finding how many BTS are available to be distributed and how many BTS will be returned to the reserve fund (i.e., "refunded") during the next maintenance interval.

First find how many BTS have not been distributed:
from_initial_reserve = max_supply - current supply of BTS
from:
max_supply: get_object 1.3.0
current_supply: get_object 2.3.0


then modify it by adding the accumulated fees and witness budget remaining (i.e., 1.5 BTS per block is budgeted, so budget remaining is 1.5 BTS * (number of blocks left in maintenance period+blocks missed by witnesses))  in this maintenance cycle (they will be added to the "reserve fund" permanently at maintenance)

updated reserve fund = from_initial_reserve +  from_accumulated_fees + from_unused_witness_budgetvariables all from: get_object 2.13.* (choose the most recent one, for example)

Next calculate how much is available to be spent on workers and witnesses is:

total_budget = (updated reserve fund)*(time_since_last_budget)*17/(2^32)
rounded up to the nearest integer

Ok, now to find how much workers will get in this budget period (1 hour), you find the smaller of the available pay AFTER subtracting witness budget from the total_budget OR the worker_budget_per_day/24 from "get_global_properties"

worker_budget=min(total_budget-witness_budget,worker_budget_per_day/24)

That is how much per hour allocated for all workers. NOW you rank each worker and pay them one hours worth of pay in order or # votes.

---

To VOTE:
update_worker_votes ACCOUNTNAME {"vote_for":["1.14.6"]} true

As of now, no linux binaries of bitshares are available. This will fix that!

This worker will provide repositories for Debian based distributions for BitShares. Debian and Ubuntu are ready on both amd64 and i386. The worker will also implement Mint and extend to ARM processors (Raspberry Pi).

Preview and Installation Instructions:
http://162.243.185.205/
http://162.243.185.205/repos

Raspberry Pi Preview:
https://people.debian.org/~showard/raspbian/


They will be "official" since they are funded by the blockchain with voter approval.

What it does: Pulls from git every hour and checks for a new tag. If a new tag is present, new packages are built. Packages are gpg signed, md5sums are included in release files and signed. The Debian apt tool verifies md5sums and gpg key after download and before installation. Ubuntu packages are hosted and built on Canonical's Launchpad Service (ppa:bitshares/bitshares). Debian packages are built and hosted on the worker's VPS.

Qualifications: maqifrnswa is a Debian developer, has maintained a bitshares PPA for 1.5 years, was a delegate and a witness. maqifrnswa is the founder of the debian bitcoin team and is the maintainer of bitcoin in Debian and Ubuntu.

Internals/Security/Trust: The static pages will be SSL secured reduce chance of prevent man-in-the-middle attack. apt-get transport will follow standard distribution practices (over http). The package list, md5sums, and package info are GPG signed and will be verified automatically by apt's internal mechanisms. Sources are available for inspection via the "apt-get source" command and via the online repository.

Witness: maqifrnswa is currently running a witness. If this proposal is approved, maqifrnswa will serve as witness if needed by the network. If witness numbers should be reduced, maqifrnswa volunteers to be voted out.

Timeline: Prototype site already up and running for testing. Production-level site announced and running for Ubuntu and Debian by December. Mint and Raspbian/ARM by 2016 or early 2016. Future work to investigate: Automatically generate rpm from .deb packages and Ubuntu Snappy packages (container based Ubuntu packages).

Worker proposal costs:
$15/day (~3966 BTS)
New worker proposal every 3 months to adjust for price.
Breakdown:

• Servers: $80 monthly for front-end and back-end servers.
• Domain name: $15 one time
• SSL cert: free (startssl, just to prevent man-in-the-middle attack on the info page)
• Development time: $50/hour based on jobs at freelancer.com
• 10 hours: server set-up development of build scripts (done)
• 1 hour/week maintenance (new versions/bug fixing)
• New distributions and architectures are not included yet. They will add as development time based on actual time spent in future months

Daily expenses over 90 days:
[80*3+15+(10+1*12)*50]/90 = $15.05/day
Rounded down to $15/day

create_worker maqifrnswa "2015-10-28T00:00:00" "2016-01-31T00:00:00" 396600000 "Debian/Ubuntu-based PPA" "https://bitsharestalk.org/index.php/topic,19485.msg250031.html" {"type" : "vesting", "pay_vesting_period_days" : 0} true
get_object 1.14.6
[{
    "id": "1.14.6",
    "worker_account": "1.2.6004",
    "work_begin_date": "2015-10-28T00:00:00",
    "work_end_date": "2016-01-31T00:00:00",
    "daily_pay": 396600000,
    "worker": [
      1,{
        "balance": "1.13.279"
      }
    ],
    "vote_for": "2:80",
    "vote_against": "2:81",
    "total_votes_for": 0,
    "total_votes_against": 0,
    "name": "Debian/Ubuntu-based PPA",
    "url": "https://bitsharestalk.org/index.php/topic,19485.msg250031.html"
  }
]

This is somethig i've been trying to get to the bottom of since BTA2.0 was announced...
How do you price a short?

The system allows for automatic destruction of BTA when there is an oversupply, but I thought there was no mechanism to cause the creation of BTA when there was on under supply. However, the SWAN event essentially wipes out the market based on external feeds and thus is the mechanism for "creating" bitassets (then instantly destroying them) when in a massive under-supply.

Therefore, pricing bitassets is becoming a little clearer. The system enforces:
SWAN < bitUSD/BTS  < USD_FEED
A/USD_FEED < bitUSD/BTS < USD_FEED
where A is the least collateralize debt/collateral ratio (in units of bitUSD/BTS). We can assume A is essentially a constant. A can change, but the rate it will change is relatively slow as it requires a significant number of people to up their collateral.

So there are two prices, with a very large spread:
1) If I think USD_FEED should go down (that is BTS value increasing), I want to short at USD_FEED so I make a profit no matter what (or at worst, break even).

2) If I think USD_FEED will increase (BTS value decrease), I want to buy bitA at as close to SWAN as I can, as I will make a profit no matter what (or at worst, break even).

Therefore, as long as BTS is increasing in value (i.e., making a profit), I will want to short as close to USD_FEED as I can get. That is the mechanism that enforces the peg.

The only participants in such a market are those that all agree that BTS value will increase, but disagree over the rate and/or premium that should be paid.

Conversely, if market participants all expect a black swan, price will drop to black swan levels and market participants will play the game of chicken with the price feed. Since that is a one shot event that destroys the market, and value of BTS, the only participant will be those that also shorted BTS on an external exchange.

BTS profit (and expected future profit) is essential to the peg in BTS2.0 to 1) enforce the peg, and 2) grow the number of users participating in the market.

apt-add-repository ppa:showard314/bitshares
apt-get update
Light wallet:
apt-get install bitshares2
bitshares2
witness_node and cli_wallet are in:
apt-get install bitshares2-ui

you'll get a warning:
[28190:1013/173829:ERROR:browser_main_loop.cc(189)] Running without the SUID sandbox! See https://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment for more information on developing with the sandbox on.
something to fix as rollout continues

https://bitsharesblocks.com/asset/orderbook?asset=USD

with the run up of price, we ran out of forced margin calls at feed+10%.

Hi - I can''t create an account at:
https://playtalk.org/index.php?action=register2
It keeps telling me:
"You did not answer the verification questions correctly."
no matter what I try.

I just wanted to let people know I put up a package at:
https://launchpad.net/~dacplay+archive/ubuntu/ppa
apt-add-repository ppa:dacplay/ppa
apt-get update
apt-get install cpp-play
let me know what you think - both the CLI and gui are in the same package for now
I honestly don't know much about PLAY and haven't used it yet so I'd appreciate the extra set of eyes