Haha BLS everything of course. I can’t even imagine how you could do it only for the PoK. Any equivalence proof between curves will be a PoK so there’d be no point in the BLS in the first place.
I like “purecoin”. Although I also think it’s not a great direction. It’d still make way more sense than bip444. It would be interesting to present a possible if not realistic soft fork that actually would significantly reduce the amount of data embedding that could be achieved per vbyte. Then a rational debate could be had.
Point taken about locktimes. I don’t think anyone would be in favour of disabling lightning. You’d probably have to leave the spammers with that one.
Login to reply
Replies (4)
Oh also public derivation could work with the BLS scheme I think. Just don’t commit to the public key in the hash to curve for the PoK and it becomes malleable.
OK. But my gut would tell me that malleable (not pubkey prefixed) BLS sigs would be unsafe. I'm assuming by PoK you do mean BLS sigs. Wouldn't you be able to forge sigs on related keys?
I agree it would be nice to prevent this somewhat formally, because I think there's some quite woolly thinking about "it's impossible to prevent data" without concrete analysis. Btw, even purecoin suffers also from amount fields being plaintext: though it's tough, a well funded 'spammer' can probably get a number of bytes of data on chain with a "split and then recombine a large single utxo" strategy. It's an extremely low data embedding rate on a per tx basis, but it's not nothing, assuming we succeeded in getting rid of locktimes, and pubkey and sig embedding. If we encrypted amounts we might hit the old 'zk implies randomness implies embedding' problem again.
'present' not 'prevent'