pull down to refresh
422 sats \ 0 replies \ @conduition 6 Jul \ on: What the heck is Spark? lightning
I helped Spark's devs design their protocol under contract. I can confirm OP's description is roughly accurate, although there's another layer of complexity on top of the basic statechains described here.
A statechain UTXO by itself is not super ergonomic because you have to transfer all of it or none of it. Spark wanted to design a system where you can subdivide statecoins up into smaller units using a tree of off-chain transactions, by sharding the keys that control the locked UTXO. More info here. The cryptography behind it is really cool, but not described very thoroughly in the docs. Maybe they're reworking the protocol since I left? IDK
Thanks! Check out the landing page of my website, https://conduition.io - I have my contact details posted there
ZK STARKs are very powerful and will certainly be useful for off-chain bitcoin smart contracts, rollups, etc, but STARKs are very complicated and inefficient.
An average bitcoin dev could probably implement almost any hash-based signature algorithm in a day or two. Contrastingly, implementing a STARK prover/verifier seems to demand teams of people with years of expert knowledge in the domain. Even established STARK software like Winterfell suffer from awful usability/ergonomics. Read their README and examples, and you'll see what I mean.
I don't think we should build on-chain bitcoin security standards based on such things without a simple easy-to-use library to depend on, like libsecp256k1 is today. Perhaps there will be a more stable and usable STARK library in the future but so far I haven't found any. The closest is RISC0, but AFAICT it's bugged for secp256k1 usage, and they're not fixing it.
@mega_dreamer is there anywhere I can contact you directly? I'd rather not broadcast details of my setup publicly
Thanks and good point. I'm new to this and wasn't expecting mercury to unilaterally publish without asking me first. My mistake was in not being explicit about timeline with them, and also Tom admitted that he thought my vulnerability report (given over a private link to my website) was publicly accessible on my blog (it wasn't). That's why mercury rushed to publish fixes ASAP.
Miscommunication all around and a good learning experience for next time in a low-stakes environment
Very nice work. Like some others have commented, I was unable to log in with lightning-supported browser extensions, so i had to use username/password. When I clicked on a market and tried to buy shares in an outcome, i received a small red popup which said "Prediction is not valid", and the market card was stuck in a "Please wait..." loading state. Trying again I got the same thing.
Bug reports aside, I'm obliged to remind viewers that this market is centralized. The Predyx operators seem to be the only entity who ultimately decides how to settle all predicted events, and deciding who gets paid. They also custody your money.
For now that's OK because there aren't many alternatives, but please be careful and be aware that decentralized options will exist in the future which let betters spread trust out among many oracles, without any custody risk.
Our first covenant-specic opcode proposal, OP_CheckTemplateVerify — or “CTV” as it’s commonly referred to — aims to create a very specific, restricted, covenant opcode by doing exactly one thing: hashing the spending transaction in a specified way that does not commit to the input UTXOs, and checking the resulting digest against the top stack element. This allows the spending transaction to be constrained in advance, without making true recursive covenant restrictions possible.
I had never really understood OP_CTV before reading this paragraph. Bravo
Certainly there is no publicly released client software configured for mainnet
The mercury client code can be configured to use mainnet statecoins by simply setting
network = "bitcoin" in the client's Settings.toml file, so it's not that hard to set up. In fact, to demonstrate the vulns to mercury I double-spent some mainnet coins after ostensibly "transferring" the statecoin UTXO to Tom. But it would take a conscious effort to do that, in spite of blatant warnings to the contrary.Really I have no idea if there are any mainnet users, but I find it unlikely. See tom's post below for more info
Well, due to the nature of mercury, it's impossible to know. The key server is a blind-signer which is agnostic to whether its users are on testnet, mainnet, signet, etc.
The vulns themselves are in the client code, and mercury has no insight as to who (if anyone) is running that code, or what networks they're running on. No way to notify them besides publishing.
xD no no no, @tptrevethan and I had a very reasonable discussion of how to handle this and roll out fixes. I offered to give Mercury as much time as they needed to roll out fixes, but then Mercury went ahead and published the vulnerability report on Twitter. Only after seeing that did I publish it to my blog as well. The cat was already out of the bag at that point.
Also see the twitter thread here: https://x.com/TTrevethan/status/1832064237499269463
The vulnerabilities are described in detail in my blog here: https://conduition.io/code/mercury-disclosure/
1098 sats \ 0 replies \ @conduition 30 Aug 2024 \ parent \ on: Mutiny Wallet is Shutting Down bitcoin
Yikes, this thread is toxic. Clearly there are some strong feelings about Mutiny in both directions.
I admire the work Tony and Ben have done to get Mutiny working the way it does. Mutiny is particularly impressive to me as it's one of the few wallets available today which manages L1, L2 (lightning), and L3 (fedimint) transactions in one unified package which at least tries very hard to be non-custodial. That's no small feat. That said, I don't use Mutiny myself, as I'm not a huge fan of PWA wallets, for security reasons, but clearly for many people the convenience was worth the risk.
I hope someone carries on developing Mutiny's open source code. The bitcoin wallet ecosystem needs greater diversity to support the great diversity of people on earth and their needs. Every honest bitcoin wallet which shuts down is a net loss to everyone invested in that ecosystem. I'm loathe to see stackers like @DarthCoin in this thread espousing "i told you so," calling the devs grifters, childishly behaving as if this event were a positive thing. But haters gonna hate, and we devs have to shut it out and focus on what matters.
@TonyGiorgio has always seemed like a reasonable person to me and I don't blame him for disembarking this peculiar train he was conducting. I wish you all the best of fortunes in your future endeavors, sir.
132 sats \ 2 replies \ @conduition OP 12 Aug 2024 \ parent \ on: Cassandra: My RESTful DLC Oracle API bitcoin
Unfortunately I had to shut down the Polymarket oracle, because (and honestly i shoulda seen it coming given it's built on a shitcoin), Polymarket's API is dogshit. They frequently return bad/inconsistent data which put my oracle in a bad position - e.g. changing the outcomes strings, events aren't resolved by their stated end date, end dates are changed after I announce them (illegal in a DLC), etc.
And their API is genuinely unreliable even if it weren't for that: events' data fields suddenly go missing (unexpected null values), and it's rate limited so cassandra can't always fetch updates for every event in a timely fashion.
The CryptoCompare oracle API is still up and running though. As for real-world event attestations, i'm working on something else which should help fill that gap. Stay tuned....
Many Zero-knowledge proving systems, including Groth16, require something called a 'trusted setup ceremony', where one or more people (usually a commonly trusted set of third parties) create some secret data and some corresponding public data. The public data from this ceremony can then be used to create and verify zero knowledge proofs. The important part of the ceremony is that the secret data (often called 'toxic waste') must be deleted unrecoverably.
If that toxic waste isn't deleted, it can be used to create fraudulent proofs indistinguishable from valid proofs.
There are more powerful ZKP systems like STARKs available these days, which do not require trusted third parties, but their proofs are much larger and slower to verify. Most blockchain applications prefer SNARKs for performance.
Also, could you explain a little what the difference is between a multisig escrow instead of an on-chain ZKP verifier?
Sovryn's on-chain ZKP verifier is basically a BitVM smart contract holding a user's BTC in escrow, which says: "release these coins to whomever can provide a proof that
X tokens were burned on Y other blockchain". How that proof is constructed I don't know... But if such a proof can be verified on Bitcoin (using their flavor of BitVM) then the prover is entitled to get their escrowed bitcoin back.A multisig escrow is much simpler, faster, and more efficient on-chain, but requires more trust. A user deposits money into a 2-of-2 multisig, where the first key belongs to the user, and the second key is a FROST threshold key belonging to some group of independent auditors. Those auditors watch the other blockchain and promise to sign a refund transaction when the user burns their wrapped BTC tokens.
Naturally the auditors could withhold that signature, or go offline, and the user doesn't get their money back. Hence the higher trust level. But with a diverse enough group, that risk can be mitigated, and there's zero risk of the user's Bitcoins being stolen because the user holds one of the necessary signing keys.
Their whitepaper is pretty bad at explaining what this tech is, and their docs aren't much better. I'll give it my best shot but if anyone from sovryn is reading, please correct me if i'm wrong here.
The whitepaper introduces two technologies, "Grail" and "BitSNARK", which i assume taken together are the 'framework' they call BitcoinOS.
They claim BitSNARK is a more efficient version of BitVM for the specific case of validating ZK rollups, but they fail to elaborate on how they made it more efficient and how it works internally, beyond the high level overview given on page 3. The main raison d'etre of BitSNARK seems to be to act as an on-chain enforcement mechanism for settling smart contract disputes using zero knowledge proofs (Groth16 snarks) as the ultimate source of truth for who 'wins' the settlement. Basically this is BitVM specifically instantiated for SNARK verification.
Also, Groth16 requires a per-circuit trusted setup and produces "toxic waste", and their paper doesn't clarify how they deal with that. Who does the trust fall on? What are the consequences if the trusted parties misbehave and keep their toxic waste?
As for Grail, it seems to be a procedure used to 'transfer' bitcoin in and out of an L2/sidechain, using BitSNARK (BitVM+ZKP). This type of procedure seems to be a hot topic for businesses these days. Full disclosure: i'm doing some work for a company who is building something similar, except with multisig escrow instead of an on-chain ZKP verifier.
Grail BridgeThe bridge is intended to allow users to transfer assets between the Bitcoin blockchain and an L2 (Layer 2) networkOperators can lock funds on the Bitcoin side by sending them to Taproot addresses created using BitSNARK. The funds are thereby locked in a UTXO until a SNARK proof is provided that allows them to be retrieved. On the L2 side, the operator sends a SNARK proof to the bridge smart contract, thereby causing the bridge to mint tokens to the operator’s wallet. In the reverse process, an operator burns their tokens via the smart contract, thereby obtaining a SNARK proof that allows the operator to retrieve their funds, on the Bitcoin side, from the UTXO, using the BitSNARK protocol.
So the "Unlimited Smart Contracts and Scalability" claim they have emblazoned on their website isn't occurring on bitcoin - it's occurring off-chain, and the framework they've designed is just an engine (powered by BitVM and SNARKs) to allow people to wrap bitcoin which they can then use on smart contracts inside the given L2.
Ultimately users still need to choose their L2 wisely because a bug or hack in the L2 will destroy the wrapped bitcoins, and prevent users from creating valid proofs to reclaim the actual Bitcoins proper.
For example, if you used Grail to wrap BTC onto Ethereum, and then deposited that wrapped-BTC in a poorly coded ETH smart contract which gets hacked, then you're shit-outta-luck - the hacker can burn the wrapped-BTC and create a proof which lets them sweep away your mainchain BTC, and you can't do anything about it. Your money would be just as gone as if you'd just sent your BTC straight to the hacker in the first place.
Overall rating: 6/10. Highly efficient ZKPs enforced on Bitcoin is exciting and I would like to know more about how their 'BitSNARK' system actually works. I think Sovryn is focusing on the wrong use case with Grail though. Instead of bridging Bitcoin to shitcoins, they should be focusing on using BitSNARK to create more powerful expressive tools on L1 bitcoin.