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

Pages: [1] 2
The following BitShares Improvement Proposals (BSIP) are ready for Community voting as announced by the BitShares Blockchain Foundation. Please review these proposals (they all come with a short summary) and make a decision on each of them if you support that particular change. A few of them have a Chinese language interpretation of the proposed changes denoted with (CN).

BSIP 73 (CN): Match force-settlement orders with margin calls and limit orders
BSIP 72 (CN): Tanks and Taps: A General Solution for Smart Contract Asset Handling
BSIP 70 (CN): Peer-to-Peer Leveraged Trading
BSIP 69: Additional Assert Predicates
BSIP 64 (CN): Optional HTLC preimage length, HASH160 addition, and memo field
BSIP 62: Close margin position
BSIP 61: Operation to Update Limit Orders
BSIP 57: Managed Vesting Balances
BSIP 47: Vote Proxies for Different Referendum Categories and explicit voting operation
BSIP 45: Add BitAsset as Backing Collateral flag/permission
BSIP 39: Automatically approve proposals by the proposer
BSIP 22: Vote Decay for Witnesses, Committee members & Proxies

The BSIP Review Team advances completed drafts to the Community for voting. Many additional BSIPs are currently in review. Please participate in their discussion within the BSIP GitHub Repository.

General Discussion / BitShares Online Summit - 10 OCT 2019
« on: September 25, 2019, 09:00:46 pm »

BitShares Online Summit
10 OCT 2019

Being the nature of a decentralized community, consensus building is an important component toward moving our BitShares project forward. Lacking effective communication, voices within our community cannot be heard, their ideas cannot be shared, and the overall project cannot be improved efficiently. This is your opportunity to participate in a meaningful discussion about the future of BitShares.

The BitShares Online Summit intends to leverage the collective knowledge within our diverse, decentralized BitShares community into a live unified online conversation. The summit will focus on topics related to Workers, Project Vision and Marketing of the BitShares project. The format will consist of presentations and Q&A (questions and answers), with open discussion facilitated by English-Chinese Live Interpretation Services to enhance real-time communication. All contributors and community members are welcome to join the discussions regarding issues, opportunities and solutions for growing a sustainable BitShares project.

The 2019 BitShares Online Summit is hosted by the BitShares Core Team, with event organization and coordination provided by Spark Blockchain Incubator.

What Makes This Summit Different
Sharing Insights
An online summit is an ideal venue for community members, committee members, workers, block producers, proxies and anyone contributing to BitShares growth to share their ideas. It is also an opportunity to question these ideas and seek to clarify information. We welcome all to participate using the conference tools provided.

Communication Among Participants
The conference will provide a direct channel for presenters to share their ideas and facilitate raising questions and soliciting feedback from the live audience. The audience will have 5-10 min to raise questions for each presenter following the 4-7 minute presentation.

Voices Without Borders
The Conference will be accessible anywhere you can connect to the Internet. In order to achieve good communication between the Chinese Community and the English Community, simultaneous interpretation will be provided throughout the conference. It will help translate the ideas and thoughts for our global community.

How to Attend / RSVP
In order to attend the conference, please RSVP with this form:

If you intend to present at the conference, please also complete the following form, indicating what topic area you intend to present, and provide a brief description of your content:

Date and Location
The summit will be held online using a video conferencing software platform. Registered attendees will receive their personalized URL and login credentials upon registration. The summit will begin promptly at Noon / 12:00 PM(UTC) on October 10th, 2019. The local time for various time zones is provided below for your information.

Asia / Shanghai  (China Standard Time / UTC+8):
8:00 PM - Midnight, Thursday, October 10th, 2019

Europe / Paris (Central European Summer Time / UTC+2)
2:00 PM - 6:00 PM, Thursday, October 10th, 2019

North America / New York (Eastern Daylight Time / UTC-4):
8:00 AM - Noon, Thursday, October 10th, 2019

Time Zone Base: UTC

12:00 PM - 1:30 PM     Workers Presentation
Workers present their current working progress and plans for future efforts.
4 min for each presentation and 9 min for Q&A from attendees.

10 min Break

1:40 PM - 2:50 PM      Project Vision Session
Speakers discuss their vision and future direction for the BitShares project.
Topics include but not limited to:
  • Easy Access to BitShares
  • Decentralized Finance Application
  • Lending and Collateral Mechanism
  • Cross-Chain Transfer
6 min for each presentation and 8 min for Q&A from attendees.

   10 min Break

3:00 AM - 4:00 PM       Marketing Session
Evaluate our past marketing efforts. Discuss how we may structure our market research and marketing efforts for the future.
5 min for each presentation and 10 min for Q&A from attendees.

Host: BitShares Core Team
BitShares Core Team is responsible for the maintenance and development of the core protocol and oversight of the BitShares Improvement Proposals (BSIP) process. The core team liaises with the UI and Mobile Teams, and other community lead efforts maintained within the BitShares Organization on GitHub. The Core Team actively attend and speak at relevant international conferences, hackathons and events.

Conference Organizer: Spark Blockchain Incubator
Spark Blockchain is a leading blockchain consulting and incubation service provider in North America. Headquartered in Boston, it radiates its influence through NY, LA, SF and the Bay Area, China, ASEAN, etc. Since its establishment, it has quickly established a leading position in North America's blockchain community and has established great cooperative relations with top-tier projects and investment funds in China, and the United States. The current clients of Spark Blockchain include not only select top 100 blockchain projects, but also DApps, quantitative teams, media, and blockchain investment funds.


作为去中心化社区,建立共识是推动我们的BitShares项目向前发展的重要方式。 如果缺乏有效的沟通,我们社区内的建议将无法被听到,想法无法被分享,整个项目也无法得到提高。 此次峰会是所有社区成员参与有关BitShares未来发展讨论的机会。

BitShares线上峰会旨在使我们去中心化社区中的各种想法能够通过实时的在线对话被分享、讨论。 峰会将重点讨论与Worker,项目愿景和BitShares项目营销相关的话题。 形式将包括演讲和问答,并通过英汉实时翻译进行公开讨论,以增强实时交流。 欢迎所有社区成员参加有关BitShares项目可持续性发展的讨论。


在线峰会是社区成员,委员会成员,worker,见证人,投票代理以及任何为BitShares增长做出贡献的人分享想法的理想场所。 这也是一个对各种想法提出疑问并寻求答案的平台。 我们欢迎所有人参加会议。

会议为演讲者提供分享他们的想法的平台,并征询现场观众的反馈。 在4-7分钟的演讲之后,听众将有5-10分钟的时间向每个演讲者提问。

您可以在任何可以连接到互联网的地方参与会议。 为了在中文社区和英语社区之间实现良好的沟通,会议期间将提供同声传译。 这将有助于全球社区内的想法的交流。


峰会将在视频会议软件平台上举行。 注册的参加者将在注册后收到个性化URL和登录凭证。 峰会将于2019年10月10日中午/12:00 PM(UTC)开始。下面提供了各个时区的当地时间,以供参考。

亚洲/上海(中国标准时间/ UTC + 8):
8:00 PM - 12:00AM 2019年10月10日,星期四

欧洲/巴黎(中欧夏令时/ UTC + 2)
2:00 PM - 6:00 PM 2019年10月10日,星期四

北美/纽约(美国东部夏令时间/ UTC-4):
8:00 AM - 12:00 PM 2019年10月10日,星期四


下午12:00-下午1:30   Worker汇报

10 分钟休息

下午1:40-下午2:50   项目愿景
  • 更加便捷的访问BitShares
  • 去中心化金融应用
  • 贷款与抵押
  • 跨链转账

10 分钟休息

下午3:00 - 下午4:00 市场营销

BitShares核心团队负责维护和开发核心协议,并监督BitShares改进提案(BSIP)的流程。 核心团队与UI团队、移动团队和社区领导者保持密切联系,共同维护GitHub的BitShares Organization的运行。 核心团队积极参加各类相关的国际会议,黑客马拉松和活动并在其中发言。

「星火区块链」以开发者关系为核心,成为北美领先的区块链咨询及孵化公司。总部位于波士顿,辐射纽约、洛杉矶、旧金山及湾区,中国,以及东盟等。2018 年 3 月成立至今,依托咨询与孵化业务,迅速在北美的区块链行业圈内站稳头部位置,与中美顶级的项目以及投资基金建立良好合作关系。「星火区块链」目前的客户不仅包括前 100 名知名公链,还包括 DApp、量化团队、区块链服务提供商、媒体、区块链投资基金等,促进了中国与美国区块链圈的多层次和多维度的交流发展。

Stakeholder Proposals / Core Team Worker Funding Status
« on: June 27, 2019, 01:37:51 pm »
I am pleased to announce that the Core Team Worker has fully funded its 2019 budget in bitCNY value due to the increased valuation of the BTS token. I am reaching out to proxies and community members to suspend their votes for this WP to allow other valuable initiatives to receive funding. The Core Team will continue its development efforts from the accumulated budget holdings in escrow with the BitShares Blockchain Foundation (should BTS valuation drop I may request lifting the vote suspension to fund the original intent).

Ryan R. Fox
Development Coordinator

General Discussion / Core Team Recommendations for HTLC Parameters
« on: April 03, 2019, 02:05:23 pm »
TO: BitShares Committee
FROM: BitShares Core Team
RE: Core Team Recommendations for HTLC Parameters

This post is intended to be an open letter from the Core Team to the Committee to provide recommendations and explanations for consideration when setting the required values to activate HTLC functionality included in the BitShares 3.0.0 Protocol Upgrade Release on 23 APR 2019. Implementation of BSIP44 introduces the following Committee-controlled chain parameters and fees [1]. The Core Team intentionally left the fees and parameters blank in the code.  Only the Committee may set (and modify as needed) these protocol parameters. The Core Team offers recommendations denominated in USD, allowing the Committee to convert to BTS using their established process.

Chain Parameters for HTLC:

This is the maximum time the HTLC my live before the funds revert to the sender. In Bitcoin, this can be any time in the future. For BitShares, we recommend 2592000 seconds (30 Days).

While active, these contracts remain in RAM. Allowing an indefinite lifetime to the contract somewhat defeats the purpose of an HTLC and unnecessarily uses a valuable system resource. It is believed that most HTLCs will live around 6 hours. It is believed that 30 days will easily cover most known use cases.

If the contract is redeemed by providing the preimage, the contract is no longer in RAM. However, the preimage is stored in the blockchain. This parameter limits the size of the preimage that can be used to redeem an HTLC.

It is believed that the vast majority of preimages will be 256 bytes or 512 bytes which provide sufficient entropy for security. We recommend 10kb initially.

Note: Higher per-kilobyte fees should help mitigate the use of large preimages. Preimage size is a tiered calculation where bytes 1-1024 are included in the minimum fee of 1 kilobyte and a preimage of 1025 bytes would calculate in the second tier of 2 kilobytes.

Fees for HTLC:

Creating an HTLC has two component fees: a fixed fee to execute the operation and a variable daily fee to store the contract in RAM. Our recommendation is to keep the total cost of a single day HTLC near the cost to execute the transfer operation.

We recommend setting this fee to  $0.001 USD (a tenth of a cent) as the fixed component and using the fee_per_day below to equate to near the transfer operation fee for a single day HTLC.

These contracts sit in RAM until they are redeemed by either party. Memory is a limited resource, and should be considered when setting fees for HTLC. It is envisioned that the typical HTLC will be less than 1 day and thus pay the minimum cost of one fee_per_day. To encourage adoption of this technology we feel $1 USD/month to hold open an HTLC is sufficient. We recommend $0.033 USD per day.

The redeem operation also has a pair of related fees: operation fee and fee_per_kilobyte. Similarly, we recommend these fees be nominal for the fixed component and quite large for the variable component, as this requires permanent storage space within the blockchain to retain the preimage.

We recommend setting this fee to $0.001 USD (a tenth of a cent) as the fixed component and using the fee_per_kb below to encourage appropriate use of the blockchain resources.

The preimage size is known up-front, so a redeemer can calculate their total cost of redemption before the preimage is known. Hence, if redemption cost is a deciding factor as to whether to perform the transaction, the total cost can be calculated.

We expect most HTLC transactions can be secured with a preimage well under 1kb, the current minimum fee tier. 512 bits or even 256 bits provide adequate entropy. If large preimages are desired, a large fee will be charged.  We recommend $0.10 USD as the initial fee per kilobyte.

This operation allows the HTLC to be extended to up to the maximum_timeout_seconds defined above. Allowing indefinite length contracts. It is recommended to match the fixed creation fee defined above.

Similarly, we recommend to match the create fee_per_day defined above.


Stakeholder Proposals / [Worker Proposal] Core Team 2019
« on: January 31, 2019, 09:00:04 pm »
BitShares Core Team Budget Worker Proposal - 2019

* Author: Ryan R. Fox ("fox")
* Complete Document: Steemit Post.
* 国语翻译 Mandarin Translation: TBD ("TBD")
* Accounting: Provided by BBF


* Provide sustainable protocol development funding for the BitShares Core Team
* Operate as a multidisciplinary collaborative team to benefit the BitShares decentralized autonomous community (DAC)
* Engage the community, regulators and public as the authoritative source for protocol development and information


This budget proposal represents a follow on to the efforts established and executed by the
BitShares Core Team in 2018. It seeks to continue funding the development efforts related to the core protocol and expand its scope within the DAC to deliver greater outreach throughout 2019. The Core Team is responsible to our DAC to transparently deliver a secure protocol, collaborate on research, prioritize innovative features, and engage our Community and the public toward increased protocol adoption.


This is a _Budget Worker Proposal_ which funds the following effort areas through calendar year 2019:
* BitShares Core Development
* Collaboration Tools
* Conference Participation and Community Engagement

This Worker funds a not to exceed budget for ideation, collaboration, development and defense of the ideas, engagements and implementations required to advance the BitShares Project. Individuals supported by funds from the budget occupy a defined set of Core Team Roles at specific rate valuations detailed in _Table 2._ below.

BTS are collected into the "" account which is a multi-sig account controlled by "BitShares Blockchain Foundation" and owned by "committee-account" using the Budget Worker Model which provide:

* Transparent accounting provided by the BitShares Blockchain Foundation
* Invoice review, approval and remittance within 5 business days
* Compensation remitted in a viable SmartCoin (i.e. bitCNY)
* All accumulated and unallocated BTS returned to the Reserve Pool at the conclusion of the Worker

As the team size scales or BTS token valuations fluctuate, subsequent Worker(s) will be offered to fully fund the Intent.

Core Team Scope

The primary focus of the Core Team remains maintenance and development of the core protocol and oversight of the BitShares Improvement Proposals (BSIP) process. The Core Team will continue to liaise with the BitShares UI Team, and other community lead efforts maintained within the BitShares Organization on GitHub. The Core Team continues to guide Community Contributors toward promotion into open Core Team Roles through the Community Claims program detailed below.

Collaboration tools will continue to include software tools and server infrastructure to support development and testing efforts. The bitshares-core GitHub repository remains the primary source for our planning, discussion and deliveries. The Core Team participates with the UI Team and BitShares Committee to manage access within the BitShares Organization on GitHub.

Attendance and speaking engagements at relevant international conferences, hackathons and events remain an important component of the Core Team's dedication to community outreach. We gather for in-person meetings prior to each conference and hold remote planning meetings throughout the year.

Expanded Core Team scope for 2019 will include:
* Participation in one (1) additional international conference
* Multilingual information gathering and dissemination (English and Mandarin)
* Designate the Development Spokesperson(s) for public engagements

Core Team Member Introductions

Abit More - Core Developer
I have contributed to the BitShares code base for many years [4].

Alfredo Garcia - Core Developer
Started Bitshares contributions into the core more than 2 years ago, initially funded by my own worker proposal[5]. Activity was always maintenance, development, testing, discussion and review around the bitshares-core source code[6]. I also provide support to the community and build utility tools to increase the adoption of Bitshares technology[7]. In the second half of 2018 i joined the core team and had been working there since then.

Peter Conrad - Core Developer
I am a knowledgeable and long-standing member of the BitShares community (@pc) and an active developer for many years [8-9].

John Jones - Core Developer
I have been a professional software developer since 1991, and a "hacker" before then. Most of my work experience has been in finance/investments/insurance. I have been contributing to the BitShares codebase since the beginning of 2018. [10-12].

Ryan R. Fox - Coordinator, Business Analyst, QA/Tester
I have actively contributed to BitShares development from its inception [13-16]. I have extensive professional background in project management with software development teams and am a professional scrum master (PSM-1) with multi-national experience in financial services, mortgage banking and manufacturing.

Dr. Christopher J. Sanborn, PhD - Junior Developer
I have more than a decade of experience in scientific computing and developing software for physical simulations, and more than two decades in software development generally [17].  I have been passionate about crypto since 2013, and have been contributing to the BitShares ecosystem since 2017.  I have a particular interest in improving privacy preservation within blockchain technologies.

Michel Santos - Senior Business Analyst
Trained as an aerospace engineer with extensive experience in modeling and simulating the dynamics and control of different types of vehicles.  Background in analyzing business processes and finding ways to improve them.  Has assisted firms with identifying how to use blockchain technologies as one option in their toolchest [18].

沈瞳 Tong Shen - Coordinator Assistant
I have over 10 years of experience in development of web apps, mobile apps, API servers, data processing apps, smart contracts, and have served various roles as SDE, Project Manager, Product Manager, IT Consultant, Agile Coach and CTO [19-21]. As Cofounder & CTO of Spark Blockchain and Liaoyuan, I've built a strong connection with the blockchain and startup ecosystem through our blockchain & startup summits and meetups in United States and China [22].

杉本 T. Sugimoto - Documentation Specialist, QA/Tester
I have created and revised documentation for BitShares over the past two years [23]. I hold a Masters in MIS and have held professional titles including Systems Analyst & Programmer, Web Designer and Database Administrator. I have experience using Content Management Systems to re-organize multiple websites. I am proficient analyzing system code in many programming languages and have created many web applications and websites.

田蒙蒙 Linda Tian - Coordinator Assistant
I was fully engaged in the planning and organization of China Graphene Blockchain DevCon in January and Global Graphene Blockchain DevCon in May, 2018 [24]. I have organized a series of activities like translation, meetups, live events about BitShares. Now I work as Secretary General of Graphene Blockchain Application Center(GBAC) [25], and regularly communicate with Graphene projects including BitShares community in China. In short, I have extensive professional background in community operation [26].

You may read the entire document on this Steemit Post.

General Discussion / BitShares Core Release 2.0.181105
« on: November 05, 2018, 07:28:03 pm »
BitShares Core Release 2.0.181105

Please read the Steemit post for proper links:

Get the software here:

The BitShares Core software has been updated to the 181105 Feature Release. The Core software is used by validation nodes which perform consensus of all transactions on the BitShares blockchain. This release includes new features, optimizations, and bug fixes but does not include any changes to the consensus protocol.

No action is required if you do not operate a validation node or the command line interface (CLI) wallet.

Numerous performance improvements have been made to the software that will benefit all operators of validation nodes including block producers, seed nodes, and API nodes, especially those using the Elasticsearch plugin.

Documentation for BitShares developers may be now be found at the new BitShares Developer Portal (

Who Should Upgrade?
No upgrade is required by any operator of a validation node. Yet many operators will benefit by upgrading.

All operators will benefit from performance improvements (915, 1327, 1359) and fixes (1024, 1203, 1286, 1325).
Operators of block producing nodes will benefit from performance improvements (1251), safety measures (1252), and fixes (1266, 1332, 1364).
Operators of API nodes including Elasticsearch APIs will benefit from improvements to data availability (1351, 1352) and performance (1049, 1271, 1356).
Users of the command line interface (CLI) wallet will also benefit from improvements (1195, 1248).
Upgrade Process
Precaution 1
Operators of API nodes that service client software that expect to receive updates about all data on the blockchain by default (such as BitShares Reference Wallet before 180401), as opposed to narrowly subscribed data, should ensure that their API nodes are configured with the enable-subscribe-to-all set to true due to Pull Request 1049.

How to Upgrade from Source Code
Obtain the Source Code
The source code may be obtained by checking out the 2.0.181105 tag
Download the source at:
Build the Binaries
The binaries may be built by using your pre-existing process, or by following the standard instructions that can be found in the wiki:

Windows Development Environment
Deploy the Binaries
Your standard process for deploying the node software may be used. No additional requirements or precautions will be required to deploy the new release.

How to Upgrade with Docker
The latest Docker image may be found at BitShares Core Docker page and updated with

docker pull bitshares/bitshares-core
CLI Binaries for Windows and Mac
A binary of the command line interface (CLI) wallet for Windows is pre-built and available for download here

For Mac please download BitShares-Core-2.0.181105-macOS-cli-tools.tar.gz.

The changes for BitShares Core for the 201810 Feature Release are summarized below.

Core Functionality
Description   Issue   Pull Request
Change call_order_update_operation to return order_id   1269   1352
Node Functionality
Description   Issue   Pull Request
Segmentation fault when running several witness nodes on the same machine   377   1286
Performance opt pt 1   1079   1359
Log console output during replay to file   985   1355, FC-76
Change replay percentage to total block size processed   1289   1335
Improve block generation performance   -   1251
Review and backport EOS patch about unsigned_int unpacking   993   1267
Check and port Steem PR 2692: missing FC typenames   1217   1248
witness_node uses two incompatible parsers for config.ini   149   1024,1325
db_block.cpp: removed unreachable code   -   1312
Cleanup budget_record_object?   1139   1213
Change object_id to more than 32 bit   1088   1267
More 32 bit to 64 bit changes   1206   1347, 1374
Remove definition of unused symbol_type   -   1235
Update application.cpp   -   1345
application.cpp: minor optimization   -   1327
Call order and bitAsset related code refactory   -   1306
Re-add enable-subscribe-notify-all option after GUI issue fixed   752   1049
When signing a block that updates the signing witness's signing key, use correct signing key   125   1203
remove unused variable _consecutive_production_enabled   -   1294
Check Steem issue 2658: Not producing block because node didn't wake up within 500ms of the slot time   1157   1266
remove verify_account_history_plugin_index()   -   915
inconsistent error message for update_asset_issuer   944   1255
Possible to generate a block that is too large   1136   1252
remove duplicated line in network code node.cpp   -   1231
Error while converting value to string   1392   1394,FC-83
Update Sahkan's seed nodes   -   1404
Node Plugins
Description   Issue   Pull Request
Terminate block production loop when shutting down witness plugin   1314   1332, 1364
add dascoin adaptor   -   1356,1396
[ES plugin] Wrong value of additional_data.fill_data.fill_order   1295   1351
refine es_objects plugin      1271
Command Line Interface (CLI)
Description   Issue   Pull Request
CLI wallet: avoid directly overwriting wallet file on exit   1109   1195
cli_wallet crashes when doing import_key on Mac   1244   1248
get to_id from to_account instead of get_account_id()   -   1242
wallet compatibility issue   1307   1323
Build Process
Description   Issue   Pull Request
Integrating cURL into cmake   -   1329, 1336
cli_test doesn't compile on Windows due to using 'sys/socket.h'   1292   1305
clean old style codes   -   1250
Unit Tests
Description   Issue   Pull Request
Not able to perform testing [100,000 transactions per second]   1298   1337
Refactor cli_test   1192   1243
Test case failed on chain_test   1326   1346
Description   Issue   Pull Request
API documentation   780   1174
Launch BitShares Developer Portal   1031   How-19, Dev-41
add new doc portals to readme   953   1358,1363
add readme to plugins   -   1319
LaTeX project for documentation like C++ ISO/IEC   1288   -
Probably wrong comment   1301   1349
Create plugin script   -   1302
add new doc portals to readme      1363
Add disk space requirements to readme   -   1376,1379
Update get_trade_history API docs and coding style   -   1397
Release Contributors
Damir from Dascoin

General Discussion / BitShares TESTNET Feature Release 2.0.20180803
« on: August 04, 2018, 11:36:45 am »

This is a Feature Release for the TESTNET only. Active block producers are encouraged to upgrade at this time. The testing period will continue thru 14:00 UTC 21 AUG 2018 after which time the Core Team will begin finalizing a release for the mainnet.

Download and build the [test-2.0.180803]( tag from GitHub.

Preliminary Release Notes:

### Assets

- BitShares-Core-2.0.1808-macOS-cli-tools.tar.gz
- Source code (zip)
- Source code (tar.gz)

## Security fixes
- CLI wallet: updated choice of range proof params in cli wallet reveals transaction magnitude to very narrow range for Blinded Transfers (issue #480 / PR #1117 #1227)

## API changes
- Removed crypto_api from default list of allowed APIs. (issue #1123 / PR #1125)
- Changed default `max-ops-per-account` value to 100, impacts account history (#1120)
- Added `get_account_limit_orders` database API to query for open orders of one account in one market #463 #849 #1163
- Added `get_asset_count` API to return total number of available assets #688, #1159
- Added `get_transaction_hex_without_sig` API get serialized transaction hex without `signatures` field (issue #1013 / PR #1038)
- Added support for account name as parameter for all API calls #969 #989 #1164 #1168 #1152 #1155
- Added `fail_reason` field to proposal object #730, #1036
- Retroactively deducted witness `missed_blocks` caused by chain halts #1087

## New features and improvements
- Added Openssl 1.1 and Ubuntu 18.04 support (issue #835 / PR #559 #921 #1008
  - Fixed invalid use of incomplete type `BIGNUM {aka struct bignum_st}` #327
- Added `witness_node` startup option `--enable-standby-votes-tracking` to track votes of standby witnesses and committee members #987, #1191, #1211
- Added `cli_wallet` startup option `--suggest-brain-key` to generate keys without connecting to a witness_node #1011, #1039
- Added `quit` command to `cli_wallet` #1104, #1050
- Improved witness_node performance for generating blocks, resyncing and replaying
  - Improved account maintenance (vote tally) performance (issue #803/ PR #1085)
  - Improved performance of `database::update_expired_feeds()` and global object getters #1093 #1180
  - Slightly improved price comparison performance #1094 #1124
  - Added index on `short_backing_asset`, better performance for updating asset (Issue #960 / PR #1019)

### Docker File
- Changed default docker p2p port to 1776, fixed p2p port to match Dockerfile #1226, #1078
- Fixes to make Docker containers shutdown gracefully #1077 #1115
- Fixed Docker Cloud Build Failing Due to Compile Time #1221 #1222
- Modified Dockerfile to work with new docker cloud version (0.10.1) #1075
- Updated testnet Branch to Include Latest Dockerfile #1074

### Elasticsearch
- Elasticsearch refactor #1103 #1201
  - Add auth to communicate with the ES database with `--elasticsearch-basic-auth` startup option.
  - Custom index names with `--elasticsearch-index-prefix` startup option.
  - Removed `--elasticsearch-logs` startup option
  - Better error handling: if there is an error when sending data to ElasticSearch, plugin will stop processing blocks and keep trying, and it resumes when connection is back at the same place. #681
  - add operation_id_num for easier filtering.
  - Fill orders data in additional for easy volume.
  - Test cases framework. #1047
  - Make full use of common functions in the 2 plugins(utilities).
  - flush ES database on every block when node is in sync to improve real time user experience. #1137
- Updated documentation

## Bugfixes
- Fixed CLI `get_account_history` pagination issue (duplicate ops when `limit` great than 100) #1176, #1177, #1179
- Fixed `cli_wallet` crashes for macOS 10.13.5 #1127
- Fixed "log file of current hour gets overwritten by default" #809
- Fixed 2 minor bugs in snapshot plugin #1185
- Fixed object database exception handling when built with Boost 1.66 (#852 #1126 #1161)
- Enable `boost::stacktrace` correctly

## Other changes
- Integrated SonarCloud into travis build (issue #836 / PR #1081
- Added `USE_PROFILER` option to Cmake to enable profiling #1119
- Added `OPENSSL_CONF_SOURCE` variable for building in Windows
- Added cli_tests to Travis-CI #1156
- Added `asset_api_tests` #1202
- Added new seed node by bangzi #1130 #1138
- Changed default `core_exchange_rate` quote asset in order to create asset more easily #1132
- Updated node.cpp, check attacker/buggy client before updating items ids #1007
- Optimized `find()` call in P2P code #1090, #1091
- Refactored `get_impacted_account_visitor`, removed duplicate code from impacted.cpp #845 #1073
- Refactored `cancel_all_subscriptions` for better performance and consistency #762 #1009
- Changed `push_proposal exception` log level to warn #1146
- Cleaned up Balance evaluator code #1150
- Cleaned up `get_named_account_balances` code #1154 , #1135
- Cleaned up logging in account.cpp #1010
- Cleanup up a visitor struct in static_variant.hpp
- Removed obsolete constants (issue #1034 / PR #1072)
- Removed unused "smaz" compression #986
- Remove fc bz2 unused linkage
- Removed double assert in `object_id_type` constructor #1128
- Removed protocol.hpp #1197, #1200
- Backported EOS PR 3560 replace assert in FC::crypto #992
- Backported EOS PR 3240 HTTP performance improvement, added move-semantic-version `set_body` function #999
- Updated test case for `time_point_sec::to_iso_string`, detect boost version #597
- Fixed Performance sucks at first block after a long sequence of missed blocks #1086 #1087
  - witness `missed_blocks` count no longer increases due to chain halt (retroactive change)
- Fixed cli_tests websocket port binding #1178 #1187
- Fixed RPC logging level inconsistency #929
- Fixed wallet in-code docs, suppressed compiler warnings  #1015 #1181 #1129 #1199 #1190
- Updated `asset_object::amount_to_string` implementation for slightly better performance #1012
- Updated system requirements into Documents #1107 #1108
- Updated document #1121, #1166, #1212

## Contributors in this release:

- @pmconrad
- @abitmore
- @oxarbitrage
- @jmjatlanta
- @cogutvalera / @nanomobile
- @cifer-lee
- @ryanRfox
- @nathanhourt
- @christophersanborn
- @xeroc
- @xiangxn
- @RichardWeiYang
- @Zapata
- @cwyyprog
- @Tydus

## SHA256 Checksum   

BitShares Core Team Budget Worker Proposal - 2018 (1.14.99)

* Author: Ryan R. Fox (`"fox"`)
* [国语翻译]( Mandarin Translation: 招木 (`"Zhaomu"`)
* Article published on Steem blockchain
* Worker published by BitShares Blockchain Foundation 201803-bitshares-core (1.14.99)


* Establish a budget to sustain the development efforts of the BitShares Core Team
* Define a framework for the Core Team to collaborate within
* Provide transparent delivery of BitShares development efforts to the community


BitShares Core software is currently maintained by individuals either volunteering their time or
receiving funding through distinct short-term worker proposals. The BitShares Community has
recognized the need for organized development efforts to increase the utility of our platform.
There is a large backlog of ideas and requirements lacking prioritization, including feature
enhancements, bug fixes, and BSIPs. Therefore, proposed is the establishment of a long-term,
professional, global team dedicated to cohesive and comprehensive development efforts delivered


This is a Budget Worker Proposal which provides partial funding through calendar year 2018 for:
* BitShares Core Team Roles
* Collaboration Tools
* Development Initiatives

This Worker funds an _initial_ Core Team at reduced hours to mitigate draw on the reserve pool
and support bootstrapping efforts. Subsequent Worker(s) will be offered to fund the team as it
scales up. This Worker intends to work in concert with the existing development resources including
Abit, Alfredo Garcia, and the UI Team, led by Bill Butler.

BTS are collected into the `""` account which is a multi-sig account
controlled by `"BitShares Blockchain Foundation"` and owned by `"committee-account"` using the
Budget Worker Model [5]:

* Transparent accounting provided by the BitShares Blockchain Foundation [6]
* Submitted invoices reviewed, approved and remitted within 5 business days
* Compensation paid in bitUSD (according to the rules set forth in [5])
* All unused accumulated BTS returned to the Reserve Pool at the conclusion of the Worker [5]

_Initial_ BitShares Core Team

The initial Core Team is comprised of community members who have demonstrated their ability to work
with Graphene-based code, contribute to this community with thoughtful leadership and share a
dedication to the BitShares ethos. Initially, the team is a skeleton, with many contributing to
multiple roles and at reduced weekly hours as represented in _Table 1_ Each team member is focused
on returning more value to the BitShares platform than is drawn from the reserve pool.

The initial team is estimating 54 hours of weekly effort. This Worker proposes to budget $15,000
for a team delivering approximately 100 hours weekly to support conservative growth. Demonstrated
results will warrant subsequent Worker(s) to budget for additional team members and weekly hours.

Table 1. Initial BitShares Core Team

| Roles (described below)           | Rate Range (Hourly USD) | Team Members    | Estimated Hours   |
|:--------------------------------- | -----------------------:|:--------------- |:----------------- |
| Core Developer                    |                    $150 | Peter Conrad    | 10 hours weekly   |
| Core Developer                    |                    $150 | Abit            | 5 hours weekly*   |
| Core Developer                    |                    $150 | Alfredo Garcia  | 2 hours weekly*   |
| Junior Core Developer, BA         |                    $125 | Taconator       | 10 hours weekly   |
| Business Analyst, Coordinator, QA |                    $125 | Ryan R. Fox     | 15 hours weekly   |
| Lead Documentation Specialist, QA |                    $ 90 | Tamami Sugimoto | 10 hours weekly   |
| UI/UX Liaison                     |                    $125 | Bill Butler     | 2 hours weekly    |
| Core Developers                   |             $125 - $200 | -open-          | -                 |
| Business Analysts                 |             $ 75 - $125 | -open-          | -                 |
| Documentation Specialists         |             $ 60 - $ 90 | -open-          | -                 |
| QA/Testers                        |             $ 75 - $125 | -open-          | -                 |
| TOTALS INITIAL CORE TEAM      |             $ 90 - $150 | -all-           | 54 hours weekly** |
| $6,825 WEEKLY (EST.)          |                         |                 |                   |
| -                                 |                         |                 |                   |
| BUDGET FOR THIS WORKER        |                         |                 |                   |
| $15,000                       |                         |                 | ≈100 hours weekly |

_*Abit and Alfredo intend to complete their existing Workers. Their contributions as part of the
Core Team will initially be at the reduced hours above, then expected to increase similar to their
existing Worker.
**Additional hours for all roles remain available at this time. Please contact
[email protected] for additional information._

BitShares Core Team

The BitShares Core Team is a self-organizing agile-principled team focused on delivering regularly
scheduled releases and ad hoc bug fixes for the BitShares Core software. The actual number of
contributors and roles may vary within each development cycle (described below), leading to
variations in weekly compensation per contributor. The team has discretion in allocating resources
to meet the needs of each development cycle.

Producing reliable and secure software at scale requires ideation, organization, definition,
prioritization, development, testing and documentation. The ideal team composition includes roles
specializing in each of these functions and capable of contributing to many. The goal of a highly
functioning team is to fully utilize each individual's effort and together maximize their
collective output.

Development Cycles*
  * Feature Release (non-hard fork):
    * Three-week sprints
  * Core Release (Hard Fork):
    * Twice annually: first Thursday of June & December

_*Subject to change upon consensus of Core Team Members_

A typical Feature Release will likely span three weeks from planning thru tested and delivered
software, called a sprint. Many agile principals will be adopted by the Core Team, but do not
expect a strict scrum practice. This is a global team, so a formal daily standup is unlikely. One
should expect asynchronous communication within various collaboration tools keeping the team
informed of progress, plans and problems. The community are our stakeholders; we look to them for
ideas, enhancements and identifying bugs, then organize these into a backlog for future
development. The Coordinator facilitates the prioritization of the backlog items based on feedback
from the stakeholders and the Core Team. The team will keep the stakeholders informed of
development progress throughout the sprint.

At the beginning of a sprint cycle the Core Team meets to review the prioritized backlog and
identify the highest value items that each can contribute to, within the established time block.
Many features have dependencies and cannot be implemented within a single sprint. Therefore, the
team will create tasks, a subset of the feature, that can be delivered on time. A task may be
researching and defining requirements to be implemented later. A task may be writing a test case,
or perhaps implementing only a subset of a given requirement, or even documenting how existing code
functions. The team will maintain a sprint backlog comprised of the tasks selected from the project
backlog. Completing each of these tasks results in incremental value added to the project. Testing
is performed throughout the sprint to ensure functioning code from each increment.

As the sprint nears completion, the Core Team will begin release planning. They will select which
tested increments are ready to be included in a release candidate. This will be deployed to a
staging network for final validation. A release will be tagged within the bitshares-core GitHub
repo along with release notes. The team also produce stakeholder documentation detailing resource
allocations and budget consumption.

The final steps of the sprint include a retrospective look at how the team performed. Here we
reflect on our original estimates, the delivered increments and what contributed to our successes
and shortcomings. We will use insights gained from the retrospective to improve in the next sprint.
The following day we immediately begin our next sprint cycle.

Bounty Process (Implicit Budget)

The BitShares Core Team maintain a prioritized project backlog of ideas, enhancements, bugs and
BSIPs which they select from for their development sprint. The community is encouraged to comment
on the items to aid in refining requirements and guide prioritization. Effort estimates are first
assigned to the highest value backlog items. Unassigned and estimated project backlog items are
available for ad hoc _bounty_ development. Successfully completing ad hoc bounty items is a primary
consideration for an invitation to join the Core Team on a future sprint.

The Core Team encourages ad hoc code contributions of estimated project backlog items from
community members and will compensate successfully merged code based on those estimates. The
Coordinator will facilitate onboarding new community contributors to _claim_ a backlog item and
implement a solution that fits within the broader architecture design defined by the Lead
Developer. Care must be taken to ensure effort is not duplicated and can easily be merged within a
future sprint. Claimed items that become a dependency of a sprint may be recalled by the Core Team
to facilitate feature delivery. Compensation for a partially completed increment will be evaluated
by the Lead Developer.

Compensation for a successfully merged _bounty_ item is drawn from the excess _implicit_ budget
capacity within _Table 1_ when any Core Team Role is not fully allocated. The specifics for the
bounty process is still being revised (note: it is largely based on the process in use by the UI

BitShares Core Team Framework:

* Maintain timely collaborative communications with each BitShares Core Team Member
* Participate in at least two of three weekly Collaboration Sessions (see Coordinator description)
* Target a majority of your weekly hours between Tuesday - Thursday
  * Facilitates ad hoc collaboration
  * Facilitates healthy work/life balance

* Maintain working increments within Community facing collaboration tools
* Maintain timely updates within Community facing collaboration tools of work in progress and development priorities

* Deliver the highest value work first
* Favor release schedule over feature completeness (see Development Cycles)

BitShares Core Team Member 'Contract Work' Guidance:

This section is to be considered guidance, not a legal statement. The BitShares
Decentralized Autonomous Community (BitShares DAC) controls the funds collected
by this Budget Worker and are issued as compensation to individuals performing
agreed work as described elsewhere in this document. Effort contributed by
individuals is considered by personal commitment as no formal employment
contract is intended or able to be formed between BitShares DAC and the
individual worker. Neither the BitShares Blockchain Foundation (BBF) nor the
BitShares Committee or any individual serving those entities are to be
considered employers of any agreed contribution. No BitShares Core Team Member
or Role is considered the manager or the employer of any individual person. Any
compensation received from the BitShares DAC might be considered earned income
for individual persons involved in their individual situation and may be
subject to tax reporting by the recipient. Neither BitShares DAC, nor the
BitShares Blockchain Foundation, nor BitShares Committee, nor the Coordinator,
or any Core Team Member will neither carry responsibility, nor command, nor
issue, nor prepare any document, including tax documents, to any entity or
natural person. All effort performed is a contribution to the BitShares DAC
adhering to its MIT license.

Each Core Team Member is encouraged to contribute in a responsible way with
respect to a work/life balance and legal employee engagements he or she might
have entered into, or enter, with an employer.

Table 2. Core Team Roles and Rates

| Roles (described below)         | Hourly Rate (USD) |
|:------------------------------- | -----------------:|
| Lead Core Developer             |              $200 |
| Senior Core Developer           |              $175 |
| Core Developer                  |              $150 |
| Junior Core Developer           |              $125 |
| Lead Business Analyst           |              $125 |
| Senior Business Analyst         |              $100 |
| Junior Business Analyst         |               $75 |
| Lead QA/Tester                  |              $125 |
| Senior QA/Tester                |              $100 |
| Junior QA/Tester                |               $75 |
| Lead Documentation Specialist   |               $90 |
| Senior Documentation Specialist |               $75 |
| Junior Documentation Specialist |               $60 |
| UI/UX Liaison                   |              $125 |
| Coordinator                     |              $150 |

Core Developer

The Core Developer is a seasoned C++ developer primarily tasked with writing and documenting the
source code. Secondarily, the Core Developer is tasked with refining user stories, requirements
and process models prior to development as well as resolving bugs during testing.

Core Developer Key Performance Indicators
* Collaborate with Business Analyst to refine user stories, requirements and process models
* Collaborate with QA/Tester on bug identification and resolution
* Collaborate with the Documentation Specialist to review documentation and ensure it matches
the source code intent and implementation
* Maintain code repositories within GitHub using GitFlow principles [7]
* Contribute to Code Review of peers and provide approval for Release
* Document code for the benefit of future development efforts

Business Analyst

The Business Analyst is a key role in a highly functioning team. They review the prioritized list
of enhancements and refine them into requirements prior to the Developer beginning their design.
Creating requirements documents often include user stories which narrate how the end user and/or
system behaves. Process models are another tool for conveying the requirements in a visual flow
diagram. Attention to detail and the ability to research and document are desired characteristics
During development the Developer will often collaborate with the Business Analyst to clarify and
refine requirements to ensure the implementation meets the desired behavior. The Business Analyst
will assist the QA/Tester with writing test cases as well as executing and documenting results
thereof. The Business Analyst will review and refine documentation produced by the Documentation
Specialist to ensure it accurately reflects the requirements.

Business Analyst Key Performance Indicators
* Maintain user stories, requirements and process models
* Collaborate with Core Developers to refine user stories, requirements and process models
* Collaborate with Documentation Specialist to revise developer documentation matches the intent
of the user stories, requirements and process models.

Documentation Specialist

The Documentation Specialist is technical writer able to interpret test cases, user stories,
requirements, process models and C++ source code. Primarily the Documentation Specialist will
write documentation for the development community on the GitHub Wiki and
website. Secondarily, the Documentation Specialist will work with Core Developers to revise
developer documentation based on the intent of the user stories, requirements and process models
to ensure they match the intent and function of the source code.

Documentation Specialist Key Performance Indicators
* Collaborate with the development community to ensure documentation supports their efforts
* Collaborate with the Core Developers to review documentation and ensure it matches the source
code intent and implementation
* Collaborate with the QA/Tester and Business Analyst to enhance documentation including user
stories, requirements, process models and test cases


The QA/Tester is primarily tasked with writing test cases based on user stories, requirements and
process models, then executing the tests and documenting the results. Secondarily, the QA/Tester is
tasked with revising developer documentation with the Documentation Specialist.

QA/Tester Key Performance Indicators
* Maintain test cases within Aha!
* Collaborate with Core Developers to identify and document bugs in GitHub
* Collaborate with Documentation Specialist to revise developer documentation, ensuring it matches
the intended workflow

UI/UX Liaison

The UI/UX Liaison is the primary point of contact for planning, prioritizing, defining and testing
UI/UX elements impacted by the implementation of the Core software. The UI Team function
independently of the Core Team, but their combined efforts are interdependent. Therefore, the UI/UX
Liaison is integral to delivering our feature rich Core platform.

UI/UX Liaison Key Performance Indicators
* Maintain Feature Requests related to UI/UX
* Collaborate with Business Analyst and Core Developers to refine user stories, requirements and
process models


The Coordinator is an experienced agile project manager or scrum master with deep knowledge of
distributed ledger technology. Primarily, the Coordinator is tasked with general facilitation,
organization and prioritization of development efforts.

Coordinator Key Performance Indicators
* Maintain transparent communications with BitShares Community
* Maintain transparent communications with BitShares UI Project Manager
* Maintain transparent communications with Chinese Spokesperson
* Maintain transparent communications with BitShares Spokesperson
* Maintain prioritized backlog of issues/feature requests
* Maintain project roadmap
* Facilitate release cycles
  * Facilitate communication to centralized exchanges listing BitShares tokens
* Maintain physical presence for BitShares within co-working space
* Maintain a pool of candidates to select from to fulfill open roles
  * Contingency: If both a backlog of effort and an empty candidate pool for an open role exist,
  the accumulated budget funds may be allocated to a recruitment effort to fill the open role
* Onboard and mentor Core Team Members
* Facilitate standing collaboration sessions (Thrice weekly 2-hour blocks dispersed for
international participation)
  * 02:00 - 04:00 UTC Tuesday
  * 19:00 - 21:00 UTC Wednesday
  * 11:00 - 13:00 UTC Thursday
* Approve invoices submitted by Core Team Members, forward to BitShares Blockchain Foundation
for remittance
* Maintain vendor relationships for collaboration tools
* Facilitate Developer Conference attendance

Initial Core Team Member Introductions

Abit - Core Developer

Draft: I have contributed to the BitShares code base for many years [11].

Alfredo Garcia - Core Developer

I recently began my second 6-month Worker as a BitShares Core Developer [12]. Mainly I focus on the
bitshares-core software by implementing features, fixing bugs, testing, maintenance, etc. [13]. I
also develop outside the core tools for other developers and final applications for the BitShares
community. [14]

Bill Butler - UX/UI Liaison

I lead the BitShares UI team and have extensive industry experience: Founded an ISP in 1993,
NodeJS, Angular, PHP, CouchDB, SQL. UX/UI Experience [16]. I am currently VP Engineering for a
healthcare software development firm and have eight years’ experience managing development teams.

Peter Conrad - Core Developer

I am a knowledgeable and long-standing member of the BitShares community (@pc) and an active
developer for many years [9-10].

Ryan R. Fox - Coordinator, Business Analyst, QA/Tester

I have actively contributed to BitShares development from its inception [1-4]. I have extensive
professional background in project management with software development teams and am a professional
scrum master (PSM-1) with multi-national experience in financial services, mortgage banking and

Taconator - Core Developer, Business Analyst

I began participating in the BitShares Hangout in early 2017 after submitting a patch and
associated unit tests related to the recurring withdrawals capability that already existed in
BitShares Core [8]. I also began publishing monthly reports on the fees collected by the BitShares
blockchain in April 2017. I have experience within various industries identifying problems of
non-technical end-users, designing technical products for solving those problems, and leading teams
to successfully build those technical products. (Just because one might have a "hammer" does not
mean that every problem is a "nail".) These solutions span from augmented reality applications on
mobile devices to global distributed software systems.

Tamami Sugimoto - Documentation Specialist, QA/Tester

I have created and revised documentation for BitShares over the past year [15]. I hold a Masters in
MIS and have held professional titles including Systems Analyst & Programmer, Web Designer and
Database Administrator. I have experience using Content Management Systems to re-organize multiple
websites. I am proficient analyzing system code in many programming languages and have created many
web applications and websites.

Collaboration Tools

The BitShares Core Team use various collaboration tools to organize their work, convey ideas and
aid development efforts. Transparency of development efforts to the community is a key requirement.
Tools selected by the team generally provide read/reviewer access for the community to observe
progress, track our time and provide feedback. Write/contributor access may be limited to a
specific Core Team role(s). License quantities and types will vary monthly, therefore $2,000 is
budgeted for tools. A non-exhaustive list is provided in _Table 3_ below.

Table 3. Collaboration Tools (Monthly)

| Description                      | Amount (USD) |
|:---------------------------------| ------------:|
| Software Tools                   |       $2,000 |
| --Code Repository                |           -- |
| --Continuous Integration         |           -- |
| --Continuous Code Quality        |           -- |
| --Product Roadmap                |           -- |
| --Process Models                 |           -- |
| --Time Tracking/Auditing         |           -- |
| --Infrastructure Environment     |           -- |
| Escrow and Remittance (BBF)      |       $3,000 |

Select Core Team will meet prior to each of the scheduled DevCon events for team building,
in person collaboration and presentation preparation. The Core Team will participate in conference
events in constructive ways. A budget for Conference participation is provided in _Table 4_ below.

Table 4. Conference Budget (One-Time)

| Description                          | Accommodations | Amount (USD) |
|:------------------------------------ |:-------------- | ------------:|
| DevCon Spring 2018 - Shanghai, China |                |              |
|   Travel round trip (up to $2000)    | 5 FTE          |      $10,000 |
|   Lodging (up to $150)               | 5 nights       |       $3,750 |
|   Meals (up to $60)                  | 5 days         |       $1,500 |
| DevCon Autumn 2018 - TBD, Europe     |                |              |
|   Travel round trip (up to $2000)    | 5 FTE          |      $10,000 |
|   Lodging (up to $200)               | 5 nights       |       $5,000 |
|   Meals (up to $80)                  | 5 days         |       $2,000 |
| TOTAL TOOLS BUDGET (ONE-TIME)   |                |  $32,250 |

Development Initiatives

The Initial Core Team has identified in _Chart 1_ a set of Initiatives to research, define and
develop as part of their 2018 Roadmap. A detailed Roadmap will be a deliverable of this Worker for
Community review. An 'Ideas Portal' will also be maintained to incorporate Community priorities
into the Roadmap.

Caveat: The Core Team cannot commit to deliver fully implemented solutions for all identified
Initiatives. The intent here is to provide guidance at the outset, realizing the Core Team
continuously evaluates and prioritizes new issues ongoing.

* Interchain Communication
  * Atomic Cross Chain Transactions (ACCT)
  * EOS.IO Integration Report
  * Trustless Gateway
* Market Mechanics
  * Market Engine Improvements
  * Maker/Taker Model
  * Bancor Protocol
* Consensus & witness_node Enhancements
  * Database Storage Options
  * Installation scripts / environments
* Confidential Transactions / Confidential Assets
* Hardware Wallet Integrations
* API & cli_wallet Enhancements
* Community Engagement
  * Vote Decay
  * Fee Schedule based on Market Pegged Assets
* Refine/Prioritize Existing BSIPs

Chart 1. Initiatives - 2018

![BitShares Core Initiatives - 2018]( "BitShares Core Initiatives - 2018")


The items listed in the tables below represent an **upper bound** on expenditures. All funds
collected and unused at the conclusion of this Worker Proposal will be returned to the Reserve
Pool [5-6].

Table 5. Core Team Budget

| Description                             | Amount (USD) | Daily     | TOTAL BUDGET |
|:--------------------------------------- | ------------:| ---------:| ------------:|
| Total Core Team Roles (Table 1)         |      $15,000 |           |              |
| ++ Convert to daily (/7 days)           |              |    $2,143 |              |
| Total Collaboration Tools (Table 3)     |       $5,000 |           |              |
| ++ Convert to daily (/30 days)          |              |      $167 |              |
| Total Conference Budget (Table 4)       |      $32,250 |           |              |
| ++ Convert to daily (/44 weeks /7 days) |              |      $106 |              |
| ≈≈ TOTAL DAILY BUDGET ITEMS             |              |    $2,416 |              |
| **≈≈ ≈≈ TOTAL 44 WEEK BUDGET**          |              |           | **$744,128** |

Duration and Pay

This proposal will last for roughly 44 weeks, starting from 1st March 2018.

* Invoices from Core Team Members will be submitted to the Coordinator by Monday 12:00 UTC for work
performed thru Sunday 23:59 UTC of the previous period
* Coordinator will review and approve submitted time sheets, then forward an invoice to BitShares
Blockchain Foundation for release of funds from escrow to `"bitsharesdev"` account for remittance to
* Coordinator will review and approve vendor invoices, then forward to BitShares Blockchain
Foundation for direct payment to vendor

* 3.9761 BTS/bitUSD = Settlement price of bitUSD at the moment of writing (2018-02-16)
* 2.5 = Collateral multiplier to cover market fluctuations and borrow with 2.5x collateral, as needed
* $2,416 USD/day * 3.9761 BTS/USD * 2.5 collateral multiplier ≈24,016 BTS/day

USD payment will be in bitUSD with method developed by the BitShares Blockchain Foundation [5].


* [1] [BitShares Talk Profile](;u=5333), Ryan R. Fox
* [2] [GitHub Repository](, Ryan R. Fox
* [3] [LinkedIn Profile](, Ryan R. Fox
* [4] [Twitter Profile](, Ryan R. Fox
* [5] [Budget Worker Template](, BitShares Blockchain Foundation
* [6] [Transparent Accounting](, BitShares Blockchain Foundation
* [7] [GitFlow](, BitShares
* [8] [GitHub Repository](, Taconator
* [9] [Professional Background](, Peter Conrad
* [10] [Implementation of BSIP-18](, Peter Conrad
* [11] [Core Dev Worker](, Abit
* [12] [Core Dev Worker](, Alfredo Garcia

[Edits: update URLs to published locations]

General Discussion / Request - Wallet API Access Using curl
« on: May 06, 2016, 04:06:34 am »
May I request some assistance with the syntax to access the wallet-api using curl (not wscat)? I have reviewed the the following documentation:

I am successful requesting get_dynamic_global_properties:
Code: [Select]
curl --data '{"jsonrpc": "2.0", "method": "call", "params": [0,"get_dynamic_global_properties",[]], "id": 2}'
But fail requesting for help:
Code: [Select]
curl --data '{"jsonrpc": "2.0", "method": "call", "params": [0,"help",[]], "id": 2}'
Thanks in advance for the assistance,

The BitShares on Ubuntu 15.10 template for Microsoft Azure Blockchain as a Service (BaaS) is now live:

You may search for BitShares at the Azure Quickstart Templates site:
# BitShares Blockchain Node on Ubuntu VM

This template delivers the BitShares network to your VM in about 15 mintues (PPA install).  Everything you need to get started using the BitShares blockchain from the command line is included.
You may select to build from source or install from the community provided Personal Package Archive (PPA).  Once installed, the 'witnes_node' will begin syncing the public blockchain.
You may then connect via SSH to the VM and launch the 'cli-wallet' to interface with the blockchain.

<a href="" target="_blank"><img src=""/></a>
<a href="" target="_blank"><img src=""/></a>

# What is BitShares?

BitShares is an industrial-grade financial blockchain smart contracts platform.  Built using the latest in
industry research, BitShares delivers a decentralized financial platform with speeds approaching NASDAQ.

# Template Parameters

When you click the Deploy to Azure icon above, you need to specify the following template parameters:

* `adminUsername`: This is the account for connecting to your BitShares host.
* `adminPassword`: This is your password for the host.  Azure requires passwords to have One upper case, one lower case, a special character, and a number.
* `dnsLabelPrefix`: This is used as both the VM name and DNS name of your public IP address.  Please ensure an unique name.
* `installMethod`: This tells Azure how to install the software bits.  The default is using the community provided PPA.  You may choose to install from source, but be advised this method takes substantially longer to complete.
* `vmSize`: This is the size of the VM to use.  Recommendations: Use the A series for PPA installs, and D series for installations from source.  Notice: Once the blockchain is synced, resize your VM to A1, as the BitShares witness_node requires a small resource footprint.

# Getting Started Tutorial

* Click the `Deploy to Azure` icon above
* Complete the template parameters, choose your resource group, accept the terms and click Create
* Wait about 15 minutes for the VM to spin up and install the bits
* Connect to the VM via SSH using the DNS name assigned to your Public IP
* Launch the cli-wallet: `sudo /usr/bin/cli_wallet --wallet-file=/usr/local/bitshares-2/programs/cli-wallet/wallet.json`
* Assign a secure password `>set_password use_a_secure_password_but_check_your_shoulder_as_it_will_be_displayed_on_screen`
* `ctrl-d` will save the wallet and exit the client
* View your wallet: `nano /usr/local/bitshares-2/programs/cli-wallet/wallet.json`
* Learn more: [](   

# Licensing

BitShares is offered under the MIT License as [documented here](

# More About BitShares

Please review [BitShares documentation]( to learn more.

Add: Azure Quickstart Templates
Fix: Spelling


The 'other' Open Ledger project making progress on their hardware solution.

BitShares 0.9.3 has been released:

This release will stop block production on October 13th at 9AM EST and adds new API calls for exporting the wallet for Graphene.   

If delegates do not wish to stop producing blocks at the stated date/time then they need not upgrade.   If you are a seed node then you do not need to upgrade. 

All delegates committed to transitioning from the existing BitShares network to BitShares 2.0 should upgrade their node(s) to 0.9.3, publish their version to the blockchain and be ready to produce 2.0 blocks using the Graphene codebase upon launch 13 OCT 2015. 

Stakeholders should watch each delegate's published versions (both active and stand by) and their statements below, then adjust their votes to support delegates that (will) produce blocks for the network they intend to follow after the announced hard fork time.  An updated list is visible at the bitsharesblocks website [1].

Stakeholders should take care to ensure their wallet client software and that of the third parties they may interface with also follow the chain of your choice after the hard fork.  These choices are yours to evaluate and act upon.  Decentralization welcomes you.


Technical Support / Understanding Graphene: Shared Secret Key
« on: September 02, 2015, 02:42:00 am »
Does the Graphene protocol make use of a shared secret key by the set of block producing witnesses in each round?  If yes, please describe the protocol for generating the shared secret key and what current and potential function(s) is served by its use.  References within the code are also appreciated.

Requesting assistance with building Graphene on Ubuntu 14.04LTS.  I have reviewed the Build Ubuntu documentation for Graphene [1] and taken care to verify Boost 1.57 is referenced within the CMake script.  However, the build fails within 'project_secp256k1' with the output:
Code: [Select]
[  6%] Performing autogen step for 'project_secp256k1'
/home/myUser/graphene/libraries/fc/vendor/secp256k1-zkp/ 3: /home/myUser/graphene/libraries/fc/vendor/secp256k1-zkp/ autoreconf: not found
make[2]: *** [libraries/fc/vendor/secp256k1-zkp/src/project_secp256k1-stamp/./project_secp256k1-autogen] Error 127
make[1]: *** [libraries/fc/CMakeFiles/project_secp256k1.dir/all] Error 2
make: *** [all] Error 2

I did review closed Issue #76 [2] which references this library and similar build issues.  Those changes were merged into Master three weeks back, so perhaps this is new, yet related.

For troubleshooting purposes I'll include:
  • My Graphene Build Script
  • CMake Output
  • Make Output

My Graphene Build Script
Code: [Select]
# Prep Server
sudo apt-get update
sudo apt-get -y install dphys-swapfile

# Install Prerequisite Packages
sudo apt-get -y install ntp cmake git libreadline-dev uuid-dev g++ libdb++-dev libdb-dev zip libssl-dev openssl build-essential python-dev autotools-dev libicu-dev libbz2-dev libboost-dev libboost-all-dev

# Install Boost 1.57
wget -c ''
tar -xf download
cd boost_1_57_0/
./ --prefix=/usr/local/
./b2 install

# Install Graphene
git clone
git submodule update --init --recursive
cmake -DBOOST_ROOT="/usr/local/" -DCMAKE_BUILD_TYPE=Debug .
make -j4

CMake Output
Code: [Select]
myHost:~/graphene$ sudo cmake -DBOOST_ROOT="/usr/local/" -DCMAKE_BUILD_TYPE=Debug .
-- Using custom FindBoost.cmake
-- Boost version: 1.57.0
-- Found the following Boost libraries:
--   thread
--   date_time
--   system
--   filesystem
--   program_options
--   signals
--   serialization
--   chrono
--   unit_test_framework
--   context
--   locale
-- Using custom FindBoost.cmake
-- Boost version: 1.57.0
-- Found the following Boost libraries:
--   coroutine
-- Configuring Graphene on Linux
-- Using  as BerkeleyDB root
-- Looking for: db_cxx-6.0
-- debug/usr/lib/x86_64-linux-gnu/libdb_cxx.sooptimized/usr/lib/x86_64-linux-gnu/
-- Configuring project fc located in: /home/myUser/graphene/libraries/fc
-- Configuring fc to build on Unix/Apple
-- Using custom FindBoost.cmake
-- Boost version: 1.57.0
-- Found the following Boost libraries:
--   thread
--   date_time
--   system
--   filesystem
--   program_options
--   signals
--   serialization
--   chrono
--   unit_test_framework
--   context
--   locale
--   iostreams
--   coroutine
** websocketpp

=========== Used Build Configuration =============

-- ENABLE_CPP11        = ON
-- BUILD_TESTS         = OFF

-- WEBSOCKETPP_ROOT    = /home/myUser/graphene/libraries/fc/vendor/websocketpp
-- WEBSOCKETPP_BIN     = /home/myUser/graphene/libraries/fc/vendor/websocketpp/bin
-- WEBSOCKETPP_LIB     = /home/myUser/graphene/libraries/fc/vendor/websocketpp/lib
-- Install prefix      = /usr/local


-- Could NOT find Curses (missing:  CURSES_LIBRARY CURSES_INCLUDE_PATH)
-- Finished fc module configuration...
-- Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/myUser/graphene

Make Output
Code: [Select]
myHost:~/graphene$ sudo make
[  0%] Building CXX object libraries/fc/vendor/udt4/CMakeFiles/udt.dir/src/api.cpp.o
[  1%] Building CXX object libraries/fc/vendor/udt4/CMakeFiles/udt.dir/src/buffer.cpp.o
[  1%] Building CXX object libraries/fc/vendor/udt4/CMakeFiles/udt.dir/src/cache.cpp.o
[  2%] Building CXX object libraries/fc/vendor/udt4/CMakeFiles/udt.dir/src/ccc.cpp.o
[  2%] Building CXX object libraries/fc/vendor/udt4/CMakeFiles/udt.dir/src/channel.cpp.o
[  3%] Building CXX object libraries/fc/vendor/udt4/CMakeFiles/udt.dir/src/common.cpp.o
[  3%] Building CXX object libraries/fc/vendor/udt4/CMakeFiles/udt.dir/src/core.cpp.o
[  4%] Building CXX object libraries/fc/vendor/udt4/CMakeFiles/udt.dir/src/epoll.cpp.o
[  4%] Building CXX object libraries/fc/vendor/udt4/CMakeFiles/udt.dir/src/list.cpp.o
[  5%] Building CXX object libraries/fc/vendor/udt4/CMakeFiles/udt.dir/src/md5.cpp.o
[  5%] Building CXX object libraries/fc/vendor/udt4/CMakeFiles/udt.dir/src/packet.cpp.o
[  6%] Building CXX object libraries/fc/vendor/udt4/CMakeFiles/udt.dir/src/queue.cpp.o
[  6%] Building CXX object libraries/fc/vendor/udt4/CMakeFiles/udt.dir/src/window.cpp.o
Linking CXX static library libudt_debug.a
[  6%] Built target udt
[  6%] Performing autogen step for 'project_secp256k1'
/home/myUser/graphene/libraries/fc/vendor/secp256k1-zkp/ 3: /home/myUser/graphene/libraries/fc/vendor/secp256k1-zkp/ autoreconf: not found
make[2]: *** [libraries/fc/vendor/secp256k1-zkp/src/project_secp256k1-stamp/./project_secp256k1-autogen] Error 127
make[1]: *** [libraries/fc/CMakeFiles/project_secp256k1.dir/all] Error 2
make: *** [all] Error 2

Any suggestion for troubleshooting is greatly appreciated.

Please help me understand what impacts, if any, the BitAsset 3.0 proposal has on existing User Issued Assets. 
  • What is the relation between BitAsset Market Issued Assets, User Issued Assets and BitAsset 3.0?
  • What are the potential risks to existing User Issued Assets (issuers and holders) when BitAsset 3.0 enters the market?

Pages: [1] 2