since many (~4) asked me about the zcash bug - - - earlier this year I had this convo with a zcash core dev:
zk: it's weird that kaspa is pruning past records
me: why does it need to keep 'em?
zk: the whole point of ledgers is to prove correctness of all state transitions
me: the whole point of ledgers is to provide focal points for the consensus state
zk: the whole point...
me: hmm then why did you come work in zcash? you know the Sprout->Sapling counterfeiting bug
zk: Turnstile guarantees that the counterfeit could have been very limited
me: true but you still cannot prove or even reason about correct state transitions besides the total supply cap
zk: that's actually a good point
----
the most hardcore cryptography coin is shifting away from correctness proofs to practical-enough proofs. I believe this is a step in the right+practical direction, yet the paradigm shift should not go unnoticed - -cryptography is giving way to consensus.
if you came to zcash for cryptographic integrity, reconsider. there are many good reasons to root for zcash prospering. zcash is serving a more important role than bitcoin, whose utility for the original mission is by now blurry. cryptographic integrity is/should not be one of those reasons.
----
BTW the bug should definitely have been exploited. I don't know the personal values of Taylor Hornby, and I shouldn't be required to make the effort to learn them. I only know that if I found such an exploit, it wouldn't take me more than a few minutes to tempt myself into printing a longint amount of ZEC and deciding later what to do with it.
I wouldn't necessarily use it to exit the pool immediately and corrupt the supply, I'd wait to see if some portion of the broken pool does not seem to migrate on time (probably lost funds), in which case I would not think twice before claiming the funds myself.
you could argue that no harm done, and you might be right, but then again you are here -- in zcash / in crypto -- for its consensus dynamics, the ability to coordinate interests and convictions across different trust zones around some shared asset; not for some pristine mathematical integrity.
To me the bottleneck on this "legit defi usage" is the aggregate bizdev talent in kas ecosystem. I guess we'll be able to assess how we score on that once Tocatta launches with the necessary primitives and features.
(And since we can't know for sure, and while others are making hopefully successful efforts to attract existing defi activity from other chains, I am attempting a parallel trajectory to bootstrap coordination markets on kaspa. Hopefully at least one of these efforts succeeds.)
Sure tho I consider based apps a natural extension and usage of (what you called pure) covenants: if you impl covenants seriously rather than thru op_cat workarounds, you unlock their programmability potential by extending the txn commitment scheme to allow the covenants to govern based logic. This extension is straightforward, requires no research / theoretical novelty, and is highly useful even if it's the end form of programmability on the layer (ie no further syncompo/vprogs solutions ever develop).
---
@KaspaSilver There's nothing wrong with implementing an EVM L2 as an interim solution, but this requires an interim agenda. If in contrast a project aims to become the main gateway for builders on our money network, then our hard-fought efforts - and the prices we paid - for decentralized fairlaunch go to waste. Such a takeover is far from inevitable, and fwiw I know of no other crypto project that had to cope with independent L2 attempts that early in its growth efforts (to be clear I never attribute to malice that!).
To spell it out further: If an L2 has an interim agenda, or at least focuses on its own bizdev rather than general builder devrel -- ie, it uses L2 tech as a <business> enabler rather than as an <infra> value prop -- then the risk of fragmentation is restricted to liquidity and standards, which is tolerable and solvable down the road. I wouldnt endorse it but I would get it, and I'd respect those who dont give an f about my endorsement
The upcoming upgrade was chosen without regards to vprogs, and no meaningful effort was made to optimize it for vprogs (definitely nothing delaying Tocatta by more than a few days).
Tocatta is a principled implementation of bitcoin-originating covenants which, if ever implemented in bitcoin, would use the op_cat workaround. It is the default method to introduce programmability into a thin verification-oriented L1 to preserve its decentralized lean value prop.
vprogs are outside core’s focus precisely because we are optimizing for usability over theoretical superiority.
I hope this helps you and grok update your premise.
(BTW counterexample to your claim about inevitability of fragmentation: Solana)
@eliottmea@BankQuote "pulls" liquidity or RFQs?
I'm highly skeptic one can prove manipulation (then justify slashing) just based on quotes. more likely to hit an impossibility due to manipulations being indistinguishabe from white noise + network latency.
any chance u reached a formal model/claim?
@nic_carter This is a very interesting use case of real-time decentralization, ie the ability to sample the honest majority in real time - - miners running a decentralized chancery (I suppose using SLMs) to govern stablecoin transfers
(https://t.co/woM0WlLVqW)
Kaspa is real-time bitcoin, solving scalability is great but not the core value prop.
Real-time bitcoin means achieving in a few seconds the same security guarantees that nakamoto consensus / bitcoin achieves after an hour; decentralizing each consensus round rather than chain quality achieved through a coarse aggregate of rounds.
A clean definition anchor for real-time decentralization (RTD): The ability to sample the honest majority in real-time.
(Note that even fast leaderless VRF-based proof-of-stake cant sample honestly bc the selected nodes get to choose the content of their blocks after they've been selected; pos=select then write, pow=write then select)
--
RTD affects: txn confirmation, censorship resistance, secure oracle finality, MEV resistance.
Eg censorship resistance, bitcoin is the most censorship resistant chain, but if 60% of the miners are censoring you (point in reference: OFAC abiding tornado censoring eth miners), your txn will pend for 30-40 minutes. For shady business payments that's not prohibitive, but for a real economy, for an asset aspiring to be at least a king of collateral even if not an MoE, this is unacceptable, esp under economic stress.
Beyond censorship, all things finance benefit tremendously from pow density, from sampling the majority in real-time in a secure and honest manner.
I wont get into MEV resistance now, but having a "conscious" stream of oracle attestations (not price oracles) finalized in real-time qualitatively upgrades the ability to encode informed risk, collateral, liquidity management, which is the lifeblood of defi.
In context of conf times, increasing from 1 to 10bps saturates the latency optimization. But for pow density we need dozens of blocks per second, with the endgame of 100 bps: Under 10bps a 37% attacker can fake the majority signal with probability 12%. With 100bps this drops to 0.3%. Today Kaspa can't accelerate to >10bps w/o harming conf times, but DAGKNIGHT will be implemented hopefully by Q3 at least on testnet, by which we will push for 25-40bps.
The cherry on top: RTD also implies netsplit resistance, as per the partial synchrony framework.
WWIII cyberwar resistance. Hypothetically speaking ofc.
(elaborated- https://t.co/o8vKa7gBwm)
Appreciate you taking the time to read and flesh out the coordination markets thesis for everyone, myself included. Learning from these nuances. @hus_qy@Radical_Ed_Bad
One linguistic note - the word <cooperation> hints at an attempt to "altruise" human nature, whereas <coordination> better connotes acting together in self-interest without assuming trust, but yes assuming shared missions/goals; hence the term coordination games from competitive game theory
@Grayscale@realvijayk arigato gozaimasu!
if Kaspa army showed up here, think how they'll show up when you provide a KAS digital asset..
by mid june Kaspa OP_CAT++ Bitcoin. worth the attention _/\_
@oneforonehaha note there exists a documentation website for programmability in Kaspa, the temporary link was published by izio a few weeks ago in the pub rnd channel https://t.co/gqLlrxk5Yn
I presume it will migrate/redirect to a different URL soon.
Please bombard core with questions and clarifications needed until they are sick of you and have no choice but to spell it all out fully clearly legibly onchain
1) Txn activity requires either luck or spelling out usecases that can uniquely be built on or attract builders to kas. Merely being EVM compatible - and then replicating the EVM defi play and calling it "a usecase" - was the strategy of many EVM GHOSTchains.
2) With AI coding, programming languages and VM frameworks are no longer significant moats. In fact, being Rust friendly is more important here than being EVM friendly, since coding agents work meaningfully better in Rust than in other languages due to its strict compiler which forces correctness, sharper debugging loop for the agent.
3) My stance is mostly unrelated to vprogs. Vprogs too is a framework, not an acronym of "usecase", tho at least it is corresponding with the future of crypto rather than its past. https://t.co/bm5LdVIm4e
0) Launching an interim EVM solution requires having an interim agenda.
Welcome to the Ethereum Economic Zone (EEZ), a framework for synchronously composable rollups.
What does that mean?
One deployment. Shared liquidity. Single transactions across L1 & L2. Identity verified anywhere. Smart wallets connected everywhere. No additional trust assumptions.
This means L2s that are as credibly neutral, economically aligned, and publicly governed as the base layer itself.
EEZ furthers Ethereum as the leading decentralized economy.