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.y...@nist.gov> > > To: CANNON <can...@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
signature.asc
Description: Digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev