summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authormail <mail@albertodeluigi.com>2017-12-18 22:41:18 +0100
committerbitcoindev <bitcoindev@gnusha.org>2017-12-18 21:41:24 +0000
commitfa933911e1659e4eac61241e226ccbba21afac9f (patch)
tree06af1ae253d52dbc784fdfc1222132616713a1d0
parent75bf975578d1d66ddc689716cc0bdc66b3d4d641 (diff)
downloadpi-bitcoindev-fa933911e1659e4eac61241e226ccbba21afac9f.tar.gz
pi-bitcoindev-fa933911e1659e4eac61241e226ccbba21afac9f.zip
[bitcoin-dev] Clarification about SegWit transaction size and bech32
-rw-r--r--fa/7fd2672c2c59f9a9015d16f83067f1d5ed7f87219
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/
+
+
+