1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
Return-Path: <cannon@cannon-ciota.info>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A67D6102E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 18 Feb 2018 16:20:25 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from forward4.bravehost.com (forward4.bravehost.com [65.39.211.71])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D55395D1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 18 Feb 2018 16:20:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at bravehost.com
Received: from [10.137.3.35] (exit1.ipredator.se [197.231.221.211])
(Authenticated sender: cannon@cannon-ciota.info)
by forward4.bravehost.com (Postfix) with ESMTPSA id 4CBC6B2D;
Sun, 18 Feb 2018 08:20:18 -0800 (PST)
References: <cad6fbdf-b826-41e8-f8ff-c37ec72193e9@cannon-ciota.info>
<BY1PR09MB09045CA927AB6A87BBB315D9E4E50@BY1PR09MB0904.namprd09.prod.outlook.com>
From: CANNON <cannon@cannon-ciota.info>
Message-ID: <39d9da2d-c462-66bc-1b24-f5531265018b@cannon-ciota.info>
Date: Sun, 18 Feb 2018 16:20:13 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.5.2
MIME-Version: 1.0
To: undisclosed-recipients: ;
In-Reply-To: <BY1PR09MB09045CA927AB6A87BBB315D9E4E50@BY1PR09MB0904.namprd09.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 18 Feb 2018 16:40:42 +0000
Subject: Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Feb 2018 16:20:25 -0000
-----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-----
|