Micro-transactions: A proposed implementation

[timthelion]

Dear Bitcoin community,
forgive me if I seem to be jumping into things I don't know about.  I am not a member of your community, but I am very interested in the theory of crypt-currencies.  My message is related to the problem of the purported 7 transaction per second limit to the bitcoin network.  From my understanding, transactions are quite large, around 1k, and my assumption that a majority of this space comes from the signing of the transaction.  In this case, the size of a message does not correlate directly to the actual data transferred, but rather has a large upfront cost.  If this assumption is not correct, than I guess you can stop reading now.
  I have seen several possible solutions to the low number of transactions per limit problem:

  - increase the block size limit
  - make a new cryptocurrency that is trade-able with bitcoin/backed by bitcoin.
 - Allow more complex transactions, so that a single transaction can have more than one recipient.
 - Have an authority, such as MtGox, provide for a micro-payment system.
 - Use a low security voucher system.

 The first option is clearly necessary, yet it does not solve our problem.  Increasing the block size by a factor of 100 does not allow for micro-transactions.  We need to multiply the number of transactions by at least 1000.
 The second option has never been explained satisfactorily to me.
 The third option would require one to wait some time, before a "build up" of small transactions had come about before sending them out in batch.  Most services requiring micro-payments do not work well with a model that would enforce such a delay.
 The last two options are not really options at all.  We already have an authority for micro-payments.  It's named paymal or emuney/ebunny? or something like that(sorry, not an expert in trademarks here), and it has not been satisfactory(I understand dislike authority is a major reason to replace these services).  The voucher system is very insecure.

 Or is it?  I have created a cleaver way to prevent double spending of bitcoin vouchers.

I propose creating four new transaction types on the bitcoin network.  These would be the "create vouchers" transaction.  A wallet would send create vouchers along with a list of a thousand or so keys. This list of keys would become a new "voucher group".  Each voucher would be worth(and subsequently cost the wallet) about 1(or 10) Satoshi.

Each voucher key would be a key pair.  The first key is a public key, and the second key is a private "voucher redemption key".

The second new transaction type I need is the "redeem vouchers" transaction.  It includes an encrypted list of several thousand redemption keys to the bitcoin network as well as an unencrypted list of the public keys being redeemed.  This transaction would come with a fee, but itself would have no affect.

The third new transaction type I need is the destroy vouchers transaction.  It includes an unencrypted list of unspent voucher redemption keys to be destroyed.

The fourth is the "decrypt redemption key list, and perform redemption." This transaction would be sent AFTER the encrypted redeem vouchers transaction has been incorporated into the block chain. This would provide a key that would allow the second type to be decrypted. It would also perform the redemption, by transferring funds to the wallet which initialized the redemption transaction.

The wallet which creates the voucher group, can now spend these vouchers by sending merchants the private voucher redemption key, and a special signed message saying "voucher X has been given to merchant Y".
The merchant would then use a voucher redemption transaction, once a month or so to redeem all his vouchers.

It should be obvious, that no merchant wants to receive a bitcoin voucher that has been given to another merchant.  And no merchant, wants a second merchant to accept a voucher which it would like to redeem itself.  This would encourage the merchants to share, in a separate from bitcoin network, a list of who had received which vouchers.  They would do this, by sending the second part of the voucher payment out to this new merchant network, that is the  message I mentioned earlier which is signed by voucher group creator and says "voucher X has been given to merchant Y".  This would prevent merchants from accepting vouchers which were being double spent within their own community.  But what if the voucher group creator wanted to redeem his own vouchers.  He of course has the redemption keys, since he created the voucher group.  If a person tries to redeem a voucher which a merchant has already received, the merchant has recourse.  Before the redemption is completed, he can send out the "destroy vouchers" transaction.  The merchant doesn't get anything out of this, but neither does the client.  This should prevent double spending, since it would be idiotic, like burning money.

Each voucher key would be much smaller than a standard bitcoin transaction.  To create a secure public/private key pair, 128 bits should suffice.  There is no profit in breaking the algorithm.  Even if you do find the redemption key, you will not be able to redeem the voucher, as the voucher holder would simply destroy it. Such a small key size should allow us to create and redeem many vouchers for the cost of a single standard bitcoin transaction, and thus would hopefully lead to the possibility of micro-transactions.

One last note.  Some might rightfully relate the destruction of vouchers to the hated chargeback system.  Indeed, they are somewhat similar in their features. However, the chargeback system can be abused for monetary gain, whereas voucher destruction is solely a means of punishing a merchant you don't like, without any personal gain.  Indeed, it would likely lead to personal loss, because any smart merchants that sees that a lot of vouchers from a given voucher group are being destroyed, will stop accepting vouchers from that voucher group. Thus voucher groups may gain a notoriety or "low credit rating" which forces the holder to redeem those vouchers himself(at the cost of the creation and redemption fees.)

What do you all think?

Timothy

[fluffypony]

I believe the general consensus (albeit very general) is that LTC is more suited to micro-transactions.

[timthelion]

Litecoin provides faster payment confirmation times, but no improvement in network bandwidth efficiency.  My voucher system does, however, improve the efficiency of network bandwidth use.

Furthermore, there is no integrated way to change bitcoins into litecoins and back again.  This requires an exchange, and thus the unnecessary trust of a third party.

My statement that "- make a new cryptocurrency that is trade-able with bitcoin/backed by bitcoin." had not been sufficiently well explained to me was not to say that I don't know that litecoin exists.  I am just saying, that based on their website, there is no reason to believe that they solve the problem.d

[FreddyFender]

It appears to be a Bitcoin independent protocol. Are you at or near Whitepaper stage?

[timthelion]

It is unfortunate, that I did not find a way to make this integrate with the bitcoin protocol without changes.  I do not plan to pursue this line of thought any farther than this forum post.  I just wanted to get the idea out there, though if my post is unclear, I will happily try to clarify, if my idea is flawed, I'd love to learn from my mistake, and if this is the wrong place to discuss such ideas I might post elsewhere.

[timthelion]

It seems to me, that it would actually be useful to make each voucher-group have a settable voucher value, instead of having them all equal 1 satoshi.  This would increase their efficiency significantly, and cost only a few bytes per voucher group creation transaction.