[...] updated votes is:

1.14.181   Poll - BSIP59 - Reduce MSSR of bitCNY to 1.01            592,218,889
1.14.144   Poll-BSIP41-Reduce MSSR of bitCNY from 1.1 to 1.05   429,791,729   
1.14.168   Poll - BSIP59 - Reduce MSSR of bitCNY to 1.02 .          421,620,749   
1.14.169   Poll - BSIP59 - Do Not Reduce MSSR of bitCNY .           239,878,984

I feel 1.14.169 does not apply to the current question regarding reduce to 1.01 from 1.02, rather it was set regarding the previous reduction to 1.02 from 1.05 and therefore should not be considered at this time.  Further, there should have been a "Do Not Reduce MSSR of bitCNY from 1.02" when 1.14.181 was created to match the previous for/against voting set to allow voters to explicitly state their intentions on the single question.

Currently the 21 block producers are split 11/10 (1.02/1.01) on their feeds. The block producers are able to definitively resolve the outcome of the vote due to lack of clarity in the available Polls. 

I suggest to create a new set of polls:
1. Reduce MSSR of bitCNY from 1.02 to 1.01
2. Do Not Reduce MSSR of bitCNY from 1.02 to 1.01

I feel there is no short term harm to the market to remain on 1.02 at this time. This value represents the most recent vote which provided both for and against movement.

We decided to leave the fixed operation fees as BTS to allow the Committee to adjust the variable component fee per day or fee per kilobyte in USD terms. They can also be converted to USD fees. The recommendation is the fixed component in nominal.

TO: BitShares Committee
FROM: BitShares Core Team
REFERENCE: https://github.com/bitshares/bitshares-core/issues/1694
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:

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

max_preimage_size
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:

htlc_create_operation::fee
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.

htlc_create_operation::fee_per_day
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.

htlc_redeem_operation::fee
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.

htlc_redeem_operation::fee_per_kb
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.

htlc_extend_operation::fee
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.

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

[1] https://github.com/bitshares/bsips/blob/master/bsip-0044.md

Besides SmartCoin and UIA ,we need UnionToken.

ebit you raise a very interesting topic here. I am keen to discuss it further. However, respectfully, I feel we should discuss it within a new forum post specific to UnionTokens. If one already exists, please provide the URL and we can discuss further there. Else, I suggest you open a new topic (and post the URL here). As mentioned above, 瞳沈 (Tong Shen) is working with the Core Team to better connect with the Chinese Community and he will help us with translating and advancing the conversation further.

Thank you,
Fox

BitShares Core Team Budget Worker Proposal - 2019

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

Intent

* 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

Background

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.

Worker

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 "workers.bitshares.foundation" 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.

This is a welcome addition to the BitShares ecosystem. Very grateful for the efforts of the Magic Wallet Team to develop and produce this hardware device. Integration with the Reference Wallet will great.

- 1.1 Gather data from external APIs of CEX
  - Support publishing open source tools/process to collect data from CEX
  - Support collection of public data to be published as an open source dataset (may not meet EULA/TOS of provider(s))
  - See [Bitshares-Core/1350](https://github.com/bitshares/bitshares-core/issues/1350): NVT Data Collection and Visualization
- 1.2 Data visualization
  - Support the concept.
  - Provided already by [Kibana](https://www.elastic.co/products/kibana) today (visualization tool for Elasticsearch)
- 2 Multi-dimensional query and data export from DEX
  - Support.
  - Provided already by Elasticsearch
  - See [Bitshares-Core/1350](https://github.com/bitshares/bitshares-core/issues/1350): NVT Data Collection and Visualization
- 3 Data backup service
  - Support the concept. Have open questions about the implementation:
    - How does this differ from a seed node?
    - If not seed node How can service provider attest data authenticity (trust required)
    - Opinion: Best if block producers snapshot, attest and post to bitshares.org (caveat: loose history data)
- 4 Address identification and classification
  - Concerned this may lead to censorship
- 5 Analysis of Witnesses (feeds, nodes, etc.)
  - Support the concept

Suggestions for Other:
  - Replace focus on Postgresql Plugin in favor of ZeroMQ implementation
  - Focus on building out APIs and wrappers (using Elasticsearch) that UI Team can build from
  - DevOp tools for node operators (seed, api, block producers)

I look forward to iterating on a proposal that advances development and adoption of the BitShares platform.

Best,
Fox