Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - bytemaster

Pages: [1] 2 3 4 5 6 7 8 ... 42
General Discussion / Looking for Deposit Tutorial for OPEN.BTC
« on: April 04, 2016, 09:25:27 pm »
I am looking for someone to create a step-by-step guide with screenshots on how to deposit OPEN.BTC into your BitShares account.

These instructions will be used as part of a marketing push for STEEM that will direct users to BitShares which will start out as the exclusive exchange where STEEM is traded. 

If we play this right BitShares can ride the STEEM publicity and we can get some new traders into the exchange.

Having exclusive assets that people want to trade is one of the best ways of bootstrapping BitShares.

Ideally the guide would be done in MARKDOWN.

General Discussion / STEALTH Status Update
« on: April 04, 2016, 05:33:54 pm »
I want to take a moment to give everyone an update on where we are with STEALTH.

The hardfork today will allow us to transfer the STEALTH asset to [member=49]onceuponatime[/member] and the blockchain will be fully functional from that perspective.

The GUI release here: implements an interface and set of functionality that we outlined in the proposal. 

The server-side wallet storage was not part of the proposal, but something we felt was necessary to backup/secure user funds. We do not yet have confidence in the reliability of server-side storage to enable this feature. There is a significant about of liability associated in offering to host/backup user wallets.  We don't want to be responsible for the loss of funds.

With todays hardfork and enabling of the fee-backed-asset along with the windows binaries we will release the STEALTH worker will technically be completed to spec. We were late and over budget so have actually lost money on this worker.

That said, I am not happy with the resulting product and user experience. It is still too hard to use for most people and therefore, it is reasonable to expect few will use it. 

In an effort to make things right for everyone, especially [member=49]onceuponatime[/member], we intend to implement an alternative in the months ahead:

Blind Transfers with Public Accounts

In this mode everyone will be able to tell which accounts are transacting with each other, but be unable to know the amounts involved. The impact is that you would be able to tell if someone sent money to an exchange, but would be unable to know how much. Furthemore, your
account balance would be completely private.

With this mode of operation it is possible to make blind transfers the default mode of operation while maintaining the same interface we have for normal transactions.  A simple checkbox can be used to enable public/free transfers.

This interface will generate many more STEALTH transfers and improve everyone's privacy while at the same time enabling the holders of the STEALTH asset to make more revenue.

We cannot promise a particular schedule for this enhancement, but will state that we intend to work toward it. We want to make sure that people can actually use privacy enhancing features and that [member=49]onceuponatime[/member] has a reasonable chance to recoup his investment.

General Discussion / GUI 2.0.160330 Released
« on: March 31, 2016, 12:58:00 pm »


Proposed transactions
Add a 'Reset settings' button to Settings and InitError page
Split workers table into proposed and active workers
Remove negative votes
Add set of known proxies, add lists of active witnesses and cm's to voting pages
Add name replace for asset symbols in fee selection dropdown
Improve worker approve/reject logic and add status coloring
Add explanation of vesting balances
Add memo support to asset issue modal and display memos in Operation/Transaction


Language settings not persisting in light client
Fix some bugs and typos in AccountStore authority check
In serializer for transactions, sort addresses and public keys in descending order
Handle nested authorities for hierarchical multi-sig
Set new accounts voting proxy to 'proxy-to-self' account #700
Improve RecentTransactions sorting function #793
Add Settings link to mobile menu #759
Make sure negative votes are removed when updating votes #798
Fix vesting balance styling #722
Fix init loader white background
Fix orderbook onClick not syncing after order has filled #768
Translate csv and tooltip and move closer to title #780

General Discussion / Looking for help with Social Media
« on: March 30, 2016, 01:15:35 pm »
We are looking someone who would like to take over day-to-day management of the BTS Social Media (Facebook, Twitter, etc). 

If you have skills in this area and think you can improve things post here for community feedback.  Let us know how you would run them.

General Discussion / Testing Stealth UI
« on: February 29, 2016, 07:36:31 pm »
Anyone who would like to experiment with stealth UI please post in this thread:

To get started, create an account on the test network.
Then go to settings and enable multiple account mode.
Then go to dashboard and create private account
Then give someone your public key.. or get someone else's public key
Then add public account (with their public key)

Private accounts are indicated via a "~ACCOUNTNAME" in the transfer to/from field.  These accounts are not registered and are just local labels.

I have identified some major usability issues that we are going to address...

Some issues I found...

1. It should ask you to unlock prior to asking you to select a new account name rather than failing after you enter an account name because the wallet is locked.
2. Truncating the public key behaves poorly and unexpected when you click on it (we will remove the truncation)
3.  Clicking on a blind account should take you to the transfer page with the "from" already filled in
4. All account balances of from account should be displayed above the history
5. There is no way to recover past transfer receipts after you close the dialog, be sure to copy the receipt and give it to the person you are sending funds to.

This is the minimum interface to get things functional and does not represent what I consider to be a "finished" feature. 

General Discussion / Trustless, Decentralized Bond Market Draft
« on: February 28, 2016, 04:18:26 pm »
The challenge is to create a bond market where lenders can earn interest while being 100% protected against default by the borrowers. This means that at all times the blockchain must be able to cover all loans on the market.

This is difficult because it is computationally expensive to calculate the cascade effect of multiple margin calls and this must be done after every market operation.

The Solution

Someone who wants to borrow an asset may do so as long as there exists enough orders on the book to cover their new position and all other open loan positions at the price of  the least collateralized loan’s DEBT to COLLATERAL. The least collateralized loan establishes what we call the SWAN PRICE, short for black-swan. 

Every time a limit order is created, filled, or canceled the blockchain updates a running total of how much of a given asset is available for sale above the SWAN PRICE.

Every time a loan position is updated and a new SWAN PRICE is established, the blockchain must also update how much of a given asset is available for sale above the SWAN PRICE.

Basic Algorithm

Code: [Select]
    Let TAS = Total asset for sale above swan price.
    Let TD   = Total asset that has been borrowed

    onOrderUpdate   /// create, cancel, fill
          push undo state
          create, cancel, or fill orders on the book
          update TAS
          if( TAS < TD )
                undo changes and throw
          commit changes
          execute margin call on least collateralized loan
          goto try

Someone looking to borrow an asset makes a request of the network that includes:

1. how much they wish to borrow
2. how much collateral they wish back it with

The borrowing request will be filled so long as they post sufficient collateral. The network will automatically bump lower collateralized positions if necessary.

A margin call can happen for any of the following reasons:
1. If canceling an open order would result in insufficient orders on the books to buy back the debt with the collateral, then a margin call is executed first, then the order is canceled (if it wasn’t used as part of the margin call).
2. If filling an order would result in insufficient orders on the books to satisfy all debt at the SWAN PRICE, then the margin call is executed first.
3. If someone is looking to borrow, offering more collateral than the SWAN PRICE, and there is insufficient orders above the SWAN price then the least collateralized position is called. This will update the SWAN price to the next best.

The impact of these rules is the following:

1. The least collateralized position is always at risk of margin call when there is more demand for loans than orders on the book.
If there are more orders on the book than demand for loans, then collateral requirements can fall and the least collateralized position is safe from potential margin call

2. The ability to move an order, rather than cancel and create a new order must be supported to prevent unnecessary margin calls.
Borrowers will post sufficient collateral to ensure sufficient market depth that they are not at risk of being called.

3. Increasing collateral lowers SWAN PRICE and increases the number of orders above SWAN and thus increases SUPPLY of asset to be borrowed.
Interest Payments

4. Everyone with an open order on the books above the SWAN PRICE is effectively lending money to those who wish to borrow. If there is heavy demand for borrowing then the market response should be to pay interest to the lenders.

In this algorithm, the network charges a “fixed” interest rate on the variable collateral. In this way the interest charged to borrowers grows along with the collateral requirement. Every open order on the books above the SWAN PRICE receives their pro-rata share of the interest paid by borrowers.

Lenders have the ability to “set their interest rate” and “collateral requirement” based upon the price at which they leave their order open on the book. If demand for loans grows enough to find the least collateralized loan  (SWAN PRICE) to be above the order price, then the loan is executed and the lender starts earning interest. If the SWAN PRICE never reaches the order price then the loan is not accepted and no interest is paid.

The impact of interest is to increase the number of orders on the book above the SWAN price which in turn serves to reduce collateral requirements.

The “fixed” interest rate can be configured by the asset issuer. If collateral requirements start to get unreasonably high, then interest rates can increase.

Feedback Wanted

General Discussion / Light Weight Market Status Page
« on: February 26, 2016, 08:40:22 pm »
I am looking for someone to put together a nice "market status" that loads "instantly" rather than with a delay.

It should be able to display any market pair on BTS and show the price history, order book, and market depth chart.

Ideally it would be on something like

It should work with server-side rendering and not require downloading 2MB of JS.

General Discussion / STEALTH Status Update
« on: February 25, 2016, 04:00:03 pm »
Now that the hardfork has gone through we are preparing to update the permissions on the STEALTH asset and distribute it to Onceuponatime.

We had a slight delay caused by a bug in our testing framework that was preventing us from testing the asset update transactions prior to broadcasting them on the BTS network.

Valentine and James are preparing a beta GUI that the community will be able to test later today or tomorrow.

If everything goes smoothly, we can merge the beta GUI into OL a week later. 

General Discussion / How much did Stellar and Ripple give new users?
« on: February 23, 2016, 11:26:48 pm »
I am curious how much Stellar and Ripple paid each user who signed up on their platform.

I am particularly interested in the dollar value they gave away.

General Discussion / Looking for Most Concise Rationale For SmartCoins
« on: February 23, 2016, 05:41:51 pm »
I am looking for help producing a concise rationale for why SmartCoins are needed, what makes them unique and special.  What makes them secure.  I would like to consider the following rules for describing this:

1. We shouldn't talk about HOW they are created (don't mention collateral, market, etc)
2. We should talk about why they are more secure than bank deposits.

A quick list of all implementations of "smart coins" and how they achieve meet the criteria of being special and better than IOUs. 

I guess a SmartCoin is NOT an IOU and thus NOT a liability of anyone else.  How can we express this in a POSITIVE form, ie: define what it is without saying what it isn't? 

General Discussion / Subsidizing Market Liquidity
« on: February 19, 2016, 09:04:16 pm »
I would like to propose a new feature for BTS that CNX will provide free of charge if a hard fork is approved.

We would like to allow any market pair to reward users who provide liquidity in that market. The feature would work as follows:

Every order that is filled after being open on the books for at least 10 minutes earns shares a reward pool. The shares earned are proportional to the size of the order filled.

Any user *or* worker can contribute funds to the reward pool. These funds can be denominated in any asset specified by the issuer.

At most once per day users may convert their shares in the reward pool to a pro-rata share of the rewards.

The asset issuer has the ability to enable this feature for any market their asset trades in and to specify the asset used to fund the reward pool.

With this feature Open Ledger *could* pay out OBITS to those who provide liquidity in the OPEN.BTC / BTS market.
BTS can vote for a worker to provide liquidity in the BTS / USD and BTS / CNY markets.

It is possible that trades in the BTS / OPEN.BTC market could earn rewards from both BTS and OBITS *if* shareholders voted to subsidize this market.

Assuming we implement this feature in the BTS / USD market and voters approve workers funding this at a rate of 2.5 BTS / sec (50% of allowed dilution) and the internal exchange had $100,000 of daily volume then users trading on the internal exchange would see a 1% more than they would get by trading off chain. If daily volume was $50,000 then they would see a 2% profit over doing the same trades off-chain.

The impact of this should be a major influx of new traders who can make more money trading on the internal exchange than the external exchange. This added liquidity will dramatically tighten the USD / BTS peg and give shorters much more confidence.

This implementation will require 3 new operations on the blockchain:

1. create_liquidity_reward_pool issuer ASSET FUND_ASSET MARKET_ASSET    ie: openledger OBIT OPEN.BTC OPEN.USD
2. fund_liquidity_reward_pool funding_account AMOUNT FUND_ASSET ASSET MARKET_ASSET
3. claim_liquidity_rewards username AMOUNT FUND_ASSET  ASSET MARKET_ASSET

It will also create a new worker type that can direct BTS to any fund where FUND_ASSET is BTS.

Note: CNX reserves the right to retract this offer or request payment for adding this feature. This proposal does not commit CNX to develop the feature if we decide to pursue other options.

General Discussion / Using Casper Protocol for Secure Price Feeds
« on: February 17, 2016, 03:46:58 pm »
Vitalik published a well written blog post on the new Casper POS protocol being researched by Ethereum.

This paper was very enlightening and introduces some useful concepts. Perhaps one of the most interesting aspects is this:

The validator will wish to make such a bet only if they believe block X is likely enough to be processed in the universe that people care about that the tradeoff is worth it. And then, here’s the economically recursive fun part: the universe that people care about, ie. the state that users’ clients show when users want to know their account balance, the status of their contracts, etc, is itself derived by looking at which blocks people bet on the most. Hence, each validator’s incentive is to bet in the way that they expect others to bet in the future, driving the process toward convergence.

The original goal of BitUSD was to create a system that didn't depend upon price feeds and yet would maintain a peg. This system depended upon creating an "economically recursive" feedback loop.  In our initial experiments with BitUSD we saw that without a price feed or settlement it is possible for market participants to "short the USD to 0".  The economic feedback loop we conceived failed if one side or the other in the market had more strength and could push the price around and "wait out" the other party. 

Now we have the CASPER protocol which is designed to reach consensus on the current blockchain. Users place bets on each block on whether or not it will be included in the final chain. They cannot bet on all chains at the same time or they forfeit their deposit. 

A price feed can be viewed as a blockchain where the goal is to reach consensus on the price at any given point in time. There can only be "one" consensus value at a time so given a set of published prices they cannot all be "true" at the same time. This is like a blockchain can only have one history, not two.

So if we assume the CASPER protocol works as advertized then we can use it to get more secure decentralized price feeds.

CASPER rewards people for moving toward consensus and punishes those who deviate. It is claimed that the incentives are structured to reward some deviation and incentivise participants to defect from attempted collusions.  I have my doubts on this, but for now I will assume this is true.

If the reward from colluding is much greater than the penalty for failed collusion then the participants may find it worth the risk to collude. Furthermore, people are not machines and are biased toward trusting one another more than we should. This means that in a prisoners dilemma where each individual is better off defecting, people remain loyal more often than rationality would suggest.

Assume a price feed controls the forced-settlement ratio and the validators are using CASPER protocol to bet the next settlement price. If the bettors have a large stake dependent upon the outcome they will be more likely to bet on a favorable price, even if they lose the bet. Essentially, if the bet gains them 1 if they win and costs them 100 if they lose, it still make sense if they can shift the price by more than 1% and have have $10,000 available for settlement. It is impossible to know what side-bets participants have.  Those side bets could even be encoded in smart contracts.

My hypothesis is that either CASPER works for both Price Feeds *AND* Blockchains or it is fundamentally insecure for both.
The corollary here is that all consensus algorithms work for both Price Feeds and Blockchains or are equally insecure for both.

If my hypothesis is correct then DPOS witness published feeds are equally secure as CASPER based feeds *IF* CASPER and DPOS are equally secure consensus protocols.

If CASPER doesn't work as well for price feeds as it does for block production, then perhaps that says something about the fundamental security assumptions of CASPER.

So I am looking for people to evaluate how CASPER can be used to produce reliable price feeds.  Some thoughts to consider:

1. The security of CASPER depends upon the total amount bet
2. What happens if the feed being bet upon controls 1% of the amount bet
3. What happens if the feed being bet upon controls 100x the amount bet
4. What happens if the feed controls "NOTHING"

General Discussion / BitShares 2.0.160216 Released
« on: February 16, 2016, 08:56:11 pm »

Windows binaries will be posted shortly.

Pages: [1] 2 3 4 5 6 7 8 ... 42