path: root/15/0b02370b3edbffc2aca4889c87815fd014197a

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0FA2FABC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 22:03:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pl0-f43.google.com (mail-pl0-f43.google.com
	[209.85.160.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2C584171
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 22:03:47 +0000 (UTC)
Received: by mail-pl0-f43.google.com with SMTP id o2so5669054plk.12
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 14:03:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=x0lbrRWQbefdHM/Qh04atDkszrVMmu7oP7jnY46B3JI=;
	b=sppr/7KNA2L0ZG/HpB7iViSLhh+ERuhLIOpR16IkmAm5cM27R+lQRseJw+ZQ3whw6X
	X5x78y4DtoLG4BGwLPkWTN/CokVfINf3fcpGuQ00jnsu8CdOoFZpufWm6kji0HOLfikL
	kOjStE5c4WUAY65uIKwFD67FGfzLI+xBIYemLdxcqQwb9j9f2D6cUWesTbbMGAOzAeq+
	siLmN35QS07EQDG1pU4jfDMv/iQPXfuQETBBesD1nNsnDf9CwZZ3QFF172AELpTsYmFu
	ec0uCPox2wuIFBD3jMUx4esKK/8hTuqajZR/Ey2qowxCPQWkd4HTCvI806kn/wJ9tr6t
	puOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=x0lbrRWQbefdHM/Qh04atDkszrVMmu7oP7jnY46B3JI=;
	b=izv76gpQmmn/gQfeEZCA1jycsA4kT9lLIJgcjGOHVxwZ/VKuwohyhnRsClsUuLxv/6
	IWLbFYZFSDFgmZAcpGoKrVy+prdafk0euCftPyZG5CMiar3QjE0rEmrPb9OeGIgCVxF3
	LO9aB4YBVPhIhah3qB5BlTuciiQ8Qv0HrS9HvrFjpNK5hxmLL3lSy8lnlHR3y/1OpSrv
	ZH/WJArLcAxQ7vf0JSbJGzzuxU3sMqnoKWmgciiwouc8mBtec3Mz8Y2MMwRxZtIZrSlR
	1mGhExccGYx5jqvJIZokyVHx1K9WC2HxzQ1f/BK2dE5UAiw1BQEhiHFAhWKKXOPy3zv5
	iazw==
X-Gm-Message-State: AKGB3mLdlfvqEqNvuH5GeJzKMi12KAeyhxVCDKfc4kmVkqO/cpA6TcM7
	HRy6HptlI8ygjtlwJJ1aIHCqpHzMAzk=
X-Google-Smtp-Source: ACJfBosBQPHyk1tkss9AHo++Q4QRNIoI6ao0fb5a3X+2oEm5ib2MeV1/2euMgmcKEzo0Wi6dpUQgbQ==
X-Received: by 10.159.246.7 with SMTP id b7mr1041496pls.81.1513634626284;
	Mon, 18 Dec 2017 14:03:46 -0800 (PST)
Received: from ?IPv6:2607:fb90:a50d:ca1d:199:dd52:269f:35d9?
	([2607:fb90:a50d:ca1d:199:dd52:269f:35d9])
	by smtp.gmail.com with ESMTPSA id
	g7sm22611485pgn.43.2017.12.18.14.03.45
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 18 Dec 2017 14:03:45 -0800 (PST)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
From: Mark Friedenbach <mark@friedenbach.org>
X-Mailer: iPhone Mail (15B202)
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
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, MIME_QP_LONG_LINE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Clarification about SegWit transaction size and
	bech32
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Dec 2017 22:03:50 -0000

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