Live data from Hacker News

Some ideas for native Bitcoin apps

cdixon.org

41–50 of 82 posts

Re: Some ideas for native Bitcoin apps

#41

Interesting to see VCs like Chris Dixon desperately pumping Bitcoin in a last ditch effort to wipe the egg off their faces.

If you're referring to the recent price drop - you should learn about what causes price fluctuation in Bitcoin. It's actually largely due to the fact that Bitcoin is actually rapidly becoming USED rather than HELD which causes downward pressure on it. This causes miners to become un-profitable btw which will eventually cause upward pressure on the price (but that problem is worrying as it's getting really expensive t…

:-) Well said. I read this after I posted elsewhere on this thread about how the price drop is caused by adoption so in fact we are buying _utility_ with the value that we lost. Once we've bought enough utility the price trend will likely reverse.

I do own bitcoin, and I buy lots of stuff with it all the time. I can't recommend it enough.

Re: Some ideas for native Bitcoin apps

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

See http://e-drexler.com/d/09/00/AgoricsPapers/agoricpapers.html for more in that line. Also http://www.cap-lore.com/Economics/DSR/ and http://www.whatisthought.com/eric.html under "artificial economies of agents that reinforcement learn".

Re: Some ideas for native Bitcoin apps

#43
I think there is huge opportunity in decentralising existing business models that are well suitable for p2p.

Think of Uber / AirBNB / etc with no fees and no government power over them.

Another huge opportunity in distributing revenue of these services to peers running the network. This may cause rapid growth & unparalleled fault tolerance.

Third thing that might be disrupting is ability of such services to issue their own coins/stocks, which price is linked to service's revenue. Revenue is then distributed among stock owners, and service can issue such stocks at will without government's approval.

Re: Some ideas for native Bitcoin apps

#44
post #40

Earlier quoted context omitted.

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 getting ridiculous. So much patchwork and overcomplications show how unfit for the real world Bitcoin is. Just drop Bitcoin for Stellar and problem solved. But, wait, all that vested interest and money in Bitcoin keeps people stick to Bitcoin and reject anything else.

Patchwork??! This uses the original scripting implementation that Satoshi built. It's just one of many possible applications of it.

New applications are exactly why a (non-Turing complete) scripting language was included in the protocol -- so people could extend the Bitcoin to new areas.

You may not like Bitcoin, but calling the use of a feature that was built by the original developer to support one of the earliest aspired uses of Bitcoin "patchwork" is pretty unfounded.

And regarding Stellar, I'm a big fan of the Ripple technology, but very cautious about the entities behind both Ripple and Stellar. Just like Stellar, Ripple started out with promises of distributing the vast majority of the coins around the world, and yet 2-3 years out this still hasn't happened. The fact is -- unlike Bitcoin's -- Stellar's and Ripple's distribution model is highly centralized and thus potentially undependable.

Re: Some ideas for native Bitcoin apps

#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 every transaction ever. I'm confident that as soon as the need arises, this limit will be increased.

> and every node has a full copy of the block chain, so traffic goes up roughly as the square of usage.

That's not true, traffic goes up linearly with the number of transactions. If there are twice as many transactions, twice as much data needs to be sent around in the network. It is also linear in the number of full nodes running - but most users do not run a full node.

> 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.

Wrong again. At the moment, the recommended minimum fee is 0.03 USD, or 0 for high-priority transactions (those who move large amounts or old coins). It used to be 0.001 BTC, but that was reduced to 0.0001 BTC. Also, most merchants have to pay much more than 0.30 USD to process credit card payments.

> Nor can Bitcoin handle fast payments.

Firstly, when looking at throughput (how many times can the same Bitcoin be spent per day), Bitcoin beats all existing payment systems by a wide margin. Even with SEPA, which is praised to be very fast, you can resend the same euro to a new account at most once per business-day or about 20 times per month. A Bitcoin, however, can be moved thousands of times per day (assuming movements between trusted parties) or dozens of times per day between untrusted parties. So regarding throughput, Bitcoin is the clear winner.

Secondly, there is the time it takes until the money arrives with certainty. For credit card transactions, that time is 60 days. For bank transfers, settlement is T+2 days. That means if you send 100 USD from a Lehman brothers account to a BofA account on Monday, and Lehman goes bankrupt on Wednesday, you won't receive anything. With Bitcoin, it takes about an hour to reach that level of certainty.

The problem you are referring to is that by colluding with a miner, someone could issue a competing second transaction that invalidates the first. Fortunately, such attacks require effort and are perfectly detectable. So if not much is at stake, one can accept a transaction as soon as it has spread to the relevant miners. For example, when you order a coffee in a restaurant, it is much easier to simply walk out without paying than to try to launch such an attack.

> Meanwhile, Bitcoin for vending machines, music tracks, and parking meters isn't going to happen.

Exactly for those applications, it is safe enough. None of them is 100% safe anyway: vending machines can be fed with fake coins, music tracks can be pirated, and parking meters can be ignored (betting that the police won't check them). In all those cases the effort to cheat with traditional means is smaller than that of colluding with a majority of miners (and you need a majority for a reasonable rate of success).

Re: Some ideas for native Bitcoin apps

#46
post #32
post #24

Earlier quoted context omitted.

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 mul…

That does not increase the number of independent transactions that can take place. You can't have multiple recipients: "this does not allow you to send micropayments at high speed to different recipients" And you can't have multiple senders. You just get to do incremental transfers. In the end bitcoin needs to handle around 1,000 independent transactions a second to see widespread adoption and even 100,000 transactio…

An example of a company working on this issue is monetas.net, which has announced launch for December. Their solution is based on OpenTransactions, which adds a layer on top of Bitcoin (or any other payment system) that allows to perform much smaller and cheaper transactions.

Re: Some ideas for native Bitcoin apps

#47
Out of these 4 categories, marketplaces is the one that I think has the most potential for a breakaway change.

Micro-payments, micro-incentives and any kind of a scaling down of transactions is something I'm not exactly sure about. Maybe there's some cool stuff here, but I would be surprised.

Marketplaces though are a different story. Marketplaces have been developing into giants since the internet began and the financial infrastructure for running them is terrible.

Ecommerce, native or not, will also be impacted. Anti-fraud & payment verification colour the world of ecommerce enough. Solving friendly fraud (mostly chargebacks) could enable a lot of otherwise transactions and serve underserved markets (EG shipping goods to high risk countries like most of Africa).

ATM though BTC is still in a shaky place. Even bitcoin owners don't use it much. Most people don't have bitcoin wallets so unless a service is important enough to make people use it, BTC cannot be the only option.

Marketplaces are the kind of thing where users can be forced to use the payment method available. EG, if Uber paid driver in BTC, drivers would accept BTC.

Re: Some ideas for native Bitcoin apps

#48
> Incentivized social software. Up until now, social sites have had to rely on non-monetary currencies such as likes, followers, karma, upvotes, etc. With Bitcoin we can add actual monetary incentives to the mix. This is happening organically on Reddit where users are tipping each other using Bitcoin and Dogecoin.

Incidentally, this is a pretty bad idea, because of how the way people think about things changes when money gets involved. Someone said it well in a recent thread, so I'll defer to them -

https://news.ycombinator.com/item?id=8392883

(AFAIK, most Reddit tips are only for a few cents, so the only real value is the acknowledgement that someone appreciated your post enough to tip you. This sidesteps the issue, but means that it isn't a good reflection of what would happen if you tried to make a real incentivized social network.)

Re: Some ideas for native Bitcoin apps

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

You don't need a new protocol, you could do this by putting stuff in smtp headers and validating it with a mail filter.

Re: Some ideas for native Bitcoin apps

#50

Interesting to see VCs like Chris Dixon desperately pumping Bitcoin in a last ditch effort to wipe the egg off their faces.

If you're referring to the recent price drop - you should learn about what causes price fluctuation in Bitcoin. It's actually largely due to the fact that Bitcoin is actually rapidly becoming USED rather than HELD which causes downward pressure on it. This causes miners to become un-profitable btw which will eventually cause upward pressure on the price (but that problem is worrying as it's getting really expensive t…

Why would unprofitable mining cause a upward pressure on price? There is a fixed amount of bitcoin distributed per day cumulatively to all miners regardless of their number.

I doubt the recent price drop is due to people buying and selling in bitcoin since it's way too steep a decline.

I'm guessing that most miners themselves also happen to be investors as well. After all, if you believe in bitcoin enough to purchase equipment to mine it, you must also believe that the price will at least stay constant or rise. So it seems natural to keep some of your profits in bitcoin.

So people mining and investing together are heavily dependent on price, more than those doing one or the other. With the constant slow decline, it left a lot of miners languishing, and they not only need to convert all their current profits to their local currency to pay the bills, but their bitcoin investments as well. This creates a feedback loop and an ever increasing rate of price decline until enough miners run out of bitcoin to sell and/or close up shop.

Post reply on HN