Verifiable bank transfer using SCIP?

[oakpacific]

So I read this post: https://bitcointalk.org/index.php?topic=277389.0 , without understanding much math detail about it, but if "a system where someone can run an arbitrary program inside a special environment and then publish a very compact and quickly-checkable proof which will convince anyone" is indeed possible, then it sounds to me like it should also be possible to build a program which allows a Bitcoin buyer to do an online banking session, and publish a proof to convince a escrower that he has indeed transferred the negotiated amount of fiats to the designated account. Such a program would then enable anyone to buy bitcoins online in a P2P manner without giving away any confidential information, all you need to find is a seller, and an escrower.

Could anyone please tell me if I am too naive? Thanks.

[Mike Hearn]

SNARKS are the wrong tool for this job, however, the right tool for the job is already being developed here:

https://bitcointalk.org/index.php?topic=173220.0

Why not go help them out?

[oakpacific]

SNARKS are the wrong tool for this job, however, the right tool for the job is already being developed here:

https://bitcointalk.org/index.php?topic=173220.0

Why not go help them out?

I have been closely following this project, and that's why I have been thinking about it.

Theirs is about the most practical solution you can find, but it's not very elegant and contains some weak links(e.g., the use of an "oracle" server allows certain organizations to track if you are buying bitcoins), and I am purely exploring theoretical possibility here, so I am more interested in hearing why SNARKS is not the right tool, because it doesn't scale for complex jobs?

[Mike Hearn]

It's still very early days for SNARK/SCIP technology, yes. It's not even open source yet.

If you want a solution without a third party oracle, the correct solution is an extension to the TLS protocol. It would be useful for many things. Of course, banks tend to upgrade their software slowly, but it's also a market (sorta) where you can open up accounts with more savvy banks if you want. For instance, my bank (UBS) has a pretty reasonable SSL setup and runs on Apache, so assuming they keep it up to date with security updates, eventually an OpenSSL that supported the new extension would make it to their servers naturally.

[gmaxwell]

In case you're too lazy to follow Mike's first link: The main theoretical problem with your idea is that SSL/TLS doesn't provide non-repudiation.

The server does not sign the data it's sending to you— it signs a session key, but that means that the party creating the transcript could take the signed session key and attach it to a forged transcript.

[waxwing]

SNARKS are the wrong tool for this job, however, the right tool for the job is already being developed here:

https://bitcointalk.org/index.php?topic=173220.0

Why not go help them out?

I have been closely following this project, and that's why I have been thinking about it.

Theirs is about the most practical solution you can find, but it's not very elegant and contains some weak links(e.g., the use of an "oracle" server allows certain organizations to track if you are buying bitcoins), and I am purely exploring theoretical possibility here, so I am more interested in hearing why SNARKS is not the right tool, because it doesn't scale for complex jobs?

about tracking - it's an interesting and valid criticism. The original concepts did not involve an oracle, and were more based around escrows being instantiated by lots of users. We developed the idea of a P2P network of escrows (local/remote port forwarding via escrow to avoid NAT issues), with random choice of escrow (and obviously Sybil mitigation), and I in particular liked the extra twist of 2 escrow steps for additional verification.
In this kind of model tracking is far less of an issue (but it would of course require a big network, but then there's an obvious way to incentivise that).

In the oracle model we could still have a network but if we're using Amazon or whatever as our trust root, then clearly the decentralisation effect is somewhat limited. On the other hand the oracle model has very significant trust benefits which might outweigh the theoretical possibility of tracking/flagging.

About inelegant - I totally agree, but I think that was an inevitable consequence of what the project is trying to do. We're trying to do something that is trivial to achieve if the bank wants to help - they simply sign their statements, end of discussion. They don't do this, and they will not be interested in helping us. It's not about features in TLS, it's about banks prefering to keep repudiability. They've known how to do digital signing for a long time, they choose not to. That's why inelegant hacks are the only approach.

[oakpacific]

SNARKS are the wrong tool for this job, however, the right tool for the job is already being developed here:

https://bitcointalk.org/index.php?topic=173220.0

Why not go help them out?

I have been closely following this project, and that's why I have been thinking about it.

Theirs is about the most practical solution you can find, but it's not very elegant and contains some weak links(e.g., the use of an "oracle" server allows certain organizations to track if you are buying bitcoins), and I am purely exploring theoretical possibility here, so I am more interested in hearing why SNARKS is not the right tool, because it doesn't scale for complex jobs?

about tracking - it's an interesting and valid criticism. The original concepts did not involve an oracle, and were more based around escrows being instantiated by lots of users. We developed the idea of a P2P network of escrows (local/remote port forwarding via escrow to avoid NAT issues), with random choice of escrow (and obviously Sybil mitigation), and I in particular liked the extra twist of 2 escrow steps for additional verification.
In this kind of model tracking is far less of an issue (but it would of course require a big network, but then there's an obvious way to incentivise that).

In the oracle model we could still have a network but if we're using Amazon or whatever as our trust root, then clearly the decentralisation effect is somewhat limited. On the other hand the oracle model has very significant trust benefits which might outweigh the theoretical possibility of tracking/flagging.

About inelegant - I totally agree, but I think that was an inevitable consequence of what the project is trying to do. We're trying to do something that is trivial to achieve if the bank wants to help - they simply sign their statements, end of discussion. They don't do this, and they will not be interested in helping us. It's not about features in TLS, it's about banks prefering to keep repudiability. They've known how to do digital signing for a long time, they choose not to. That's why inelegant hacks are the only approach.

Let me be clear that I absolutely appreciate your guys' effort, it's just my obsession with theoretical elegance and my "greatest idea ever" bullshit that induces me to make this post. I haven't given up on it entirely yet, despite what seems like insurmountable difficulty.

[waxwing]

No possibility of offense here, this is constructive dialogue. I am fully with you in always looking for the best way.

So, you aren't the only one who thought about possible ZKP solutions to our problem. I even wondered whether it might be possible for the buyer to prove that the encrypted data corresponded to a particular html page, without handing over the ssl key. In principle such things are actually possible with asymmetric encryption, but not with symmetric.
These approaches would of course be cleaner, but I think they are not possible, at least for now. Would love to be proved wrong.

[markm]

About inelegant - I totally agree, but I think that was an inevitable consequence of what the project is trying to do. We're trying to do something that is trivial to achieve if the bank wants to help - they simply sign their statements, end of discussion. They don't do this, and they will not be interested in helping us. It's not about features in TLS, it's about banks prefering to keep repudiability. They've known how to do digital signing for a long time, they choose not to. That's why inelegant hacks are the only approach.

Isn't this simply a matter of remaining competitive? Any bank/currency (currency as in things like Liberty Reserve, e-gold etc type "banks") that refuses to cater to this type of customer will simply be deprecated; person to person currency-exchangers will simply tell people "I don't accept Paypal or e-gold, use Liberty Reserve, Bank Of Blackmarkestan, or Lloyd's of London" or whatever the banks/currencies happen to be that they know do provide such a service?

Back in the late 1990's to 2000 or thereabouts this was actually happening. I think e-gold might not have given users the ability to expose their transaction history, but some other service(s) did; maybe it might have been Liberty Reserve that did, I am not sure as I never used Liberty Reserve personally.

Basically you would say "okay expose your transactions on the account you want me to send to and I will expose the transactions on the account I will send from, once we can both (and in fact everone on the trading forum, if we post our URLs here on the forum instead of in private messages) see each other's transaction histories I will send". Also of course things along the lines of "e-gold is no good, use Liberty Reserve" or whatever one it was the person preferred that did offer this exposure capability.

The resistance to signing statements could possibly be "justified" by arguing that such a statement, being non-repudiable, should be regarded as in effect a public publication, because there is no assurance that the recipient or their heirs and assigns would not make it public. Thus maybe this approach of setting an entire account to have a public transaction-history is better because it makes it more likely that the user will realise the data is public, instead of falling into the trap of imagining that the other party and the heirs and assigns of the other party will never make the data public.

Maybe though if Liberty Reserve was one of the banks/currencies offering this option that might be part of how it ended up getting in trouble about money-laundering, since obviously people would want to be able to open throw-away accounts if they didn't want all their verifiable transactions to be publicly known to all pertain to the same actor. That is, maybe the same people who wanted to be able to provide a link on a currency-trading forum whereby anyone could see they did indeed send the money they said they would send or had not received the send the other party claimed to have sent also wanted there to be no way any of those forum-denizens could strongarm the currency-provider to find out the real identity of the person who thus "proved" they had done the send, leading to the provider deciding such a feature needs to be accompanied by the ability to open throwaway accounts anonymously in order to truly be useful/competitive?

Just signing one-off acknowledgements of individual sends does seem more private than having the entire history of an account be made public, but, bear in mind that merely proving someone's bank/currency-provider claims to have sent the funds is not as damning, in fraud accusations involving an intended recipient claiming not to have received funds, as being able to tell the intended recipient to "prove" they did not receive the funds by exposing the account-history of the account the funds were sent to.

(Showing the intended recipient did or did not receive the transfer is "stronger" than merely proving the sender did send it. It helps diagnose, for example, whether the problem lies with the sender, the receiver, or the site/entity that was supposed to actually implement/perform/make-so the transfer.)

-MarkM-

[Come-from-Beyond]

So I read this post: https://bitcointalk.org/index.php?topic=277389.0 , without understanding much math detail about it...

It relies on hardware implementation, not on pure math. Hence it's breakable or can contain backdoors.

[waxwing]

<snipped>
-MarkM-

Overall answer: first, in terms of why banks don't sign statements. First, it's not that it's never happened. I found one case via google of ICICI bank in India doing it (but no longer, I believe). I have heard anecdotally of perhaps one other case. Now, why? The question splits into two parts, as you pointed out: 1. Why don't banks want to do it, 2. Why don't competitive pressures force at least some of them to offer it.

1 - I can only conjecture, but it's a pretty obvious cover your ass scenario. Just like when software devs write "provided as is", banks do not want what comes out of their software to be recorded for all time. If they screw up and tell you you have a million dollars on the screen, they don't want people to be able to prove that they said that. And variations on this theme, but you get the general idea.

2 - Competition in banking is in a very unnatural state. It's not that there is no market, but that the price signal they're following is a very screwy one. While the interests of their retail customers count somewhat, they are much more driven by regulatory pressures (a huge part of their costs nowadays) and their big corporate customers. Heck, this is a pretty complicated discussion and veering off topic. And while retail customers might want this (e.g. for proving income, and some trade scenarios) if they understood public key encryption, they don't, and so they don't.

I think my main point is, they don't have any incentive to do this for ordinary customers, and they have a massive disincentive. End of story.

[Mike Hearn]

I'm not sure it's a strategic decision not to implement that. I think it's just that digital signatures are complicated and normally unnecessary, so 99.9% of users wouldn't find that feature valuable and are not requesting it. I mean, did you care or have any use case for it before this project? I doubt it. I've never needed digitally signed statements from my bank because normally I don't share them with anyone.

If it was brainless and on by default, I don't see why a bank would explicitly disable a TLS extension to let you sign a session hash. It's not like banks routinely say, "We didn't send that" about paper statements even when they did.

But it's something that would take years to become widespread, at best. So the oracle approach is not a bad way to start.

[waxwing]

I'm not sure it's a strategic decision not to implement that. I think it's just that digital signatures are complicated and normally unnecessary, so 99.9% of users wouldn't find that feature valuable and are not requesting it. I mean, did you care or have any use case for it before this project? I doubt it. I've never needed digitally signed statements from my bank because normally I don't share them with anyone.

If it was brainless and on by default, I don't see why a bank would explicitly disable a TLS extension to let you sign a session hash.

Yep, as I say, conjecture on my part, and you have a good point about defaults. I can't remember if dansmith or I ever looked into that in the end.

As to strategic or not: Yes, it could simply be that nobody ever asks for it. But there is an obvious use case - it is very common for certain organisations (sometimes governmental, sometimes not) to ask for proof of income or "means". I had such a case myself only a couple of months back. I printed a copy of my bank statement off the internet. It proved, of course, nothing, but they accepted it.

It's not like banks routinely say, "We didn't send that" about paper statements even when they did.

No, they wouldn't do that of course in practice, but the point is whether a statement stands up in court. Take a look at typical internet banking TOS (from what I've seen it varies a lot). There is absolutely no reason for them to create terms of service that create any liability for a bank if they don't have to. Frankly, if they did create such liabilities willingly, without any external or market pressure to do so, they should fire their lawyers

Here is an excerpt from one such TOS (I chose at random Lloyds TSB in the UK):

You are responsible for checking statements, text
messages or other account information we give
you. If you tell us about any errors on your account,
or if we notice any errors, we will correct them as
soon as reasonably possible.

This is actually even worse than I thought, they are disclaiming any responsibility to give accurate information under any circumstances. This, by the way, is typical of the ridiculously lopsided service agreements one has to enter into with banks.
Under these circumstances it theoretically wouldn't even help to have digital sigs! What's the point of signing something you don't stand behind? Of course in practice people would not worry about such details. The point is, from the point of view of lawyers, I think they would be strongly against it.

(Of course in all this I am ignoring the fact that banks view Bitcoin like leprosy, it's too obvious to mention).

[oakpacific]

I'm not sure it's a strategic decision not to implement that. I think it's just that digital signatures are complicated and normally unnecessary, so 99.9% of users wouldn't find that feature valuable and are not requesting it. I mean, did you care or have any use case for it before this project? I doubt it. I've never needed digitally signed statements from my bank because normally I don't share them with anyone.

If it was brainless and on by default, I don't see why a bank would explicitly disable a TLS extension to let you sign a session hash. It's not like banks routinely say, "We didn't send that" about paper statements even when they did.

But it's something that would take years to become widespread, at best. So the oracle approach is not a bad way to start.

I have some experiences about that, in many countries when you need to apply for a student visa to another for education, the visa officers routinely request you to submit proof of you financial ability, like something they call a certification of deposit, which is only produced in paper form and needs to be stamped, as electronic version can always be forged, so you will need to get to a bank branch and queue for several hours just to get it done, an annoyance especially consider they only work Monday to Friday, nine to four, had they digitally signed their statements you could have one printed out in minutes, I guess it's just the non-profitability and fear of any change that is stopping them from making digital signed bank statements available, as my use case is quite common.

[Mike Hearn]

Governments have always been behind when it comes to use of basic crypto. Estonia is an unusual exception. It wouldn't surprise me to learn you can get digitally signed bank statements there. Their whole government infrastructure is incredibly hi-tech (by the standards of government), they issue every citizen with a smart card that can be used for digitally signing documents, and there's a specific standard they use for signing PDFs and so on. Everything can be done online and digital signing is widely used.

One reason Estonia is like this, is that after the fall of communism they got a very young government (average ages were in their 30s) and they were far behind with infrastructure, so they got something of a clean slate.

A TLS extension wouldn't just help with banks of course. It gives you free, authenticated exchange rates from any site that serves JSON exchange rate data over TLS, and then that can be used in oracles to do other things. Actually because HTTP responses include a date/time, you could take basically any document or piece of data you find on the web and use them in oracle-based automated dispute mediation. Being able to prove SSL sessions is a very powerful and general tool.