On public keys and frozen hearts:

Recently, I was discussing with #[0] the other day, about the slightly disappointing fact that BIP340 Schnorr stopped us from being able to do pubkey recovery.

(Sidebar: what's that? In ECDSA, since s = k^-1(H(m) + rd) where d is the private key, so that ksG = H(m)G + rP, it means that P can be calculated from r^-1(sR-H(m)G) .. so, given a message m and a signature (R, s) you can always find a/the pubkey that makes the signature verify, even though you don't know its private key (d)).

There's a good reason that this property is explicitly broken by BIP340 "key-prefixed" Schnorr, though (but *not* by Schnorr's original algorithm from the 1980s). It's because it violates a crucial cryptographic principle used in the "Fiat Shamir transform", which turns identity protocols into non interactive proof of knowledge protocols (which signatures are a type of). The principle is "the challenge hash must cover the entirety of the conversation between prover and verifier that preceded the challenge". That conversation *must* include the communication of the pubkey in cases, like bitcoin, where the key is ephemeral and not a global, fixed constant of the system.

Where this can crop up is in cases like elucidated in Sec 4.4 of this paper: https://arxiv.org/pdf/2006.16714.pdf , quote "If the signature algorithm did not commit to the public key, then an attacker could claim any Taproot

spending conditions, and a watch-only wallet could maul signatures for one BIP-32 key tree to be valid for another.".

I went into this point in some detail in the middle of https://reyify.com/blog/ring-signatures (see "Tweaked s values on fixed message and tweaked keys" .. you can malleate a signature both additively and multiplicatively) ... once you see this it's really clear that key-prefixing is an absolute requirement.

But this has cropped up outside signature schemes, too. For example the Bulletproofs paper had an error in this regard, where a key was left out of the transcript committed to, and so did several other implementations of new ZK schemes. This point was covered in considerable detail in this rather wonderful "Frozen Heart" writeup:

https://blog.trailofbits.com/2022/04/13/part-1-coordinated-disclosure-of-vulnerabilities-affecting-girault-bulletproofs-and-plonk/

Not disagreeing, but i think it's not an accident that we struggled so much to make bitcoin wallets that feel 'right'. It's because it's not a consumer payments network, it's intrinsically an industrial layer, or a settlements layer. Notice how quickly many LN wallets developed a clean UI. (though of course there's a shitton to be improved there, still!)

That's a nice optimistic thought. I feel like two factors will be pivotal in whether that works out: Bitcoin, and China.

There's a bitcoin meetup at la casa del bitcoin in Escalon in San Salvador tonight, for anyone in town that didn't know:

https://www.eventbrite.com/e/mi-primer-bitcoin-meet-up-tickets-548074915827

All that might be obvious. I'm guessing you're more focused on the idea of assigning scores, not on censorship.

For that, I guess there's nothing to debate - it can't be stopped! I'm more doubtful than you though, that it will get traction ... probably just lacking imagination here.

Interestingly enough my talk was actually called "Identity is the problem", so I was largely making an opposing point (or at the least, a different one) ... I think "solutions" to Sybil attacks based on identity are largely bound for failure.

I guess filtering in online discussions is another discussion (with overlap ofc). For that I'm mostly in agreement with what you say here. I just don't understand why for the whole microblogging/social media thing we don't have user-controlled algorithms for feeds. Fediverse/activity pub is in the same boat as nostr there, I see no reason why it couldn't happen other than it's fairly sophisticated engineering. I guess users mostly can't handle that cognitive load.

Personally I don't like blocking, I don't like tribalism and I'm a free speech extremist, at least people should understand that it's crucial as a principle to be upheld. So I'm mostly interested in how to block *spam*, and certainly not things like "intellectual dishonesty" ... whatever that is.

BIP340 usage in nostr *might* have interesting implications.

One, it means multisig is an automatic "first class citizen". You could have a group account where 5 people have to agree before a post goes up, and this requires *zero* protocol or client interface changes (just some sidecar software to do the co-signing).

(It also could mean use of signature adaptors to do weird things ... you can't get the 'atomic swap of money for message' quite, e.g. the idea of 'you can only post a reply by sending me 1000 sats', because there isn't enforcement of atomicity without multisig signing as per above. Maybe there's wiggle room there, not sure).

Good question, I'd like to know too, I get the vague impression it's not defined in protocol? and thus limits might be per-relay.

I posted something pretty damn long the other day (it was collapsed in my snort.social interface but readable fine). Why not just try? 😄

So my ln address seems to be working OK at the moment.

Can someone try using the 'zap' feature and send me some sats? I promise to send back an unspecified amount :)

Sats do not exist at all.

I wonder if anyone here knows what my issue with btcpayserver is, here:

I have the following in my most recent logs:

```2023-02-16T18:23:34Z UpdateTip: new best=000000000000000000003bd3cb6f0c27b8b2d0722e954bb8bb6ac0180bda30be height=776881 version=0x2452a000 log2_work=94.007934 tx=806119764 date='2023-02-16T18:23:28Z' progress=1.000000 cache=44.4MiB(338543txo)```

i.e. up to date, but in my btcpayserver admin interface I have the popup for "Nodes are synching" and it says "NBXplorer height: 0". Not sure what changed, this was working fine until about a week ago. This problem has persisted for days at least, and I tried restarting but it didn't change.

Interesting article, I was curious about one point: it says funds can't be seized if 2 parties are honest; afaik Fedimint started out with the old Gennaro/GKJ style threshold key generation, which is a bit funky in how its threshold security properties work (I actually raised this point with elsirion on discord (don't laugh) ... then it seems they followed up a bit, see: https://github.com/fedimint/fedimint/issues/760 ), so I'm not sure if it's already done, but they definitely want to use FROST. This avoids weird problems with majority (say, 9 of 13) threshold signing, which is what you want. But why does it say 2 there? I think I missed something.