From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0FA2FABC for ; 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 ; Mon, 18 Dec 2017 22:03:47 +0000 (UTC) Received: by mail-pl0-f43.google.com with SMTP id o2so5669054plk.12 for ; 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 X-Mailer: iPhone Mail (15B202) In-Reply-To: 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> 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >>> 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