Re: [bitcoin-dev] ZeroSync: Introducing Validity Proofs to Bitcoin

[Robin Linus via bitcoin-dev]

Hi Weiji,

> Could you please expand more on how you plan to "implement a SNARK verifier 
> on Bitcoin’s base layer"?
First, I should clarify that I see this as a long-term option, which will take 
years. If Simplicity gets activated, we could use it to implement a SNARK 
verifier on Bitcoin's base layer. But for now, we just plan to experiment with 
Simplicity on the Liquid sidechain when it gets activated.


> For your information, I happen to be the one proposing a new opcode OP_ZKP to 
> enable the Bitcoin network to verify zkp proofs. My proposal requires a soft 
> fork. You may find more information from the email archive here: 
> https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg12601.html
>  
> 
I've seen it; however, I suppose it is hard to establish consensus over some 
particular kind of op_snark_verify opcode because there are so many competing 
proof systems with different trade-offs. For example, STARKs are great for a 
chain state proof as they are scalable and allow for processing huge circuits; 
however, I would not favor STARKs for an on-chain verifier because there are 
other proof systems, such as Plonky2, with much smaller proof sizes.

A nice thing about SNARK verifiers is that once we have any verifier, we can 
use it to wrap other proofs. E.g., we could "compress" the size of a STARK by 
verifying it in a Plonky2 proof.
Still, Simplicity offers much more flexibility and allows to update verifiers 
as the research advances.


> We might be tackling similar issues and probably could benefit from each 
> other. 

Sounds good! Please join our Telegram group, if you would like to chat about 
SNARKs on Bitcoin https://t.me/zerosync_chat 



Cheers,
Robin ___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] ZeroSync: Introducing Validity Proofs to Bitcoin

[Weiji Guo via bitcoin-dev]

Hi Robin,

Could you please expand more on how you plan to "implement a SNARK verifier
on Bitcoin’s base layer"?

For your information, I happen to be the one proposing a new opcode OP_ZKP
to enable the Bitcoin network to verify zkp proofs. My proposal requires a
soft fork. You may find more information from the email archive here:
https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg12601.html

We might be tackling similar issues and probably could benefit from each
other.

Thanks,
Weiji

On Fri, May 12, 2023 at 9:16 PM Robin Linus via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Today we are publishing a summary of our research on "ZeroSync:
> Introducing Validity Proofs to Bitcoin".
>
>
> Here's the preface:
>
> *We introduce ZeroSync, the first-ever proof system addressing Bitcoin’s
> scalability challenges with Succinct Non-Interactive Argument of Knowledge
> (SNARKs). ZeroSync compresses the entire Bitcoin blockchain into a compact
> proof of validity, enabling instant verification and unlocking various
> innovative applications. We discuss our prototype implementation of a chain
> state proof, utilizing the Cairo language, Utreexo, and recursive STARKs.
> Our work enables diverse applications, including quick bootstrapping of
> full nodes, trustless light clients, enhanced Lightning Network privacy,
> and secure cross-chain bridges. Chain state proofs require no consensus
> changes, which is crucial as forks in Bitcoin are challenging to implement
> and achieve consensus for. Despite the existing bottleneck of prover
> performance, we present a range of optimization strategies and demonstrate
> the practicality of generating a complete chain state proof. *
> *Finally, we introduce zkCoins, a client-side validation protocol combined
> with zeroknowledge SNARKs, drastically improving privacy and throughput of
> token transactions. In combination with future Bitcoin features, such as
> Simplicity, zkCoins also enables private and more scalable BTC
> transactions. *
> *The groundbreaking compression capabilities of SNARKs initiated a
> paradigm shift in cryptocurrency design, and ZeroSync is pioneering their
> application to Bitcoin.*
>
>
> You can find the full paper here: https://zerosync.org/zerosync.pdf
> Happy to receive any comments and answer any questions the bitcoin dev
> community may have about the paper!
>
>
>
> Best regards,
> Robin Linus
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] ZeroSync: Introducing Validity Proofs to Bitcoin

[Robin Linus via bitcoin-dev]

Hi all,

Today we are publishing a summary of our research on "ZeroSync: Introducing 
Validity Proofs to Bitcoin".


Here's the preface:

We introduce ZeroSync, the first-ever proof system addressing Bitcoin’s 
scalability challenges with Succinct Non-Interactive Argument of Knowledge 
(SNARKs). ZeroSync compresses the entire Bitcoin blockchain into a compact 
proof of validity, enabling instant verification and unlocking various 
innovative applications. We discuss our prototype implementation of a chain 
state proof, utilizing the Cairo language, Utreexo, and recursive STARKs. Our 
work enables diverse applications, including quick bootstrapping of full nodes, 
trustless light clients, enhanced Lightning Network privacy, and secure 
cross-chain bridges. Chain state proofs require no consensus changes, which is 
crucial as forks in Bitcoin are challenging to implement and achieve consensus 
for. Despite the existing bottleneck of prover performance, we present a range 
of optimization strategies and demonstrate the practicality of generating a 
complete chain state proof. 
Finally, we introduce zkCoins, a client-side validation protocol combined with 
zeroknowledge SNARKs, drastically improving privacy and throughput of token 
transactions. In combination with future Bitcoin features, such as Simplicity, 
zkCoins also enables private and more scalable BTC transactions. 
The groundbreaking compression capabilities of SNARKs initiated a paradigm 
shift in cryptocurrency design, and ZeroSync is pioneering their application to 
Bitcoin.


You can find the full paper here: https://zerosync.org/zerosync.pdf 

Happy to receive any comments and answer any questions the bitcoin dev 
community may have about the paper!



Best regards,
Robin Linus___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Jaroslaw via bitcoin-dev]

W dniu 2023-05-11 13:57:11 użytkownik Keagan McClelland via bitcoin-dev 
 napisał:

> The current fees we are experiencing are still significantly lower than they 
> need to be if Bitcoin is going to survive in a post-subsidy era. If our 
> layered protocols can't survive the current fee environment, the answer is to 
> fix the layered protocols.


I also believe that this discussion should be expanded to the problem of 
Bitcoin's survival in the post-subsidy era, because it's very related, i.e. 
also directly related to the high transaction fees. The only difference is that 
the current $30 fee situation is probably temporary, and the future $40 
(today's price tag) fee situation in post-subsidy era will be hopeless for 
change other than to reduce the difficulty of the network and hence its 
security and the marketcap/price in the end of day.

Because if the current network hashrate (current level of security) would drop 
e.g. to half of what it was in the past - the Store-of-Value feature simply 
collapse, while it's one of the most important (if not: the most important) 
long term feature of Bitcoin and as such advertised...
If you really care about SoV - you can't accept network security regression. 
Period.

I am a committed supporter of the free market. And Bitcoin is not the e-mail 
system, where sending is free and therefore spam which costs nothing to the 
sender - becomes a problem. In Bitcoin, every transaction costs - and in such a 
situation, distinguishing paid transactions into the good ones and the bad ones 
- would be a mistake and contradict the idea of the free market.

We should not interfere where the free market intervenes: the same way how 
small transfers are migrating to LN, the same way "non-economic", low value 
informations will migrate to Layer2 (RGB, Taro or maybe something else yet)

But, we should intervene there, where there is no free market. And I am not 
alone in alarming that there is such a place in Bitcoin.
In the post-subsidy era There Is No Free Market between: active users 
(overtaxed) and pasive users (free riders).

One of possible (very conservative) option to introduce free market there - is 
to delay halving in case of 4 years network difficulty regression situation.
Such a long-term regression of network difficulty means nothing else that 
transaction revenue from active users is not able to fund current network 
security anymore for both active and passive users. Delaying of halving is 
simply: not introducing additional more damage to the network security (really 
conservative approach)
Another option is: demurrage (but I'm not very sure it will work fine, at least 
before "hyperbitcoinzation")

Again, from my almost 50yo experience:
Bitcoin network difficulty can be more-less constant or can be slightly 
increasing (both options are "good for Bitcoin") but we should do our best - to 
avoid the network security regression.
I did.


Regards
Jaroslaw

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev