Bitcoin Forum
June 04, 2024, 11:37:45 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 [6] 7 »
101  Economy / Securities / Re: ASICMINER: Entering the Future of ASIC Mining by Inventing It on: May 22, 2013, 08:24:53 PM
just give us the forking dividends!

https://blockchain.info/tx/9a6608efc8338d707f636594a6b547f849c12e002897e47a37bd5c8b6f994d80 - 148 BTC  2013-05-22 14:46:50
https://blockchain.info/tx/130a075194393462ad361a5191205cf35d27cd5206734b9315f1ba7d18473548 - 321 BTC  2013-05-22 14:46:39
https://blockchain.info/tx/43222fad233e04ef2db654bcec4609b9ca6203d832433112025f196a9cd9abb9 - 106 BTC  2013-05-22 14:47:04

...all still unconfirmed and all apparently Asicminer divis.
102  Economy / Auctions / Re: Auction of 400 shares of ASICMINER on: May 19, 2013, 04:51:58 AM
Update to 10 @ 1.89
103  Economy / Auctions / Re: Auction of 400 shares of ASICMINER on: May 18, 2013, 09:56:30 PM
damn you emoticorrect. emoticon in prev post = 1.8
104  Economy / Auctions / Re: Auction of 400 shares of ASICMINER on: May 18, 2013, 09:52:14 PM
10 @ 1.801

This is my first auction bid so please bear with me, auction rules state minimum increment of .01 - my bid represents an increment of 0.011 over the current high bid, so I believe this is ok (but if it is in any way invalid then please treat as 1.Cool.  Cheers
105  Bitcoin / Project Development / Re: ICBIT Derivatives Market (USD/BTC futures trading) - LIVE on: May 13, 2013, 08:26:33 PM
i agree
106  Economy / Trading Discussion / Re: Ripple account connection map visualiser - URL needed on: April 22, 2013, 09:06:25 PM
Spot on - thanks
107  Economy / Trading Discussion / Ripple account connection map visualiser - URL needed on: April 22, 2013, 08:55:23 PM
I was browsing yesterday and found a very cool site which visually mapped out connected ripple addresses, and also displayed balance info by currency, as well as recent transaction history and open trade book orders for each address.  It was an interactive map, clicking into a node opened up the further connections of that node etc...

Today - I cannot find it for the life of me, anyone know it?

Any help appreciated...
108  Alternate cryptocurrencies / Altcoin Discussion / Re: Ripple Giveaway! on: April 22, 2013, 12:08:50 PM
rnKTt2odaGAxyorMspdT6KSSrEx78WQ1vu
109  Economy / Service Announcements / Re: Amagi Metals - Largest Selection of Gold & Silver for Bitcoins on: April 19, 2013, 07:09:51 AM
Hi - Do you plan to offer 10 tola bars at any point?
110  Bitcoin / Project Development / Re: ICBIT Derivatives Market (USD/BTC futures trading) - LIVE on: April 18, 2013, 12:01:08 PM
Fireball,

It's great to be getting the opportunity to discuss this stuff, my feedback below.

1. Additional clearing happens automatically if the price hits the limit for N minutes (N may be 5, 10 or more minutes - to be discussed).

There are two scenarios in which limits are typically locked:
1) During a spot price reversal, spot moves away from futures range and the range is trending TOWARDS the spot but is not able to move quickly enough.
2) During a bull/bear run, where the range is moving AWAY from the spot and speculation results in contango/backwardation reaching range thresholds.

Is the objective to solve one or both of these issues?

As for the proposed solution, it is not clear what "Price" is being referred to here, do you mean Mt Gox spot price, ICBIT "last" price, or some kind of VWAP?   

If basing on Mt Gox prices, this might be effective in times of trend reversal, but will not prevent limit locks during contango/backwardation stretching.

If basing on ICBIT prices, I would suggest using modified VWAP rather than last price to reduce the scope for manipulation, and I would also suggest any trigger times are measured in hours rather than minutes, again to reduce the scope for abuse.

Whilst limit-locked ranges are frustrating at times, the range ceilings/floors do provide a buffer against intraday volatility which is both useful and relevant in a futures market.  Nobody will benefit from changes which make 100% daily range movement possible if the primary outcome of this is increased counterparty default and contract liquidation.

2. Margin calls are executed automatically against the market according to the existing 75% rule.

Does this not currently happen?  I agree this should happen, if a holders margin is exhausted contracts should be auto-offered to market and either sold/bought at the best available price, or placed as an offer at the minimum level which will guarantee 0 counterparty loss.  If no-one picks up the distressed contracts, the corresponding contracts should be liquidated at some specified point (e.g. the subsequent clearing session).

3. Margin requirements (both initial and maintenance) would be different for long and short positions. The formula for margin requirements calculation will include contango/backwardation into account, so that if some traders drive the price away from spot price, they are guaranteed to have enough money reserved in case contango is reduced.

This needs to be thought through very carefully.  A blanket rule to automatically raise margin requirements because of increased backwardation/contango could have the effect of moving innocent contract holders into negative margin and possible liquidation, even if they are on the gaining side of a contract (!).  This could potentially be mitigated if such a margin adjustment were programmed to occur at clearing after unrealised P/L has been transferred to balance (and then used to refil margin), but I suspect that is not what is being proposed.

4. Daily settlement price is going to be calculated as the last hour average

This is far better than using last trade price. However, if there has been no trade in the past hour the "last second single trade manipulation" would appear to remain possible.  To prevent this could you ensure the last hour average somehow apportions appropriate "weight" to periods in which no trades have occurred (e.g. because ranges are limit locked).

5. Contract specifications will be united into one (with the only difference of settlement dates), so that e.g. BUM3, BUU3 would be the same spec, with different settlement dates. The contract specification may be amended, and a list of all amendments must be maintained along with the recent edition of the contract spec. Amendments may come into effect at least in the next trading session after announcement, but usually for big changes the waiting interval after announcement may be a few days.

Cool.
111  Economy / Service Discussion / Re: *Unofficial* ICBIT (BTC Futures Trading) - Help & FAQ's on: April 10, 2013, 11:29:20 PM
Cool thanks - updated.

Also added requirement for a damn order summary before final submission!
112  Economy / Service Discussion / Re: *Unofficial* ICBIT (BTC Futures Trading) - Help & FAQ's on: April 05, 2013, 05:39:23 PM
Unscheduled clearing is being tracked as hot issue #1!

@ Fireball - are you able to confirm the planned deployment date for the move to twice daily clearing and the associated guarantee against unscheduled clearing?
113  Bitcoin / Project Development / Re: ICBIT Derivatives Market (USD/BTC futures trading) - LIVE on: April 05, 2013, 07:10:51 AM
Presumably only a risk if you have actually leveraged the underlying position? With enough capital (and i accept a lot would be needed), the risk of margin closure is zero and simply holding to settlement would see any widened spreads converge again, no?
114  Bitcoin / Project Development / Re: ICBIT Derivatives Market (USD/BTC futures trading) - LIVE on: April 04, 2013, 10:27:45 PM
Steps to solving the futures liquidity problem at ICBIT.

1. Create a "pooled fund", where users can allocate portions of their available balance (one fund for BTC, one for $) into a holding area.
2. Create a bot and use this fund to auto-execute arbitrage opportunities between Futures and Exchange markets (both local Icbit and Mt Gox exchanges).  This will provide liquidity to the market, and increase trade volume, not to mention establishing a lucrative interest rate to attract further deposits.
3. Repay arbitrage gain back into pooled account to be divided amongst contributors, users can also withdraw balances back into main account at any point, along with interest "earned".
4. Collect reasonable commission on arbitrage profit for ICBIT.
5. Pay me commission (this is the most important step).
6. Everybody wins.

Any reason this won't work?
115  Economy / Service Discussion / Re: *Unofficial* ICBIT (BTC Futures Trading) - Help & FAQ's on: April 03, 2013, 07:20:52 AM
Adding requirement - "margin" field within "your orders" view (esp. useful against unfilled orders).
116  Economy / Service Discussion / Re: *Unofficial* ICBIT (BTC Futures Trading) - Help & FAQ's on: April 02, 2013, 08:09:08 PM
Thanks Stephen - yes 100% unofficial - I have amended the title.

Also - I have amended the settlement specifics to incorporate the text you provided, thanks for the clarification.

Any features you would like to see on the platform?

Here's one - the way I see it, liquidity is a problem, also the contango arbitrage opportunities are very often HUGE on the futures instrument range.  If we could somehow make the arbitrage process more accessible, I bet we could vastly improve liquidity.  There could be opportunities to do this via both the UI and the API...
117  Other / Beginners & Help / Re: Incredibly confused by Bitcoin Futures contracts on icbit on: April 01, 2013, 08:42:56 PM
Note - new help/FAQ thread created: https://bitcointalk.org/index.php?topic=164255.0
118  Economy / Service Discussion / *Unofficial* ICBIT (BTC Futures Trading) - Help & FAQ's on: April 01, 2013, 08:17:49 PM
This thread is intended to support and mutually benefit the ICBIT user community, I'll try (edit: failing miserably) to keep up to date as poss - corrections or additional info/clarifications welcome.

UPDATE - 19/07/2014 - semi-official training guide available.

There is a nice trading guide called ICBIT Futures for Dummies. Check it out.

INTRODUCTION TO ICBIT FUTURES TRADING

https://icbit.se/

You want to hedge, arbitrage, or simply open a leveraged position against BTC price changes.  ICBIT offers leveraged trades through "futures" contracts, which are exchanged as a quantity of units between buyers and sellers.

Update: there is now an official rules page: https://icbit.se/rules

CONTRACT VALUE

https://icbit.se/BUH4 (example contract spec)

Each contract unit represents $10 worth of BTC at the specified price in $, so:

   > 1 unit at a trade price of $100 represents $10 worth of BTC, or 0.1 BTC in contract value.
   > 100 units at a trade price of $100 represents $1000 worth of BTC, or 10BTC in contract value.

The current trade value of each open futures instrument is not pegged to the underlying spot price, but is instead based on speculation as to what the final settlement value will be.  For this reason it is not guaranteed/expected to rise and fall as the spot price does.  Final settlement value is determined on listed the day of settlement for each instrument (currently 14th Apr, 14th Jun and 16th Sep), and the final settlement value is the 24 hour volume weighted average price (VWAP) from the largest exchange at the time of the settlement (i.e. 20:00 UTC).


OPENING A POSITION

Use the Buy/Sell buttons if you want to place an order with specific price conditions, if no corresponding offers exist at the specified price, then the order will enter the order book and become visible to others as an active bid/ask, if another user places an order which meets the specified price, the order will be filled and contract positions activated.

Use the Buy/Sell at Market button if you simply want to purchase at the most favorable currently available price.

To open a position, the following key fields must be populated.

  • Quantity  = The number of $10 chunks of Bitcoin you want to bet on.
  • Price       = The price you are prepared to buy/sell at.
  • Amount   = Calculated field displaying the amount of underlying BTC you are effectively betting on (Quantity * 10 / Price).
  • Margin    = Calculated field displaying the amount in BTC which must be "reserved" in the account to cover any potential loss incurred against the position (15% I believe).

CLEARING

The nature of the contracts is such that ongoing profit or loss against open contracts is re-distributed twice a day (08:00 and 20:00 UTC / GMT) in a system wide clearing process (rather than only being realised when a position is closed).

During Clearing all contract positions are evaluated and the latest trade price is used to determine the relative gain loss between the buyer and seller of each open contract. This difference (variance) is then transferred from the loser to the gainer, the contract remains active and will be re-evaluated at the next clearing session.

So if trade prices increase from 100 to 110, then the variance will be ((100*10)/100)-(100*10/110) = 10 - 9.09 = 0.91.  
     > Prior to clearing, the sellers account would show an unrealised loss of 0.91BTC, and the buyer +0.91BTC.
     > At clearing the loss of 0.91 would be deducted from the sellers account, and credited to the buyers account.  
     > After clearing:
               > "Unrealised P/L" balance reverts to 0 for both buyer and seller.
               > "Execution Price" for the open position is reset to the trade price upon which the variance adjustment was made.
               > "Margin" will also be adjusted (again, not sure of the precise margin calculation).

So, open a position of 100 units at around $100 and sell after a rise/fall of say 10 bucks, you are looking at just under 1BTC profit/loss (excluding fees).


RANGE

Another feature of the contract format is the use of trading range controls, an upper and lower limit on each instrument beyond which trading cannot occur within the current (12hr) session.  The range for the session is set during clearing based on the variable weighted average price (VWAP) price plus or minus 10% (edit: some newer instruments have wider range boundaries), so if the last trade price was 100 at clearing, the range for the following session will be set to 90 - 110.

Range boundaries are a safety feature to protect market participants from exceptional price swings in the underlying spot market, and limits risk exposure to traders (e.g. during intraday spikes/dips), given Bitcoin price volatility it is not unusual to see prices reaching upper/lower range limits, resulting at times in cessation of trade as no-one is prepared to buy/sell within session range threshold.

FEES

Each trading instrument will operate one of two fee models:
  • Lower transaction fees, but a twice-daily holding fee per contract applied at clearing (designed to encourage day-trading)
  • Higher per-transaction fees, but no holding fees (designed to support longer term trades)

Per transaction fees are calculated in BTC and are chargeable at the point of contract purchase/sale, therefore each position will incur fees twice (open and close).  Fees are charged according to the quantity of contracts being bought/sold, so whilst the fee is not displayed prior to purchase, it can be calculated by multiplying the quantity by the fee (and double if you also need to consider closure fees).

Actual fees are listed on the instrument reference pages (e.g. https://icbit.se/BUH4) and vary per instrument, usually with lower fees on contracts which are furthest form settlement.

Update 01/04/13: Fee discounts based on trade volume - fee discounts are now applied based on trading volumes, so if you trade a lot your fees will be lower - as outlined here: https://bitcointalk.org/index.php?topic=50817.msg1717445#msg1717445

MARGIN CALLS AND FORCED LIQUIDATION

https://icbit.se/margincall

Already spelled out pretty well on the ICBIT site, but many people still ask this, so here is the text:

"Every user's balance is continually checked by the trading engine if that user has any open positions. Margin call (forced close) is issued when his balance (actual money in the account plus total variation margin) is less than or equal to 75% of the total maintenance (initial) margin necessary to keep the positions.

If there are no respective bids/asks in the order book, the worst case scenario begins. The trading engine will go through users holding counter positions and forcibly close them by such a price that the user's balance who has the loss never goes negative."

API

https://icbit.se/api

There is an API available which offers full access to order book info, as well as order execution capabilities.  Personally I think the specs page could be improved through the inclusion of some additional specific worked examples, as well as instructions for the configuration of a very simple user control interface (excel/vba would be a start)... submissions welcome!

edit: example code here http://captainbodgit.blogspot.co.uk/2013/04/exploring-icbit-bitcoin-exchange-api.html


BUGS, HOT ISSUES

[NOW CLOSED] 1. Unscheduled clearing.
There is currently some controversy surrounding the use of unscheduled clearing sessions.  These appear to be run as exceptional events when large variations in BTC/USD spot price occur, and form part of a risk management strategy used to limit ICBIT's potential exposure to loss where over-leveraged contract losses can exceed the available account balances before any forced position closure has occurred.

There have been several instances of unscheduled clearing resulting in trading range increase/reduction, and subsequent forced closure of positions resulting in trading losses to individuals, prompting heated discussion of the legitimacy of such clearing.

Solution agreed and implemented (10/04/13): Fireball has confirmed ICBIT will now operate two daily clearing sessions, 20:00 and 08:00 UTC, and ad-hoc clearing sessions should no longer take place.

[NOW CLOSED] 2. Range Manipulation during the clearing process.

Each day during clearing the trading range for the following session is adjusted for each instrument, previously the adjustment is based on the price of the last single trade prior to clearing.  As a result, there were frequent attempts to influence the adjustment by shooting low/high orders in at the last second before clearing.  Range adjustment manipulation is attempted as a means of limiting losses and maximising the potential for profit during the following trading session, it can also result in forced closure of otherwise profitable trading positions, and has resulted in much heated discussion.

Solution implemented (December 2013): Range and variance adjustment calculations during clearing are now based on a new Volume Weighted Average Price, which should resolve the problem.
Target Fix Date: TBC

3. Forced closure of "winning" contract positions.  

Because ICBIT does not assume the counterparty risk for futures contracts being traded, gains must come directly from counterparty contract holders.  So if you buy a contract, and BTC rises, your profit must come from the loss of a corresponding seller.  In extreme market scenarios, those on the negative side of a contract will decide not to replenish a heavily depleted margin (and are perfectly entitled to do so).  Under normal conditions such contracts will then be forced back onto the market and transferred to a new seller at the best offered market price, however in the event that no other sellers exist, there is no way to continue maintain the contract obligation to pay profit to the gaining party, so contracts are force-closed at the "optimal" price (which essentially means the best possible price for the "gaining" side).

Because market price gaps can cause a contract loss to exceed both available margin, and the entire available account balance (if low enough), it is possible that already "realised" profit against an open contract can be reversed at the point of closure.
119  Alternate cryptocurrencies / Altcoin Discussion / Re: Ripple Giveaway! on: April 01, 2013, 06:01:13 PM
rnKTt2odaGAxyorMspdT6KSSrEx78WQ1vu
120  Bitcoin / Development & Technical Discussion / Re: Forking scenario - when border connections are closed on: March 30, 2013, 12:29:41 AM
I think in reality, whilst internet connections may be down, there will inevitably be exploitation of the double-spend opportunity.

As soon as an isolation event is discovered, people will rush to take advantage of the opportunity, wallet codes will cross borders and double spending will occur, both accidentally and deliberately.  There needs to be a solution to this potential problem.

Tea - are you saying the scenario below would not have caused a fork within the bitcoin network?

Pages: « 1 2 3 4 5 [6] 7 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!