Author

Topic: Bitcoin and Microtransactions (Read 454 times)

newbie
Activity: 14
Merit: 0
April 04, 2013, 09:13:38 PM
#1
It's been said by respected developers, in threads regarding the current minimum transaction fee, that bitcoin isn't really suitable for microtransactions - partly in order to protect against spam attacks, and partly simply to reduce network load, they want to discourage low-value transactions.  I think this is a great shame as it's often touted as one of bitcoin's benefits, clearly wrongly so.

I've also seen suggestions of using some other system, such as vouchers, for small transactions, but that is complicated and distasteful.

Given the existing use of keys and signatures, though, it made me wonder whether we can just bypass the network for microtransactions, where the value is low enough that security is not a big deal.  We already have the means, in our clients, to generate the signed transactions, but instead of sending the transaction to random peers and watching it fail to spread across the network due to lack of a transaction fee, we can send it straight to the recipient, and let them do the broadcasting if/when they desire with whatever fee they choose to add.

This way, a merchant who accepts microtransactions can batch them together and pay a single fee for the batch, defragmenting the balance from several senders into a single target address.

It feels appealing because we already have the means to trust signed transactions - the only insecurity is the possibility of double-spending.  If a merchant is willing to accept that risk for tiny transactions then maybe this is viable, without resorting to other forms of currency.

I guess the missing piece may be for the merchant to be able to merge the previously-signed transactions into one larger transaction that's more economical for the network, and worth paying a fee for.  But I've read proposals to let a high priority transaction's priority level filter back to any lower-priority dependency transactions, so if that is, or will be, implemented into the relaying code, it would allow these consolidation transactions to naturally work on top of the microtransactions, even if they themselves are feeless and low-priority.

I'm sure this must have been discussed before, as it's a fairly obvious system - I'd be glad to see links if anybody has any.
Jump to: