With ruby to space and back

It is pretty amazing to live in a time when it is possible to broadcast data through satellites to pretty much the whole planet. The Blockstream Satellite project makes this possible. 

image

Their Satellite network not only broadcasts the Bitcoin blockchain around the world 24/7 for free but also provides an API that allows everybody to broadcast messages through this network. This is possible for for a small fee payable through the Bitcoin lightning network.

To make it easy to broadcast messages from any ruby application I’ve written the blocksteam satellite gem.

The ruby package sends broadcast orders to the API and uses a connected lightning (lnd) node to pay for the order.

Check out the quick example:


require "blockstream_satellite"

order = BlockstreamSatellite::Order.create(path: '/path/to/file')

puts order.status #=> pending
order.pay # sends the lightning payment using the configured lnd client

puts order.status #=> transmitting
order.refresh
puts order.status #=> sent

Have fun using ruby to send data to space and back!

Bitcoin lightning machine-to-machine API payments

The Bitcoin lightning network is growing quickly. The lightning network is an exciting second layer protocol on top of the Bitcoin network that allows to send real near-instant payments and is perfectly suited for micro-/nano-transactions.

The tools already work great and make it super easy for developers to integrate with the lightning network.

I’ve lately experimented with it and built a demo to show machine-to-machine API payments. It allows the server to request a payment from the client; the client can automatically pay the invoice to access the resource from the server.

The basic workflow is as follows:

  1. Client sends a request to the server
  2. Server response with an invoice
  3. Client pays and sends a proof to the server
  4. Server responds with the requested resource

To make it easy for the developer all this can happen in the background so the payment logic can be abstracted and hidden from the developer.

Here is a small ruby application that exposes an endpoint to convert markdown to pdf but requires the client to pay 100 satoshi (currently 0.44 cent) per request.

You can find the code here on GitHub. And I made a short video showing how it works:

Introducing rack-lightning

To make it easy for every ruby developer to add lightning payment requests to any ruby application I've written rack-lightning.

rack-lightning is a rack middleware that handles the lightning invoice creation and validation on the server.

A full usage example can be found on GitHub, but it is not more than adding one line of rack code:


use Rack::Lightning, { price: 100 } 

Have a look at the GitHub page for more information.


Introducing lightning faraday middleware

And to make it easy on the client side I've written a faraday middleware that handles the payment requests on the client: faraday_ln_paywall

The middleware handles the payment of the invoice. Her is a quick useage example:


# initialize a client
client = Faraday.new(:url => 'https://lightning-2pdf.herokuapp.com/') do |faraday|
  faraday.use FaradayLnPaywall::Middleware, { max_amount: 100 }
  faraday.adapter  Faraday.default_adapter
end

# use the client to do API calls:
puts client.post("/convert/pdf", "# Hallo Welt").body

Head over to the GitHub repository for more information.


Similar projects

A few years back I did something similar with pure bitcoin.

And an exciting project is lightning.ws that does something similar in Go

OpenAlias lookup with ruby

Halloween nights are scary and you are supposed to do scary things. This year I had a few hours in the hotel and so I've built a ruby wrapper around the openalias.rs rust package. That is scary because I have no idea about rust :D

But fist things first, what is OpenAlias?
OpenAlias is an open standard for simpler addresses for any crypto currencies.
It is a DNS based alias system that allows you to use a domain to lookup a cryptocurrency address. So for example, if your wallets supports it (e.g. Electrum) you can simply send Bitcoin to “michaelbumann.com” instead of my Bitcoin address.

At its most basic, OpenAlias is a TXT DNS record on a FQDN (fully qualified domain name). By combining this with DNS-related technologies [it has] created an aliasing standard that is extensible for developers, intuitive and familiar for users, and can interoperate with both centralised and decentralised domain systems.

Find more details on the OpenAlias.org website

What did I built? For rust there is a package that does the DNS lookup and parsing of the OpenAlias entries. But we should have one for any language to make it easy for developers to integrate OpenAlias. That's why I made this ruby gem that ruby developers can use in their apps and use OpenAlias.
Right now it is using the rust library as a native extension, but at some point I might write a pure ruby one.

Have a look at bumi/openalias-ruby on GitHub.

How to install your own bank and payment service - your bitcoin and lightning node

I’ve recently updated and re-installed some of my servers and bitcoin and lightning nodes that I am running. It’s amazing how easy it is to run and operate your own bank and payment service. And I encourage everybody to operate your own bitcoin full-node and lightning node. 

Even though there are plenty of resources out there on how to install everything you need on the various systems, here are a few notes on my setup. -  maybe it helps somebody. :) 

I am running currently: 

* Bitcoin core 0.17.0
* lnd 0.5.0-beta

My goal is to have my setup as simple and as default as possible. I am using the default packages where possible and I try to be able to update to latest versions quickly.
For parts of the setup I am using some custom ansible scripts which I will not cover here (ansible is rather sooner than later a pain anyway and you should not use it)

0. Install basic system packages

build-essential, git, unattended-upgrades, vim, zsh,...

make sure to secure your system: ufw, fail2ban, lynis, rkhunter

1. Install and configure bitcoind

The how-to run a full node on bitcoin.org has all the information you need to install bitcoind.

Basically installing bitcoind from the bitcoin ubuntu packages repository:

sudo apt-add-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install bitcoind

I am running bitcoind as bitcoin user and have all the bitcoind data and config stored in the bitcoin’s home directory. 

useradd -m bitcoin
mkdir /home/bitcoin/bitcoind_data

Adjust your bitcoind configuration. You can use the config file generator by Jameson Lopp. You also find all the config options in the wiki.

This is my config file - pretty standard, except the bitcoin datadir and the zeromq config that we will need later for lnd.

This is the default bitcoin systemd service configuration. By default it is loading the bitcoin.conf from /etc/bitcoin/bitcoin.conf. Though I am also storing the config file in the bitcoin dir /home/bitcoin/bitcoind_data which makes it easier for lnd to find it.

Don’t forget to open the bitcoin port; typically 8333 (ufw allow 8333)

Now you should be able run bitcoind using systemctl 

sudo systemctl start bitcoind
sudo systemctl status bitcoind

When you want to see the logs in journalctl -u bitcoind you have to make sure that you are not running bitcoind as a daemon, change the Type in the of the systemd service from forking to simple and configure the printtoconsole bitcoind option. Otherwise it does print to console and the logs can not be captured. - But you can just look at the debug.log :)

Also note: when you update the bitcoind installation the systemd service and potentially your changes get overwritten.

2. Install and configure lnd

To run lnd you need go 1.10 or better 1.11. I’ve manually downloaded go and extracted it to /usr/lib/go-1.11/
Make sure to that you have the go binary in your $PATH. I’ve linked the go bin to /usr/local/bin 

sudo ln -s /usr/lib/go-1.11/bin/go /usr/local/bin/go

Also make sure that $GOPATH/bin is in your $PATH for all go installed executables.
I’ve added a /etc/profile.d/go.sh with:

export GOPATH=~/go
export PATH=$PATH:$GOPATH/bin

Once go is working install lnd as described here in the official installation notes. Make sure to run this from the bitcoin user as we have the default $GOPATH  ~/go .

Similar to bitcoind I have LND configured to use /home/bitcoin/lnd_data as main lnd directory. This is my lnd.conf.

If you want to access your LND node remotely (for example from a mobile app) you need to configure it to rpclisten on a public interface and the port 10009 (default) must be open.

LND needs uses zeromq to read data from bitcoind so make sure you configured bitcoind with the zeromq config mentioned above. 

And try your lnd setup:

lnd --configfile=/home/bitcoin/lnd_data/lnd.conf

It will tell you to create a wallet using lnci

lncli --lnddir=/home/bitcoin/lnd_data create

I use systemd to run lnd as a service. This is my service configuration which goes in /lib/systemd/system/lnd.service (don’t forget to systemctl enable it)
But please note that the wallet needs to be unlocked using the lncli on every start of lnd manually.

That should be it! Your bitcoin and lightning node should be up and running! Now it’s time for the fun part :)

3. Setup your client GUI

So far I have tried the following lighting apps connected with my LND node:

To connect those client to you wallet you will need the tls.cert and the admin.macaroon. These files can be found in the lnd directory:

/home/bitcoin/lnd_data/tls.cert and /home/bitcoin/lnd_data/data/chain/bitcoin/mainnet/admin.macaroon

For ZAP iOS there is zapconnect that generates a QR code that can be scanned to configure the mobile client. Union7 has a similar feature described in the FAQ.

Once connected you can use the client or the lncli to get a new bitcoin address and fund your lightning wallet.

lncli --lnddir=/home/bitcoin/lnd_data newaddress p2wkh

Now it is time to go shopping! Maybe checkout bitrefill, Y’alls or buy some pixels on satoshis.place
All those sites have instructions on how to open channels. Also have a look at explorers like 1ML

If you have trouble, let me know! 

if this did not help, maybe this write up has the right info for you

Wrapping Ethereum smart contracts and IPFS objects in a GraphQL API?

I was just chatting with the always inspiring Max today about GraphQL.I’ve never really used GraphQL in production but I am pretty excited about the flexibility it brings for clients to query data from a server. GraphQL provides a easily understandable description of the data an API provides and gives the client the possibility to query exactly the data it needs in one single request. 

Currently I am not building any APIs but requesting data from Ethereum smart contracts, IPFS, etc. And one of the problems in my opinion is querying data from the different sources which adds quite some complexity and leads to loads of HTTP requests to get all the data.

For example: we store user profiles in a mapping:

mapping(address => string) public profiles;

They key is the user’s account address and the value is an IPFS hash containing detailed profile data.
To retrieve all profiles (including the data from IPFS) in our dAPP (client side JS) we would need to somehow iterate over the the mapping (which is already hard enough) and then request the profile object from IPFS.

Quite some code manage the fetching of some rather simple data and I actually don’t like that UI developers have to deal with that.

So the question arose if it is possible to create a GraphQL wrapper for smart contracts, IPFS objects, etc.?
Using the smart contract’s ABI and some custom resolvers this should be possible. The same wrapper API could make it easier for different clients and tools be built on top of that.

Now one could say we don’t want the additional server component, but as it is just loading data from the networks and prepares it for the UI I think that’s not a problem and just a useful addition to the dApp architecture.
The frontend and this GraphQL server component could still be deployed wherever and no central installation is required.

What do you think? did anyone try GraphQL in that context already?

bundle thank-you - a donation system for ruby gems (and other package managers)

Nearly two years ago I’ve experimented with the idea of using bitcoin payments to tip open source projects. The idea is to analyze the dependencies of a project (by parsing the bundler Gemfile or npm package.json), extract donation information and send a “thank you” to these projects. 

Bitcoin is the perfect protocol for this. We can directly transfer value and do not need any intermediary. The projects and users do not have to agree on a service provider (like paypal or patreon), no signup es required. It is implemented on a protocol level and not as a tool/service.

As a demo I had created a small video showing the interaction and user flow:

How does it work?

Thanks to the nature of Bitcoin transactions it is possible (and even encouraged) to send one transaction to multiple recipients (outputs).

bundle-thankyou analyzes the dependencies from the package manger file (Gemfile, package.json,...) and gathers the recipient addresses from the locally installed gems - thus no need for a central directory or similar.
Then we the user is asked how much should be paid and a single transaction is created and published. Done.

Obviously one could envision any fancy user interface and features to do that.

What the author needs to do:

The gem author adds a Bitcoin address to the gemspec (in the metadata field).
That’s all the author has to do.

Because the address is in the gemspec we can be sure it is the address the author/maintainer wants the money to go to.

The author could also decide to dedicate the donations to somebody else. For example the rails gems could say thankyous should go to RailsGirls or similar projects.

What the user has to do:

Use this tool and basically run bundle thankyou and pay the desired amount. The amount will automatically be split among all the used gems.

With Bitcoin becoming more and more popular it also gets easier for people to start using it. And it would also be possible to create a service on top of this “standard” that allows users to pay with credit cards and handles the bitcoin payments.

Advantages

  • No signup whatsover
  • User and maintainer do not need to agree on a service (like paypal) to perform the transaction
  • No central directories and services
  • Based on existing tools (rubygems, npm, etc.)
  • Implemented on a "standard/protocol level" - additional service can be built and integrated. (like any existing bitcoin services, subscriptions, etc.)
  • Works internationally (not everybody has a credit card or can have a paypal account)
  • One transaction for multiple recipients
  • Usable in the moment where the user interacts with the gems (in the terminal running a bundle command)

Questions:

Why Bitcoin?
It is probably the most broadly adopted solution. But any other cryptocurrency would be possible.

But I want to pay with credit card (or whatever else)
Bitcoin is used as a method/"protocol" to transfer value.

We could provide additional service (for both user and project maintainer separately) to better fit their needs - for example different payment methods, subscriptions, etc. For example card payments could be easily possible with services like Coinbase.

But I want to receive payments on my credit card
Again Bitcoin is the "protocol". There are already plenty tools out there that for example give you a visa/master card for spending the received bitcoins. Or bank transfers, or m-pesa mobile money payments, or....

A comment about money

I am very critical about the human perception of the "payment". I do not want it to feel like I've "paid" somebody for something.
The tone/message is super important and it should not be "payment" but a way of saying "thank you"... thus bundle thankyou.

My tattoo from the Kaila devi fair

Earlier this year I’ve been in SE Asia and while visiting Myanmar/Burma my good friend Puneet told me he will visit his mother in India. As I was thinking about moving to India after Myanmar anyway I was excited about the chance to meet him and his mother there! 

I really like all the places I’ve seen in India so far and it has been great again! 
Puneet now wrote on his blog about our visit at the Kaila devi fair where we ended up getting the most beautiful tattoos ever!

I never thought I ever will get a tattoo - something that will be there forever?! - on a small village fair in the middle of nowhere it happened. I enjoyed the fair a lot and I got excited about the tattoo artists… so it happened I got a small, beautiful, ugly memory of that time and the fair :) 

Read the full story on Puneet’s blog… check it out also for pictures and details about the fair. 

…and there are some photos on my flickr stream.

image
image
image

Advertisement for the army?

So here is a question: As far as I know doctors in Germany are not allowed to advertise freely and there are tough regulations on advertisement…. but I have to constantly see that advertisement for the German army that looks more like a first-person shooter video game?!?

During a games convention in Cologne the whole city was full of video-game like advertisement to join the army and to “do what really counts”… in “Mali” “[saving democracy]” for “our country”…

Wouldn’t it be nice if doctors are also allowed to freely advertise?

image

#IamSatoshi - we are all Satoshi

image

So there have been again some big media houses publishing stories that they have found Satoshi Nakamoto. This time again for real, really... trust us. 

The Bitcoin boards on reddit are full of posts about the story. Most of them are very critical and arguing it is a hoax. (wondering why the media companies always fail on that...but that’s a different story)

It seems the whole Bitcoin world has no better topic to talk about. And it seems it gets forgotten that Bitcoin is decentralized and open source... 

#IamSatoshi

Even though if someone will be able to proof that she is Satoshi Nakamoto...it does not matter at all in the decentralized network.

All the contributors of all the implementations are Satoshi. All the people publishing source code for the bitcoin ecosystem are Satoshi. All the people writing documentation, articles, help on forums. Everyone involved in mining. Everyone who runs a Bitcoin node. All the organizers of the many Bitcoin related meetups, all the meetup attendees. All the companies working on Bitcoin related stuff. Everyone using Bitcoin, and I the list goes on and on... #IamSatoshi

Let’s keep on working together on Bitcoin the peer to peer network. 

We are all Satoshi - How are you Satoshi?

Online payments: transfer value instead of information

First online payments happened before SSL was officially released and browsers could not make secure connections. A custom client had to be used to transfer the card details securely from the customer to the merchant. That was around 1994. Today 90% of online transactions in the US are card payments. The international numbers are probably lower with significant higher numbers for local, alternative payment methods. But the concept is all the same:

The customer transfers some information (card details, account numbers, etc.) to the merchant which uses a service provider (PSP) to pull money from the customer’s account through all the middle-men (acquirer, card network, banks,..) using that information. (or, in case both merchant and customer use the same wallet provider a closed loop transaction is done (for example PayPal).

To allow customers to pay with their payment option of choice merchants have to ideally integrate all options. Obviously a huge effort for the merchant. And many merchants only accept card payments leaving unserved all the people without cards. Crappy payment usability is probably still one of the main conversion killers.

But: value should be transferred instead of information

Since Bitcoin we have a rather widely adopted option of transferring digital value directly between two parties. Which means we actually no longer have to transfer payment information in order to pay.

One idea that I think has too little attention is the need for better integrations of wallets into browsers.
This would allow us to move the payment method selection to the client. Imagine your bank or card provider gives you a tool to pay online. Basically a tool that understands the bitcoin payment protocol and does the transaction for you. Any company could provide their customers such a solution (possibly even with additional services like dispute mediation, insurance, etc.).
No longer the merchant decides which payment instruments their customers must have access to but the customer chooses the favorite one - as long as it can transfer value in the defined standard to the merchant.

For the merchant it will be way easier to integrate payments, no need to integrate a broad range of payment options. It comes with usability improvements for the customer.

This is not a new idea, and has probably been around since the ecash times. But with Bitcoin for the first time a increasingly, widely adopted standard for digital value exchange exists. It makes it possible to transfer “money” directly instead of some information how to access the money.

image

W3C payment standardization process

Since years there has been activities around the W3C to standardize the web payment process which would make it easier for merchants to integrate payments as well as improving the usability for customers. The whole activities has imho been/is a bit confusing with many working groups, interest groups, task forces, competing standards, etc. but probably I just know to little about the W3C works ;)

I think it is super important that the payment flows become standardized, even though it seems the focus ist still on transferring payment information.
There has been a lot of activity lately at the web payments working group which is worth following. Also very - maybe even more interesting - is the Interledger payments community group.

tl;dr: let’s move the payment method selection from the merchant’s site to the client and transfer value directly and not stupid payment information (like card details).