pull down to refresh
This isn't about a mint stealing funds from its own users. It's about a malicious mint stealing funds from users of another mint. E.g. you trust Alice's mint and have $1000 on there. You don't trust Bob's mint, but someone airdrops you $5 in ecash from Bob's mint. You try to transfer (melt) the ecash to Alice's mint (which you trust) but doing so allows Bob to steal the $1000 of valid ecash that you already had on Alice's mint.
This is partially correct, but it's not the whole picture. Lava's old custody model used DLCs as one component of a complex cross-chain (Solana) multi-transaction smart contract where, in theory, the user would always have a unilateral exit back to Bitcoin when the loan expires. In theory, the user should always be able to get their Bitcoin back in full by repaying the stablecoins on Solana. Vice versa: Lava should always be able to recover the loan capital plus any accrued interest even if the user is malicious.
The problem was, like Spark's protocol, there were many assumptions made to get to that goal. The oracle behaving, the Solana smart contract key staying secure, the closed-source software being authentic, etc. The on-chain protocol itself was as well-designed as it could be, but ultimately brittle and susceptible to subtle implementation bugs or misuse.
If they wanted to, it would've been easy for Lava to rug-pull everyone, which is exactly the same as any other closed-source bitcoin wallet, because of remote code updates, naive users, etc. Lava's CEO Shehzan and I have spoken about this subject quite a bit, and while I'm more optimistic about self-custody than he is, we mostly see eye to eye.
There was no practical path to fixing all of these issues definitively. All the while, if even the smallest bug were to sneak through, if they were hit by a phishing attack, or an NPM supply chain attack, etc, it would lead to a catastrophic hack or lost user funds. This never happened, but it was a factor on their minds.
Knowing this, and also having opportunities to build a better product by doing so... Lava rebuilt everything and moved to an institutional custody model. But unlike most custodians, every user's deposits are kept isolated until they are withdrawn. You can audit on-chain to confirm your collateral isn't being rehypothecated and gambled away SBF-style. You can find more info about their new system here.
Having audited both the old and the new code bases, I would be far more confident using the new platform rather than the old DLC-based on-chain protocol.
Source: I work part time for Lava as a security contractor.
Just based on historical precedent alone, I imagine people would default to whichever fork is more economically popular (larger market cap)
I do really hope that if a fork comes, there isn't a protracted fight over naming rights
I'm happy to report I worked with Ken from paywithmoon to get my coins returned without doxxing myself. Turns out the problem was just old-fashioned buggy chainalysis, big surprise. I verified the source of my funds without KYC and that did the trick. I might give their service another try in the future, but when I do i'll make sure I deposit only with Lightning where chainalysis flagging me is less of a concern.
Neat, but it's nothing new IMO. To me this appears functionally the same as an HTLC with a really long delayed-activation timeout path, and with a 2-of-2 key-spend path where the server gives its half of the signing key to the user after the preimage is revealed.
I won't comment on the code, as it's clearly still in early development stages. But i will mention some gaps in the protocol which could become vulnerabilities if not filled in correctly.
the user optimistically hopes the preimage given by the server in step 8 of the protocol is also the private key to the public key which, when tweaked with the user’s pubkey, yields the key required for spending the money via the keypath
This must be done carefully using musig or some other key aggregation scheme. If they use naive point addition to perform this "tweak" as he calls it, the two parties could defraud each other using key-cancellation attacks.
User waits for the funding tx to confirm, verifies that the smart contract contains the exact amount needed for the swap (and that the funding utxo is the one they expected), and pays the lightning invoice
The protocol doesn't describe how it handles uncooperative LN edgecases. What if the server doesn't cooperatively disclose the preimage in a timely manner? If the in-flight LN HTLCs need to be settled on-chain, they can take weeks to resolve if the LN onion route is long enough - potentially long enough for the server to claw back the coins in the smart contract while also claiming the LN HTLC (the user gets shorted).
When paying the invoice, the user must set up proper CLTV limits which ensure the user will learn the preimage well before the server has a chance to sweep the on-chain coins back with the tx1 -> tx2 timeout path.
As soon as they pay the lightning invoice, they have everything they need to spend the money to whatever address they want, whenever they want. Nothing bad can happen.
I would be wary of this pitch. The user clearly has a liveness requirement similar to LN, or else the server can steal the money back. I'm not saying a liveness requirement is bad - but it's not the same custody profile as a two-stage HTLC, so it's silly to compare them the way he does in the readme. The user's funds are still at risk until she moves the coins out of the smart contract, and only then may she safely go offline (just like an HTLC).
Hey stackers, posting to update anyone reading this 5+ days later. My money is still locked in moon sadly. I have received no reply from their team or CEO.
NYKNYC rings truer every day.
First, let me apologize on behalf of bitcoiners everywhere for your IRL frustrations, and for the terrible advice given by my peers in other comments here. Bitcoiners can be a bit dramatic at times, and sometimes feel so righteously invigorated by their beliefs that they forget they can be wrong and do wrong.
You've done nothing unreasonable here. Maybe you should've had a talk with your hubby earlier, but you didn't, and eventually temper got the better of you. It's OK, it happens to us all sometimes.
The important thing is that you and he have a frank and honest discussion once both of you have calmed down. If the snap was on 4th of July, i'd say you're overdue for a good sit-down chat, assuming you otherwise haven't talked about it yet. I think both of you have reason to apologize.
I can't give you the "magic words" because after 9 years' marriage, you likely know him better than anyone else, including anyone on this website or anyone on his podcast.
My only advice is: When/if he asks you why you don't want to listen to his podcast, don't let him press you for constructive criticism - it may not end well. Just say "it's not my thing". Sounds like the podcast means a lot to him. He needs to understand that you support him and his podcasting in a way that doesn't involve you listening to it.
Good luck!
Thanks for posting here. I replied to the email ticket with a detailed description of my coins' origin.
They came from my employer originally. I used them to buy XMR on an instant-exchange before depositing some of the BTC change into PayWithMoon, so maybe that's the cause of the flag. Chainalysis will sometimes flag coins even if they don't directly originate from a known "bad" source - One of their many flawed heuristics which lead to situations like this.
I appreciate that your business has to comply with KYC laws to keep the governement off your back. We can all agree KYC/AML sucks, and I can live with being denied access sometimes, but opaque rug-pulling isn't an acceptable solution. If your team had simply refunded my coins I would've had no cause to complain. Instead they stonewall me, effectively saying "Your money belongs to us now, unless you KYC."
It sucks that I have to complain publicly to get any recourse. I hope you can train your team to deal with these situations better, and I hope we can come to a resolution where I can get my money back without doxxing myself. Let's take the rest to email.
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
Personally I would prefer that knotsers delude themselves, and proceed with their soft-fork confident. Gets it over with faster and less contentiously that way.
Fortunately though, you're right. Regular (non bip110) Bitcoin nodes do not simply follow the longest chain- they follow the chain with the most cumulative proof of work. This metric is called "chainwork". It's basically the overall expected number of hashes needed to get to a chain of this size, after all previous difficulty adjustments.
If BIP110 activates without majority hashpower right off the bat, then legacy nodes will (eventually) follow the regular legacy chain as it accumulates more chainwork.
For BIP110 miners to "wipe out" and reorg the legacy chain in the future, as some have conjectured, they must not merely attract a majority of hashpower- they'd have to attract it and keep it for a very long time. The BIP110 miners would need to (on average) compute more hashes than the legacy miners did while the legacy miners had the advantage. The longer it took BIP110 miners to earn their hashpower advantage, the longer the BIP110 miners must maintain it for, to exceed legacy miners' chainwork and cause a reorg for the legacy nodes.
The rules of PoW favor whichever ruleset has more work put into it over time, not just whichever chain has majority hashpower in the moment. Think integrals, not derivatives.