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

Pages: [1] 2 3
General Discussion / BTS/BTC settled at 200k?
« on: January 11, 2016, 04:55:56 pm »
I see a bunch of settle trades at 200k BTS/BTC (.000005 BTC/BTS) on 1/7 at 7:25:18 UTC

How did this happen? (i've been away)

settlement is about 150k now (4 days later)... did the price feed really go over 180k?

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
now is


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

import a backup
just cp your original
to the new location

More info:

Full Story:
The UI app is really just a lightweight chromium browser configured as a node module. The browser module is called "electron" ( The browser module itself changed where it saves its data:

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

I used:
Code: [Select]
create_account_with_brain_key "brian key" accountcreated registrar referrer true
my wallet has the memo and active private keys, but does not have the owner private key. Is this intended? I'd like to import that account in to another wallet, is this possible?

Stakeholder Proposals / Summary of How Workers Work in BitShares 2.0
« on: October 28, 2015, 06:46:40 pm »
BitShares 2.0 Worker Primer
This is a primer for those interested in being a worker or want to know what one is.


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
Code: [Select]
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:
Code: [Select]
create_worker "awesomebitsharer" "2015-10-28T00:00:00" "2015-10-29T00:00:00" 100000 "BitShares Android App Development" "" {"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:
Code: [Select]
create_worker "awesomebitsharer" "2015-10-28T00:00:00" "2015-10-29T00:00:00" 100000 "BitShares Android App Development" "" {"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 and look at the worker proposal chart.
You also can inspect all the objects 1.4.* (e.g. "get_object 1.4.0")
Code: [Select]
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": [
        "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": ",19317.0.html"

How to Vote for a Worker

Currently the GUI doesn't have an interface, but you an vote using the CLI:
Code: [Select]
update_worker_votes your-account {"vote_for":["proposal-id"]} truefor example:
Code: [Select]
update_worker_votes "awesomebitsharer" {"vote_for":["1.4.0"]} trueyou can also vote against or abstain (remove your vote for or against)
Code: [Select]
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:
Code: [Select]
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:

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:
Code: [Select]
from_initial_reserve = max_supply - current supply of BTS
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)

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

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

Code: [Select]

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.

Technical Support / Is the init0 worker proposal the correct value?
« on: October 27, 2015, 06:58:39 pm »
Code: [Select]
unlocked >>> get_global_properties
    "witness_pay_per_block": 150000,
    "worker_budget_per_day": "50000000000",
    "max_predicate_opcode": 1,


Code: [Select]
unlocked >>> get_object "1.14.0"
get_object "1.14.0"
    "id": "1.14.0",
    "worker_account": "1.2.90742",
    "work_begin_date": "2015-10-20T17:30:00",
    "work_end_date": "2035-12-31T00:00:00",
    "daily_pay": "40000000000",
    "worker": [
        "total_burned": "224425051538"
    "vote_for": "2:65",
    "vote_against": "2:66",
    "total_votes_for": "13948919251522",
    "total_votes_against": "3439671953344",
    "name": "refund400k",
    "url": ""

Is another 100k worker (or committee proposal) needed?
(of course, after voting for 1.14.6)  ;D

Worker Proposal for "Official" Debian and Ubuntu Binaries via PPA

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

Raspberry Pi Preview:

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

Code: [Select]
create_worker maqifrnswa "2015-10-28T00:00:00" "2016-01-31T00:00:00" 396600000 "Debian/Ubuntu-based PPA" ",19485.msg250031.html" {"type" : "vesting", "pay_vesting_period_days" : 0} true
Code: [Select]
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": [
        "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": ",19485.msg250031.html"

If I was to get a worker sponsored by the blockchain to set up a linux repo hosted on my own hardware, would it be possible to have a redirect from:
"" --> IP_ADDRESS?

I'm envisioning setting up the exact same thing as clang does, but for tagged bitshares releases:

Although I could get my own domain "" or something like that, I'm interested in the subdomain is because people unfamiliar with the worker system might feel that it isn't "official" if it isn't on something officially owned by bitshares developers. That could be seen as there is no "official" support for linux.

General Discussion / BitAsset2.0 pricing theory
« on: October 16, 2015, 03:13:52 pm »
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:
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.

Technical Support / How to get a cli_wallet file in to openledger?
« on: October 14, 2015, 04:42:13 pm »
I have 10s of thousands of keys, so I used the cli_wallet to import the keys. All balances and accounts show up correctly.

Now that the keys and balances are all imported, is it possible to import that wallet to openledger (or the light client)?

I used the "save_wallet_file" method in cli_wallet to output a wallet.json. When I try to import that file in to the light client I am told, "Invalid Format."

Is this the right want to do this?

Technical Support / Bitshares2 CLI and Light Wallet PPA (Ubuntu)
« on: October 13, 2015, 09:48:07 pm »
Code: [Select]
apt-add-repository ppa:showard314/bitshares
apt-get update

Light wallet:
Code: [Select]
apt-get install bitshares2

witness_node and cli_wallet are in:
Code: [Select]
apt-get install bitshares2-ui

you'll get a warning:
Code: [Select]
[28190:1013/] Running without the SUID sandbox! See for more information on developing with the sandbox on.
something to fix as rollout continues

Technical Support / Building the light wallet
« on: October 10, 2015, 06:04:53 pm »

I'm trying out the electron build on linux (ubuntu 14.10). How is cryptonomex generating the windows and mac builds?

When using the start script, an an empty electron window pops up and does nothing (just white on the inside frame, no web page loaded).

When I used the release script (release_linux.js), a .deb is created. When installed, it behaves the same way.
I don't want to take away from development, but if I could get a hint as to how it is supposed to be built I can look at getting out linux binaries.

The web wallet works fine, looks great. I don't see much of a benefit to a web gui package as it's just as easy for someone to "git clone" "npm install" and "npm start," but the light client would have a wider use-case interesting.


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

Hi - I've been maintaining an Ubuntu PPA for bitshares and am planning on doing a worker proposal for bitshares 2.0. I can take care of Debian-based distribution (Mint, Ubuntu, etc.) and infrastructure, but I think having a coherent and robust packaging for all distros would be best. If you're currently maintaining packages for a distro and want to join in my proposal, please PM me with your "packaging resume" and what you've done for bitshares so far.

Also, if you know Debian-based packaging, please let me know too since we'll need redundancy in case I get hit by the proverbial bus.

Docker experience, Ubuntu snappy experience (don't know if we want to go in that direction yet) could be useful, but you'll need to explain what you do.

I'm hoping for a small team (~4) of experienced linux packagers/distribution people. Ideally we can set up something like the open build service opensuse uses (

Why?: Why have one proposal rather than independent? People may recognize that linux packages are important, but may only vote for proposals for their distro of choice. I believe distro coverage is also very important, but proposals for specific distros may not get funded. If we team up we can get a larger community behind the proposal so more distros will be covered. Also, there will be some infrastructure required, sharing the workload and removing redundancy will be beneficial.

DAC PLAY / DAC Play PPA/Packages
« on: August 21, 2015, 10:44:10 pm »
Hi - I can''t create an account at:
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:
Code: [Select]
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

General Discussion / Graphene daily PPA
« on: August 19, 2015, 06:26:38 pm »
Graphene master built daily (05:30 UTC) for Ubuntu vivid and wily (15.04, 15.10)
Code: [Select]
sudo apt-add-repository ppa:showard314/ppa
sudo apt-get update
sudo apt-get install graphene

the commands "witness_node" and "cli_wallet" will be in your path

Pages: [1] 2 3