From: CANNON <cannon@cannon-ciota.info>
To: undisclosed-recipients: ;
Subject: Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview
Date: Sun, 18 Feb 2018 16:20:13 +0000 [thread overview]
Message-ID: <39d9da2d-c462-66bc-1b24-f5531265018b@cannon-ciota.info> (raw)
In-Reply-To: <BY1PR09MB09045CA927AB6A87BBB315D9E4E50@BY1PR09MB0904.namprd09.prod.outlook.com>
-----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-----
next prev parent reply other threads:[~2018-02-18 16:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cad6fbdf-b826-41e8-f8ff-c37ec72193e9@cannon-ciota.info>
2018-01-29 1:08 ` [bitcoin-dev] NIST 8202 Blockchain Technology Overview CANNON
[not found] ` <BY1PR09MB09045CA927AB6A87BBB315D9E4E50@BY1PR09MB0904.namprd09.prod.outlook.com>
2018-02-18 16:20 ` CANNON [this message]
2018-01-29 0:40 CANNON
2018-01-30 1:43 ` CANNON
2018-01-30 3:30 ` CANNON
2018-01-30 7:22 ` Peter Todd
[not found] ` <PS2P216MB0179F59241705B69BC88CFEF9DFB0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
2018-02-06 2:08 ` CANNON
2018-02-06 7:07 ` Damian Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=39d9da2d-c462-66bc-1b24-f5531265018b@cannon-ciota.info \
--to=cannon@cannon-ciota.info \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox