Live data from Hacker News

Some ideas for native Bitcoin apps

cdixon.org

21–30 of 82 posts

Re: Some ideas for native Bitcoin apps

#22
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…

Chaum ecash is one way to solve it. You'd use chaum ecash tokens backed by bitcoin by an issuer. You would then use the tokens, since they are instant, have no transaction cost and can be anonymous. The ecash tokens themselves require a central issuer that is trustable to avoid double spending, which is it's central issue with it. To side step the trust issue, the issuers would be a large multi sig bitcoin pool. The two technologies compliment each other. Bitcoin creates a purely virtual good that has scarcity and solves the trust issue. Chaum ecash solves the cost, speed and anonymity issue for bitcoin.

Bitcoin will become something like the international wire transfer mechanism.

One implementation of chaum ecash is open-transactions, i suggest you check it out: http://opentransactions.org

Re: Some ideas for native Bitcoin apps

#24
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…

Actually, Bitcoin can handle micropayments extremely well by using micropayment channels.

https://bitcoinj.github.io/working-with-micropayments

In short, the payer sends a signed transaction to the payee every time they want to increment the payment, but the payer does not broadcast the transaction to the network until they want to finalize it. To prevent double-spending, the payer and payee first set up a 2-of-2 multisig, so all transactions must be signed by both parties.

This lets applications send many instant micropayments, and only one transaction fee is paid.

Re: Some ideas for native Bitcoin apps

#25
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)

It also makes it suddenly expensive to run a decent sized email list. For security announcements, say.

Re: Some ideas for native Bitcoin apps

#26
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 call it microchannels, and there's a very succinct explanation here if you're familiar with Bitcoin scripting: http://www.slideshare.net/JohannBarbie/bitcoin-micropayment-...

There's even a working implementation: part of Mike Hearn's BitcoinJ, the second oldest Bitcoin implementation.

Now, you could argue that there's so far no big demand for Bitcoin microtransactions, and I'd have to agree. But to say bitcoin is not capable of them is simply false.

Edit: Also, your per tx fee is too high by at least 10x. In fact, many transactions can be sent at absolutely no charge.

Re: Some ideas for native Bitcoin apps

#27
post #3

Also see OpenBazaar, a peer-to-peer marketplace: https://openbazaar.org This is a rapidly developing example of an application that couldn't exist without Bitcoin.

That seems pretty promising. I'm wondering if this project might try going into currency as the landscape evolves, As i think it would be great to see centralized exchanges made irrelevant and the network more resilient, though i suspect it might be a bit harder to solve than physical goods.

Re: Some ideas for native Bitcoin apps

#28
post #25

Earlier quoted context omitted.

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)

It also makes it suddenly expensive to run a decent sized email list. For security announcements, say.

No, the idea is that users would be able to set an incoming fee per email address, including a default fee for unknowns. Users would simply whitelist email subscriptions at 0 fee. In fact, this could likely be done completely automatically beyond the initial setup (and then only if you want to diverse from the defaults).

Re: Some ideas for native Bitcoin apps

#29
This list is pretty good but I suspect infrastructure work is far from done. Also Marketplaces aren't quite native by this definition-- cdixon is more so pointing out that their reaches can be expanded to the unbanked. I think the real magic of Bitcoin lies in the Blockchain itself and its application to the real world via smart contracts. The fact that bitcoin is a currency might turn out to have been a big distraction or just a side effect of the real applications. If this is true it further points to the need for ubiquitous infrastructure.

Re: Some ideas for native Bitcoin apps

#30
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)

It's convenient sometimes that sending email is free, but remember the fascinating read about the gmail anti-spam measures, and how they require central knowledge?

I'd bet you can satisfy 99.9% of my antispam needs with 2 rules:

1 - if I've ever sent an email to your address and haven't blacklisted you, you get to my inbox

2 - everyone else, pay 2-3 cents

Note that mailing lists, via an email opt-in, would pass under rule 1. As for everyone else, if emailing addresses that have never conversed with you isn't worth a couple pennies, rethink sending the email.

Post reply on HN