From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2F646C0037 for ; Sat, 13 Jan 2024 15:04:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id EB2F041E72 for ; Sat, 13 Jan 2024 15:04:00 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org EB2F041E72 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=kpaHV7OA X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wt4283f2Z5Ti for ; Sat, 13 Jan 2024 15:04:00 +0000 (UTC) Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) by smtp4.osuosl.org (Postfix) with ESMTPS id E169041E20 for ; Sat, 13 Jan 2024 15:03:59 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E169041E20 Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-598a5448ef5so1981003eaf.0 for ; Sat, 13 Jan 2024 07:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705158239; x=1705763039; darn=lists.linuxfoundation.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2o/QvAa6uc/VpBkOtkNaQlM9fudD6ugcWg14tkswBYY=; b=kpaHV7OAuU3mHmdmys6J0SMHmnZOIpDELZ+x/lPAd2pWKmG2Sb0t14qZ31G22xlSZk JEEq2FxEUQAlJtr2fLctXxiWgeS6VGiKUS0njrbBKXK/jp7A6cb7kjsQ/MwVE8s/MMZQ hYR8GS9fVHSYLEN6NEyUfuTKLKpDwFzUH9V+sJLfwV1NKZAe3bfrGDWesVWrhNiSMRnK IiUsfeFCszNvfG0iXVkFJCkL6l1xsvB5X5w8uW9QoDI55XSPMmAl7P56TtT2e2+3nJFO /PNZtobzo5k1iWpsRz57A/CS40GhvBvb+/JAoW3y2xwR9kbrdei7HVaTh05CpSSc1s/F hY6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705158239; x=1705763039; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2o/QvAa6uc/VpBkOtkNaQlM9fudD6ugcWg14tkswBYY=; b=WIy6nuiE40i9EEKxJECnDebg77TBlkh1v5xa3i+/9jNLAJr3I+2OPmoXXXLa0W695r H9TFD9HP/DfLmscOrjl6m0Dleq5qYTo8Akiyy72dode6sDh1n1tFFRBJyjo/XDLnNL6J x4S/7oAlNVrQ66vHwmUfclrl68uuxThMS//AE4o4MgZVDwY7SOkD2WOfAELpdRJR3Kp3 zTSylnGCBDSbNT02G1XzEmtJT5b7CJnN3F5NS8mAmXLmijOK4v44O7incJO4OrpRDqsk GrTLUNmaW6WklObw+sBnm2YVvywCU/iHv0vp4+EuHPQ0OBrhpFXSYT9aHmEBLp6qa5k7 wXCA== X-Gm-Message-State: AOJu0YxtQDjDleQIAPJXcr/drLfHHj6tuqCB4fkgC4Btl+Ue5Mu0UYBu HXWI9BUMSq1nIBbDSufsKQZZQ09FdquCrQ5NRds= X-Google-Smtp-Source: AGHT+IFPXNnIKeY+5aOmvtdIU1VCn05UcAYMY6ZbkdMCBne70RKW2xcCRQcT5WostNgG3JbtU0IW3CvMoV/g38DakAM= X-Received: by 2002:a05:6358:460e:b0:175:597a:5c9 with SMTP id y14-20020a056358460e00b00175597a05c9mr4850419rwl.48.1705158238734; Sat, 13 Jan 2024 07:03:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Tonoski Date: Sat, 13 Jan 2024 16:04:12 +0100 Message-ID: To: Nagaev Boris Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 13 Jan 2024 15:58:17 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2024 15:04:01 -0000 On Wed, Dec 27, 2023 at 8:06=E2=80=AFPM Nagaev Boris wr= ote: > > On Wed, Dec 27, 2023 at 2:26=E2=80=AFPM Greg Tonoski via bitcoin-dev > wrote: > > As a result, there are incentives structure distorted and critical > > inefficiencies/vulnerabilities (e.g. misallocation of block space, > > blockspace value destruction, disincentivized simple transaction, > > centralization around complex transactions originators). > > > > Price of blockspace should be the same for any data (1 byte =3D 1 byte, > > irrespectively of location inside or outside of witness), e.g. 205/205 > > and 767/767 bytes in the examples above. > > Witness data does not contribute to utxo set. The discount on storing > data in witness creates an incentive to store data exactly in the > witness and not in the parts contributing to utxo set. > > $ du -sh blocks/ chainstate/ > 569G blocks/ > 9.3G chainstate/ > > Witness data is part of the "blocks" directory which is not > latency-critical and can be stored on a slow and cheap storage device. > Directory "chainstate" contains the data needed to validate new > transactions and should fit into a fast storage device otherwise > initial block download takes weeks. It is important to maintain the > incentives structure, resulting in a small chainstate. I think that the argument "discount on storing data in witness creates an incentive to store data exactly in the witness (...)" is fallacious. The "witness discount" does not affect the cost of data storage in a Bitcoin node. What the "witness discount" affects is the priority of a transaction pending confirmation only. For example, a SegWit type of transaction of size of 1MB is prioritized (by miners) over a non-SegWit transaction of the same size and fee. "Segwit discount" benefits bloated transactions and puts simple transactions at disadvantage (demonstrated at "https://gregtonoski.github.io/bitcoin/segwit-mispricing/comparison-of-cost= s.html" and "https://gregtonoski.github.io/bitcoin/segwit-mispricing/Comparison_of_= 4MB_and_1.33MB_blocks_in_Bitcoin.pdf"). The Bitcoin fee is not charged per UTXO set size. It is not charged from a node operator. Nodes are up and running independently of Bitcoin fees. Any relation between UTXO set size and discount would be artificial and inefficient, wouldn't it?