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.
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.
Correction: the bitcointalk link above is wrong, it should be 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).
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.
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/ ... 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.
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?
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.
> 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).
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/
>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.
BoilerGrid has been in use for years. I they have an automatic checkpoint system so your job/program can get evicted (either forced, like with a human logging into the node or via node failure), find a new node, and resume its progress.
We've had micropayment channels since 2012. You can even do micropayment channels with regular money[1]. All that's happened is that 21 put one in their api. I doubt that any hing is going to change that didn't change when they were invented in 2012.
I think equivalence at least with cloud is possible for most tasks except those that require vast amounts of local data.
... 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.
The problem with that is privacy and security. Any machine you trust with the computation can both see the data and can compute dishonestly, unless you use (extremely!) expensive forms of encryption and verification.
It's not micropayments holding back decentralized compute, it's that fact that you are dealing with untrusted counterparties.
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/
I am very interested in your opinion and I hope it is not considered rude that I am posting here.
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.
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.
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]
They use Bitcoin due to its granularity (1 Satoshi = 0.0000040352 USD) and because users can mine a small trickle of new money easily with the hardware they have designed. But mainly because it's much easier than bootstrapping users onto a new payments network from scratch.
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.
This is what I designed, however I am not going to do a startup with it[1]. Feel free to do it yourself, email me and I'll get you up to speed on the implementation.
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.
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.
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.
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?
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.
No, phones don't use power after they're done charging (they might trickle-charge[1], but that uses a fraction of the power). That would either destroy the battery or heat up your phone to spend that energy.
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.
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...
The energy that idle chargers use up is negligible, and even then, it's not as if you can just turn that into computational power. You'd still need to consume (significantly) more energy to mine.
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.