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 8EBF4596 for ; Tue, 9 May 2017 14:33:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 534E8168 for ; Tue, 9 May 2017 14:33:36 +0000 (UTC) Received: by mail-oi0-f42.google.com with SMTP id w10so1756818oif.0 for ; Tue, 09 May 2017 07:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=US4D1DEP7q5sZeEopKluvBvDJ77USJatqwZCXrQYQl4=; b=tp+bn7bhMAOgOO7ull7IBDcJ5XTLudI81604v7irmbzx2sJnLcUzeCToaLQaLYXV2M raLOLXpApn2mt2QLDXuXbULF9DjyMxALZNSbHXwb18dpLczOQxXaCZMBd0PrX3eFYZNo HIN23hfjppZDg3u25v+nkPIA6u8uj350dOdVGO36Wl7h6mG9X+BJXMzjCx0Zd64Noux5 qqh5b9PMLW0P67+xAqUZ2EKv8K/y1BQEPp8mPDmIlCHQ1bND+TxqFTkMsji2JouQ/LQ6 8RxJdM0VFP/5cbHh+cVHds2ADhJi7lyBMptIQ4tks3wXWMyj4y+SmxJOdr7YJn4AbUL0 UNqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=US4D1DEP7q5sZeEopKluvBvDJ77USJatqwZCXrQYQl4=; b=BRkPVSBAG965BePC3uNjs8+2QnlDE/cRfwQIa3S2PuS69py76QA4x5qHAgmLajV0rU 2bKgJmH7sILhep4MWX8+aU9K0k7Fo9zDPyQSDGlw/br9yLHq3MFpsbNtQWTvSD1JwjTn CCZL7zK6k8XRPNg4ZtfaIxOxRrxG/CvRyoh5yDsnC+1a3FtX/4M4rTTJdWDOwW3cffcz 1egXARd8/tHVBpXAEJJ+8GwtIDLpNrdIAlkolOBpxz0KoJiC16Bp92ZIosnsjHepvBkf dRUh2UJuSrP4WmlA9fSBchcNm1L1db1mJzNBU2447rN9bU5oH6ugZMgJAr7RgcrNDI30 KViw== X-Gm-Message-State: AODbwcAcSJELsLSnPoJRr4w+JgOQLv3u4qhxxPUu9L7iBh01aF+bLJ0a qQYPYqdR6mxOgQOIKnFbCKhsl4XSDA== X-Received: by 10.202.74.194 with SMTP id x185mr103516oia.96.1494340415487; Tue, 09 May 2017 07:33:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.130.166 with HTTP; Tue, 9 May 2017 07:33:34 -0700 (PDT) In-Reply-To: References: From: James Hilliard Date: Tue, 9 May 2017 09:33:34 -0500 Message-ID: To: Sergio Demian Lerner Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev Subject: Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 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: Tue, 09 May 2017 14:33:37 -0000 The discount is designed to reduce UTXO bloat primarily, witness spam data would not make it into the UTXO set. The discount brings the fee of a transaction more in line with the actual costs to the network for the transaction. A miner spamming the network with 4MB witness blocks would have very little impact on the UTXO size compared with 1MB non-witness blocks. UTXO size is a bigger issue than blockchain size since full nodes can't prune the UTXO set. The discount of 75% for the SegWit softfork doesn't really have any effect on future hard forks as it can always be adjusted as needed later on as part of a HF. On Tue, May 9, 2017 at 8:49 AM, Sergio Demian Lerner via bitcoin-dev wrote: > This [1] article says the current discount prevents witness spam. Witness > spam is free space in the witness part of the block that can be filled by > miners to create bigger blocks with almost no cost for the benefit a cluster > of miners with low latency, increasing centralization. > > The 75% discount does not prevent it, but on the contrary leaves a lot of > extra witness space for spam. > > If the maximum block weight is set to 2.7M, each byte of non-witness block > costs 1.7, and each byte of witness costs 1, then a normal filled block > would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4 > Mbyte block. The worst case would be the average case, and the transaction > rate would be the maximum possible. > > The current 75% discount can only achieve more transactions per second if > the type of transactions change. Therefore the current 75% discount only > makes the block size worst case worse (4 Mbytes when it should be 2.7 > Mbytes). > > 80% of all inputs/outputs are P2PKH. The only way to make use of the extra > witness > space If most P2PKH transactions are replaced by multisigs (typically for > LN). > > So it seems the 75% discount has been chosen with the idea that in the > future the current transaction pattern will shift towards multisigs. This is > not a bad idea, as it's the only direction Bitcoin can scale without a HF. > But it's a bad idea if we end up doing, for example, a 2X blocksize increase > HF in the future. In that case it's much better to use a 50% witness > discount, and do not make scaling risky by making the worse case block size > 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes. > > I've uploaded the code here: > https://github.com/SergioDemianLerner/SegwitStats > > [1] > https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e. > > > On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev > wrote: >> >> Sergio, >> >> I'm not sure what the data you present has to do with the discount. A 75% >> discount prevents witness spam precisely because it is 75%, nothing more. >> The current usage simply gives a guideline on how much capacity is gained >> through a particular discount. With the data you show, it would imply that >> those blocks, with SegWit used where possible, would result in blocks of >> ~1.8MB. >> >> >> >> On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev >> wrote: >>> >>> I have processed 1000 blocks starting from Block #461653. >>> >>> I computed several metrics, including the supposed size of witness data >>> and non-witness data (onchain), assuming all P2SH inputs/outputs are >>> converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH. >>> >>> This takes into account that other types of transactions will not be >>> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't >>> take into account that LN transactions may affect the current state, >>> increasing the segwit/nosegwit ratio. >>> >>> Among a lot of information, I've got the following real world results... >>> >>> acMainChainSpace =352608924 >>> acSegwitSpace =599400403 >>> Ratio segwit/nosegwit=1.6999 >>> >>> This implies that the 75% that discount is not the best option to prevent >>> witness spam in a block of 4 MB, as stated in >>> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e. >>> >>> The non-witness data weight factor should not be 4 but 2.35. The closest >>> integer value is 2, which leads to a 50% witness discount. >>> >>> The Bitcoinj source code is available for anyone to review. I encourage >>> anyone to re-compute this with another utility to cross-check. Maybe Antoine >>> Le Calvez (p2sh.info) would like to double-check. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >