I guess banks are decades away from implementing a third-party automatic transaction confirmation based on digital signatures.
I'm gonna close this thread now and start a new one, because the title of this thread i misleading and I think I found a workable solution with SSL dumps. Stay tuned.
Topic: P2Px. How to create a tamper-proof screencast? (Read 910 times)
Banks should be more like bitcoin. 
If you have a transaction number, they should be able to tell you how much was transfered and if it was successful without revealing who it came from or went to unless you know the hash of that person's name
If you have a transaction number, they should be able to tell you how much was transfered and if it was successful without revealing who it came from or went to unless you know the hash of that person's name
You are correct in that SSL is spoofable because it uses symmetric keys to encrypt its traffic.
I'm now looking into TLS specification to see if there is any exotic feature which would enable my plan. (but I doubt that)
This is my plan too, as you said: A. to verify that the payment was sent B. to not store user/passwd data in case the data is compromised.
Asking the payer to provide his uname/passwd to the escrow agent in case there is a dispute, so he could log into the payers account and verify that the payment took place is an option, albeit a last resort. I'm looking for any possible way to do it without disclosing login credentials to the escrow agents.
Getting confirmation from the bank (using the OFX protocol) is doable, but still requires logging in, because the bank will not disclose the info to a third party.
I'm now looking into TLS specification to see if there is any exotic feature which would enable my plan. (but I doubt that)
This is my plan too, as you said: A. to verify that the payment was sent B. to not store user/passwd data in case the data is compromised.
Asking the payer to provide his uname/passwd to the escrow agent in case there is a dispute, so he could log into the payers account and verify that the payment took place is an option, albeit a last resort. I'm looking for any possible way to do it without disclosing login credentials to the escrow agents.
Getting confirmation from the bank (using the OFX protocol) is doable, but still requires logging in, because the bank will not disclose the info to a third party.
Why don't you just record keystrokes of the payer logging into his bank account so you can later log in to his account as well and make sure the transfer happened? 
I'm glad you decided to not go with a screencast--it is quite easy to create an offline copy of a website and set up your computer to redirect certain url requests back to itself, so even though it will look like the user is logging in and sending payment, he won't actually be connecting to his bank's website.
It seems like getting a confirmation number directly from the bank would be the safest bet, but I don't know how you would arrange that. Making the payer give proof that isn't spoofable but also doesn't endager the payer's personal information and accounts sounds near impossible.
Wouldn't even an SSL dump be easy to fake? Or include the payers password and other info making it possible for someone else to log in and clean out their accounts if that data were ever compromised?
I'm glad you decided to not go with a screencast--it is quite easy to create an offline copy of a website and set up your computer to redirect certain url requests back to itself, so even though it will look like the user is logging in and sending payment, he won't actually be connecting to his bank's website.
It seems like getting a confirmation number directly from the bank would be the safest bet, but I don't know how you would arrange that. Making the payer give proof that isn't spoofable but also doesn't endager the payer's personal information and accounts sounds near impossible.
Wouldn't even an SSL dump be easy to fake? Or include the payers password and other info making it possible for someone else to log in and clean out their accounts if that data were ever compromised?
I guess I've found a simpler solution. No need for screencasts.
All that is needed is the dump of SSL traffic with one's online banking account along with the private key used for the SSL session.
This way a third party can later establish with certainty that a user indeed logged in and sent payments.
Great, now I need to create a Firefox plugin which saves the SSL dump and integrate it with a p2p exchange.
All that is needed is the dump of SSL traffic with one's online banking account along with the private key used for the SSL session.
This way a third party can later establish with certainty that a user indeed logged in and sent payments.
Great, now I need to create a Firefox plugin which saves the SSL dump and integrate it with a p2p exchange.
Thank you Ripple has its future and its niche.
Yet I need something even more decentralized. And something that can be done RIGHT NOW. We already have bitcoin.de with substantial amounts of transactions.
Having tamper-proof screencasts will boost even more trust in p2p exchanges.
Yet I need something even more decentralized. And something that can be done RIGHT NOW. We already have bitcoin.de with substantial amounts of transactions.
Having tamper-proof screencasts will boost even more trust in p2p exchanges.
I'm researching ways of creating a p2p exchange with (little) escrow services.
May be it is worth to take a brief look here for some inspiration, if you are talking about currency exchange: https://ripple.com/bitcoiners/
EDIT: this idea has been superseded by a better one - SSL dumps
https://bitcointalksearch.org/topic/tlsnotary-cryptographic-proof-of-fiat-transfer-for-p2p-exchanges-173220
----------------------------------------------------------------------------------------
I'm researching ways of creating a p2p exchange with (little) escrow services.
I'm looking for a way to make a screencast (a video recording) of user's desktop where he logs in to his bank account, enters the recipients bank details and sends the funds. This screencast has to be tamper-proof. It can be later used as proof in case a dispute arises.
Does there exist such a technology?
Can you suggest ways of implementing it?
My only idea at this point is this:
While the video is being recorded, every second the recording app takes a hash of the frames, submits it to a server (controlled by escrow) and receives a unique token which it embeds into the frames of the next second. Because the paying party has to be online anyway in order to log into his bank account, this should work.
Could we please brainstorm here any other possible solutions.
Particularly is there a pure offline implementation?
I am willing to invest a lot of time and money into this idea as I see it as a significant step forward for p2p exchanges with minimal escrow involvement.
https://bitcointalksearch.org/topic/tlsnotary-cryptographic-proof-of-fiat-transfer-for-p2p-exchanges-173220
----------------------------------------------------------------------------------------
I'm researching ways of creating a p2p exchange with (little) escrow services.
I'm looking for a way to make a screencast (a video recording) of user's desktop where he logs in to his bank account, enters the recipients bank details and sends the funds. This screencast has to be tamper-proof. It can be later used as proof in case a dispute arises.
Does there exist such a technology?
Can you suggest ways of implementing it?
My only idea at this point is this:
While the video is being recorded, every second the recording app takes a hash of the frames, submits it to a server (controlled by escrow) and receives a unique token which it embeds into the frames of the next second. Because the paying party has to be online anyway in order to log into his bank account, this should work.
Could we please brainstorm here any other possible solutions.
Particularly is there a pure offline implementation?
I am willing to invest a lot of time and money into this idea as I see it as a significant step forward for p2p exchanges with minimal escrow involvement.
Jump to: