Some ideas for native Bitcoin apps • Hacker News Board

Re: Some ideas for native Bitcoin apps

#61

Post by eric_bullington » Sun, Oct 05, 2014, 2:31 PM UTC

bduerst wrote: post #51

eric_bullington wrote: post #26

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

What other techniques are there? I'm interested.

Re: Some ideas for native Bitcoin apps

#62

Post by gregpilling » Sun, Oct 05, 2014, 2:54 PM UTC

comex wrote: post #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 m…

Club Med used to solve the problem with beads. Vacationers would use beads to buy beer or whatever while there. At the end of the stay they add up the beads that you used and give you a bill. It is pretty effective at making you not think it is money.

My bill was over $600 for 2 weeks :(

Re: Some ideas for native Bitcoin apps

#63

Post by JoeAltmaier » Sun, Oct 05, 2014, 2:59 PM UTC

gregpilling wrote: post #62

comex wrote: post #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 m…

Club Med used to solve the problem with beads. Vacationers would use beads to buy beer or whatever while there. At the end of the stay they add up the beads that you used and give you a bill. It is pretty effective at making you not think it is money. My bill was over $600 for 2 weeks :(

You know that going in. As a way to quit obsessing about the money and just enjoy yourself, it worked quite well.

Re: Some ideas for native Bitcoin apps

#64

Post by kordless » Sun, Oct 05, 2014, 3:13 PM UTC

Animats wrote: 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 can't handle micropayments

That is an inaccurate statement. Technically speaking, sending small amounts of Bitcoin from one source address to one or more destination addresses in separate transactions are inefficient, given the default size of the transaction(s) and the cost of processing. Depending on your use cases, there are solutions to this apparent limitation.

To handle one-to-one micropayments, Bitcoin microtransactions can be done in a trustworthy manner by using rapidly adjusted payments between parties[1]. Basically, funds are held in escrow and the amount owed is adjusted in a variable off-chain transaction until either a) the funds are exhausted, b) the parties decide they are done, or c) a timer expires.

Second, Bitcoin allows for making one-to-many payments in a single transaction[2]. You could send sub pennies (US$) amount of value to 1,000s of addresses in a single transaction. The cost of the transaction goes up as the size of the transaction goes up (more addresses == bigger transaction), but it remains a very economical way to send very small amounts to lots of addresses.

I'm using the latter of the two methods to send coin to virtual appliances controlling OpenStack cluster based instances, which would have an analogy of feeding parking meters in the physical world. You need to trust the payment party (entity paying for all the instances/parking spots in a single transaction), so the plan is to make the payment mechanism distributed by deploying multiple payment nodes onto the network. Payment nodes deposit pennies into instances/parking meters periodically from wallets they create and control themselves. If someone hacks a single payment node's guest machine, and steals its private key, they'd only score a few bucks. Not worth the time or effort of hacking the hypervisor, in theory.

An interesting side note here, payment nodes could also be aware of their own Bitcoin instance payment address, effectively allowing them to use a wallet they are carrying to pay for their own existence.

[1] https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adju...

[2] https://bitcoin.org/en/developer-guide#block-chain

Re: Some ideas for native Bitcoin apps

#65

Post by kordless » Sun, Oct 05, 2014, 3:29 PM UTC

Retric wrote: post #32

mappum wrote: 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…

Multiple recipients are already a feature of the blockchain (one input multiple outputs) and you can make each of those payments as small as you like, just so long as the rolled up transaction is over a given amount.

BTW, this does not require the rapidly adjusted transaction technique.

Re: Some ideas for native Bitcoin apps

#66

Post by derefr » Sun, Oct 05, 2014, 3:46 PM UTC

lpgauth wrote: post #59

derefr wrote: 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.

I think the definition of a reduction (in terms of what it buys) is allowed to be pretty much arbitrary while still having an effective distributed economy emerge on top of it. Think of it as a communist state that both issues currency, and sets arbitrary prices for all state-produced goods in terms of that currency. In one state, a loaf of bread (or a multiplication) might be worth $1, and a hamburger (or a network message send) $5; in another state, the costs might be reversed. This would shake out as

1. exchange rate nash-equilibria between dom0s, determined by their "monetary policies";

and 2. spawning of subagents on dom0s with better cost-structures for the particular tasks they're assigned to accomplish. (If you're doing a lot of network IO, you'd want to delegate that part of your job to a place where network IO—after currency-conversion—is cheap.)

Re: Some ideas for native Bitcoin apps

#67

Post by obi-nine » Sun, Oct 05, 2014, 4:03 PM UTC

eterm wrote: 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…

Stopping (or greatly reducing) mail spam was the original intended solution for the Proof Of Work solution that now guards the Bitcoin blockchain.

See: https://en.wikipedia.org/wiki/Proof-of-work_system

Re: Some ideas for native Bitcoin apps

#68

Post by the_mitsuhiko » Sun, Oct 05, 2014, 4:14 PM UTC

Hermel wrote: post #45

Animats wrote: 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…

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

How does that make sense in a peer to peer environment?

Re: Some ideas for native Bitcoin apps

#69

Post by kolev » Sun, Oct 05, 2014, 4:43 PM UTC

eric_bullington wrote: post #44

kolev wrote: post #40

Earlier quoted context omitted.

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…

It's patchwork as doing all this is not intuitive, it needs to be explained, spec'd out, needs examples and requires a learning curve. I'm fine with the entities behind Stellar and totally not fine with the shady, questionable, and faceless ones behind Bitcoin! The only character I cared about within Ripple is now with Stellar - Jed McCaleb. Last thing - the distribution is not Ripple's fault, it's the uselessness of cryptos for the 99% of the population, which is leading the imminent crash and burn across the board!

Re: Some ideas for native Bitcoin apps

#70

Post by [deleted] » Sun, Oct 05, 2014, 5:29 PM UTC

kordless wrote: post #65

Retric wrote: post #32

Earlier quoted context omitted.

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…

Multiple recipients are already a feature of the blockchain (one input multiple outputs) and you can make each of those payments as small as you like, just so long as the rolled up transaction is over a given amount. BTW, this does not require the rapidly adjusted transaction technique.

[deleted]