diff options
author | mail <mail@albertodeluigi.com> | 2017-12-18 22:41:18 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-12-18 21:41:24 +0000 |
commit | fa933911e1659e4eac61241e226ccbba21afac9f (patch) | |
tree | 06af1ae253d52dbc784fdfc1222132616713a1d0 | |
parent | 75bf975578d1d66ddc689716cc0bdc66b3d4d641 (diff) | |
download | pi-bitcoindev-fa933911e1659e4eac61241e226ccbba21afac9f.tar.gz pi-bitcoindev-fa933911e1659e4eac61241e226ccbba21afac9f.zip |
[bitcoin-dev] Clarification about SegWit transaction size and bech32
-rw-r--r-- | fa/7fd2672c2c59f9a9015d16f83067f1d5ed7f87 | 219 |
1 files changed, 219 insertions, 0 deletions
diff --git a/fa/7fd2672c2c59f9a9015d16f83067f1d5ed7f87 b/fa/7fd2672c2c59f9a9015d16f83067f1d5ed7f87 new file mode 100644 index 000000000..e6c5fbe6f --- /dev/null +++ b/fa/7fd2672c2c59f9a9015d16f83067f1d5ed7f87 @@ -0,0 +1,219 @@ +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 EBCD0BC4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 18 Dec 2017 21:41:24 +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 77DCC4FE + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 18 Dec 2017 21:41:23 +0000 (UTC) +Received: from mail.albertodeluigi.com (vm4784 [127.0.0.1]) + by mail8.dominiofaidate.com with ESMTPA + ; Mon, 18 Dec 2017 22:41:18 +0100 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8; + format=flowed +Content-Transfer-Encoding: 8bit +Date: Mon, 18 Dec 2017 22:41:18 +0100 +From: mail@albertodeluigi.com +To: Mark Friedenbach <mark@friedenbach.org> +In-Reply-To: <B0012211-15E8-45F8-881C-D4C120288CA4@friedenbach.org> +References: <003c01d3781e$dda115f0$98e341d0$@albertodeluigi.com> + <B0012211-15E8-45F8-881C-D4C120288CA4@friedenbach.org> +Message-ID: <cdc58f64d235e77031d59dc316c85a86@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:14:55 +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 21:41:25 -0000 + +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/ + + + |