Last Notes
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'.
Yes it's succinct. Recursive proof.
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
Unlimited Liquid withdrawals?
The private keys shall be randomly chosen between 1 and the curve order.
Well, they're between 1 and 256. Good enough right? 🤦♂️
This is an internet Certificate Authority?
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c5
In all the frantic discussions about how thoroughly fucked all blockchains are in the case of an ECDLP break EITHER from AI OR from Quantum, no one seems to have noticed something important: a halt to a proof of work chain is a fundamentally more meaningful concept than a halt to a proof of stake chain that maintains consensus on a threshold signature scheme that uses discrete logs - which includes BLS as well as Schnorr, of course, so it covers Ethereum and I guess most all (?) PoS chains. there is no objective halt height if the thing that determines our current height becomes forgeable. In a quantum scenario (ECDLP broken by CRQC) that most envisage, the proof of work headers chain is untouched. assuming there was some "flag day". But with consensus over a forgeable signature scheme .. sheesh.
Shielded transfers on L2. All state transitions are proved valid. Spending costs the sender a 5-10s proof (it's not very optimized).
A question for anyone following along: is Bob safe?
#lichen
https://blossom.primal.net/da0ee808c671837a83f6dcf66e45ad0b5c2a550f0a9d27e623eaa0a4220ef238.jpg
The problem with BABE and how Lichen solves it: In BABE, you set up a puzzle to be solved later, like "if you can at any time find a valid proof for the statement that this 1BTC belongs to you, you can claim it". The problem is that the amount, 1BTC is fixed right there, at setup, before anything happened. So the only system you can use that for are things like claiming collateral or whatnot. Very limiting. If you made the statement say "I have a valid claim on an amount x" with x being a variable, then they can claim the prize with x=0.01 while the prize is 1BTC; useless.
In Lichen we can exploit the fact that the hub is *required* to answer requests (hub's have to stay live; users don't, until timeout), as follows: first, the statement that BABE's WE works over becomes: "I have an amount x **which the hub signed** and a valid proof that my balance on L2 is > x" where the proof ensures both 'x's are the same. It's bizarre at first until you realize, the hub doesn't sign 'x' to say 'x is a valid withdrawal'; he signs 'x' to commit the user to that choice. So the process goes: user claims 'i want to withdraw x', hub (forced by liveness; loses after timeout) must winternitz-sign x. Then user can use the setup-at-contract-start BABE setup to extract the spending secret which then fires off into the bit decomposition, that actually pays out that same x.
Currently I'm about 80% sure this works in practice, not just theory. And if it does, dispute goes from worst-case 23 transactions onchain to worst-case 4 or 5 and *maybe* 20kb. In either case, it's zero normally. ( Lichen: if you don't know what it is, see the paper in https://github.com/AdamISZ/lichen, also the explainers under docs/ ).
Right now setting up a shielded transfers L2 using a basic design, just to create a prototype. Already done a fair few mutinynet tests of the existing BitVMX dispute (with its 20+ transactions, a lot more bearable on that chain of course!).
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
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.
Wow!
https://www.anthropic.com/research/ecdsa-curve-origins
This is not a bad thing, don't worry 😄
The opposite: we now where G comes from in secp256k1. It was theoretically not a problem anyway. But now we know for ~sure it was not some weird backdoor.
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.
Small community discourse is always higher quality, as we see here.
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 😄
This reminds me a lot of the tlsnotary work we did back in 2013. At a glance it's solving a slightly different problem. Cool idea either way.
I feel rather the same. Especially because paying between hubs, I've just realized, should be just as simple as it is between ecash servers now.
#nevent1q…xz2z
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.
https://www.coinbase.com/blog/working-together-on-btc-post-quantum-readiness
This is an interesting perspective from the biggest custodian on the planet.
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.
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 absolutely do need to do test txs! Maybe i missed the context of your comment though.
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.
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.
There may, however, be *2* known remote attacks :)
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.
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.
Maybe people will finally realise (a) it's easier to audit software than hardware (b) the threat model on hardware isn't realistically backdooring general purpose computers when they don't even know what software you'll run (c) you don't have to rip out network cards, if there is no accessible internet.
Maybe, maybe not ;)
I wonder if I was influenced by getting into bitcoin before hardware wallets existed. Back then the discussion was "don't be a dumbass and run your wallet on windows" and "keep it on a separate machine". People were running wallets on phones and getting into arguments about how much is safe to keep on it - I guess that just hasn't changed at all. BIP32 was just starting to become commonplace and people realized the 'watch only' concept could work (a massive step forward imo), people were just starting to tinker with the idea of special purpose devices, I remember Trezor starting up. I played with one a few times, small amounts, it's kind of cool technology, but I could never bring myself to put much money on it. It's sitting in a drawer, empty, now. I bought a couple Coldcards, gave one to a guy in El Salvador who used it for teaching, the other one sat in my drawer until the hack, shortly after which I took it out of its bag and used it as a teaching demonstration, myself. Thanks for coming to my ted talk.
Tbh it never really worked in 2016. I tried very hard but no one was interested in helping me, not even to test, so I just gave up.
I remember I found a bug in Electrum while I was doing that, that made it impossible to cosign transactions. Thomas fixed it when I showed him, but man did it take time to debug it! Pretty slow back then 😄
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
The general replay potential of APO style sighashing was discussed quite a bit in 2018 when eltoo came out. For example here's GMax suggesting to call it "SIGHASH_WEAK_REPLAYABLE" :) [1] . It's not hard to deduce that of all the various and sundry op_code proposals we've had over the years, this is one that has the least solid foundation of "users cannot footgun themselves". By any measure, they can.
To be clear, I haven't bothered to read these new proposals, but I get that your point is: because they offer more powerful templating, the risk is no longer just 'replay the payment' but 'replay the coin-spending into an actually different payment'. Very clearly a bigger risk, agreed.
Presumably the obvious counter-arguments apply: the contract outputs are 'special', they'll never be presented as addresses you can spend into and etc etc. The counter-counter argument is operational fallbility etc. I guess. I don't really have strong opinions, but I think I agree that this at least a point of controversy in terms of what should be added to consensus rules. That style of argument has been made before.
[1] https://gnusha.org/pi/bitcoindev/CAAS2fgS-_D7aBcDf_nAbuREBxv65zYMr60-1YqCnx-esvRVfEg@mail.gmail.com/
From the table of contents this looks like a fantastic ZKP reference. All the way from the absolute math basics to modern systems:
https://github.com/BlockstreamResearch/zk-book/releases/tag/latest
A follow up from recent ideas : Lichen[1]. You can have trustless withdrawal from an L2 based on liquidity in channels.
https://groups.google.com/g/bitcoindev/c/yZEZ5P1lj5E
I'll be interested to see opinions. I believe this can be built today. No consensus changes needed (op codes). The application I'd like to see it for is shielded transfers for good privacy, without some of the current impracticalities in proposed bridge designs.
https://github.com/AdamISZ/lichen has a prrof of concept with a demo on regtest.
[1] another backronym 😄 .. L2 In CHannels ENforced by bitcoin.
What about tamper evident seals.
Is anyone else getting paranoid that their own writing is starting to sound like AI cliches, because so much of what they read nowadays comes out of an AI.
To be clear, I don't look down on AI writing just because it's AI. I still read it if it's a useful set of ideas, but I see it very differently if you aren't writing it yourself because, *sometimes* (depending on context) it means you just didn't make much of an effort.
Also it's gradually getting less cliched with more recent models. But, gradually.
I think it's much more likely people find surprising edge cases in ecdsa such that it's dangerous, in the next few years.
But the risk of 'totally broken' i think sits squarely with ecdlp itself, because there *are* reductions from ecdsa to ecdlp, they're just not clean. So I guess different kinds of risk, but, again, I obviously am 99% just guessing.
Yes. The quantum attack, any attack breaking ECDLP, it's worse.
An ECDSA specific algorithmic attack, it's better.
Example: with ECDSA you can create a signature that validates against two different pubkeys. With Schnorr you can't do that.
if you want to know why i always talked down people's belief in hardware wallets, it was not because of what happened with Coldcard, it's because of what just happened (apparently? seeing it rumored via Karpeles on twitter; not sure if it's true) with Ledger: supply chain. They didn't need to tamper the wallet directly, they just created a way to watch it. You buy via the authorized resale agent, but he goes rogue and sells versions with 'implants' that read your seed as you enter it.
*Not advising any particular approach to all this, not even 'don't use hardware wallets!'. just saying - central points of failure matter, you need to think about that *actively* because it's human nature to stay in the herd, even in subtle ways.
Interesting detail that I bet no one else mentions ;)
If you're worried that AI might break the cryptography protecting your coins, it might make sense to switch to taproot. ECDSA is *far* less trustworthy than Schnorr and ECDLP, imho.
Of course no one really has a clue, but that take is not unreasonable.
The part that got my attention so far is chapter 3: using fedimint ecash servers!
https://bounty.blink.sv/
Very interesting read!
H/T @nprofile…jtmp
Yeah you were right, it is dns level block at ISP.
Ironically that boss is famously not only very easy to kill, but also much smaller in the game than in the cover art/intro cinematic.
My guess is it's a classification error, not a ban; that would have been news.
I honestly think that's orthogonal to what I'm talking about. What you're talking about is a very serious problem of vastly expanding automation of real world interaction. I have experienced similar.
I'm talking about pure software. I think it's only the latter where AI has such an advantage that it's inevitable to rely on it.