Bitcoin Forum
November 09, 2024, 06:28:23 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Idea: Banks and checks  (Read 926 times)
qbg (OP)
Member
**
Offline Offline

Activity: 74
Merit: 10


View Profile
July 09, 2011, 07:04:37 PM
 #1

Waiting for a transaction to be confirmed can be an impediment towards POS transactions. Accepting a check from a trusted Bitcoin bank would be one solution to the problem. I've being thinking about how this would work and have derived the following protocol so far:
Quote
Alice wishes to buy a neat toy for her daughter from Bob for two Bitcoins.

Alice asks Bob if she can pay with a check from her bank, ABC. Bob says 'yes' and gives her the public key to make the check out to (call it PK).

Alice contacts ABC and asks for a check payable to PK for the amount of two Bitcoins. ABC checks Alice's account for two Bitcoins. Alice's account has at least two Bitcoins, so ABC puts a hold on her account for, say five minutes, of the amount two Bitcoins. ABC then creates a check of the following form and gives it to Alice:
Quote
(magic bytes) [identifies this as being a check]
ABC [the name of her bank]
2 [the amount of the check]
PK [the receiver's public key]
(transaction details) [public information about the transaction]
(bank info) [encrypted information used by ABC. Can contain information such as an id number to prevent double spending, Alice's account number, etc.]
(bank signature) [A signature by ABC of all previous fields]

Alice gives this check to Bob.
Scenario 1 (Bob doesn't have a bank):
Bob verifies he can accept the check. Bob contacts ABC and asks to cash a check. Bob gives the check to ABC. ABC verifies the check, and gives a nonce to Bob. Bob encrypts the nonce with the corresponding private key of PK and gives the result back to ABC. ABC verifies the result with PK, and asks Bob for a receiving address. Bob gives a receiving address to ABC. ABC sends two Bitcoins to the address and notifies Bob that Bitcoins have been sent.

Scenario 2 (Bob's bank is XYZ):
Bob contacts XYZ and asks to deposit a check. Bob gives the check to XYZ. PK is the public key for XYZ, so they perform the steps in Scenario 1. Upon success, XYZ informs Bob that his account has been credited the amount on the check.

The transaction is now complete, so Bob gives the neat toy to Alice.

(transaction details) can be used to indicate the type of account from which the amount is being drawn. In the above situation, this field is empty, indicating full-reserve on-demand Bitcoin deposits.

Thoughts? Does anyone see something wrong with the above?
error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
July 09, 2011, 07:39:10 PM
 #2

That's a very complicated protocol for a vending machine.

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
qbg (OP)
Member
**
Offline Offline

Activity: 74
Merit: 10


View Profile
July 09, 2011, 07:52:29 PM
 #3

That's a very complicated protocol for a vending machine.
It would be implemented by software so it would be easy to use in practice. Cryptographic protocols tend to be complicated.
oillio
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
July 09, 2011, 08:19:22 PM
 #4

I had a similar idea, but I think you can use the bitcoin transaction protocol for this.

The gist is that, if you trust the transaction creator to not double-spend (not much trust required), you don't need to wait for the transaction to confirm in a block.

So, if you receive a transaction from a "bank" you trust, you can act immediately on the transaction.  If it is not from a trusted source, you must wait for confirmation.

To prove a transaction came from a particular source, the bank creating the transaction would sign it with a private key (the corresponding public key could be put in their DNS entry).  They could either add the signature to the bitcoin transaction (I believe there is a way to add arbitrary data) or the signature could be stored in a separate database.

This is a pretty minor (and backwards compatible) addition to the current protocol.  We just need the big players (MtGox, mybitcoin, etc) to agree to a standard and start signing their transactions.
qbg (OP)
Member
**
Offline Offline

Activity: 74
Merit: 10


View Profile
July 09, 2011, 09:22:54 PM
 #5

I had a similar idea, but I think you can use the bitcoin transaction protocol for this.

The gist is that, if you trust the transaction creator to not double-spend (not much trust required), you don't need to wait for the transaction to confirm in a block.

So, if you receive a transaction from a "bank" you trust, you can act immediately on the transaction.  If it is not from a trusted source, you must wait for confirmation.

To prove a transaction came from a particular source, the bank creating the transaction would sign it with a private key (the corresponding public key could be put in their DNS entry).  They could either add the signature to the bitcoin transaction (I believe there is a way to add arbitrary data) or the signature could be stored in a separate database.

This is a pretty minor (and backwards compatible) addition to the current protocol.  We just need the big players (MtGox, mybitcoin, etc) to agree to a standard and start signing their transactions.
Transactions are already signed, so it looks like you just have to verify the coins came from a trusted address.
oillio
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
July 10, 2011, 02:42:29 PM
 #6

Transactions are signed against a pseudo-anonymous identity that is used for a small number of transactions.  How do you verify it is a trusted address?

The best idea I have is to provide a public database where banks can store lists of their addresses which are signed against their public identity.  I think signing the transaction with their public identity would be easier.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!