
True Micropayments with Bitcoin - oska
https://medium.com/@21/true-micropayments-with-bitcoin-e64fec23ffd8#.s8ezmd20q
======
nadaviv
This is an implementation of "simple" directional payment channels between two
parties, without the concept of hubs (as in the original LN) or p2p routing
(as we have in LN today), and which expire at at a pre-determined timestamp
(forcing you to close & re-open the channel every once in awhile).

This is useful for cases where one party wants to send payments in small
increments to another party (e.g. pay-per-kilobyte for internet access). Funds
locked up in the channel are only usable for transacting between the two
parties, and funds can only be sent in one direction.

BitcoinJ implemented this nearly two years ago:
[https://bitcointalk.org/index.php?topic=945401.0](https://bitcointalk.org/index.php?topic=945401.0)

And BitPay released this as part of BitCore around 1.5 years ago:
[https://github.com/bitpay/bitcore-channel](https://github.com/bitpay/bitcore-
channel)

The innovation in payments channels being discussed nowadays is something
completely different: bi-directional payment channels that can be kept open
indefinitely, with a peer-to-peer routing layer that makes it possible to send
off-chain payments to anyone in the network and not just to one specific
party.

~~~
nadaviv
Correction: the bitcointalk link above is wrong, it should be
[https://bitcointalk.org/index.php?topic=244656.0](https://bitcointalk.org/index.php?topic=244656.0).
I also got the times wrong because of that - BitcoinJ released payment channel
support 2.5 years ago, not "nearly two years ago" as in the original comment
(which cannot be edited now).

------
RustyRussell
(Disclaimer, work for Blockstream on Lightning).

Commenters are right that micropayment channels have been around for years;
but they're not widely used; more convenience is a big win. Lightning uses
more sophisticated generalised 2-way channels, plus routing to form a network,
but it's still early days.

~~~
contingencies
Smiles from China Rusty. We met back in Sydney in the late 90s/early
noughties. I wrote a Wikipedia page for your pettycoin project but it was
deleted by the notability police. Funny that it changed your career path, as
I'd found it significant in distant observation! Congrats on the new role. I
was in touch with your apparent new co-worker Jorge (congrats to him too) on
the more socially engaged side of economies circa time of writing
[http://www.ifex-project.org/](http://www.ifex-project.org/) ... I left Kraken
now, still thinking to push IFEX forward if anyone expresses interest. Too
many of these new systems have assumptions baked in, IMHO we still need a
business-level transaction protocol that doesn't suck to glue these
innovations together with conventional assets/systems of exchange and to
justify (possibly automatically) in business terms (speed, reputation,
redundancy, assets supported, jurisdictions (not) traversed, etc.) versus a
well expressed risk model (critical) why they should be used. I feel this is a
big part of the lineage-of-cryptoanarchist fintech equation that is missing if
broad social adoption is desired.

------
roymurdock
_The scale of the Bitcoin mining buildout indicates that grid computing may
indeed be feasible after all given the appropriate compensation, and
potentially better than or competitive with cloud computing for some
applications.

Now that we have a quick way to set up a fine-grained bitcoin micropayments
channel between any two machines, an obvious next step is to start
generalizing this to the renting out of other compute resources beyond just
storage._ [1]

Can anyone provide an example of a problem that would be better solved with
grid computing/micropayments instead of cloud computing?

[1] [https://21.co/learn/grid-computing-with-bitcoin-
micropayment...](https://21.co/learn/grid-computing-with-bitcoin-
micropayments/#bitcoin-mining-as-grid-computing)

~~~
ikeboy
Assuming grid computing ends up cheaper, any problem that doesn't depend on
high availability.

Why grid computing might be cheaper: people could rent out excess capability
that would otherwise go wasted, so their marginal cost of computing is 0 or
close to 0. The question is how much overhead would be, but building on a
marginal cost of 0 is better for costs than any dedicated solution.

It's not obvious that those considerations outweigh the cost efficiencies of
centralization, but it's by no means obvious that they wouldn't or can't.

Think the power grid as an example. If power wasn't fungible in close to real
time (like cloud computing today, unless you specifically set it up that way)
our prices would be more expensive, because less participants would be
producing energy. The fact that anyone can, in theory, produce energy and sell
it on a market which accepts the best bid improves the market for everyone.
This seems similar.

~~~
roymurdock
> any problem that doesn't depend on high availability

Do you have any specific examples of resource-intensive computing problems
(other than SETI@home) that do not depend on high availability? Seems a bit
like a solution in search of a problem.

I like your example of the power grid as an explanation for how owners of
small amounts of computing power might interact with the larger system and
have an impact on market prices. But if the analogy truly holds, it would be a
good indication of how negligible rewards would be to smaller entities
(individuals running computers or smartphones).

~~~
ikeboy
Anything that would currently use AWS spot instances. Amazon created it, so we
can assume there's a market for "cheaper, but lower availability". Google has
something similar [https://cloud.google.com/preemptible-
vms/](https://cloud.google.com/preemptible-vms/)

>I like your example of the power grid as an explanation for how owners of
small amounts of computing power might interact with the larger system and
have an impact on market prices. But if the analogy truly holds, it would be a
good indication of how negligible rewards would be to smaller entities
(individuals running computers or smartphones).

I'm not thinking of individuals making a living off of their one computer. But
surely there's a significant amount of computing power in datacenters that
goes unused, or not optimally used. Now, they could manually partner with
other datacenters to absorb excess capacity, and bargain a price individually.
But if grid computing becomes a thing, all they'd have to do is hook up a
bidder to their excess capacity.

Admittedly, focusing on high capacity entities makes it harder to see
micropayments as helpful. Even if the minimum transfer amount was $100, it
would still be worth it for datacenter operators to trade on such a market.

~~~
eru
The smaller the minimum payment, the closer you can fit the area under the
curve.

------
konschubert
I recently drafted a protocol for micropayments. It is almost trivial, and
while it requires a trusted payment provider which issues and validates
tokens, the way it is designed should prevent any vendor lock-ins. My goal was
to design something that avoids the need for user authentication and logins
towards the website which provides content or services. Anyway, here's the
link to the specification I wrote:
[http://konstantinschubert.github.io/pennytoken-
spec/](http://konstantinschubert.github.io/pennytoken-spec/) I am very
interested in your opinion and I hope it is not considered rude that I am
posting here.

~~~
clarkmoody
_> while it requires a trusted payment provider which issues and validates
tokens_

The most interesting part about Bitcoin micropayments is that they can be done
in such a way that you do not have to trust a "payment provider."

~~~
konschubert
I know. But I think at least for instantaneous payments you will need SOME
trusted party, even if you trust this party only for small amounts and a
limited amount of time. Also, regarding bitcoin, I'm worried about the future
of the network after the recent drama and I'm concerned about the computing
resources spent in securing the network. I realize that this expense in
securing the network is a necessary component of the game theory. But apart
from the ecological impact, I think that the cost of it might be higher than
trusting a provider who is ultimately backed by the state.

I think bitcoin is amazing and I'd love for it to succeed. However, I believe
that for micropayments, the most pragmatic solution might be the one with
trust involved.

------
7373737373
Related, here is a probabilistic nanopayment implementation for Bitcoin:
[https://github.com/paulkernfeld/bitcoin-
nanopayment](https://github.com/paulkernfeld/bitcoin-nanopayment)

And here a unidirectional payment channel contract for Ethereum (.sol file):
[https://github.com/obscuren/whisper-payment-
channel](https://github.com/obscuren/whisper-payment-channel)

------
Animats
This is really a private payment network that happens to be denominated in
Bitcoins. You have a balance denominated in Bitcoins on a server at "21.co".
"Before you can execute an off-chain transaction in the 21 system, you need a
bitcoin balance at 21.co." It's a centralized micropayment system. So only
people with 21.co accounts can play. Hey, it worked for PayPal.

You can initiate a "flush" transaction which asks "21.co" to sell you real
Bitcoins in exchange for their book-entry Bitcoins. Sellers would presumably
do this at least once a day, avoiding keeping a substantial balance on
"21.co". Given the track record of "hosted Bitcoin wallets", which tend to be
"take the money and run" operations (anyone knowing the whereabouts of
Cryptsy's "Big Vern", please contact the Silver Law Firm) that's a good
feature.

There's no real reason this needs Bitcoins at all. This scheme would work if
it was denominated in dollars. There's a startup opportunity here. Reuse the
micropayment system, forget about the Bitcoins. You'd deposit money into your
micropayment account with a credit card, and your computer can then spend
against that balance. Merchants could "flush" their balance via an ACH
transfer to their bank.

~~~
comex
This is false. The micropayments system they are using is based on fancy
Bitcoin transactions and does not require anyone to be trusted:

[https://21.co/learn/intro-to-micropayment-channels/#how-
micr...](https://21.co/learn/intro-to-micropayment-channels/#how-micropayment-
channels-work)

~~~
Animats
When they actually do it that way, the "channel" relationship is between buyer
and seller, without going through "21.co". That's fine. But that only works if
you do enough transactions with one buyer to justify a blockchain transaction.
You have to tie up some predetermined amount of BTC for a day or so, and you
get back change for what isn't used. That's a pain.

The more common case is what they call "Off-Chain Transactions
(BitTransfers)". "21.co" acts as a clearing agent for microtransactions, and
so you have funds tied up against "21.co", not with the seller. This involve
some degree of trust in "21.co", in that they can potentially steal your
balance. (In keeping with Bitcoin scam tradition, they'd probably claim they
were "hacked".)

Their terms of service demand confidential arbitration (!), so you're gagged
if they screw you.[1]

[1] [https://21.co/terms-of-use/#dispute-resolution](https://21.co/terms-of-
use/#dispute-resolution)

------
Animats
Let's take a look at their Bitcoin miner. From their FAQ: $399, 50 gigahashes
per second, 0.16 Joules per gigahash. Plugging those numbers into a Bitcoin
mining calculator [1], initial revenue is under $0.05/day, and declines as the
difficulty increases, until you're paying more for power than you're getting
out in Bitcoins within a year. This does not make sense financially.

What's the point of the "miner", then? You don't need it to do transactions.
This could be a pure software product.

[1]
[https://bitcoinwisdom.com/bitcoin/calculator](https://bitcoinwisdom.com/bitcoin/calculator)

~~~
solotronics
the point is to remove the barrier of buying bitcoins and instead give these
new users a bitcoin generator so they can try out bitcoins.. its less about
being profitable and more about providing a platform to participate in the
bitcoin ecosystem.

------
LAMike
This solves the problem of inflating the Blockchain, now a user can have
multiple offline transactions and have it count as only 1 when everything is
settled. Anyone else think Micropayments in Bitcoin will be it's killer app?

~~~
stale2002
We could be doing that now, on the blockchain instead. Inflating the block
chain isn't really a "problem" until you get to very large values.

~~~
rasz_pl
what is the current max speed of transactions again? yeah, that what I thought

~~~
grubles
It worked for Satoshi Dice, which happened to sell for ~$11,000,000.

------
dbalan
That device looks awefully lot like a Raspberry PI. Anyone know the exact
spec?

~~~
tlrobinson
It's a Raspberry Pi 2 with 21's mining chip.

------
LAMike
Anyone have any guesses on what the 21 team will release as a product for
consumers?

The best theory I've heard is a charger that mines BTC for you when it's done
charging your phone for the night.

~~~
tommynicholas
That is an excellent idea, doesn't your phone continue to use power after it's
done charging? This wouldn't produce a ton of Bitcoin but it would be an
opportunity for a net-positive outcome from a cost perspective which is
clever.

~~~
ssharp
How is it net-positive from a cost perspective? From what I remember, 21 takes
a large cut of the Bitcoin "mined" and you'll spend far more on electricity
than you'll get in return for Bitcoin.

~~~
nadaviv
You're right indeed. 21's mining chip does give a negative ROI, even in areas
where electricity is very cheap.

Why would anyone buy a $400 mining chip that costs more in electricity than it
produces in bitcoins, when they can just buy $400 worth of bitcoins? Beats
me...

~~~
jsprogrammer
Because they aren't paying for the electricity?

------
ukd1
Isn't the library already out here?
[https://testpypi.python.org/pypi/two1](https://testpypi.python.org/pypi/two1)

