bitshares / bsips Goto Github PK

BitShares Improvement Proposals and Protocols. These technical documents describe the process of updating and improving the BitShares blockchain and technical ecosystem.

Home Page: https://bitshares.github.io

bitshares bitshares-improvement-proposal documentation blockchain

bsips's Introduction

BitShares Improvement Proposal

BSIP stands for BitShares Improvement Proposal. A BSIP is a design document providing information to the BitShares community, or describing a new feature for BitShares or its processes or environment. BSIPs provide a concise technical specification of features and a rationale for them.

The distinct document BSIP Purpose and Guidelines gives a more detailed explanation.

Available BSIPs

Number	Title	Owner	Type	Status
1	BSIP Purpose and Guidelines	Fabian Schuh	Informational	Draft
2	Refund Create Order Fees on Cancel	Daniel Larimer	Protocol	Superseded by 26
3	Maker / Taker Market Fees Flag	Daniel Larimer	Protocol	Obsoleted by 81
4	Distribute Market Fees on Core Asset to Referral Program	Daniel Larimer	Protocol	Obsoleted by 43
5	Expiring Votes for Witnesses	Daniel Larimer	Protocol	Superseded by 22
6	Market Maker Incentivization	Daniel Larimer	Protocol	Draft
7	Fee Backed Assets (FBA)	Daniel Larimer	Protocol	Installed
8	Privacy (STEALTH) Mode	Daniel Larimer	Protocol	Installed
9	Benefit Society	Fabian Schuh	Protocol	Draft
10	Percentage-based transfer fee solution based on CER	Jakub Zarembinski	Protocol	Accepted
15	Disable negative voting on workers	Daniel Larimer	Protocol	Installed
16	Optimization to Force Settlement Parameters of BitCNY	Jerry Liu	Protocol	Installed
17	Revive BitAsset after Global Settlement	Peter Conrad	Protocol	Draft
18	Revive BitAsset through buying Settlement Pool	Fabian Schuh	Protocol	Installed
19	Introducing profit sharing/dividends to Bitshares (MPA only)	Customminer	Protocol	Deferred
20	Introducing profit sharing/dividends to Bitshares (UIA only)	Customminer	Protocol	Deferred
21	Introducing the 'Coin-Age' statistic to Bitshares assets	Customminer	Protocol	Draft
22	Vote Decay for Witnesses, Committee Members & Proxies	Customminer	Protocol	Draft
23	Sharedropping an UIA against an external cryptocurrency distribution snapshot	Customminer	Protocol	Draft
24	Locking Bitshares away as 'Bitshares Influence' for voting privileges on the BTS DEX	Customminer	Protocol	Draft
25	Transaction Flat-Rates with Weighted Rate-Limitation	Fabian Schuh	Protocol	Draft
26	Refund Order Creation Fee in Originally Paid Asset on Cancel	Abit More	Protocol	Installed
27	Asset Issuer Reclaim Fee Pool Funds	Abit More	Protocol	Installed
28	Worker Proposal Improvements	Bill Butler	Protocol	Draft
29	Asset issuer change to require owner authority	Fabian Schuh	Protocol	Installed
30	Always Allow Increasing Collateral Ratio If Debt Not Increased	Abit More	Protocol	Installed
31	Update Short Position's Margin Call Price After Partially Called Or Settled	Abit More	Protocol	Installed
32	Always Match Orders At Maker Price	Abit More	Protocol	Installed
33	Maker Orders With Better Prices Take Precedence	Abit More	Protocol	Installed
34	Always Trigger Margin Call When Call Price Above Or At Price Feed	Abit More	Protocol	Installed
35	Mitigate Rounding Issue On Order Matching	Abit More	Protocol	Installed
36	Remove expired price feeds on maintenance interval	oxarbitrage	Protocol	Installed
37	Allow new asset name to end with a number	oxarbitrage	Protocol	Installed
38	Add target collateral ratio option to short positions	Abit More	Protocol	Installed
39	Automatically approve proposals by the proposer	Fabian Schuh	Protocol	Draft
40	Custom active permission	Stefan Schießl	Protocol	Accepted - Milestone 1
41	Reduce MSSR of bitCNY from 1.1 to 1.05	Jerry Liu	Informational	Superseded by 59
42	Adjust price feed to influence trading price of SmartCoins	Abit More	Protocol	Rejected
43	Market Fee Sharing	OpenLedgerApp	Protocol	Installed
44	Hashed Time-Locked Contract	Ryan R. Fox	Protocol	Installed
45	Add bitAsset Backing Collateral flag/permission	Customminer	Protocol	Draft
46	Escrow Concepts	Taconator	Informational	Accepted
47	Vote Proxies for Different Referendum Categories and explicit voting operation	Fabian Schuh	Protocol	Draft
48	Add Flag to Asset to Prevent Manipulating Max Supply	Fabian Schuh	Protocol	Draft
50	Stealth development, Phase II	Chris Sanborn	Informational	Draft
51	New operations for Confidential Asset (CA) transactions	Chris Sanborn	Protocol	Draft
52	Ring signatures for untraceability of Stealth transactions	Chris Sanborn	Protocol	Draft
53	Blockchain scanning for inbound Stealth transactions	Chris Sanborn	Informational (Client Protocol)	Draft
54	Deterministic addresses for Stealth wallets	Chris Sanborn	Informational	Draft
55	Metadata hiding via Garlic Routing and other means	Chris Sanborn	Informational	Draft
57	Managed Vesting Balances	Blockchain Projects BV	Protocol	Draft
58	Global Settlement Protection Through Price Feeding	Jerry Liu	Informational	Accepted
59	Adjustment of MSSR and MCR Through Voting	Jerry Liu	Informational	Accepted
60	BitShares URI scheme	John Titor, Stefan Schießl, Abit More	Informational (Client Protocol)	Accepted
61	Operation to Update Limit Orders	Nathan Hourt	Protocol	Draft
62	Close Short Position	Stefan Schießl	Protocol	Approved
63	Short-lived Unidirectional Payment Channels	Christopher J. Sanborn	Informational	Draft
64	Optional HTLC preimage length, HASH160 addition, and memo field	John Jones, Abit More	Protocol	Installed
65	Fix Locked Accounts	OpenLedger	Protocol	Draft
66	Sharedrop Operation	OpenLedger	Protocol	Draft
67	Dynamic Market Fees	OpenLedger	Protocol	Draft
68	Market Fee Based Asset	OpenLedger	Protocol	Draft
69	Additional Assert Predicates	Christopher J. Sanborn	Protocol	Draft
70	Peer-to-Peer Leveraged Trading	George Harrap, Michel Santos, Peter Conrad	Protocol	Draft
71	Add "Prevent Global Settlement" Flag for Smartcoin	Jerry Liu	Protocol	Draft
72	Tanks and Taps: A General Solution for Smart Contract Asset Handling	Nathan Hourt	Protocol	Draft
73	Match Force-Settlement Orders with Margin Calls and Limit Orders	Abit More	Protocol	Draft
74	Margin Call Fee Ratio	Jerry Liu	Protocol	Installed
75	Asset Owner Defines MCR and MSSR Values	John Jones	Protocol	Installed
76	Committee-Defined SmartAsset Collateral Threshold	Abit More	Informational	Draft
77	Require Higher CR When Creating / Adjusting Debt Positions	Abit More	Protocol	Installed
81	Simple Maker-Taker Market Fees	Abit More	Protocol	Installed
84	Elections Based on non-Core Asset	Peter Conrad	Protocol	Draft
85	Maker Order Creation Fee Discount	Abit More	Protocol	Installed
86	Share market fees to the network	Abit More	Protocol	Installed
87	Force Settlement Fee	Jerry Liu	Protocol	Installed

bsips's People

Contributors

Stargazers

Watchers

Forkers

juanfranblanco abitmore shentist pureland pmconrad johndba cryptobuks biophil grctest sensecollective testlump shanxin bitcoiners descifra agoric-systems wmbutler amadeobrands francewhoa christophersanborn johnblockchain grendias stevengu999 jollygood11 miraclezhang poundhu vvvictorlee bitshares3 ebit116 thetaconator bxlkm cogutvalera shiyuesong sanjumm1983 pchaozhong sschiessl-bcp conner72 jmjatlanta bitcrab denissok openledgerapp openledger dayman32 bitsharesteam open-asset jbelke pansiyu0913 blockchainprojects b-t-s-1 secp256 lanhaoxiang ryanrfox techsusinc michelsantos jhtitor bluffet uniblockchain quantumbitnetwork bubach liferocks007 andreishybin compumatrix hb1github payplatinum nathanielhourt ethernodes-org froooze litepresence vianull clockworkgr dls-cipher winston-1984 oxarbitrage hobbit19 shulthz sonjdf prcolaco bts-cm

bsips's Issues

Portfolio Balances to include Open Order funds

Now that the hover over Holdings amount that brought up a breakdown of holdings is gone permanently, can we have funds in "open orders" reported under the Portfolio page.
Thanks

bsip#10: Percentage-based transfer fee solution based on CER

BSIP: 0010
Title: Percentage-based transfer fee solution based on CER
Authors: Jakub Zarembinski <[email protected]>
Status: Draft
Type: Protocol
Created: 2015-12-27
Discussion: https://bitsharestalk.org/index.php/topic,20789.0.html
Worker: t.b.d.

Abstract

This is a proposal aiming to introduce a percentage-based transfer fee solution as an alternative to the current flat rate. The main goal is to make BitShares competitive for transfers below the equivalent of $5 while keeping the referral program unharmed (or even strengthened).

The idea is to derive the BTS value of an asset transfer from the Core Exchange Rate (CER) defined by the asset's issuer. A complementary change in the referral system is also needed in order to prevent abuse on the part of referrers.

The only stakeholders affected by this proposal are referral businesses as their revenue stream will be negatively affected for smaller transfers but instead positively affected for larger ones. As for shareholders in general, the change is positive because BitShares will become more competitive in terms of pricing when compared to the legacy systems.

The financial effect for the blockchain itself will be neutral as all profits (or losses) will be absorbed by the referrers. However, an overall increase in the network's revenue is expected as it is safe to assume that when small transfers are cheaper, there will be more of them and each of them will contribute to the network's revenue. As we have it know, most blocks are empty, which from a business perspective is a clear waste of company's resources.

Motivation

Having a flat transfer fee of 30 BTS for non-LTM users, currently BitShares cannot be regarded as a competitive payment solution for transfers between the equivalent of $1 and $5. The current fee in this range is above 2%, which is way more than any legacy system wants to charge its customers.

There are two important objectives this proposal aims to achieve:

to allow users to pay lower transfer fees for smaller transfers (while charging them more on bigger transfers)
to allow referrers to earn extra income associated with bigger transfers (while taking away from them the current income associated with smaller transfers).

Rational

The simplest way to solve the "high transfer fee" problem would be to lower transfer fees for all assets. However this would effectively kill the referral program. On the other hand, a simple percentage-based transfer fee system is not doable as for most assets we do not have a viable way to determine their exact value at any given time. This is mainly due to the fact that most markets are very illiquid but also due to the difficulty of establishing an asset's price in a manner which is deterministic enough to reliably prevent unintended hard-forks.

Also, a percentage-based transfer fee system, if introduced without any modifications to the referral program, would open up the possibility for referrers to game the system by transferring small amounts back and forth between their own accounts just to collect the referral award at the expense of issuers. Therefore, for assets enjoying a percentage-based transfer fee system, referrers' revenue structure has to be percentage-based as well.

Specifications

The assumptions

The following description uses a fictional asset called BAX but this solution can be applied to all assets (i.e. SmartCoins, private bit-assets, UIAs and FBAs) and all non-stealth transfers. Also, what is described below refers to pay-as-you-go users. For LTM users exactly the same rules apply, except for the fact that in this case the referrer's income is redirected to the user's cash-back fund.

Values used in the description are just an initial proposal, the actual values will be determined be the committee.

The concept

The transfer fee can be paid either in BTS or BAX.

If the user chooses to pay the fee in BTS:
- The transfer fee is equal to 1% of the BTS value of the BAX amount being transferred, adjusted by a floor (i.e. minimum fee) and a cap (i.e. maximum fee): 6 BTS and 300 BTS respectively. So effectively the transfer fee is 1% but it is never less than 6 BTS and never more than 300 BTS.
- To establish the BTS value of the transfer, CER is used.
- The fee paid by the user is split as follows: 6 BTS goes to the network, any excess above 6 BTS goes to the referrer.
- The issuer does not earn anything.
If the user chooses to pay the fee in BAX:
Let F be the transfer fee (expressed in BTS) which was calculated as described in (1).
- To establish the BAX equivalent of F, CER is used.
- The issuer receives the entire fee paid by the user in BAX.
- The following amounts are deducted from the asset fee pool: 6 BTS goes to the network, and (F - 6) BTS goes to the referrer.
- The issuer makes a profit or loss, depending on CER being above or below the actual BTS/BAX exchange rate.

The main issue

What happens when the issuer attempts to artificially lower transfer fees on his asset by pretending his asset is not worth much and deliberately keeping CER below the actual BTS/BAX exchange rate?

for the user: it's cheaper for him to pay the fee in BTS rather than in BAX
for the issuer: he makes a profit on all those transfers for which the user, for whatever reasons, decides to pay the more expensive fee in BAX (instead of the cheaper one in BTS)
for the referrer: no matter if the user pays the fee in BAX or BTS, he is deprived of a large part of the referral reward, as due to distorted CER, transfers are interpreted by the system as involving smaller value than they actually are.

How is the issue solved?

By keeping CER artificially low the issuer will effectively discourage users from using his own asset because transfer fees will only be low when paid in BTS, so the process of transferring the asset will be dependent on users having BTS in their wallets to cover the fees. Furthermore, if the issuer distorts CER too much, he'll not be able to benefit from it himself as users will start avoiding paying the fees in BAX. Also, it will be bad PR for the issuer to value his own asset below the market rate. At least in case of SmartCoins and major private bit-assets issuers are not likely to be wiling to sabotage their own assets in this way.

However, if it turns out that a large number of issuers try to game the system, we can introduce the following mechanism aimed at preventing abuse on the part of issuers:

To enable percentage-based transfer fees, the issuer will be obliged to keep an open ask order on the BTS:BAX market and thus allow anybody to buy BAX at e.g. 120% of CER. As a result, if CER is out of sync with the market rate by more than 20%, the issuer will incur a significant loss.
If the issuer is not willing to comply with the above requirement, the default flat transfer fee structure will be applied.

This is an opt-in feature

As the issuer is the only entity that actually controls CER, the percentage-based transfer fee is meant to be an opt-in feature decided by the issuer. It is safe to assume that most issuers will find it beneficial for their assets because:

assets which are worth something will benefit from having a reasonable pricing structure for transfers
assets which are worth nothing or almost nothing (i.e. most UIAs) will be able to be transferred almost for free (for 6 BTS instead of the current 30 BTS).
However, if an issuer for some reasons does not find the above features beneficial, he will be able to keep the existing flat fee structure.

Discussion

Being voluntary for issuers, the above proposal is actually targeted to the referral businesses: do they perceive it as a beneficial change for the ecosystem and a fair deal for them? They will need to forgo the referral income on transfers below the equivalent of $2 but will substantially increase their income on transfers above the equivalent of $10. In the range between $2 and $10 they will get on average half of the income they have now. Nevertheless, the main benefit will be indirect: it's much easier to sell a reasonably priced product.

As for the BitShares network itself, the overall impact of this proposal will be positive, as the network's resources will be better utilized. With the current flat fees, most of the blocks are empty. Percentage-based fees will not fix this waste immediately, but will be a step in a good direction and a good foundation for businesses based on small tips and micro-payments above $1.

Copyright

This document is placed in the public domain.

bsip#16: Optimization to Force Settlement Parameters of BitCNY

BSIP: 0016
Title: Optimization to Force Settlement Parameters of BitCNY
Authors: Jerry Liu<[email protected]>
Status: Draft
Type: Protocol
Created: 2016-05-06
Discussion: https://bitsharestalk.org/index.php/topic,22355.0.html
Worker: no

Abstract

By optimizing 2 key force settlement parameters of bitCNY to make the force settlement rule more reasonable, the expected consequence is that the shorters will be encouraged to provide more bitCNY supply and benefit the whole economy.

Motivation

As a smartcoin, bitCNY pegs to CNY, it is expected to be used in some payment and trading scenarios as a stable currency, however, as bitCNY is generated by shorting with BTS as collateral, and the debt position is possible to be force settled at any time, users always do not have enough incentive to short and then bitCNY is always in low supply level, this restrict the growing of relevant economy, so what is proposed is to set a compensation from holder to shorter and lower the force settlement volume limit, these will reduce the risk of shorters and encourage them to provide more bitCNY supply.

Rationale

The force settlement offset can be seen as a service fee that holder pay to shorter at the time of force settlemetn happens, the offset need to be set a proper value that can balance the risk of holders and shorters, the 0 offset setting is not reasonable enough as in common financial logic the collateral should not be force settled without any compensation if the collateral price does not fall below the margin call price, on the other hand, if the offset is set too high, holders will be discouraged to hold the smartcoin as high offset can make force settlement not feasible. as a reference, in the initial time after creation, TCNY has been set a 2% force settlement offset, the consequence is that almost all the holders do not want to request force settlement, even when BTS price is very low, based on these reference, now 1% offset is proposed.

Suppose there's no shorting happens in 24 hour, then the maximum volume that can be force settled in this period is supply * (1-(1-q)**24) , here q = maximum_force_settlement_volume.

Here p=(1-(1-q)**24) represent the maximum percentage of the supply that can be force settled in 24 hours, then

if q=3% p=51.9%
if q=2% p=38.4%
if q=1% p=21.4%
if q=0.5% p=11.3%
if q=0.2% p=4.7%

q=0.5% should be a reasonable choice with at most 11.3% of supply can be force settled in one day.

Specification

A committee proposal will change the 2 parameters of bitCNY from

force_settlement_offset_percent = 0
maximum_force_settlement_volume = 2% per hour

force_settlement_offset_percent = 1%
maximum_force_settlement_volume = 0.5% per hour

The expiration time will be set to 30 days for relevant users to respond and operate.

Discussion

Will bitCNY be "devalued" after this change?

If we can say force settlement offset is a service fee paid from holder to shorter. this change is just to ask holders to pay 1% fee to shorters while requesting force settlement, and they really should pay some fee. bitCNY is really "devalued" with 1% if force settlement is the only way for this smartcoin to quit, but bitCNY has some other way to quit, including to trade with other assets, to deposit to btc38 and to withdraw through gateway. and the collateral of the smartcoin are always there without any change, so the "devalue" is slight enough if not zero. The holders also have a long expiration time to request 0 offset force settlement to quit. So comparing to the benefits this change will bring to the relevant economy, this "devalue" is not a problem.

Should this change be applied to other smartcoin such as bitUSD?

Based on the same logic, it is also necessary to apply the same change to other smartcoins, but to be cautious, it is proposed to first apply the change to bitCNY, after obesevation and review with long enough time, it can be considered to apply the change to other smartcoins.

Copyright

This document is placed in the public domain.

extend user issued names

this is an issue to test the waters on how much interest the bitshares community will have on extending asset names to allow numbers at the end of them. for example issue an asset with the name SP500.

inspired by this issue. bitshares/bitshares-core#620

BitShares Network Is Overloaded and Needs More Infrastructure

Recently I have been only seeing one or two nodes at a time with medium or high latency and many times my transactions are timing out due to poor server connections...

I am in New York City now and have been in Germany, France, and England recently and have had the same issue so it isn't the network where I am. Throwing out my library files for the BitShares application on Mac OS 10.12 seems to give me a few more or faster connections for a short time then it goes back to slow again. It is very frustrating.

I am wondering if this problem has been happening for many people and if it is just an overloaded infrastructure due to higher use recently. If so, we need a proposal to incentivize more nodes for the blockchain. Pay more to the witnesses or something. This is a serious bottleneck we have hit.

Any suggestions are appreciated!

About BSIP 39: make the approval optional

Since sometimes the proposer don't want to approve immediately, it's better if she has an option to decide whether approve.

bsip#12 BitShares Hardfork Precdure Proposal

BSIP: 0011
Title: BitShares Hardfork Precdure Proposal
Authors: [email protected]
Status: Draft
Created: 2016-01-13

Purpose

This documents tries to establish a process that will be applied to all
future hard fork proposal and that will be used to identify if
a proposal is approved or not.

Preface

In BitShares, every shareholder has a vote as to whether a new feature,
innovation or other proposal shall be integrated into the BitShares
protocol via a hard fork.

It is of importance to establish a voting mechanism that clearly
resolves to either

approved by shareholders, or
not approved.

To identify the will of the shareholders, we make use of blockchain
workers that is attached to a BitShares Improvement Proposal (BSIP).

Every shareholder can approve, or disapprove the worker and by this
casts a vote. Currently, a worker proposal is considered approved once
it enters the actively paid workers (independent of its actual pay). In
other words, a worker that has more approval votes than the last
approved worker that is paid (often a refund or burn worker), then
the proposal is approved. Thus we currently have:

   vNet(fork) = vPro(fork) - vCon(fork)

   "approved" if (vNet(fork) > vAct(x)) else "not approved"

With

vNet being the net votes
vPro(x) being the approval votes
vCon(x) being the disapproval votes
vAct(x) being the last active worker

Once a proposal has reached approval, it has to be implemented by
the witnesses until the hard forking block.

Problem Statement

There never was an approved consensus about the threshold.
Hard Fork Proposals compete with Workers which is a different demographic

Solution Proposal 1

Since Worker Proposals can be approved and disapproved, a net
positive vote for a hard fork proposal can be considered approved.
If the net vote result is negative, the proposal is not approved. Here
shareholders compete with pro and contra votes.

Thus we here have:

   vNet(fork) = vPro(fork) - vCon(fork)

   "approved" if (vNet(fork) > 0) else "not approved"

Pros

Fair representation of consensus
Simple Scheme

Cons

Shareholders need to vote on every hard fork

Solution Proposal 2

To relax the rule, we could have a threshold worker (zero pay) so that
shareholders can define the threshold as well.

By this, shareholders vote on hard forks in general and have the options
to also vote for particular hard forks of which they are in favor, or
not.

If a shareholder doesn't want to see additional features implemented, he can
approve the threshold worker and raise the required net votes for a hard fork.

Alternatively, those that want a flexible protocol can disapprove it and
have hard fork proposals be approved more easily.

Thus we here have:

   vNet(fork) = vPro(fork) - vCon(fork)
   vNet(threshold) = vPro(threshold) - vCon(threshold)

   "approved" if (vNet(fork) > vNet(threshold)) else "not approved"

In order to prevent rapid approvals, a proposal will only be evaluated
after 2 weeks. This gives shareholders time to disapprove in a timely
manner.

Pros

Allows to set a 'default' approval/disapproval
Only a little more difficult scheme

Cons

Can not distinguish between different degrees of innovation in a hard fork

Solution Proposal 3

To extend the previous idea, we propose to characterize different BSIPs
into categories (tier-1, tier-2, ..) and have a distinct threshold
for each of them.

This would lead to the rule:

   tier = characterize(fork)
   vNet(fork) = vPro(fork) - vCon(fork)
   vNet(threshold, tier) = vPro(threshold, tier) - vCon(threshold, tier)

   "approved" if (vNet(fork, tier) > vNet(threshold, tier)) else "not approved"

In order to prevent rapid approvals, a threshold worker will only be
considered if it existed at least 2 weeks. Furthermore, threshold
workers shall be created by the committee-account, only.

Pro

Very Flexible

Con

Very difficult approach
How to decide categories in a decentralized way

Solution Proposal 4

And then of course we can combine them. A hard threshold which must be
passed by ever soft threshold and a successfully approved proposal must
surpass the hard threshold as well as the tier-specific soft
threshold.

   tier = characterize(fork)
   vNet(fork) = vPro(fork) - vCon(fork)
   vNet(threshold, tier) = vPro(threshold, tier) - vCon(threshold, tier)
   vNet(hardthreshold) = vPro(hardthreshold) - vCon(hardthreshold)

   "approved" if (vNet(fork, tier) > vNet(threshold, tier) AND vNet(fork, tier) > VNet(hardthreshold)) else "not approved"

Pros

Most flexible approach

Cons

Very difficult approach

Initialization

In order to reach consensus, we propose a 2-step procedure.

We first let shareholders approve this general document such that
a consensus is reach about the general concept.
Shall this document be approve, each proposed solution will have it's
own (zero-pay) hard fork worker. The last active worker (that is
being paid) is considered as approval threshold.
- If any of the proposals is approved into the active domain within
  8 weeks after creation, the active proposal with the most net votes
  is approved an shall be implemented accordingly at that time.
- If after 8 weeks, no proposal has reached the active domain, the
  proposal with the most active net votes shall be implemented.

Conclusion

We here present four approaches to identify if shareholders approve
a hard fork or not and show a way to reach consensus about the
implementation of one of these options.

Order lost - "Failed to broadcast transaction" error loses order setup

When the nodes are not responding well, and i make an order that "Failed to broadcast transaction", then the whole order i set up gets lost, the values disappear from the order buy/sell panel. I had to recreate the order 6 times before it finally went through. This is a recipe for a fat finger error x6.
Could you make it so the amounts stay in the GUI panel or alternately have the ability to save an order without placing it so that it can be tried a number of times without creating from scratch again.
Thanks & Cheers

Increase witness payment to 4BTS/block

Title: Increase witness payment to 4BTS/block
Authors: Jerry Liu<[email protected]>
Status: Draft
Type: Protocol
Created: 2017-1-31
Discussion: https://bitsharestalk.org/index.php/topic,23702.0.html
Worker: no

Abstract

I here propose to increase the witness payment from 1.5 BTS/block to 4 BTS/block.

Motivation

With the growing of the Bitshares ecosystem, the community begin to demand more on witnesses, including more stable block production and more reliable price feeding to smartcoins. on the other side, the current witness payment level - 1.5 BTS/block is too low to encourage witnesses to pay more cost and effort to upgrade their services, and there are not enough qualified witness candidates ready to be voted, this proposal is to solve this problem.

Rationale

Under current witness payment level witnesses can only get low profit while limiting the input, a detailed summary from rnglab can be found at https://bitsharestalk.org/index.php/topic,23607.45.html .

Propose to increase the payment to 4BTS/block is a compromise to differnent parties, first, this is a solid increase that can encourage witness to pay senseful more cost and efforts to upgrade their service. second, the number is comparatively conservative and avoid to occupy too much resources of daily budget.

When I wrote, the BTS supply is 2580953927(reserve pool not included), so 4BTS means 1.6% annual dilution rate.
Today(2017/1/31)'s total avaliable worker budget: 305493 BTS. in which 68961(22.6%) are paide to 3 real worker and the left is for one refund worker. while 4BTS means 115200 BTS daily payment to witness.

According to above conditions, 4BTS/block is acceptable to all the parties.

Discussion

How to make sure that the witnesses will and really do more after the payment increase? Can we set some standard to qualify active witnesses?

the current mechanism to determine active witnesses is based on voting, is decentralized, some people has shared their idea on what standard a witness should reach.

For example rnglab has expressed, "It seems to me that having two 8Gb nodes per witness, with failover able to identify and move away from minority forks (when possible with just two nodes), are the minimum technical requirements to handle the upcoming network growth."

As a proxy, I also expressed my standard to qualify witness, with main concern on price feeding:

1.stable block generation.
2.at least feed bitCNY or bitUSD or both.
3.the price feeding should be reliable enough with no obvious drawback like "yunbi fault" .

I already began to evaluate witnesses and vote the unsatisfactory ones out following the above rules.

When the witness payment really increases, voters will pay more concern on witnesses' working quality, and I believe the unsatisfactory witnesses will be voted out, however, I don't think we need to rush to set a common standard on witness admittance at this stage, proxies will take actions on their own judgment and some times later a general accepted standard can emerge during community interaction.

Why not separate the block production service and price feeding service?

I agree that block production and price feeding may need different resources and expertise, however, it's not very difficult for one to do both by learning new things or cooperation.

To separate the 2 services need some new design, if we can solve the problem as a whole, it will be not worthwile to introduce more complexity and pay more time and coordination cost to solve such a not so complicated problem.

Summary for Shareholders

The idea behind this proposal is "pay to who really contribute" and "raise Bitshares standard", it can be seen as the response to the challenge bring by growing network, hope this bring satisfactory consequences.

Copyright

This document is placed in the public domain.

The problem of Witnesses and committee votes.

When a person votes for multiple witnesses and the committee, the number of votes each witness and committee receives should be his market value/the number of votes cast by him.

Otherwise one can register several witnesses and committee account, some people vote for his multiple accounts when he won the voters' accounts are so value vote, he could only become a witness and committee results but became more.

New BSIP: Prediction Market Improvements

Related discussions:

Current behavior:

When the outcome of a PM is 1, the issuer can globally settle with 1, the price feed producers can feed 1 as well (which will trigger a black swan event then globally settle at 1), the result is same.
When the outcome of a PM is 0, the issuer can globally settle with 0, but
- the price feed producers are unable to feed 0 (which is a bit complicated to fix),
- even if they feed a very small price e.g. 0.0001, the market won't be globally settled since a small price won't trigger a black swan event.

The final fix would be:

allow and only allow feeding 0 or 1
when there are enough feeds, global settle at median feed price.

By the way, settling at 0 means the market fees collected by the asset issuer/creator and shared to referral program worth zero. That's not a good business.

Core exchange rate of PM need to be considered as well. I think the best approach is to claim all CORE asset from the fee pool thus prevent the asset from being used to pay fees.

New BSIP discussion: Require UIA owner permission to use UIA as backing collateral for an MPA?

Should we require UIA owner permission to use UIA as backing collateral for an MPA?

Recently, issue #1537 in the bitshares-ui Github repo highlighted the fact that despite the UI and documentation indicating that UIA cannot be used to back an MPA on the BTS DEX, the reality actually is that UIA are an allowed backing collateral asset type in the core code.

This BSIP is not arguing for/against UIA being used as an MPA's backing collateral, because this is already enforced by core (Abit has a testnet asset configured as such).

The purpose of this BSIP discussion is to whether or not you should require owner permissions/approval of the asset being assigned as backing collateral for a new MPA.

Why I think we should require permission

Any assets locked away as MPA backing collateral cannot be reclaimed/recalled by the UIA owner (even by force). This has the consequence of being unable to reduce the supply to 0, potentially preventing asset settings from being changed or the asset from being fully shutdown.
By 'wrapping' an UIA in an MPA 'container' the MPA owner can effectively impose new asset settings over the existing UIA flags/permissions/settings to the potential detriment of the UIA owner.

Why perhaps we shouldn't require such permissions

An asset owner may refuse (or be unable to) provide permission to use the asset as backing collateral, requiring an alternative asset for backing collateral.
The committee may be overwhelmed with requests to use committee owned assets as backing collateral, though that's subjective.
The committee would have a greater centralized control of backing collateral selection on the BTS DEX, however that could result in more private MPAs being created. The committee size could be increased too to offset risk.
Existing MPA with non-BTS backing collateral may make implementing such a permission requirement too complex? Perhaps existing MPA could be exempt?
What if the asset owner removed their approval at a later date? It'd have to be permanent approval unless supply was 0.
What happens if you have owner permissions of the backing asset & MPA, then transferred the backing asset ownership to another account?
Being able to avoid market fees and replace restrictive permission flags with an MPA is pretty cool.

Exclusions:

The Bitshares core token should be excluded, as nobody has ownership permissions over it.

So, what are your thoughts?

Note: This is a mirrored github post!

Regarding BSIP022

Well done, nice work!

The only thing I had concern about was committee power, as their ability to set decay parameters could position them to become a centralized body more easily unless the range of decay they can adjust (max age, rate of decay) has hard coded limits committee must work within that mitigate that concern.

Also, I've long held that exchanges should NOT have voting rights, but how can that be accomplished? Blacklisting is not the answer, b/c as you say that power could be extended to individual accounts and thus effectively amount to control / censorship of individuals.

How to identify an exchange's account is one method of addressing the problem. Another might be a cap on stake for voting (max_stake_weight - an account with 1M bts = an account with > 1M BTS) it would equalize power of biggest stakeholders, but also discourages holding > max_stake_weight. What would impact on that be? Not saying 1M is the correct limit, just an example. However, the idea may lead to a more decentralized ecosystem.

BitRUB community owned smart-coin

Please add BitRUB (Russian Ruble) as community owned smart-coin.

White screen of death

WSOD on:
iPhone 5se iOS 11.4
&
iPhone 5 iOS 11.4.1

Same issue for both Chrome and safari browser on both iOS phones

Screen capture video below:

https://drive.google.com/open?id=1yaFGsTBiiwuAihZg5elFloIwOLIjrjlo

BSIP#26: Refund Order Creation Fee in Originally Paid Asset on Cancel

BSIP: 0026
Title: Refund Order Creation Fee in Originally Paid Asset on Cancel
Authors: Abit More
Status: Draft
Type: Protocol
Created: 2017-10-16
Discussion: https://bitsharestalk.org/index.php/topic,25153.0.html
Replaces: <BSIP number> (optional)
Superseded-By: <BSIP number> (optional)
Worker: <Id of worker proposal> (optional)

Abstract

When a user placing an new order, fee can be paid with another asset but not only BTS. Currently, when the order is cancelled and if not partially filled already, an amount of BTS will be refunded to the user. This BSIP proposes refunding in the originally paid assets but not always BTS.

Motivation

Make the asset system easier to use and less vulnerable.

Rational

With the asset fee pool feature, asset holders don't need to hold BTS to pay transaction fees. However, after the "Refund Create Order Fees on Cancel" feature introduced in Graphene issue #445 as well as BSIP #2, due to the (inappropriate) design / implementation, fee pools often get drained by 3rd-party bots unexpectedly, which renders the fee pool feature hard to use / less useful. This BSIP proposes a protocol change to prevent fee pool draining from happening, while still keeping a similar "Refund Create Order Fees on Cancel" feature in the system. It brings following benefits:

If a user created an order with fees paid in one asset, it's more acceptable for her to be refunded in same asset when the order is cancelled.
If the same asset paid is refunded, exploiters/bots will be unable to drain the fee pools.

Specifications

Current Design and Implementation

Always refund fee in the form of CORE asset (BTS), even if fee was paid with another asset.

When a new order is created, if fees are paid in an asset other than BTS, that fees will be added to the asset's accumulated_fees field right away, in the same time some BTS will be deducted from the fee pool according to the asset's CER then be put into the deferred_fee field of the new created limit_order_object.
When the order got filled or partially filled, the BTS in deferred_fee field will be directed to referral program.
If the order be cancelled manually before partially filled, the BTS in deferred_fee field will be sent to the owner's balance.
If the order be cancelled automatically due to expiration or too small to fill, a cancellation fee will be deducted from deferred_fee but capped by the remaining amount, then the cancellation fee (if any) will be redirected to referral program, the yet remaining amount (if any) in deferred_fee will be sent to the order owner's balance.

Proposed Changes

Always refund fee in the form of paid asset.

When a new order is created, if fees are paid in an asset other than BTS, store the fees to the new order's deferred_paid_fee field (a new field) but not add it to the asset's accumulated_fees field right away, in the same time deduct some BTS from the fee pool according to the asset's CER and put it into the deferred_fee field of the new created limit_order_object. Say, the order owes the system some fees in BTS and owe the asset issuer some fees in that asset.
When the order got filled or partially filled, redirect the BTS in deferred_fee field to referral program, at the same time send the assets in deferred_paid_fee field to the asset's accumulated_fees field.
If the order be cancelled manually before partially filled, send the BTS in deferred_fee field to the asset's fee pool, and send the assets in deferred_paid_fee field to the owner's balance.
If the order be cancelled automatically due to expiration or too small to fill, deduct a cancellation fee from deferred_fee but capped by the remaining amount, then redirect the cancellation fee (if any) to referral program; if the cancellation fee is positive, deduct an amount equals to round_up(cancellation_fee_in_bts * deferred_paid_fee / deferred_fee_before_deduct) of assets from deferred_paid_fee but capped by the remaining amount then send it to the asset's accumulated_fees field; then send the yet remaining amount (if any) in deferred_fee to the fee pool, send the yet remaining amount (if any) in deferred_paid_fee to the order owner's balance.

Discussion

When creating an asset, with current design, the issuer is forced to put half of creation fee into the new asset's fee pool. But not all people like this feature. It's better if the fee pool filling is optional when creating a new asset.

Asset issuers may want a dedicated operation to get out some BTS from the fee pool, for example when accidentally filled too much BTS into the pool. This is discussed in bitshares-core issue #188. If this BSIP is implemented, asset issuers will be no longer able to get out the BTS from the fee pool by cancelling an order.

Summary for Shareholders

Copyright

This document is placed in the public domain.

Abstract

Asset issuers need a way to get out some CORE assets (BTS) from their assets' fee pool, for example when accidentally filled too much BTS into the pool. As of writing, this can be done by crafting a special limit order then cancel it, the process is a bit complicated. In addition, this approach will no longer work if BSIP #26 (Refund Order Creation Fee in Originally Paid Asset on Cancel) is implemented. This BSIP proposes a protocol change to meet the demand.

Motivation

Make the asset system easier to use.

Rational

Asset issuer should have full and easy control over the funds in the fee pool.

Specifications

Current Design and Implementation

Asset issuers can fill the fee pool with the asset_fund_fee_pool_operation operation, which has a structure as follows:

   struct asset_fund_fee_pool_operation : public base_operation
   {
      asset           fee; ///< core asset
      account_id_type from_account;
      asset_id_type   asset_id;
      share_type      amount; ///< core asset
      extensions_type extensions;
   };

The amount in the structure can only be positive, which means the from_account can only add some CORE asset (BTS) into an asset's fee pool.

Proposed Changes

Allow amount to be negative;
When amount is negative, from_account can only be the issuer;
When amount is negative, deduct the absolute amount from the asset's fee pool and add it to the issuer's balance.

Discussion

The operation fee for asset_fund_fee_pool_operation should be no less than transfer_operation.

Summary for Shareholders

[to be added]

Copyright

This document is placed in the public domain.

Check out the BSIP

Any thoughts?

Relevant threads

https://steemit.com/bitshares/@cm-steem/draft-bsip-0024-locking-bitshares-away-as-bitshares-influence-for-voting-privileges-on-the-bts-dex

https://bitsharestalk.org/index.php/topic,24906.0.html

Sections of the BSIP which require developer input

Snapshot data inclusion in Bitshares network
- How to include snapshot genesis data in blockchain (within many transactions, or alongside genesis.json when launching the full/witness nodes?)
Claiming UIA token via importing external cryptocurrency private keys
- Currently we can only redeem BTS (Core) assets on the BTS DEX by importing BTS0.9x private keys, what dev is required behind the scenes to support many types of private keys & enable UIA claim via key import.
Need to pre-register sharedrop recipient accounts?
- Do we need to pre-register an account for a sharedrop recipient, or can any account claim the sharedrop if they import the appropriate private keys?

TODO

Proof of concept Bitcoin based altcoin snapshot (far less data to process than bitcoin).
Detail steps to produce a provable Bitshares snapshot
Get developer input on the above (and the BSIP as a whole)
Talk about this during the next Bitshares hangout.

New BSIP 0051: New operations for Confidential Asset (CA) transactions

(From: https://github.com/Agorise/bsips/blob/master/bsip-1201.md)

BSIP: 1201 (unassigned)
Title: New operations for Confidential Asset (CA) transactions
Authors: Christopher J. Sanborn
Status: Draft
Type: Protocol
Created: 2018-01-29
Discussion: <url>

Abstract

Confidential Assets (CA) [2] extends Confidential Transactions (CT) [1] to include asset hiding. The BitShares network already understands and validates CT transactions, but is not yet capable of validating CA transactions. The transaction format will need minor to moderate updating and the validation routines will likewise need updating. We propose to either (a) update op-code 39, 49, and 41 to be CA capable, or (b) define new opcodes for CA stealth operations. The latter option probably affords a cleaner upgrade path. The old opcodes should then be disfavored for user wallet use.

Confidential Assets is a new, but not un-tested, technology. The Elements Project [3] maintains an experimental implementation [4] of CA as a Bitcoin side chain. The code for that project is MIT-licensed and can help guide the implementation of CA in the BitShares ecosystem.

This BSIP is one of several describing Stealth development, Phase II.

Motivation

A user maintains value-blinded balances on the BitShares blockchain as a collection of Pedersen commitments, which are EC curve points that obscure their committed values by adding a secret blinding factor times a generator point. By keeping the blinding factor secret, the user keeps their balance secret. Meanwhile, balances can be transferred, subdivided, or combined, provided the sum of blinding factors for all inputs to a transaction are equal to the sum of blinding factors of all outputs of a transaction. A user wishing to un-blind and "claim" a balance contained in a Pedersen commitment may do so by revealing the blinding factor for that commitment, which then allows the network to verify the committed amount and credit it to a public balance.

A commitment C is given mathematically by C = value * H + blinding_factor * G, where H and G are separate curve point generators with no known divisor between them. Because there is no known multiple m solving H = m*G, the value and blinding_factor quantities are effectively independent, which makes C a firm commitment to value.

BitShares is a multi-asset chain. The Pedersen commitments implemented in Stealth Phase I commit only to a value amount, and nothing more. For the network to understand which asset is represented by a commitment, a plaintext metadata field is associated with the Graphene object for the commitment, containing the asset ID of the blinded asset. This means that the asset type of an individual blinded balance is publicly knowable.

Confidential Assets (CA) introduces a method for using a commitment to a hash of the asset description as a confounding factor similar to the blinding factor, such that, unless one already knows the asset represented by a particular Pedersen commitment, one cannot determine the asset from inspection alone. Furthermore, amounts of differing assets can be combined in a single transaction, so that the asset IDs of the outputs are not individually knowable. Thus, even by tracing the history of a given commitment, one cannot simply divine the asset type by back-tracing to the point where a public asset was blinded, as the history may implicate multiple asset types. When a user wishes to un-blind an asset, he may do so by providing both the value blinding factors and the asset blinding factors for the commitment, so that the network can confirm the contents thereof.

By allowing commitments of differing assets to be mixed together, we achieve two points for privacy: (1) we increase the available mix-in set for diffusion of transaction history, and (2) we make it more difficult for blockchain analysis to determine which assets are being operated on in any given transaction (the more assets involved in the history of a particular commitment, the greater the uncertainty of what the commitment contains).

Rationale

Asset Tags and Asset Commitments

The existing value-blinded CT transaction capability includes an explicit asset ID in the transaction format, and unspent commitments are associated with an explicit clear-text asset ID in the database. For example, querying the blockchain for commitment "024449...8073" returns a structure containing three defining fields:

Field:	Data (Meaning)
commitment:	"0244492ceafc9c3d6fab34b4e2912b360a3276560651451580325f754705758073"
asset_id:	"1.3.0" (Core asset, BTS)
owner:	(Authority struct specifying public key that must sign)

Under CA, the asset_id field would be replaced by asset_commit which is a commitment to an asset tag. The asset tag, denoted H_A, is a curve point produced by a hashing procedure of some defining description of the asset (for example the asset_id, "1.3.0", etc.). The asset commitment, denoted H, is the sum of H_A and a blind point, e.g., H = H_A + r*G. Under this scheme, a CA commitment in the database would look similar to:

Field:	Data (Meaning)
commitment:	"0244492ceafc9c3d6fab34b4e2912b360a3276560651451580325f754705758073"
asset_commit:	"022b607af588386028a97d6bc4be5caddb432340329bc808ba587c0b92ffb1087c"
owner:	(Authority struct specifying public key that must sign)

As can be seen, casual inspection of the blockchain does not reveal the underlying asset, nor even asset tag, since it is commingled with a blinding factor. The only way to know the asset id would be if the commitment were a direct descendent of an asset-issuance transaction (where a public balance was blinded into a value-asset blind CA commitment). However, once a commitment is involved in a transaction involving inputs of multiple asset types, then uncertainty is introduced in the descendent commitments: the asset type will be one of the parent asset types, but which one is unknowable except to parties that know the blinding factors.

(TODO: QUESTION: How is it ensured that H_A is a valid curve point? There must be some kind of nonce increment in the hash procedure to reject non-curve points. Find out.)

Range Proofs and Surjection Proofs

Since the committed values in the Pedersen commitments are unknowable to parties not privy to the blinding factors, there exists the possibility for a transaction resulting in two or more outputs to encode a negative value in one output and an excess positive value in the others, resulting in inflated (i.e., counterfeit) asset supply. To prevent this, transactions with more than a single output are required to provide a range proof for each output, which is a zero-knowledge proof that the committed value is in a finite range between zero and an upper bound that won't risk overflow into negative values. (Values are encoded as 256-bit unsigned integers such that very-large integers "wrap around" and behave as negatives. Range proofs typically prove that a committed amount can be represented in 64-bits or less, affording no risk of overflow.) Under CA, the requirement to provide a range proof remains the same as under CT.

A new requirement in CA is the asset surjection proof. Similar to range proofs, ASPs prove that a validity contstraint is met on the blinded asset commitments of the transaction outputs. Specifically, it proves that the asset tags of the outputs match the asset tags of the inputs, without revealing what those tags are or which outputs correspond to which inputs. (TODO: preceding is imprecise.)

(TODO: discuss space requirments of ASPs, since they do add to transaction size. Compared to range proofs already included in CT transactions, however, they are comparatively small, except perhaps in the case of a large number of inputs and outputs in a single transaction.)

Specifications

We propose to add the following three CA operations to the set of valid operations declared in graphene::chain::operation (chain/protocol/operations.hpp). The new CA operations are shown here side by side with their CT equivalents:

Op-Code	Description	Op-Code	Description
39	transfer_to_blind_operation	49 (placeholder)	transfer_to_ca_blind_operation
40	blind_transfer_operation	50 (placeholder)	ca_blind_transfer_operation
41	transfer_from_blind_operation	51 (placeholder)	transfer_from_ca_blind_operation
		52 (placeholder)	ct_to_ca_blind_transfer_operation

On the left are CT operations, whose outputs are value-blinded commitments. On the right are the corresponding CA operations, whose outputs are value-and-asset-blinded commitments. Of special note is op 52, which takes value-blinded CT inputs and outputs value-and-asset-blinded outputs. (As an alternative, op 50 could be made flexible enough to accept either CT or CA inputs, if this proves feasible.) As CA is seen as an upgrade to CT, no op-code is here proposed for transferring from CA back to CT, however in the event of market demand such an operation could be coded.

Proposed operation: transfer_to_ca_blind_operation (Public to Blind)

Proposed operation: ca_blind_transfer_operation (Blinded to Blind)

Proposed operation: transfer_from_ca_blind_operation (Blind to Public)

Discussion

Compatibility with ring-signature scheme

The Op-Code additions and specifications provided in this document do not conflict with or depend on the details of the ring-signature proposals in BSIP-1202, as they effect different substructures of the Transaction structure, and therefore both proposals can be implemented independently. This document specifies structures within the Operations vector within a Transaction structure, whereas the ring signature scheme would change the Signatures vector.

(TODO: Check whether preceding is true, i.e. that the operation structure is independent of signature method. If it is not true, include here a discussion of what else might need to be included in the structure, so that a decision can be made as to whether the two features would be best developed in parallel, or whether ring-sigs could be implemented subsequently as an "upgrade" to CA.)

Asset surjection and compatibility

TODO: Question: Are Asset-Surjection Proofs compatible with a Ring-Sig scheme? I.e., can a prover who is "accusing" unrelated inputs produce the proof even not knowing the blind factors and asset tags of the unrelated inputs?

Summary for Shareholders

Copyright

This document is placed in the public domain.

Abstract

Confidential Transactions (CT) [1], (as implemented by Phase I of Stealth development), solves the linkability and value-hiding problems, but not the traceability problem. CT transfers are traceable on the blockchain, meaning that for any given transaction, a history of prior transactions can be determined. If the set of antecedents is large, then there is a great degree of plausible-deniability regarding the origins of the hidden assets. However, if the set is small, it is possible to determine with increasing probability where the assets originated from. A solution to this is to “mix” transaction inputs with unrelated users so as to increase the traceability set. Some privacy blockchains rely on a mechanical mixing or “tumbling” process to increase the traceability set, however this approach has drawbacks. Monero has a very clever scheme of using ring signatures to automatically and randomly mix in unrelated inputs on every transaction, guaranteeing that even newly blinded funds are mixed with with inputs having a rich history. It is proposed, as a component of Stealth development Phase II, to implement a similar mechanism for BitShares.

Motivation

Stealth can be thought of as a constellation of privacy-preserving features implemented on (or planned for) the BitShares blockchain. "Privacy" here is a set of specific goals:

Untraceability
Unlinkability
Value/Asset hiding
Anonymity

Although Confidential Transactions (CT) provides good solutions to unlinkability and value hiding, (which together help but do not fully solve anonymity), the transactions currently supported on the network are fully traceable. This means it is possible generate a history all prior transactions leading up to a particular transaction output, including a set of originating transactions wherein public balances were blinded. For outputs which are "close" to their originating transactions, it may be possible possible to identify a small set of non-anonymous originating actors, and to make estimates of the possible maximum value amount of an output (by assuming it can be no larger than the sum of all originating transactions in its history).

What we seek is a method to make it unknowable which prior transaction outputs were consumed in the generation of a new transaction output. Although it seems a tall order (how can a node validate that a sum of inputs balances a set of outputs when it is unknown which inputs are involved?), a solution actually comes in the form of a ring signature protocol developed for the Monero project.

The ring signature strategy in Monero has gone through two major developmental stages. In the first stage, transaction amounts were not blinded (although pseudo-blinding was achieved by composing value transfers from an aggregate of round-number individual transactions). In the second stage, the ring signature authorization protocol was combined with Confidential Transactions to form the RingCT protocol [2], in which transfers are both value-blinded and untraceable. Since BitShares already implements CT, the adoption of RingCT into BitShares Stealth operations can be seen as an improvement upon an existing feature.

Rationale

Although BitShares is an account-based blockchain, in which value-transfer operations are a simple transfer of balance from one account to another, Stealth operations on the BitShares blockchain instead follow a UTXO model. Stealth transactions produce "transaction outputs" (TXOs) which represent individual balance amounts under the control of someone possessing the appropriate secret key. These TXOs are "unspent" (UTXOs) until they are involved in a downstream transaction, at which point they are considered destroyed and no longer spendable. (To partially spend a UTXO, a transaction consuming it would need to produce two outputs: one to the intended recipient, and one back to the sender as "change.")

A transaction in a UTXO-based blockchain is simply a list of inputs (UTXOs which will be destroyed) and a list of outputs (newly-generated UTXOs). Validating such a transaction involves confirming that the value sum of inputs equals the value sum of outputs plus fees, and that appropriate authorization is provided for all inputs.

Because the list of inputs is part of the transaction, all UTXOs have a traceable history.

Ring signatures are a signature scheme in which, for a given set of credentials, a signature is provided proving that at least one of the credentials authorized the transaction, but it cannot be determined by a third party which credential it was that signed it. Thus ring signatures provide plausible deniability. All involved credentialed parties can mutually point fingers at each other, saying, "it wasn't me."

Ring signatures can provide untraceability in Stealth transactions in the following way: For a given transaction, a set of inputs is collected which is larger than the set needed to cover the the intended transaction outputs. The additional inputs should include inputs for which the spender does not have authorizaton to spend. A signature is provided proving that at minimum enough inputs are authorized to cover the outputs, however an external observer cannot determine which inputs are thereby consumed. Double-spending of inputs is prevented by the provision of a "key image" for each actually-spent input. A key image is a piece of data that uniquly derives from the consumed input, but which cannot be matched to it. A subsequent spend of the same input would produce the same key image, alerting the network to the attempt at a double spend. Now, the set of inputs to any transaction includes not only the actually-consumed inputs, but also a large set of "red herring" inputs, which achieve two important aims for untraceability:

A degree of plausible-deniability for the authorizer of any individual transaction, and
An enormously larger set of prior transactions that form the "history" of the transaction, implicating a much larger set of originating transactions than is actually involved in the true history of the transaction.

It should be noted that one drowback of this scheme is that it is no longer possible to determine which UTXOs are spent vs. unspent, and this has implications for database pruning. However, the Monero chain has been functioning with this limitation for several years now without hitting a performance bottleneck. Additionally, the Monero team has projected that performance growth will keep pace with database size, even absent pruning of spent TXOs. (CITE). (A review of this projection and discussion of its implication for the BitShares chain is in the Discussion section.)

Specifications

(Detailed description of RingCT with annotations for how it would be adapted to BitShares Stealth transactions.) [2]

Discussion

Overview of alternative untraceability solutions

(Compare/contrast with other schemes for providing untraceability, including ZeroCoin accumulators, master-node facilitated tumbling, MimbleWimble, etc.)

Mimblewimble

PRO: Supports a sort of automated, non-interactive aggregate signature scheme (end result similar to CoinJoin), facilitating untraceability at the blockchain level (although not necessarily at the network-snooping level).
CON: Requires communication between sender and recipient.
[Jed2016], [PoelMW]

CoinJoin, CoinSwap, etc.

In [1], Maxwell states "[CT is] compatible with CoinJoin and CoinSwap, allowing for transaction graph privacy as well while simultaneously fixing the most severe limitation of these approaches to privacy (that transaction amounts compromise their privacy)."
- ((This still needs to be researched by this author but I believe these protocols involve mixing with contemporaneous participants, many of whom may be nefarious actors. RingCT allows mixing with historical transactions, and reuse of historical transactions, greatly broadening the set of available mix-in transactions. TODO: confirm this disadvantage.))
Dash (http://dash.org) uses a system of "master nodes" to coordinate an opt-in mechanism of "pre-washing" coins via several rounds of mixing with other participants where each round of washing is a CoinJoin-like process. (https://dashpay.atlassian.net/wiki/spaces/DOC/pages/1146924/PrivateSend)

Accumulator Schemes, e.g. ZeroCoin

Spending a coin into the accumulator produces receipt that can be used to withdraw a coin from the accumulator later. The withdraw operation cannot be linked to the orignal deposit operation. Untraceability os provided by the fact that the "plausible deniability set" of users who might be responsible for the coin is the set of all users who have deposited coins into the accumulators. This can be a very large set.
- Pros:
  - Large deniability set
  - Conceptully simple mechanism
  - Possible to audit supply
- Cons:
  - Depends on a trusted setup, which, if compromised, could allow theft or counterfeit of coins
    - (NOTE: Announcement by ZCoin team of an upgrade that eliminates need for trusted setup) (CITE)
    - [Yap2017], [GrothSigma]
  - Mechanism to transfer coins between users while the coins are inside the accumulator is unclear/unknown (to this author) or impossible. Thus an accumulator may be a good way to wash or hide your own funds, but is not a good solution for creating a balance that one easily use in cash-like user-to-user transactions.

Scaling challenges in a Ring-Sig scheme

(Discussion of the implications of not pruning spent TXOs.)

Summary for Shareholders

Copyright

This document is placed in the public domain.

Abstract

With this paper i propose to make Collaterized trading availalbe with settlement available for both sides anytime. If you are not familiar with Contract for Difference (CDF) you can take a look here https://en.wikipedia.org/wiki/Contract_for_difference

Motivation

I think we should provide more possibilities to our users how they can trade assets on BitShares, and this is a really popular way to do it. The goal of a normal bitAsset is to give one party the abilility to lock some value up and the other party will go long the underlying (most in the cases BTS). With this proposal both parties are just speculating on the rise or fall of the tracked asset.

Rational

Specifications

Parameters we can use and change:

How much collateral do you need to start a trade, this will set the risk profil of a market or the leverage - Percentage of collateral (feedprice/2*percentage)
Percentage of collateral left to get a margin call (percentage/100)
Settleprice away from feedprice ( >= 0 ) (30/100)
-Percentage of splitting fees (20% network/20% FBA/workercontract /50% issuer)
Time to make it possible to settle the position after agreeing on a contract (x hours)

Discussion

An Example:

Bitcoin (BTC) exchangerate is in this example 130.000 BTS starting rate
in this example we will use a 50% collateral (initial) requirement

market rules:

all orders are matched on the feedprice
a trader can choose to settle 1% away from the feedprice
if someone settles the opposite trader with the least collateral will be (forced settled)

Party A wants to short 1 BTC against BTS
Party B wants to go long 1 BTC against BTS

With the BitShares powered CFD trading they will find a market where they can place their orders:

A places an order to short 1 BTC
B places an order to long 1 BTC
they are matched on the feedprice and the collateral is locked on both sides , each 65.000 BTS

The price of 1 BTC to BTS is now moving to 120.000 BTS

The collateral of A is now worth 65.000 BTS + 10.000 BTS from the moved price
The collateral of B is now worht 65.000 BTS - 10.000 BTS from the moved price

B wants to cut his losses low so he dicides to settle his position. In our example party A is forced to settle too, but in a running market the "least" collaterized party on the opposite side will be forced out of his position.

So B settle and he get instantly 55.000 BTS back and lost 10.000 BTS and Party A was settled and gets 75.000 BTS back.

To disuss:

Is it good to settle anytime or do we give something like. For the first 10 days you can not forced out of your position?

Summary for Shareholders

In my proposal i assume we need people who will create markets like "50% collaterized BTC market"

the markets needs feedprices

In this markets the issue can take a fee and we need to split this fees to (network, referral, FBA/worker and market issuer)

Copyright

Abstract

We here propose to optimize the settlement offset and maximum settlement volume of bitUSD to encourage shorters to provide liquidity in the bitUSD:BTS market with a lower risk.

Motivation

Smartcoins are stable currencies and also leverage tools, smartcoin supply can only grow while more and more users select to use this leverage tool, because using this leverage tool means generating smartcoin by shorting with BTS as collateral, and the debt position is possible to be force settled at any time, market participants do not have enough incentive to use the leverage tool and as a consequence smartcoin supply is always in low level. This restricts the growing of relevant economy. We have changed bitCNY parameters and effectively made bitCNY supply grow up, now we propose to do the same change to bitUSD as have done on bitCNY - set a compensation from holder to shorter and lower the force settlement volume limit, these will reduce the risk of shorters and encourage them to provide more bitUSD supply.

Rationale

The force settlement offset can be seen as a service fee that holder pay to the settled shorter at the time of force settlement. The offset need to be set a proper value that can balance the risk of holders and shorters. A 0 offset is not reasonable enough as in common financial logic the collateral should not be force settled without any compensation if the collateral price does not fall below the margin call price; on the other hand, if the offset is set too high, force settlement will be unfeasible as "last resort" for value express. another parameter - the max hourly force settle volume - should be low enough to prevent sudden settlement to force shorters out quickly. experience in bitCNY shows that 1% offset and 0.5% max hourly force settle volume are comparatively reasonable combination.

Discussion

Will bitUSD be "devalued" after this change?

It is our opinion that force settlement is a service. This change is to ask holders to pay a small percentage (1%) fee to shorters when requesting force settlement. currently bitUSD is in low supply and badly pegged, partly because it do not attract enough market participants, If the proposal is accepted by the committee, we can expect more market participants will come and help bitUSD to peg better. after the change bitUSD can be better traded in the regular markets with other assets. it will not be "devalued", "force settlement " is not a common value express way but the "last resort" and should not be used directly to judge the value of the smartcoin.

Should this change be applied to other smartcoins?

Based on the same logic, it makes sense to apply the same change to other smartcoins, but to be enough cautious, it is still proposed to apply the change to only bitUSD this time, one choice is to apply the change to all the other fiat-pegged smartcoins next time. This, however, will require another written proposal and is not covered by this BSIP.

Does this proposal break a promise?

Yes, but maybe not! There were promises made that bitassets can be settled at any time at the fair price (price feed). With this proposal, we ask for a percentage fee for the settlement service. This can be interpreted as breaking a promise while it could also be interpreted as a change in fee schedule: "Settlements are free for the first few months, after that they are 1%".

Summary for Shareholders

Currently, there is no settlement offset which means that longs can settle their position at the price feed. The consequence is that market participants are not selling their bitUSD at the price feed but slightly higher knowing that they could always settle at the feed via settlement.

By asking for a percentage of the settled volume, the premium is assumed to be reduced and bitUSD will be traded more tightly around parity. Since the settlement offset is paid by the long position to the settled shot position, shorters are compensated for providing bitUSD. Because settlements happen on a 24h notice, we expect shorts to adjust their collateral to catch settlement orders and make a profit.

For the long position, the settlement offset appears as if it was a percentage fee for the serivce of settlement after 24h.

Copyright

This document is placed in the public domain.

Port ACCT from Scorum

Apparently Scorum have implemented Atomic Cross-Chain Trading in their graphene chain (apparently a steem fork). We should evaluate and port this to BitShares.
https://github.com/Scorum/Scorum/wiki/How+to+do+atomicswap
https://bitsharestalk.org/index.php/topic,25789.0.html

New BSIP: voting with non-core asset, and asset-specific committee

Currently only CORE can vote for certain things E.G. witnesses, workers and the committee.

It's been demanded by the community for a long time that, holders of other assets can vote with their assets, for things related to those assets.

Another thing is asset-specific committee. Currently it's able to set committee of an asset to top-N holders. I think it would be useful if the committee can be decided by voting.

Update:
Example of asset-specific committee with top-N holders: https://cryptofresh.com/u/stealth-mgmt

Change ownership of CASH.USD and CASH.BTC Smartcoins to committee-account

BSIP: 0018
Title: Change issuer of CASH.USD and CASH.BTC Smartcoins to committee-account
Authors: Jun Dam ([email protected])
Status: Draft
Type: Protocol
Created: 2016-08-14
Discussion: https://bitsharestalk.org/index.php/topic,23010.0.html
Worker: no

Abstract

We at Bitcash propose to have the Bitshares committee custody and control the the CASH.USD and CASH.BTC Smartcoin assets.

Motivation

Several months ago we created CASH.USD and CASH.BTC Smartcoins to provide an alternative to bitUSD and bitBTC primarily because we felt that the current Smartcoin designs were not optimal and could significantly deter adoption. We strongly believe that the Smartcoin designs we have implemented are significant improvements over the current bitUSD and bitBTC designs. However after deep consideration, we at Bitcash have decided that decentralized key management is vital to security and that it is important to implement committee custody of Smartcoins sooner than later.

Rationale

Having alternative Smartcoins with distinct designs in the Bitshares ecosystem is extremely beneficial to the Bitshares ecosystem. Making changes to a Smartcoin design is already contentious and difficult, especially when the Smartcoins are already being used. Any design change with bitUSD or bitBTC could upset existing holders. Some changes in design parameters could improve liquidity whereas others may be detrimental. It is also difficult to isolate the cause of any particular improvement in liquidity because many external factors beyond design parameters affect liquidity. Hence having a couple alternative designs at the same time could increase the chances of success and expedite mainstream adoption. Dan Larimer has mentioned the experimental nature of Smartcoin parameter designs and purposely created Privatized Smartcoins to allow competition and even give companies an opportunity to monetize a good design. However our intent has always been to create an optimal design to benefit the Bitshares ecosystem. The best designs will attract the most participants, businesses and liquidity. Even small changes in parameters can make a significant difference.

Currently there are proposed changes to bitUSD under BSIP #17. We support those changes and should make it somewhat closer to our CASH.USD design. However the reduction of forced settlement from 20% to 0.5% per hour is not enough. CASH.USD does not have forced settlement. Furthermore the Maximum Short Squeeze Ratio for both bitUSD and bitCNY remain at 110% instead of 100.1% for CASH.BTC and CASH.USD. At this early stage of adoption, experimentation with more than one Smartcoin design is important.

Background

Our Smartcoins are defined to be worth the same as the corresponding asset. Hence one CASH.USD should trade for $1 and one CASH.BTC should trade for one bitcoin. Companies like Bitcash are expected to maintain bridges to support the 1:1 exchange or place orders at the price feed when necessary to reinforce the price feed and provide CASH.USD and CASH.BTC holders the ability to liquidate at the price feed when necessary. The price feed determines the social consensus of what amount of BTS is equivalent to $1 or 1 bitcoin at any given time. Currently we use witnesses to provide the price feed. All the parameters are designed to support the social consensus that the value of CASH.USD is equivalent to one dollar and the value of CASH.BTC is equivalent to one Bitcoin.

Differences compared to bitUSD and bitBTC:

Merchants or CASH.USD holders will not have a price floor guarantee. If merchants/holders do not have a gateway or buyers that will exchange a CASH.USD 1:1 for a dollar, they may have to exchange it for BTS and may get more than or less than one dollar when selling BTS.
User forced-settlement will be disabled to protect CASH.USD creators. Any user can create CASH.USD and will not be burdened with the uncertainty of being manually force-settled and should be comfortable creating and maintaining a long-term supply of CASH.USD. Creators of CASH.USD will only be force-settled when they are undercollateralized.
The maximum short squeeze price is set at 100.1% so that when creators who borrow CASH.USD into existence are margin-called, the settlement price will be at the price-feed.

Parameters:

MSSR: 100.1%
MCR: 175%
No forced settlement
Witnesses provide price-feed

Theory:

All fiat dollars are treated the same even when they are distinctly different. Just think about the the qualitative difference between coinage, checkbook money, federal reserve notes, and digital dollars from Venmo/Square Cash/Paypal. The reason such varied forms of money are treated as equivalent is because there is a social consensus of dollar equivalence. Without a social consensus, digital dollars may be traded for more than a dollar for its convenience, and coinage less than checkbook money for its inconvenience. However most everyone treats any form of the dollar the same.

Banks create checkbook money, the dominant part of M1 money supply, out of thin air and allow this money to circulate in the economy. Usually banks use real estate assets as collateral to create monetary assets. These monetary assets aka debt-money aka checkbook money are merely accounting entries, but they are treated the same as federal reserve notes (green paper dollars in your wallet) or coins. Again there are distinct qualitative differences between checkbook money, federal reserve notes & coins. The current Bitshares system functions precisely the same way as banks, but instead of real estate, BTS is used as collateral.

Banks create debt/checkbook money that are defined to be dollars, and the real estate collateral that backs this money can fluctuate in value. As long as the real estate value is greater than the value of the money banks create, banks are not concerned. In the Bitshares ecosystem, members can create an equivalent type of debt/checkbook money on the blockchain when they create CASH.USD (or borrow CASH.USD) into existence using BTS. Hence there should be no difference between the checkbook money banks create in the current banking system compared to the CASH.USD that members create on the Bitshares system as long as the social consensus defines both types of debt-money to be valued as dollars.

What if someone trades CASH.USD for something other than a dollar? In a free market someone can trade three quarters for one federal reserve note or a one dollar check, but that doesn’t mean trading three quarters for a dollar is part of the social consensus nor should a number of bad trades dictate what the social consensus is. Hence as long as there is no external reason or design parameter that would lead one to believe CASH.USD is worth anything other than a dollar there will be a social consensus that it is. The current CASH.USD design should support this reasoning.

Specification:

Account owner of bitcash-reg will change the issuer designation of CASH.USD and CASH.BTC Smartcoins from bitcash-reg to the committee-account.

We do recognize that in doing so the committee will have control over future parameter changes. However we would like the committee to acknowledge and uphold the principles of our alternative design, namely: 1) the forced settlement feature is to remain permanently disabled (bitcash-reg may permanently disable before transfer ) 2) the maximum short squeeze ratio is to be as close to 100% as possible so under-collateralized settlement will be sold as close to the price feed as possible. These parameters are foundational to the success of CASH.USD and CASH.BTC and key to their designs.

Discussion:

Will having two Smartcoin assets be confusing for users?
Bitcash will independently promote CASH.USD and CASH.BTC. Any other company or user can choose to do the same. It will just be one of the many tradeable assets among the many Smartcoins and UIAs. Although having too many Smartcoin options may be confusing, having just 2 or even 3 variations is worth any minor inconvenience.

What maintenance or changes should the committee expect in the future?
There should be very little maintenance other than keeping the fee pool balance funded. The parameters for the Smartcoins are based on the principles stated above and should require little to no changes going forward.

Summary:

We propose to have the Bitshares committee custody and control the the existing CASH.USD and CASH.BTC Smartcoin assets. Our main motivation is to decentralize ownership of these alternative Smartcoins. The transfer of ownership should require no action from the Bitshares committee and will only require the committee to keep the fee pool funded after the change in ownership of the asset. One CASH.USD is defined to be equivalent to a US dollar and expected to be traded 1:1 excluding fees by social consensus. One CASH.BTC is defined to be equivalent to one Bitcoin and expected to be traded 1:1 excluding fees by social consensus.

Copyright

This document is placed in the public domain.

bsip28 lacks of determinate technical specification

The specification of BSIP's should be determinate, wording like "Possibly allow" is not acceptable.
I don't think committee should have the right to terminate a worker proposal.

New BSIP 0050: Stealth development, Phase II

(From: https://github.com/Agorise/bsips/blob/master/bsip-1200.md)

BSIP: 1200 (unassigned)
Title: Stealth development, Phase II
Authors: Christopher J. Sanborn <...>
         Agorise, Ltd. <[email protected]>
Status: Draft
Type: Informational
Created: 2018-01-29
Discussion: <https://t.me/Agorise>

Abstract

To discuss the continued development of Stealth functionality and provide an overview of the following BSIPs which define components of that development.

Component BSIPs: (Works in progress!!)

Number	Title	Type	Status
1200	Stealth development, Phase II — (this document)	Informational	Draft
1201	New operations for Confidential Asset (CA) transactions	Protocol	Draft
1202	Untraceability solutions for Stealth transactions	Protocol	Draft
1203	Detection of inbound Stealth transactions	Protocol	Draft
1204	Deterministic addresses for Stealth wallets	Informational	Draft
1205	Metadata hiding via Garlic Routing and other means	Informational	Draft

Motivation

The initial phase of Stealth development was proposed and implemented in BSIP-0008, and is live on the BitShares network. Support for this first round of confidentiality features has been implemented in the CLI wallet, and has also been demonstrated in the UI wallet by Agorise, Ltd., in a code fork not yet integrated into the mainline UI-Wallet code. Utilization of the privacy features remains low, for two reasons: (1) the difficulty of using the CLI wallet for day-to-day activities, and (2) the Stealth feature set thus far, while valuable, does not yet provide a comprehensive privacy solution.

Phase One of Stealth development consisted of the implementation of Confidential Transactions (CT) [1], which was initially proposed for the Bitcoin network in a paper by Greg Maxwell. CT provides two key features: value-blinding, and stealth addresses. Value-blinding means that the value amounts of transactions are unknowable except to the parties of the transaction (provided the transaction is sufficiently removed from the operation that initially converted a public balance to a blind balance). Stealth addresses are an address format that the sender can use to derive a "shared secret" public key for which only the recipient can derive a private key, without revealing publicly that the stealth address and the public key used to transmit the funds are related. The use of stealth addresses helps to anonymize transactions, however it creates a burden of communication between the sender and the recipient, who must be made aware of the existence of an inbound transaction.

Stealth addresses also provide partial unlinkability, or the inability to "link" balance elements (we'll call them UTXOs for Unspent Transaction Outputs) together to see that they are controlled by the same party. However, wallet implementations may, in order to facilitate discovery by the receiving party, publicly embed the stealth address of the receiving party into the transaction, thus breaking unlinkability and threatening anonymity. Heretofore, no privacy-preserving method has been proposed on this network to enable discovery, other than the sender and receiver being in direct communication off of the blockchain (e.g. sending transaction receipts). Furthermore, CT transactions are traceable, meaning that a transaction reveals which UTXOs are consumed in the creation of new UTXOs. This has two implications: (1) a transaction history can be constructed, and it may be possible to establish a vary narrow set of originating users who initally "blinded" a previously public balance, thus potentially establishing to a high degree of probability who is involved and how much value is involved in a particular sequence of transactions, and (2) a user spending a balance consisting of more than one UTXO will of necessity reveal that those UTXOs are controlled by the same party, or "linked," thus again breaking unlinkability.

In what follows we propose methods of enhancing the confidential abilities offered by the BitShares network by integrating specific solutions to achieve unlinkability, untraceability, and automated transaction discovery by the receiving party. Additionally, since BitShares is a multi-asset blockchain, we propse to adopt Confidential Assets (CA). CA is an extension to CT that hides not just the values of a transaction, but also the assets involved. Further, we propose various convenience and user-experience enhancements to ease the backup burden placed on users and reduce the chances of lost funds. Lastly, we propose an ongoing effort to harden wallets and p2p nodes against metadata leaks.

Rationale

We view "Stealth" as a constellation of features providing robust privacy and "grandma-friendly" usability and reliability. A user of Stealth transactions should be reasonably assured that their privacy is complete, and not underminable by easy-to-make procedural mistakes.

"Blinded" vs. "Stealth"

To facilitate an orderly, confusion-free upgrade, and to differentiate between Phase One and Phase Two functionality, we have adopted the convention of referring to the existing CT transactions that only blind transaction amounts as Blind Transfers, and the proposed more fully-private transaction features as Stealth Transfers. The names convey that Stealth Transfers will be more private than Blind Transfers (although some user education will be needed on this). Upon maturity of the Stealth feature set, the utilization of Blind transfers should be retired.

Specific features and enhancements

Specific features and enhancments proposed by this and associated BSIPs are as follows:

Asset Hiding

Confidential Assets (CA) [2] extends Confidential Transactions (CT) to include asset hiding. Existing CT functionality can hide the value amount of a transaction, but the asset being transfered is publically visible in the transaction format. Since BitShares is a multi-asset blockchain, it would be of value to hide not just the value but also the identity of the asset involved. CA provides a method to do this. The proposal to implement CA on the BitShares network is in BSIP-1201.

Unlinkability and Untraceability

While BitShares is an account-based blockchain, similar e.g. to Ethereum and others, Stealth operations on the BitShares network follow a UTXO model, similar to BitCoin and related blockchains. UTXOs (Unspent Transaction Outputs) are discrete balances held in the "outputs" of transactions. A user's total balance is composed of the sum total of all UTXOs that fall under their control. A Stealth transaction consists of the destruction of one or more existing UTXOs and the creation of one or more new UTXOs. CT guarantees that the values of the outputs are unknowable (except for deductions that can be made if one happens to know, precisely or approximately, the values of the inputs). However, the current implementation of CT provides no privacy regarding which UTXOs are used as inputs to the transaction. Because of this, current CT transactions are fundamentally traceable and linkable. Traceable means that a history of prior inputs can be constructed, "tracing" where an output came from, and if the history is short enough (refering to how many prior UTXOs one must traverse before finding an operation where a public balance was converted to a blind balance) then it may be possible to reveal involved parties and estimate transaction values. Linkability refers to the ability to show that a set of UTXOs are controlled by the same party, or that a set of disparate transactions were conducted by the same party. Although the latter is well protected due to non-reuse of public keys, the former is implicated by CT. A CT transaction consuming multiple inputs necessarily reveals that all inputs are controlled by the same party, and if anonymity has been compromised for one input UTXO, then it is effectively compromised for all of them.

To solve the problems of linkability and traceability, we propose to take a page from the Monero project. The Monero network uses a system of ring signatures to create a high degree of plausible-deniability as regards who exectuted any particular transaction [3]. A ring signature is an n of m signature scheme wherein the set of inputs to a transaction is much larger than the set of inputs actually consumed by the transaction, and the signature provided guarantees that the correct party signed the transaction, but makes it impossible to know which party is the signer. With a Monero-like ring signature scheme, it is no longer possible to determine which UTXOs are "spent" vs. "unspent" (a mechanism to prevent double-spends does exist, of course). This means that it is no longer possible to construct an exclusive directed graph if inputs to outputs, thus providing untraceability and unlinkability. (More specifically, the set of inputs that might be in the history of a particular output rapidly becomes so large that it is no longer possible to say with significant probability that any particular party was involved.)

We propose and discuss the implementation of ring signatures for Stealth transactions in BSIP-1202.

Scanning for Inbound Stealth Transactions

The current implementation of CT requires that a sender must communicate to the recipient a "transaction receipt" that contains, in encrypted form, data that the recipient needs in order to take possession of a transaction output. This is burdensome, and implies a high risk of lost funds as a result of lost or uncommunicated receipts.

We propose automated, privacy-preserving methods of scanning for inbound transactions in BSIP-1203.

Backups of Stealth Balances

In BSIP-1204 we propose standardized derivation of Stealth addresses to enable backup seeds or brainkeys to be used to securely back up a Stealth account prior to first use, enabling recovery in the event of a lost or corrupted hot wallet.

Metadata Hiding

Lastly, in BSIP-1205, we propose methods of hardening wallets against eavesdropping and timing attacks, so that usage patterns and the method used to communicate with the peer-to-peer network do not compromise user privacy. (As an example, a naive wallet might check a users balance by querying the status of a set UTXOs under the user's control, revealing immediately to the network that a given set of UTXOs are "of interest" to a single party.)

Specifications

Discussion

Summary for Shareholders

Copyright

This document is placed in the public domain.

Abstract

Currently the Annual Membership (AM) price is set globally by the committee and there is a 50% cut reserved for the network. The remaining 50% goes to the registrar and the referrer (the split between them is defined by the registrar).

This arrangement is not flexible. A registrar targeting price-sensitive customers is limited by the minimum price required by the network. The purpose of this proposal is to remove this limitation and allow a registrar (i.e. hosted wallet service) to offer very low transfer fees by selling AM at any price the customers are willing to pay (including the price of zero).

What is proposed here, is a very simple change: the price of AM to be determined not globally by the committee but locally by the regional registrars (i.e. hosted wallet services). This way, in regions requiring low fees, AM can be given away for free (or almost for free), which translates into access to extremely low transfer fees, as an AM means 50% discount on those fees for its holder.

Motivation

The primary motivation of this proposal is to reconcile two opposing interests:

Allow BitShares to become competitive on markets which might require very low transfer fees.
And at the same time preserve those two important aspects:
- preserve the default transfer fee at the current level (i.e. around $0.10), which is high enough to support the referral program, as it was initially announced in June 2014,
- preserve the network's income stream at the current level.

Rationale

By allowing the AM price to be determined locally be the registrar, effective transfer fee can be easily slashed by 50% by selling AM at a very low price or giving it away for free to all newly registered accounts.

To align the network's interests with the registrar's interests, we propose to make the network's income proportional to the registrar's income from AM sales but not bigger than certain threshold defined by the committee.

Specifications

The committee sets two values:
(a) Maximum Income MI - it's the maximum income the network would like to receive from each AM sold,
(b) Network's Share NS - it's the network's share in the registrar's income from AM sales.
The registrar is obliged to share with the network NS of its income but not more than MI. In other words, the network gets the smaller value of these two: MI and NS * AM price. Thus it's not guaranteed to receive MI, but this mechanism will attempt this, if the AM price is high enough.
The price of AM is determined by the registrar who has originally registered a given account. When registering a new account, the registrar sets the future price of AM in terms of percentage of MI.
The split between the registrar and the referrer is defined by the registrar, as we have it now.

Let's consider two examples to illustrate how it works:

Example I

MI = $4.00
NS = 50%
AM price = 300%
referrer share = 60%

AM price for the customer is $12.00 [= 300% * $4.00].

the network gets $4.00 [= min($4.00, 50% * $12.00)]
the business gets $8.00: the registrar gets $3.20 and the referrer gets $4.80

Example II

MI = $4.00
NS = 50%
AM price = 20%
referrer share = 80%

AM price for the customer is $0.80 [= 20% * $4.00].

the network gets $0.40 [= min($4.00, 50% * $0.80)]
the business gets $0.40: the registrar gets $0.08 and the referrer gets $0.32

Discussion

This is the most crucial question: if the price of AM has no lower limit, how can we make sure the network's income is preserved? Will there be lost revenue for the network as a result of this proposal?

We must all agree, that a revenue can be considered as lost only when a user ends up paying less than s/he was willing to pay. Otherwise no revenue is actually lost, because no sale would have happened anyway.

If there was a perfect competition between hosted wallet services, the issue of lost revenue could have some ground, as the price of AM would be constantly undermined by the market participants. However, it will take a long time for the BitShares ecosystem to reach this state and by the time this state is eventually reached, the referral program will be redundant anyway and this mechanism will no longer be needed.

The main assumption we make is that a registrar is a business-oriented entity aiming to maximize its profits. Thus it will utilize the opportunity of selling AM very cheaply or for free, only if it operates on a market where an average user is not willing to pay a better price. This way the price of AM is naturally adjusted to the average price acceptable by customers on a given market. On some markets this value can be close to zero, but most of those customers, who will acquire AM for zero, would not have bought this subscription for any other price, so no income is actually lost.

The other assumption we make is that if a registrar offers a reasonable price for AM (e.g. $5), most customers are not going to be bothered to hunt for a better bargain and then attempt to migrate their accounts. For most customers, money saved this way is not worth the effort. This is especially true for shorter subscriptions.

Copyright

This document is placed in the public domain.

Smartcoin Design Improvement

While Smartcoins are powerful with its stability, its mechanism is flawed against the issuers. More specifically, issuers only benefit when BTS price is rising, regardless of popularity of Smartcoins (e.g. large number of transactions per day). Meanwhile, profits generated from using Smartcoins via fees are diluted to the whole network and this yields the free-rider problem.

My proposal is basically to directly benefit the issuers when Smartcoins are used. This will make another profit source in addition to BTS price change. More specifically, my suggestion is:

Divide fees from using Smartcoins (e.g. transfer fee) into the network and the issuers (currently 100% goes to the network and be burnt). When 100% goes to issuer, there would be an attacking vector to spam the network.
If fees are paid in BTS, add them to a Smartcoin's collateral pool so the issuers can return more when they clear debt.
If fees are paid in a Smartcoin, reduce the debt pool so each issuer have less debt.
By doing so, businesses using Smartcoins are more incentivized to issue and facilitate using Smartcoins, and when issuing Smartcoins become profitable regardless of BTS price (e.g. profits from fees exceeds losses from BTS price fall) more people are willing to issue Smartcoins, and consequently more BTS is locked and will start the virtuous circle.

BSIP 23 & 24 filenames are incorrectly upper case

The filenames are uppercase BSIP, so the readme link goes to a 404.
Should I submit a PR, or can the repo admin help me out?
Thanks

bsip#11: on demand voting

@bytemaster created another bsip. However, I removed it from the directory since it simply doesn't fit our format (yet)

The purpose of this BSIP is to minimize the cost incurred by the network
doing unnecessary operations every maitenance interval.

Every hour votes are tallied and 99% of the time there is no meaningful
change. Under this proposal, votes would only be tallied when requested
by a user and at most once per maitenance interval. The fee for
talleying votes would be around $5.

Users of the system can determine whether or not there is a $5
difference in votes that would justify a retally. A worker, witness, or
committee member who got voted in would pay $5 to have the vote counted.

The side effect of this behavior would be to greatly improve reindexing
performance, the vast majority of which is spent tallying votes that
never change.

Witnesses producing blocks on the maitenance interval can pre-tally the
votes and compare them to the last value. They can then indicate whether
or not anything changed significantly in the block they produce.  

If there is no one who stands to benefit by more than $5 then chances
are it is an unnecessary update to the voting totals.

Future settlement of orders across future blocks

A futures market where assets are bought/sold and then released on the settlement date can provide a good amount of liquidity to the market. This is especially true for Smartcoins, where speculation is essential to keep the price pegged to the underlying asset.

A true free-market (where there no is learning curve to use the Futures vs. the current implementation) completely eliminates the need to lock up more collateral than a 1:1 ratio. This is because the Futures market acts to "stabilize" the current market, because future volatility is inherently built into the market itself.

This stability leads to a reduction (elimination?) of "Black Swan" events with the following situation:

In BitShares, if there is not enough current liquidity on either the buyer/seller side, a “black swan” event occurs, where collateral is destroyed in the opposite direction to allow the price trend to reverse. This can happen if the underlying asset (BTS for example) is falling so quickly, that no one even wants to lock up their BTS into a smart contract and would rather sell it.

With the allowance for asset settlements that take place in the future, someone can see that the price of the backing asset may be currently falling rapidly (where there is a risk of a black-swan event), but can openly see that the market expects a strong rebound in 30 blocks. Therefore, they are comfortable locking up some BTS now in anticipation of future upward price movement. This leads to market-stability as this "Buy" order puts upward pressure on the price.

New BSIP: Implement Buy Limit Order

BSIP: <BSIP number>
Title: Implement Buy Limit Order
Authors: Abit More
Status: Draft
Type: Protocol
Created: 2017-11-02
Discussion: https://github.com/bitshares/bitshares-core/issues/342
Replaces: <BSIP number> (optional)
Superseded-By: <BSIP number> (optional)
Worker: <Id of worker proposal> (optional)

Abstract

By now, in BitShares, since all markets are flip-able, all limit orders are implemented as sell limit orders. When a user placing a buy order via GUI, actually it's placed as a sell order in the flipped market. Although usually a flipped sell order is very close to a buy order, their behaviors are a bit different, as a result, this has led to some confusion. This BSIP proposes a protocol change to address this issue.

Motivation

Make the exchange more user-friendly.

Rational

A typical exchange should have both buy limit order and sell limit order with different behavior.

Specifications

[WIP]

A limit sell order means a user set a minimum price and an exact amount of one asset (which she owns) to sell, expecting all of them to be bought, and expecting to get at least amount*price of the other asset (which she doesn't have). It's expected and acceptable that she will get more than she wanted when there are better offers in the market.

A limit buy order means a user set a maximum price and an exact amount of one asset (which she doesn't have) to buy, and willing to pay at most amount*price of the other asset (which she owns). It's NOT acceptable if she finally got more than she wanted, instead, it's expected and acceptable that she will pay less when there are better offers in the market. When the order is partially filled, if the remaining fund is not enough to pay for the rest desired amount on next match, the order should be cancelled.

All above are talking about taker orders, when placing the order, there may be better offers on the order book already. For maker orders, usually the owner won't get a better offer, unless caused by rounding.

Discussion

Summary for Shareholders

Copyright

This document is placed in the public domain.

Abstract

With current design, when creating an asset, the issuer is forced to put half of creation fee into the new asset's fee pool. This means the issuer need to have double amounts of BTS to be able to create an asset. If the issuer don't want to use the fee pool, she need to sign additional transaction(s) to get out the fund from the fee pool. This BSIP proposes a protocol change on this feature.

Motivation

Make the asset system more user-friendly.

Rational

Specifications

In asset_create_evaluator::pay_fee(), don't halve core_fee_paid
In asset_create_evaluator::do_apply(), don't add funds into the new asset_dynamic_data_object's fee_pool field.

Discussion

On the other hand, forced fee pool funding on asset creation brings more use of the fee pool feature.

If this BSIP is implemented, it's expected that asset creation fee listed in the fee schedule should be halved.

Summary for Shareholders

Copyright

This document is placed in the public domain.

bitshares / bsips Goto Github PK

bsips's Introduction

BitShares Improvement Proposal

Available BSIPs

bsips's People

Contributors

Stargazers

Watchers

Forkers

bsips's Issues

Abstract

Motivation

Rational

Specifications

The assumptions

The concept

The main issue

How is the issue solved?

This is an opt-in feature

Discussion

Copyright

Abstract

Motivation

Rationale

Specification

Discussion

Copyright

Purpose

Preface

Problem Statement

Solution Proposal 1

Pros

Cons

Solution Proposal 2

Pros

Cons

Solution Proposal 3

Pro

Con

Solution Proposal 4

Pros

Cons

Initialization

Conclusion

Abstract

Motivation

Rationale

Discussion

How to make sure that the witnesses will and really do more after the payment increase? Can we set some standard to qualify active witnesses?

Why not separate the block production service and price feeding service?

Summary for Shareholders

Copyright

Should we require UIA owner permission to use UIA as backing collateral for an MPA?

Why I think we should require permission

Why perhaps we shouldn't require such permissions

Exclusions:

Abstract

Motivation

Rational

Specifications

Current Design and Implementation

Proposed Changes

Discussion

Summary for Shareholders

Copyright

See Also

Abstract

Motivation

Rational

Specifications

Current Design and Implementation

Proposed Changes

Discussion

Summary for Shareholders

Copyright

See Also

Relevant threads

Sections of the BSIP which require developer input

TODO

Abstract