A Miner Problem

As announced in #bitcoin-assets, BitBet was attacked earlier today through a transaction withholding mechanism. The attack unfolded as follows :

  1. A BitBet bet (Jeb Bush will be Republicans' 2016 Presidential Nominee) was closed and resolved on 21 February. This created a list of winners with a reasonable expectation to be paid their winnings.
  2. A first transaction was broadcast, to satisfy the claims of the winners, spending some inputs, and offering a fee of 0. This transaction was, as you'd expect, neither mined nor included in the mempools of most Bitcoin nodes.
  3. A second transaction was broadcast, spending the same inputs as A1, including a fee of 0.0001, call it A2. For a ~1.5kb transaction, this fee is on the low side, so it perhaps could be argued that it not being mined would be expected. Nevertheless, transaction A2 was also not included in the mempools of most Bitcoin nodes.
  4. As neither transaction A1 or A2 were mined after 54 (48) hours, a further transaction was broadcast, spending the same inputs as A1 and A2, and including a fee of 0.000175, call it A3. By any measure, a fee in excess of 10 satoshi per byte should be sufficient to have transactions mined. Nevertheless, contrary to expectation, transaction A3 was not included in either a block or the mempools of most Bitcoin nodes.
  5. After a further 48 hours, a fourth transaction was broadcast, spending the same inputs as A1, A2 and A3, and including a fee of 0.00022, call it A4. Just like the previous three, transaction A4 was not either included in a block or advertised by most Bitcoin nodes.
  6. After a further 16 hours, transaction B was broadcast, that included the same outputs as transactions A1-A4, but different inputs. Transaction B, like transaction A4, included a fee of 0.00022. Transaction B was advertised by most Bitcoin nodes immediately thereafter, and was included in a block within half hour of being broadcast.
  7. Two hours after B was included in a block, transaction A1 was re-broadcast by an unknown third party. Twenty minutes later, the 0 fee, week old, not-advertised-by-anyone-ever transaction was included in a block.

On the basis of these events, the following allegations can readily be supported :

  • That the notion of "a majority of Bitcoin nodes" is void of content, most of the relay network being under the control of the same entity and supporting functionality not contemplated by the Bitcoin protocol (such as selective mothballing of specific transactions).1 This specifically means that "someone"2 has the ability to nuke transactions out of the network irrespective of whether they are validly signed or not, directly replicating functionality already available to fiat governments in fiat payment processors such as Visa or Paypal.
  • That a cartel of Bitcoin miners is deliberately and systematically withholding blocks for an interval of about 20 minutes to a half hour, so as to ensure themselves a (significant) advantage over any would-be competitors.3
  • That neither above item makes sense or could long survive without the other, meaning that necessarily the culprit is one and the same. Note for the record that an entity controlling 51% of the network (as is by a large margin the case with the Antpool/F2pool cartel) can safely withhold blocks for an indefinite period – if a competitor publishes a longer chain all the cartel has to do is keep mining on its own, eventually they'll prevail.4

Note that there are no alternative theories that more parsimoniously explain the chain of observed phenomena, and consequently the validity of the above allegations is a matter of objective truth. One may disagree on the strength of subjective feeling, or put forth his own interpretations, but these – much as in the case of alternative explanations for biological evolution – suffer from a fundamental logical weakness.

Update March 2, 2016 18:49 UTC:  In a further development on this story, Bitbet has now announced a moratorium on payments until the issue is resolved. (N. ed.)

  1. You should remember that the Bitcoin relay network has for many years been in very poor shape – there were as little as 60 nodes active last year around this time. Since then the situation has only deteriorated – the jury is still out as to whether BlueMatt's doohicky actually helped or hindered while it was functional, but there's no argument that the network degraded YoY. 

  2. Who, according to your own preference, may be the NSA or the Antpool/F2pool cartel. 

  3. The A1 transaction wasn't broadcast and then included in a block – at the time it was broadcast, the block containing it had already been mined – it simply hadn't yet been shared with the rest of the plebs is all. 

  4. 51% means that out of a day's 144 blocks, one has 74, and consequently gains a 3 block advantage over a competitor chain every single day..It is true that the cartel does not generally wish to advertise its presence (yet), and so to date they've avoided major reorgs. Bear in mind however that it is also the case that the remainder minority is not united but fragmented – so they don't actually need to resort to major reorgs. 

69 thoughts on “A Miner Problem

    • If they were independent of one another, their incentives missalignment would essentially force them to fight with one another until one prevails. Except the miners have the printing press, so guess who prevails.

  1. So how many confirmations did transaction B receive in total ? Was it orphaned by a longer chain, and if so which pool mined B and which pool mined A1 ?

    How did you receive the 2:20 hour old valid block containing B ? After that time if should only be orphaned if the pool mining A1 deliberately mined on its own shorter chain for 2h:20m (and/or if there were no block rewards in that time period).

  2. Why broadcast with so low fees? First zero fee and then 0.000175 BTC to ~1.5kb? My personal node, e.g., does not relay tx with less than 0.00001 BTC / kb. And why B has used different inputs? Silly bug, a human mistake or any special reason with bad collateral effect? Thanks for share and congrats for the transparency anyway, lesson learned.

      • Your own client probably re-broadcast the old transaction after a.) being opened and b.) seeing that the transaction had still not confirmed.

      • > Your own client probably re-broadcast the old transaction

        I think you might be retarded, so this won't likely help you, but in general : I'm a guy worth a cool billion bits of the toilet paper you call money when talking into the clown mouth/food pellet dispenser.

        I know it's fashionable to imagine things "happen" to me like they happen to you, because you've seen it all on TV. Here's a hint : TV is not real! There are fundamental differences between us that preclude this cheap sort of "what did MP do ? Hey, I guess he did what usually happens to me" attempt at empathy.

        Thanks for playing!

        • For example, the last time a large BitBet payout was delayed, back in January, MP failed to investigate it properly for several days because he'd forgotten that the inputs to a Bitcoin transaction are specific outputs of previous transactions, rather than simply addresses. That wouldn't have happened to you.

          • The most common thing that happens to me is that random guy on Internet is going to try take something I said and shoehorn it into some pet theory of his. Strangely, that the reverse never happens doesn't seem to give random guy on the Internet any pause.

            Seriously, it's MPs fault that Bitcoin drops txn on the floor ? Because why, no beret ?

  3. It's simple. The A transactions used an input that was unconfirmed due to the congestion, so the A transactions would not confirm regardless of the big fee.

    The B transaction, not having any unconfirmed inputs, went through.

    The A1 transaction inputs got confirmed so a random node retransmitted it, and it made it into the "free transaction" space of a block. Some miners must still have such reserved space available.

    • The A transactions used an input that was unconfirmed due to the congestion

      Which input was that? I see 5 of them, and they have 12`172, 25`383, 3`366, 17`772, and 13`869 confirmations. All of these numbers are significantly greater than the 53 confirmations on the "A transaction" as of this writing.

  4. Why would a node relay A2-A4,when it already knows about A1. A2-A4 are double spend attempts and it is by design in Bitcoin Core to ignore any transactions that include an input that has already been spent.

    Perhaps you want Bitcoin-XT (which does relay double spend attempts).

      • My guess is that A1 counted for double-spend detection purposes but not for inclusion purposes. A node would know two things:

        1. A1 is an attempt to spend.
        2. A1 is not a successful spend.

        A node applying the rule "an attempt too soon after an attempt fails" would reject A2-A4 because of attempt A1, and the same node applying the rule "a transaction with an insufficient fee counts as an attempt but not a spend" would "selectively" know about A1 in this manner.

        • That "too soon" would have to extend to over a week in order to cut out A4 on the basis of a held A1. While it's possible a node somewhere does this, such outlier behaviour is not really germane to the discussion.

          Moreover, the important part is that a 0 fee, low priority transaction was broadcast and included in the space of a half hour. Address that part prominently in your theory, otherwise this "I once also saw a kind of lion – it was a cat" sort of argument was dismissed already.

  5. I was all too ready to dismiss this series of events as "that's what you get for not paying fees" or perhaps even "yay more drama!"… before almost falling off my chair as I realised how well this block/tx withholding hypothesis maps to my recent 'mishaps' with multibit. The inputs from my troubled transaction attempts were the proceeds of BitBets won, so it's not entirely unlikely that the publicly listed beneficiary addresses on BitBet are being marked as verboten downstream as well, not just at the initial payout stage.

    What was that about there being no taint ? Hmm.

  6. RBF is very useful exactely in this case where tx are broadcasted with insufficient fees, and stuck. Unfortunately wallets have not yet implemented it.

    Broadcasting A2-A4 is useless, they are not relayed by the network because considered as double spends, so miners were unlikely know about these.

    "transaction A1 was re-broadcast by an unknown third party"
    Do you have evidence ? Assumption seems unlikely.

    Then why was A1 mined ? Well it was in every nodes mempools and it was valid. Note that every miner have a different blockprioritysize (and thus different inclusion policies) and it has been suggested to miners to re-enable it (blockprioritysize=0 by defaut since 0.12) during the spam attack : https://twitter.com/theymos/status/704527020009500672

    • Would you stop with this "rbf is a solution in search of a problem that thinks it found a problem here" nonsense ?

      A) RBF is not useful. Ever. It's a stupid doohicky made by some irrelevant derp who aims to resolve the existential void gnawing at his inside by "doing things". So he keeps doing things so things have been done so maybe people won't deem him entirely worthless. Think five year old with major guilt and anxiety issues making ruined paper "gifts" for the adults nine times a day instead of once a year.

      B) Once the miners have replaced Bitcoin with their altcoin, you can RBF all you want amd they'll still do what they want to do not what you think they should do. What, you think your piddly F in RBF is going to change their mind, because they're as desperate for an extra penny as you are ? See above and try to understand what the fuck it means. God damned labrats thinking you own the fucking lab, what is this, equality ?!

      The only thing that can save Bitcoin, at this point, is completely breaking down the Chinese miner cartel. Which yes, means bricking all their hardware. It's time to do this, not least of all because having this precedent is extremely important for safeguarding Bitcoin in the future. We must show that we ~are~ able to destroy a miner cartel, or else.

  7. "A first transaction was broadcast, to satisfy the claims of the winners, spending some inputs, and offering a fee of 0. This transaction was, as you'd expect, neither mined nor included in the mempools of most Bitcoin nodes."

    How do you know it was not included in the mempool of most Bitcoin nodes? Why does it matter? It only needs to be included in the mempool of the node of the miner which puts it into a block.

    This is absurd, why would you resend the transaction without first being sure that the first one would not be included in a block? You should have made another transaction A' spending those outputs to one of your addresses, and only publish transaction B after A' gets put into a block.

    • A' that spends the same outputs? You mean inputs right? As the outputs they don't have the keys for. And I think that was exactly what A2 was so not sure what you are suggesting here

  8. Did you try to push your txen through public wifi in McShit or use blockchain.info pushtx? Maybe the blackholer upgraded his toys and went full Force 4th or something. Silently dropping tx for his payout to get m0ar.

    Hash: SHA1

    [01:49:23] [mircea_popescu] so what i'm thinking to do here is, ima write a qntra piece explainint the situation, and we put a banner on bitbet saying something like "Payments of all bets currently suspended due to Chinese miner collusion (see here for details). We're working on a technical solution for this problem."
    [01:50:03] [mircea_popescu] and as a technical solution, what are you thinking ?
    [01:50:43] [kakobrekla] if the tech solution is what i proposed earlier in chan then it can be done rather quickly and no need to put up a banner, if its something else, then i dunno
    [01:51:23] [mircea_popescu] i want the banner up in any case – most of the benefit of the idiots in this comes from me keeping quiet. i'm not keeping quiet.
    [01:51:36] [mircea_popescu] let the matter be well publicized, i say. you disagree ?
    [01:52:22] [kakobrekla] i dont have a problem you publishing your interpretation of events
    [01:52:40] [kakobrekla] and linking to it from a bbet banner
    [01:52:50] [mircea_popescu] alright.
    [01:52:57] [mircea_popescu] you actually think it's not the case ?
    [01:53:35] [mircea_popescu] i mean… explain this to me, i'm interested.
    [01:53:45] [kakobrekla] at this point i dont think that is likely.
    [01:53:59] [kakobrekla] i also cant disprove ufos but i dont think those are likely either.
    [01:53:59] [mircea_popescu] like a gut feeling sorta thing ?
    [01:55:07] [kakobrekla] i believe the culprit of this mess is the fact the first tx had 0 fee on it.
    [01:55:15] [mircea_popescu] go on ?
    [01:56:21] [kakobrekla] and it was after a time dropped out from blockchain explorers mempool.
    [01:56:35] [mircea_popescu] so why was not then any of the other ones mined ?
    [01:58:39] [kakobrekla] that could be a separate issue. perhaps node connectivity. im sorry i havent asked for tx earlier so i would broadcast it myself before it was included.
    [01:59:09] [mircea_popescu] there's a number of discrete elements here, with associated probabilities. let's try and work this together if you have a moment ?
    [02:00:00] [kakobrekla] dozens of one in a million events happen daily
    [02:00:05] [mircea_popescu] in a chain ?
    [02:00:15] [kakobrekla] on this planet, say.
    [02:00:39] [mircea_popescu] butr anyway, this is not about persuading you, more like trying to see if maybe you've got something that'd persuade me.
    [02:01:00] [kakobrekla] honestly i dont think you can be persuaded :)
    [02:01:14] [mircea_popescu] ha! except you've seen it happen like multiple times ?
    [02:01:24] [kakobrekla] have i ?
    [02:01:42] [mircea_popescu] well i dunno, it was certainly in teh logs.
    [02:02:06] [kakobrekla] oh you mean your persuasion. yes possibly.
    [02:02:13] [mircea_popescu] huh ?
    [02:02:42] [kakobrekla] i thought you mean i have seen one in a million event multiple times
    [02:02:43] [kakobrekla] nevermind.
    [02:02:55] [mircea_popescu] oh oh. ok, so moving to the solution :
    [02:03:01] [mircea_popescu] explain it slowly and with small words again for me ?
    [02:04:49] [kakobrekla] the tx in question did not get included in block in a decent time because 0 fee and relatively small coinbase
    [02:05:21] [kakobrekla] it got dropped from blockexplorers mempool after that decent time ran out
    [02:05:42] [mircea_popescu] there's a number of txn.
    [02:06:02] [mircea_popescu] ~one every two days for the interval.
    [02:06:04] [kakobrekla] it didnt got dropped from mempool of some other mempools for which you dont know what those contain
    [02:06:20] [mircea_popescu] yes, but it's not just one. they were all dropped ?
    [02:06:21] [kakobrekla] (im talking about the one in question)
    [02:06:36] [mircea_popescu] no, that's the thing. the bitbet bet was attempted to be paid by a succession of transactions.
    [02:07:07] [mircea_popescu] the first of which had 0 fee. the 2nd had 0.0001. the next 0.000175. the next 0.00022 etc.
    [02:07:17] [mircea_popescu] eh too few 0's
    [02:07:30] [mircea_popescu] no, that's right. 0.00022000
    [02:07:54] [mircea_popescu] ALL these ~happened~ to somehow drop out of mempools ?
    [02:08:10] [kakobrekla] all these for the same 'jeb bush' bet right ?
    [02:08:15] [mircea_popescu] yes, and using the same inputs.
    [02:10:06] [kakobrekla] and those showed on bc.info and elsewhere ?
    [02:10:14] [mircea_popescu] they showed ~nowhere.
    [02:10:25] [kakobrekla] aha thats a clue.
    [02:10:51] [mircea_popescu] which is why i was raging in the logs earlier this morning, after the 4th in that chain was still not visible, after ~10 hours of hourly rebroadcasts.
    [02:12:27] [kakobrekla] it could be you are connected in a pocket of nodes. it could also be some anti-double spend code somewhere. it could also be something i dont know at the moment.
    [02:12:30] [mircea_popescu] so then, upon advice, i sent it separately. and it went through within half hour. AFTER WHICH somehow the txn was magically found, and… this time it wasn't dropped from mempool ? what changed since last week, mempool is even bigger now.
    [02:12:43] [mircea_popescu] well sure, it could be many things, in a very theoretical view of the matter.
    [02:13:47] [kakobrekla] why would the 0 fee tx pop up later and not the 0001 or 000175 or 00022 one? it would make more sense.
    [02:13:59] [kakobrekla] if your theory is correct, anyway.
    [02:15:04] [mircea_popescu] how so ? if YOUR theory were correct, the 22 one would pop up.
    [02:15:31] [mircea_popescu] but if my theory is correct, they picked whichever one they figured would be more defensible.
    [02:15:54] [mircea_popescu] the 22 one wouldn't make such a good "mystery" story, so i can see the logic of the ~deliberate~ choice.
    [02:15:56] [kakobrekla] if YOUR theory were correct, the 22 one would pop up. << not if you are connected to nodes in a pocket.
    [02:16:06] [mircea_popescu] but if you say the choice was not deliberate, then yes, you must explain why not any of the others.
    [02:16:10] [kakobrekla] which goes along 'those txes werent seen anywhere'
    [02:16:23] [mircea_popescu] by this same theory, "not if i'm an idiot", also.
    [02:16:28] [mircea_popescu] which, granted, is a possibility.
    [02:16:38] [kakobrekla] however the 0 fee tx was visible on block explorers?
    [02:17:22] [mircea_popescu] nope.
    [02:17:26] [mircea_popescu] none were.
    [02:17:44] [mircea_popescu] and we're not discussing block explorers per se. i run my own proxy network.
    [02:18:02] [kakobrekla] its important to know what other nodes see.
    [02:18:35] [mircea_popescu] agreed.
    Version: GnuPG v1.4.11 (GNU/Linux)


  10. Hey MP! I read your comments here and in the logs. What you say about the miners may well be true, but when it comes to Bitbet's misfortune and talk of breaking the protocol, the main culprit is…you.

    Bitcoin was designed and is intended to work with anonymous addresses. You've been breaking this aspect of the protocol with a vengeance and for years. Pretty much since forever, actually. More power to you, but it was going to come home to roost one day, eventually. Today it did.

    Why do the miners know which transactions are yours? Because you publish them. Why do you publish them? I understand why, of course, your thoughts about anonymity are well stated and very persuasive. For things like WOT, PGP keys, irc nicks it works, it even works very well. Why do you think it would work with Bitcoin transactions? It is specifically not a design assumption, you are like the man who, after riding horses, donkeys, mules and the occasional cow one day attempts to ride the Ford pick-up. It may very well work, for a while. Eventually it will come to tears.

    You think Bitbet benefits from the open display of bets and payouts? Fine! Publish them for paid-out bets. Publish a shortened version for active bets, first few digits of the amount, a fragment of the address… publish hashes of the whole data, deedbot them, anything you'd like. Why publish the whole thing, plain text, all the time? What did you imagine would come out of that rabid, unthinking transparency besides empowered attackers?

    Yes the miner cartel is the threat at the moment, as far as Bitcoin is concerned. It isn't any sort of threat for BitBet, or at least it doesn't have to be. Fix the design of the betting site to match the design assumptions of the payment processor it intends to sit atop, for Chrissakes!

  11. The unknown third party could be my node. As described my node would only contain transaction A1 and B. It would rebroadcast both at regular intervals. A2-A4 would not be accepted as long as A1 exists.

    1. My node is patched to reserve a part of my mempool for high priority transactions regardless of fee. It means that A1 will get accepted, and not eviced as long as the priority is sufficient. Since A2-A4 collides with A1, my node won't accept any of them. The unknown third party rebroadcasting A1 could be my node, or any node with a long uptime and very large mempool, or a very old node with no limitations on mempool or throttling of 0-fee transactions.

    2. Most miners/pools run with default -blockprioritysize=50000. Which means 50kB of every block is reserved by transactions sorted by priority, regardless of fee. The profit loss is very low, because most high priority transactions pay fees as well. Most nodes will throttle 0-fee transactions, but not deny them unless they run 0.12 with a full mempool.

    3. The priority of a transaction increases for every block.

    4. Since A1-A4 and B spend different inputs, one of both will eventually get mined, unless one of them is evicted from every mempool on the network. It is impossible to prove that a tx has been evicted from all mempools. I have filtered several nodes and netblocks for spying, and this includes known block explorers. I have however -addnode to many pool nodes to get my transactions reliably through.

    Unfortunately it is very hard to get a transaction respending inputs from a different transaction relayed. E.g. mine will keep A1 and ignore the rest. RBF will fix this for transactions where the RBF flag has been set.

  12. I'm a guy worth a cool billion bits of the toilet paper you call money

    This is a rumour we've heard more than once. It might be an idea for Mircea Popescu to spend half of that money and start up a mining operation to take direct control of what transactions get processed. Sitting on a billion in toilet paper is pointless unless you have a lot of stuff to wipe.

  13. TL;DR BitBet sent zero fee transactions, resent one with other inputs, is surprised when both get mined, blames nebulous Chinese conspiracy.

    Make Qntra great again

    • Tweaking the block size is not the magical solution you think it is. It could happen with 1 GB blocks because miners and pools have various mining and relaying policies. It also doesn't mean that miners will actually create bigger blocks just because they can, especially to include free transactions.

  14. Operator of Fairlay.com here.
    My first impression was: wow, they can't handle payouts – even more people will join Fairlay now. However – I now can admit that we had a similar problem. We broadcasted a transaction with 0 fees: https://blockchain.info/de/tx/50c87fcd60a999fd27e7b31e2258de45c5ba8f97ffde8de32e3399e8c862b463 2 days ago. Since the transaction was not mined and it was not visible in any memepool according to our node, blockchain.info and blockcypher we created a second with similar inputs and outputs. A few hours after this second transaction the first was mined. Out of curiosity – what pool mined the A1 transaction? And are you sure you saw the transaction in the mempool again before it was mined?

  15. So I had a thought to explain the first transaction showing up later. Various clients will each have their own rules for accepting and transmitting transactions. Perhaps one of the original recipients of the transaction accepted it, but was not directly connected to any miners who would accept it. Periodically, nodes will disconnect from some peers and connect to others. So as time went on, eventually this node which was holding onto the transaction connected to a miner who would accept it, and stuck it into a block. Since it is a low priority transaction, even though the original node and the miner had it, it still would not be visible on the network overall, and so it seemed to suddenly appear in a block.

    It seems an important point, but was left out of the article, which Mircea Popescu revealed later in IRC, that the first two transactions were sent to different sets of nodes. It is possible, therefore, that there was a 50:50 chance of either A1 or A2 being included in a block, and the circumstances happened to result in A1.

  16. Unfortunately I do not feel comfortable making any more bets until this is resolved. Seems like paying a transaction fee is a reasonable solution.

  17. So – let me get this straight – you're accepting bets and deposits and then you're not paying out, but keeping all of the money. Looks legit. Do you have offices in Japan and a space-hopper by your desk by any chance?

  18. which chances the bettors have to get their funds refunded?
    at this point I don't mind winnings paid. The original bets I deposited are enough. keep the winnings, keep the BTCs of those who have lost.

    I think this is a reasonable exit for everybody

  19. Hi moderators/admins,

    Could you please share an update as to the status of payouts for the Alphago bet? Wondering when I'll be seeing a payout, or at the very least, the amount I put into the bet back. Thanks,


    • Please have patience in the matter. Mircea needs to pay for his skiing holiday in Gstaad first. Then we can see how much change is left.

  20. Guys, I have something important to say about this mess. PAMP – people around MP (of course, I don't know that for sure, maybe it's just Kakobrekla).

    1) In January I emailed MP / Kako asking whether they have a contingency plan. See below.

    2) When PAMP receive profit then that is cool. E.g. January 2016 brought them 93 BTC (also consider 24 BTC unexplained expenditure on Tech). We can also presume that most dividends are received by PAMP. Honestly who would buy some fucking shares if you have to pay 50 BTC (!) just to be allowed to do it?!

    3) But when PAMP encountered a loss (not the biggest in history of Bitcoin):
    "Bitbet, of course, holds no assets and consequently should in principle be dissolved on the first loss month." How is it possible to grudge a supersmall 0.001 fee? It's less than a cup of coffee!
    I do not run enterprise like PAMP and I'm an amateur however I always pay a fee.

    4) Just 1 comment: "So when MP receives double pays or mistaken pays or delayed pays, he keeps. But when it's his turn to fuck up, he's forgiven?"

    5) Google for "Romanian Billionaire Saves OpenBSD". Of course, it's MP's money and he may do whatever he wants. This is a ground for 6) b).

    6) Real missing (overpayed) amount is 4.37 BTC, not 17. Is 5 BTC really a tragedy comparing to:
    a) the revenue generated by BitBet?
    b) assets of rich MP?

    7) Now do you recall someone saying "yes there are contingency plans"? Here is a cont. plan: without extensive consultation with bettors MP or PAMP made a decision to transfer all our assets to "senior lord of Bitcoin".

    8) Mentioned lord already owns 13.37 BTC out of 750 transferred to him. Yes, I am nobody in BTC community, but I would gladly do the liquidation of BB within 3 months for 3 BTC.

    9) But NO liquidation was needed!! 750 BTC on one side and 5 BTC on another. WTF??

    Can anyone tell me if I am wrong at any point? One lady from Argentina just managed to state that I'm retarded, and that's it.

    Shortened email and reply
    Or maybe there is just one such person – M.Popescu (as I know, he established BitBet), and if something happens to him then business halts, full stop?
    So the main questions are:
    1) Is there any contingency plan?
    2) Have you considered adding a section describing this issue in FAQ?
    yes there are contingency plans. no they will not be discussed, with anyone.
    not until after we've salted the earth where the last "parliament" / "presidential residence" etc stood.

  21. Hey mods, what's the latest? Doesn't sound like there's much traction with people getting their payouts… How is the site still taking bets if payouts aren't being sent?

  22. So the alphago bet is now resolved. I haven't been paid and I checked a lot of other peoples payouts and none of those transactions have gone through. What's going on?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>