Bitcoin.com’s new “Trading Platform” really just for online gambling?

No KYC?? Yikes! Risky. That is just thumbing your nose at the FBI isn’t it?

 

Bitcoin.com recently launched a new trading platform. Bitcoin.com Trading
Except that they don’t list it as a trading platform, as that would fall under the new FINCEN guidelines, and potentially land them in trouble with the law.

 

Even if we believe Bitcoin.com’s pitch that his exchange is for trade, it is probably more useful for unlicensed betting. Why?

From their own FAQ:

https://local.bitcoin.com/faq

Oracle needs only to decide offline who the “winner” is. The oracle cannot arbitrate a settlement or change the payout of the escrow in any way.  Bitcoin.com is calling this “Blind Escrow” service, where the ‘escrow’ is not really custody of any funds, they just decide the winner of the pot.  This is not escrow at all.  This is bookmaking, just thinly disguised.  This is allowing online betting in a trust-less way. (or not having to trust the bookie… or do you? More on this later)

As an escrow-ed exchange service, Bitcoin.com’s trading platform is not any better than standard escrow contracts.  So it is a POOR replacement for the service that they are ostensibly trying to put themselves off as.

  1. Why? Think of this example:
  2. Alice agrees with Bob to buy 100 DASH for 10 BCH.
  3. Alice locks up 10 BCH into Bitcoin.com’s blind escrow contract.
  4. Bob never pays Alice the DASH, but tells Bitcoin.com that he did
    Bitcoin.com (oracle) investigates and asks Alice if she received the the 100 DASH

    1. If she has (and bob has paid): (ignoring for a moment how she can prove this) then the oracle signs the txn and gives to Bob
    2. If she has NOT: (once again, ignoring the problem of proving this) then the oracle signs the txn and gives it to Alice.
  5. Alice OR Bob, gets the FULL 10 BCH, that is the only 2 outcomes…. OR IS IT?
  6. The third outcome is that Alice refuses to sign the txn to Bob, AND the Oracle is given a cease and desist order to stop signing txns as it is acting as an unlicensed exchange market operator, which means it cannot sign. This means Alice’s 10 BCH LOST FOREVER

Compare this to the standard Escrow contract in Bitcoin, (using Multi-sign or thresholds sigs) where if the escrow company is shut down for whatever reason, the 2 parties (despite their dispute, may be able to broker a compromise and send the 10BCH to a new Escrow company who can arbitrate a mutual settlement between Alice and Bob. There are countless reasons why Bob may refuse to pay the full original agreed amount of 100DASH to Alice…. perhaps the market crashed and Alice delayed the trade, perhaps there was a fork, and Bob doesn’t want to send pre-fork coins. etc. etc. etc. In these cases, it may be necessary to renegotiate the amount that is paid to which party, as well as perhaps pay a new escrow additional fees.

The real world is full of agreements that need to be renegotiated everyday. Bitcoin.com’s exchange does not allow for that.

The way they have it currently setup, even though they advertise it as ‘trust-less’ ironically means that the seller has to bear the risk of trusting that the trading platform is not forced to stop their service in the middle of a transaction that has gone bad.  Which will limit the amount of legitimate uses for this system.  The kind of activities or actors which won’t be too fussed about this? You guessed it, illegal actors, gamblers, money launderers.  They will be willing to take the risk, because they have no where else to go to be served.

In truth, the PROPER way to handle this type of peer-to-peer swapping is via an atomic on-chain swap which swaps the keys on both sides at the same time, coupled with a timed refund txn. (one of nChain’s patents).  If the deal were to go bad, then the parties can always seek a licensed escrow to provide an arbitration service, for a fee.

More on that next time.

/EOL

/begin Metanet

The Bangkok Summit: The failed last attempt to prevent the BCH Split

So the BCH fork is over.  And one party sort of cheated by bringing in their mercenaries to fight the war, and to usurp their BCH chain for themselves, which was not miners who have been mining the chain for the since BCH’s birth.

But leaving all that politics behind, I would like to leave the official record of the Bangkok meeting which took place in Aug 30th 2018, in which the ABC and the nChain group and chinese miners tried to keep BCH together as one blockchain.  I leave the whole record here for you to do your own research, as nobody has since had the time to create a transcript of the record, but I will give you some very important timestamps so you don’t have to listen to the whole 3 hours…

The infamous Bangkok Summit.  The last time the BCH community was in one room… and also the inside story of the fork split that crashed the whole crypto market.

Bangkok BCH Miners and Developer Summit Aug 30th, 2018

To save you from having to listen to the whole 3 hours (it has yet to be properly transcripted), I will give you the timestamps of some of the highlights.  But I encourage those who are true truth seekers to listen to the whole thing.  Don’t take my word for it.

I’ll skip the initial 3 or so presentations, which was just the hosts welcome, BU’s chat, ABC’s presentation, and nChain’s plea for quicker scaling.  Jumping straight into the panel discussion with Amaury (head ABC dev and self declared ruler of BCH), Shammah, (2nd in command ABC dev), Steve Shadders (nChain head dev), and John Fletcher (nChain head researcher).  This was the infamous panel where CSW, “called bullshit and left the room”.

Panel Discussion with the nChain and ABC devs (timestamps by VLC player)

Apologies, I was made aware that the timestamps may differ a bit depending on your player. I used VLC.

1:12:04 is when ABC Jason Cox and Shammah starts giving reasons why the block size cannot be lifted at this time.

1:13:35 is when Amaury starts talking about how the block size cannot be increased because there is an attack where an attacker can send an SPV node an endless stream of txns and they cannot know they are invalid txns until they stop and they can actually verify it with the MERKLE root.  This is the flat lie, (or it shows how Amaury is already assuming that Bitcoin uses his proposed MERKLIX tree idea (currently in the roadmap for BCHABC) because using that data structure it is INDEED true that you could attack a SPV node this way.  But why CSW left in disgust (unknown to many at the time because people didn’t recognize Amaury’s lie) was that MERKLE trees have a certain depth, and all txns are at that same depth. That means once you get ONE txn, you can hash it up to the merkle root and you know the depth of the tree, and thus the total max number of txns that you should be expected to receive in the block.  To understand this, all you need to know is simple geometry. A merkle tree is a tree structure in the shape of an equilateral triangle. (with the exception of the last row, which may be incomplete), that means, once you know the height of the triangle, and span of the base of the triangle, you know the area of the triangle. (it’s a close enough analogy).  Thus, CSW was right, and Amaury was either being deliberately deceitful, or just forgetting how Bitcoin works, and maybe thinking more about how his version of BCH would work after CTOR and merklix trie implementation. (where it no longer has a triangular shape, so the depth of any given txn would not give you any information about what the maximum number of txns in the block would be.

1:40:18 Andreas Suisani (BU dev) talks about how blocks aren’t full yet, so it’s not a priority.

1:41:18 I speak about the need for blocks to be bigger than the actual use patterns observed, because businesses need to see the block space being available BEFORE we even fund any projects that will use the space.

Discussion about what the current problems that need to be voted on:

2:59:30 —  The question of block cap size raising starts to get discussed.  The discussion gets bounced around back and forth on the issue of whether or not the block cap should be increased before the businesses start using it or after it starts to be obvious that it is needed.  Many people chime in on this including Emil from Bitcoin.com, Roger, Jason Cox, Shammah from ABC, and frankly the main question is just avoided and dodged for the next 7 minutes.

3:14:25 I pull the meandering discussion back to the MAIN issues that needs to be resolved here at this summit, namely, the question of whether or not these CTOR and block limits issues are important enough to split the fork over.

3:19:05 Amaury starts whining about how CTOR was agreed but nChain later disagreed and left and then wasted everyone’s time by leaving the dev discussions. (those discussions were done in Chatam house rules and no transcripts were kept.)  His argument that CTOR was agreed by the devs who attended those private dev meetings is his only real defence of why CTOR should be included in the Nov 15th fork NO MATTER WHAT nChain (with Coingeek, the largest mining group) says.  Pretty much the devs are the ones that make the call.  Miners shouldn’t need to care, just need to agree with them.

BIP135 was mentioned by Dagur and Andreas as a way to resolve the dispute by the miners, but none of the chinese miners seem to be supportive of it.

The rest of the discussion (if you really want to bear through listening to it all) is ABC devs consistently focusing on the need to improve communications with miners (basically how to educate miners about the things that the devs have already decided in their private dev meetings of which they kicked nChain out of)

3:24:45 I summarize the whole day and the ideological question that is posed to all the BCH community.  I called out the ideological differences in the scaling strategies.  The answer to my question was when I realized that BCH was dead.

This was the last time the BCH devs, miners and community was all in one room. It was apparent that after this meeting, the existing BCH community was already fractured.  There were the anarchists that want to push the agenda of a grey market platform, to compete with DASH or Ethereum using Wormhole and ICOs, or whether or not we should just focus on scaling via the original Bitcoin model and let all the businesses build the ecosystem.

This is why we now have BSV and BCHABC aka BAB.

There was no way that the people at this summit was going to agree on these fundamental differences.

There was just too much individual agendas at play, and too much difference of opinion on what was important for the ecosystem, and what the developers roles to play vis-a-vis miners were.

I went to this meeting to try to find some common ground to prevent a BCH chain split.  What I found out was that one side (ABC) was already determined to split no matter what.

Now you all can decide with your money.  Each chain is separate, and only one is maintaining the original goal and roadmap of Bitcoin.

/EOL