pull down to refresh
10 sats \ 1 reply \ @027c352e45 15 Jul 2023 \ parent \ on: SegWit explained in 4 slides bitcoin
A witness can be thought of as basically a piece of data that gives a concrete proof for a claim you're making. Like imagine i claim '91 is not prime'. The witness could be (13,7) because anyone can verify that those are the factors. Note that for some problems, there is more than one solution, so multiple witnesses might be valid.
It's not hard to see that 'i have control of this utxo' and a signature (or more generally a script) could fit that same template. With ecdsa/schnorr digital signatures, more than one signature is valid.
About the segregation: this is all about how you uniquely identify transactions. A fully valid transaction includes a list of inputs, a list of outputs and thirdly a 'witness' (as above) that the spending of each input is authorised by its owner.
If you hash all 3 of those and use that as the txid, you lose uniqueness; by changing the witness - using a different, but still valid, signature - you will change the hash, but the transaction will still be valid and accepted by the network.
So instead, segwit removes that third part, the witness, from the hashing. The txid only refers to the inputs and outputs, not the witness.
This means that the txid fixes the actual financial transfer, but is not affected by how it is authorized. This is how it should be.
Finally, three practical points: 1/ the witnesses are stored in a separate part of each transaction, not in a separate part of the block, as some people erroneously say (how would that even work!?), 2/ in ECDSA it is possible for another person, not the key holder, to create a different signature, so txids depending on it really can be a disaster (see 'malleability'), 3/ lightning actually really depends on removing this malleability, it wouldn't work otherwise.
Ok, I finally get it. It's not about any material change in the signature or the transaction, but rather, the transaction hash does not include the signature.
Maybe I am muddling it up again but just intuitively I guess that "transaction hash" should be... you know... of the transaction.
Why exactly did they decide that the size of the ... if I am understanding it correctly, signature data, should have some kind of size limit on it other than the 1mb virtual bytes rule?
The signature is what joins the out points and the in points of the transaction. It's illogical to derive a unique identifier for a transaction that is based also on the signature that authorises it. Because there is always, and MUST be a random value in the signature or you have this pesky preimage problem. In my current exact task on Indra I have got signed advertisment pieces that have to be signed to be trusted (by the identity key of the peer) and they always have to have a different 64 bit value in there to make sure there isn't a leak of the private key bits.
I seem to recall that someone found a bunch of old wallets that had been generated with buggy code that signed on identical hashes repeatedly, leaking the private keys and with HD keys and secp256k1 curves if you break a child key and you have the xpub you can get the original seed quite cheaply. The article didn't point that out but fortunately some actually knowledgable people in the subject of cryptography pointed deeper into the article where they basically say that they could do this because the cryptographic protocol of the wallet was not using different values in the signatures.
Ah, 20:20 hindsight eh? Well, let's hope we aren't in line for future to write code that loses people money eh?
Also, why is there no limit on witness data???????? wt actual f??
reply