Bitcoin Forum
June 16, 2019, 08:05:08 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
   Home   Help Search Login Register More  
Pages: [1]
Author Topic: "Gift Card" style merchant credit with instant transaction.  (Read 566 times)
Offline Offline

Activity: 3
Merit: 0

View Profile
February 04, 2013, 02:44:36 AM

I got whitelisted and was asked to repost this here (t.y. johnthedog)

I've been reading up on BitCoin and the crypto behind it, and I think I have a way of providing instant transactions, provided you establish a credit with a merchant beforehand. This credit cannot be spent by either party until the other consents.


This proposal is based on the AcceptBit scheme. I'm not a crypto guy, so I might be completely misunderstanding how the AcceptBit crypto works. What I'm proposing here is a method of creating a credit with a merchant, such that:

1: A transaction from credit to merchant can be completed immediately by computers (important for physical transactions)
2: Neither the merchant nor customer need to trust one another. (though either party can freeze the credit)

This method is based on the scheme that AcceptBit uses to create multiple addresses spendable with a single "root" private key. Aside from some basic knowledge of ECDSA, my knowledge of this scheme is limited to the information presented at . So if I'm misunderstanding something, I would appreciate a more knowledgeable person correcting me.

Establishing Credit:

1: The client notifies the merchant that she would like to create a credit.
2: The merchant generates an ECDSA root private key (R) and gives the client the corresponding public key (R'), and a denomination unit (u). (e.g. the BTC equivalent of the smallest denomination the store usually accepts in its primary currency. In the U.S., it might be equivalent to 0.01 USD)
3: The client generates log2(c) ECDSA private keys (K1-Kn), where c is the credit she would like to have with the merchant, which she then uses, along with R' to create n new bitcoin addresses (A1-An).
4: The client sends u*2^(n-1) BTC to each of A1-An.
5: The client sends each address to the merchant.
6: Once the transactions of step 4 are confirmed, the credit is established.

While waiting for her computer/smartphone to complete step 6, the client might drive to the merchant's physical store, shop around, etc.

At this point, neither party can spend the balance in the addresses.

To spend the credit, the client simply gives the merchant the keys corresponding to the addresses which sum to the amount she wants to spend. For example, if the following addresses were created...:

A1: 1 BTC
A2: 2 BTC
A3: 4 BTC
A4: 8 BTC

... and the client wants to spend 5 BTC, then she gives the merchant K1, A1, K3, and A3. The merchant can verify the transaction by generating the public addresses, proving that the merchant now controls the 5 total BTC contained in those accounts.

It is probably good practice that the merchant refund the remaining amount by giving the client R. (Though this can be implementation-specific)

Also note that as described here, this method forces the amount of credit created to be 1 less than a power of two units, but this restriction can easily be circumvented by creating multiple sets of these which sum to the desired amount. (e.g. 80 = 63 + 15 + 1 + 1)

The only weaknesses to this I can fathom (barring social engineering) is that the merchant can suspend the credit indefinitely (forcing you to either spend the money, or to lose it completely), and that all credit is lost if the merchant loses or accidentally disseminates R (e.g. get's hacked).

Guess The Symbols Of a Real Ethereum Hash
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Vitalik Buterin
Sr. Member
Offline Offline

Activity: 331
Merit: 337

View Profile
February 05, 2013, 11:53:16 AM

Another option I've seen is to create a transaction of, say, 100 BTC going from you to you, with a 0.00001 BTC input from the merchant, with a lock time, and then every time you make a purchase you and the merchant together release a new version of that transaction that sends some of the money to the merchant instead. If the merchant disappears, when the lock time hits you just get the rest of your money back, and neither you nor the merchant can unilaterally replace the transaction with another one - you have to both agree to do it.

Argumentum ad lunam: the fallacy that because Bitcoin's price is rising really fast the currency must be a speculative bubble and/or Ponzi scheme.
Pages: [1]
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!