Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Credit card transactions generally take 2.9% + $0.30, which completely removes the possibility of making money on micropayments. Theoretically crypto should enable lower-fee transactions which could enable micropayments.

I say that, but a transaction on the Bitcoin ledger has been more expensive than $0.15 since mid-2016 and fluctuates wildly. Other cryptocurrencies might be able to handle this better. I'm optimistic about Stellar being a useful transaction network, but I don't think the value of 1 XLM is going to move much relative to 1 USD.



Micropayments and cryptocurrencies are really separate concerns.

All you need for micropayments are low fees - that doesn't require a pseudo-anonymous collective keeping a shared public database of transactions. In fact it's better if you know who the counterparties are.

Companies like stripe, apple, google or banks like monzo could offer low fee transactions for example between two counter-parties who are both customers, bypassing payments networks and taking on a little more risk for a lower fee.

Payment networks are ripe for disruption, but I'm not sure bitcoin et al will do the disrupting - it's solving the wrong problems.


> All you need for micropayments are low fees - that doesn't require a pseudo-anonymous collective keeping a shared public database of transactions.

Oddly it kind of does, but for bad reasons.

Existing rules for payment processing basically require the payment processor to eat the cost of fraud. That means you can't have small transaction fees because they have to cover the cost of fraud or the payment processor goes out of business.

A payments system where there is no "payment processor" middle man to foist the cost of fraud onto thereby doesn't require that middle man to charge high transaction fees to cover it. In principle that could allow lower transaction fees.

> Companies like stripe, apple, google or banks like monzo could offer low fee transactions for example between two counter-parties who are both customers, bypassing payments networks and taking on a little more risk for a lower fee.

Scenario: Mal uses your payment service to buy goods from Alice, Bob and Carol and pays you with a credit card, possibly stolen. As soon as the goods change hands, Mal (or the real owner of the card) disputes the charge with the credit card company.

You have a bootstrapping problem. You need a way for the customer to get money into the system which doesn't impose the cost of fraud on you if the charge gets reversed after the goods change hands.

This could also be solved by changes to the law, but easier said than done, especially with a bunch of incumbents enjoying the larger vig from the status quo.


It was my understanding that in the current system merchants tend to eat the cost of fraud under our current system (see charge backs, rolling reserves, etc.)


> It was my understanding that in the current system merchants tend to eat the cost of fraud under our current system (see charge backs, rolling reserves, etc.)

1) A significant portion of the cost of chargebacks is administrative, especially for small transactions. The banks at least nominally attempt to prevent customers from defrauding merchants, even if they fail more often than not, because if they didn't even try it would get a lot worse fast. But that costs money, and the money it costs is proportional to the amount fraud/chargebacks and not linearly proportional to the purchase price. Having to go through the chargeback process over a nickel is not something they're about, hence the minimum transaction fees. They also sometimes lose the money because it's not possible to recover it from the merchant for some reason.

2) If you're trying to become a payment processing system with low transaction fees which people can transfer money into using their credit cards, the "merchant" who eats the cost of fraud is you.


I believe that merchants are not responsible for fraud for certain kinds of transactions, like credit card transactions that use chip-and-PIN.

On the other hand, there might be higher responsibility for card-not-present transactions (i.e. someone entering a CC number into a web form over the Internet, or merchants deciding to accept a CC transaction while their machine is down and can't swipe, entering the transaction later as a card-not-present).

Not an expert on this.

One remark I'd share is that many crypto systems, in their basic transaction form, remove all consumer protections like that exist in the form of chargebacks. This can be a good thing if the merchant or marketplace is reputable and can be trusted to do the right thing. It could be a bad thing for consumer protection broadly though. The fact that you can easily charge-back a transaction provides a sort of lubricant that makes consumers more willing to spend online. You know that if a subscription company makes it really a pain in the ass to cancel, then you have the nuclear option to fall back on.

(OTOH, there's no such thing for subscription payments for blockchain. You'd have to build that custom as far as I know.)


Isn't what you describe just cash?

If you want the convenience of it being online, here in Sweden we have something called swish, it's essentially a bank transfer initiated by via your phone number. It is free for non business transactions (I actually don't know how it works when used by a business). As far as I know bank transfers are free in most of Europe.


The phone number is the fraud prevention mechanism. In most countries you can't bulk generate a consumer phone number through an API. A Bitcoin "account" on the other hand is just a library call.


This isn't available across most of the world.

Also would this work if you try going from say, Swedish citizen/bank to German citizen/bank?


Obviously this needs buy in from the respective banks in Germany and Switzerland, but otherwise I don't see why it wouldn't work. It is really just matching accounts with phone numbers and doing a wire transfer. I know there are no fees between Sweden and France or Germany, I assume its the same for Switzerland


This is what I meant by a little more risk.

I think the potential gain in transaction fees would be worth this risk, particularly for companies which know both the customers well (e.g. already process all their transactions).

Cryptocurrencies don't address this, they simply pass the risk to the merchant instead which is far worse.


Bitcoin Lightning (and, in principle, similar netting layers) allows transactions with fees on the scale of a few satoshis (or on the scale of $0.0001) without any reason to expect they would increase very much over time. This sort of system (off-chain private netting) is kind of the only system that makes sense for substantial scaling, because

1. It allows you to forget (most of) the system's history without sacrificing the consistency of the system

2. It allows you to distribute/factor out the work of the system into lots of independent components

3. It maintains decentralization, whereas most "fast" "cryptocurrencies" actually just work by having a trusted central authority, once you peel back enough layers of obfuscation


>Bitcoin Lightning (and, in principle, similar netting layers) allows transactions with fees on the scale of a few satoshis

The lightning whitepaper also says a minimum block size of 155mb is needed to work at scale. Bitcoin currently has a 1mb block size.

I dont see lightning network being useful on a large scale until thats resolved.


> The lightning whitepaper also says a minimum block size of 155mb is needed to work at scale.

Where? I just checked and can't find it. This statement also seems nonsense in isolation - positing block size requirements involves a lot of assumptions about network topology and load.


it is in the conclusion, 133mb not 155mb, my mistake

"If all transactions using Bitcoin were conducted inside a network of micropayment channels, to enable 7 billion people to make two channels per year with unlimited transactions inside the channel, it would require 133 MB"

https://lightning.network/lightning-network-paper.pdf#sectio...


Thanks for finding that.

If everyone on earth was using lightning, I suspect most users would be using custodial lightning wallet providers (e.g. "Wallet of Satoshi" is very popular now). I doubt even 1% of people would elect to host their own node (although it's important that they be able to). 500 bytes is also a high estimate of channel opening transaction size.

The socially efficient end state I expect looks a lot like the current state of affairs (in terms of payment network topology), except A) small institutions (including individuals) have direct access to the same financial network used by large institutions if they want it, B) the financial network is trustless, C) transactions are non-repudiable. This is to be expected - there's no reason to expect Bitcoin would cause a radically different experience for the typical end user, except insofar as they will capture whatever passive benefits may be associated with saving in a hard currency. Paypal et al is already quite convenient and technically amenable to microtransactions. The benefits of Bitcoin, while substantial, mostly occur at the margins.


>I doubt even 1% of people would elect to host their own node

The block size limit was kept small in order for everyone to be able to run their own node.


Bitcoin nodes are distinct from lightning nodes. I was talking about the latter. Also I think "everyone" is a hyperbole - surely some people will prefer custodial solutions.


bitcoin maxi position is not that block size can never increase. rather, block size increase is a last resort.

so far block size increase has not been necessary. if hyperbitcoinization occurs and there is a bottleneck with lightning, block size increase is ok.

with lightning factories this may never be necessary.

if it is, it is.


IF... and I stress IF ETH 2.0's sharded blockchain system works then we'll see a 64x increase (from 64 shards) in throughput on launch with a roadmap to scale to 1000 shards.

The gist of it is you have a "multi core blockchain" that is only verified by a randomly chosen subset of validators that then sync their state back up to an oversight chain called the beacon chain.


I'm not up to date on ETH, but is this the same fabled upgrade that people have been talking about for years now? The concept sounds like it could have real potential.


Yep that's it. As of now they have a multi-client testnet running a near-final version of the beacon chain, using proof of stake. Assuming all goes well, they'll launch for real later this year.

The sharding design is integrated with that but won't actually be implemented until next year. First version of sharding will only store data; execution on shards will be after that.

The other thing going on is various layer-two systems called "rollups" which compress on-chain data to a minimum and prove its validity with either fraud proofs or a cryptographic zero-knowledge proof. Some of those are in or near production and can take today's Ethereum to about 2000 tx/sec, for simple transactions like transfers and exchanges. The data-only phase of sharding will multiply that by the number of shards.


Microtransacting is easy: someone offers to act as a microtransaction aggregator, I pay them like, $1, and they keep it and disburse funds to the things I microtransact against.

The real issue is no one cares about microtransactions because they're "micro" - and not enough to actually live off. See the artists spotify pays for plays - living that microtransaction lifestyle and making nothing.


There are 7.8 billion people in the world. If you can get 1% of them to pay you a penny once a year, you're making $780k/year. You can make $100k/year by getting $0.10/year from one person in every 7800. If you can get people to pay you $0.01/week, you can make $100k/year from less than 200,000 people.

But not if your $0.01 transaction has a $0.30 minimum transaction fee.


I’m not particularly convinced consumers want to pay with micro-transactions nor that it makes financial sense for producers. What’s the experience? Do I need to click a button to commit to paying someone $0.01/week or is it somehow automatic? Because if you can get 200k people to make the decision to pay you a penny a week I think it’s likely you could raise your price and get 50k people to pay you a dollar a week.


My issue with microtransactions is that the cost of making the decision seems like it outweighs the currency cost. Like, I used to buy computer games (e.g. from Steam) when they were on sale. Now I ignore any sale which has a price greater than $0.00, because if a game is free, I don't have to spend any time figuring out whether I will like it.

Where do you see microtransactions being applied in practice?


Everything you say makes sense, except the last line. I dont understand my the minimum transaction fee matters -- as long as you have a middle-person (such as Apple Music or Apple News), they can charge $15/mo or whatever, and do the many-to-many disbursement in bulk, right?


Bitcoin block transactions are terrible for microtransactions, since the amount of transactions that can be held are intentionally limited, which means higher fees.

Lightning network is capable of solving the issue though, as these transactions are done over a secondary layer.


>Lightning network is capable of solving the issue though, as these transactions are done over a secondary layer.

The lightning network whitepaper states a base block size of 155mb is needed for it to work at scale. Right now bitcoin has a 1mb block size limit. And as you said, this size is intentionally limited, so i doubt we'll ever see lightning network work at scale.


BTC fees are currently ~$2.50 (11PM EST 4/30/20)[1]

[1] https://twitter.com/CoinFees/status/1256045351024418821


Once cryptocurrencies gain any traction as currencies, expect Visa and Mastercard to either lower that fee or remind you about that time you had to issue a chargeback.


Credit card pricing is not a fixed thing. PayPal, for instance, offers 5% + $0.05 microtransaction pricing. Surely that also works as a solution


The microtransaction element doesn't require crypto.

This can be seen by the 0 fees on network on Alipay and WeChat Pay which don't use crypto and transact more volume now than Visa and Mastercard seamlessly.

With the rollout of DCEP why use the others?


I have been using Lightning network (second layer network that runs on Bitcoin) for over a year and it works great. Extremely low fee near instant transactions. Really a game changer for Bitcoin.


There isn't an inherent cost to that fee. Whatever crypto does central processors can do cheaper.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: