pull down to refresh
41 sats \ 2 replies \ @crrdlx 15 Jul 2023
Wait, 3 slides embedded inside 4 slides? That's 12! I've been scammed by the title!
(just kidding) One thing though, the 3rd box on slide two, I'm pretty sure the red arcs are going to the wrong places. Seriously, though, great graphic.
reply
10 sats \ 0 replies \ @elvismercury 16 Jul 2023
Nice catch!
reply
1 sat \ 0 replies \ @AR0w OP 15 Jul 2023
Yes actually youre right
Was an error
reply
0 sats \ 0 replies \ @iguano 15 Jul 2023
nice, thanks for sharing!
but those are 12 slides :D
reply
0 sats \ 0 replies \ @MisterCoins 15 Jul 2023
Bitcoin Explained Podcast episode that explains “The Witness Discount”
https://fountain.fm/episode/VQAVfgmv3HLdKhaYEubf
reply
0 sats \ 2 replies \ @l0k18 15 Jul 2023
I still don't get it. "witness program" sounds like it should be code, but that's not what it is, is it?
The general impression I got was that the signatures are stored in a more compact form, thus "segregated" and these are stored separately in the block as the key to proving the spends of the inputs that went into the transactions.
They are cheaper because some kind of coding matrix is used to compress the witness data size, and plus, their size is counted as lower per byte than the transactions.
It's that "segregation" that most people are not going to understand, explaining how it is segregated, and what witness refers to - witness means not the actor but one who documented the actions.
If someone can make simple explanation of what Segregation means and what Witness means precisely then maybe I'd get it, but otherwise it's opaque, weird terms that I can't relate to anything.
reply
10 sats \ 1 reply \ @027c352e45 15 Jul 2023
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.
reply
0 sats \ 0 replies \ @l0k18 15 Jul 2023
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
0 sats \ 1 reply \ @byzantine 15 Jul 2023
is 3rd slide second row mislabeled?
reply
0 sats \ 0 replies \ @l0k18 15 Jul 2023
yeah I don't think the lines match the symbols but they are in the same order top and bottom.
reply
0 sats \ 0 replies \ @03c43494a9 16 Jul 2023
deleted by author
reply