1 2018-06-26 01:04:00 <weiyang> I am curious about how segwit reduce the transaction size. For example, when I look at the raw data of https://blockchain.info/rawtx/de3a7c36bdb50479fc77f4fd31b6042bf85ecade46c5676949946b52847255b3, each input has a "witness" field. Compared with put it in "script" field, I don't see the benefit of segwit.
 2 2018-06-26 01:04:20 <weiyang> Hmm... do I miss something?
 3 2018-06-26 01:05:23 <weiyang> And some input has both "witness" and "script" field. What is this for?
 4 2018-06-26 09:44:22 <AndyS2> weiyang: there's two different things we could talk about here. either why the new payment schemes like P2WPKH might be a few bytes shorter (or longer) than with older style bitcoin transactions
 5 2018-06-26 09:45:00 <AndyS2> weiyang: or why segwit allows for blocks to be larger than 1MB, and how that makes SegWit transactions smaller within that 1MB limit.
 6 2018-06-26 09:45:55 <AndyS2> basically (and I'm usually not that strong on details, so bear with me or wait for someone to correct me ;) )
 7 2018-06-26 09:46:32 <AndyS2> stuff that goes into the script or scriptsig field is an immediate part of the transaction, and has to reside in the 1MB part of the block
 8 2018-06-26 09:46:52 <AndyS2> stuff you put into the witness field is segregated into a different part of the block that old nodes/old consensus rules don't see
 9 2018-06-26 09:47:10 <AndyS2> so there's no hardfork if you run an old node
10 2018-06-26 09:47:45 <AndyS2> and because data in the witness field is counted differently (it's still counted, so not free, but only with 1/4th compared to the data in the 1MB part)
11 2018-06-26 09:48:32 <AndyS2> some people (maybe incorrectly) claim that such a transaction is smaller.
12 2018-06-26 09:50:57 <AndyS2> There's a few cases where SegWit transactions are actually smaller, btw. That's because with segwit, we detect the kind of script that needs to run by using version bytes and the length of an output (IIRC). instead of pushing the real, potentially longer script into the script-part of an output.
13 2018-06-26 09:51:59 <AndyS2> sorry, not the length of an output. I'm actually not so sure anymore. I think it was the length of the witness that is being used when spending an output.
14 2018-06-26 14:56:49 <roconnor> achow101: from BIP 174: "If duplicated keys are encountered, the software may choose to use any of the values corresponding to that key."
15 2018-06-26 14:57:11 <roconnor> Ambiguity is breeds security vulnerabilities.
16 2018-06-26 14:57:35 <roconnor> how about "If duplicated keys are encountered processing MUST abort with an error."
17 2018-06-26 18:03:44 <achow101> robzon: right. combiners will inherently encounter duplicate keys though when combining, and they will need to choose one of the values. but for a given psbt, I suppose it should fail for duplicate keys
18 2018-06-26 18:37:30 <roconnor> It seems if we do the protobuffer compatability thingy suggested on the mailing list, then protobuffer has specific semantics for duplicate entries.