Discussion:
NIST 8202 Blockchain Technology Overview
(too old to reply)
CANNON via bitcoin-dev
2018-01-29 00:40:32 UTC
Permalink
Raw Message
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-ciota.info

NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
CANNON via bitcoin-dev
2018-01-29 01:08:24 UTC
Permalink
Raw Message
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.
CANNON via bitcoin-dev
2018-01-30 01:43:22 UTC
Permalink
Raw Message
-------- Forwarded Message --------
Subject: RE: NIST 8202 Blockchain Technology Overview
Date: Mon, 29 Jan 2018 12:25:05 +0000
From: Yaga, Dylan (Fed) <***@nist.gov>
To: 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.
CANNON via bitcoin-dev
2018-01-30 03:30:21 UTC
Permalink
Raw Message
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) <***@nist.gov>
> To: 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-***@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?
Peter Todd via bitcoin-dev
2018-01-30 07:22:55 UTC
Permalink
Raw Message
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) <***@nist.gov>
> > To: 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-***@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
CANNON via bitcoin-dev
2018-02-06 02:08:24 UTC
Permalink
Raw Message
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.
Damian Williamson via bitcoin-dev
2018-02-06 07:07:26 UTC
Permalink
Raw Message
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-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.
CANNON via bitcoin-dev
2018-02-18 16:20:13 UTC
Permalink
Raw Message
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-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.
Loading...