Nostr Web Client

What's this "mishandling of Segwit and Taproot" that you're referring to?

You mean the changes were technically flawed? Or you didn't like the activation processes? Or something else that I'm missing?

(Minimal paranoia please)

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 3mo ago 💬 2

segwit enabled a cheap spam vector. taproot also opened up a vulnerability.

i don't think segwit was intentional but i was in the schnorrr signatures camp back in those days. IMO segwit needs to be deprecated and people encouraged to move their UTXOs to taproot. taproot still hasn't achieved full penetration yet, but the benefits of taproot are manifold, not the least of which being full channel open privacy and improved coinjoin transaction sizes since multisigs only take one combined signature for potentially hundreds of signers.

taproot also was unnecessarily complicated on the API side. simply using taproot signatures (schnorr) is obfuscated by the API, because of the "tweak" thing. that tweaking is for smart contract sub-addresses. but you can perfectly well use taproot as a simple HD keychain as well, since tweaking and HD path derivation is much the same type of thing

Reply to this note

Please Login to reply.

Discussion

epsql 3mo ago 💬 1

What about P2TR addresses exposing the public key? Wouldn't that be quantum vulnerable?

SatsAndSports 3mo ago 💬 1

Thanks nostr:nprofile1qqsdlumwtmnqqdqnhzn2yc2azuftg57z380wq47fp62pds7tme2n7gspzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtc4j5yaw for giving an answer with some details, and nostr:nprofile1qqsptacwh5c0dxu9hw58c0ky2eznqrwzsddxmtprtl0czs72kh5jstqpz3mhxue69uhkuethwvh82arcduhx7mn99uqjqamnwvaz7tmzd96xxmmfdekkz7rfd4skc6tnw3ejummwd35kuef0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uwkfddv for raising the quantum-resistance point about TR

While witnesses have a discount, normal monetary transactions also benefit from the same discount as they also use the witness

What concretely could be done differently? Maybe the discount should apply only to small witnesses, so that larger - potentially spammy - witnesses pay more? (It's too late to include this change to the discount rules, as it's a consensus change, but I'm just curious to discuss these issues to learn more)

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 3mo ago

segwit should be deprecated and wallets should encourage users to move their UTXOs to taproot

quantum resistance is a far future risk. the best option we have currently for switching to quantum resistant signatures and ECDH is an algorithm called VDOO which has 96 byte signatures. so such an upgrade is not really feasible before 5 years when there might also be low enough storage prices to justify such a switch. the danger of bitcoin addresses being cracked is completely unrealistic in the short term (less than 10 years). the smallest economic UTXO to attack right now is over 800btc and it would take about 2 weeks to do it, assuming someone builds a big enough machine to do it, which is gonna cost upwards of 50 million dollars in the first place, plus that much again to power it for such an attack.

also, segwit witness discount does not make transactions as much cheaper as taproot. taproot can combine multiple signatures allowing many UTXOs to be merged with only one signature block.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 3mo ago 💬 2

ecdsa and schnorr signatures are both vulnerable. there are no signature algorithms with as small data size as these algorithms, smallest post-quantum signature algorithm has 96 bytes, most others are upwards of 600 bytes long. every transaction has one so a quantum upgrade would probably not even use any of the ones that are known currently, but something in the future when someone figures out a compact signature for post quantum algos. lattices are too big, multivariates are better, and there is also the possibility of short coding algorithm signatures, as well as hash based signature schemes that use similar techniques as merkle trees.

taproot addresses don't expose the public key until spent same as other transactions. the address is the hash of the public key, which is verified when signed by revealing the public key. this is why you should not reuse bitcoin addresses.

epsql 3mo ago

"the address is the hash of the public key"

I'm not sure this is true for P2TR though, as per https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-2

Maybe I'm misunderstanding what you mean exactly?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 3mo ago 💬 1

no, you are not. and this is super gay.

this means there is zero protection against brute force or quantum attacks to reverse public keys.

this is why i hate taproot. why could we not just have schnorr signatures on regular P2PKH? there's no upgrade path away from segwit with this horsecrap. i already hated the way that the APIs about taproot force you to specify a tweak. so now i see that every tx you make reveals the public key immediately. i doubt that their logic about why it isn't hashed washes technically either. it should have at least been a fucking sha256 hash. why not? just why FUCKING not?

all of the changes starting with segwit have been a downward spiral.

i think there should have been a simple single schnorr pubkey hash anyway. that's what segwit should have been.

i'm gonna have to read closely through the state of bitcoin signatures and transaction formats to try and figure out if there is some hole to push something else in there that isn't this abomination. for some time to come, bitcoin's main transaction type is going to be single signature and not multisignature, and the logic of taproot signatures is based on not differentiating, so you put the pubkey at the out points instead of address hashes, and instead of reveal signatures you need the pubkey to validate the signature. after all, taproot is permitted but not understood by pre-taproot nodes, probably there is a way to do non-taproot schnorr signatures while remaining valid to old nodes but only limited to needing a wallet that can verify the signatures.

i have thought about the idea of making a nostr event format that throws away the ID and pubkey and using reveal signatures (like segwit and legacy do, the hash combines with the signature and produces the public key). it would be very neat and compact for saving a full 256 bytes of data in nostr events. make the signatures base64URL and they are also only 86 bytes instead of 128. this would leave enough space for a check on it with the extra 40 bytes, merely 240 bits, hardly even truncated, which would then serve as verification and the signature and fingerprint would take the space of one hex signature and provide identification and message authenticity. you hash the revealed pubkey, and then compare to the fingerprint, and if it matches the pubkey is correct and the message is authentic.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 3mo ago 💬 2

i stayed up way too late last night to learn about how schnorr signatures work.

the pubkey is effectively like part of the signature value, in fact. probably satoshi chose ECDSA because it was easier to find but also for being able to use pubkey hash construction but you can't do that with schnorr.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 3mo ago

this is the tradeoff that schnorr gives you:

no signature malleability, the pubkey X is like a malleability protection.

the pubkeys must be in the spend transaction along with the signatures on the out-points being spent.

so they are not so much smaller in size than p2pkh transactions actually. in fact slightly larger

epsql 3mo ago

I believe Schnorr could not have been used at the time due it being protected by a patent, which seems to have expired only in 2010 according to Wikipedia