ZK-proof on Bitcoin

[sha420hashcollision]

The whole this situation is very similar to the one with Theranos. Theranos' succinct blood test analysis machine was producing zero-knowledge proofs that it works as intended.

As we know, Theranos' devices were capable to execute only a fraction of analysis with a high error rate. However, Theranos team was claiming that analysis is full and accurate. Is it possible that we have the same story with zero-knowledge proofs applied to blockchain verification?

When you describe your ZK-proof system, do you describe "how you want it to work" or "how it actually works"?

I was trying to make some honest challenges with my claims, but do you also agree there is not much being said as for how these proofs are being used and how they are secure within the Bitcoin framework?

Yes, I completely agree with you. They don't provide us much information about how these proofs are being used and how they are secure within the Bitcoin framework. They want us to believe their product works as intended without disclosing the full data. It's kind of ZK-proof in real life.

Anyways, I guess ZeroSync exists only as a prototype, as RobinLinus writes. I doubt this prototype is working as described in the real-life test scenario and within a reasonable time limit. I doubt the team has a clear picture of how to finalise the product. It's not clear whether we talk about a working product or about a vision of how it should look like in the future.

Second, there are many proposals which try to utilise ZK-proof system in blockchain networks. It's very common that their developers do not understand what "the complete verification" actually means. The complete list of verifications performed within "a complete verification" might not be as complete as it sounds.

Last but not least. According to RobinLinus, Zerosync relies on the third party ZK-proof library and on math which is "sound and well-established in the research community".

Cairo and ZKSTARK is very sound stuff in my own opinion, I went through some workshops on it myself. But the idea that the ZK part is thrown out makes me entirely confused, the whole point of the ZKSTARK prover is to have an efficient ZK proof. These are also transparent proofs as they require no trusted setup. But the offered STARK non-ZK proofs don't seem to offer much value, this in my opinion needs to be elaborated on heavily.

 For example if I want to prove I know  5+5=10 I can just write that out in clear text. There is no secret information, and thus why wrap the data in a non-standard prover and verification scheme? I was proposing just use a merkle tree for such a thing, for example lets say I want to prove a tx to send bob 50 sats and alice 25 sats. I can do:
sign(sha256(50 | bob))  sign(sha256(25 | alice)) and hand you these signed merkle branches, then you could use them in an extended tree of fully signed commitments that would match hashes when the input data is reproduced perfectly. Such you have a fully transparent proof of knowledge that is to be revealed eventually and you do not need some archaic verification scheme.  

[1715109642]

1715109642

[1715109642]

1715109642

[IShishkin]

But the idea that the ZK part is thrown out makes me entirely confused, the whole point of the ZKSTARK prover is to have an efficient ZK proof.

My personal opinion is that we shouldn't try to guess what is going on there, behind fancy user interfaces. In the trustless system we don't trust.

[Wind_FURY]

I am not sure how the Bitcoin community and pro full-node proponents will accept the idea of not being the ones that perform the full verification process themselves. If the idea has always been to verify and not trust, I don't see that changing. I guess it's also going to depend on how ZeroSync exactly verifies those transactions. An increase in centralization will surely not be something hardcore-bitcoiners will approve of.  

Besides the technical side, in essence, what would be the difference between a ZeroSync client and an SPV wallet/light-client? SPV wallets have existed since the early days of Bitcoin, I believe full-node proponents wouldn't mind another implementation of another kind of light-client.

[sha420hashcollision]

I am not sure how the Bitcoin community and pro full-node proponents will accept the idea of not being the ones that perform the full verification process themselves. If the idea has always been to verify and not trust, I don't see that changing. I guess it's also going to depend on how ZeroSync exactly verifies those transactions. An increase in centralization will surely not be something hardcore-bitcoiners will approve of.  

Besides the technical side, in essence, what would be the difference between a ZeroSync client and an SPV wallet/light-client? SPV wallets have existed since the early days of Bitcoin, I believe full-node proponents wouldn't mind another implementation of another kind of light-client.

SPV clients inherently trust other nodes for block contents. Another implementation of it does not seem to solve this.

[Pmalek]

SPV wallets have existed since the early days of Bitcoin, I believe full-node proponents wouldn't mind another implementation of another kind of light-client.

They wouldn't mind that others use them if they want to, sure, but I don't see why they would. Think about it, if you are using a full-node client, it means you want to have your own copy of the history that your client has verified and ticked as correct. Why would you go from there to trusting my version or a different one, as mentioned in the OP?

It could surely be an attractive option for those of us used to light-clients, but I wasn't thinking about that user base when I wrote that post you quoted. 

[baro77]

The statement is the bitcoin consensus rules, basically expressing "I know a chain of blocks that is valid and results in chain state X". The (private) witness is the chain of blocks.
The chain state contains data like the block height, the total work, etc, but also a UTXO set commitment. To get a feeling for it, see our demo https://zerosync.org/headers-chain.html

So, is it correct to say that when you'll have The Full Chain Proof, your proof will prove that you known a set of ordered blocks (the witness) which starts from the Genesis one and produce -following all BTC consensus rules- the current UTXO set you advertise (and the additional data you have mentioned - height, total work,...)?

If so  I think it's important -without of course forgetting the non-easy need for Full Chain Proof- to underline explicitly the result I have summarized above, because it would mean that, with publicly and widely audited scheme proved sound, the only way to cheat "for you" (aka for anyone advertising a current state by means of your tech) would be to be able to reconstruct a valid blockchain from the beginning, which should reassure many doubts.

Wish you to make fast progresses toward Full-Chain-Proof

[Wind_FURY]

SPV wallets have existed since the early days of Bitcoin, I believe full-node proponents wouldn't mind another implementation of another kind of light-client.

They wouldn't mind that others use them if they want to, sure, but I don't see why they would. Think about it, if you are using a full-node client, it means you want to have your own copy of the history that your client has verified and ticked as correct. Why would you go from there to trusting my version or a different one, as mentioned in the OP?

It could surely be an attractive option for those of us used to light-clients, but I wasn't thinking about that user base when I wrote that post you quoted.  

From my personal opinion, it would be because of for the sake of convenience unless the user wants to be a hardcore, power-user and run full-nodes in all of his/her computers. But I would also encourage that all users should run their own nodes, or have the experience of running one.

But to give you the context of my post, I don't think most full-node proponents would mind if a user runs a Light Client, although they would always suggest that everyone should run one to validate their own transactions, and enforce the consensus rules.

[sha420hashcollision]

That's fair, I think the issue is mainly that SPV is a faulty model that often gives end users incorrect warnings and stuff like that. For example here is a problem I ran into yesterday with Blockstream official software: https://www.reddit.com/r/BitcoinBeginners/comments/za8vqz/invalid_merkle_proof_between_two_blockstream/

Tons of other people experiencing too, and it's safe to say it is not the specific implementation causing the error given that this is developed by one of the leading development groups known to Bitcoin.

[OmegaStarScream]

Update: So apparently there has been some progress in the last few months. You can read these articles[1][2] that came out a couple of days ago.

@RobinLinus Any GitHub links we can look into? and I'm also interested in knowing the ETA of this.

Bitcoin light clients are now able to sync to the tip of the blockchain nearly instantly, thanks to a new development enabled by bitcoin startup ZeroSync and their work in zero-knowledge (ZK) proofs. Ultimately, ZeroSync seeks to enable full nodes to do the same.
--snip--

[1] https://bitcoinmagazine.com/technical/bitcoin-nodes-now-one-step-closer-to-instant-sync
[2] https://blockworks.co/news/zerosync-starkware-zero-knowledge-proofs-bitcoin

[NotATether]

Update: So apparently there has been some progress in the last few months. You can read these articles[1][2] that came out a couple of days ago.

Are there any designs on how the zero knowledge proof will be calculated? I imagine this can be eventually be added into Bitcoin Core cli and graphical with a command to generate the proof of the blockchain up to a certain height, after which the proof can be included in future Bitcoin Core builds to skip the first N (thousand) blocks.

[sha420hashcollision]

Hello! I want to say I'm very impressed with your work and I would like to lighten up the suspicion that I casted on this project a while back.
I look forward to the immense potential of these tools. Also the BitVM paper is very cool!

[OmegaStarScream]

Are there any designs on how the zero knowledge proof will be calculated? I imagine this can be eventually be added into Bitcoin Core cli and graphical with a command to generate the proof of the blockchain up to a certain height, after which the proof can be included in future Bitcoin Core builds to skip the first N (thousand) blocks.

Not as far as I know, I couldn't really find much about it but maybe BitVM whitepaper (made by Robin linus too) as mentioned above might give you an idea of what to expect (just went through it quickly so not sure)[1][2].

[1] https://www.coindesk.com/tech/2023/10/11/bitcoin-might-get-ethereum-style-smart-contracts-under-bitvm-plan/
[2] https://www.bitvm.org/