True Micropayments with Bitcoin
medium.com
medium.com
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
And BitPay released this as part of BitCore around 1.5 years ago: 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.
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.
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...
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.
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).
>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.
Maybe you could get paid for being a botnet node.
1. http://altheamesh.com/documents/universal-payment-channels.p...
[1] https://books.google.com/books?id=0TsEAAAAMBAJ&pg=PA92&lpg=P...
... for now. Gigabit endpoint links and super cheap storage could close that gap.
Mainframe/PC is one of the great oscillating "cycles of reincarnation" in computing. It's been mainframe for a while now but I get the sense it's ready to swing.
It's not micropayments holding back decentralized compute, it's that fact that you are dealing with untrusted counterparties.
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."
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.
And here a unidirectional payment channel contract for Ethereum (.sol file): https://github.com/obscuren/whisper-payment-channel
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.
Yes, you could design a new micropayments system denominated in dollars with electronic wallets that would piggyback off card and bank payment networks, but you would add latency in flushing (admittedly negligible) amounts to your bank, and if your service became large enough, credit card providers would probably disallow you from using their infrastructure to deposit billions of tiny amounts into micropayment wallets, which would generate a lot of overhead and fees for a relatively small transaction volume.
Seems to me that the reason this micropayment startup doesn't exist is because it wouldn't solve any pressing problem at the moment.
https://21.co/learn/intro-to-micropayment-channels/#how-micr...
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]
As for 21, they raised 100mil because one of the founders used to work at a vc firm. Now they are making mining chips that are far slower than state of the art, and reimplementing Bitcoin library code from 4 years ago.
1. http://altheamesh.com/documents/universal-payment-channels.p...
Their original offering was indeed a centralized off-chain payment network, where they hold funds on behalf of everyone and just move coins in their own internal database. https://21.co/learn/21-micropayments/#off-chain-transactions...
What they released now is a trustless solution based on "real" bitcoin payments: https://21.co/learn/21-micropayments/#micropayment-channels
(Note, however, that this exists for nearly two years as part of BitcoinJ and other libraries... https://news.ycombinator.com/item?id=11100518)
What's the point of the "miner", then? You don't need it to do transactions. This could be a pure software product.
The best theory I've heard is a charger that mines BTC for you when it's done charging your phone for the night.
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...