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

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.

I was explaining so other could understand why it's needed. I did not even think you complained :-)

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.

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


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.


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


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.


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.


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.


That's a good idea, actually.

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.


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

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


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.


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.


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.


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


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!


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.

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.

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?

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.(?)

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.


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

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.

I believe, in this case, a STAT would determine if the order was accepted or not.

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?)

spooky

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.

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.  

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


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?


Well, I have ~4 BTC balance on ICBIT now. Also I discussed futures exchanges with Fireball is summer of 2011. That's all.

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?

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.

Yes.


Unlike you (apparently), MP has a moral compass.