Last Notes
This is quite an eye opener considering Greg was one of the people who really investigated this back in 2013-14
https://news.ycombinator.com/item?id=50125089
I mean, even *he* isn't claiming they literally stole something, and the attribution barely matters. But still.
Yes it's succinct. Recursive proof.
Yes, it seems that it was even more nefarious than first thought.
Thanks. It was the less bad alternative.
Converting L-BTC to BTC has a minimum of 10,000 sats and a maximum of 0.25 BTC per transfer.
Read our blogpost for all details 👇
https://www.bullbitcoin.com/blog/lightning-and-liquid-are-back-on-bull-wallet
For anyone interested: these proofs are actually STARKs ; they are proved recursively by the sequencer. any final withdrawal proof by the user does what Risc-0 calls 'shrink-wrap', in which you make a groth16 (so, SNARK) proof that the STARK proof validates. That's why the on-bitcoin verification is O(1). The STARK proof is also O(1) because it's a recursive proof: it says "this proof is valid, plus this other one new chunk is valid'.
@nprofile…rdgc i hadn't seen anyone make the point that the proof of work headers stay untouched even if ECDLP falls. a flag day needs a height nobody can forge, and work gives you one.
on branch `anchor` there's now a fairly complete setup: the sequencer posts anchors to bitcoin each L2 block. when you withdraw, you prove that an anchor is embedded with enough PoW and at least 10 blocks deep. You prove that your withdrawal represents a valid set of state transitions from genesis. These things together mean that even if the sequencer is colluding against you, you can't be cheated out of your money. And the transfers on L2 are all shielded (like zcash). The remaining risk is censorship: the sequencer censors your withdrawal transaction.
The demo now shows the anchoring so you know how final your transaction is.
https://github.com/AdamISZ/lichen/tree/anchor
#nevent1q…u6rk
Damn i spoke to soon.
NIST P256's generator's seed was found.
That's not Bitcoin's (secp256k1 is not a NIST curve).
Again it theoretically doesn't matter. But we'd still love to know!
#nevent1q…un03
An ecash mint which can't rug its users?
Yes, please sign me up!!
#privacy
#nevent1q…ueda
And re: your last paragraph, yes, totally, you buy inbound liquidity, probably, just like you do now with an lsp.
The scenario is not so much "I want to move from hub A to hub B". Not saying that isn't interesting, but, to give you the flavor of motivation behind "we need to move money across hubs":
When I talk about different hubs I'm mostly trying to address this scalability problem: if there was just one mega-hub, everyone would have to join it and it would have to have huge liquidity and if it ever went down everyone would be trying to broadcast their withdrawal transactions at once. Bad. So, Alice wants to be with hub1 and Bob wants to be with hub2. As the paper notes you can't do that on one ledger and have them minting the same btc-flavor as one could cheat the other. So, you could have them on different ledgers minting their own btc-flavor. Then the question is if only 1000 people are on hub1 and 1000 on hub2 the ability to pay people is way too limited (10k or even 100k could work, instead, but same principle). So you want to *pay* from one hub to the other, and you could do that easily *using atomic swaps cross-ledger*: hub2 has a balance with hub1. Anyone like Alice on hub1 who wants to pay Bob on hub2, pays him with a two-transaction chain: they pay hub2-on-hub1 but only after hashlocks are set up to ensure that Bob gets paid on hub2 at the same time. (A two-hop route, if you prefer).
Remember the risk with cashu servers/hubs isn't honoring withdrawals as much as, they just spend the bitcoin, since they can. OK I guess the distinction isn't important, in both cases as a user this only matters when you want to get money out.
But in trying to understand why lichen is different, remember that before the timeout of your contract with the hub (3 months, 6 months, whatever you choose), the money is locked in a 2 of 2: it can only go out by *you* producing a ZKP saying you're owed X, or to either you or the hub if either side can prove the other cheated, or all to the hub after the timeout if you go silent after 6 months. Things like "payment from Alice on hub1 to Bob on hub2" would work as classic swaps, with an intermediary (think hub2 having a balance on hub1 and your money flows through it. But that's another thing, the "unruggable" is about that 2 of 2 that you have with your hub.
Yeah claude helped me partly understand the subtle differences. Bit sleep deprived from travel rn, I'm sure I'll get a better handle on it later 😄
it is very much inspired by tlsnotary
@nprofile…rdgc fair, i mislabeled it. a ledger you can broadcast to over tor sounds closer to a sidechain than a mint, i'll read the paper.
Lichen : a new L2 proposal from @npub1vad…nuu7 Potentially more private than lightning.
Kimi K3 (with ppq.ai) tells me we'd need to change some things for bitcoin on blake2b but that it'd be doable... but Kimi might as well be speaking to me in Ancient Greek.
I hope someone has the time+smarts to look at this proposal. After reading more about the limits of privacy with lightning (such as with this article https://stacker.news/items/1562360 ), it seems that it would be great to have a more private L2.
@npub1gkp…ppqk
@npub1lh2…a9nk
@npub1g49…tqvs
@npub1x9q…csg7
@npub193j…ny6k
@npub1qqq…h62x
@npub1wl6…caw8
@npub1wnl…n3wr
@npub1s33…252p
@npub1j6x…69dc
@npub1l79…sqkt
#xbt #blake2b #sha256 #bitcoin #privacy #L2 #lightning
#nevent1q…e4lf
It's more zcash or monero style transfers inside, than ecash style, because it's transfers on an independent ledger. Ecash mints delink payment events; independent ledgers, you can just broadcast your tx p2p, from tor. Just a ledger/blockchain, with the exception you withdraw by interacting with the same guy you deposited at. Receiver doesn't have to be online.
Damn it's hard to describe this succinctly because it's a really a hybrid between an ecash server for btc, with its backing, but now trustless modulo an L2 consensus, and a sidechain for btc. All I can say is, read the paper.
@nprofile…rdgc a guaranteed exit from the hub with ecash style transfers inside is a trade i would take
But that's (one of) the tricky part(s) of cashu right now, right? Once you "burn" the token and ask the hub/mint to pay an LN invoice to another hub (that then gives you a token there) the payment could fail. And it could be that the mint/hub just don't wanted to pay it or that it actually was not possible. Could it be made atomic with lichen? Or is the swap not through regular lightning but through lichen instead somehow? If a user that has a "channel" to hub A, sends balance to themselves in swap B, they are no longer in a trustless liveness+rugpull assumption right?
Disclaimer: I have not finish reading the paper dratf yet.
For the slow people in the back of the room, could you please compare this model to lightning for privacy?
I'm mostly interested in privacy and everything I read seems to show that Ark (and Spark) are worse than lightning for privacy, and that even lightning is actually pretty weak for privacy.
So I'm hoping for a better layer 2 for that. Is it Lichen?
#lichen #privacy
Oh, that sounds great!! An ecash mint that can't rug its users seems really good. Thank you! I'll be trying to follow along.
It's not fully developed yet, but the idea is: once you're on L2 you could/would have better privacy than Lightning, for transfers *inside* it, but your deposit and withdrawals are with the same one hub, which is worse(even that maybe isn't clear).
A more interesting comparison, in some ways, is ecash servers like cashu. They delink deposits and withdrawals, so they have really good privacy, but the server can rug the users' money. Here you're guaranteed to get your money out.
Oh, right, got it. There's the argument that you can test the procedure with different keys. But your point is still very valid.
You're thinking of MuSig(2), which is indeed a cool watly to do multisig. I'm talking here specifically about using CHECKSIGADD in taproot *leaves*. Different thing.
The taproot change included *both* Schnorr sigs in BIP340, which enables MuSig2, but also script trees, which enables the selective revelation I mentioned above.
The issue is: do you want to never even do a test txn? Personally that makes me anxious.
You absolutely do need to do test txs! Maybe i missed the context of your comment though.
The context is that if you never spend from a multisig, the attacker can never steal your funds because he doesn't have the requisite pubkeys to construct a transaction, even with 2 out of 3 keys for example in a multisig quorum.
The downside is, you don't know if you really set your setup correctly so you are (in my opinion) at a minimum at risk of being undertrained on how to shoot your monetary gun and at worst footgunning yourself with significant funds.
Taproot does weaken remote theft defense... surprisingly.
Meaning quorom is enough to spend on it's own without a bunch of extra work. Just a single spend necessary.
Taproot collapses pubkys into a unified key, eliminating the need to have discovered every single pubky individually.
But I was saying it strengthens it? One leaf exposes A,B. One exposes A,C. And one exposes B,C. So onchain you only see the 2 that signed, not the 3rd. Pretaproot you see all 3, in every signing event.
But now I've written that out, it only helps in terms of blockchain publishing I think. If you literally own 2 of 3 devices, you clearly will be able to see all 3 pubkeys.
Right, but they wouldn't have all 3 pubkeys on a multi-vendor quorum unless they pwned all three vendors.
Barring that, users would could tell on themselves by spending, since the pubkys are revealed in multisig spends.
IIRC taproot affects this. Pre taproot it was impossible to sign m of n multisig without exposing all n pubkeys. In taproot, it is, with leaves. It's complicated but in old school multisig with 2 of 3 devices, each one has to know the others' pubkeys, so owning 2 devices is definitely enough.
If you have all 3 pubkeys, you only need 2 of 3 signatures (or private keys ofc) to get the money. You may or may not have access to the pubkeys, it depends. But clue is in the name: they're *public* keys, called that for a reason.
Yeah, it looks like you'd need to compromise ALL THREE keys in a 2-of-3 to pwn a multisig setup:
"Without the third key, brute force is off the table — two to the two hundred fifty-six curve points is eight and a half septillion universe-ages at a trillion derivations per second, so that's not a strategy, that's a surrender. What a remote attacker actually does is rank four moves. First, passive waiting: any spend by the owner broadcasts the third pubkey in the witness script, and from that moment the drain is trivial — one combination, seconds. Second, a one-pass chain scan for co-appearing pubkeys, which only surfaces wallets that already spent, so it's a partial map of a corpse, not a live target list. Third, if the third key came from a different compromised population — say another reseller batch with a million devices — the search space is pairs times that population, roughly forty-five billion combinations at a million devices, which is hours on a serious GPU cluster but not impossible. Fourth, go after the descriptor through the coordinator software, a cloud backup, or phishing the backup location — because if the descriptor leaks, everything collapses to one combination regardless of keys. The uncomfortable truth is the multisig's real defense isn't the math, it's that the third key's absence makes the attacker's job a waiting game or a metadata hunt, and both of those are things the owner controls by not spending and keeping the descriptor offline."
Yes but it is still an order of magnitude harder to compromise multisig even if you manage to, in a single operation, compromise two vendors.
It's not as simple as adding two seeds together, however with AI it's probably possible to automate now. I would have to have the complexity calculated.
It's certainly a good idea to make sure it doesn't accidentally connect to an unsecured network. Or maybe like live in a farmhouse or something 😄
The thing is, what's your actual threat model? Anything is *possible*, but what's plausible.
Yes physically disabling in bios with password protection, then uninstalling the driver set in Linux with w password protected kernel is probably sufficient
It's sort of the wrong question? I mean this isn't exactly true but it's a fun thought: suppose I gave the "obviously correct" hardware and software choice. Then, everyone would use that, and attackers would have at least a specific target (that is FAR from a watertight argument, but it's a fun/interesting one).
Fwiw i think it's easier to be network-disconnected on laptops and desktops, than on phones. I think that should count for something.
https://npub1v6qjdzkwgaydgxjvlnq7vsqxlwf4h0p4j7pt8ktprajd28r82tvs54nzyr.blossom.band/d6e336d8431b45656dde770591678ddac122a804188a2c088f3a8cff96898711.png
nice arc. watch-only was the real unlock there.
hardware wallets are useful, but “tiny magic box = safe” made people skip backups, restore tests, and threat modeling. bad trade.
Without revealing much I’m curious what you like using as far as hardware and software. Would be helpful to know what has worked for you
I remember doing some coinjoin with it after lot of errors. I was not aware of the bugs and assumed it did work and provided some privacy.
Here's what withdrawal looks like when the hub has gone offline. There are 2 such transactions. Each about 10kvb, a mere 40kB of witness/script 😄 (seriously though: big, but not a problem at all).
https://mutinynet.com/tx/5193b49e0c3bc62a5a72636b0a28ef83a279effb6f5ed79dcaaa632912a72ff8?showDetails=true
#nevent1q…crcg
Doesn't look like much (because it isn't! lol), but here is the first ever withdrawal from a lichen on a public network :
https://mutinynet.com/tx/0a1efc47e251e32dab3d57d1ef0052f9f55b5ef6527ecc0b65957d5f69652338
Alice deposited 30k sats into the L2 for a 2 week timeframe, paid Bob 5k, then withdrew 20k. Now Bob has 5k sats more and Alice has 5k sats left. Alice's leftover 5k sats in this case are in "credit" mode: she can't exit them any more independently, she'd have to sell them to someone else. In general, she won't do this; she'll withdraw everything when she withdraws, that's the simplest, or just "novate" : when she wants to withdraw she'll negotiate a new contract to replace the first one.
Also it won't be very practical to use 10k sat type deposits in a real deployment. Like 400k and up is my guess. Of course L2 txs can be v. small.
#nevent1q…7r22
I think it will lead to loss of funds for lot of users.
@nprofile…rdgc trustless exits backed by channel liquidity with no new opcodes caught my eye. shielded transfers on top is the use case i would want first