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.
Intro:
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
http://bitcoinmagazine.com/review-of-acceptbit-the-trust-free-payment-processor . 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).
Thoughts?
