<blockquote>
  <p>it means that proportion of fresh node should be bigger than proportion of legacy node.</p>
</blockquote>

<p>The requirement for segwit's activation was that the majority of the hashrate signaled readiness for activation. Although this process was frequently misconstrued as a "vote of miners", the activation proposal actually requests that miners judge whether the majority of the network would enforce the change upon activation and only signal readiness then. So, when segwit got activated, more than 85% of all nodes already enforced the segwit rules and IIRC 98% of the hashrate.</p>

<blockquote>
  <p>Block size is physically 1MB.</p>
</blockquote>

<p>The blockspace was limited to 1,000,000 bytes before segwit and to 4,000,000 weight units with the activation of segwit. The weight of a block is calculated by the addition of the witness data bytes and four times the non-witness data bytes. This is backwards compatible for blocks without witness data, but allows segwit blocks to be bigger than 1 MB.</p>

CC BY-SA 4.0
2019-11-18T23:05:18.653Z
2019-11-18T23:05:18.653Z
Murch
<blockquote>
  <p>In this point, if Bob make a fraud transaction with Segwit, legacy
  node will accept, but it is not accepted in terms of fresh node. so,
  some group(legacy nodes) accept, other some groups(fresh nodes)
  doesn't accept. it means that proportion of fresh node should be
  bigger than proportion of legacy node. I think that this is really
  critical issue but current Bitcoin works well. we can say proportion
  of fresh node is bigger than legacy groups,<b> but how it was achieved?
  </b> when Segwit is appeared, at this time proportion of fresh node is
  maybe too small to overtake legacy groups.</p>
</blockquote>

<p>Segwit did not just show up out of nowhere with no warning and no software to enforce it. Segwit capable software was released long before its activation, thus allowing for sufficient time for nodes to upgrade.</p>

<p>As with all previous soft forks, the activation time was determined well in advance (kind of). It wasn't scheduled (one soft fork  did have a scheduled activation), but rather required that miners signal readiness to enforce Segwit's rules before they would actually activate and be enforced by nodes on the network. This signalling was done by setting a particular bit in the block version number. 1916 out of a period of 2016 blocks must have the bit set in order for the rules to be activated.</p>

<p>Furthermore, even after the signalling threshold was reached, there would still be another 2016 block grace period where Segwit is "locked in" but not yet active. This is just a grace period for people who haven't upgraded yet to upgrade now that they know that the Segwit rules are going to activate. After the grace period, the rules will activate.</p>

<p>With even the fastest activation (everyone started signalling as soon as possible and the threshold is reached in  the first signalling period), there are ~4 weeks from time of "release" to activation  for people to upgrade. It is likely that there wouldn't be a majority, but at the very least, miners would have upgraded and enforced the rules (in the ideal case, but reality does say otherwise). And once the fork becomes "locked in", it can be expected that many more people will upgrade as they do see the importance of enforcing all rules in effect.</p>

<p>In addition to the time it would take for signalling and lock in, there is also the signalling start time. Miners could only begin signalling for segwit activation after a predetermined time. Any signalling before that time would be ignored. This start time was set to be a few weeks after the release of the first mainnet segwit capable software. Specifically, Bitcoin Core 0.13.1 was released on Oct. 27, 2016. The start time was defined to be Midnight Nov. 15, 2016 UTC. So there was almost 3 weeks between the release of the software and the beginning of the first signalling period. In total, ~7 weeks between the  release of the software and the first possible activation time. This is sufficient time  for many nodes to upgrade, and ideally, enough to protect the network.</p>

<p>Lastly, it is not expected for any soft fork to be deployed at the first possible activation period. They are expected to take a few months as miners are typically slow to upgrade (usually auditing software, upgrading their custom software, etc.). So in practice, by the time a soft fork does activate, many, if not most, nodes have upgraded.</p>

<p>This whole deployment mechanism can be (and is) used for many soft forks. It is described by <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki" rel="noreferrer">BIP 9</a>.</p>

<hr>

<p>And then let's look at what actually happened with Segwit's activation. Segwit took 11 months from the release of 0.13.1 to be fully deployed. By that time, the vast majority of the network had upgraded to segwit capable software.</p>

<blockquote>
  <p>Block size is physically 1MB. Regardless of the calculation rule is 'Weight' or 'Bytes', the transaction size is always same physically. Why some guys says that Segwit transaction is compact than traditional transaction? Signatures are not removed, it is just moved to end of the transaction. Consquently, the data size are same between Segwith and traditional protocol. Please catch where I am wrong.</p>
</blockquote>

<p>Blocks are physically larger than 1 MB. The "block size limit" has been removed and replaced with the weight limit. It is true that physically, Segwit transactions are about the same size as non-segwit ones.</p>

<p>The "more compact" stems from a confusion between physical data size, and data size used for computation of the previous block size limit. Under the block size limit byte computation, segwit transactions are more compact. But when computing the actual number of bytes transmitted over the network, they are about the same.</p>

CC BY-SA 4.0
2019-11-18T22:05:59.883Z
Nice answer, two comments: (1) Segwit is primarily safe against the "old nodes will accept without witness" issue because someone giving out a segwit address is by definition running segwit-compatible software that requires a witness (2) segwit blocks can be physically bigger than 1 MB.
Pieter Wuille
CC BY-SA 4.0
2019-11-18T17:36:34.797Z
2019-11-18T17:36:34.797Z
Ava Chow
<p>In the Segwit rules, transactions propagated to legacy node doesn't have any signature. so it will be valid as well as in terms of fresh node(supporting Segwit).</p>

<p><strong>First question:</strong></p>

<blockquote>
  <p>In this point, if Bob make a fraud transaction with Segwit, legacy
  node will accept, but it is not accepted in terms of fresh node. so,
  some group(legacy nodes) accept, other some groups(fresh nodes)
  doesn't accept. it means that proportion of fresh node should be
  bigger than proportion of legacy node. I think that this is really
  critical issue but current Bitcoin works well. we can say proportion
  of fresh node is bigger than legacy groups,<b> but how it was achieved?
  </b> when Segwit is appeared, at this time proportion of fresh node is
  maybe too small to overtake legacy groups.</p>
</blockquote>

<p><strong>Last question:</strong></p>

<blockquote>
  <p>Block size is physically 1MB. Regardless of the calculation rule is
  'Weight' or 'Bytes', the transaction size is always same physically. 
  Why some guys says that Segwit transaction is compact than traditional
  transaction?
  Signatures are not removed, it is just moved to end of the transaction. Consquently, the data size are same between Segwith and traditional protocol. Please catch where I am wrong.</p>
</blockquote>

<p>Sorry for my English.</p>

<transactions><segregated-witness>
Is Segwit really safe and reduced?
Hyunsoo
# Is Segwit really safe and reduced?

(Asked by: username_0 on 2019-11-18)

In the Segwit rules, transactions propagated to legacy node doesn't have any signature. so it will be valid as well as in terms of fresh node(supporting Segwit).

**First question:**

> In this point, if Bob make a fraud transaction with Segwit, legacy
> node will accept, but it is not accepted in terms of fresh node. so,
> some group(legacy nodes) accept, other some groups(fresh nodes)
> doesn't accept. it means that proportion of fresh node should be
> bigger than proportion of legacy node. I think that this is really
> critical issue but current Bitcoin works well. we can say proportion
> of fresh node is bigger than legacy groups, **but how it was achieved?** when Segwit is appeared, at this time proportion of fresh node is
> maybe too small to overtake legacy groups.

**Last question:**

> Block size is physically 1MB. Regardless of the calculation rule is
> 'Weight' or 'Bytes', the transaction size is always same physically.
> Why some guys says that Segwit transaction is compact than traditional
> transaction?
> Signatures are not removed, it is just moved to end of the transaction. Consquently, the data size are same between Segwith and traditional protocol. Please catch where I am wrong.

Sorry for my English.

**Tags:** transactions, segregated-witness


---

## 2 answers

### Answer by username_2 on 2019-11-18. Score: 6 | Accepted answer

> In this point, if Bob make a fraud transaction with Segwit, legacy
> node will accept, but it is not accepted in terms of fresh node. so,
> some group(legacy nodes) accept, other some groups(fresh nodes)
> doesn't accept. it means that proportion of fresh node should be
> bigger than proportion of legacy node. I think that this is really
> critical issue but current Bitcoin works well. we can say proportion
> of fresh node is bigger than legacy groups, **but how it was achieved?** when Segwit is appeared, at this time proportion of fresh node is
> maybe too small to overtake legacy groups.

Segwit did not just show up out of nowhere with no warning and no software to enforce it. Segwit capable software was released long before its activation, thus allowing for sufficient time for nodes to upgrade.

As with all previous soft forks, the activation time was determined well in advance (kind of). It wasn't scheduled (one soft fork did have a scheduled activation), but rather required that miners signal readiness to enforce Segwit's rules before they would actually activate and be enforced by nodes on the network. This signalling was done by setting a particular bit in the block version number. 1916 out of a period of 2016 blocks must have the bit set in order for the rules to be activated.

Furthermore, even after the signalling threshold was reached, there would still be another 2016 block grace period where Segwit is "locked in" but not yet active. This is just a grace period for people who haven't upgraded yet to upgrade now that they know that the Segwit rules are going to activate. After the grace period, the rules will activate.

With even the fastest activation (everyone started signalling as soon as possible and the threshold is reached in the first signalling period), there are ~4 weeks from time of "release" to activation for people to upgrade. It is likely that there wouldn't be a majority, but at the very least, miners would have upgraded and enforced the rules (in the ideal case, but reality does say otherwise). And once the fork becomes "locked in", it can be expected that many more people will upgrade as they do see the importance of enforcing all rules in effect.

In addition to the time it would take for signalling and lock in, there is also the signalling start time. Miners could only begin signalling for segwit activation after a predetermined time. Any signalling before that time would be ignored. This start time was set to be a few weeks after the release of the first mainnet segwit capable software. Specifically, Bitcoin Core 0.13.1 was released on Oct. 27, 2016. The start time was defined to be Midnight Nov. 15, 2016 UTC. So there was almost 3 weeks between the release of the software and the beginning of the first signalling period. In total, ~7 weeks between the release of the software and the first possible activation time. This is sufficient time for many nodes to upgrade, and ideally, enough to protect the network.

Lastly, it is not expected for any soft fork to be deployed at the first possible activation period. They are expected to take a few months as miners are typically slow to upgrade (usually auditing software, upgrading their custom software, etc.). So in practice, by the time a soft fork does activate, many, if not most, nodes have upgraded.

This whole deployment mechanism can be (and is) used for many soft forks. It is described by [BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki).

---

And then let's look at what actually happened with Segwit's activation. Segwit took 11 months from the release of 0.13.1 to be fully deployed. By that time, the vast majority of the network had upgraded to segwit capable software.

> Block size is physically 1MB. Regardless of the calculation rule is 'Weight' or 'Bytes', the transaction size is always same physically. Why some guys says that Segwit transaction is compact than traditional transaction? Signatures are not removed, it is just moved to end of the transaction. Consquently, the data size are same between Segwith and traditional protocol. Please catch where I am wrong.

Blocks are physically larger than 1 MB. The "block size limit" has been removed and replaced with the weight limit. It is true that physically, Segwit transactions are about the same size as non-segwit ones.

The "more compact" stems from a confusion between physical data size, and data size used for computation of the previous block size limit. Under the block size limit byte computation, segwit transactions are more compact. But when computing the actual number of bytes transmitted over the network, they are about the same.

> **Comments:**
> **username_3**: Nice answer, two comments: (1) Segwit is primarily safe against the "old nodes will accept without witness" issue because someone giving out a segwit address is by definition running segwit-compatible software that requires a witness (2) segwit blocks can be physically bigger than 1 MB.  

---

### Answer by username_1 on 2019-11-18. Score: 4

> it means that proportion of fresh node should be bigger than proportion of legacy node.

The requirement for segwit's activation was that the majority of the hashrate signaled readiness for activation. Although this process was frequently misconstrued as a "vote of miners", the activation proposal actually requests that miners judge whether the majority of the network would enforce the change upon activation and only signal readiness then. So, when segwit got activated, more than 85% of all nodes already enforced the segwit rules and IIRC 98% of the hashrate.

> Block size is physically 1MB.

The blockspace was limited to 1,000,000 bytes before segwit and to 4,000,000 weight units with the activation of segwit. The weight of a block is calculated by the addition of the witness data bytes and four times the non-witness data bytes. This is backwards compatible for blocks without witness data, but allows segwit blocks to be bigger than 1 MB.


---

