Showing posts with label Factom. Show all posts
Showing posts with label Factom. Show all posts

Monday, September 12, 2016

Smart guns and BlockSafe

DISCLAIMER: I work for Factom, which is mentioned in several examples in this article. While I work for Factom, the opinions expressed in this piece are, as always, my own.

Recently, I came across a token sale from the BlockSafe project. After a brief chat with the project's founder, I think this might be an interesting example of a blockchain solution looking for a problem and cashing in on some buzzwords. But let's start from the beginning...

Smart gun technology


A concept of a smart gun is nothing new - it's been around for at least 14 years. The premise is simple - it is a firearm that includes some technology only allowing for the gun to be used by an authorized user. It can be used to prevent "misuse, accidental shootings, gun thefts, use of the weapon against the owner, and self-harm". There are many approaches for user authentication - RFID chips, proximity tokens, fingerprints and biometrics, magnetic rings, mechanical locks, etc.

However, since most guns are inherently simple tools, and a lot of people would rather not have their defensive firearms "rely upon any technology more advanced than Newtonian physics" - batteries go dead, electronics malfunction, software bugs out, etc. Waiting for a blockchain transaction to confirm before your gun is unlocked is the last thing you want to be doing in a hurry.

Moreover, even if the technology was reliable, it would not be able to prevent every situation the society would want to avoid dealing with. Most gun deaths are suicides in the US, you wouldn't really be able to stop most mass shootings or other homicides without some major restrictions (like location-locking guns to one's home for example). Best it could do is restrict the use of stolen guns by people that wouldn't know how to crack or circumvent the DRM - a very small part of the issue.

The smarter the guns would become, the more concerns would be raised by people being paranoid the government would install a kill switch in their weapons to disable them remotely to "take away their freedom" and so on.

Lastly, it is very unlikely requiring any such technology would ever pass the NRA's lobbying in US's current political system. At very best it would be sold as an extra feature, but I somehow doubt there would be many end-user buyers for a gun with limited firing capabilities:



Blockchain for smart guns - good and bad ideas


There are many ways blockchains could be used in conjunction with smart guns, some more useful than the others. As the BlockSafe Foundation website (or their other, non-functional website, #gunsafety #liberty?) doesn't go into too much details on the specifics, let's explore a few options by ourselves.

Solution for the manufacturers - If the project is working up to manufacturer's spec, even if it was ultimately misinformed or using "the blockchain" as a buzzword, you can't really blame the developers for it. Even if using traditional solutions would've been better, they would be paid to deliver the solution in its current shape.

Data logging - If the gun would not be locked by the blockchain, but the solution was only used to log any discharges, or possibly even photos or other data, the blockchain might be used to ensure no data is lost or altered after the fact. This would be similar to how DHS uses Factom - to prove integrity of data. This approach would be especially useful for police and similar civil servants.

Ownership tracking - Instead of doing anything directly with the gun itself, the blockchain could be used to track the ownership of the guns themselves. This would work for both smart and traditional guns to establish an unalterable record of history if a firearm was to be used in a crime in the future. This would be a similar approach to Factom's land title record project. While this might be a good solution for the blockchain, it is very unlikely to pass through NRA as explained here.

Gun locks - possibly coupled with Ownership Tracking, the gun would essentially become a smart property. The gun would keep track of which private key owns it, and would only unlock itself if authorised by the proper private key - through RFID chip, smartphone app, etc. If the ownership would change, proper, new keys would be uploaded and so on. While it might sound like an interesting idea, allowing people to remotely disable their stolen property, etc., this approach would negatively effect the firearm's functionality as described in the previous section of the article.

All in all, it looks like most of the applications for blockchain-powered smart guns could basically be implemented in some straightforward smart contract on Ethereum or the like. Most of the complexity in the technology would come from everything that would be built on top of the blockchain. Now, with that in mind, let's look at how BlockSafe is selling itself...

Claims and buzzwords


Looking at BlockSafe's promotional video, we can list a number of claims, stated or implied, of what the project can do:
  • Prevent
    • Tragic amount of human suffering
    • Mass shootings
    • Unnecessary deadly force from police officers
    • Terrorist attacks
    • Gang violence
    • Citizens being killed by their own guns
  • Save lives
  • Secure one's firearms
  • Manage who can use their firearms
  • Locate and disable stolen weapons
  • Maintain a decentralised database

All powered by Trigger token. Other than the slew of buzzwords intended to appeal to emotions, it looks like the BlockSafe is designed to remotely control and track the guns. Looking at one of their infographics, the system also looks designed to be logging when the gun is used and notify emergency personel. This seems to be hitting on all of the major blockchain applications listed in the previous section, for better or worse.

Even if the project was to succeed, it is very unlikely it would accomplish all of its claims. A terrorist, a gang member, or a mass shooter would not choose a smart gun for their actions. You might get some chance of preventing people getting killed by someone taking their gun, but that's a slim percentage overall, about 0.02% of the gun owners would be killed by their own gun, which includes suicides. As for police officers using deadly force, it might have some dampening effect, but I somehow doubt it would make a significant impact if any.

So what would the Trigger token be likely used for? Well, if you would pay to place logs of the gun into the blockchain, then that's defeating the point - you want every log to go into the chain and not allow people to withdraw their funds to prevent logs from happening. You would need some sort of transactional currency for that, or a centralised solution maintained and paid for by the manufacturer (in which case, you don't need much of a blockchain). Using triggers to transfer gun ownership might be possible, but it might not occur often enough to maintain the network. Using the tokens to unlock the gun would be outright malicious.

Conclusions



All in all, the BlockSafe project looks like a solution looking for a problem and wanting to use a public blockchain to boot. The token presale looks like pure speculation - the project itself doesn't look like it needs the tokens, nor is there a clear explanation of what the tokens would be used for.

The smart gun technology as hinted by their video doesn't look useful. While that might not matter if the project already has industry partners committed to using the project, it might be an important thing to keep in mind for the token speculators - if nobody wants to use the technology, the tokens will ultimately be worthless. If the industry partners are paying for the technology, why sell the tokens at all?

All in all, most of the goals smart guns wish to accomplish could be accomplished easier with a physical lock on the gun, or putting the gun in a safe.

Ultimately, if you are focused on saving lives and reducing gun-related deaths, ban the guns like Australia did, don't run a token presale for some blockchain project...

The Bitcoin Bullshit List


Your Crypto Idea Will Not Work

Your post advocates a new:
(x) Altcoin
(x) Permissioned blockchain


Your idea will not work.  Here is why it won't work.

(x) Your target audience is too small to support the project
(x) The proposed security model is (x) flawed / ( ) not enough / ( ) completely wrong and therefore you will be ( ) scammed / ( ) hacked / ( ) stolen from / (x) circumvented quickly
(x) There is already a product on the market that does exactly what you’re doing, but (x) faster / (x) cheaper / (x) better / ( ) is more established / ( ) ______________
(x) You rely on proprietary (x) hardware / (x) software / ( ) intellectual property / ( ) _________
(x) The solution would work better as a (x) centralised / (x) decentralised / ( ) distributed solution
(x) Your solution is worse than general-purpose computing hardware / software
(x) Your solution will make the current hardware / software perform significantly worse
(x) Your presale tokens have no economic value

Specifically, your plan fails to account for:
(x) Public reluctance to accept weird new forms of money
(x) The human factor
(x) The problems computers have with interacting with the real world
(x) Strong lobby groups opposed to solutions like yours


and the following philosophical objections may also apply:
(x) Nobody likes DRM
(x) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
(x) Whitelists suck
(x) Feel-good measures do nothing to solve the problem

Furthermore, this is what I think about you:
(x) Sorry dude, but I don't think it would work.


Bitcoin Bullshit Tier

You are advertising a new Bitcoin / crypto related project. Based on the information provided, you have reached the Bullshit Tier of 3 for the following reasons:

Bitcoin Bullshit Tier 1 - marketing babble, technology misunderstanding
(x) “Blockchain”

Bitcoin Bullshit Tier 2 - willful misinformation, bait and switch
(x) Claiming your project can accomplish something hard without a clear explanation of how to do so

Bitcoin Bullshit Tier 3 - Many red flags
(x) Token IPO
(x) Logical fallacy: ( ) false equivalence / ( ) false dichotomy / (x) appeal to emotion
(x) Providing no company contact information

Monday, July 18, 2016

Transactional currencies - Entry Credits and Gas

Transactional currencies - Entry Credits and Gas

DISCLAIMER:
While I work for Factom, the opinions expressed in this piece are, as always, my own.

----

Working at Factom I came across an idea that seems seldom explored in the cryptocurrency space - a transactional currency called entry credits. They operate alongside the main currency of the network, factoids, but while factoids are a fully functional cryptocurrency that can freely circulate in the network, entry credits have a number of restrictions on them:

  • Entry credits are created out of factoids (by burning them) at an exchange rate dictated by the system, but they can't be turned back into factoids
  • Entry credits can be created ahead of time to lock in their factoid-entry credit exchange rate, and used later down the line
  • The exchange rate is tweaked by the system to stabilise the price of entry credits, while still allowing factoids to be a free-floating currency
  • Entry credits can only be spent (burned) to store entries into Factom - they can't be spent elsewhere
  • Entry credits are not transferable - they can only be spent by the account that received them during the factoid->entry credit conversion
These restrictions create a few interesting features for the system that I don't see explored much in other cryptocurrencies:
  • It is possible to put a large amount of entry credit tokens on a hot wallet without worrying much about theft - any would-be hacker wouldn't be able to cash out the stored value, only spend it. This makes production servers much less of a target for attacks.
  • Being able to lock in the price of the tokens ahead of time means companies can budget ahead of time and don't have to worry about token volatility
  • Having the exact amount of tokens in an account, one always knows how many transactions they can perform in the system before running out

Other tokens


While I haven't heard of another currency having the same features, there are some that function similarly.

Most cryptocurrencies adjust their transaction fees on a regular basis to keep up with the price of their coins. This can function as a way to keep the transaction cost stable without trying to control the price of a currency.

Ethereum uses a more formal approach to this with their gas currency. It is separate from their ethers, but you can't purchase gas ahead of time. The gas is used to pay for transactions and operations in smart contracts, but the final cost calculations are more complicated - one can get gas rebates for freeing up memory as far as I heard.

Conclusions


The Factom project might be one of the first projects to implement a fully transactional currency - entry credits. While being a confusing feature for some, it is an interesting approach of stabilising the transaction cost of production blockchain application, as well as limiting the attractiveness of an attack on the production servers.

Monday, April 11, 2016

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.

Sunday, April 26, 2015

Shipping without incentives and features

Shipping without incentives and features

Recently I was doing some research into Factom, a new project that aims to embed a lot of data into the Bitcoin blockchain and create a "proof of existence as a service", among other things. I stumbled upon some criticisms of the software (Google Cache link, as the original was taken down). One of the crucial features missing from the Factom code at the current time appears to be the lack of incentive for nodes to store any data after it is embedded into the Bitcoin blockchain. Pondering this for awhile, a few similar issues with other systems came to mind, and thus I'm writing this blog entry on various Bitcoin-related software that launched without some important features or incentives.

"Convenient bugs and arbitrary features" is also a recommended reading related to this topic.

Red balloons - Bitcoin is not without its flaws


When I was doing research for my master thesis on Bitcoin, some researchers from Microsoft and Cornell University released a paper called On Bitcoin and Red Balloons, where they pointed out the Bitcoin nodes have no incentive to propagate transaction information through the network, and miners have all the incentive to actively withhold that information.

The gist of the research is that while anyone creating a transaction has the incentive to propagate it through the network (they want the transaction to be put in a block, so they spread it to everyone), miners have the incentive to include paid transactions into blocks (to earn fees), Bitcoin nodes have no incentive to relay the transaction information. They are not getting paid to do so, nor do they benefit from the transactions they transmit directly. Moreover, if a miner knows of a transaction with a fee, they benefit from not broadcasting it - this way it is less likely to be mined by their competitors and they are more likely to earn that particular transaction fee.

One can argue, however, that every business built on top of Bitcoin has the incentive to run a full node that relays all the information. While they don't benefit directly, the abundance of full nodes makes the network more resilient to attacks and more distributed. What benefits the community at large is also beneficial to the individuals in some way.

Mastercoin - a token without a purpose


Back in the day when Mastercoin launched (and has since re-branded into Omni), my biggest question surrounding this technology was - "what are mastercoins used for?". In the Bitcoin space, you would use bitcoins to pay the transaction fees. In the Mastercoin space, well, there wasn't a clear use for mastercoins. Sure, the project itself benefited from the crowdsale to fund the development of the protocol, and some people earned some pretty penny speculating on the price of the coins, but there was no immediate use for the tokens themselves. There were no mastercoin-denominated fees in the system, the transactions instead paid the standard Bitcoin transaction fees. Only much later did the developers include a clear use case for the tokens - to burn them for crowdsales. A little bit of an arbitrary feature in my opinion, but at least it is some feature.

Ripple validators - a big burden with no reward


In a similar vein to Bitcoin's lack of incentives for running full nodes, the Ripple network provides no incentive for network validators. A validator is similar to a miner on the Bitcoin network - they process all the transactions taking place on the network and create new ledgers. While mining bitcoins is a computationally-intensive task due to proof of work, the Ripple network is more heavy on the disk space (full network history taking up 100-500GB of data at the moment).

Unlike Bitcoin however, Ripple fees are not paid to the miners / validators, they are instead burned. Similarly, Ripple has no coin distribution schedule - all the XRPs have been created in the genesis ledger. This leaves validators with no incentive for a potentially burdensome effort (most of them are currently run by Ripple Labs last I heard).

There are two approaches to solving this issue however. One is the idea that the Ripple gateways should also run validators, as they are the ones earning the most money from the network operating. The second approach could build on top of Stellar's token creation - the validators can be compensated by the users of the networks for their contributions with newly minted stellars.

Factom - pay to save, never load


As mentioned in the opening paragraph, it appears that the Factom network allows its users to save any pieces of information into the network for a fee, but fetching the data in the future carries no cost and thus no reward for the nodes to carry out that request. If someone decided to abuse the network, they could try flooding it with a lot of requests similar to a denial of service attack - honest nodes would be overburdened with having to provide a lot of data, while lazy nodes that wouldn't even attempt to provide the information would be better off.

As such, it appears that the Factom network will need to expand its fee and reward structure to provide incentives for nodes to store information as long as it is useful, similar to how MaidSafe is supposed to work.

Branded coins - start with a purpose


I heard a few similar pitches - a company wants to release a new, branded coin and tie it to their service. They usually have some grand vision of how everyone will want to use their coin since they will be able to spend it in their system and pay anyone just as easily as they do with Bitcoin. Sometimes it's customer rewards for shopping, sometimes it's some coin to raise brand awareness. However, quite often such pitches lack one crucial thing - why would anyone want to use the branded coin over Bitcoin? If you say, have a payment processor that accepts Bitcoin and their branded coin, I personally see no reason to use the branded coin over Bitcoin, nor to hold it any longer than it takes to convert it back into BTC. Even the usefulness of presale tokens can sometimes be dubious.

In the end, a branded coin needs to serve some purpose other than just existing for the sake of it.

Conclusions


There have been a lot of projects in the past that have launched without all the necessary features or without proper incentives to support all of the functionality. While we can expect some level of altruistic behaviour from the people running the software, a well-run system shouldn't rely on altruism alone - either you pay to use the resource, or you lose it.