This thread follows on from
this post.
But before you read the details, some background.
You're welcome not to read ALL of this
Just get a flavour. Then click the link above for instructions on how to get involved.
Motivation The biggest problem with Bitcoin is getting hold of some. Conduits allowing fiat money to flow into Bitcoin have proven themselves unstable, and so many are searching for a decentralized way to allow this to happen.
The problem The problem with most attempts to solve this is the fundamentally different nature of fiat money, controlled by banks, governments and financial institutions is so different from the fundamental nature of Bitcoin. Bitcoin is irreversible, most other forms of money in everyday use are not. Take a look at the
scale of money hardness. If you try to trade directly with a counterparty (i.e. not via an exchange), say, credit card money for bitcoins you have an insurmountable problem: the bitcoin buyer can reverse his payment in the future.
Solution 1: the localbitcoins model The site localbitcoins.com has been a tremendous success in allowing people to transfer cash and other 'hard' money for bitcoins. Physical transfers are awkward in various ways, and impractical for those in remote locations. Online payments with mechanisms like bank wires and OK Pay seem like a better solution, although they incur fees; they're faster, location-independent, and in some ways safer. Escrow helps keep the process even safer, but there's a problem: what if the bitcoin seller denies having received the funds? Here's what the localbitcoins site says about disputes:"LocalBitcoins.com support handles disputes based on evidence and reputation supplied by trade participants." What evidence might that be?
We shouldn't forget also how centralized localbitcoins is as a business and as a trusted third party, albeit the model can be replicated.
Solution 2: the Paysty approach With Paysty we are proposing a significant improvement to the above model:
a way to prove that you sent a bank transfer. You still have the escrow mechanism, but it's relegated to a trivial checking mechanism: the escrow requests proof of transfer.
So how does it work?Payments of 'hard' money (see above) made via bank transfer and via OK Pay (and some others) are done over ssl (https) connections on the internet. This network traffic is encrypted, for obvious reasons. There is nothing stopping you
recording encrypted traffic; it's just that without the secret key which both you and your bank have, it's not possible to read it.
So here's the trick: pass your internet banking session through a proxy, which records the encrypted traffic. The bank won't know this has happened: they just see the traffic coming from a particular IP address.
But let's go one better: let's host the proxy on a virtual machine in the cloud, and let's set that machine up in a special way so that anyone can verify what software it's running, and no one (including the account owner!) can modify what it does. Let me be clear: any person accessing this machine can only run one program by accessing the machine, and the only extra thing the owner can do is shut it down.
So? You can record the traffic. Big deal, it's encrypted. We can do more. The person making the bank transfer can, if asked, and they agree, provide ONE (or a few) of the ssl encryption keys to a third party. This will allow that third party to decrypt ONE html page. That html page might have this kind of info:
Subject Acknowledgement - Ref No. BA123
20 Oct 2013
Status: transfer completed
TT Reference No: XXXXXXXXXXXXXXX
Processing Date: 20 OCT 2013
From Account: my-usd-account-number
Payment Amount: USDX,XXX.XX
To Name: recipient-account-name
To Account: beneficiary-acct-number
To Bank: XXXXXXXXXXXXXXXXXX
Bank Address
Amount Debited from Source Account: USDX,XXX.XX
Charges: USDXX.XX
Charge Account: my-usd-acct-numberNotice that you will never, of course, have to display your username, password. That will remain fully encrypted and as safe as it was in just doing a normal banking session.
So, how will it usually work? Usually, you will
(0) Choose in advance an escrow agent to act as third party for bitcoin payment, and to adjudicate dispute.
(1) agree on a transaction with a counterparty (we are looking at options for how to set up private messaging for that now)
(2) place bitcoins in escrow (if you're the seller)
(3) do your normal internet banking
without running Paysty (if you're the buyer)
Note for those aware of such things: there is a possibility that this whole system will be integrated into Open Transactions as a legacy banking interface; this will mean that OT will handle (0),(1) and(2).
And how will it work if there's a dispute?The most plausible type of dispute is where the seller of bitcoins says "no, I didn't receive those fiat funds".
The buyer of bitcoins (=the sender of fiat funds) will be asked to run Paysty. Inside Firefox, she will browse to her banking website and to the page which shows proof of the transfer, including the account number of the recipient and the amount. Paysty will record this whole banking session in encrypted form on the 'oracle' machine (the one in the cloud, remember?) which is doing the proxying. Then the escrow will request the buyer to send that set of ssl encryption keys that decrypts that one html page, which the buyer has marked as being proof. This is the objective basis on which the escrow can judge.
The best thing is - the more watertight the proof, the less likely anyone will dare to try to defraud you...
So this isn't finished? Why does it need testing? The part of the software that's new (the verification/proof of bank sessions) is basically finished. The other elements are bits of software that already exists so we're not very worried about getting them working.
What it needs right now is a good set of example data of how well it works with bank websites. We already have evidence from about 5 banking websites that it works fine, but we'd like many more.
What does the test actually do? If you follow all the instructions in the link at the top of this post (
here it is again), you should see either a "congratulations" or an error message. Report these findings back to dansmith or I.
For best results, please use a page on the website with a record of an actual transfer of funds, so you can select an account number and sum/amount. If you choose to use some other data on the page, such as a statement balance, or anything else, it will still work, but this will not serve the purpose of the test - we want to know whether it's possible to use this system with your bank.
How can I know this software is safe?The software is open source and, in this simple testing version, does not transfer your ssl keys off your local machine under any circumstances. Therefore you're in the same situation as with a normal internet banking session - the only thing the 'oracle' machine sees is encrypted data. If you feel like reviewing the code, go to
https://github.com/themighty1/ssllog, and in particular review buyeroracle.py to see how ssl keys are handled locally. If you need help understanding something about the code, give us a shout.
