Addresses are entirely a user-interface issue. They don’t factor into the bitcoin protocol at all.
The bitcoin protocol doesn’t have addresses. It has a generic programmable signature framework called script. Addresses are merely a UI convention for representing common script templates. 1.. addresses and 3… addresses have script templates that are not as optimal as could be constructed with post-segwit assumptions. The newer bech32 address just uses a different underlying template that achieves better security guarantees (for pay-to-script) or lower fees (for pay-to-pubkey-hash). But this is really a UI/UX issue. A “fork” in bitcoin-like consensus systems has a very specific meaning. Changing address formats is not a fork, soft or hard. There are many benefits to segregated witness. You may find this page helpful: https://bitcoincore.org/en/2016/01/26/segwit-benefits/ <https://bitcoincore.org/en/2016/01/26/segwit-benefits/> > On Dec 18, 2017, at 8:40 AM, Alberto De Luigi via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hello guys, > I have a few questions about the SegWit tx size, I'd like to have > confirmation about the following statements. Can you correct mistakes or > inaccuracies? Thank you in advance. > > In general, SegWit tx costs more than legacy tx (source > https://bitcoincore.org/en/2016/10/28/segwit-costs/ > <https://bitcoincore.org/en/2016/10/28/segwit-costs/>): > > Compared to P2PKH, P2WPKH uses 3 fewer bytes (-1%) in the scriptPubKey, and > the same number of witness bytes as P2PKH scriptSig. > Compared to P2SH, P2WSH uses 11 additional bytes (6%) in the scriptPubKey, > and the same number of witness bytes as P2SH scriptSig. > Compared to P2PKH, P2WPKH/P2SH uses 21 additional bytes (11%), due to using > 24 bytes in scriptPubKey, 3 fewer bytes in scriptSig than in P2PKH > scriptPubKey, and the same number of witness bytes as P2PKH scriptSig. > Compared to P2SH, P2WSH/P2SH uses 35 additional bytes (19%), due to using 24 > bytes in scriptPubKey, 11 additional bytes in scriptSig compared to P2SH > scriptPubKey, and the same number of witness bytes as P2SH scriptSig. > > But still it is convenient to adopt segwit because you move the bytes to the > blockweight part, paying smaller fee. In general, a tx with 1 input and 1 > output is about 190kb. If it's a Segwit tx, 82kb in the non-witness part > (blocksize), 108 in the witness part (blockweight). > See source: > 4 bytes version > 1 byte input count > Input > 36 bytes outpoint > 1 byte scriptSigLen (0x00) > 0 bytes scriptSig > 4 bytes sequence > 1 byte output count > 8 bytes value > 1 byte scriptPubKeyLen > 22 bytes scriptPubKey (0x0014{20-byte keyhash}) > 4 bytes locktime > https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transactions-what-would-be-the-max-number-of-transaction-confi > > <https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transactions-what-would-be-the-max-number-of-transaction-confi> > > Which means, if you fill a block entirely with this kind of tx, you can > approximately double the capacity of the blockchain (blocksize capped to 1mb, > blockweight a little bit more than 2mb) > > My concern is about segwit adoption by the exchanges. > SegWit transactions cost 10bytes more than legacy transactions for each > output (vout is 256 bits instead of 160). Exchanges aggregate tx adding many > outputs, which is of course something good for bitcoin scalability, since > this way we save space and pay less fees. > But when a tx has at least 10 outputs, using segwit you don't save space, > instead: > - the total blockweight is at least 100bytes higher (10bytes x 10 outputs), > so the blockchain is heavier > - you don't save space inside the blocksize, so you cannot validate more > transactions of this kind (with many outputs), nor get cheaper fee > - without cheaper fees exchanges have no incentives for segwit adoption > before they decide to adopt LN > > In general we can say that using SegWit: > - you decrease the fee only for some specific kind of transactions, and just > because you move some bytes to the blockweight > - you don’t save space in the blockchain, on the contrary the total weight of > the blockchain increases (so it's clear to me why some time ago Luke tweeted > to not use SegWit unless really necessary... but then it's not clear why so > much haste in promoting BIP148 the 1st august risking a split) > > If it's all correct, does something change with bech32? I'm reading bech32 > allows to save about 22% of the space. Is this true for whatever kind of tx? > Immediate benefits of segwit for scalability are only with bech32? > > Bech32 is non-compatible with the entire ecosystem (you cannot receive coins > from the quasi-totality of wallets in circulation), I would say it is a hard > fork. But the bare segwit is really so different? the soft fork is "soft" for > the reference client Bitcoin Core, but outside you cannot know what happens, > there are plenty of implementations (especially frontend customization) which > don’t work with segwit and need to upgrade. To upgrade takes a lot of time, > especially when services are so crowded and so many new people want to step > in. At this point, if bech32 brings only efficiency (but correct me if it’s > not so) and it is well planned, it could be a consensual upgrade, maybe > together with a 2x blocksize? Is there a specific plan for some upgrade in > 2018? I personally think it is far easier to reach consensus on a blocksize > increase una tantum rather than a dynamic increase. You cannot predict the > technology growth: will it be linear, exponential, or suddenly stop for a > while, maybe right before a huge innovation? I think a hard fork bech32 > upgrade + 2x could help a lot in scalability while we test LN, and it might > be the only way to effectively promote (or should I say enforce?) SegWit > adoption. > > thank you, > Alberto De Luigi > (.com) > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
