2017-07-13 18:53 GMT-03:00 Tomas via bitcoin-discuss <bitcoin-discuss@lists. linuxfoundation.org>:
> It is incorrect. SegWit only takes a small overhead of a few percent due > to being wrapped in P2SH. > > The primary argument that is being written incorrectly has to do with the > primary motivation of a limit. Several people (including me) believe that > the only purpose of the limit is to prevent a rogue miner from creating a > gigantic block. These people (including me) believe the network should > never operate anywhere *near* this limit. With SegWit this limit is > extended to 4mb, while the practical maximum transaction rate is raised > only by 1.7x. > But how can we be prevent the network from operate near the limit if there is organic and legitimate demand for more transactions to be approved? If there is demand, miners will inflate the block as much as they can, either to collect transaction fees, or to preserve Bitcoin economic value as a cheap transaction medium (which drives price up, as it is more useful to a wider range of people). Regardless, it is not a particularly valid criticism, as neither a single > 4mb block nor a single 32mb block would serve as a viable DoS attack. > But don't mind the limits: if Segwit is *less* space efficient than currently enforced rules, so it will costs *more* per confirmed transaction to run a full node, thus the transaction size does poses a long term centralization concern: I myself won't be able to run my full node for too much longer, due to storage requirements. If transaction efficiency is worse (storage-wise), I'll have to shut down my node even sooner. > I believe the primary problem with SegWit is that it incentives miners not > to download witness data as I have explained here: > https://bitcrust.org/blog-incentive-shift-segwit.html > This is without doubt bad in the long term for the security of bitcoin and > entirely preventable by using another malleabilty fix like BIP140. > I am not dismissed of my concern, and you have just added another. I agree that an alternative solution is better. BIP-140 seems better than BIP-134 because it is a softfork, although it doesn't address all problems with current transaction rules. -- Lucas Clemente Vella [email protected]
_______________________________________________ bitcoin-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
