I meant that there could be implementation bugs as in any cryptographic software. And it will take a lot of work to harden it.



We have not really build a new verifier, but only apply existing open source tools. We use the Giza verifier, which is mostly the Winterfell STARK library. What we have added is a translation of that verifier to Cairo.


The best of it all is that you don't have to use it. It is fully optional. It can get rolled out for low value use cases first and grow over time into a hardened library that makes sense for high-value use cases.

That is also a misunderstanding. It all depends on the verifier. If the verifier implementation is correct then the prover cannot fool the verifier even the slightest bit. That is the magic of proof systems. The invention is that there is no trust required. The prover can only ever prove a valid chainstate. Otherwise, it isn't a valid proof.

Of course, you can doubt our implementation. And we openly state ourselves that this is all still prototype-grade. It's still a long way to get it production-ready, but the underlying math is sound and well-established in the research community. STARKs don't even require any novel cryptographic assumptions like many other ZKP systems. They rely only on collision-resistant hash functions*.



* In theory. Actually, we're using a STARK-friendly hash function for proof recursion, e.g. Pedersen hash. However, this also relies on nothing more fancy than assuming that dlogs are hard.

That is a fundamental misunderstanding. STARKs are transparent which means there is no trusted setup. What you mean is SNARKs and not wanting to trust a 'consortium' is exactly why STARKs were invented.

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

Hi, I am the project lead at ZeroSync. Happy to see our work discussed on bitcointalk. Would like to clarify a few points mentioned here:  

- We are using STARKs, which is a form of zero-knowledge proof that requires no trusted setup. It is a *transparent* ZKP.
- "Zero-knowledge" is indeed misleading in a way. This technology was invented for privacy reasons but it turned out to be also very useful to compress a computation. To be precise, actually it doesn't even use the zero-knowledge property really. Nevertheless it became an industry standard to call this tech ZKPs. We use it just because it is a *succinct* proof.
- Using ZeroSync requires no global consensus. Every user can decide individually if they want to sync using a proof or the conventional way. You can even zerosync Bitcoin Core without any code modifications: Use an external tool to verify a UTXO set and then copy it into your chainstate folder.
- ZeroSync is not a company but a Swiss nonprofit creating FOSS software.
- ZeroSync is not just a chain proof but creates a toolkit for Bitcoin developers to apply ZKPs to their own products and services.

On our project website https://zerosync.org you can find more details.


Happy to answer any questions you have.

The point of using your email is that basically everyone has one and it is easy for them to remember. Of course, you can use a random ID, but that's hard to remember.

Here is an example how you could use it in an interesting way: https://github.com/coins/bitcoin-scripts/blob/master/op-codeseparator.md

We're developing the contract in Solidity. That makes it compatible with Ethereum, BSC, but also RSK.


You are right. No third party is required to execute a swap. The client is only doing the client-side validation of the token protocol for you and compiles your token transactions. In theory, you could do that in e.g. Electrum, too. If you're curious about the details, here's a writeup on swaps.

Here's a detailed writeup of the trustless 2-way peg. For now, it is just a trusted peg containing $480 USDt inital "playmoney", or "bug bounty" if you want. We want to replace it ASAP with the trustless peg.



You can download and run the client just by clicking on the html file. The server is not required to swap tokens. In theory, I could paste an order here into this thread and then anyone could take it. The purpose of the servers is only to bundle liquidity.

Thanks a lot for your feedback because it was motivating.

There is already a "reckless" mainnet version and there is already a $5 offer which you can buy. It's even discounted as it wasn't changed since bitcoin was at $42000. You are very welcome to execute the first real world order on our DEX! :-)


This inspired me to work out the details of the 2-way peg protocol. Next step is to implement the peg-out in Solidity. Then you can trade every asset on every EVM-like platform trustlessly against BTC. This includes all assets on Binance Smart Chain, too.

Here is a more technical writeup of this project. Maybe it would have been better to start the thread with this summary instead of dumping the prototype on you without much background info  

Using some email as salt is important for security...


You can monitor all requests in the network tab of the developer tools in your browser.


Yes, you can find the source code on Github. You can run it locally simply by downloading the client and clicking on the index.html.

@BlackHatCoiner and @bitmover,  I updated the signup page to be more clear about the email being used as salt.

Do you think this is better, or do you consider warpwallet with email+pw a bad idea in general?

I personally like the idea because users are very familiar with such logins.

You're right, it looks like we are communicating badly here. Your email is used only locally on your machine as salt for generating keys with a WarpWallet. It is basically just a random string that is unique per user which guarantees attackers using bruteforce have to target each user separately. We use the email address because it is a salt that is easy to remember and makes the login feel familiar to regular web services.

Of course, you can use the DEX with any random email address if you want.

Today we are releasing an alpha version of Bitcoin DEX - a decentralised bitcoin exchange based on non-interactive atomic swaps. It allows you to swap bitcoins for stablecoins with a single bitcoin transaction, and without having to know your counterparty upfront. You can find the FAQ here. Here are some screenshots.
Your feedback is very welcome!

PS: you can use this faucet to receive some testnet Bitcoins to buy testnet Dollars on the DEX. Or you can receive testnet dollars by posting your address in this thread. Or you can receive testnet dollars in our Telegram group.


Edit: Here's a writeup of the protocol.

For fun I implemented OP_MUL using OP_ADD. You can find the code here on Github.

Feedback very appreciated!

And I have a question: do you guys know any good source for advanced bitcoin scripts? Is there something like a library for scripts?

I have been working on a protocol for stateless nodes. It is a simplified version of Utreexo. It does not require dedicated bridge nodes - only regular nodes serving regular blocks. Furthermore, nano nodes can serve each other. The protocol works on top of today's bitcoin. No consensus changes are required. All data structures emerge from the existing blockchain structure.

If there is at least one honest node available, the protocol provides full node security by downloading just about 150 MB.

Here is a straw-man proposal demonstrating the basic idea.

The detailed description can be found here.

Feedback is very welcome. Thanks for taking your time!

Thanks! Yes, simply copy the file into your project. It has no dependencies and is fully self-contained.

Indeed, it is a wrapper for Blockstream's Esplora API. I am not sure about their rate limits, though. Will try to find it out.

Also, publishing it on npm is a good idea!

A flexible backend for browser-based Bitcoin clients. The in-official JavaScript library for Blockstream's Esplora API.
Find the code and a demo on Github

Feedback highly appreciated!

Hi all,

I've been working on a sidechain protocol with no trusted third party. You can find the whitepaper here.

Abstract. Coins is a Bitcoin extension designed for payments at scale.  We propose an efficient solution to the double-spending problem using a bitcoin-backed proof-of-stake.  Validators vote on sidechain blocks with one-time  signatures,  forming  a record that cannot be changed without destroying their collateral.  Every user can become a validator by locking bitcoins.  One-time signatures guarantee that validators lose their  stake  for  publishing  conflicting  histories.   Checkpoints  can  be  additionally secured with a bitcoin-backed proof-of-burn.  Assuming a rational majority of validators, the sidechain provides safety and liveness.  The sidechain’s footprint within bitcoin’s blockchain is minimal.  Spawning multiple, independent instances scales horizontally.

Your Feedback is highly appreciated!

Thanks!