Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
From: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <cdc58f64d235e77031d59dc316c85a86@albertodeluigi.com>
Date: Mon, 18 Dec 2017 14:03:44 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <31B7FC33-8C4A-4F73-A126-70D6C830BFBB@friedenbach.org>
References: <003c01d3781e$dda115f0$98e341d0$@albertodeluigi.com>
	<B0012211-15E8-45F8-881C-D4C120288CA4@friedenbach.org>
	<cdc58f64d235e77031d59dc316c85a86@albertodeluigi.com>
To: mail@albertodeluigi.com
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Clarification about SegWit transaction size and
	bech32
Precedence: list

Why would I send you coins to anything other than the address you provided t=
o me? If you send me a bech32 address I use the native segwit scripts. If yo=
u send me an old address, I do what it specifies instead. The recipient has c=
ontrol over what type of script the payment is sent to, without any ambiguit=
y.

> On Dec 18, 2017, at 1:41 PM, mail@albertodeluigi.com wrote:
>=20
> Hi Mark,
> thank you. I understand your point, but despite what we define as a fork, w=
hen a software uses a particular address, it becomes part of the rules of th=
at software. If another software doesn't recognize that address as a bitcoin=
 address, then the rules it enforces aren't compatible with the behaviour of=
 the first software. If you send me your bitcoins, I can't receive it, exact=
ly like if it was in another chain. This happens even if there isn't such a s=
ituation where miners verify that transaction on a chain, while other miners=
 reject it.
>=20
> If we want to change the addresses, we need consensus and the coordinate u=
pgrade of the entire network. In case we haven't consensus, most of the clie=
nts cannot send and receive bitcoins, which is a huge problem.
> For this reason I think it is something we should discuss in order to make=
 a coordinated upgrade, exactly like what we do when we propose a fork. And i=
t would be better to do it precisely as a part of a fork, like a 2x (or what=
ever other upgrade gaining enough consensus)
>=20
> Apart from the proposal of an upgrade to bench32, do you agree with the re=
st of my points? I know segwit is valuable because it fixes tx malleability a=
nd so on... thank you for your link, but that wasn't the point I wanted to h=
ighlight!
>=20
> Thank you,
> Alberto
>=20
>=20
>=20
>=20
> Il 2017-12-18 18:38 Mark Friedenbach ha scritto:
>> Addresses are entirely a user-interface issue. They don=E2=80=99t factor
>> into the bitcoin protocol at all.
>> The bitcoin protocol doesn=E2=80=99t 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=E2=80=A6 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 =E2=80=9Cfork=E2=80=9D in bitcoin-like consensus systems has a very spe=
cific
>> 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-transac=
tions-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=E2=80=99t 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=E2=80=99t
>>> 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=E2=80=99s 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-transac=
tions-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/
>=20
>=20