path: root/7f/9e7d51ee0142e67e4423aca256a9b4427a5bb4

Return-Path: <mail@albertodeluigi.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 97A7FBA9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 22:19:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail8.dominiofaidate.com (mail8.dominiofaidate.com
	[212.35.195.17])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 22036551
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 22:19:48 +0000 (UTC)
Received: from mail.albertodeluigi.com (vm4784 [127.0.0.1])
	by mail8.dominiofaidate.com with ESMTPA
	; Mon, 18 Dec 2017 23:19:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Mon, 18 Dec 2017 23:19:34 +0100
From: mail@albertodeluigi.com
To: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <31B7FC33-8C4A-4F73-A126-70D6C830BFBB@friedenbach.org>
References: <003c01d3781e$dda115f0$98e341d0$@albertodeluigi.com>
	<B0012211-15E8-45F8-881C-D4C120288CA4@friedenbach.org>
	<cdc58f64d235e77031d59dc316c85a86@albertodeluigi.com>
	<31B7FC33-8C4A-4F73-A126-70D6C830BFBB@friedenbach.org>
Message-ID: <cc605af6ccaf752d26dd85aaf122b8d0@albertodeluigi.com>
X-Sender: mail@albertodeluigi.com
User-Agent: Roundcube Webmail/1.1.1
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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
X-Mailman-Approved-At: Mon, 18 Dec 2017 22:53:50 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: [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:19:50 -0000

Mark,
suppose I am an average user. Give me a bech32 address and ask me to 
send a few coins there. I am 100% sure you will never receive my coins. 
I will call you back saying: "Mark, sorry, I tried with three different 
wallets, but it seems what you gave me is not a bitcoin address!"

My point is: we want SegWit is used and implemented more and more by the 
community. But if besides malleability fix, the main effect of sw 
adoption is this:

1) The blockahin is heavier (transactions require more space)
2) the fee is smaller only for some kind of tx
3) the transactions of the exchanges, which aggregate outputs, would be 
heavier and pay a higher fee using segwit!

then how can we expect people, exchanges and services to adopt segwit?

Thank you,
Alberto De Luigi



Il 2017-12-18 23:03 Mark Friedenbach ha scritto:
> Why would I send you coins to anything other than the address you
> provided to me? If you send me a bech32 address I use the native
> segwit scripts. If you send me an old address, I do what it specifies
> instead. The recipient has control over what type of script the
> payment is sent to, without any ambiguity.
> 
>> On Dec 18, 2017, at 1:41 PM, mail@albertodeluigi.com wrote:
>> 
>> Hi Mark,
>> thank you. I understand your point, but despite what we define as a 
>> fork, when a software uses a particular address, it becomes part of 
>> the rules of that 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, exactly like if it was in another 
>> chain. This happens even if there isn't such a situation where miners 
>> verify that transaction on a chain, while other miners reject it.
>> 
>> If we want to change the addresses, we need consensus and the 
>> coordinate upgrade of the entire network. In case we haven't 
>> consensus, most of the clients 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 it would be better to do it precisely as a part of a fork, 
>> like a 2x (or whatever other upgrade gaining enough consensus)
>> 
>> Apart from the proposal of an upgrade to bench32, do you agree with 
>> the rest of my points? I know segwit is valuable because it fixes tx 
>> malleability and so on... thank you for your link, but that wasn't the 
>> point I wanted to highlight!
>> 
>> Thank you,
>> Alberto
>> 
>> 
>> 
>> 
>> Il 2017-12-18 18:38 Mark Friedenbach ha scritto:
>>> 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/
>> 
>>