waxwing's avatar
waxwing 1 month ago
Gave a presentation last week on "purecoin", showing basically how ~ 50% embedding rate in "pure" bitcoin transactions with no scripts is inevitable *even if* you force the outputs to prove they are not "fake". 'Fraid the audience had no idea what I was talking about, so I'll post the pdf here: https://files.catbox.moe/tpfc4x.pdf I must apologize for calling it a "very hard fork" because you could actually do it as a soft fork (thanks @Giacomo Zucco ) but it's hardly relevant. The point is that there is no version of Bitcoin, even a 99% crippled version of it that doesn't allow L2s, that does not allow data embedding, *except* one in which we completely change the cryptography to BLS (any deterministic signature scheme could in theory do it, but nobody is going to seriously suggest hash-based signatures or RSA FDH I think) (thanks @Zero-Knowledge Goof for thoughts on this), *and* totally cripple any programmability. And since quantum is coming (so they tell me!) I see basically no chance of this happening. #bitcoin #cryptography

Replies (9)

The link isn't working for me, but does it have anything to do with answering the question below?
npub1wuhe...h6ym
@npub1xtsc...kk5s True or false: there is no conceivable way to prevent steganography in a digital cash system. If true, is it because there is inevitably an "amount" input that can be (ab)used for this purpose?
View quoted note →
waxwing's avatar
waxwing 1 month ago
I think the site is blocked in certain countries like UK. I should have hosted it on github but tbh there's only a few slides, it only helps a little. Basic ideas already on the bitcoin mailing list "on (in)ability to embed data in Schnorr from a few weeks ago.
waxwing's avatar
waxwing 1 month ago
Re: your true or false question: i think the answer might be: technically it's surprisingly false, but it requires almost absurd total redesign of bitcoin; see our discussion here:
Zero-Knowledge Goof's avatar Zero-Knowledge Goof
Has anyone tried developing a soft fork that would actually verifiably stop all spam? 1. Make a new address type that has a public key + proof of knowledge. 2.5x larger than current addresses. No script nothing else. 2. disable spending to anything other than the new address type. Spam solved. You could modify (1) to allow raw multisig also. You can actually do lightning without script using MuSig + adaptor signatures. So everything keeps working… in theory :)
View quoted note →
waxwing's avatar
waxwing 1 month ago
And indeed: amount field represents an especially big challenge to prevent embedding, but to be fair it is small and could be smaller. I considered it but keys/signatures are the crucial part.