With these kidnappers, rubbers and others not knowing who is behind an address what matters to a selective disclosure?
“Not knowing who is behind an address” is a very large assumption, oft untrue in practice.
The attacks to which I referred are not hypothetical—not only my worries! Please read the link to Jameson Lopp’s collection of news links about physical attacks on Bitcoiners all over the world—mostly armed robberies:
https://github.com/jlopp/physical-bitcoin-attacksSurely, some of those attackers identified their targets in other ways. Surely, some used blockchain data.
Right here on this forum, I have seen how easily people can be identified through their wallets: Leak an address from your wallet. Someone browses around your wallet transactions, and finds the an address connected somehow to your dox. Boom! You are doxed
by someone who also knows how much BTC you have.
Protecting against this type of scenario is difficult, and it should not even be necessary. Privacy should be the default.
Safety should be the default. Disclosure should be opt-in—disclosure by consent—wherefore, “selective disclosure”.
On MagicIf/when Bitcoin gets real privacy, I expect that it will also embrace “selective disclosure”. That would preserve irrevocable, undeniable, irrefutable blockchain information for legitimate use cases—while locking out the prying eyes of hackers, cyberstalkers,
armed robbers, kidnappers seeking ransom, and commercial espionage that seeks to infer competitive business plans from financial transaction data.
Isn't the blockchain information irrevocable, undeniable and irrefutable because, from the way I know it, these attributes and the confirmation that follows broadcasted transactions are the ways in which the chains are ensured of security.
[...]
You know, the only way for transactions not getting counterfeiters is the verifiable nature of the blocks. I'm not very deep into this stuff so, if am getting it wrong at some point, am happy to be corrected.
An excellent question.
Before I answer it, I must ask: How do you know that a cryptographic hash can’t be faked? How do you know that a digital signature can’t be forged? Do you have a deep, rigorous mathematical understanding of the abstract theories behind all of this cryptography? I admit that I don’t—by my own exacting standards of “a deep, rigorous understanding”, I do not understand. I do not understand like someone with a Ph.D. in cryptography!
Recently, I have observed a few times that with a nod to Clarke:
Any sufficiently advanced cryptography is indistinguishable from magic. Now, let’s work some magic.
The Bitcoin POW mining algorithm depends on the pseudorandom properties of a cryptographic hash, SHA256. How does the “avalanche effect” work to give the right statistical distribution of bits?
Magic. Bitcoin also depends on SHA256-based Merkle trees and txids to assure the integrity of transactions. Why can’t anyone forge a txid using fake double-SHA256? What would stop them?
Magic.(I could speak similarly of the secp256k1 digital signatures that Bitcoin uses, but I think I have made my point.)
Hashes and digital signatures have been with us for many decades. That is why Satoshi had them available to use for Bitcoin in 2008.
Within about the past decade, there has arisen a new class of zero-knowledge proof systems commonly known as “zk-SNARKs”. Without digging into the technical details, what such a proof system does is this:
It lets you
prove that you ran a computer program producing a certain output, without revealing all of the inputs of the computer program. In theory,
any computer program can have its execution proved this way; in practice, computational costs impose some rather severe limitations.
When you make the proof, you
cannot substitute a corrupt program for the program that you claim you are executing. By analogy (pedants, please don’t shoot me!), think of it like how you
cannot use an arbitrary fake private key to forge a digital signature. How does it work?
Magic!The way that zero-knowledge proof blockchains work is that
you run a program validating your own transaction. You run the program inside of the proof system—think of the proof system as sort of like a special type of virtual machine
(Pedants...). The proof system outputs a proof that you ran the program validating your own transaction. You publish your proof on the blockchain. Full nodes then verify your proof that you ran the tx-validation program yourself. How’s that for magic?
To preserve privacy, typically, the proof is constructed so as
not to reveal the validation program’s inputs. The program itself must have full access to the inputs. The program verifies that you have money, that your money is not already spent, and that the amount you are sending equals the amount you are irrevocably deducting from your own available funds.
(Oversimplified for explanation—pedants, please don’t shoot me!) The program returns a publicly known output that simply declares that the transaction is valid.
Again, you cannot fake or modify the program that you claim you are running. The program itself processes your private financial data. It is coded to succeed if your transaction is valid, and to fail otherwise. You run it on your own computer—why does every node in the world need to validate your financial data? After you publish your proof, every full node in the world can verify that you ran the right program.
Why do you trust a digital signature, or a hash? How do you
know that a Bitcoin transaction is valid? How do you
know that nobody could forge it? You trust the cryptography!
When this stuff was totally new, an argument could be made that it had not yet had sufficient review by cryptographers. The principles of hash construction used by SHA256 have been known and studied since the 1970s (in part, since various points going back to the 1940s). The basic principles behind digital signatures have been publicly known since the 1970s—elliptic curve digital signatures, since the 1980s. Cryptographers have been analyzing these theories for many years, searching for flaws. The basic principles behind zero-knowledge proofs have been known since the 1980s—but the proof system I hereby describe was not invented until much more recently.
(All dates IIRC, off the top of my head; I may have erred here and there.)But for the past decade, this type of zero-knowledge proof has been a hot area of cryptographic research. It has advanced very rapidly. Cryptographers from all over the world have been working on it—refining the theory, searching for flaws, making improvements and advancements. It is no longer bleeding-edge “moon math” that few understand. And this type of cryptography has already been securing large amounts of financial value for almost six years. (Zcash mainnet launch was in October 2016.) It is now being used on multiple blockchains.
As of 2022, I am willing to declare the technology sufficiently mature for Bitcoin.
To round out the view of how this works:
The zero-knowledge proof reveals zero information about the transaction. It proves that “a valid transaction occurred, in which someone sent some money somewhere”. That’s it! That is why it is called “zero knowledge”.
It is not like Bitcoin mixers, which add fake disinformation to a coin’s history to try to obfuscate private information that has been leaked. It is not like Monero, which is essentially a coin with a built-in mixer (mixins/ring signatures adding decoys as disinfo) plus some other stuff to conceal the amount and the recipient address. zk-SNARKs do not obfuscate information. They do not use decoys or disinformation. They avoid leaking any information to begin with.
The payee needs to know some information, so as to receive the money and later be able to spend it. Since the proof itself reveals no financial information at all, the transaction typically contains, in addition to the proof, an encrypted message. This uses more old-fashioned cryptography, similar in principle to PGP. The message is encrypted to the payee’s public keys. To support selective disclosure, the information required to
spend is encrypted differently than the information required to
view. Accordingly, the recipient has
view keys that can be disclosed separately from
spend keys. (Zcash actually has several different types of view keys, with varying levels of disclosure; I am trying to keep this simple.)
All of the foregoing is an oversimplified explanation. I have omitted many details. If you want to dig into the technical stuff, that is
far beyond the scope of a WO post—DYOR, study the cryptography. I have tried to keep this nontechnical summary as succinct as I can.
Poll
