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/ [4]
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/ [1]):
* 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
[2]
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [3]
Links:
------
[1] https://bitcoincore.org/en/2016/10/28/segwit-costs/
[2]
https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transactions-what-would-be-the-max-number-of-transaction-confi
[3] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
