Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Re: My Segwit questions - a Q&A for Achow and the rest
by
nullius
on 13/12/2017, 23:02:13 UTC
⭐ Merited by ETFbitcoin (1)
Hi Achow, did Segwit make the blocks more compact by removing the signatures from the transactions and placing them in an "extended block", and at the same time, maintaining the block size to 1mb?

Is that what it really did?

Another question. Where is the "extended block" stored exactly?


achow101 already answered your questions.  Fully.  Did you read his replies to you?

There are no "extended blocks". Blocks are the same as before; [...]

The signatures are stored as part of the transaction.

In other words, there is no “removing” of signatures as you say.  Now to elaborate on this, which you should read carefully:

What actually happened is that the block size limit was redefined to something called block weight. There is now a block weight limit, which is 4000000 weight units. Each byte of non-witness data (everything that a legacy node will see) is worth 4 weight units. Each byte of segwit data (everything that a legacy node won't see) is worth 1 weight unit. So if you use segwit, more bytes of your transaction will be in witness data than a comparable non-segwit transaction. So the weight of your transaction is lower and thus there will be more weight for other transactions in the block. That is where the capacity increase comes from.

Stop thinking in terms of “block size”.  The whole concept of a “block size” is obsolete.  With Segwit, there is no longer a block size limit at all!  Instead, as achow101 already explained to you, there is a block weight limit of 4000000 bytes:

Code:
/** The maximum allowed weight for a block, see BIP 141 (network rule) */
static const unsigned int MAX_BLOCK_WEIGHT = 4000000;

The above-mentioned “weight” calculation is specified by BIP 141:

Quote from: BIP 141
Blocks are currently limited to 1,000,000 bytes (1MB) total size. We change this restriction as follows:

Block weight is defined as Base size * 3 + Total size. (rationale[3])

Base size is the block size in bytes with the original transaction serialization without any witness-related data, as seen by a non-upgraded node.

Total size is the block size in bytes with transactions serialized as described in BIP144, including base data and witness data.

The new rule is block weight ≤ 4,000,000.

Aside:

Ok, sorry for all the dumb questions. As you have seen, I am not a technical person so the concept is a little hard for me to grasp.

There is no need for you to grasp it.  If you’re “not a technical person”, don’t even try.  And if you do want to try, then you should start by increasing your basic technical skills—then reading the specs.  Then, you would never find yourself apologizing for “dumb questions”.

There is some sort of absurd postmodern myth that everybody needs to understand everything.  No, you don’t—and you won’t; you never will.  You use technology every day which you have not the slightest hope of ever understanding.  I guarantee that you don’t understand GPS, either; but I’d wager that you trust it to guide you where you want to go.

Segwit is highly technical.  It’s a hack; but it’s a brilliant, elegant hack which makes everything Just Work without sacrificing backwards compatibility (= no hardfork).  The whole Internet is built on such hacks, most of them far less neat and orderly.  Do you want to start brushing up on IPv6 and DNSSEC?  Or for that matter, the long chain of weird kludges applied to SMTP since the protocol was first defined in 1982?

Segwit does not remove signatures; that’s a ridiculous canard peddled by smear campaigners for cheap propaganda purposes.  The engineers did a fine job on this one.  That’s all you really need to know.  If you can’t or won’t read all the specs—if you lack the ability and/or the will to work through the process of gaining significant expertise—then don’t ask questions, especially if you won’t read the answers anyway.  Just sit back, use, and enjoy.

(Note:  I am not affiliated with Core, though I hope to perhaps contribute someday.  I like specs and Unix kernel C code for bedtime reading.)