On Thu, Jul 13, 2017 at 06:23:11PM -0300, Lucas Clemente Vella via bitcoin-discuss wrote: > I just read on a Reddit post by a SegWit opposer that it increases the > badwitdth and storage needs to 400% of current needs, while allowing for 160% > of the number number of transactions. Is that true? Is 240% more data the > price > we pay for preventing non-updated nodes from forking the network?
The statements might be true separately, but are not true together. You either get 160% of the number of transactions at a cost of 160% of the bandwidth/storage; or you get 400% of the number of transactions at a cost of 400% of the bandwidth/storage. Here's an analogy I've thought of the other day that might help: * Current bitcoin is like a railway system, where every train can have up to 50 carriages, each 20m (60 feet) long, each weighing up to 40 tons. The maximum length of a train is therefore 1km. This also implies the maximum total weight is 2000 tons. * New bitcoin adds a different sort of carriage, that is still 20m long, but only weights 10 tons each [0]; and rather than limit the size of trains by maximum length, it's now limited by the maximum weight each carriage could carry, still at 2000 tons -- perhaps because that's how much your engines can pull. This means that if you have a train with old style carriages only, its maximum length is still 1km, but if you could have one with only new style carriages, you could have a train that's 4km long but still only weights 2000 tons in total. As it turns out, based on actual usage, its expected that there'll end up being about two new style carriages (at 10 tons each) for every old style carriage (at 40 tons each), so the 2000 tons will be made up of about 33 old style carriages (1320 tons) and 67 new style carriages (670 tons), for a total weight on 1990 tons, and a total length of 2km. You get a figure of 160% as many transactions by figuring out the length of the train: where previously you would have had two separate trains, one with 50 carriages and one with 40 carriages to transfer all your data, now you can have a single train with 90 carriages, that transfers all the data, by using some of the new, lighter weight carriages instead. To get a figure of 400% as much bandwidth/storage, you need to have trains that are entirely using the new carriages -- which will require completely different usage patterns than we have today. Maybe that will happen, but even if it does, it will be an increase of 400% compared to what we have today: the single train with 200 new-style carriages full of cargo would have required four of the old trains each with 50 old-style carriages. This is the first time I've tried putting that analogy in words, so it's probably a bit weak, but hopefully it's helpful. Note that there is actually some overhead to segwit transactions, but it's pretty small: something like 10%-20% for each segwit transaction while wallets are transitioning, and at most 6% in the long term (but likely smaller than that, since segwit P2PKH transactions actually have lower overhead than current P2PKH transactions). See: https://bitcoincore.org/en/2016/10/28/segwit-costs/#serialisation-costs Cheers, aj [0] Essentially, this is saying signature data is less dense -- ie has lower weight per volume -- than transaction data in bitcoin by a factor of four; but the "density" of signature data this is a subjective measurement, not an objective one, though, so this difference in density is chosen as a matter of policy; it isn't a constant that can be derived from natural laws. A factor of four is a pretty good policy at the moment, but just as the total block size will probably need to be increased at some point after segwit, the weighting will probably need to be adjusted over time as well. _______________________________________________ bitcoin-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
