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

Pages: 1 2 [3] 4 5 6 7
31
General Discussion / Clarification on trading engine & matching
« on: April 14, 2015, 04:18:44 am »
A couple of things I realise I'm still not clear on. I'm happy to be pointed to a document that explains this in simple terms.

Is it the case that orders submitted, cancelled or filled during a 10 second round, cannot be received and displayed by clients as part of the market state until that block is produced and synced? (as opposed to being broadcast immediately for all clients to display in the market state?).

Does the matching algorithm effectively get applied once every 10 seconds at the end of each block, when it is produced?
Does it take any account of the time sequence in which orders were submitted during the 10 second interval of that block? If not, how are equal orders for that block prioritised for fills?
Do certain order types get sequenced before others?

Thanks.





32
When I try to put on a short order, my short buttons (e.g. "Short BitUSD") do not respond. I have Short Mode selected on the tab. Is there a setting somewhere I need to change?

33
General Discussion / Some questions on running delegates
« on: April 13, 2015, 02:29:09 am »
I would like to understand some elements of the delegate structure better.

How much is a delegate realistically to have to pay to third parties or employees for outsourcing block-production and feed prices, assuming they do not possess these skills themselves? After such contract payments, how much revenue would remain for a 100% pay rate delegate?

If an individual runs multiple delegates, what is the best way to ensure that feed prices provided by each delegate are uniquely manufactured? (come to think of it, how do we know how many unique processes there are generating price feeds among the set of 101 delegates?)

Is there a limit on how many delegates an individual can run?

34
General Discussion / Idea: Models for Decentralised Governance
« on: April 12, 2015, 02:29:49 am »
Currently the only way for stakeholders to fund common work in the BitShares system is to vote for individual developers and marketers, who are then paid like employees of the system. Realistically, all the core developers need to be individually voted in to continue their work toward the team priorities if we want development to progress. This process allows funding for directed development, but does not give stakeholders any meaningful say in the direction or prioritisation of that development. Their only option is a binary one - to opt in or opt out of owning BTS, with those votes reflected in the BTS price, which affects the delegate group collectively.

Its possible to instead have a system where stakeholders are individually free to vote on the priorities for development of the entire system, and to use their stakes to direct this effort. This would be through the voting and funding of public agents. Public agents would maintain a public policy and budget, and a required number of seats for office. Their platform could be specific to an area, like product design, or development, or security, or a more holistic policy, vision or principle to implement within BitShares. And the public could vote them in so that they receive the required public funding and create those outcomes through their expenditure plans.

Rather than merely acting as employees, public agents could be considered as running an office. Their budget would include employees as well as payments to other service providers to influence workflow performed in the system. For example, if a public agent with a new product design obtained enough seats by public vote, they could budget payment to the core developer team to either influence a change in priorities or allow them to pull in more coders to fulfil this demand.

A much broader skill-set would be utilised by these public agents, beyond coding and marketing. They may bring skills in design, strategic planning, law or other fields, and use this to direct change in the system.

Public agents could also receive voluntary funding from stakeholders, and this list of patrons could also be used in various ways without obligation, such a votes on budgets if required. (*)

Now I've been careful not to say public agents are delegates, although clearly the delegate structure, with a couple of modifications, could easily be redirected toward this purpose. These modifications would include:

- removing the requirement for all delegates to perform certain tasks such as block-signing and feed-prices (see https://bitsharestalk.org/index.php/topic,15688.0.html), a process that can be managed by specific agents

- setting up control mechanisms for delegates to transparently and honestly manage their budgets

We could alter the labels we use if we want to avoid confusion with the historical role of delegates under DPoS, being purely block production. So for example, we could call the block-signers delegates, and the public agents "ministers" or "agents" or some other more useful name. I do happen to think though that delegate is a useful label for what I am describing, moreso than the block-producers.

Now in modern society, the structures of government, businesses and other institutions are largely hierarchical in their decision and prioritisation processes. What I'm suggesting here is a way to truly decentralise the governance structure so that stakeholders retain as much control over the evolution of their system as possible.

(*  Its conceivable that the system could exist on patronage alone rather than any public funds, but that requires deeper thought).

35
There has been some past debate about whether delegates should fulfil more or less services, perhaps even being purely block-signers (as they were originally) and paying for other common services in some other form. Here I take a different tack. What if delegates as a collective group were completely freed from the requirements of block-signing and price-feeds? What I find compelling about this idea that there would be far richer competition for delegate slots, delegates could be voted on their specific contributions rather than a menagerie of tasks, and the block-signing and price-feed pools could be managed by more expert judges. But there may well be big flaws or weaknesses as well.

I've already suggested elsewhere the possibility that a much smaller group of delegates could be voted in as price feed arbiters, that coordinate an open pool of price feed submitters. This would remove price-feeds as a required delegate function. See https://bitsharestalk.org/index.php/topic,15331.msg197641.html#msg197641

Is it feasible that something similar be done for block-signing? This is not a proposed process, as I don't think I'm best placed at all to determine the best procedure, but as a starting point for discussion I'm thinking something along these lines -

- there is a smaller group of block-sign arbiter delegates voted in by all stakeholders via the usual process, on the basis of their proposed selection process for block-signers
- each delegate in this group is required to maintain a template of preferred block-signers
- the combination of these templates determines the 101 block-signers at any time
- block-signing rewards no longer go to delegates but to this set of 101 block-signers
- whenever a block-sign arbiter delegate changes their template, there is a minimum time period before it comes into force, so in effect all stakeholders have a right of veto
- when a new block-sign arbiter delegate is voted in, their template takes immediate effect

So is something like this feasible? How would it affect the integrity of the block-signing process? Does the idea have merit?


36
Technical Support / Problem importing BTC wallet
« on: April 09, 2015, 06:57:08 am »
I'm currently trying to import the BTC wallet from which I purchased NOTES in the pre-sale, but I'm getting an error. Not sure if I'm doing it all correctly.

My understanding is this.
I go into Keys - Import Keys from Wallet in the client.
I select Wallet Type Bitcoin/PTS.
I use the Select File button to locate my wallet. Now in my case it was a Multibit wallet, and the Wallet Path comes up (on MAC) as :
    /Users/xxxxx/Library/Application Support/MultiBit/Notes.wallet
I enter my Multibit Wallet Password.
When I hit Import Wallet, I get the following error:

"Error
Db::open: Invalid argument (13) Db::open: Invalid argument:"

I have no problem accessing my wallet in the Multibit client.
Ideas?

37
Technical Support / Not syncing on 0.8.0
« on: April 08, 2015, 05:04:23 am »
My client has not synced the last couple of versions, and I've not been able to trade for many weeks as a result. I'm now running with 0.8.0 and plenty of RAM. I tried starting from scratch, and syncing is stuck at 113 days ago. Below is what get_info says...anything obvious?

{
  "blockchain_head_block_num": 1272493,
  "blockchain_head_block_age": "16 weeks old",
  "blockchain_head_block_timestamp": "2014-12-16T00:37:40",
  "blockchain_head_block_id": "36e9a00a6cc5b028425789d65d01975a6daf80ec",
  "blockchain_average_delegate_participation": "0.01 %",
  "blockchain_confirmation_requirement": 1,
  "blockchain_share_supply": "2,498,429,811.47841 BTS",
  "blockchain_blocks_left_in_round": 6,
  "blockchain_next_round_time": "at least 58 seconds in the future",
  "blockchain_next_round_timestamp": "2015-04-08T04:47:10",
  "blockchain_random_seed": "49eff8a9887b01cfc6b9a6d855a3a40e63a60948",
  "client_data_dir": "/Users/<username>/Library/Application Support/BitShares",
  "client_version": "0.8.0",
  "network_num_connections": 6,
  "network_num_connections_max": 200,
  "network_chain_downloader_running": false,
  "network_chain_downloader_blocks_remaining": null,
  "ntp_time": "2015-04-08T04:46:12",
  "ntp_time_error": 0.055073999999999998,
  "wallet_open": true,
  "wallet_unlocked": true,
  "wallet_unlocked_until": "12 days in the future",
  "wallet_unlocked_until_timestamp": "2015-04-19T18:32:29",
  "wallet_last_scanned_block_timestamp": null,
  "wallet_scan_progress": "100.00 %",
  "wallet_block_production_enabled": false,
  "wallet_next_block_production_time": null,
  "wallet_next_block_production_timestamp": null
}

38
General Discussion / Relative orders clarification
« on: April 07, 2015, 12:26:11 am »
Back in February, theoretical made the following comment regarding relative orders. I was wondering if we could get more clarification on what was meant by "fundamental architectural limitations". Is there a fundamental property of bitAssets that does not theoretically allow relative orders (and what is it?), or is it more an issue with the way in which things are currently coded (and if so, what's the current status)? It would help understanding of what's possible and what's not.

Quote from: theoretical

TLDR, ticket in OP is still under discussion.

Some history.  A feature which has been on our road-map for some time is relative orders, where people can place a bid or ask at a given percentage of the feed, like "I want to buy at 95% of the feed and I want to sell at 105% of the feed," without having to run scripts and spam the blockchain with a ton transactions.

I was tasked with implementing relative orders (more specifically, rehauling bytemaster's implementation to use percentages of the feed instead of absolute difference from the feed, and thoroughly testing it in preparation for release).

During the testing, I found certain fundamental architectural limitations of our matching algorithm prevented us from properly matching relative orders.  The same limitations also prevent certain combinations of existing order types from matching correctly in certain circumstances, which subsequently occurred on the main network.  A community contributor (pmconrad) advised us of this, which I already suspected due to what I knew about the architecture, and confirmed in testing.

My solution was to embark on a significant refactoring of our market engine to make orders execute the way we always intended them to.  I had hoped to have it ready for initial testing this week, however I've been hugely distracted upgrading my own delegate for the 0.6.x hardfork.

bytemaster thinks I am being overly optimistic about the timetable for my refactoring, and thus is looking for a change that will fix the problems but be much less expensive (in terms of developer time).  This ticket is the solution he's hit upon.

What we need to do is sit down and discuss the options, which will happen just as soon as I finish dealing with my obstreperous delegate VPS.



39
I am noticing quite a strong opinion that price feeds are just a temporary hack required until liquidity improves. And on the basis of this opinion, there is some resistance to ideas that build on top of the feed price. So I feel this is a useful issue to attempt to clarify at this point.

I personally think that for market-pegged assets to operate successfully it is critical there is some form of obligation on issuers (shorts) to redeem (destroy) units at the peg level at some point in time. So I currently see price feeds as a permanent feature.

I think if there were no redemption obligations on issuers, then all market participants would now choose to own and sell the bitAsset purely on the basis of their own individual perceptions of utility and future prospects. There would be no reason for any seller below the peg level to instead hold for a better price on the prospect that redemption may be available at the peg price. Likewise any buyer at this level takes on a risk that the market's evaluation might go lower instead of higher. Even if there are more liquidity providers over time, they would be forced to place orders around the current market rather than the peg price in order to make profits instead of losses.

I guess its possible issuers (shorts) could collectively choose to adjust supply to manipulate prices toward the peg price. They may be disincentivised from allowing peg failure if they believe that would jeopardise the valuation of their personal BTS holdings. However, I'm skeptical such an indirect incentive can be relied upon. BitShares may one day be much more than just bitAssets. Smaller bitAssets might not make much difference. And competitors may attack Bitshares by self-creating unlimited supply and driving certain bitAsset prices toward zero. BitAsset users would be asked to rely on trust in a group of unknown issuers and their unknown desires.

Placing an obligation on issuers to redeem at the price feed means that each market has a separate valuation anchor, related directly to the value of that "contract". No trust or reliance on issuer incentives is involved. While certain market conditions can still devalue that contract more than usual - for example, a quickly declining BTS price may lead to a discount reflecting lower collateral levels and greater uncertainty in converting any BTS received to real assets - I would take comfort that the existence of a contract places limits around how far the market will allow the price to deviate from the peg price.

I know others differ in view, so interested in thoughts.

40
This is purely a post of personal interest (thus in Random Discussion), prompted by government debt debates in Europe.

I've come to the view that is is not moral for a government to ever create debts upon future generations without their consent. Even to the extent that any infrastructure spend is directed for future rather than current generations, it is best considered a gift without obligation. There is no way to anticipate any value these future generations will place upon this gift. Thus I have come to the view that all governments should spend solely from revenue and no more.

In principle at least, I think that any governments should cease accumulating existing debt, and repayment of those debts should fall upon the segment of society that was of voting age when those debts were accumulated. Though this does not allow for the fact that many in society may have been dissenters (another moral question), at least the debt falls upon the correct generations mostly responsible. Any excess debt over what a government can reasonably shoulder through such selective taxation of the "responsible" generations should be written off as null and void. 

Further, as no innocent child can be held responsible for the sins of the father, war reparations (state obligations to other states) cannot fall on any generation beyond those involved in war crimes.

In every case however, those free of these burdens may volunteer to make amends for past grievances for the future betterment of society.

These are just some basic thoughts on the matter. What do others think?



41
[Edit May 12: The ideas in this thread have now been superseded by whitepaper here: https://bitsharestalk.org/index.php/topic,15880.0.html]

This is not a proposal, just a personal idea, let me know what you think.

Basic Structure

There would be a standard free market in the bitCurrency (e.g. bitUSD, bitCNY, bitEUR...) against BTS, with only bids/asks, and no price feeds or shorts,

PLUS

There would be an Issuance Window, where users are free to create and destroy units of the bitCurrency instantly at the median feed price (MFP) +/- a small spread.

An Issuer Pool would automatically make the market at the Issuance Window, by accepting BTS to create new bitCurrency, or distributing BTS to destroy bitCurrency, instantly upon demand and in unlimited quantity for destruction, and nearly unlimited (see below) for creation. The Issuer Pool would be capitalised by a combined pool of investors seeking leverage to the BTS price, who have paid BTS into the pool by buying units in the pool (Issuer Units). The Issuer Units would trade in their own free market against BTS.

The leverage to BTS in the Issuer Pool varies with both bitCurrency creation/destruction (i.e. demand) and movements in the BTS price. The Issuer Pool is required to remain within specified leverage limits. If leverage begins to get too high, the Issuer Pool would issue more Issuer Units into the free market, tending to create a discount to NAV that would attract new investors and raise capital. If leverage begins to get unattractively low, the Issuer Pool would buy back Issuer Units in the free market, tending to create a premium to NAV that encourages capital release to increase leverage again. These changes in unit supply should be prescription-based and transparent to the market with notice, so that the market has time to prepare to take advantage of it.

The only limit on unfettered activity at the Issuer window would be that new creation would be stopped and queued if the Issuer Pool failed to raise more capital when beyond its leverage limit, despite significant discounts to NAV on the Issuer Units (e.g. if the Pools had grown too large relative to total BTS supply that is available to support them). In this scenario bit-Currency premiums in free markets would be unresolved, just as they would in the current system.

Key Benefits

- BitAssets would retain their key advantages over competitors, being it is transparently and overly collateralised, and supply is highly responsive to changes in demand in both directions
- The peg would be as close to perfect as possible, because market-makers could provide massive buy and sell walls around MFP in the knowledge they have access to the Issuance Window
- It removes the complexity associated with individual shorts, including expiries, calls, rolls and interest (shorts are now replaced by Issuer Pool investors)
- It allows free market trading in bitCurrencies:BTS in a simple form that people are traditionally familiar with, without needing to understand complicated market rules
- It allows other functionalities to be built in the BitShares environment that complement these markets, such as lending, depositing, margin trading etc (see below)

Impacts on bitCurrency users

They can have confidence operating in highly liquid strongly pegged markets, whether they ever personally use the Issuance Window or not.
They no longer receive interest (bitCurrencies are more like cash) but they can receive interest in lending or deposit markets (below), just like when they lend or deposit fiat cash. This is less confusing than the current market which combines properties of both cash and deposits.

Impacts on Issuer Pool Investors (replacing shorts)

Unlike shorts in the current system, Issuer Pool investors share the costs associated with managing a leveraged investment. Costs exist in both systems, but in different forms.

When supply is too high for demand in the current system, shorts would need to raise their interest rates to compete to retain their shorts beyond expiry. In the Issuer Pool, unit-holders get diluted by those accepting the buyback of Issuer Units at a premium, if they do not also accept it themselves and take capital out.

When BTS falls in price and collateral becomes low for some shorts in the current system, they can choose to add collateral, or get called and effectively lose BTS at a low price (which is a cost). If the Issuer Pool runs low on collateral, it sells new units at a discount, which dilutes any investors that choose not to participate by contributing more collateral.

If demand is running hot and outstripping supply, there are no costs for shorts in the current system in maintaining their position. However investors in the Issuer Pool will be diluted by new Unit issuance if they choose not to participate.

In the current system, shorts receive a leveraged return on their BTS, less interest, and less the costs associated with inopportune calls or expiries. In the Issuer Pool, investors receive a leveraged return on their BTS, plus a return from market-making at the Issuance Window, less dilution from new unit issuance or buybacks that they do not participate in pro-rata.

In the current system, shorts can attempt to earn extra timing return by shorting at premiums and covering at discounts. Issuer pool investors can attempt to earn extra timing return by buying more Issuer Pool units at discounts and selling at premiums.

Its not clear to me that there would be a big difference one way or the other, on average, from a purely economic perspective. However it is much easier for the average investor to participate in the Issuer Pool than it is to manage shorts, which may expand the available supply.

Impacts on market-makers

Market-makers would now make a market anywhere in the bit currency, and utilise the Issuance Window for hedging or offsetting. This makes the task easier and less risky, so spreads should be very tight. Gateways would likewise be able to offer very tight spreads.

Complementary functionalities

A direct lending market could be established in the bitCurrency, allowing bitCurrency lenders to earn interest at risk. The borrowers could use or sell the bitCurrency for any personal purpose, opening up the set of all available borrowers beyond just BTS bulls, in the same vein as BTCjam.
A banking/deposit market could be established in the bitCurrency, where an intermediary accepts interest-bearing deposits, and lends to a managed pool of borrowers, taking some equity risk.
A margin lending market could be established in the bitCurrency, providing margin for other on-blockchain investments such as BTS. This could operate similarly to Bitfinex.
Other possibilities are using the bitCurrency for margin accounts to underpin derivative and CFD markets.

Essentially there is no need for the properties of any of these markets to be built into the primary bitAsset market, because they can all be provided separately, such as via UIAs. In particular, it is not necessary to offer interest in a cash-creation market if lending and deposit markets can provide this.

There's more I could flesh out, depending on initial interest.

42
Technical Support / Should I get 8GB or 16GB on my iMAC?
« on: March 30, 2015, 05:10:09 am »
Upgrading the RAM on my 2011 iMAC from 4GB as syncing the block-chain keeps stopping half way through on latest client versions. Would 8GB or 16GB be recommended?

43
I was wondering if it might be worthwhile having a basic client available just for holding and transferring functions on a private wallet. This would allow casual users and BTS investors to maintain a simple unchanging client while the development work and upgrades continue on the full service client. It would provide extra security of funds over the online wallet, while still allowing users to transfer to/from external exchanges when needed and make switches between bitAssets and BTS via exchangers such as metaexchange. Any views?

44
The potential uses of self-creation, self-cancelling, self-rolling, and auto-rolling functions


These ideas have been touched on in a couple of recent threads, and also been discussed to some extent in the past. My idea here is that although many of these functions can theoretically be performed through a series of manual steps in the current system, having simple functions that automate these would have the following benefits -

- they simplify the processes to "one-click" processes
- they would offer simultaneity of matching trades, which eliminates the risk of other parties stepping in to take one side of the order
- as such, they facilitate market-making and short-side management
- there is no risk to the system if the conditions of these self-matching orders meet the conditions that would have existed in implementing them manually

The last point is important. As long as the incentives in the system are set up right, we should have no problem with taking out the practical inconveniences that rational actors would experience in trying to manually replicate these strategies.

There's no doubt issues I have not thought of, as I've not read all the previous history, so apologies in advance.

Self-cancellation

Self-cancellation does not alter the ability of sellers to achieve the feed price, since it buys from the pool of sellers that might exist below the price feed. Actually I discuss here...https://bitsharestalk.org/index.php?topic=14835.msg195515#msg195515...why I currently think it is necessary to have a mechanism for sellers to be able to set a sell order that moves with the price feed in order to guarantee they will receive the feed price level within 30 days. In any case, self-cancellation orders (in the current system, covered short orders) do not jeopardise this at all.

There are alternate ways to accomplish self-cancellation other than the current short-cover procedure. Self-cancellation could also be achieved by presenting a unit of the bitAsset (from any source) against the short position. This would be useful in certain strategies such as the one described in self-creation below.

Self-creation

Self-creation provides a neat way for profit-seeking market makers to exploit bitAsset premiums when there is not enough bitAsset remaining in inventory to sell. Simply, the market-maker takes some of their BTS inventory, self-creates bitAsset (long and short) then sells the bitAsset for the real asset on a centralised exchange. Should the premium contract at some future time, the market-maker can exchange the real asset for the BitAsset again, and present the bitAsset against their short position for self-cancellation (alternative means of self-cancellation described above). The big advantage of this approach for the market-maker is that at no time are they exposed to the directional movement of the asset, and they unlock just as many BTS as they put in to start with. Their profit comes in the form of units of the real asset, which of course can be converted afterward to USD, BTS or whatever exposure is preferred.

To do this in the current system requires the market-maker to manually match a long to a short order. In slow-moving, illiquid markets, that may seem easy enough. If fast-moving liquid markets (which we hope to see) there are risks of others taking one side or the other before it is matched. This creates an exposure to both BTS and the bitAsset that needs to be quickly unwound (potentially at a loss) or hedged (at risk and cost). From a pegging perspective, facilitating and simplifying this type of market-making strategy helps to manage the potential excessiveness of bitAsset premiums from time to time.

In practice self-creation requires there to be no sellers below the price feed. It also requires the new short order to be at the front of the short queue, which means either the highest interest rate (if at the price feed) or the lowest price (if above the price feed). So it ought to be possible for anybody to queue a self-creation order at an interest rate of X%, and when it's the highest it gets created. Note that these limits are not limits at all when the bitAsset is at a premium, because there are no sell orders below the price feed, and with no shorts at the price feed, shorts are queued on price and can pay 0% interest.

But the process could be even more sophisticated than this. In practice if there were a small short order at a very high interest rate at the price feed (that blocks reasonable self-creation), one could manually buy out this self-order, sell the bitAsset at the highest bid, then do the self-creation. This comes at a cost equal to the volume of the order to be taken out, times the price spread. But by taking this out, the interest rate required for self-creation might be much lower. By specifying a maximum cost that one is willing to bear in the self-creation process, along with the interest rate, this could all happen automatically, without the market shifting or getting in the middle as the various steps are attempted manually.

Self-rolling

Self-rolling is essentially self-cancelling plus self-creation occurring simultaneously. So the conditions on self-creation also apply to self-rolling. Self-rolling orders could be placed with a maximum interest rate and roll cost, and when the market allows this, the roll occurs.

Auto-rolling

Auto-rolling could be a permanent (switch on, switch off) feature that always self-rolls when it can, subject to one's interest and cost parameters.

45
With BTS/fiat trading now dominated by BTC38, and very poor liquidity elsewhere, is it the case that basically the price feed is derived from a single exchange? If so, this makes us very reliant on a single external party where we don't have good transparency on the internal practices of such exchanges. It seems a shame that BitShares is promoting decentralised trading, yet the trading in our own token needs to take place on centralised exchanges in order to feed inputs to the system.

I've seen talk in the forum about setting up decentralised exchange between chains using escrow parties. Could somebody apply a similar idea to BTS/fiat, for example one of the gateways? If so, then that might also be a reliable price feed, depending on how active such a market might be. I expect the regulatory requirements would be more stringent than a crypto-crypto exchange though.

On a related point, it also seems a shame that for now, while its difficult for most casual users to maintain an up-to-date client, this forces them to centralised exchanges to hold and trade. This subjects them to risks as in the recent BTER case. It would be good if some form of trading were available from the online wallet, which although not as secure as a private wallet, removes the need to rely on external exchanges.


Pages: 1 2 [3] 4 5 6 7