Pages:
Author

Topic: ICBIT Derivatives Market (USD/BTC futures trading) - LIVE - page 34. (Read 97654 times)

hero member
Activity: 756
Merit: 522
If Fireball was behind these manipulations, why would he have undone them by an extra clearing one of the first times it happened?   I lost a significant amount due to a manipulation, but instead of liquidating my position (although I was below the limit for a margin call), a second clearing occurred "due to high volatility" half an hour or an hour later.  You can probably still find the announcement in the Twitter feed.  Fireball quickly stopped doing this, probably he realised that this kind of ad-hoc manual interventions are not a good idea. 

So Fireball has to your knowledge intervened to fix the price to a different level than the market showed, and this you bring as an argument against the otherwise clearly proven fact that he...is fixing the price. You were thrown a bone by your own declaration and would like to be thrown more in the future. You're not a "customer", by this, you're a client. In the old, Latin sense of that word.

As far as I'm concerned the point has been clearly proven. If any fools want to part with their money from this point onwards they're welcome to do it, but they won't be able to claim that they "couldn't have known". Simple as that.
hero member
Activity: 674
Merit: 500
I don't complain!!

I was explaining so other could understand why it's needed. I did not even think you complained :-)
hero member
Activity: 547
Merit: 500
Decor in numeris
I lost a significant amount due to a manipulation, but instead of liquidating my position (although I was below the limit for a margin call), a second clearing occurred "due to high volatility" half an hour or an hour later.  You can probably still find the announcement in the Twitter feed.  Fireball quickly stopped doing this, probably he realised that this kind of ad-hoc manual interventions are not a good idea. 

Additional clearings are normal when market conditions are rapidly changing. They are pre-announced via official Twitter channel (displayed on the site's frontpage). I did an additional clearing because the market went too much against spot market and when the rate returned back (thanks to arbitragers) I did the additional clearing to move trading range back. No margin calls happened during that period because that would be greatly unfair to our clients.

I don't complain!!

I just thought you stopped doing it because any kind of manual intervention opens you to being attacked for being biased.  But I agree it was a good thing when it happened.
hero member
Activity: 674
Merit: 500
I lost a significant amount due to a manipulation, but instead of liquidating my position (although I was below the limit for a margin call), a second clearing occurred "due to high volatility" half an hour or an hour later.  You can probably still find the announcement in the Twitter feed.  Fireball quickly stopped doing this, probably he realised that this kind of ad-hoc manual interventions are not a good idea. 

Additional clearings are normal when market conditions are rapidly changing. They are pre-announced via official Twitter channel (displayed on the site's frontpage). I did an additional clearing because the market went too much against spot market and when the rate returned back (thanks to arbitragers) I did the additional clearing to move trading range back. No margin calls happened during that period because that would be greatly unfair to our clients.
legendary
Activity: 1022
Merit: 1033
I may be dense, but I do notice you've conveniently ignored the question of your own involvement with the icbit scamsite.

I didn't ignore it, I described it in all details.

As you're dense, I can repeat: my involvement is limited to:

1. Being a customer, I played with ICBIT a bit since last Friday. With sum less than 5 BTC.
2. I had a discussion with Fireball more than 1 year ago, in summer of 2011. We have considered making futures exchange together. But I abandoned this idea, and we were not communicating up to last Friday.

That's all, there is no other involvement. I've answered your question, please mark it in your notebook, you seem to be forgetful.

Just because you want to uncover scam it doesn't mean scam exists, OK?

Nope. If the order made it then it's on the books. If it didn't make it then it's on the customer, it's his job to get his order to MPEx, not MPEx's.

Same is true for ICBIT: it's customer's job to get his order to ICBIT. There is no evidence that smickles coped with it, all we know that he clicked some button in his browser, but that's not enough. There is no tcpdump log.

There's in no case absolutely anything to investigate: if MPEx is down (which hasn't happened yet) then nobody is getting orders through. If MPEx is up and the customer fails to talk to it he picks up his phone and talks to his ISP support hotline or w/e.

It looks like you have very vague ideas about network and software engineering.

ALL sorts of problem are always theoretically possible, and moreover they happen all the time, even with very important servers.

If MPEx is not made out of pixie dust it might be vulnerable too. Denying this just shows your ignorance.

Here's an example of network problem which can happen: http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html

There was a problem with one of routers several hops away to a data center. Connections which were routed via it predictably failed. But even if you repeatably try to connect, sometimes it works. And, of course, if you're connecting from a different location there is no problem.

So it is an undeniable fact that site might be down for some people, and not down for others. Moreover, problem might be stochastic, i.e. one out of 100 connections fail. Moreover, problem might be somewhere between customer's ISP and your ISP, usually there are many hops.

These are basics, if you understand it you know nothing.

And exactly same kind of unpredictability can happen on server side. I won't bother explaining it to you in all details, but it is very well possible that overloaded server will drop some connections while processing other. E.g. check SPECweb2005 benchmark, as you see there is such thing as "tolerable error level", even when people run it in controlled environment and can retry as many times as they want: http://www.spec.org/web2005/results/res2009q2/web2005-20090520-00138.html

This is quite different from the scamsite behavior, wherein customer can see his account, can see the volume move, can see other orders for "other customers" being executed but his orders are ignored. Repeatedly. For the obvious reason that if the scamsite allowed actual customers to place orders in that magical interval it wouldn't be able to fix absurd prices. Duh.

I agree that people should demand more transparency from ICBIT, but that does not mean that MPEx is made out of pixie dust, OK?

Do not make bold statements like "we can never fail", they simply show your incompetence, and that's all.

Notice the difference here. MP checked out the icbit.se site, has proof that it's a scamsite. You're talking theories about your understanding about how things may be. Quite a very different thing (not that I'm not impressed you sometimes use ssh, don't take this the wrong way).

I was simply replying to your statements that MPEx cannot fail. It can. It doesn't mean that it DOES fail, I never claimed that. I simply outlined how it is possible, so your statement is provably false.

You do not understand how technology works and you are boasting and making invalid statements. I'm trying to correct you. This is totally unrelated to ICBIT being a scamsite.

No, they're both necessary for trading and impossible for a scamsite.

Yet another bullshit statement from you. It is possible to implement a scam site which would give PGP-signed receipts.

It is not a slightly misleading statement, you're implying that if if PGP receipts are given then site is definitely not scam, which can mislead people into believing to scam sites which use crypto.

It is only secure when it is done via blockchain.

Alternatively, I need to stop entertaining pompous shills.

That's a good idea, actually.
hero member
Activity: 547
Merit: 500
Decor in numeris
You were caught scamming. Your sorry attempts to avoid that discussion by making ciuciu-esque attacks won't save you, you'll just end up with egg on your face on top of the original problem of having been caught scamming.

No.  You saw behavior that you find consistent with scamming.  Others saw otherwise - at least your proof is far from convincing.  It may be convincing what you saw, but certainly not what has been posted here or on the blog.

I'm concerned with rude spam by MPOE-PR (https://bitcointalksearch.org/topic/heres-where-i-spew-my-accusations-against-mpoe-all-are-welcome-102333 ).
Other related people (smickles) are behaving quite good, and we had useful discussions over support email.

I will consult with [Tycho] about further actions.

Don't bother, the moderators will not do anything.  MPOE is entitled to her opinions, and is entitled to post them here.  We are entitled to disagree (and the shrill tone of her posts certainly don't help, even if her points were valid - which they might be!)

It would be very bad indeed if the moderators started censoring people calling a scam - even if they appear to be wrong!!!
hero member
Activity: 756
Merit: 522
I'm concerned with rude spam by MPOE-PR (https://bitcointalksearch.org/topic/heres-where-i-spew-my-accusations-against-mpoe-all-are-welcome-102333 ).
Other related people (smickles) are behaving quite good, and we had useful discussions over support email.

I will consult with [Tycho] about further actions.

I'm concerned with you behaving like a scammer, on top of actually being one.

You were caught scamming. Your sorry attempts to avoid that discussion by making ciuciu-esque attacks won't save you, you'll just end up with egg on your face on top of the original problem of having been caught scamming.

I'm rather bored with this discussion. You are dense. I'll try to spell it out for you one more time, but this is the last time...

I may be dense, but I do notice you've conveniently ignored the question of your own involvement with the icbit scamsite. So no, you're not bored. Anything BUT bored.

Suppose it was time sensitive like it was with smickles order. How is MPex going to explain why order wasn't accepted immediately? Most likely response is "oh maybe the connection failed we'll investigate": connection failure is indeed the most likely cause, but it is a good idea to check server logs.

Nope. If the order made it then it's on the books. If it didn't make it then it's on the customer, it's his job to get his order to MPEx, not MPEx's.

There's in no case absolutely anything to investigate: if MPEx is down (which hasn't happened yet) then nobody is getting orders through. If MPEx is up and the customer fails to talk to it he picks up his phone and talks to his ISP support hotline or w/e.

This is quite different from the scamsite behavior, wherein customer can see his account, can see the volume move, can see other orders for "other customers" being executed but his orders are ignored. Repeatedly. For the obvious reason that if the scamsite allowed actual customers to place orders in that magical interval it wouldn't be able to fix absurd prices. Duh.

In that case we can a situation like this: 1) user clicks "stop" button in browser, but it doesn't stop packets which are already in flight; 2) user checks state, it says that order is not accepted; 3) now those packets which are in flight arrive to server and it actually accepts the offer. Whoopsie.

You'd probably look a lot less ridiculous if instead of sitting here and puking mental experiments you actually took the time and checked things out.

Notice the difference here. MP checked out the icbit.se site, has proof that it's a scamsite. You're talking theories about your understanding about how things may be. Quite a very different thing (not that I'm not impressed you sometimes use ssh, don't take this the wrong way).

Practically: if MPEx says you can't repeat an order, then it has your order on record. If it doesn't then it never saw it.

It is completely independent from transparency issues, I agree that use of PGP signatures and full transaction log are desired features.

Desired, eh?

No, they're both necessary for trading and impossible for a scamsite. The beauty of this is that the Fireball character, though he continues to lie about it, did take the site down for maintenance and made some changes mere hours upon being called out for his little scam. Those changes, while probably temporary, are a little more in line with his declared intentions, and magically the "future" contract is almost in line with reasonable economic expectation.

Isn't it fascinating how the big bad evil mean and mysterious manipulator suddenly got scared and left cause Mr. P wrote something on his blog? Isn't it grand how caught in between the rock of the article and the hard place of everyone being able to verify it for themselves the next day Fireball suddenly fixed the "exchange"? Tsk tsk.

So you know...desired. Myeah. Call them imposed.

Anyway, you need to learn a bit more about how networking works

Alternatively, I need to stop entertaining pompous shills. How is it that all you idiots sing from the same book?

Quote
Nov 17 19:57:25 <_Fireball>   honestly, by reading your blog post, I  see that you have little idea how futures exchanges work
Nov 17 19:57:32    that's fine.
Nov 17 19:57:42 <_Fireball>   and I'm explaining it to you ;-)
Nov 17 19:58:23 <_Fireball>   so, would you be a man and write an apology?
Nov 17 19:58:35    you're joking, right ?

Get your heads out of your asses, both of you. You're here to learn, not to teach, and you're doing an usagi-level job of it. The nerve of you people!

Quote
15NOV12 19:59 At 30 seconds until close, I saw the expected sell order. It was larger than I had expected, leaving about 450 contracts on the book at 10.025. Notwithstanding the fact that his order would not overcome this, I dutifully placed the order Mircea had asked me too.

I expected to see the results of Mircea's order within the next few seconds as server load could be expected to be higher than earlier in the day.

At 10 seconds until close I had not seen any evidence of the order taking effect.

Hurriedly, I began repeating the order as many times as I could before close, knowing that, should each of these orders go through, some of my own funds would be used and entered into a position which I did not really want to take. However, I felt it better to potentially sacrifice some of my own funds to fulfill my word. I was able to repeat the order at least three times before close.

That is what you need to explain. Tried the "it's the ISP", it didn't stick, tried the "we'll investigate", nobody cares, tried whatever else, that didn't stick either. You were caught manipulating the close price, period.
hero member
Activity: 674
Merit: 500
SECOND EDIT: This is all horribly off topic, isn't it?
I'm concerned with rude spam by MPOE-PR (https://bitcointalksearch.org/topic/heres-where-i-spew-my-accusations-against-mpoe-all-are-welcome-102333 ).
Other related people (smickles) are behaving quite good, and we had useful discussions over support email.

I will consult with [Tycho] about further actions.
sr. member
Activity: 446
Merit: 250
I believe, in this case, a STAT would determine if the order was accepted or not.

I believe STAT wouldn't be aware of packets which are in flight but haven't yet reached servers.

But this is largely a theoretical problem since you can simply wait a bit to make sure that all data in flight either arrived or died peacefully.

Also I hope that if MPex sees two identical orders it would ignore duplicate, so even if you submit twice it is not a problem.(?)
Yeah, if you submit the same data twice, it rejects the duplicate. It must be duplicate data tho, not just 'the same order'.

EDIT: so basically, don't resign a 'new' order, just resend the same signed/encrypted message as you did originally.

SECOND EDIT: This is all horribly off topic, isn't it?
legendary
Activity: 1022
Merit: 1033
I believe, in this case, a STAT would determine if the order was accepted or not.

I believe STAT wouldn't be aware of packets which are in flight but haven't yet reached servers.

But this is largely a theoretical problem since you can simply wait a bit to make sure that all data in flight either arrived or died peacefully.

Also I hope that if MPex sees two identical orders it would ignore duplicate, so even if you submit twice it is not a problem.(?)
legendary
Activity: 1022
Merit: 1033
You miss the point. The Byzantine generals situation would be akin to completely cut. communication, no technology will help here.

See my reply to MPOE-PR. Use of simple HTTP requests is a bit too fragile: any network congestion can leave order in a dangling state where it can arrive to server at any time. And checking that won't help you, as you're checking current state, but you cannot remove packets which are already in flight.

And colored coins are still vulnerable to doublespend attacks if not done properly.

Colored coin exchange will be based on "atomic coin swap" transactions. Double-spend can only cancel such transaction if it is included into blockchain faster, but it won't be possible to steal anybody's coins.

There is a lot of other useful traits:
  • after you've got counter-party's signatures you'll be able to demonstrate that he isn't trustworthy if he double-spends
  • transaction is either included into a block or it is not, there is no dangling state
  • you can chain several transactions together, if one fails due to double-spend dependent transactions will get canceled automatically

GPG has years of development and fixes behind it and allows for immediate verification without waiting for blochchain confirmations.

Um, what? GPG is simply a digital signature/encryption software. Bitcoin transactions are also digitally signed, but they are also included into blockchain to ensure there are no double-spends. It's an extra protection on top of what GPG can provide.

sr. member
Activity: 446
Merit: 250

Now let's consider a bit more complex case: suppose that packet which was carrying request body was buffered at some router between user's computer and MPex server and was "in flight" for some considerable time, e.g. 1 minute. It's possible in case of congestion, packet loss/retransmission, routing problems etc.

In that case we can a situation like this: 1) user clicks "stop" button in browser, but it doesn't stop packets which are already in flight; 2) user checks state, it says that order is not accepted; 3) now those packets which are in flight arrive to server and it actually accepts the offer. Whoopsie.
I believe, in this case, a STAT would determine if the order was accepted or not.
legendary
Activity: 1022
Merit: 1033
Well, since we're discussing this: your computer sends a SYN. The MPEx server goes SYN-ACK. Your computer goes ACK. The TCP connection is not established. Your computer goes POST. The MPEx server responds to that POST. Your failure scenario was that somehow right after the POST but right before the response completion the connection drops. This scenario is possible in theory, but not quite comparable with the general "oh maybe the connection failed we'll investigate" alternative.

I'm rather bored with this discussion. You are dense. I'll try to spell it out for you one more time, but this is the last time...

OK, let's consider it from user's perspective. User tries to submit order to MPex. His user agent "hangs". User doesn't know whether his order was accepted. He waits for some time, let's say 30 seconds, then clicks "stop" button and tries to check whether order was accepted by other means.

Let's say order was not accepted, then user will try to re-submit it.

Suppose it was time sensitive like it was with smickles order. How is MPex going to explain why order wasn't accepted immediately? Most likely response is "oh maybe the connection failed we'll investigate": connection failure is indeed the most likely cause, but it is a good idea to check server logs.

If user was running Wireshark, or maybe just in-browser debugger like firebug, he would know more about this failure, but let's just say a typical user doesn't run Wireshark so it doesn't matter.

Now let's consider a bit more complex case: suppose that packet which was carrying request body was buffered at some router between user's computer and MPex server and was "in flight" for some considerable time, e.g. 1 minute. It's possible in case of congestion, packet loss/retransmission, routing problems etc.

In that case we can a situation like this: 1) user clicks "stop" button in browser, but it doesn't stop packets which are already in flight; 2) user checks state, it says that order is not accepted; 3) now those packets which are in flight arrive to server and it actually accepts the offer. Whoopsie.

It isn't simply theoretically possible, this actually happens. Say, when I use ssh sometimes it freezes and I see what I typed after a significant delay.

So... How is this different on ICBIT? I don't know. As I understand, there is no progress indicator, but it is not a fundamental flaw, it can be trivially added. Otherwise, situation is identical.

It is completely independent from transparency issues, I agree that use of PGP signatures and full transaction log are desired features.

But that wouldn't have helped smickles. On the other hand, Wireshark could: he could see whether he got SYN-ACK and whether server ACKnowledged that it received POST body. Having that log he could prove that problem is indeed at ICBIT's side. (Sort of, ACK isn't signed... But it would be a good evidence.) Unless ICBIT blocked him via IP address on firewall (iptables TARPIT). Then he would need to use pathping to collect evidence...

Anyway, you need to learn a bit more about how networking works (just knowing about SYN-ACK isn't enough), and how to consider concurrency problems (i.e. you need to consider all possible event orderings for all participants). Also you have serious problems with logic. ("MPex uses PGP signatures, and thus ICBIT sucks". Really?)
sr. member
Activity: 446
Merit: 250

The one thing I find most disturbing about accusations, is that most humans seem to accuse others of those faults, flaws, and outright criminal behavior, that they themselves are guilty of. MPOE-PR, you post about pretty much every other trading related site, in a negative way. I'm starting to wonder how many of your accusations are based in MP's own behavior (and not that of the competing exchange being accused). That notwithstanding, MP's opinion on other exchanges has been pretty well-founded, and predictions of doom have oft been correct. So...................
spooky
hero member
Activity: 756
Merit: 522
Ehm... Suppose there is a connection problem and you DIDN'T get a signed receipt.

Well, since we're discussing this: your computer sends a SYN. The MPEx server goes SYN-ACK. Your computer goes ACK. The TCP connection is not established. Your computer goes POST. The MPEx server responds to that POST. Your failure scenario was that somehow right after the POST but right before the response completion the connection drops. This scenario is possible in theory, but not quite comparable with the general "oh maybe the connection failed we'll investigate" alternative.

Moreover, your transaction will still show either in the book (which MPEx publishes) or in the trade stream (which MPEx also publishes). Alternatively, if the connection failed before that magic moment, the transaction simply wouldn't ever be issued (which again you can verify in the same manner). Again comparing this with something as vague as "we'll investigate" and "we don't publish anything but we keep private logs of all trades which then we retroactively edit without announcing it, explaining it or even admitting it" is quite the stretch.
sr. member
Activity: 340
Merit: 250
GO http://bitcointa.lk !!! My new nick: jurov
At the very minimum you get MPEx signed receipts, so you can clearly prove what happens, rather than the situation here where the site does something,

Ehm... Suppose there is a connection problem and you DIDN'T get a signed receipt.

Now what, can you prove that you HAVEN'T got it? You don't even know whether server registered your trade or not.

Do you know a story about Byzantine Generals? Look it up.

BTW trade via colored coins will be Byzantine fault tolerant in some way (due to use of Bitcoin protocol which is Byzantine fault tolerant), while simplistic HTTP-based trade won't be, ever. (Not that it matters that much, but it's nice.)
You miss the point. The Byzantine generals situation would be akin to completely cut. communication, no technology will help here. And colored coins are still vulnerable to doublespend attacks if not done properly. GPG has years of development and fixes behind it and allows for immediate verification without waiting for blochchain confirmations.

In case of MPEx, you are supposed to issue STAT call to verify your order whereabouts, you get signed response for that as well. Alternatively, all orders are shown in public market depth data and all trades go to twitter.. So this problem is practically solved,  you do have tools to get the information beyond doubt. It will be better to ask such transparency from other exchanges instead of waiting for some colored coins wonder that will supposedly solve all problems.  
legendary
Activity: 1022
Merit: 1033
So basically, here's a bucket shop working suckers out of a few bitcoins a day. MP comes by, risks a few hundred BTC of his own money, establishes some points.

Evidence he collected so far isn't enough, IMHO.

Your retort is that "he's a pussy" because he's not dumping more money into the scam.

Well, if he wants to continue with accusations, he probably needs to dump more money.

But I was commenting on your "moral compass" comment. Clearly it is not about moral compass, it is about risk. You just didn't know how it works, did you?

Are you in any way involved?

Well, I have ~4 BTC balance on ICBIT now. Also I discussed futures exchanges with Fireball is summer of 2011. That's all.
hero member
Activity: 756
Merit: 522
Maybe I'm missing something, but to prove his point MP just needs to up the ante. If ICBIT is a bucket shop it would be out of business (or MP will be out of his money, hehe).

So basically, here's a bucket shop working suckers out of a few bitcoins a day. MP comes by, risks a few hundred BTC of his own money, establishes some points. Your retort is that "he's a pussy" because he's not dumping more money into the scam.

Are you in any way involved?
legendary
Activity: 1022
Merit: 1033
Unlike you (apparently), MP has a moral compass.

Oh, I see. So punishing "the manipulator" OR scammy exchange operator is against MP's moral. I knew it.

Maybe I'm missing something, but to prove his point MP just needs to up the ante. If ICBIT is a bucket shop it would be out of business (or MP will be out of his money, hehe).

Or did you mean that MP is a pussy who cannot put money where his mouth is, and that is his moral compass?

Girl, please stop trying painting MP as a saint. He got some evidence against ICBIT, we get that. Pushing it further just doesn't look good. You don't seem to understand all intricacies of the business, and cheap propaganda just doesn't work.
hero member
Activity: 756
Merit: 522
Which means that MP got some good profit out of this. And now he's complaining?

Yes.

Yeah, I, too, hate it when I have profit.

Unlike you (apparently), MP has a moral compass.
Pages:
Jump to: