How Can We Make a Financial Transaction, Without Anyone Finding Out?

How Can We Make a Financial Transaction, Without Anyone Finding Out?

A bit of work over the Christmas break

Over the Christmas break, I have been working on zero-knowledge proofs for blockchain, and I now have a deep understanding of their operation. But the more I work on blockchains, the more apparent their weaknesses become. This includes the way that Bitcoin gives away the full details of a transaction, including the participating parties and the amount transferred. In a financial system, this has advantages, in that every transaction can be audited, but the disadvantage is that everyone can see all the transactions that we made.

Imagine if every time you paid a bill to your utility company, they could tell how much money you had in your account? In fact, everyone in your street could tell what you have just paid and how much money you have in your account ... well, that's what happens with blockchain and bitcoins.

So one of the greatest challenges in blockchain research is to create methods which allow two parties to transfer an asset, and for only those two parties to see the details of the transaction.

Blockchain - A new model for transactions

Blockchain provides a way to share data transactions between untrusted nodes, without the need for a centralised service. But every node is able to see every transaction made, and can validate them. In a public blockchain for crypto-currencies we define the complete ledger which shows who owns the currency at any point in time.

When Bob and Alice made a transaction on a blockchain, such as "Alice pays Bob one Bitcoin", their identities are hidden with a long alphanumeric string of gibberish. But the strings can still be used to map back to the real identity.

So when Alice sends some bitcoins to Bob, she generates an address and the number of bitcoins to send, and then signs the transaction with her private key. She adds Bob address, and the bitcoin miners will process her transaction.

A secret address?

In Bitcoin methods, we secure our Bitcoins using a private key and to sign a transaction, and then use the public key to verify it. It uses a distributed database that tracks the ownership of all the bitcoins created. These are defined with a Bitcoin address, such as:

1A3CohNBuB6kFAMtp3KFEYwv3Eu58F2HyN

There are no centralised servers with bitcoins, and instead, there is a distributed peer-to-peer network with nodes which exchange transactions, blocks and addresses with the rest of the network. One a new transaction the node sends out the new transaction to a peer node, who will send it to others, until it spans the whole network. The mining nodes then pick up the transactions, and start mining, and then broadcast the mined block. After a while, the node will receive the mined block back and which will show the successful transaction.

So if we need to use blockchain as a data storage entity, where we can store data, we need the blockchain to define where the data was sourced from, and where it is going, with a timestamp, and something that proves the transaction (immutable). In a Bitcoin network, all the nodes much know how much money Bob and Alice have, otherwise Alice could send Bob more money than she has.

Now we have come to the first problem:

All nodes now know how much money Alice has, and much verify she has enough credits, before the transaction can be approved

But is this a problem, as the blockchain entry will have gibberish addresses, and not relate to Alice. But if I know when Alice does her transactions on-line, and what she likes to purchase I can search the chain for her address, and who she trades with, and then find out all the other addresses that Alice uses (see Chainalysis).

Immutable for just me and you?

So recently we saw the launch of Zcash, and which uses a public blockchain. With this new currency, money can be sent without identifying the sender and receiver, and which overcomes one of the core drawbacks of Bitcoin, and many other cryptocurrencies.

So is it possible for us still to use the advantages of blockchain, but overcome the problem of every node knowing the details of a transaction? In this way we need a system where only the two parties involved in the transaction can read the details of the transaction, and that it is immutable. So what we need is zero-knowledge proofs.

If you want to understand zero-knowledge proofs:

With Zcash we use to prove that the transfer of an asset is correct, but where none of the transaction is revealed, and uses a new method of zero-knowledge proof known as zk-SNARKs (Zero-Knowledge Succinct Non-interactive Argument of Knowledge). Basically, Alice asks Bob if he can prove that he knows the input values for an arithmetic circuit, and which will produce an output of 1. For example if the circuit was a simple X-OR gate, then Bob would produce a 0 and a 1, and Alice would prove that this gave an output of 1. Overall the method is fairly complex, but here is a basic description of the concepts around scrambled circuits:

While zero-knowledge proofs have been around for a while, with zk-SNARK [paper], we have the ability to add them to blockchains, as they significantly reduce the footprint of the transaction proof (1KB) and also the computation required for the validation (less than 6 milliseconds). With bitcoins we have 0.3KB footprint, and transactions verified in less than 1 millisecond, and we see that the zero-knowledge version can now compete with bitcoins.

So what's the downside?

Now we come to the setup. In order setup Zcash, we need a trusted setup, where the two nodes come together. We then generate two public keys from a randomly generated private one. This private one must be destroyed after it has been used to create the public keys. Anyone who has a copy of this private key will be able to solve the proofs. You can read the creation of the privacy key here, and where several participants come together to create the private key. The system can only be compromised by taking over all of the participants in the creation of the private key.

While the time to verify the transaction is on-par with bitcoin, the creation of the transaction has a considerable computation footprint. This, on a high-performance system, can take over 40 seconds to produce [here]:

Conclusions

At present, Zcash looks to be a major advancement, but it is let down by its performance issues. Along with this, there is the lurking threat around the zero-knowledge proof, and if it is broken, the transactions will not be credible, and if money is involved, they will be worthless.

Finally, as Zcash requires miners to verify its transactions, what happens if the miners are controlled by malicious miners (where they gain a 51% share of the mining process)?

Are you interested in ZKP? Here's a few articles to get those cogs in your brain moving again after the Christmas break:

and:

and:

and:

and:

and:


Lou R. Houlemarde

Software & Technology Leader

8 年

I think the more pertinent question is: how does a company protect its users from itself? That is, how can a company prove to its users that even though the company controls the data, there is no way to determine what transactions have occurred (and by who) even if they wanted to. I have solved this problem via a cryptographic scheme without resorting to a blockchain --and so it is a very pragmatic and performant solution to problems like this.

回复
Dimitri T.

Avoiding self-identifying labels and building cybersecurity solutions to leave no risk unturned.

8 年

So lets reimplement Zcash and make it faster. :))

回复
Ian Watt

FRSA. FIoL, MSc Data Science. Open data advocate; Charity Founder and Trustee; Data Scientist; Director; Wikimedia UK trainer. Burgess of Guild of Aberdeen

8 年

Interesting article as always. Of interest to James Littlejohn who is doing really interesting things in the Blockchain / Health arena.

回复

要查看或添加评论,请登录

Prof Bill Buchanan OBE FRSE的更多文章

社区洞察

其他会员也浏览了