Re: [bitcoin-dev] Coins: A trustless sidechain protocol

Good morning ZmnSCPxj, Thank you for your detailed feedback! Two topics: ## Lightning vs Sidechains Why an either-or-solution, if we can connect sidechains via the LN to get the best of both worlds? The LN works exceptionally great under the following conditions: - you're always online - you

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

ld only use honest majority > assumption where the scope is global, where it is very hard and very > expensive to obtain majority. > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Sunday, January 12, 2020 6:54 PM,

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

ak concretely about your proposal, you assume >>> honest majority of validators. But in your system the validators come from >>> locking of stake on Bitcoin chain by nodes that are interested in a >>> particular sidechain. If you put this model on a niche chain where on

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

considered as a Bitcoin sidechain, but you > > > > > > will be, from certain point of view, indistinguishable from any > > > > > > other altcoin. At the level of my current understanding, the only > > > > > > interesting si

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

system seems to be very fragile, >>>>> unless I have missed something. When I think about sidechains, I expect >>>>> that it should be possible to create a niche chain which is used by few >>>>> participants while the security of the chain is somehow guaranteed from

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

Goog morning ZmnSCPxj, > Unless of course you propose to have the sidechain issue its own coin, in > which case it is not much more than an altcoin. Okay, call it an altcoin consensus mechanism. Because sidechains do have to issue their own coins. Still, I am not proposing independent

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

> because all users must process all transactions within the blockchain Reality shows, that's wrong. Bitcoin's security doesn't require verification to scale quadratically with users. Since the whitepaper, Satoshi was explicit about that phenomena. We can discuss nuances, yet it's overall

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

Good morning ZmnSCPxj, > > > because all users must process all transactions within the blockchain > > > > Reality shows, that's wrong. Bitcoin's security doesn't require > > verification to scale quadratically with users. Since the whitepaper, > > Satoshi was explicit about that phenomena. We

Re: [bitcoin-dev] Compressed block headers

Hi, not sure if headergolf was mentioned yet. It's about very similar ideas: https://github.com/alecalve/headergolf ‐‐‐ Original Message ‐‐‐ On Friday, May 8, 2020 2:31 PM, Will Clark via bitcoin-dev wrote: > Hello list, > > I would like to propose a compressed block header

[bitcoin-dev] Implementing Blake3 in Bitcoin Script

Good morning mailing list, We implemented a hash function in Bitcoin Script to verify Merkle inclusion proofs in the BitVM. This allows the VM to have sheer infinite memory, which doesn't have to get represented in expensive bit commitments. The following transaction demonstrates on-chain a

[bitcoin-dev] BitVM: Compute Anything on Bitcoin

Abstract. BitVM is a computing paradigm to express Turing-complete Bitcoin contracts. This requires no changes to the network’s consensus rules. Rather than executing computations on Bitcoin, they are merely verified, similarly to optimistic rollups. A prover makes a claim that a given function

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

Hi Michael, Thank you for your reply. You wrote: > I have a better (and safer) way forward which is to continue to build out use > cases of CTV, convince the community it is the best tool for the job > (whatever use case(s) that is), compare it to other existing covenant > enabling proposals

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

Dear Michael, Firstly, I think it is great that you do share enthusiasm for "vaults, eltoo constructions, payment pools etc". Many people see covenants (or covenant-like features) as one of the most important upgrades currently in the pipe line because it enables so many important use cases

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

> https://bitcoin.stackexchange.com/questions/tagged/bip119-checktemplateverify > > -- > Michael Folkson > Email: michaelfolkson at [protonmail.com](http://protonmail.com/) > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > &

[bitcoin-dev] Nondeterministic Programming and Hints in Bitcoin Script

TL;DR: Bitcoin Script supports a lot more opcodes than previously assumed. We just have to apply nondeterministic programming, which is a concept from ZKP circuit design. Good morning Mailinglist, the Taproot update dropped the restrictions for script sizes, so in theory a TX can now have a

[bitcoin-dev] Some Day Peg: A crazy two-way peg bridging BTC to other chains Raw

Hi all, Here's an interesting but not-so-serious attempt to implement a two-way peg in Bitcoin Script. https://gist.github.com/RobinLinus/1102fce176f3b5466180addac5d26313 -Robin

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

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

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

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).