Category Archives: Technology

Yet Another Bitcoin Use Case: microtransactions

With the usual drumbeat of bad news continues, fraud, price manipulation, opaque actors, extortion, and just plain “oopsies”, a disinterested observer can be forgiven for wondering if the end is near for crypotcurrencies.

Bitcoin itself is increasingly controlled by giant mining combines who effectively control the Bitcoin network. This situation was assumed to be impossible in the original Nakmoto design [1], but here it is. And it is leading to a catastrophic crackup (AKA the “hard fork”), possibly as soon as August.

Meanwhile, this blog is ticking off the long list of supposed use cases for Bitcoin and blockchains. Supply chains?  Yes.  Remittance? Not on a public blockchain. Local currencies? Nope. Identity? Mostly not.

This week there is yet another use case that isn’t happening: Microtransactions.

From the start, it was imagined that Bitcoin technology could support transactions of any size, down to fractions of a penny. The cost of doing a transaction could be small, possibly even zero, and if so, then there is no reason not to do lots of tiny transactions. This would open the way to all kinds of new business (pay as you go for web content, metered use of services, etc.) including automatic management of IoT resources.

How is this admittedly exciting use case holding up?

Chuan Tian reports in Coindesk that “SatoshiPay to Stop Using Bitcoin Blockchain for MicropaymentsStoshiPay is a nicely developed concept that has, for instance, a plugin for WordPress that would let me charge you a tenth of a penny (in Bitcoin) to read this deathless prose.

Their business model is to take 10% of every transaction—when you paid me, they get 1/100 of a penny.

The original approach was to just use Bitcoin, putting the transactions on the Bitcoin blockchain. Even bundling a bunch of them, these are small transactions, so the cost of pushing them out to the ledger obviously has to be small enough for the 10% cut to be profitable.

As Tian points out, the “essentially zero” transaction costs seen even two years ago are long gone, and more than one company has abandoned microtransactions with Bitcoin. At $2 and more per transaction, it is economically infeasible to implement microtransactions directly in Bitcoin. (By the way, these transaction costs for Bitcoin are now in the range with conventional financial systems.)

Why has this happened? Congestion.

The same scaling issues that are threatening to crack Bitcoin into multiple rival networks have pushed transaction fees higher and higher. The big players who are collect these fees (their entire business model is to collect these fees) have blocked engineering changes that would likely reduce congestion, and lower fees.

It is possible that transaction fees might go down, who knows. But the fact is there isn’t any good reason why you need to use the public ledger to implement microtransactions at all. So companies are moving to other technology.

SatoshiPay is said to be moving to IOTA, which is a blockchain-inspired system targeting the Internet of Things. IOTA implements a cryptographically secured peer-to-peer network, with their own protocol and data structures. They argue that transaction fees will be very low, or even zero.

Actually, the IOTA protocol and data structures are completely different from Nakamoto [2]. IOTA is based on familiar concepts used in large scale data systems, with a peer to peer twist inspired by Bitcoin. They use cryptography and the idea of consensus, but in a way that allows a lot more throughput, along with other interesting features such as smooth offline operation (i.e., you can cut off part of the transactions and merge them back later).

There are some funky things about the protocol (e.g., there is a knob for how confident you want to be about the validity of the transaction tree) but there are no miners and therefore no transaction fees.

IOTA aims to do IOT things, smart machines bargaining with each other. (No puny humans involved!) They call thing the Economy of Things or something like that. But what they have built should also be good for something like SatoshiPay.

As in many Bitcoin use cases, people using SatoshiPay or services that use it will never notice the transaction technology behind the scenes.

Will we finally see digital microtransactions? I dunno. But it won’t be on the public Bitcoin blockchain, that seems clear.

So this use case for blockchain might come true, but, as IOTA puts, with No Blocks and No Chains.

Inspired by Bitcoin, yes.

But implemented by more sophisticated technology, designed for this use case.


  1. Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System. 2009. http://bitcoin.org/bitcoin.pdf
  2. Dominik Schiener, A Primer on IOTA (with Presentation), in IOTA Blog. 2017. https://blog.iota.org/a-primer-on-iota-with-presentation-e0a6eb2cc621
  3. Chuan Tian,  SatoshiPay to Stop Using Bitcoin Blockchain for Micropayments Coindesk.July 17 2017, http://www.coindesk.com/satoshipay-stop-using-bitcoin-blockchain-micropayments/

 

 

Cryptocurrency Thursday

Turtlabot Follow Me Demo

Turtlebots are low cost, open source robots. Glancing through the tutorials, there is a lot of state of the art stuff here, including serious mapping, navigation and autonomous driving!!

The latter features are showed off in the “follow me” demo.

Neat. And, theoretically, you can DIY!

I haven’t had the time and energy to get into turtlebots, but I really should.

The ‘follow me’ demo is nice, but what I really want is a flock of raptors to follow me like this. A posse of small fast, toothy, bipeds. Maybe in a vee instead of a line. Don’t mess with me!

 

PS. Wouldn’t “My Raptor Posse” be a great name for a band?

How about, “A Rip of Raptors“?  Or “Personal Raptor

Or, “The Robot Raptor Revue“.

 

Robot Wednesday

Blockchain for Local Identity?

As soon as I declare that blockchain technology is unsuited for two use cases, Identity and local currency , Wolfie Zhao reports in Coindesk that the Swiss city of Zug is going to have a local ID service using a blockchain.

Oops. These use cases are still open, or at least not as dead as I said.

Of course, there is a difference between a local currency and a local ID service. The former needs to interact with conventional financial systems, the latter needs to interact with conventional ID systems. The press release indicates that digital IDs are not well developed in Switzerland, though I’m sure that digital banking works great.

Similarly, there is a difference between a global ID system, with secure digital passports for everyone including refugees and repressed populations, and a digital ID issued by a city. For that matter, the city is Swiss, which means it already has a well developed national ID system to build on.

So this isn’t quite the use cases I considered earlier.

What it is, is an intersection of them, a simpler problem and a well organized local government. Perhaps this is a favorable “corner” of the use cases, where blockchain will work well.


So far as I can tell, the rationale for this system is that Switzerland has a personal ID system (which I’m sure is quite rigorous and efficient), but digital versions of the IDs have not been successful. Blockchain technology is a way to securely associate a cryptokey with a particular ID. The blockchain is intended to make it possible for digital apps to quickly and cheaply confirm IDs.

Sure. This can work.

We’ll see how well it works. Is there enough need for this sort of crypto ID, and does it work well enough to be useful?   I don’t know, we’ll find out.


I note that blockchain is being used for a tiny part of the problem. As the press release makes clear, citizens must go to a city office to prove their identity and then are issues a digital key. This process is the hard part, and blockchain does nothing to support this service.

We want a single electronic identity – a kind of digital passport – for all possible applications. And we do not want this digital ID to be centralized at the city, but on the blockchain.” (Dolfi Müller, quoted in [2])

It is ironic to see the proponents of this system talk about how this is a “decentralized” solution. What they mean by that is that the part of the process where digital IDs are looked up is “decentralized”, particularly compared to previous systems that have attempted to implement the service with a database.

Essentially, the city doesn’t want to run a database with a secure public interface. Fair enough.

To a certain extent, they are also boasting about the local city’s initiative, too, though IDs issued by one city may have limited use elsewhere. Ethereum runs everywhere, but Zug IDs may not be trusted anywhere outside Zug.

I suspect, though, that Zug is issuing IDs based on Swiss national credentials. In that case, IDs issued in Zug are great throughout Switzerland. These are, of course, centralized IDs in that case.

Looking up IDs is a decentralized problem, but issuing IDs demands trust, and a web of trust between authorities. If every city in Switzerland issues its own crypto IDs, even using the same Federal ID, it will be chaos.


Finally, I have to say, “Ethereum? Really?”

I’m rather surprised that anyone would try to build a trusted system using the catastrophically messed up Ethereum technology. But they probably use Microsoft Windows, too. Massively clever cryptography running on wobbly, hackable software infrastructure.

Anyway, we’ll see how this works out.


  1. Stadtverwaltung Zug. Blockchain-Identität für alle Einwohner. 2017, http://www.stadtzug.ch/de/ueberzug/ueberzugrubrik/aktuelles/aktuellesinformationen/?action=showinfo&info_id=383355.
  2. Wolfie Zhao, Swiss City Announces Plan to Verify IDs Using Ethereum Coindesk.July 7 2017, http://www.coindesk.com/swiss-city-verify-id-ethereum/

 

Cryptocurrency Thursday

Hoppy Robot!

This is a great age of robot locomotion, and human engineers are recapitulating natural evolution, trying out every biological system– butterflies, bats, snakes–and many things not seen in nature (at least above the micro scale) (quadcopters, bucky bots.

Evan Ackerman reports on the amazing Salto jumping robot from U. C. Berkeley. Salto has one (count ‘em, one) leg, and springs around spending 90% of its travel in the air. It’s absolutely astonishing.

The article indicates that the control algorithm is pretty much the same as one developed in 1984, though we can pack a lot faster computation in a smaller critter now. The mechanical design is bio-inspired, learning from the small marsupial galago, which is a crazy jumper.

However, the actual magic is done with steerable “thrusters” (propellers), and the control depends on an external motion capture system that feeds instructions via wireless (an invisible tether).  This is not the way little bushbabies do it!

The new improved version will be officially presented September at IROS 2017, probably with some even more awesome demo.

I’m not really sure if this design is especially good for anything, but it’s fun to watch and would make a great game. Imagine the fitness benefits of playing “chase the boingy bot”! Or “try to escape the boingy bot”!  (These apps would mash up some kind of planning algorithm to evade or catch the puny human.)

So Cool!


  1. Evan Ackerman, Salto-1P Is the Most Amazing Jumping Robot We’ve Ever Seen, in IEEE Spectrum – Automation. 2017. http://spectrum.ieee.org/automaton/robotics/robotics-hardware/salto1p-is-the-most-amazing-jumping-robot-weve-ever-seen

 

Robot Wednesday

Side effects – Xtreme End-to-End thinking!

I think that the one of the most important habits of good design and engineering is end-to-end thinking. Solving problems is fine, but they need to be the right problems, and this means they need to be solutions all the way to the actual ends of the system.

Pat Helland writes this month about an even more funky, extreme version of this principle: Side-Effect-Thinking.

He focuses on digital transactions which are the backbone of the digital world.

The basic observation is that digital systems are composed of many pieces and layers which interact through APIs that are specifically designed to hide the TMI. These systems are also connected to real world systems, which may act in response to a transaction.

The main point is, of course,

One system’s side effect is another’s meat and potatoes.” ([1], p. 39)

The whole idea of APIs is to hide how the system works. By design, we have no idea exactly what happens when we place an order, or change an order, or whatever. Lot’s of stuff goes on behind the scenes, and we neither know nor need to know about it.

Helland points out that a side-effect of this design strategy is that a transaction may have knock on effects much wider than we might guess. He describes a scenario of reserving a hotel room. This may trigger the hotel to increase staff for that period, to order additional supplies, reschedule maintenance, and so on. Suppliers may respond with new orders and reserve capacity. And so on. All I asked for is a room!

It becomes more interesting when you cancel the room request. In one sense, the transaction is reversed, and all effects undone—in the reservation systems. But the side effects are not and some cannot be undone.

“cancelled’ transactions don’t undo side effects

He also points out that “idempotent” operations are idempotent only from the viewpoint of the transaction system. Each execution may produce the same result, but each will have side effects. If nothing else, the traffic will be logged (many times and at many levels of the system).

(Historic note: in the early days of the web, it wasn’t uncommon for web servers to swamp their logging and other ‘hidden’ systems, even when there was only a few pages that never changed. The information delivered was trivial, all the work was side effects.)

As I said, all this stems from the completely sound and reasonable design principle of information hiding. It would be impossible to build distributed systems any other way. On the other hand, designers implementing the system would do well to think about side effects that the callers might cause.

I would note that side-effects like those described by Helland have been the source of break-ins and denial of service attacks. Any of the scenarios in the article could, if repeated many times, become a denial of service attack. Some of them would be weird and unprecedented attacks, such as creating local petrol shortages by spamming hotel reservation systems.

Side effects and their ramifications will be even more problematic as the Internet of Things deploys. I don’t really know what the IoT will actually be, but most visions of it imagine that everyday actions will trigger waves of automatic transactions among the “Things”, which will also cause real world actions. TMI to the TMth power!

Following the spirit of Helland’s scenarios, imagine that when you cancel your hotel reservation (triggering mischief in France and memory fragmentation in some database), your home infers that you will be home that day instead of away. The “smart home” had planned to stand down many systems and conduct maintenance, but now anticipating what you will need, and proactively purchases extra electricity and utilities, cancels a maintenance visit, and orders food. These orders in turn trigger a wave of transactions and just-in-time orders by the services. And so on.

If this sounds like a chaotic system, it might very well be.

Remind again, me why the IoT is a good idea?


  1. Pat Helland, Side effects, front and center. Communications of the ACM, 60 (7):36-39, 2017. http://queue.acm.org/detail.cfm?id=3099561

Origamizier: Origami Anything

Wow!

I think I’ve always believed that origami could, in principle, represent most any shape, if you were clever enough. Until now, that was just a hunch.

This summer Erik D. Demaine and Tomohiro Tachi (of MIT and U. Tokyo) have published a complete algorithm for “Folding any Polyhedron” [1].  In short, you can make origami anything.

I don’t know what the limits of the algorithm are, but they say they can make an origami version of The Bunny, so it must be for real!

Mot of the technical details are beyond my own puny understanding of computational geometry, but I know this is potentially very important.

The traditional craft of origami is a repository of knowledge for how to create complicated shapes out of a single sheet of paper. These techniques are now a very important source of design for foldable and flatpack designs for robots and objects.

For one thing, these designs are amenable to simple digital manufacturing with laser cutters and 3D printers. For another, just like flat pack furniture, it is interesting to deliver a compact package that folds into a complex device on location. At small scales, this might deliver medical robots inside a body. At larger scales, this might deliver a planetary rover or temporary shelter via air drop.

I’m sure there are many more cases I haven’t though about.

My own view is that every engineering and design student should study origami.  It should be part of the mental (and manual) toolkit.

The “origamizer” is extremely significant because it means that it should be possible to realize any CAD design in one or more origamis. Combined with different manufacturing techniques, designers can deliver self-assembling and DIY designs of greater and greater complexity. Cool!

I’d love to see an ‘origamizer plugin’ for Blender!


  1. Erik D. Demaine and Tomohiro Tachi, Origamizer: A Practical Algorithm for Folding Any Polyhedron, in The 33rd International Symposium on Computational Geometry (SoCG 2017),, B. Aronov and M.J. Katz, Editors. 2017: Brisbane. p. 34:1–34:15. http://erikdemaine.org/papers/Origamizer_SoCG2017/paper.pdf
  2. Tomohiro Tachi. Software. 2017, http://origami.c.u-tokyo.ac.jp/~tachi/software/.

Blockchain Use Case: Supply Chains

This summer we’ve seen the cypto world sifting through the many possible use cases enthusiastically floated in past years [2], finding that some have promise and others seem to be fading. Remittance, local currencies, and “identity” seem to be fading. Blockchains don’t seem to be an overwhelmingly great technology for these problems.

Some use cases are still up in the air. Executable contracts, AKA, “smart contracts” are the flavor of the month in some circles, despite their catastrophic track record to date.

Other use cases for blockchains are still cooking. Land registries seem to be a good fit—though mainly as a convenience on top of already functioning legal systems.  Other similar registries might work, provided the legals are worked out.

But the one use case that is coming on very strong is “supply chains”. Blockchains are a pretty interesting technology for Provenance and, apparently, for seaports.

This summer, Antwerp’s gigantic container port joins Rotterdam and other major centers, doing their or pilot projects with blockchain technology [3].

As Noelle Acheson, points out in Coindesk, blockchain technology is getting serious attention from seaports, for many good reasons [1]. These operations are huge and operate on small margins. Even a tiny cost savings can amount to huge savings. Furthermore, there are zillions of companies all doing business with each other, based all around the world. Blockchain technology, or something similar, offers the hope of easy interoperability at minimal cost.

It seems to me that the case is pretty clear. Everything is already managed digitally, so much of the infrastructure (id codes, digital records, etc.) is already in place. I note that companies such as IBM and Microsoft are participating in these developments, and have built the current systems. I’m not sure if this is “disruption”, or just next generation engineering.

In addition, many of the operations can tolerate moderate latency, minutes or even hours to complete a transaction. Blockchain technology can meet such a requirement, even if it can’t handle the speed and scale of other cases.

This application makes use of public key cryptography to implement chains of trust and to share data in controlled ways. These are perfect use cases for PKI, with or without blockchains, per se.

The use case also requires interoperation among many, many players. This requires open interfaces and open data standards, for sure. Blockchain technology can be used as a robust mechanism for these machine interactions. It’s not the only way to do it, but blockchain may be a pretty good way.

Acheson suggests that the decentralized nature of blockchain should improve the security of the system, or at least the robustness in the face of cyber attack.

a distributed network of blockchain platforms could enhance the security and integrity of key operations

I’m not so sure how strong this case is, because the blockchain is only a tiny fraction of the whole system, and, in fact, not the most vulnerable. (For example, knocking systems off line stops operations, blockchain or no.) Given that the blockchain based system will introduce new vulnerabilities, it is difficult to say what the overall security implications are.

Acheson also suggests that there should be some kind of global standard and industry consortium to implement these concepts.

“it’s curious that an international blockchain consortium of ports and shippers has not yet emerged.

I’m not surprised and don’t really expect this to happen. First of all, shipping has been going on for millennia, and even today is characterized by a pretty loose set of agreements, ad hoc, and de facto processes.  Second, the internet itself works without such standards.  And third, these systems are built by global companies, which resist such non-competitive arrangements.  In short, don’t hold your breath.

Finally, I note that this use case suggests the importance of both public and private blockchains. For some purposes, especially consumer confidence and compliance, a public trace of sources is ideal. The Provenance.org people are looking at a public blockchain for this purpose.

On the other hand, container port operations probably will use a private blockchain for most of the work, or perhaps multiple private blockchains. There is no need for this information to be public (though it will be easy to audit when needed), and good reasons why the details should be private. For example, if you are worried about cyber security, you probably don’t want any kid on the Internet to be able to track your shipment of industrial chemicals every centimeter of its transfer. Nor do you want your competition monitoring your shipping traffic in order to infer details of your production capabilities and plans.

The bottom line is that blockchain technology may be a very useful augmentation for the already highly organized, digitized, and optimized business of transportation. It’s not quite as sexy as “reinventing money”, but it’s probably a good use of the technology, and it appears to have a strong economic case, too.


  1. Noelle Acheson Port of Call: Blockchain’s Impact on Supply Chains is Broader Than It Seems. Coindesk.July 3 2017, http://www.coindesk.com/port-call-blockchains-impact-supply-chains-broader-seems/
  2. Don Tapscott and Alex Tapscott, Blockchain Revolution: How the Technology Behind Bitcoin is Changing Money, Business, and the World, New York, Portfolio/Penguin, 2016.
  3. Wolfie Zhao, Europe’s Second Largest Port Launches Blockchain Logistics Pilot. Coindesk.June 28 2017, http://www.coindesk.com/europes-second-largest-port-launches-blockchain-logistics-pilot/

 

Cryptocurrency Thursday