0 sats \ 0 replies \ @lightcoin OP 27 Mar \ parent \ on: BitVM 2: Permissionless Verification on Bitcoin [Draft writeup] bitcoin
Bridges/sidechains may not be the only applications to benefit from a permissionless challenger protocol. Since this change can be utilized by any BitVM application I think it is worth the version bump.
The thread does say that if the payment is to a CASP then the sender will need to KYC, which suggests to me that if the merchant is using a custodial point of sale system hosted by a third party (like BitPay) then all customers will need to KYC.
https://twitter.com/paddi_hansen/status/1771929875894399367
I actually think that optimistic ZK rollups are the most promising bitcoin scaling solution
Rollups on their own are limited in throughput due to the block size limit on their parent chain. On bitcoin this is a theoretical max throughput of a few hundred thousand tx per 4 million WU block, which translates to about 50 tps. Compare this to Visa which does 10s of thousands of tps during peak load and you'll see we have a big gap to close. I think more likely is that rollups will work together with validia chains and payment channel networks (such as Lightning) to reach the level of scale required -- but this is not without some security tradeoffs. See also: https://lightco.in/2023/12/13/lightning-validia-rollups/
We will no longer be able to say "bitcoin, not crypto", because crypto garbage will run on top of bitcoin.
That ship sailed over a decade ago when people started building colored coins on bitcoin.
Can we do optimistic ZK rollups solution on bitcoin that does fast, cheap, private and trustless transactions for the world and it explicitly does not do EVM, tokens, NFTs?
sure, devs can design a rollup with whatever capabilities or limitations that they want. although as we've seen with inscriptions and colored coins on L1 it is probably impossible to prevent people from building embedded consensus protocols aka "metaprotocols" or "client side verification" protocols if they have some way of storing arbitrary data in transactions.
If they use proof of work then it would be called POW
Using proof of work for issuance of the staking asset is a separate process from staking itself.
Why would you burn precious BTCs?
As a provably-fair way of issuing the staking asset.
Wrapping Bitcoin on a proof of stake protocol is a big attack to Bitcoin and will prob fail.
Based on your comments so far it seems that you don't really understand what you're talking about, so maybe save your opinions and confident predictions of failure for a topic you're better educated on.
There are many models for generating staking assets. They could even be generated using proof of work or burning BTC. As the post points out BTC itself could be the staking asset. Anyways there's not really a "network" to "sustain" here as such, the staking asset is just being used as a Sybil prevention and penalty enforcement mechanism for the bridge protocol.
BitVM bridge research. Posted one of my findings yesterday:
#423955
interest rates are set by the market, I don't think it's worthwhile estimating what they might in this early research stage. but if someone wanted to actually implement this then they probably would want to do a market analysis to see what kind of rates would actually be competitive and economically viable.
The first 8 minutes or so of this talk I gave at btc++ last year explains the motivation for working on bridges: https://yewtu.be/watch?v=M40yzuv6DNY
With that context in mind, Bitstake is a decentralized (and potentially more secure) alternative to the federated/permissioned bridges that exist today. If we accept that the motivation for bridges is sound, then it follows that finding a design that is more decentralized and secure is a worthwhile thing to work on.
someone who wants to earn fees from operating the bridge (and chain if the staker set is re-used for operating the chain)
nowadays there is a huge industry of professional stakers for all kinds of different protocols, could draw from that pool of experienced operators or recruit new ones.
"Bitcoin's first" technically true
it's not the first, it hasn't even launched yet. if it launches on mainnet first then they can claim first.
3759 sats \ 2 replies \ @lightcoin 7 Feb \ parent \ on: Introducing Citrea: Bitcoin’s First ZK Rollup bitcoin
Assuming the details in the post and docs accurately describe what the final product will look like, the main difference is that Citrea is verified optimistically using a BitVM program rather than an onchain smart contract, and as such is limited to at-best a 1-of-n security model (where
n
is a permissioned group of arbitrary size) rather than a single honest party security model (as in optimistic rollups, where the single honest party could be anyone, and it is assumed that they can get a fault proof transaction confirmed during a challenge period) or a trustless security model (as in validity rollups, where all rollup txs are cryptographically verified). That said, the developers of almost all rollups on other chains have chosen to ultimately rely on some kind of multisig for security, because their smart contracts can be upgraded to any arbitrary new code using a multisig (often a "committee" of trusted community members, often with no time delay). So assuming this rollup does not choose to insert some trusted multisig into the governance model, that could also be a difference.Other than those differences the rollup works the same as other zkEVM rollups: it is EVM compatible, it posts its state data to a parent chain (in this case bitcoin), and it inherits the full double-spend resistance and data availability guarantees of bitcoin.
they do better than 2x
https://bitcoinrollups.org/#section-4-scaling-improvements
CTV was initially controversial because the developer suggested using speedy trial and pushed with his ego when the community pushed back on the idea. However, the activation method the developers desires is not a prerequisite for its implementation. We very well can soft fork CTV using an activation method that is against the developer's wishes because it is open source code after all.
We should delineate here. There were really two main points in time where CTV was (implicitly) rejected: once when Jeremy tried to get it into Bitcoin Core, and then again when he announced he would publish an alt client with CTV activation parameters implemented.
In the second instance, CTV was rejected not because of speedy trial (Taproot used speedy trial and did not get that same pushback) it was rejected because there were people either mistakenly or intentionally misrepresenting it, and that caused other people to be against its activation by any means.[1][2] In that context, speedy trial was just fuel on the fire and made it a hard no for even more people.
But that activation attempt only came after months of the CTV PR languishing in the Bitcoin Core repo. It was ready to be merged but the maintainers would not merge it. So prior to the outcry by misinformed, non-technically savvy plebs, we have to go back to the root of why was CTV not merged into Bitcoin Core in the first place. Why did Jeremy feel like he had to push for a speedy trial using his own alt client to get CTV activated? I haven't seen a good post mortem on this. I think we need to address whatever was the root cause blocking rough consensus among core devs for merging into Bitcoin Core before we can discuss new activation parameters.
Next time, lets do a deep dive into the technical differences between APO and CTV.
good article, it got me thinking!
--
it's a bit of chicken and egg problem. users won't use lightning without "apps with lightning". but app developers won't integrate lightning into their apps unless it's something users want. so the utility has to be clear to users, and the ux has to be better than fiat. that brings me to my next point...
--
what's the onboarding story for an app that integrates breez sdk? do users of the app already need a lightning wallet? and/or will the users need to create a new wallet, back up a seed phrase, figure out how to buy bitcoin and transfer it into the app (which may involve a whole other separate user journey), etc? imo onboarding and key management are critical to get right to cross the chasm from highly motivated ideological bitcoiners to "mainstream" users who have a Job To Be Done and bitcoin/lightning just happens to be the best tool for the job. if the ux is subpar compared to fiat, developers are just going to go with fiat.
--
I think the developer-first approach is directionally correct. of course it's important to have wallet software, but once we have that, the next important step is distribution. and using third-party applications as the distribution channel makes a lot of sense. paypal became successful because of its integrations with applications (crucially, ebay to start). I think bitcoin/LN for payments will succeed similarly. at a high level there are two paths you could take here: integrating with existing applications (which involves BD/marketing to existing merchants and product dev teams) and integrating with new applications (which involves capturing mindshare of product teams/devs who are at the beginning of their product building journey). since your article seems to be mostly about the latter I'll focus here.
It may be instructive to see how other developer-oriented technologies that we see everywhere took root. take google analytics for example. as an anti-privacy tool, I don't like it, but it is everywhere so it's at least worth thinking about how they were able to achieve that scale and take some lessons from that. part of it was partnerships with website building companies. "hey website builder, your clients want to track their website performance? use google analytics". part of it was partnerships with online marketing classes. "hey marketer, want to track your impressions and clicks? use google analytics" ... which led the marketers to either plug it into the stack themselves or ask a dev on their team to do it for them. part of it was developer training. "ok and on step 3 of How To Build Your First App we're going to add in some analytics so we can track user metrics, let's integrate google analytics." these distribution channels got GA in front of many many people for whom GA solved a problem, and successful conversions through those channels over many years compounded to the point where GA is now nearly ubiquitous.
with a similar strategy of getting bitcoin/LN in front of many developers (or entrepreneurs) who need a payment solution, maybe we can get bitcoin/LN payments to be a ubiquitous part of the payments stack. and maybe we don't even need the application to use bitcoin/LN exclusively for payments, maybe bitcoin/LN is just one option alongside fiat (stripe, square, paypal, where you at?). but bitcoin/LN is the option that should be promoted to users for whom bitcoin/LN uniquely solves a problem, whether that's no KYC (depending on the onramp used), or privacy (ish), or micropayments, or no chargebacks, or censorship-resistance, or global accessibility, etc.
there are a few components to it: you need to know the type of script you used to create the address, you need to know the keys and policies involved in the script, and you need to use a wallet that can build the script and sign transactions for it.
take a 2-of-3 p2sh multisig for example. if you created this script with electrum, you went through a process to set up the multisig. electrum has a gui that walks you through the process, it asks you what the signing policy is and what the xpubs of the signers are, and from that it can create the wallet, derive all of the addresses, and build txs to sign. so in the case of this multisig wallet you need to know that it's 2-of-3, p2sh, and the specific 3 xpubs used. with this information you should be able to recreate the wallet in any application that supports creating p2sh multisig wallets.
for more advanced scripts, you might need to know/backup more information related to the spending conditions. and if you lose that information, then you lose access to your funds.