Re: NIST 8202 Blockchain Technology Overview

Re: NIST 8202 Blockchain Technology Overview
2018-01-30  1:43 ` CANNON
  
From: CANNON @ 2018-01-29  0:40 UTC (permalink / raw)
  To: nistir8202-comments

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

January 20 2018

(I am also forwarding this message to the bitcoin mailing list just in case there
are other technological errors that could use correction in this draft paper or
anything that should be added with my comments.)

To the authors of this paper,
I am commenting on Draft NISTIR 8202 Blockchain Technology Overview located at
https://csrc.nist.gov/CSRC/media/Publications/nistir/8202/draft/documents/nistir8202-draft.pdf

Just in case that document is modified or removed I have also downloaded
it to redistribute this error ridden draft at a later point if neccesary,
and I also had the Internet Archive save a copy here for sake of archival reasons
to give context to this message.

https://web.archive.org/web/20180124170359/https://csrc.nist.gov/CSRC/media/Publications/nistir/8202/draft/documents/nistir8202-draft.pdf

There are a couple things I would like to contribute on regarding some
corrections needed in this paper. I must say, the content in this paper is
making me doubt the credibility of the NIST. I am starting to wonder if the
NIST is also incompetent with lack of credibility just like with most other
government institutions. Falsified information published as truth such as this
only expose their ignorance and incompetence and also propagate such ignorance
to other institutions and people whom rely on NIST for information or research.
The information presented in this paper is technologically invalid and contains
false information. I understand that mistakes happen, but this specific section
regarding "8.1.2 Bitcoin Cash (BCC)" is obviously written without prior research.
Even if research was done no citation is included to back these claims.
I ask you to please conduct research and validate information before publishing it,
especially when the credibility of the NIST is at stake.

I will proceed to outline some corrections.

1. Bitcoin Cash uses the ticker BCH, BCC is the ticker for BitConnectCoin

2. "When SegWit was activated, it caused a hard fork"
This is incorrect information. Segwit was not a hardfork. Rather segwit was
a softfork meaning that it is backwards compatible with unupgraded nodes and
miners. With it being a softfork it actually prevents a fork in the blockchain
by still being valid to unupgraded nodes and miners. Because segregated witness
is not a hardfork its use is optional.

3. "and all the mining nodes and users who did not want to change started
calling the original Bitcoin blockchain Bitcoin Cash (BCC)"
The original bitcoin blockchain is still called Bitcoin. Segwit did not create
any fork in the blockchain. Bitcoin Cash however was a hard fork that resulted
in a forked blockchain and new altcoin.
Bitcoin is Bitcoin,
Bitcoin Cash is Bitcoin Cash.

4. "Technically, Bitcoin is a fork and Bitcoin Cash is the original
blockchain."
Technically, that statement is not truth.

Bitcoin Cash was forked from the original Bitcoin blockchain to create
the altcoin "Bitcoin Cash" (BCH) by people whom believe that the blocksize
should be large enough to accomodate all individual transactions on the main
chain. Without going into any of my personal opinions of which one is better
(bitcoin vs. "bitcoin cash") technically Bitcoin Cash was a hardfork and is
not the original chain but a forked one. It is a hardfork as the blocks
generated by BCH are incompatible with BTC nodes. Because of this lack of
backwards compatibility, and the resulting fork in blockchain is why BCH is
technically a hardfork.

This is just one section of this paper I have read thus far. It makes me
wonder how many other fallacies are throughout this paper. I also wonder how
many other NIST papers exist out of draft form that contain errors. Even
the smallest amount of research could have prevented this in the case of
this paper, unless you are intentionally pushing false information.

I hope these comments are of benefit to the improvement of this paper.

Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 
Email: cannon@cannon-ciota•info

NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD 
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJabmySAAoJEAYDai9lH2mwVPcP/ika01NHFMBbxVU9OKc4Ibrd
12MpWW2sgvB14dm8NIuh/xQeFpxGjKvkwWCzqj0pSOE+WClVdK573MJcZF1hqnR4
iPNIr3noR632Hyl9V3Cst5hg5BiUmwETpsyDXG7q7Oj/bX3QAR+psjahk2H2gA6v
i4m1BP4052eRymznJ8aRQc1ak23C4ylLvjC3RRfNmXozG77N4w+tQvFXq45yQam+
nh/8EIck5D9vNTOtVgzgjVqQwfDgUsxgClqHGLNiUOSSievCQLhz1WynDZZSlKmf
Y1Gd70fBpHdrhLBe/SOLglZXPU2BTlicUoN/t9P+5i4qzPfNxfMW9eRi/Urd4sJX
INUuEUMJ2m5EspFjv3rMT19ELts8WhGskBq/4OCT8Wlb9arzhvrDySzLdX5ij75V
DhIX1r3CMDVN4HNb1V4M+Je4Wgle7oh+LS2QDjBnw3IMfjF37j+3OXiRDrlAkE30
GNg0SooANGBvMIMdjnc8fwIV/TxeNh0vEj8M2a4VjbthiDT4L1a4CzxOqT3eWbvB
YHUdz+hwSnydkj5EhyC2e0XN3zqvgSNYoE8HTvKG78ik49bZpxkssEuMWC5N+KM8
j2pgzbVdJXu08mwxrgf2wylUpR630WAEXkcVg3rOw+irPl1U0VxzNL8eNFZehMe6
nuUyXL4VMlApOgesmrCI
=RQoE
-----END PGP SIGNATURE-----


 permalink raw reply	[|nested]


       [not found] ` <BY1PR09MB09045CA927AB6A87BBB315D9E4E50@BY1PR09MB0904.namprd09.prod.outlook.com>
  
From: CANNON @ 2018-01-29  1:08 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Slight correction to email I just posted titled "NIST 8202 Blockchain Technology Overview"
The date in top of email states Jan 20, corrected date is Jan 28th which can be validated
also by verifying my signature (gpg includes timestamp when signing).

I also sent email with corrected date to NIST comments email address.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJabnPNAAoJEAYDai9lH2mwzywP/Rr5qlkfihE6SkUZrMRp2G1R
jANSEOMgH3yj7UmNKO2Xqzw93ZyNxNIVAL7z2ru2A6D0ziPgMOUKzyTXbDDpqtJR
mvnI0pe50UpDIbpBMx18X6pGw97LlnEYR81UKeEUPJWDzE1auJiuBr+teHMqVA5O
DjGqYVQM/3LEK2yeKfYcTtxBqnHE3jwGnqV7AviHT6KqxmKuLQe18Rs+wNR9wmWO
RYSsp3lD0sIYAC/snZx1c3NrwnB5kbwTbISzYLF5wK6WOcguoUPTFnZ7x1uEHImt
pbDdgDKnkuUusHTGQJEz+0xYjugcYImP12nx73qrUUJBq17g9BdfhdBGlRXabIzu
STRDw3gwnoqfXcJLeJ8/3ICauA8TCkugp8vXXbQ+Gk5G/DXMYokR/DvxmTzWmvky
58vhrKOEFvVz9FBd6OALVbghQFVC8vtqvXB+AoM5bzHASlN+yOpt7wC4EOROla6f
qSusq3xvp3aybui5tmlTOQtvMV4kxxoqA/HFmJ/Wdxm3/oQdGCHw5qrlMtjILuM5
B5l+7UDbIiw6Vvi/ouGP7OekzJkTZo1tYY/95yXfg3I9cjv6wgEaRzHrVjF3o/FP
FQL4GN/Fnjz7E8VQ/w0ttJ+sRyoIMvd16FcRRIC0LzpsczlWuhpBfdxuSry80Loi
gztvxP9+MJVhJ5kZ27BJ
=BxwT
-----END PGP SIGNATURE-----


 permalink raw reply	[|nested]
2018-01-29  0:40 CANNON

  2018-01-30  3:30   ` CANNON
       [not found]   ` <PS2P216MB0179F59241705B69BC88CFEF9DFB0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
  
From: CANNON @ 2018-01-30  1:43 UTC (permalink / raw)
  To: bitcoin-dev



-------- Forwarded Message --------
Subject: RE: NIST 8202 Blockchain Technology Overview
Date: Mon, 29 Jan 2018 12:25:05 +0000
From: Yaga, Dylan (Fed) <dylan.yaga@nist•gov>
To: CANNON <cannon@cannon-ciota•info>

Thank you for your comments.
You, along with many others, expressed concern on section 8.1.2.
To help foster a full transparency approach on the editing of this section, I am sending the revised section to you for further comment. 

8.1.2	Bitcoin Cash (BCH)
In 2017, Bitcoin users adopted an improvement proposal for Segregated Witness (known as SegWit, where transactions are split into two segments: transactional data, and signature data) through a soft fork. SegWit made it possible to store transactional data in a more compact form while maintaining backwards compatibility.  However, a group of users had different opinions on how Bitcoin should evolve – and developed a hard fork of the Bitcoin blockchain titled Bitcoin Cash. Rather than implementing the SegWit changes, the developers of Bitcoin Cash decided to simply increase the blocksize. When the hard fork occurred, people had access to the same amount of coins on Bitcoin and Bitcoin Cash.



 permalink raw reply	[|nested]
2018-01-30  1:43 ` CANNON

  2018-01-30  7:22     ` Peter Todd
       [not found]   ` <PS2P216MB0179F59241705B69BC88CFEF9DFB0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
  
From: CANNON @ 2018-01-30  3:30 UTC (permalink / raw)
  To: bitcoin-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/30/2018 01:43 AM, CANNON via bitcoin-dev wrote:
> 
> 
> -------- Forwarded Message --------
> Subject: RE: NIST 8202 Blockchain Technology Overview
> Date: Mon, 29 Jan 2018 12:25:05 +0000
> From: Yaga, Dylan (Fed) <dylan.yaga@nist•gov>
> To: CANNON <cannon@cannon-ciota•info>
> 
> Thank you for your comments.
> You, along with many others, expressed concern on section 8.1.2.
> To help foster a full transparency approach on the editing of this section, I am sending the revised section to you for further comment. 
> 
> 8.1.2	Bitcoin Cash (BCH)
> In 2017, Bitcoin users adopted an improvement proposal for Segregated Witness (known as SegWit, where transactions are split into two segments: transactional data, and signature data) through a soft fork. SegWit made it possible to store transactional data in a more compact form while maintaining backwards compatibility.  However, a group of users had different opinions on how Bitcoin should evolve  and developed a hard fork of the Bitcoin blockchain titled Bitcoin Cash. Rather than implementing the SegWit changes, the developers of Bitcoin Cash decided to simply increase the blocksize. When the hard fork occurred, people had access to the same amount of coins on Bitcoin and Bitcoin Cash.
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

This is much better than the original. My question, the part where it says segwit makes transactions more compact, I thought that transactions are not more compact but rather they just take advantage of extra blockspace beyond that of 1 MB? Yes they would appear to be more compact to un-upgraded nodes due to the witness being stripped, but the transactions are not actually more compact right?
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJab+afAAoJEAYDai9lH2mwCDAP/RRpExXmnPzlvxuhhJ+8gSlc
QRZHVa0nJ2SETTZnQSa+0t8dBO9ROYSnDHuMEqz/ba8o00Rce8icxQvCGOO29OSK
Cru7/UJzYTwnt5mK2ljpUB1Fsx96fAPxfg4QMeDCRe+O5LLkH1als1GGVOwlFnLu
BAV0MoCljWzBxokf0ax8+ZHHYEaKe+Fj9PKby7CZrqQKoL9PkI/n7EvqICUdTCu5
tAz9SNIBVtUxgGx/ZY96hvBx0zorV1IQEWchQ50oh/V+TgmnOW4njQOKc4TcSgfp
TKpRFs8Zd7TzeIS/85GX0APGypchxdjlBaV0EORTO9GYFo7nKlzHkIGOF9Er+E6q
II4qjbKLc5d/wwCIA8MHFW0Vxwv2+0ztApaWAFW42+LeHERaPCzi4NEy5quqvmsE
IiTaGebl2XbTd0I+aB6WWsScTUmfXrt+NL05kwE0KDylY/mSwYMgYjP95X1Mci7X
rcJRf6/pP607EiHlq3MmDlyt4TrYBp9FVVjdjvM+sD8wz72FhWeYJQdyF8t1ToOD
U/ItNsxl5Jx9JvCkBXoX+6MMZ91W7D2x04Ur3OMRmy/lOoztOYAdlKy0tMyRqfCi
L81apfjvmTaR2OTWhCawgZGLXGJcfOG5ECuXC90B6il5Jsts/XwyFMN2Fa1iZB50
cZwF3ySKxoVtpsf/vTW7
=feRa
-----END PGP SIGNATURE-----


 permalink raw reply	[|nested]
2018-01-30  3:30   ` CANNON

  
From: Peter Todd @ 2018-01-30  7:22 UTC (permalink / raw)
  To: CANNON, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

On Tue, Jan 30, 2018 at 03:30:21AM +0000, CANNON via bitcoin-dev wrote:
> On 01/30/2018 01:43 AM, CANNON via bitcoin-dev wrote:
> > 
> > 
> > -------- Forwarded Message --------
> > Subject: RE: NIST 8202 Blockchain Technology Overview
> > Date: Mon, 29 Jan 2018 12:25:05 +0000
> > From: Yaga, Dylan (Fed) <dylan.yaga@nist•gov>
> > To: CANNON <cannon@cannon-ciota•info>
> > 
> > Thank you for your comments.
> > You, along with many others, expressed concern on section 8.1.2.
> > To help foster a full transparency approach on the editing of this section, I am sending the revised section to you for further comment. 
> > 
> > 8.1.2	Bitcoin Cash (BCH)
> > In 2017, Bitcoin users adopted an improvement proposal for Segregated Witness (known as SegWit, where transactions are split into two segments: transactional data, and signature data) through a soft fork. SegWit made it possible to store transactional data in a more compact form while maintaining backwards compatibility.  However, a group of users had different opinions on how Bitcoin should evolve  and developed a hard fork of the Bitcoin blockchain titled Bitcoin Cash. Rather than implementing the SegWit changes, the developers of Bitcoin Cash decided to simply increase the blocksize. When the hard fork occurred, people had access to the same amount of coins on Bitcoin and Bitcoin Cash.
> > 
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > 
> 
> This is much better than the original. My question, the part where it says segwit makes transactions more compact, I thought that transactions are not more compact but rather they just take advantage of extra blockspace beyond that of 1 MB? Yes they would appear to be more compact to un-upgraded nodes due to the witness being stripped, but the transactions are not actually more compact right?

That's absolutely right; this is why segwit is a blocksize increase first and
foremost rather than some kind of transaction size optimization.

It'd be good to get that corrected as well.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

 permalink raw reply	[|nested]
[not found]   ` <PS2P216MB0179F59241705B69BC88CFEF9DFB0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>

  2018-02-06  7:07       ` Damian Williamson
  
From: CANNON @ 2018-02-06  2:08 UTC (permalink / raw)
  To: Damian Williamson, Bitcoin Protocol Discussion

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/31/2018 11:16 AM, Damian Williamson wrote:
> I disagree with the correctness of the following statement:
> 
> 
>> Rather than implementing the SegWit changes, the developers of Bitcoin Cash decided to simply increase the blocksize.
> 
> 
> I would suggest "Rather than being satisfied with the implementation of SegWit changes alone, the developers of
> Bitcoin Cash decided to also increase the blocksize.
> 
> 
> Regards,
> 
> Damian Williamson

You do realize that segwit includes many improvements of which are unrelated to scaling? These same improvements of which
simply increasing the blocksize alone would not fix or enable. Segwit is not just a blocksize increase.
Bitcoin Cash, while increasing the blocksize directly, from my understanding has yet to implement the
improvements and capabilities that segwit enables.

One example being, with transactions hashes being able to be calculated in advanced prior to signing
(due to the signature being in different section than that used
to calculate the transaction ID) it is possible to create transaction trees, enhanced smart contracts, trustless mixing protocols,
micropayment networks, etc...

Segwit also increases the security of signatures.

There are lots of other things segregated witness enables as well.

By saying "..segwit changes alone.... decided to also..." Bitcoin Cash has not implemented segwit. Bitcoin Cash only
increased the blocksize.

that wording above at least from the way I read it, seems to imply that Bitcoin Cash has segwit.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJaeQ3IAAoJEAYDai9lH2mwKkQP/3dgYApq1qv2lGIyZIdeN9SE
D5AuXPqFQYAoMwhC0RPNQU/jUisKIyd6zm4XCIm6KPufCtXkjfH9FLhd0ThbCTcy
Gk+pYYRBzSuBZdPBKg0DHu7alRETtxbdtUI0zDfERt1FFZb+HmcDcGTfwdVci3fa
jBiFXq1R+myMW5xdB44dipSk5kBhcpx2zitr1bIA4rF11QbxKAmzU7iPdRpA+PXz
gB9NImc1Dbz+TEA50tdq3v9Ov3x7m7F+QtBnqyLAigJh6XKa6guCfwKIGoawRGwZ
v2ur7T+Qh3KGRXCBlHnxgtFte16wHagwvsVgE5EEmJR0yJUc/4XU2kCGANVNDZ/P
pphqk8pruQ5rjQ8S+s6i5XG8oHVSB2fDh56NvPY7msA72j+Gk+XneV2eJbEAdjhb
9Ci7u1uPJL3pb3c/ZOwQvpIRV3tRjlh0DertWkd3Li5RZLO3uFvBTxNxrni6+9bf
/cmAOwfHjoUp8BX/nvgMjpIDCoEu+Rv9IO/ok3s3mX300JbczAdGbXbsPTE5G+DI
RB1kSmszwst8wOlOAsdVqk/iKRJdN9daTGGN6aE/wjkpSg8rW9BOaoI2X9t4oXCU
+oe/WlgkxhxPcNyhKpLeeYVe6nFX2fjU+THyyiAq/LJ/qHU/brKpXc4NesCVHhQP
BBlxiN0E4gndMGs/Lx89
=+UCK
-----END PGP SIGNATURE-----



 permalink raw reply	[|nested]
2018-02-06  2:08     ` CANNON

  
From: Damian Williamson @ 2018-02-06  7:07 UTC (permalink / raw)
  To: CANNON, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2862 bytes --]

Then you have my apology, I will not claim to be any kind of advocate or user of Bitcoin Cash but *had* understood that segwith had been enabled. Clearly my mistake.


Regards,

Damian Williamson

________________________________
From: CANNON <cannon@cannon-ciota•info>
Sent: Tuesday, 6 February 2018 1:08:24 PM
To: Damian Williamson; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/31/2018 11:16 AM, Damian Williamson wrote:
> I disagree with the correctness of the following statement:
>
>
>> Rather than implementing the SegWit changes, the developers of Bitcoin Cash decided to simply increase the blocksize.
>
>
> I would suggest "Rather than being satisfied with the implementation of SegWit changes alone, the developers of
> Bitcoin Cash decided to also increase the blocksize.
>
>
> Regards,
>
> Damian Williamson

You do realize that segwit includes many improvements of which are unrelated to scaling? These same improvements of which
simply increasing the blocksize alone would not fix or enable. Segwit is not just a blocksize increase.
Bitcoin Cash, while increasing the blocksize directly, from my understanding has yet to implement the
improvements and capabilities that segwit enables.

One example being, with transactions hashes being able to be calculated in advanced prior to signing
(due to the signature being in different section than that used
to calculate the transaction ID) it is possible to create transaction trees, enhanced smart contracts, trustless mixing protocols,
micropayment networks, etc...

Segwit also increases the security of signatures.

There are lots of other things segregated witness enables as well.

By saying "..segwit changes alone.... decided to also..." Bitcoin Cash has not implemented segwit. Bitcoin Cash only
increased the blocksize.

that wording above at least from the way I read it, seems to imply that Bitcoin Cash has segwit.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJaeQ3IAAoJEAYDai9lH2mwKkQP/3dgYApq1qv2lGIyZIdeN9SE
D5AuXPqFQYAoMwhC0RPNQU/jUisKIyd6zm4XCIm6KPufCtXkjfH9FLhd0ThbCTcy
Gk+pYYRBzSuBZdPBKg0DHu7alRETtxbdtUI0zDfERt1FFZb+HmcDcGTfwdVci3fa
jBiFXq1R+myMW5xdB44dipSk5kBhcpx2zitr1bIA4rF11QbxKAmzU7iPdRpA+PXz
gB9NImc1Dbz+TEA50tdq3v9Ov3x7m7F+QtBnqyLAigJh6XKa6guCfwKIGoawRGwZ
v2ur7T+Qh3KGRXCBlHnxgtFte16wHagwvsVgE5EEmJR0yJUc/4XU2kCGANVNDZ/P
pphqk8pruQ5rjQ8S+s6i5XG8oHVSB2fDh56NvPY7msA72j+Gk+XneV2eJbEAdjhb
9Ci7u1uPJL3pb3c/ZOwQvpIRV3tRjlh0DertWkd3Li5RZLO3uFvBTxNxrni6+9bf
/cmAOwfHjoUp8BX/nvgMjpIDCoEu+Rv9IO/ok3s3mX300JbczAdGbXbsPTE5G+DI
RB1kSmszwst8wOlOAsdVqk/iKRJdN9daTGGN6aE/wjkpSg8rW9BOaoI2X9t4oXCU
+oe/WlgkxhxPcNyhKpLeeYVe6nFX2fjU+THyyiAq/LJ/qHU/brKpXc4NesCVHhQP
BBlxiN0E4gndMGs/Lx89
=+UCK
-----END PGP SIGNATURE-----


[-- Attachment #2: Type: text/html, Size: 4079 bytes --]

 permalink raw reply	[|nested]
[not found] ` <BY1PR09MB09045CA927AB6A87BBB315D9E4E50@BY1PR09MB0904.namprd09.prod.outlook.com>

  
From: CANNON @ 2018-02-18 16:20 UTC ( / )


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Pardon my unproffesional tone in my original comment.
But thank you for passing on these corrections. This looks much better.
I have a few comments that might lend to making this even more accurate or complete.
It is nice to see Bitcoin Cash use the proper ticket "BCH" and with
clarrification that segregated witness  was a softfork (backwards compatible
and optional to unupgraded nodes) instead of a hardfork. While segwit might
seem to compact more transactions to unupgraded nodes still using the 1 MB
blocksize limit (because signature data is stored outside of this legacy 1MB
limit), segwit is not actually more compact, but rather is a conservative blocksize
increase as a result of the new block space made available through segwit upgrade.

(One question I do have, which I am going to ask on the bitcoin-dev mailing list, is
"Is the increased blockspace made available through SegWit limited to just witness data?")

Segwit is not just about increased blockspace or transaction capactity though, but
also has more advantages as a result of seperating the signature into a different
segment. More information can be found here https://bitcoincore.org/en/2016/01/26/segwit-benefits/

One advantage is with segwit seperating the signature data, advanced smart contracts and functions
on top of bitcoin can be used. This is due to transaction IDs being able to be calculated without
signatures, or before being signed.

Segwit also increases signature security, and if I am correct enables signatures algorithms to be
able to be upgraded via a softfork.

Segwit also enables Lightning Network. Lightning Network upgrade to Bitcoin enables instant and really
cheap transactions which can handle micropayments and massive scaling of throughput of transactions per second.

With micropayment networks such as Lightning Network, payments can be made off-chain, while still being enforced
by and settled on the Bitcoin blockchain. The Bitcoin blockchain would act as a settlement or dispute layer. As
a result this would also result in freed up space on the bitcoin blockchain as well.

The political reasons which differ from the "bitcoin cash" crowd, and the "bitcoin" crowd is the long term vision
of how to scale Bitcoin. The majority of the "bitcoin cash" crowd believes that scaling should be done by
simply raising the blocksize.

The majority of the "bitcoin" crowd, believes that increasing the blocksize to accomodate for all transactions like
what "bitcoin cash" is doing, would lead to dangerous centralization of whom would able to operate a Bitcoin node.
This is due to the factors of both storage, and bandwidth which are needed to sync and store the blockchain by nodes.

https://lightning.network/lightning-network-paper.pdf
Paper:
The Bitcoin Lightning Network:
Scalable Off-Chain Instant Payments
DRAFT Version 0.5.9.2
page 2-3 outlines a good description of why increasing the blocksize to accomodate every global transaction as a scaling
solution is not feasible.

In summary,
So while the majority of the bitcoin crowd see micropayment channels and micropayment networks on higher layers as the
next step in scaling for handling majority of transactions, the "bitcoin cash" supporters prefer to simply increase the
blocksize to handle all these transactions.

I plan on reading the rest of this paper to see if I have any other things to add.

Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
Email: cannon@cannon-ciota•info
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.

On 01/29/2018 12:25 PM, XXXXXName removed for privacyXXXXXX  wrote:
> Thank you for your comments. You, along with many others, expressed
> concern on section 8.1.2. To help foster a full transparency approach
> on the editing of this section, I am sending the revised section to
> you for further comment.
>
> 8.1.2 Bitcoin Cash (BCH)
> In 2017, Bitcoin users adopted an improvement proposal for Segregated Witness
> (known as SegWit, where transactions are split into two segments:
> transactional data, and signature data) through a soft fork. SegWit
> made it possible to store transactional data in a more compact
> form while maintaining backwards compatibility.  However, a group
> of users had different opinions on how Bitcoin should evolve  and
> developed a hard fork of the Bitcoin blockchain titled Bitcoin
> Cash. Rather than implementing the SegWit changes, the developers
> of Bitcoin Cash decided to simply increase the blocksize. When the
> hard fork occurred, people had access to the same amount of coins
> on Bitcoin and Bitcoin Cash.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJaiabpAAoJEAYDai9lH2mwOVMP/id1xlK7Z7Sx0YpRD0SOHPw2
Ly/C42TQKH/w5zW5NnzndFJhgrLw68FDHcNRXF7NkryJBH9uZC0PuK/F7p2fGfdc
OAGAnz6dGJKi3aIXS9wyuLXCOBRuBN/PEOTiYk8t7HZ8n60Lsdo5zMxZhuS7QNdu
g1w3UtosNNXU5+9l4LpcRfynXSCCnh1EnNHa9qTIjmCJIjphnpu/hGVAIYWrYwof
AgcEMnv+KseYl6zWs7l5+nevAiDjxrUGEuHDUD9N0+kSLYv3Jsp8t++6q5gdtAI4
xfbyZaIOrSidSe3iSNCnHYuf6TQ/+RstvgPd4VfPJsCK+jVxuJ5R3MC0b5+3cWGU
iUnYsPuX7lKE00B/tW8gVoyVtzYc4eiv8Tp50GeI4Gv6n4K+QuKM82S9DPfn1Ku8
1vJpyL4LrZLkhmYGdTt2ajmg88wXpcySfaPa+xEY0bFziqEqnKgQgwAv1p3a5PbM
WCU2x8Hrv8mMR/RCpo4I0QmkdZfM6ITHGRX/WZa3MVdHB8C1hqT574AKyWvzse4K
YxIdbDZU0cjE5o7oOqTRAF1uR7XD2v8XAbyqQJaHi9z9n8l+CbyEXwNIHAWTkPPb
OVGmnECTCxE0ZZAyaYWaAEnK3FnYEWlF92LKUmjQxD6+1YkCiEe0X2AwFibXw3at
FPcZUkjeX+c7YDArq20l
=Ryov
-----END PGP SIGNATURE-----