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.
Topic: Idea: Banks and checks (Read 931 times)
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. 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.
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.
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.
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. 
That's a very complicated protocol for a vending machine.
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:
(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?
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:
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.
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]
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?
Jump to: