waxwing

Bitcoin, cryptography, Joinmarket etc.

Public Key

npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

NIP-57 Address

Profile Code

nprofile1qqsxwkuyle67y94tj378gw8w2xw2wa6nwmwlqhddlwnz0z7sztsaw2qpzpmhxue69uhkummnw3ezuamfdejsz9nhwden5te0wfjkccte9ehx7um5wghxyctwvs4793qy

Publishing to

nostr.wine

relay.nostr.band

nos.lol

Author Public Key

npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

Show more details

Last Notes

2025-01-16 16:46:47 GMT

Is anyone who works on Liana around on nostr? I'd seriously like to figure out if I missed something as I'm giving a presentation on this topic next week.
#nevent1q…q0cy

2025-01-16 16:36:26 GMT

Trying to investigate Liana https://wizardsardine.com/liana/ and I'm having a rather typical frustrating experience. I come to their website wanting to know the mechanisms they use for vaults and inheritance setups. Scrolling all over the page I find a number of things that look like buttons but I can't click. There are several download links but .. where is the description of how it works? Ah, we have "LEARN MORE ABOUT LIANA", that must be it, right? Nope, links to the next section down the page. Etc. Finally in desperation I choose "support" from the top menu, and, ah! Now we have it right? "Guides", "Resources" and "FAQ". But the Guides are videos on setup, the Resources are video presentations at conferences. And the FAQ is as expected just brief answers to non-technical questions. At this point I *half* give up and load up the github, but at least on the main repo I found no docs that explain the basic mechanisms used, so short of spending a couple of hours reading the code, I still have no idea how Liana actually works, at least, not from *their* web presence.
For context, I think I actually understand how their inheritance mechanism works, just from reading phrases in a couple of places describing it in words. But why is it so hard to find definitions or examples of their scripts (miniscripts w/e), let alone detailed technical justification.

2025-01-11 00:23:30 GMT

- reply

Sorry you're right. I use 90% LN so I'm only using onchain btc a few times a month.

2025-01-10 23:17:10 GMT

Still out here using bitcoin every single day ... and according to the mempools I see, there are literally ... dozens... of us.

2025-01-06 23:05:54 GMT

"Re: Reused R-values again"
from bitcointalk, 2014 https://image.nostr.build/c34fe79968c4a709ea9011f8fed6509a3cfcbe8b8c9f89dfd833222885b40545.jpg

2025-01-03 15:59:17 GMT

A bit tricky to explain this but let's try:
In the summer Jeremy Rubin proposed "F-ed up covenants" which was the idea of making covenants on bitcoin without an op code, using functional encryption. Basically the idea of FE is "you don't have a key that lets you decrypt encrypted data, you have a key that lets you decrypt the result of a function, F, on encrypted data". And he used that to get a signature on a transaction to be outputt-able by decryption, but the "functional" part restricted it so it would only work if the transaction hash was some value, e. This means that only the covenant-preparer's intended transaction could be signed over, assuming the "root" private key had been permanently deleted on setup. (and this could be repeated indefinitely for different covenants after an initial setup).
Very clever idea and I commented on it here at the time. The problem was, as Jeremy himself well understood, that the function he proposed being complicated (something like "ECDSA-sign(private key + hash, over message which is hash)") is complicated and there is no functional encryption scheme that we know that can do this efficiently. More or less.
So I've spent a couple days writing it out, and I *think* you *can* actually do this using the simplest kind of functional encryption which is inner product functional encryption. There are several twists, though. First, it only works for ECDSA not taproot (I'll explain that to anyone that asks). Second, what we want out of this is different from the toy "calculate student's grade average from encrypted grades" use-case example that's quoted in papers; we want to calculate the ciphertext of the private key, throw it away, then calculate decryption keys separately for each new transaction that we want to covenant. I found a way to do that but with a huge limitation: we need a server to be able to calculate the one-time use decryption keys; we can *still* throw the original private key away, immediately, but we need these "decryption secrets" per use case. However, I think this can be done with a simple blinding, such that a decryption-key-generating server doesn't need to see anything when creating them. Given this, one simply needs to use the El-Gamal encryption scheme "over" the functional encryption (see https://eprint.iacr.org/2015/017.pdf ) to allow anyone to output a valid ECDSA signature from an inner product of the one-time created ciphertext for the private key, combined with the user's individual nonce and transaction data.
fwiw the nastiness of trusted setup one-time privkey creation doesn't bother me so much; it can probably be MPC-ed which is good enough. But the need to do (albeit blinded) calls to some server to create the one time decryption keys is quite nasty. If there were a trick to get round that, AND there was solid enough security analysis to say that this actually works, then I'd call this a huge advance. For now it's a bit pie in the sky. I'll try to make a toy implementation along with a writeup, when I get back to my desk.
Original f-ed up covenants post: https://delvingbitcoin.org/t/fed-up-covenants/929
#cryptography

2025-01-01 13:36:48 GMT

- reply

Out of curiosity, are there other types of posts that do better on Twitter, than here? What's the difference do you think?

2024-12-29 01:25:15 GMT

New blog post:
https://reyify.com/blog/the-fallacy-of-agency
A pictorial essay about a (wrong) mental pattern, which I think is very pervasive, and my own speculation about why it exists.
It is a *bit* related to bitcoin, I promise :)

2024-12-19 15:51:21 GMT

Little comment on the details of the IMF-Bukele deal. My take on the general bending-of-the-knee here I already gave a week ago.
I think people are not paying enough attention to one aspect of the language here (distracted as they understandably are by the first 4 sentences): "Transparency, regulation, and supervision of digital assets will be enhanced to safeguard ..." . Here the IMF is reasserting the right of the global banking system to prevent autonomous control of money using Bitcoin in El Salvador. Note that the banks wilfully ignored the bitcoin law for 3 years despite on more than one occasion Bukele claiming he would address this and punish them, but he never did. And now, not only have they been vindicated and will continue to persecute bitcoin usage aggressively, but even very concrete every day things - using Bitcoin ATMs here will imo, after a while, be reduced and phased out - no longer will you be able to buy and sell hundreds of dollars just with a random phone number. If the ATMs persist at all, they will require ID cards and/or (more likely) the use of accounts regulated and approved by the banking system/regulators. And since Chivo will be phased out (most likely), then using bitcoin in stores will *mostly* disappear. Pessimistic take, but I think so. I give it 18 months before living on Bitcoin here will not be very practically possible any more. Hopefully I'm wrong!
#elsalvador

2024-12-06 15:36:02 GMT

https://blog.cashu.space/buckets-of-blind-signatures/
@nprofile…xnfk : good clear writing, thanks for that writeup! I think it's rather hard to explain the *first* part, let's say, the (M,C), (M',C') relationship, to the unfamiliar reader. I particularly thought the second half fleshed out the issues very well. And by the way, I refuse to believe that the optimal base is not in fact e :)

2024-11-28 22:30:44 GMT

- reply

I'm not sure what that means? I'm using the alby Hub desktop app. I installed alby Hub locally. I have a getalby account yes.

2024-11-28 22:09:15 GMT

- reply

What does "save the screen here" mean? Press save on the (after long press) settings screen? Pretty sure I did that every time. As for what happens, the circle goes all the way round (95% I guess) and then just stops.
I notice that on the alby hub side, I'm seeing nothing in the logs that I have tail-ed in a console. (apart from the normal LDK background stuff)

2024-11-26 15:06:14 GMT

- reply

I'm not sure who the intended audience is; for a casual reader who'll never write code, it's probably way too detailed. For an engineer who needs to understand mechanisms, it's too abstract. We need scripts (to be fair these are given), transactions, utxos and signatures, and we need the sequence of steps, between the parties. So the 'Payment diagram' on 'payments' is good, e.g.
It's always great to have abstract descriptions to gain insight, but for a new and complex system that has to come after writing the *exact* mechanism. Imo.

2024-11-26 14:20:50 GMT

Pinging @npub148j…xhgp .. is there any kind of paper or spec I could refer to to better understand Ark? I'm reading arkdev.info/docs but it's too general/broad for me.

2024-11-24 15:48:00 GMT

This is an interesting response to the debate, and further firms up my sense that the real problem with enacting a covenant soft fork is the lack of a *genuinely compelling* protocol proposal using it.
Don't get me wrong, there are lots of proposals, some of which are useful: vaults seems like the strongest candidate there, but they are not critical to bitcoin's survival/success (important, yes, critical, i suspect no), and congestion control is valuable but neither of these are *genuinely compelling*. Lightning was, and segwit was propelled by its existence.
To illustrate my point, if you go to utxos.org, another proposal it highlights as an example is "Bitcoin Clique". I read the paper yesterday, and the TLDR is a kind of coinpool construct that requires covenants to allow exchange of funds within the pool. It has some neat tricks (repeated trees with double spend prevention through adaptors), but imo it doesn't reach the "compelling" level because: a) it needs an operator, who needs to put up linear collateral b) exit is unilateral, of course, but is very disruptive (so large groups might never work), c) exit onchain footprint is log_2(n) in pool size which sounds great but that is another size restriction. d) fixed denomination coins!
This protocol is cool but "meh" in terms of it ever getting usage.
We need something that feels very 10x (business/marketing speak). I don't think vaults have that feeling, and congestion control definitely doesn't. That's why I believe Sjors is right to mention sidechains/ShieldedCSV (though I think the latter doesn't actually go in this direction).
You might read this and reasonably ask me: "Well, but if you don't know any super-duper compelling usage of covenants yet, why are you so keen on finding them?" It's not easy to explain, but it's an intuition I've developed, that constraining destination might be the last piece of the puzzle (after malleability fix for presigning, then schnorr for musig, mast for script size) that allows offchain contracting to work to its full extent, which I don't care about to do fancy programming in bitcoin, I care about it because I think it's needed for 50x to 500x more *users* of Bitcoin.
TLDR someone needs to find a kickass off chain (L2 if you like) protocol that could 50x the usage of bitcoin using covenants, *without centralization *, then needs to write code and deploy it on say Liquid and signet. Then the conversation changes. Before then, we're probably not going to get vaults etc. (I could be wrong!).
#nevent1q…ag06

2024-11-20 16:31:49 GMT

i know the popular (and imo correct) view is that charging tax on unrealized gains (e.g. in the stock market) is awful, perhaps immoral. But just a second - how is this any different from charging an annual (not one-off) tax on property/real estate that you own? "Unrealized" just means you continue to hold the asset. Seems like it's exactly the same thing. (And btw I don't live in a country where there's a continual annual property tax myself, but it is indeed a common thing in many countries afaik).

2024-11-15 13:48:17 GMT

I think i agree with basically *all* of James' post here.
https://twitter.com/jamesob/status/1857049961235403101
Including the part at the end, where he doesn't have any solution ...

2024-11-13 15:44:17 GMT

Does anyone know if it's even possible to build an executable for Windows using e.g. Rust (though this might apply to other langs), without buying a signing certificate, and have it runnable by users without false positive virus/trojan warnings (which, actually, make it effectively impossible for users to run).
I did a lot of searching and found a huge number of developers reporting this problem, but actually no solutions. Is it just impossible to distribute binaries as an independent developer? Is it just isolated to Rust and maybe Go etc? Or ...? Anyone experienced this and found a way round it?

2024-10-25 23:16:34 GMT

In case you're wondering why you might prefer unaligned AI/LLMs, or about whether they can *actually* reason and not just pretend to, I just tried this question (not my own idea btw) on current chatgpt 4o, with no prior context:
"The emphatically male surgeon who is also the boy's father says "I can't operate on this boy. He's my son!". How is this possible?"
Its response:
"This classic riddle plays on gender stereotypes and assumptions. The answer is simple: the surgeon is the boy's mother.
The riddle misleads people into assuming that the surgeon must be male due to the description "emphatically male surgeon," but there’s no rule that a surgeon can't be a woman. So when the surgeon says "I can't operate on this boy. He's my son," it makes sense if the surgeon is the boy's mother.
This highlights how we often unconsciously associate certain professions with specific genders."
And if you think that's funny, when i pressed it to try again, it decided the only explanation was ... adoption! 😆😆

2024-10-25 18:49:08 GMT

- reply

How long ago was the previous version? They changed the model recently to a single channel with splicing, might be related. But any case yes you control the funds as long as you have the seed (as long as you weren't penalty closed of course).

2024-10-24 18:53:47 GMT

- reply

Btw another thing about ecash that I think people get wrong a lot is, the fact that it has a central point of failure is not just about trusting with money but it's just a really bad feature of an architecture; consider how much worse the privacy of it is because you have to send messages to a central server every time you make a transaction.

2024-10-24 18:51:00 GMT

- reply

Yes, some good feedback there. On the first point: I've always thought that this kind of thing specifically addresses the most stringent privacy requirement (or, tries to). So if you consider things like DOS on LN or Tor or other similar networks, LN micropayments can def solve it, but they can't achieve the same anon properties as anonymous usage tokens of this form. In practice, does that matter, given that LN has a decent chunk of privacy built in (if not perfect)? I think only for certain scenarios would you say, no, that's not good enough (there's also a bit of a bootstrap problem to defend LN with LN).
Ecash is faster but suffers from the trust and network effect problem, which are intertwined. Which mint? Crossing mints means more complexity and trust issues maybe? But again, you can imagine niches where it might be ideal.
I'm not going to comment so much on the web of trust kind of ideas that you mention you're working on, but i can imagine them having big advantages w.r.t. user not having to do anything, compared to some commitment like a payment or a token of ownership.
Re: proof of rich, ultimately I *suspect* you're right that it's more useful for higher (not necessarily rich but at least 'larger amounts') size money proofs/commitments than for small or micro- ones, but one never knows how a tech finds its use case until you see it in action, I guess.

2024-10-24 16:56:08 GMT

- reply

Yeah there are a few variations on the basic concept. To me the most natural one is a public service like a nostr relay that wants to offer a cheap, *private* service but does not want to get swamped maliciously; bots could still use it, but not millions of bots.

2024-10-24 16:37:28 GMT

Now applied this to aut-ct in a branch:
https://github.com/AdamISZ/aut-ct/tree/delta
Proving is now down to 1-2 seconds even for large trees like 500K, but this is more from me fixing inefficiencies in my code; the real advantage of their new technique for me is just that they made the algorithms much simpler, *and* we have an easy way to batch proofs now (though I haven't done it).
So currently it's:
1-3 minutes to start up a server (which can be left running as long as you use the same curve tree)
1-2 seconds to do a single curve tree inclusion proof
50ms to verify a proof.
This already usable for the kind of 'satoshi millionaire' proofs like the one in my blog post, with sets of 500K or so and even larger, but for some long running system which wants to update the curve tree with new utxos all the time, like lightning it should be possible to get rid of most of that startup cost by using an 'accumulator update' method as discussed in the paper(s).
#nevent1q…rlev

2024-10-21 14:39:23 GMT

- reply

Yeah. Your point about spending limits is a very good one, maybe an interesting area for research. Not being able to spend specific chunks of your balance is a limitation (though the model of discrete denominations is also problematic, in other ways!). Didn't people try to address that with cosigning for onchain? Could we do that for LN? Have an agent that cosigns your channel updates with ecdsa 2pc or musig when we finally get taproot ln (umm nested musig blah blah).
The scenario that seems really difficult is: customer arrives in new town/region and needs Internet access at a 'tienda' (or bodega to use the US vernacular!).
I think nontech answers like fd0's : #nevent1q…vzal
.. are more likely to be what is chosen; though i think physical cards representing LN funds is a nice idea too, just that spendinglimit problem to fix ... If we want people to pay with tokens to bootstrap, the unfortunate reality is they'll tend to use the tokens of the strongest mafia in their jurisdiction (that's what makes bitcoin a little bit magical, it isn't a token ultimately redeemable with some authority).

2024-10-16 16:29:20 GMT

- reply

Well, a poll doesn't *have* to be close. Also is it bad if people are engaged? I guess that heavily depends on your worldview :)

2024-10-16 16:19:01 GMT

- reply

Yes of course that's not realistic, it's designed only to point out the difference in an obvious way.
In the real world, if the polls are say 60-40 for an extended period close to the election, the pred market is likely to be 95-5 or similar, *if* the market finds the polls trustworthy. It is not going to be anywhere near 60-40. Again, they are not measuring the same thing!

2024-10-16 14:57:42 GMT

- reply

If the poll is 51-49 and people never change their mind and everyone is honest, the prediction market would settle close to 100-0.

2024-10-16 14:37:16 GMT

- reply

Yes but the point is that they are measuring totally different things.
I'm not talking about one being more reliable than the other.

2024-10-16 13:37:30 GMT

Is it me or are there countless people out there who can't comprehend the difference between a prediction market and a poll? 😄

2024-10-14 21:33:00 GMT

- reply

The end of section 3 explains; the math there has a small error but it's easily fixed and doesn't affect the main point. Not only is it easier to reduce the forgery to a discrete log break using their new algo, but more importantly, there's no way to create things like DOS by deliberately crafting entries in the leaves (the set of keys) that will take an unreasonable amount of time to pre-process, as was technically possible in the old system (not an issue for most use cases, but for their v-cash use case, it would be). More generally, they're claiming security in scenarios where the accumulator is constructed maliciously, though that doesn't apply to the kinds of use cases we care about.
I don't think the proving and verifying speedups are necessarily significant, especially if they only apply to batching. I will check in a bit more detail though. Basically this is important from my pov because it can make the pre-processing step faster and also make the code simpler. The preprocessing of say 0.5M keys is very nontrivial!

2024-10-14 15:31:56 GMT

- reply

Interesting it is :) But practical? I guess maybe not? We need a version of these ideas that doesn't involve non-trivial interaction between the client and the server (relay), right? I'm finding myself drawn back to "HMAC"; because that was always the traditional solution to this problem, i.e. only the two parties involved in the conversation can verify. There are so called "algebraic HMACs" that can use EC arithmetic instead of hashes. I'll take another look at that.

2024-10-14 15:24:26 GMT

- reply

Right, thanks, that helps quite a lot. I do get where you're coming from with the "leak private key" concept, that's of course intrinsic/fundamental to Schnorr sigs so it makes sense to at least think about it as a deterrent.
It's pretty whacky, but this combination gives you something like what you want: imagine 2 of 2 musig between user A and relay R. A gives R an adaptor on its partial sig sigma_A' where the adaptor secret is its own private key. Then R gives sigma_R and A can *internally* verify the full signature on the musig aggregated key against the message. If it broadcasts that full signature, it leaks its private key.

2024-10-14 15:07:47 GMT

- reply

umm batching 😄

2024-10-14 15:04:03 GMT

Been expecting this, it arrived today:
https://eprint.iacr.org/2024/1647
Curve Trees without permissible points, which i am expecting will significantly improve performance (and have better security). Also some batxhinh amortization type improvements.
Now renamed 'Curve Forests' :) still reading...

2024-10-14 14:47:59 GMT

- reply

First thing is that signatures are publically verifiable; generally when you want verifiability restricted, you use structures like HMAC which can only be checked with the/a secret.
I read your description several times. For the second paragraph (the first, I'll come back to), I *think* what you mean is the case where *you* (A) are giving a user (B) a signature, but you don't want them to be able to re-transmit it or share it? There's several ways to look at it but it depends on details of your use case. First thing to remember is that non-interactive signature schemes that we use are built from *interactive* identity protocols. The latter are *not* transferrable, but they are interactive. So, if A wants to convince B that the message being transferred is indeed from A who owns priv a, just follow a standard 3 pass commit, challenge, response (sigma-protocol).
Alternatively, it's often the case that you're not trying to keep any data secret, you're just trying to make the protocol disallow reuse. Then it can be fine to just include context into the message being signed. If instead of signing "Hello" I sign "Hello from A to B" then if B tries to send to C, the protocol can disallow it because the message does not contain "B to C".
Back to the first paragraph, I see three different things being requested: that the signature (s) be tweaked with a pubkey (to s' say), that the signature is verifiable only with that private key, and that s' is not linkable to s.
This feels like asking for 6 impossible things before breakfast :) Signatures can be tweaked easily (see the adaptor concept), but to state the obvious, they can't be tweaked with a scalar you don't know. So if user B has secret key b, s' = s+ b is verifiable by people not owning b but knowing B (that's adaptors), but the opposite seems impossible: to have s' be verifiable *only* if you know b, but constructible *without* b. That's kind of opposite to how public key crypto works; the world knows B, not b. That is even setting aside the problem of s not being linkable to s'.
Also BIP340 uses key prefixing (pubkey in hash), which means taking existing signatures and malleating them is impossible.

2024-10-13 20:54:23 GMT

- reply

Yes i was thinking along similar lines. Also given the scenario requires physical proximity of sender and receiver, the payer already has internet access at that moment, which makes several things possible.
To be fair, iirc, this was the *exact* application of ecash that was imagined by people like Chaum, Brands etc. in their original papers (vendor in meatspace has network access, customer doesn't) so I'm definitely not claiming this doesn't make sense.

2024-10-13 19:03:28 GMT

- reply

¿Cómo?

2024-10-13 16:54:52 GMT

- reply

Oh yes, i certainly assume liquidity ads; it makes no sense not to include market coordination, especially considering fees are offchain :)

2024-10-13 16:52:19 GMT

- reply

True. But any 2 impls is fine here, I guess - because when you search for liquidity ads, even if only 15% of peers or whatever, are offering, you would still be motivated to do it to have balanced channels by default. The clearing price for liquidity would go down from current centralized providers (which are another CPOF for the state to attack), is my bet.

2024-10-13 16:47:22 GMT

- reply

Good to know

2024-10-13 03:02:48 GMT

- reply

2 independent - that's what what i was missing/forgetting. Thanks!

2024-10-12 23:21:38 GMT

- reply

Dual funded means eg. I contribute 100k sats and my channel counterparty does as well, so that when the channel is opened, it has 200k sat capacity but is balanced, with 100k inbound and outbound.

2024-10-12 21:48:05 GMT

Entirely possible that I'm mis{sing,interpret}ing things here but: it's a shame that the dual funding in c-lightning is still behind a non-default experimental-dual-fund flag and that when i search for the "option-will-fund" in the listnodes output I only get like 5-10 out of 90K. To be clear, by following fairly simple instructions in an old blog post, I was able to make a well-funded and perfectly balanced channel, within a couple of minutes.
For those interested in coinjoin, note that this *is* coinjoin and arguably one of the best types, since by nature of the offchain payments, this kind of CJ can actually hide flows better. If we want to get the real power of such a thing we'd ideally start batching *multiple* such channel opens together, but that's putting the cart before the horse here. Dual funded channels are such an obvious good, why is it not a more widely used system, or am I missing something? #lightning
(Btw said blog post by @npub1e0z…0txy : https://medium.com/blockstream/setting-up-liquidity-ads-in-c-lightning-54e4c59c091d

2024-10-11 19:44:12 GMT

- reply

Link isn't working here (amethyst android) probably because H not h

2024-10-11 18:53:20 GMT

- reply

I see it through JM lens where you can't reliably renegotiate the CJ due to ephemeral coordination so I've always just ignored RBF there, (and nor can you stop someone retrospectively cancelling the coinjoin contract by double spending their input). Of course CPFP exists but since there's no penalty mechanism I don't think the whole pinning thing is so relevant?
Maybe with adversarial makers in a taker maker model? It seems unrealistic.
But with redesigned cj protocol maybe other issues arise.
To be clear I really don't know.

2024-10-11 18:47:58 GMT

- reply

See #nevent1q…lwum

2024-10-11 18:47:35 GMT

- reply

First, my knowledge of this area is very sparse. Second, my response would depend on what you're asking: do you need to know about the issue this is trying to address? I could suggest bitcoin optech on pinning: https://bitcoinops.org/en/topics/transaction-pinning/ (optech is good as a library/reference on these technical concepts in bitcoin, generally; you can also follow links from there). Are you asking how exactly the rules in BIP431 will work? I don't know, but the basic concept is: we have this complicated bunch of rules to decide whether a transaction can be received into our mempool. These rules try to make sure a node can't get DOSed with infinite replacements; try to make it so that what gets into the mempool is "incentive compatible" with mining, i.e. that a rational miner would actually choose these transactions, and try to make it so that pinning as described above is either impossible .. or really hard? (not sure). This TRUC thing will be a new tx type which, if you opt into it, you can't have a chain of unconfirmed txs .. like tx1 is unconfirmed, then you add tx2 which spends from tx1, then tx3 spends from tx2 etc. etc.; TRUC would only allow tx2, not the ones after. That will make some versions of pinning not work, if I understand it correctly. Perhaps someone can expand on that last bit.
My original comment was along the lines of 'trying to understand and reason about whether a transaction can confirm is just getting more and more complex the more we understand it, which just illustrates that relying on penalty mechanisms like in current LN is really painful because of the game theory stuff'. not a criticism of this proposal, as I said, it does at least *try* to *restrict* how complex things can be, but it's arguable whether it achieves that goal, I think (because it's adding another way for txs to work .. but .. if everyone takes up this new ruleset for LN stuff then perhaps not? I don't know).

2024-10-11 16:32:20 GMT

Just discovered BIP431.
My reaction is to be reminded of Shakespeare's "oh what a tangled web we weave, when first we practise to ... use game theory instead of cryptographic verification."
At least *restricting* scope (TRUC) makes the scope of the problem.. less intractable? Even that seems debatable.

2024-10-10 20:03:01 GMT

- reply

Oh interesting setup!

2024-10-10 19:06:46 GMT

- reply

Sorry only just noticed this ping.
Well, I think so, yes.
ZkSNARKs approach will be better for small, defined groups (more efficient).
For cases of very large spontaneously defined anon set from blockchain that isn't possible hence aut-ct is worth looking at.

2024-10-10 19:00:48 GMT

- reply

Christof Paar does indeed seem like a good recommendation... i remember skimming that book but not getting it for some reason, but his lecture course on YouTube is really good and quite popular.
For EC stuff I'd recommend Washington ("Elliptic Curves Number Theory and Cryptography 2nd ed " easily accessible online). Stuff by Silverman and Galbraith is more thorough and i guess suitable for graduate mathematician researchers, but Washington is already pretty heavy in mathematics. To be clear, it's often better to treat EC as a black box (discrete log hard group is mostly all we care about, except some details like serialization).

2024-10-10 15:45:49 GMT

- reply

Not sure on history. Simon Singh's 'the Code Book' was decent on that, but it's popsci, so fairly light.
For learning fundamentals of modern crypto in practice I'd recommend Serious Cryptography by J P Aumasson.
Boneh and Shoup give you a lot of solid grounding for serious study (e.g. security arguments) in toc.cryptobook.us
Work through the cryptopals challenges if you like hands on learning.

2024-10-09 22:54:13 GMT

- reply

Oh, i had no idea about tge routing distinction, that's interesting.

2024-10-09 22:43:07 GMT

- reply

Thanks.
Not sure it's easy to improve, but esplora lookups aren't as good as monitoring with home node, right? Kinda intrinsic to not having a home node. Just a first thought. Also this model used by phoenix and alby of single channel connection to LN obv has huge advantages but has a privacy tradeoff right.

2024-10-09 22:24:27 GMT

Just installed #alby hub alongside my home node.
https://guides.getalby.com/user-guide/alby-account-and-browser-extension/alby-hub/alby-hub-flavors/desktop
Interesting experience; I did not opt for the purist route of own LN and BTC node (not sure how purist that actually is, in the end) but the more 'default' option of LDK talking to esplora (as I understood). Very interesting how different the modern onboarding experience is.
Of course even this is a bit too much responsibility for most users most of the time (an always on PC!). Cloud hosting makes sense, but I think the fee will put people off, a bit (no judgment).
All of this is super lax privacy wise to be clear. Even more so than my every day expenses LN wallet, Phoenix.
As a result I've finally reenabled zaps for myself after more than a year's hiatus 😄

2024-10-09 22:00:18 GMT

- reply

Bitcoin Core.
Most of Electrum is command line usable as I recall. A little less detailed documentation.
Core CLI is the closest you'll get to the 'swiss army knife' experience, though it can be very arcane.

2024-10-09 20:54:07 GMT

- reply

Isn't this Amir Taaki's tweet?

2024-10-09 16:05:20 GMT

I've rewritten the second half of this substantially, since it had several non-trivial errors; sorry for anyone who got that far 😄. I think it makes considerably more sense now ...
#nevent1q…2fxx

2024-10-08 20:07:20 GMT

- reply

For the JM part, the taker will always know the maker linkages, independent of the network level isolation. There is no Chaumian blinding.

2024-10-08 16:53:35 GMT

- reply

Part of that price we pay for true permissionlessness. There is no foundation, org, or person to stand up for them.
Decent people have always recognised that what you say is correct, but not all people are decent.

2024-10-08 16:38:29 GMT

- reply

Unfortunately had to migrate recently, so most are currently not online, but i will bring them back (sadly cannot migrate purely automatically).

2024-10-08 16:29:21 GMT

New blog post
https://reyify.com/blog/adaptors-generalised/
... been thinking a lot about this topic, on and off. Not sure about potential applications to onchain verification of ZKPs, but *any* ability to lock bitcoin state transitions/payments to proofs of statements that are not restricted to a single generator G, feels like it could lead to some important new protocols. But this being interactive is clearly not as good.

2024-10-06 22:40:36 GMT

- reply

Pretty bad/sloppy takes mixed in with decent analysis there. 'Joinmarket is an old version of ZL' .. no, not even a little bit true. 'Joinmarket is not usable except by devs' that one's more just a matter of opinion, but it's pretty bad to not even mention JAM plus the other client(s) joininbox of @npub14tq…hy62.

2024-10-06 21:06:11 GMT

- reply

Hmm could be Ukrainian though .. that would make that combination slightly less surprising.

2024-10-06 21:01:16 GMT

- reply

2024-10-05 18:40:37 GMT

- reply

No, looks interesting. Censorship resistance is pretty clearly going to be far weaker in such a system just by common sense. And btw "private because nobody is looking" is not a good summary of what I was saying there :)

2024-10-05 16:51:56 GMT

- reply

Vpn paid for with a LN payment. E.g. https://lnvpn.net/

2024-10-05 16:48:14 GMT

- reply

I might argue that inability to unambiguously calculate an anon set is a positive - systems which don't create permanent global records of usage are ceteris paribus *more* private.
There are obviously counter arguments. But I will say that, the fact that LN is fast and cheap is the 'special sauce' that makes its particular version of privacy attractive to me. Many academic studies have already pointed out ways it can be attacked actively, it is true, so I don't claim it's even close to perfect, but it actually has 'cover traffic' in the loosest sense by being fast and cheap, and for everyday users that may end up mattering more.

2024-10-05 16:06:16 GMT

- reply

It's hard to recommend one thing, there's a whole stack of knowledge that this stuff is based on, and it depends what you're already comfortable with. For example if you wanted to learn STARKs (as I do, but haven't yet), there's a whole different bunch of mathematical machinery compared with SNARKs or Bulletproofs. This uses the latter. You could do worse than read my old doc that slowly builds up the concepts behind bulletproofs, including what 'ZK' means: https://github.com/AdamISZ/from0k2bp . You can look for detailed books that cover all the preliminaries like the "moonmath manual" (search it), or shorter more conceptual things like Matthew Green's cryptography blog that has iirc a 3 part intro to ZKPs. You can find much more rigorous academic stuff like the Crypto Book of Boneh and Shoup which gives pieces of the picture but isn't yet completed. You can read Vitalik Buterin's old blog posts explaining zkSNARKs from the ground up (he's always been a really good technical writer, one of the best actually). And at the end of the day, the academic papers will really help too. If you need more general cryptography knowledge, different recommendations would apply :)
Btw on bulletproofs specifically look up the dalek cryptography blogs/docs, they are the best in terms of details, diagrams.

2024-10-05 14:37:56 GMT

- reply

Re: the 55MB file generic/custom: it comes from parsing the taproot-only utxo set at a particular block height (you see that in the filename). It's a list of curve points, each one of them is basically P + vJ where P is the taproot pubkey of the utxo and v is the value in satoshis of the utxo. It's also filtered with minimum value to prevent being too large. Also it should be half that size (and that's one of the largest I've seen so far) because I never bothered to change it from hex to binary.
The processing takes time: yes, this pre-processing step, which reads in and modifies the curve points, is currently more friction than we'd like. That one took 4 minutes for a 440K key set. For some applications it might be fine to have this setup, then run a daemon in the background so that you can keep verifying instantly, but for this one, maybe not. Farming this out to others, I'm not sure if there's a way to do that that's more interesting than have the "other" do the whole verification. Maybe? Also, it *might* be possible to have the proof size be larger (e.g. 1MB instead of 10kb) and then the verifier only needs the tree root, but it's a significantly different algorithm and I'm not sure about if/how that would work.
The range: the range here was a from a chosen minimum of 1 million sats to a maximum of 1 million + 2^18. The minimum is completely prover choice. The range being a power of 2 is because ZKPs of range are most efficiently done as "prove that the number has the following bit representation", hence a power of 2. My feeling is that k+2^n is flexible *enough* but with some extra machinery you could make it more flexible (you can also change the base from 2 to 3 or whatever, but that doesn't help a ton I think).
Window for cheating: as above it's a utxo snapshot at a certain block. It isn't valid for any other time. So frequency of checks can't be that fast. Now I think about it, that is a big drawback here, if you want real time checking.
I'm not sure what your "custom to the prover" sentence was really asking. As per above ,the keyset/snapshot is generic for everyone, it's a snapshot of a blockheight. The prover and verifier have to agree on: the block height, and the minimum value filter, so that they have the same keyset file. If you try to verify a proof with a different keyset it just doesn't verify, even if the utxo is shared between the two conflicting keysets, because it's a tree like a merkle tree, and the roots won't match.

2024-10-04 20:48:34 GMT

- reply

Lightning works very well for this use case.

2024-10-04 18:43:02 GMT

Question for @npub12rv…85vg and others who work on ecash mints: is this kind of thing potentially useful for you guys (see linked post at the end)?
The reason I'm unsure needs unpacking: first, I've always been lukewarm on ecash as a generalized money (see my old London talk on the topic for a 2 hour expansion on that :) ), but I think both that the technology is really cool, and that there are niche use cases where it probably fits very well. So part the obvious reason for being lukewarm is the trust in the mint and that, even if you can figure out any kind of audit of reserves that makes sense, it wouldn't *in itself* prevent the possibility of absconding with user funds. Still, that doesn't mean auditing is useless; it could function as a stabilizer (and .. you can make various arguments).
So, given that context, my suggestion of this kind of *private* audit of reserves is, I can imagine there being a future where mints have to be purely pseudonymous to some or other degree, to avoid attack by the state, albeit this makes trusting them complicated. In that case, it would not be ideal if audits of reserves actually showed a blockchain fingerprint. The advantage of the private-proof-of-taproot-assets protocol I described there is, its' super fast to verify so it should in theory be really easy for the mint's clients to check it. (as opposed to other ZKP techniques which could be super cumbersome here).
#nevent1q…fpwp

2024-10-03 23:18:56 GMT

- reply

It took me a good 15-20 minutes, seeing Qg2 was quite hard, and so was seeing that moving the bishop back to its starting square is mate :)

2024-10-03 22:10:43 GMT

- reply

Bh1! If b6/b5 then Qg2; if Ra8 then Ra8. if e4 then Rg5. And if f6/f5 then Bd5.
Pass the prize on to the next puzzle :)

2024-10-02 16:40:45 GMT

- reply

Understood. I agree it's a can of worms to do it at scale. Maybe for some smaller scale projects it can be a valid choice.

2024-10-02 16:38:34 GMT

- reply

Porque no los dos? :)

2024-10-02 16:25:43 GMT

- reply

Re : "No, I don't want to reconstruct the key", I don't really understand; I didn't use the word 'reconstruct' in that. "I just want these providers to construct sigs safely which apparently FROST can do". But the point that's at issue here is you want them to do that with *your* key. FROST and MuSig both allow multiple parties to collaborate to create signatures safely, with the main difference being that the former allows it for t of n and not only n of n. *Neither* provide for the key to come from some central party. As for distributed key gen, yes they both do it, they have to; but they do it in radically different mathematical ways (because of the t of n requirement for a start). And retrofitting them to allow you to start with a key "x" and then split it up and give it to them probably can work, but my caveat point is, if you care that they can collude to take the whole key, between them, then that's not great.** In FROST's case, it happens to be polynomial evaluations that you share, but it's still designed so that t of those shares (in a t of n scheme) are enough to reconstruct your signing key.
**In any such collaborative signing scheme, by definition, the key can be reconstructed by the authorised threshold t, because they can share their nonce contributions and extract the private key using the nonce. This isn't usually discussed, but here we have an external party that'd prefer not to be attacked by the group, so to speak.

2024-10-02 16:19:10 GMT

- reply

About initial setup/delegation, my thinking is: a protocol could allow you to delegate authority to do specific things (like sign) by a direct signature on your main key saying "this sub-key is authorised to sign these events" and then that subkey could be generated collaboratively in a normal way. Common way of using digital signatures (delegation to another key), but admittedly it can be a can of worms...

2024-10-02 04:24:39 GMT

- reply

Pretty sure I agree that FROST is closer to the mark in what @fiatjaf is looking for, but specifically the signing algorithm and not the keygen algorithm. FROST (and Pedersen DKG before it) were advancing the state of the art by allowing for no central party (or aggregator/dealer) to be in possession of the whole private key at any time, either in key generation, or in signing. Here I guess you want to reset back to the earlier SSS basic idea of having the central party know the key in advance, then construct the individual shares such that they sum to the pre-existing key x, instead of following FROST's KeyGen to generate the shares.
But the "massive caveats" I mentioned in the other post still apply; it seems unlikely you'd want to allow the possibility to collude to take your full key.

2024-10-02 04:02:36 GMT

- reply

OK yes I see. It seems difficult because a musig aggregated key is not a linear sum, to avoid the possibility that less than N can forge a full signature using key subtraction attacks. Constructing the key is an interactive process that produces an unpredictable final key, by design.
Perhaps you can attach a proof of knowledge of each "key portion" works though: you distribute secret keys x1, x2 and x3 such that x1 + x2 + x3 =x, your key. Then when they go through the signing process they add a signature over their key portion at the start. This prevents them from doing key subtraction to forge with < N parties. Then they can go through the normal process of 3 round MuSig - commit to their R portion, then reveal their R, then the final signature on P is the sum of the signatures on P1, P2, P3. Two obvious problems stand out: they can collude to extract your full key; usually that is not acceptable. And of course the fact that signing becomes interactive.
Overall it doesn't seem very practical, and heck, don't even quote me that it's possible or sound, I'm not sure. Even with the massive caveats above. Various kinds of delegation or setup with the initial key, whether using existing FROST or MuSig, feel like they make for a sounder approach.

2024-10-01 23:28:10 GMT

- reply

Great work.
I agree that of the several fascinating things about the story, the depositing of 5M in cash to a bank, is the most incredible.

2024-10-01 23:14:49 GMT

- reply

Lol. Good point. But what is good here. Don't traffic lights go yellow (amber) to green?

2024-10-01 23:13:03 GMT

- reply

I remember thinking "I don't know if that's possible" but also thinking "does that question make sense"? If i use some xor/whatever to make 3 shards, don't I still have the original secret key. If that doesn't matter, and you just want the others to attest, or something, then just use their own keys? I guess I just don't get your point.
Obviously both N of N and M of N collaborative control of newly generated keys is well understood (albeit a bit complicated!).

2024-10-01 23:06:52 GMT

- reply

Vid appears to be working here, let me know if it doesn't load for you, I'm curious.

2024-10-01 23:01:49 GMT

This is a 4 minute vid demo-ing how to verify the 'private proof of assets' using a desktop app. See https://reyify.com/blog/privacy-preserving-proof-of-taproot-assets for details and links.
https://video.nostr.build/8893d5a569ebec61c4cbbde491882159d9fda0ef35dc99cb78455c17033cd698.mp4

2024-09-29 20:34:14 GMT

- reply

Definitely not my area but after a bit of reading it seems like this blog post does a really good job of explaining the pretty complex reasoning behind the double ratchet (used to be 'axolotl') setup:
https://signal.org/blog/advanced-ratcheting/
It seems like they're trying to address the difficulties of *asynchronous* messaging (users often offline for a while), as well as both forward and 'backwards' secrecy.

2024-09-26 18:01:05 GMT

- reply

No, there are several variants of ecash, most based on blinded Schnorr signatures. Cashu uses a different algo, based a kind of blinded Diffie-Hellman, similar to that used in privacypass.
Fedimint uses blind signatures plus federated mints.

2024-09-23 18:38:58 GMT

- reply

Good points.
Covenants 'open the door' to doing a whole range of things *trustlessly* or *efficiently* that are currently already being done inefficiently and/or with trusted third parties...

2024-09-23 18:34:32 GMT

- reply

Sorry that last part about snapshots was dumb; not that it isn't a valid idea, but in no way is it some kind of peg, because it's new issuance, even if controlled. The two way peg concept is the most interesting, and it seems really unclear/difficult with bitvm (given fraud proos onchain a la arbitrum) (not that i know any easy way!).

2024-09-23 16:39:43 GMT

- reply

Interestingly, something I've just worked on could help with that: issuance based on a utxo snapshot could be made private with https://reyify.com/blog/preserving-proof-of-taproot-assets
... but it could also be simpler, without privacy. Don't see the need to burn, a la spacechains, if you just use a one time snapshot.