2016-04-25

Nobody needs Counterparty - a discussion on needs and wants

About a month ago, I had a comment exchange on /r/Bitcoin with /u/brighton36, the community director of Counterparty. A lot of different points were discussed, but the general argument was that /u/brighton36 believed that there isn't a convincing argument for the use of smart contracts and turing complete language in general, thus making Ethereum an unnecessary project. However, just like that logic could be used to claim "nobody needs Ethereum", similar logic could be used to make a statement that "nobody needs Counterparty". Lets explore whether any of this holds water...

Nobody needs Counterparty


Counterparty was launched around the start of 2014 and is one of the Crypto 2.0 platforms that runs on top of Bitcoin. Their notable feature that sets them apart from most other Crypto 2.0 platforms is their reliance of Proof-of-Burn to issue their currency. The platform offers decentralized exchange between XCP, BTC, and user created assets, although no direct asset-asset exchange, as well as some financial contracts. Their most notable and active assets include LTBCoin, Gemz and BitCrystals, which seem rather negligible in comparison to other platforms.

All in all, Counterparty is a decentralized asset issuing platform for centralized assets - loyalty points, presale currencies, etc. Since it relies on the Bitcoin network, the transactions are slower than the competition, there are no real gateways on the network offering fiat currencies. The network doesn't support asset-asset trading, making it pretty useless for direct FX trading. While Counterparty tried to woo Overstock into using its platform, but that didn't work out too well. The most notable proponent of Counterparty appears to be Adam Levine with his Tokenly project, but hearing what he aims to accomplish with it during a Decentral Vancouver meetup, both myself and other listeners said "you're reinventing Ripple!".

So in general, nobody needs Counterparty - you can issue the same currencies on faster, more established platforms, you can issue them privately on a centralized platform, on semi-centralized Open Assets, partner with some exchanges, etc. There are many other, better ways you can accomplish the same result without using Counterparty. So all in all, you don't need Counterparty, right?

Nobody needs Ethereum


In similar vein, one could criticise Ethereum's smart contracts. They offer unambiguous code execution, you know the code will not be changed during execution, and you can run long-running pieces of software that can use persistent storage on the blockchain. As /u/brighton36 pointed out:

"Unambiguous code execution is already in ubiquitous use today. Package management systems use code signing to detect whether the code being executed is asserted as valid by the issuing party. Open source scripts are in abundance. "

Beyond that, Counterparty has recreated Ethereum on its platform (and Ethereum responded in kind by recreating Counterparty in 340 lines of code). So all in all, you don't need Ethereum, right?

It's not about the need, but the want


When you think about it really, focusing on whether you need something or not because you can accomplish the same task with something else is a silly argument. That's like saying "you don't need Goland, you've got C++", or "nobody needs a screw, you can use nails". So no, nobody needs Counterparty and nobody needs Ethereum, but they are both useful tools in their own right. As long as they are functioning as intended and fulfil a need people have, not necessarily optimally, they are useful. I might prefer to use Ethereum to say, publish my blog because I can / feel like it / it's cool to do that, or Counterparty to issue my local currency because it's convenient / good enough / I like the project. Sure, you can do better in both cases, and in time you might optimize and choose a better platform, but that doesn't mean those projects aren't useful in one way or the other.

The only obvious caveat here are pumps, scams and similar attempts at getting people's money illicitly. While PayCoin might be as useful to transfer money as Tether, it wouldn't be advisable to give money to the former over the latter.

Good projects can flourish if people want to use them, or die if people don't care. Bad projects will most likely burn themselves out eventually. If Ethereum, Counterparty or whatever other project is out there is used by people, even if you can accomplish the same things with something else, let them use it. Claiming a project is "full retard" won't get you very far.

Conclusions


Claiming that "nobody needs project X" because you can accomplish the same task with some other tool or technology doesn't make the project itself useless. People might have many reasons to use the various alternatives, and as long as you can accomplish what you set out to do, that might be good enough for a lot of people.

EDIT:

- It looks like Counterparty has started supporting asset-asset exchange since the last time http://tiny.cc/Crypto was updated.
- As some have pointed out, Counterparty is also used by Storj and Spells of Genesis trading cards, although they haven't been trading much recently, hence why they weren't mentioned

More discussion on the topic can be found here:

2016-04-11

Uphold - a follow-up

Two weeks ago, I wrote a blog post about Uphold's proof of solvency. Since then, I was in contact with Rebecca Geller, a PR, and by her proxy, with Jorge Pereira, chief product & engineering officer at Uphold to discuss the recent concerns with their platform and the perceived insolvency. Having exchanged a few lengthy emails, I would like to present what I learned about the situation and give a more informed opinion on the matter.

Voxels


While Voxels appeared to be an important part of the insolvency claim early on, they don't seem to play an important part anymore. As they are currently held separate from the main currencies and not counted towards the solvency anymore, it should be impossible for them to be used as an asset to cover the liabilities of currencies other than itself.

It is very unfortunate there isn't much publicly available historical data to draw on in trying to evaluate whether the Voxel balance was consistently counted towards the solvency proof when other assets were not enough to cover the difference, or was 2016-02-14 an anomaly. While archive.org does have some records of that page from before February, it doesn't render correctly. Retrieval of the data would be possible, but would take a skilled web developer to decipher. Perhaps in the future, we could see the transparency data being regularly exported to say, Factom, where it could be used for analysis in the future (disclaimer - I work at Factom).

Beyond that, Uphold handling Voxels appears to be a simple deal - Voxelus paying Uphold to list and handle their currency, handle the currency conversion, etc. As long as the currency itself is handled separately from everything else, I personally see nothing wrong or shady in the arrangement.

$38k deficit into a $57k surplus


While the Voxels can be ignored, we are still left with probably the main problem that needs addressing - the $38k deficit turning into a $57k surplus.

On 2016-02-14, Uphold's total obligations to their members was $115M, and assets - $116M. Subtracting the value of Voxels ($109M, $110M), the totals were $5.7M and $5.6M, with a deficit of $38'145.29. On 2016-03-27 Uphold's total reserves were $5'359'978.76 in obligations and $5'417'435.54 in assets, with a surplus of $57'456.78.

In other words, $95k worth of assets appeared seemingly out of nowhere in a span of a month and a bit. This either meant that either:
  1. Voxels were indeed counted towards the solvency in February
  2. The transparency website misreported some numbers
  3. The balances were mismatched due to some recent trades or money movement
  4. The numbers were fabricated
Either one of the four outcomes would show the platform in an unfavourable light, but some would be more damning than the others. 

Uphold explained the issue with option number 3 - the money was in transit between bank accounts and exchanges, and thus wasn't taken into account by the automated system tallying everything and publishing the numbers onto the transparency page. When asked for a proof that the funds were indeed in transit at the time, instead I received an a reply of

"To some extent, that’s a fair request, but if you trust the data illustrating what is perceived as a shortage of $38k, it’d stand to reason you’d trust the same source presenting an additional explanation, particularly seeing as the issue resolved itself within hours. The explanation we have provided rests on the same logic and transparency as the data you believed that illustrated the shortage."

Shorting Bitcoin, speculating with customers' funds


Another important accusation levelled against Uphold was the issue of their Bitcoin balances being short in favour of fiat currencies.

On 2016-02-14 Uphold's BTC obligations were listed as 5'834.056BTC, and their assets as 4'594.390BTC, short 1'239.666BTC, or 21.25%. On 2016-03-27, their BTC obligations were listed at 4'944.479BTC and assets at 3'652.980BTC, short 1'291.499BTC or 26.12%.

This raises a few questions - why was this done in the first place, what was the contingency plan in case of a price swing (with their $57k surplus, a 44.5BTC/USD price swing would turn the website insolvent again) as well as whether the company is speculating using their customer funds.

The reasoning behind the short balance was stated as trading sideways to save on exchange fees. As Uphold doesn't charge a conversion fee, they focus on lowering their operational costs by not immediately covering their customers' trades. In a perfect system, the trades would be going back and forth, allowing Uphold to only correct a fraction of the total trade amount on an external exchange, thus lowering the fees they pay. However, when the trades are more one-sided, the balance discrepancy grows further and further apart and needs to be corrected eventually.

Second question had a fairly straightforward answer - stop-loss mechanism. When the price swings too wildly, automatic trades are executed to protect the reserves.

Lastly, the company stated it does not condone the practice of speculating with one's customers' funds without an explicit permission from them. As such, Uphold is claiming not to engage in such a practice, and does not aim to make a profit by being over-exposed to one currency or another.

All in all, we seem to be running into the main trade-off that might have been the cause of this BTC shortage - whether one should prioritize keeping the fees low, or the reserves rigid. Neither one is a wrong answer - they both have their merits and drawbacks, but they do send a message about the company's priorities and values.

Interestingly enough, between 2016-03-27 and 2016-04-01, during my email exchange with Uphold, their BTC reserves seem to have corrected themselves:

Uphold BTC balance, 2014-04-01

Whether this balance correction was coincidental after over a month of running on a BTC deficit, or it was a deliberate action by the company, it can be hard to prove. Despite asking about "What is the threshold before your company would consider itself over-exposed on Bitcoin?", no direct answer was provided. At least I can take comfort in Uphold's statement to consider their BTC reserves more closely:

"This is feedback we’ll incorporate, and in all likelihood will just result in us adding a bit more of our own funds to the reserve surplus on the asset side of Bitcoin, to ensure it’s always close to over-reserved. "

Proof vs claim


A few times during the email exchange the topic of proofs came up. As Uphold is focusing on providing "a public, real-time, traceable and verifiable proof of solvency", it is important to distinguish between what constitutes a proof, and what is just a claim.

A proof needs to be independently verifiable and falsifiable, while a claim does not. Whether you use a send-to-self transaction, use a set of addresses and balances, or do something else an independent third party (or better yet, the public) can verify and possibly disprove, that can constitute a proof. Self-reported balances as is the case with Uphold's current transparency page, do not constitute any proof, but are merely a claim of solvency.

While Uphold is claiming that their reserves are independently audited on a quarterly basis and are currently working on publishing those audits in the future, as of the time of writing, I have no evidence of this, despite Uphold being asked to provide "independent, verifiable, sources for the information" for this article. I would exercise caution until such proofs are provided, even if this might be erring on the side of overt caution.

All in all, in an ideal world, I would like to see the following proofs:
  • Proof of liabilities - allowing anyone to verify that their assets are counted in Uphold's total liabilities and that everything adds up
  • Proof of reserves - independently verifiable proof that Uphold does indeed own the stated currencies and assets, crypto or otherwise
  • Proof of existence / records - Ideally, the other proofs would be timestamped or published on a platform like Factom to prove they weren't altered in the future
  • Proof of exchange rate - while one is able to claim they are not charging an exchange fee, a crafty party could hide the fee in the exchange rate spread and charge it covertly. While I don't know of any company that incorporates such proof, shy of using an open ledger, it might be a mark of the highest standards of transparency

At the current time, one can only wait for the first two or three to be eventually published...

Everything else


During the email exchange, a few less important topics were discussed. Some of the statements make the company appear fragile to criticism:

When asked whether Uphold stands by their CEO's tweet labeling the first Reddit post about the company's possible insolvency as "ridiculous, untrue & libellous lies", I was reassured:

"Absolutely, and it’s unfortunate that people end up misinterpreting the information we make available in good faith, without offering us the chance to clarify it. I can understand the confusion regarding VOX, and I hope our updates  address that.
Our CEO Anthony Watson is an award winning social  advocate, who does a great deal of good in the world to support people's basic human rights. He’s got no interest engaging with an anonymous Reddit poster who set up an account up several hours before he made this post seemingly only to cast doubt upon Uphold, without making any effort to engage with us to clear up these questions. "

The middle part seems like an appeal to emotion. In their closing remark, another two quotes appear to be putting the company in a victim role:

"[...] while some people may see us as “just a corporation”, we instead see ourselves as a group of people on a mission. We want to do the right thing, and being so poorly perceived is damaging to the morale of those working hard to make Uphold a reality. "
 "[...] We’re building bridges, so we’re bound to find trolls, but we see no value in taking part of a conversation where the conclusion has been decided beforehand and there is no opportunity for open dialogue."

While I'm glad that despite that the company decided to address some of those criticism in their blog post as well as answer my doubts and questions on the matter, failing to address the criticism head on because they came from an anonymous user while taking that criticism to heart and letting it lower your morale might not be the healthiest approach to take on the Internet.

Conclusions


Having had the chance to discuss the insolvency accusations with Uphold, I remain cautiously optimistic for their platform and their customers.

While they failed to provide any verifiable proof of their platform's solvency or where the $95k of extra solvency came from between February and March, their promise of publishing audits in the future might address similar issues in the future. 

Uphold's changed commitment to maintaining a more rigid BTC balance should similarly keep that issue from cropping up again.

While the company might not wish to engage "trolls" raising criticisms of their platform, it is at least good to see them addressing the concerns raised and improving themselves based on that feedback. One could see it as either being wise enough to reconsider one's stance, or desperate enough to pander to critics however.

So here's for hoping we'll get our proof of solvency soon enough and Uphold will be a shining example of transparency, rather than turning into another cautionary tale in the Bitcoin world.

2016-04-04

Transaction data vs metadata - interpreting what has happened

With Bitcoin as well as most "Crypto 1.0" currencies, the transactions are simple and elegant. You specify which coins you're spending, what are the redemption requirements, and that's about it. A transaction either goes through, is included in a block and can be spent, or it never gets included and can be safely ignored. However, when we look at the more complex Crypto 2.0 systems, things start to get more complicated - there are many more states a transaction can be in, and we require additional metadata to figure out what really happened.

Transaction data vs metadata


The way Ripple handles its transactions is a good example of the data vs metadata. When submitting a transaction, we submit its data - our intent of what we want the transaction to do. For example:


{
"TransactionType" : "Payment",
"Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
"Amount" : {
  "currency" : "USD",
  "value" : "1",
  "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
},
"Fee": "10",
"Flags": 2147483648,
"Sequence": 2,
}

Indicates that we want to send 1USD from rf1... to ra5... and we pay the fee of 10. Now, when we submit the actual transaction, we also see its metadata:

{
  "id": 6,
  "status": "success",
  "type": "response",
  "result": {
    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "Amount": {
      "currency": "USD",
      "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
      "value": "1"
    },
    "Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
    "Fee": "10",
    "Flags": 2147483648,
    "Sequence": 2,
    "SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
    "TransactionType": "Payment",
    "TxnSignature": "3045022100D64A32A506B86E880480CCB846EFA3F9665C9B11FDCA35D7124F53C486CC1D0402206EC8663308D91C928D1FDA498C3A2F8DD105211B9D90F4ECFD75172BAE733340",
    "date": 455224610,
    "hash": "33EA42FC7A06F062A7B843AF4DC7C0AB00D6644DFDF4C5D354A87C035813D321",
    "inLedger": 7013674,
    "ledger_index": 7013674,
    "meta": {
      "AffectedNodes": [
        {
          "ModifiedNode": {
            "FinalFields": {
              "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
              "Balance": "99999980",
              "Flags": 0,
              "OwnerCount": 0,
              "Sequence": 3
            },
            "LedgerEntryType": "AccountRoot",
            "LedgerIndex": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
            "PreviousFields": {
              "Balance": "99999990",
              "Sequence": 2
            },
            "PreviousTxnID": "7BF105CFE4EFE78ADB63FE4E03A851440551FE189FD4B51CAAD9279C9F534F0E",
            "PreviousTxnLgrSeq": 6979192
          }
        },
        {
          "ModifiedNode": {
            "FinalFields": {
              "Balance": {
                "currency": "USD",
                "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
                "value": "2"
              },
              "Flags": 65536,
              "HighLimit": {
                "currency": "USD",
                "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
                "value": "0"
              },
              "HighNode": "0000000000000000",
              "LowLimit": {
                "currency": "USD",
                "issuer": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
                "value": "100"
              },
              "LowNode": "0000000000000000"
            },
            "LedgerEntryType": "RippleState",
            "LedgerIndex": "96D2F43BA7AE7193EC59E5E7DDB26A9D786AB1F7C580E030E7D2FF5233DA01E9",
            "PreviousFields": {
              "Balance": {
                "currency": "USD",
                "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
                "value": "1"
              }
            },
            "PreviousTxnID": "7BF105CFE4EFE78ADB63FE4E03A851440551FE189FD4B51CAAD9279C9F534F0E",
            "PreviousTxnLgrSeq": 6979192
          }
        }
      ],
      "TransactionIndex": 0,
      "TransactionResult": "tesSUCCESS"
    },
    "validated": true
  }
}

Which specifies, among other things, AffectedNodes - the actual state change exacted on the system. It specifies the balance change of multiple addresses the transaction rippled through. This can be especially important when there are multiple paths a transaction could take, possibly even spanning many different currencies and entities.

How Ripple Works - Gateways and Pathways

All in all:
  • Transaction data specifies what we want the system to do
  • Transaction metadata specifies what did happen in the system

Lets look at a few examples of why this distinction is important.

Blockchain interpretation in Bitcoin 2.0


Some people use the term "Bitcoin 2.0" and "Crypto 2.0" interchangeably. I personally make the distinction of using the first term only when referring to systems built on top of Bitcoin itself - Mastercoin/Omni, Counterparty, Colored Coins, etc., while using the second term for all cryptocurrency systems allowing one to issue custom currencies (which includes Bitcoin 2.0s as well as systems like Ripple, Ethereum, etc.).

The distinction is important here because Bitcoin 2.0 systems inherently have no control over which of their transactions are included in the Bitcoin blockchain they are using. Unlike Bitcoin, two conflicting transactions can be included in the block and the system has to be able to interpret them correctly. Without transaction metadata, it is hard to tell at a glance whether a transaction is valid and spendable, or whether it is a double-spend and should be ignored.

A cautionary tale of the partial payment flag


In 2014 JustCoin, a Ripple gateway, got into a lot of trouble due to a small feature in Ripple very few people noticed before then - the partial payment flag. When a transaction is created with that flag, it signals to the network "I want to pay the person as much as I can up to the limit specified", rather than "I want to pay the person exactly this much". So for example if my transaction data specifies the amount I'm paying to be 1'000'000USD, but my balance is only 10USD, without the partial payment flag the transaction would fail, and with the flag it would succeed but only give a person 10USD.

The big problem JustCoin ran into was that the transaction data still would quote the big number, even if very little was sent, and only by examining the metadata would they be able to see how much money was actually sent. This meant their attackers could rack up bogus deposits and cash out of the gateway, leaving it short on funds.

Transaction successful, payment failed


While working on a Ripple gateway in the past, I got to explore a few different end states a transaction can end up in - a transaction can be not included in a block and be in an undefined state, it can be included in a block and be successfully applied, included in a block and partially applied (partial payment, open exchange), or it can be included in a block but still fail. In the context of Bitcoin, the last state would be unthinkable.

A scenario where a transaction is not applied to a block is similar to Bitcoin's unconfirmed transaction - it is in a state of limbo. However, with Bitcoin one can still spend other outputs without worrying about the transactions interfering with one another - each transaction output can be spent independently. For systems relying on address balances rather than transaction outputs, a dangling transaction can be a blocker. This is why professional transactions are sent with an expiration date (after which the transaction will definitely fail and not do anything), as well as sending a NOP transaction to overwrite the expired transactions to allow everything else to go through.

Successful transactions that applied fully are pretty straightforward - everything went through (or as much as could in case of partial payment flags).

Open-ended transactions are initialized by one transaction, but end up being fulfilled by other transactions. This applies mostly to the decentralized exchange offers - it's similar to placing a bid on a market and waiting for one or more asks to fulfill it. The transaction only closes when it is fully fulfilled, or it becomes invalid due to low balance, etc.

Failed transactions being included in a block mostly apply to Bitcoin 2.0s and balance-based cryptocurrencies. Those transactions either are inevitable - any valid Bitcoin transaction can be included in a Bitcoin block, but it can be an invalid Omni transaction -, or they are there for simplicity's sake - to do nothing, consume a sequence number and allow next transactions to be committed.

Conclusions


Transaction data specifies what we want the system to do, while transaction metadata specifies what did happen in the system. While not as important to Bitcoin and other first generation cryptos, the transaction metadata becomes more and more important for more complex Crypto 2.0 systems.