Live data from Hacker News

Some ideas for native Bitcoin apps

cdixon.org

51–60 of 82 posts

Re: Some ideas for native Bitcoin apps

#51
post #17

Bitcoin can't handle micropayments. The block chain is limited to about 7 transactions per second, and every node has a full copy of the block chain, so traffic goes up roughly as the square of usage. There's a minimum fee for each transaction (if you want it confirmed in any reasonable length of time) and it's currently about $0.30. That's more than many merchants pay to process a credit card transaction. Nor can Bi…

Your statement that Bitcoin cannot handle micropayments is absolutely incorrect. Are you familiar with payment microchannels? With microchannels, Bitcoin solves the micropayment problem like it solves other, related problems: with simple p2p network tech combined with cryptography. In short, Mike Hearn and others figured out how to exploit Bitcoin's native scripting capabilities to support microtransactions. They cal…

This is just one of many competing "techniques" for bitcoin microtransactions.

As it stands now there is no universal standard, which is needed before you can say bitcoin is ready for microtransactions. It's a market issue, not a technical one.

Re: Some ideas for native Bitcoin apps

#52
post #17

Bitcoin can't handle micropayments. The block chain is limited to about 7 transactions per second, and every node has a full copy of the block chain, so traffic goes up roughly as the square of usage. There's a minimum fee for each transaction (if you want it confirmed in any reasonable length of time) and it's currently about $0.30. That's more than many merchants pay to process a credit card transaction. Nor can Bi…

Your statement that Bitcoin cannot handle micropayments is absolutely incorrect. Are you familiar with payment microchannels? With microchannels, Bitcoin solves the micropayment problem like it solves other, related problems: with simple p2p network tech combined with cryptography. In short, Mike Hearn and others figured out how to exploit Bitcoin's native scripting capabilities to support microtransactions. They cal…

Micropayment channels don't offer the flexibility of plain micropayments. Sure I can get $0.0001 from you a certain number of times, but I have to wait until I have a certain amount paid for it to worth it for me to make a transaction.

Micropayments that aren't channels will be possible when fees are lower.

Re: Some ideas for native Bitcoin apps

#53
post #17

Bitcoin can't handle micropayments. The block chain is limited to about 7 transactions per second, and every node has a full copy of the block chain, so traffic goes up roughly as the square of usage. There's a minimum fee for each transaction (if you want it confirmed in any reasonable length of time) and it's currently about $0.30. That's more than many merchants pay to process a credit card transaction. Nor can Bi…

It's like you went out of your way and collected every incorrect piece of knowledge about bitcoin.

> Bitcoin can't handle micropayments

It already does.

> The block chain is limited to about 7 transactions per second

No, it doesn't. That limitation is completely artificial and can be removed at any time. The core developers are working on scaling the system to 1000+ tps.

> and it's currently about $0.30. That's more than many merchants pay to process a credit card transaction.

No, it isn't more. And it's $0.03, not $0.30. Have you looked at the actual credit card fees? They consist of a percentage + fixed fee per transaction + fixed monthly fee.

http://credit-card-processing.findthebest.com/

> Nor can Bitcoin handle fast payments. It takes about an hour to get solid confirmation of a transaction

The transaction takes a few seconds. One confirmation takes around 8-9 minutes on average (we always mine faster than the 10 minute goal).

Compare it to a bank - transaction takes days, confirmation takes 6+ months.

Compare it to a credit card - transaction takes a few seconds, confirmation takes 180 days.

> * you're selling anything that actually costs you money, you have to wait for some confirmations*

Same with credit cards and bank transfers. Except these kinds of payments can be reversed for 6+ months, and it's a big headache for the merchants and stores.

Re: Some ideas for native Bitcoin apps

#54
post #14

Micro-gambling Peer-2-peer gambling Webcams The real wonder is why haven't any of the major players in these areas adopted it in any way. Curiously it is the payment provider industry who has paid it some attention, rather than any of these. Perhaps the traceable nature of bitcoin makes it unappealing for these use cases. In the early days of bitcoin where it was relatively easy to get anonymous bitcoins (by paying c…

I'm always wary of email/spam solutions that require 'payment' of some form. See https://craphound.com/spamsolutions.txt for a lot of reasons (in particular, Unpopularity of weird new taxes, Public reluctance to accept weird new forms of money, Ideas similar to yours are easy to come up with, yet none have ever been shown practical, Countermeasures must work if phased in gradually, Sending email should be free)

I agree, and is partly why I think it would never take off.

But it wouldn't need to be seen as a "tax" if the money went to the recipient of the email, and any prices were set by those recipients.

Re: Some ideas for native Bitcoin apps

#55
post #17

Bitcoin can't handle micropayments. The block chain is limited to about 7 transactions per second, and every node has a full copy of the block chain, so traffic goes up roughly as the square of usage. There's a minimum fee for each transaction (if you want it confirmed in any reasonable length of time) and it's currently about $0.30. That's more than many merchants pay to process a credit card transaction. Nor can Bi…

Bitcoin's blockchain can't handle micropayments, but blockchain is ideal for insurance deposits making micropayments as a separate protocol "economically" secure (no one wants to lose their deposit).

Two use cases:

1. Micropayment channels. When you pay to a single party in frequent small chunks, you can create a transaction that locks up certain amount upfront and than you simply re-sign that transaction moving more coins to the recipient and less back to you ("change"). Recipient does not publish transaction until the session is done. If you disconnect or they decide to stop providing you with a service, they simply release a transaction with the latest balance of payment and change.

2. Micropayment channel is not always relevant. E.g. you want to make a one-time small payment. E.g. buy a drink in a cafe for $2. We can imagine another micropayment protocol similar to Ripple where IOUs are transferred, but unlike Ripple, each IOU is ensured by at least twice the amount of real bitcoins locked up in 2-of-2 multisig transaction by each pair of nodes that exchange IOUs. In other words, it's a Visa-like clearing house, but it's decentralized (mesh-like) and every penny of debt is fully insured by real bitcoins being held hostage in "joint escrow" transaction (2-of-2 multisig).

Re: Some ideas for native Bitcoin apps

#57
post #17

Bitcoin can't handle micropayments. The block chain is limited to about 7 transactions per second, and every node has a full copy of the block chain, so traffic goes up roughly as the square of usage. There's a minimum fee for each transaction (if you want it confirmed in any reasonable length of time) and it's currently about $0.30. That's more than many merchants pay to process a credit card transaction. Nor can Bi…

These things are solved in other cryptocurrencies like Ethereum. You can also take a look at "25-second irreversible confirmations for instant payments" [1].

[1] http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval...

Re: Some ideas for native Bitcoin apps

#58
post #14

Micro-gambling Peer-2-peer gambling Webcams The real wonder is why haven't any of the major players in these areas adopted it in any way. Curiously it is the payment provider industry who has paid it some attention, rather than any of these. Perhaps the traceable nature of bitcoin makes it unappealing for these use cases. In the early days of bitcoin where it was relatively easy to get anonymous bitcoins (by paying c…

> Micro-gambling Peer-2-peer gambling Webcams

What does that mean?

Re: Some ideas for native Bitcoin apps

#59
post #7

> 2. Allocating bandwidth, storage, compute. Before Bitcoin was a thing, I was thinking about the Erlang VM's "reduction-counting" processing paradigm, and noticed that it was a lot like having a dom0-scheduler "treasury" with domU-process "citizens", where each citizen gets paid a basic income every scheduling interval, and then can spend it to "purchase" time-spent-aware on a virtual core. In Erlang's model, proces…

Cool idea, the only problem I can see is how you define a reduction. In the Erlang VM a reduction is kind of a magical unit... and not a reductions are created equal.

Re: Some ideas for native Bitcoin apps

#60
post #45
post #17

Bitcoin can't handle micropayments. The block chain is limited to about 7 transactions per second, and every node has a full copy of the block chain, so traffic goes up roughly as the square of usage. There's a minimum fee for each transaction (if you want it confirmed in any reasonable length of time) and it's currently about $0.30. That's more than many merchants pay to process a credit card transaction. Nor can Bi…

Allow me to correct a few of your misconceptions: > Bitcoin can't handle micropayments. The block chain is limited to about 7 transactions per second, Note that this is not a technical limit, it is an arbitrarily set parameter. Gavin argues it could be increased at least 1000-fold with more professional infrastructure over time. Even with a tenfold increase, an average PC with mediocre broadband could still process e…

Even retail bank transfers in most of the world are same day. And wholesale ones in the financially backward US are same day not t+2
Post reply on HN