<blockquote>
  <p>Question: what is that public key? do you see any keys? ("3" is a multisig address &amp; requires 3 address? so there must be 3 public keys right?)</p>
</blockquote>

<p>No. An address beginning with a <code>3</code> is a P2SH address. This does not mean it is a multisig address or requires any number of keys to sign the transaction. Rather it just means that there is some script (it can be any script, not necessarily a multisig script) that needs to be included in the input that spends the P2SH output. That script will dictate the other items in the input.</p>

<p>For a P2SH nested Segwit output (P2SH-P2WPKH and P2SH-P2WSH), the script that the address refers to (known as the redeem script) is of the form <code>OP_0 &lt;20 byte hash&gt;</code> or <code>OP_0 &lt;32 byte hash&gt;</code>. When a segwit node sees this script in an output or as a redeem script, it knows that it should look in the newly defined witness are of a transaction to get the rest of the data it needs to verify the transaction.</p>

<p>However for a non-segwit node, they will mark the transaction as valid (but not standard) because for a non-segwit node, those redeem scripts don't specify that a signature is needed. This makes these outputs anyone-can-spend to non-segwit nodes.</p>

<p>Since Bitcoin Cash does not implement segwit, all of their nodes are non-segwit nodes. Thus in order to spend from the P2SH nested segwit outputs, you only need to provide the redeem script. However the redeem scripts are protected by a hash; given only a P2SH output, you cannot figure out the redeem script unless you already know it. Redeem scripts are revealed when the output is spent from.</p>

<p>What the miner did here was that they found as many redeem scripts as they could. The redeem scripts of the P2SH outputs used were all redeem scripts that had been revealed on the Bitcoin network because they had been used as an input in a transaction. So the miner took all of those revealed redeem scripts and checked to see which ones had corresponding outputs on the Bitcoin Cash network. Those that did could then be spent by the miner as the miner then knew the redeem script.</p>

<blockquote>
  <p>it gets even more stupid ????????????????????? Article says after making that raw transaction he mined it ..... without broadcasting it ?????? what</p>
</blockquote>

<p>A transaction does not need to be broadcast before it is mined. A miner can include whatever transactions he wants, and that includes transactions not broadcast to the public. Once the block is mined, the transaction will then be broadcast with the block.</p>

CC BY-SA 3.0
2017-12-14T23:45:06.647Z
No, there is no "collect coins in his wallet" or "prev_out are not broadcasted but mined". That is not how Bitcoin or bcash works. There are no coins to collect, only outputs and the inputs that spend the outputs. The miner simply creates a transaction that spends the outputs and includes it in a block he mines, then broadcasts the block. The purpose of broadcasting a tx is so that miners can include them in a block. Miners do not need to broadcast their transactions for someone to include them in a block, but doing so will increase the chances that it will be included sooner.
Ava Chow
CC BY-SA 3.0
2017-12-15T05:32:35.633Z
thanks you're really genius person Mr.chow... i had marked your reply as.. answered
user380208
CC BY-SA 3.0
2017-12-15T05:36:47.523Z
sorry i was asking about the purpose of not broadcasting a tx to save an output ...
if a miner didn't broadcast a tx.. other miners will pick it up & include in their version of the block.. so how did they save this 100 bch tx?
https://twitter.com/khannib/status/931448049125249024
user380208
CC BY-SA 3.0
2017-12-15T14:07:36.400Z
No, if a transaction is not broadcast other miners will not know about it and will not pick it up. In that 100 BCH case, btc.com created a transaction and did not broadcast it.
Ava Chow
CC BY-SA 3.0
2017-12-15T15:07:20.193Z
i agree, however in that special case the sender already broadcasted TX and requested pool's to not to broadcast it... cuz bch came up with solution -  if you send bch to btc than contact miner's not to broadcast it....my Question- it will propagate through every node - then mempool - than miner... even if one miner ignore it ....other will pick it up? so how bch solution works here?
user380208
CC BY-SA 3.0
2017-12-15T16:05:56.237Z
No, that is not how it works. No transaction is being broadcast; if a transaction is broadcast, even if one node (i.e. a miner's) ignores it, the rest of the network (including the other miners) will hear it and may include it in their blocks. What is happening with btc.com is that users talk directly to btc.com. They are not creating a transaction and broadcasting it.
Ava Chow
CC BY-SA 3.0
2017-12-15T19:42:32.100Z
okay, btc.com is just one pool there are many others.... what about them? or maybe i assume its all monopoly
user380208
CC BY-SA 3.0
2017-12-16T00:54:10.740Z
Other mining pools or miners might offer a similar service if they are knowledgeable enough. Regardless, whether miners offer such a service or not, any miner can spend from such segwit outputs as I described earlier provided that they know the redeem script (either discovered it themselves or were told it by the person who actually owns the address on the Bitcoin network).
Ava Chow
CC BY-SA 3.0
2017-12-13T18:38:13.357Z
"Once the block is mined, the transaction will then be broadcast with the block." 1.  a miner can include tx that haven't being broadcasted before! isn't that against consensus rules? 2. what will happen if a miner didn't broadcast that tx after the block has been mined? is that block going to get rejected by other peers?
user380208
CC BY-SA 3.0
2017-12-13T18:53:47.290Z
No, it is not against the consensus rules to include a transaction that was not broadcast. It is impossible for a node to know whether a transaction was actually broadcast to the network because they may have not received it if it were broadcast. The transaction itself does not need to be broadcast; it will be included in a block and that block will be broadcast. If the block that is transmitted does not include the transaction but when it was mined it did, then the transmitted block will be invalid.
Ava Chow
CC BY-SA 3.0
2017-12-13T19:05:57.957Z
it will be lot easier if bitcoin.org would have explained how mining works with segwit...  If the block includes that tx and removes it after being mined it will then change the nonce + hash making is automatically invalid ... thats what you're trying to say right?
user380208
CC BY-SA 3.0
2017-12-13T19:15:09.183Z
Yes. It has nothing to do with segwit though. That is a consensus rule that has always existed.
Ava Chow
CC BY-SA 3.0
2017-12-13T19:43:27.353Z
so why didn't he just broadcasted it like a regular person ...instead of mining it ? maybe cuz he was afraid other miners will take that transaction & replace with there address in the output section, i guess .... lol :) just like the game of thrones
user380208
CC BY-SA 3.0
2017-12-13T19:56:19.157Z
thanks for the explanation ... however, what does redeem script has to do with public key and scriptsig "particular hash" thing these articles are talking about?
user380208
CC BY-SA 3.0
2017-12-14T04:48:18.217Z
The transaction was not broadcast because it is non-standard. This means that it is consensus valid, but nodes won't relay it. The "particular hash" and scriptsig things are because the redeem script is placed in the scriptsig and it must hash to a hash that is specified by the P2SH output that is being spent from.
Ava Chow
CC BY-SA 3.0
2017-12-14T11:34:07.687Z
wait.... what you mean by non-standard? also the first article says that miner was using a segwit node in bcash chain to mine this Tx ....does this makes any sense to you?
user380208
CC BY-SA 3.0
2017-12-14T16:18:15.130Z
Bitcoin and related coins (including bcash) have a set of rules call standardness rules. These rules are on top of the consensus rules. A transaction can meet the consensus rules but not the standardness rules. That just means that it is valid but nodes won't relay it. Such transactions are called non-standard. It doesn't make any sense to use a segwit node on bcash because bcash does not have segwit.
Ava Chow
CC BY-SA 3.0
2017-12-14T19:11:55.237Z
jesus christ! (correct me if I wrong)
1. miner used normal bitcoin-abc node to mine his tx, 

2. The block containing the tx will be broadcasted to other miner & get accepted as a valid block

3., however, the vigilance cannot broadcast this specific tx since it is non-standard .. miner collects coins in his wallet (those prev_out are not broadcasted but mined) ready to spend anywhere? (yes, he will broadcast when he pays to "bob" later)
so whats the purpose of broadcasting a tx like a regular person from wallet?
user380208
CC BY-SA 3.0
2017-12-13T17:49:32.857Z
2017-12-13T17:49:32.857Z
Ava Chow
<p>SegWit outputs look like AnyoneCanSpend outputs to legacy nodes (to keep it as a softfork). Since Bitcoin Cash doesn't have (and strictly opposes) SegWit, all the miners see them as AnyoneCanSpend outputs, and they can redeem it.</p>

<p>This cannot happen on the Bitcoin network, because the other miners would reject that block.</p>

<p>Maybe he's this guy: <a href="https://www.reddit.com/r/btc/comments/7g6s9l/an_update_on_bch_segwit_recoveries/" rel="nofollow noreferrer">https://www.reddit.com/r/btc/comments/7g6s9l/an_update_on_bch_segwit_recoveries/</a> ?</p>

<p>[Removed nonsense part]</p>

CC BY-SA 3.0
2017-12-13T16:29:44.003Z
yeah that's the miner.. however these outputs where ignored by other miners (miners didnt took it- look the date on bch block explorer) and it is actually after than it was kindof hacked by that bcnsegwit-miner
user380208
CC BY-SA 3.0
2017-12-13T16:33:04.760Z
No, it is not a hack. Other miners could redeem these outputs too, but they didn't for some reason. (Ethics?)
MCCCS
CC BY-SA 3.0
2017-12-13T16:35:38.607Z
i know its not a hack ... other miners didnt do it cuz its complicated as hell... even the miner admits himself- "Because of the significant effort that was required to both claim these BCH and to verify that each person is the person who should be receiving the BCH, I will be taking 30% "
user380208
CC BY-SA 3.0
2017-12-13T17:54:01.383Z
That article on SegWit is nonsensical FUD, as it completely ignores full nodes. Since nearly every node on the network now enforces SegWit consensus rules, reverting it to steal its outputs would require full nodes to stop enforcing first. That's a hardfork.
Pieter Wuille
CC BY-SA 3.0
2017-12-13T18:53:14.840Z
@PieterWuille Thanks for reviewing this page ... 1. Which article are you referencing to? 2. quote "Since nearly every node on the network now enforces SegWit" which network ? bcash or bitcoin
user380208
CC BY-SA 3.0
2017-12-13T19:07:18.113Z
I'm referring to the coingeek link.
Pieter Wuille
CC BY-SA 3.0
2017-12-13T19:19:21.160Z
@PieterWuille 
 what do you think about the bitcoin cash address conventional? they are changing The version byte to 28 for p2pkh addresses and 40 for p2sh addresses... is it going to this solve this situation for all users on board?
user380208
CC BY-SA 3.0
2017-12-13T19:20:19.817Z
https://support.bitpay.com/hc/en-us/articles/115004671663-BitPay-s-Adopted-Conventions-for-Bitcoin-Cash-Addresses-URIs-and-Payment-Requests
user380208
CC BY-SA 3.0
2017-12-13T19:21:22.520Z
BitPay is acting on their own there. Cash people also have a proposal for new addresses. Yes, they should have done that from the start.
Pieter Wuille
CC BY-SA 3.0
2017-12-13T16:06:38.860Z
2017-12-14T04:34:02.183Z
2017-12-14T04:34:02.183Z
MCCCS
<p>I'm trying to fill a few gaps in my understanding how this transaction happened! </p>

<p>It all started with this <a href="https://medium.com/@csn_platform/someone-just-helped-themselves-to-600k-of-bitcoin-cash-from-segwit-addresses-ea41c05c4dc6" rel="nofollow noreferrer">article</a></p>

<p>In short, some vigilante/miner was able to scoop up all of the BCH sitting in segwit addresses (namely, the ones for which the public keys were revealed by the owners spending BTC from the same addresses.</p>

<p>See this Transaction that was created, miner
<a href="https://blockchair.com/bitcoin-cash/transaction/c26857027d072277808d509fa5e359aacb39d2a0937160b8190264e368467e65" rel="nofollow noreferrer">Bitcoin Cash Block Explorer</a></p>

<p>Step by Step Breakdown</p>

<ol>
<li><p>Miner scoops public key of this address 3P9dyU9ga3aJorHAUqKBFCX2NdyuHEVgx1
(this is a P2SH P2WPKH address <a href="https://btc.com/9d710be07bed7699055ed4c27868ee50fcb91f8d738bebfdbf4145cdbaeb15a2" rel="nofollow noreferrer">see this bitcoin block explorer</a> )</p>

<p>Question: what is that public key? Do you see any keys? 
("3" is a multisig address &amp; requires 3 addresses, so there must be 3 public keys, right?)</p></li>
<li><p>The article didn't explain how and what raw transaction he created using only public keys.</p></li>
<li><p>This is the most frustrating part. The article claims that miner created a segwit node and mined on top of that.</p>

<p>How is that even possible? (Bcash doesnt have segwit activated. However even if he mined using his segwit node, his node will not allow him to create a valid transaction because segwit requires a witness or sign with private key of public key of address 3P9dyU9ga3aJorHAUqKBFCX2NdyuHEVgx1.)</p></li>
</ol>

<hr>

<p>However, this <a href="https://icolink.com/ico-news/hacker-transferred-himself-bch-from-segwit-addresses-and-claims-a-30-redemption.html" rel="nofollow noreferrer">article</a> claims </p>

<ol>
<li><p>The miner just created a scriptsig (the article didn't explain what "apply a particular hash" means).</p></li>
<li><p>Now it's easy, the miner just has to assign a BCH output (address starting with 1)</p></li>
<li><p>it gets even more stupid. The article says after making that raw transaction he mined it ..... without broadcasting it. How does that work?</p>

<p>3.1 If you are not broadcasting it then whats the point? How will that transaction go through to the new address/wallet created by miner (in this case 1C4TafndKYFoGkeoHfQAWkZzEYLum31txf)?</p>

<p>3.2 If the miner is mining his own block and then not broadcasting it, wouldn't it get orphaned? So what is going on here?</p></li>
</ol>

CC BY-SA 3.0
2017-12-13T15:59:33.497Z
It's a good question (though it would be easier to read with capitalized sentences, correct spelling, and fewer ? marks).  However the last paragraph is off topic - this site isn't the place to recruit people for your projects.
Nate Eldredge
CC BY-SA 3.0
2017-12-13T16:32:25.710Z
i agree however i want to learn ... segwit is so confusing trying to search for 25 days .. already had 46 tabs and 4 windows open in my browser
user380208
<bitcoin-core><bitcoin-cash><segregated-witness>
Can someone explain how this person hacked bitcoin?
user380208
# Can someone explain how this person hacked bitcoin?

(Asked by: username_0 on 2017-12-13)

I'm trying to fill a few gaps in my understanding how this transaction happened!

It all started with this [article](https://medium.com/@csn_platform/someone-just-helped-themselves-to-600k-of-bitcoin-cash-from-segwit-addresses-ea41c05c4dc6)

In short, some vigilante/miner was able to scoop up all of the BCH sitting in segwit addresses (namely, the ones for which the public keys were revealed by the owners spending BTC from the same addresses.

See this Transaction that was created, miner
[Bitcoin Cash Block Explorer](https://blockchair.com/bitcoin-cash/transaction/c26857027d072277808d509fa5e359aacb39d2a0937160b8190264e368467e65)

Step by Step Breakdown

1. Miner scoops public key of this address 3P9dyU9ga3aJorHAUqKBFCX2NdyuHEVgx1
   (this is a P2SH P2WPKH address [see this bitcoin block explorer](https://btc.com/9d710be07bed7699055ed4c27868ee50fcb91f8d738bebfdbf4145cdbaeb15a2) )

   Question: what is that public key? Do you see any keys?
   ("3" is a multisig address & requires 3 addresses, so there must be 3 public keys, right?)
2. The article didn't explain how and what raw transaction he created using only public keys.
3. This is the most frustrating part. The article claims that miner created a segwit node and mined on top of that.

   How is that even possible? (Bcash doesnt have segwit activated. However even if he mined using his segwit node, his node will not allow him to create a valid transaction because segwit requires a witness or sign with private key of public key of address 3P9dyU9ga3aJorHAUqKBFCX2NdyuHEVgx1.)

---

However, this [article](https://icolink.com/ico-news/hacker-transferred-himself-bch-from-segwit-addresses-and-claims-a-30-redemption.html) claims

1. The miner just created a scriptsig (the article didn't explain what "apply a particular hash" means).
2. Now it's easy, the miner just has to assign a BCH output (address starting with 1)
3. it gets even more stupid. The article says after making that raw transaction he mined it ..... without broadcasting it. How does that work?

   3.1 If you are not broadcasting it then whats the point? How will that transaction go through to the new address/wallet created by miner (in this case 1C4TafndKYFoGkeoHfQAWkZzEYLum31txf)?

   3.2 If the miner is mining his own block and then not broadcasting it, wouldn't it get orphaned? So what is going on here?

**Tags:** bitcoin-core, bitcoin-cash, segregated-witness

> **Comments:**
> **username_1**: It's a good question (though it would be easier to read with capitalized sentences, correct spelling, and fewer ? marks).  However the last paragraph is off topic - this site isn't the place to recruit people for your projects.  
> **username_0**: i agree however i want to learn ... segwit is so confusing trying to search for 25 days .. already had 46 tabs and 4 windows open in my browser  

---

## 2 answers

### Answer by username_2 on 2017-12-13. Score: 2 | Accepted answer

> Question: what is that public key? do you see any keys? ("3" is a multisig address & requires 3 address? so there must be 3 public keys right?)

No. An address beginning with a `3` is a P2SH address. This does not mean it is a multisig address or requires any number of keys to sign the transaction. Rather it just means that there is some script (it can be any script, not necessarily a multisig script) that needs to be included in the input that spends the P2SH output. That script will dictate the other items in the input.

For a P2SH nested Segwit output (P2SH-P2WPKH and P2SH-P2WSH), the script that the address refers to (known as the redeem script) is of the form `OP_0 <20 byte hash>` or `OP_0 <32 byte hash>`. When a segwit node sees this script in an output or as a redeem script, it knows that it should look in the newly defined witness are of a transaction to get the rest of the data it needs to verify the transaction.

However for a non-segwit node, they will mark the transaction as valid (but not standard) because for a non-segwit node, those redeem scripts don't specify that a signature is needed. This makes these outputs anyone-can-spend to non-segwit nodes.

Since Bitcoin Cash does not implement segwit, all of their nodes are non-segwit nodes. Thus in order to spend from the P2SH nested segwit outputs, you only need to provide the redeem script. However the redeem scripts are protected by a hash; given only a P2SH output, you cannot figure out the redeem script unless you already know it. Redeem scripts are revealed when the output is spent from.

What the miner did here was that they found as many redeem scripts as they could. The redeem scripts of the P2SH outputs used were all redeem scripts that had been revealed on the Bitcoin network because they had been used as an input in a transaction. So the miner took all of those revealed redeem scripts and checked to see which ones had corresponding outputs on the Bitcoin Cash network. Those that did could then be spent by the miner as the miner then knew the redeem script.

> it gets even more stupid ????????????????????? Article says after making that raw transaction he mined it ..... without broadcasting it ?????? what

A transaction does not need to be broadcast before it is mined. A miner can include whatever transactions he wants, and that includes transactions not broadcast to the public. Once the block is mined, the transaction will then be broadcast with the block.

> **Comments:**
> **username_0**: "Once the block is mined, the transaction will then be broadcast with the block." 1.  a miner can include tx that haven't being broadcasted before! isn't that against consensus rules? 2. what will happen if a miner didn't broadcast that tx after the block has been mined? is that block going to get rejected by other peers?  
> **username_2**: No, it is not against the consensus rules to include a transaction that was not broadcast. It is impossible for a node to know whether a transaction was actually broadcast to the network because they may have not received it if it were broadcast. The transaction itself does not need to be broadcast; it will be included in a block and that block will be broadcast. If the block that is transmitted does not include the transaction but when it was mined it did, then the transmitted block will be invalid.  
> **username_0**: it will be lot easier if bitcoin.org would have explained how mining works with segwit...  If the block includes that tx and removes it after being mined it will then change the nonce + hash making is automatically invalid ... thats what you're trying to say right?  
> **username_2**: Yes. It has nothing to do with segwit though. That is a consensus rule that has always existed.  
> **username_0**: so why didn't he just broadcasted it like a regular person ...instead of mining it ? maybe cuz he was afraid other miners will take that transaction & replace with there address in the output section, i guess .... lol :) just like the game of thrones  
> **username_0**: thanks for the explanation ... however, what does redeem script has to do with public key and scriptsig "particular hash" thing these articles are talking about?  
> **username_2**: The transaction was not broadcast because it is non-standard. This means that it is consensus valid, but nodes won't relay it. The "particular hash" and scriptsig things are because the redeem script is placed in the scriptsig and it must hash to a hash that is specified by the P2SH output that is being spent from.  
> **username_0**: wait.... what you mean by non-standard? also the first article says that miner was using a segwit node in bcash chain to mine this Tx ....does this makes any sense to you?  
> **username_2**: Bitcoin and related coins (including bcash) have a set of rules call standardness rules. These rules are on top of the consensus rules. A transaction can meet the consensus rules but not the standardness rules. That just means that it is valid but nodes won't relay it. Such transactions are called non-standard. It doesn't make any sense to use a segwit node on bcash because bcash does not have segwit.  
> **username_0**: jesus christ! (correct me if I wrong) 1. miner used normal bitcoin-abc node to mine his tx,   2. The block containing the tx will be broadcasted to other miner & get accepted as a valid block  3., however, the vigilance cannot broadcast this specific tx since it is non-standard .. miner collects coins in his wallet (those prev_out are not broadcasted but mined) ready to spend anywhere? (yes, he will broadcast when he pays to "bob" later) so whats the purpose of broadcasting a tx like a regular person from wallet?  
> **username_2**: No, there is no "collect coins in his wallet" or "prev_out are not broadcasted but mined". That is not how Bitcoin or bcash works. There are no coins to collect, only outputs and the inputs that spend the outputs. The miner simply creates a transaction that spends the outputs and includes it in a block he mines, then broadcasts the block. The purpose of broadcasting a tx is so that miners can include them in a block. Miners do not need to broadcast their transactions for someone to include them in a block, but doing so will increase the chances that it will be included sooner.  
> **username_0**: thanks you're really genius person Mr.username_2... i had marked your reply as.. answered  
> **username_0**: sorry i was asking about the purpose of not broadcasting a tx to save an output ... if a miner didn't broadcast a tx.. other miners will pick it up & include in their version of the block.. so how did they save this 100 bch tx? https://twitter.com/khannib/status/931448049125249024  
> **username_2**: No, if a transaction is not broadcast other miners will not know about it and will not pick it up. In that 100 BCH case, btc.com created a transaction and did not broadcast it.  
> **username_0**: i agree, however in that special case the sender already broadcasted TX and requested pool's to not to broadcast it... cuz bch came up with solution -  if you send bch to btc than contact miner's not to broadcast it....my Question- it will propagate through every node - then mempool - than miner... even if one miner ignore it ....other will pick it up? so how bch solution works here?  
> **username_2**: No, that is not how it works. No transaction is being broadcast; if a transaction is broadcast, even if one node (i.e. a miner's) ignores it, the rest of the network (including the other miners) will hear it and may include it in their blocks. What is happening with btc.com is that users talk directly to btc.com. They are not creating a transaction and broadcasting it.  
> **username_0**: okay, btc.com is just one pool there are many others.... what about them? or maybe i assume its all monopoly  
> **username_2**: Other mining pools or miners might offer a similar service if they are knowledgeable enough. Regardless, whether miners offer such a service or not, any miner can spend from such segwit outputs as I described earlier provided that they know the redeem script (either discovered it themselves or were told it by the person who actually owns the address on the Bitcoin network).  

---

### Answer by username_3 on 2017-12-13. Score: 1

SegWit outputs look like AnyoneCanSpend outputs to legacy nodes (to keep it as a softfork). Since Bitcoin Cash doesn't have (and strictly opposes) SegWit, all the miners see them as AnyoneCanSpend outputs, and they can redeem it.

This cannot happen on the Bitcoin network, because the other miners would reject that block.

Maybe he's this guy: <https://www.reddit.com/r/btc/comments/7g6s9l/an_update_on_bch_segwit_recoveries/> ?

[Removed nonsense part]

> **Comments:**
> **username_0**: yeah that's the miner.. however these outputs where ignored by other miners (miners didnt took it- look the date on bch block explorer) and it is actually after than it was kindof hacked by that bcnsegwit-miner  
> **username_3**: No, it is not a hack. Other miners could redeem these outputs too, but they didn't for some reason. (Ethics?)  
> **username_0**: i know its not a hack ... other miners didnt do it cuz its complicated as hell... even the miner admits himself- "Because of the significant effort that was required to both claim these BCH and to verify that each person is the person who should be receiving the BCH, I will be taking 30% "  
> **username_4**: That article on SegWit is nonsensical FUD, as it completely ignores full nodes. Since nearly every node on the network now enforces SegWit consensus rules, reverting it to steal its outputs would require full nodes to stop enforcing first. That's a hardfork.  
> **username_0**: @username_4 Thanks for reviewing this page ... 1. Which article are you referencing to? 2. quote "Since nearly every node on the network now enforces SegWit" which network ? bcash or bitcoin  
> **username_4**: I'm referring to the coingeek link.  
> **username_0**: @username_4   what do you think about the bitcoin cash address conventional? they are changing The version byte to 28 for p2pkh addresses and 40 for p2sh addresses... is it going to this solve this situation for all users on board?  
> **username_0**: https://support.bitpay.com/hc/en-us/articles/115004671663-BitPay-s-Adopted-Conventions-for-Bitcoin-Cash-Addresses-URIs-and-Payment-Requests  
> **username_4**: BitPay is acting on their own there. Cash people also have a proposal for new addresses. Yes, they should have done that from the start.  

---

