From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 17 Apr 2024 17:55:12 -0700 Received: from mail-ua1-f58.google.com ([209.85.222.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rxG3U-000389-8R for bitcoindev@gnusha.org; Wed, 17 Apr 2024 17:55:12 -0700 Received: by mail-ua1-f58.google.com with SMTP id a1e0cc1a2514c-7e6a67e667asf495355241.0 for ; Wed, 17 Apr 2024 17:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1713401705; x=1714006505; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=hvnXjMZc+x+TVn78jDtx6ARzoAuPXRcvjhZGvKUtt6g=; b=SK3ZjB4FjAqrthEIshJupY0EyXEM3zffZoWGxcOxE/3tbagnUbz2dzyYK7ZmTkqAvL A7kQzjnNV+SRDBToi7lccBmeQnA2QNrI0gE2acDFDqG73Pd6YAvhatQQQz+Jp6ITd8ax 0iBW0tlL9rcFe9gE9hvyL/+qAnkn/KnkDXkBu5tgJS9W6y9tWoUOtKrpdNAyLTbBffxp 9YUuat8Bf7v6QqwhYHJB5NuFZPMJLG5mCXLaQHV/BWy0TSSGnEHdJ9zxUHtlggjbfsBM MBHjk+MS4BebHyuHzjSreav4i8HF/HYF3XAB501XXV+hFOCsboQf9Cf+rB2EU/iN8NFm W7EQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1713401705; x=1714006505; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=hvnXjMZc+x+TVn78jDtx6ARzoAuPXRcvjhZGvKUtt6g=; b=QuvvOn7/JKu8YVvdW/sI83O4FAXBjUnwBHilhGetKiBHkutwS7aPJJlZPQE4kmBzfc v0/M8rOP1MgH5WhqEOUgETeWw5f+5eK2nZKJuS9h9FfQ/9jE48RIORGMxML+2RmJrA84 6JxcjgJD4fUyQQx89OTF4AlrIi8xvShiWQ0TxbsRCldi757/D62SVnceZvfDLbGqIin6 96qtXDopwHuDuDDMpDtcMLBCl1PCbYs3nFwtJKD0uT7V8VTCsxLuLqSn4U8shzSGrDDe /iO+0ZiHsXWOjc9Y+JZjX8N9f51taJsN0padwKhllWidLP4kNQmkZCEIq+kZyUdGa9Qe Nczw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713401705; x=1714006505; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=hvnXjMZc+x+TVn78jDtx6ARzoAuPXRcvjhZGvKUtt6g=; b=auXpT6oQ5slHBM6rq9bkjIasFUFewr3yEzgch6ETatC0tQ0mJRBd9ClTKiHf1WGVqW KI43Jas4SG5wUvBnG5lscZ4o2YeBR6T2gDdl2nVEzVh6smcT0PNEoI+QtfYDkvL509Ei YtMZXEq2s/EB4kf0WOCZ7sJuwGmhf/QWUZRqZUoyOFJZ7kaGukbWG8jbUpNs/G33Yi5R 1A1LfkWZaIy8huJ794/dK8+omEcRWZySPWHnbUGZvtKcuP2fiWgPIltOQEfUZl7Q/TWU /ELcVArOGlsVU0muPblp71lVrs5CFmet1W/BjMIDcJntrBtJBarXoYTu++HAn0nCqmBr zIZQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCX+VsSjEGlC4HbnG6Xb2gtd6BhF+TbLlSLL9lCWN+e7y75Suw8+jnZqamRRiCQexzh6dOcXb5hmPl/0idY78uLoVcQTD5A= X-Gm-Message-State: AOJu0YzUHacz369DiOm46ZGRSqBljBWYlqDKAujB9AvwVnqNjNmclTrv iDwVwxSSIqTAPk3aHYIrxj5q/qTR2n1r0HyL8hDJvxLJIc6YMsic X-Google-Smtp-Source: AGHT+IFL8PX0W+R59fvdQ2EV+QgH+Kqrt4PvpyvnleSDg97G9jOj7HM6nIECH4f42ndoLHCVfyCCMQ== X-Received: by 2002:a25:df0e:0:b0:dc6:d258:c694 with SMTP id w14-20020a25df0e000000b00dc6d258c694mr772965ybg.19.1713401299301; Wed, 17 Apr 2024 17:48:19 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:70c1:0:b0:dcd:a08f:c840 with SMTP id l184-20020a2570c1000000b00dcda08fc840ls3631289ybc.1.-pod-prod-09-us; Wed, 17 Apr 2024 17:48:16 -0700 (PDT) X-Received: by 2002:a25:83c2:0:b0:dc7:9218:df47 with SMTP id v2-20020a2583c2000000b00dc79218df47mr267955ybm.5.1713401295943; Wed, 17 Apr 2024 17:48:15 -0700 (PDT) Received: by 2002:a05:690c:f0d:b0:61a:e84a:c592 with SMTP id 00721157ae682-61b02dcd9dbms7b3; Wed, 17 Apr 2024 17:46:24 -0700 (PDT) X-Received: by 2002:a0d:ea82:0:b0:61a:c438:69e7 with SMTP id t124-20020a0dea82000000b0061ac43869e7mr215822ywe.2.1713401183750; Wed, 17 Apr 2024 17:46:23 -0700 (PDT) Date: Wed, 17 Apr 2024 17:46:23 -0700 (PDT) From: Mark F To: Bitcoin Development Mailing List Message-Id: <62640263-077c-4ac7-98a6-d9c17913fca0n@googlegroups.com> In-Reply-To: <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com> References: <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com> Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_54456_163615468.1713401183387" X-Original-Sender: mark@friedenbach.org Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) ------=_Part_54456_163615468.1713401183387 Content-Type: multipart/alternative; boundary="----=_Part_54457_551036384.1713401183387" ------=_Part_54457_551036384.1713401183387 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, March 27, 2024 at 4:00:34=E2=80=AFAM UTC-7 Antoine Poinsot wr= ote: The only beneficial case I can remember about the timewarp issue is=20 "forwarding blocks" by maaku for on-chain scaling: http://freico.in/forward-blocks-scalingbitcoin-paper.pdf I would not qualify this hack of "beneficial". Besides the centralization= =20 pressure of an increased block frequency, leveraging the timewarp to=20 achieve it would put the network constantly on the Brink of being seriously= =20 (fatally?) harmed. And this sets pernicious incentives too. Every=20 individual user has a short-term incentive to get lower fees by the=20 increased block space, at the expense of all users longer term. And every= =20 individual miner has an incentive to get more block reward at the expense= =20 of future miners. (And of course bigger miners benefit from an increased=20 block frequency.) =20 Every single concern mentioned here is addressed prominently in the=20 paper/presentation for Forward Blocks: * Increased block frequency is only on the compatibility chain, where the= =20 content of blocks is deterministic anyway. There is no centralization=20 pressure from the frequency of blocks on the compatibility chain, as the=20 content of the blocks is not miner-editable in economically meaningful=20 ways. Only the block frequency of the forward block chain matters, and here= =20 the block frequency is actually *reduced*, thereby decreasing=20 centralization pressure. * The elastic block size adjustment mechanism proposed in the paper is=20 purposefully constructed so that users or miners wanting to increase the=20 block size beyond what is currently provided for will have to pay=20 significantly (multiple orders of magnitude) more than they could possibly= =20 acquire from larger blocks, and the block size would re-adjust downward=20 shortly after the cessation of that artificial fee pressure. * Increased block frequency of compatibility blocks has no effect on the=20 total issuance, so miners are not rewarded by faster blocks. You are free to criticize Forward Blocks, but please do so by actually=20 addressing the content of the proposal. Let's please hold a standard of=20 intellectual excellence on this mailing list in which ideas are debated=20 based on content-level arguments rather than repeating inaccurate takes=20 from Reddit/Twitter. To the topic of the thread, disabling time-warp will close off an unlikely= =20 and difficult to pull off subsidy draining attack that to activate would=20 necessarily require weeks of forewarning and could be easily countered in= =20 other ways, with the tradeoff of removing the only known mechanism for=20 upgrading the bitcoin protocol to larger effective block sizes while=20 staying 100% compatible with un-upgraded nodes (all nodes see all=20 transactions). I think we should keep our options open. -Mark --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/62640263-077c-4ac7-98a6-d9c17913fca0n%40googlegroups.com. ------=_Part_54457_551036384.1713401183387 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, March 27, 2024 at 4:00:34=E2=80=AFAM UTC-7 Antoine Poinsot wr= ote:
The only benefici= al case I can remember about the timewarp issue is "forwarding blocks" by m= aaku for on-chain scaling:

I would not qualify this hack = of "beneficial". Besides the centralization pressure of an increased block = frequency, leveraging the timewarp to achieve it would put the network cons= tantly on the Brink of being seriously (fatally?) harmed. And this sets per= nicious incentives too. Every individual user has a short-term incentive to= get lower fees by the increased block space, at the expense of all users l= onger term. And every individual miner has an incentive to get more block r= eward at the expense of future miners. (And of course bigger miners benefit= from an increased block frequency.)
=C2=A0
Every single concern mentioned here is addressed prominently in the= paper/presentation for Forward Blocks:

* Increa= sed block frequency is only on the compatibility chain, where the content o= f blocks is deterministic anyway. There is no centralization pressure from = the frequency of blocks on the compatibility chain, as the content of the b= locks is not miner-editable in economically meaningful ways. Only the block= frequency of the forward block chain matters, and here the block frequency= is actually *reduced*, thereby decreasing centralization pressure.

* The elastic block size adjustment mechanism proposed = in the paper is purposefully constructed so that users or miners wanting to= increase the block size beyond what is currently provided for will have to= pay significantly (multiple orders of magnitude) more than they could poss= ibly acquire from larger blocks, and the block size would re-adjust downwar= d shortly after the cessation of that artificial fee pressure.
* Increased block frequency of compatibility blocks has no e= ffect on the total issuance, so miners are not rewarded by faster blocks.

You are free to criticize Forward Blocks, but ple= ase do so by actually addressing the content of the proposal. Let's please = hold a standard of intellectual excellence on this mailing list in which id= eas are debated based on content-level arguments rather than repeating inac= curate takes from Reddit/Twitter.

To the topic o= f the thread, disabling time-warp will close off an unlikely and difficult = to pull off subsidy draining attack that to activate would necessarily requ= ire weeks of forewarning and could be easily countered in other ways, with = the tradeoff of removing the only known mechanism for upgrading the bitcoin= protocol to larger effective block sizes while staying 100% compatible wit= h un-upgraded nodes (all nodes see all transactions).

I think we should keep our options open.

-= Mark

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/62640263-077c-4ac7-98a6-d9c17913fca0n%40googlegroups.com.=
------=_Part_54457_551036384.1713401183387-- ------=_Part_54456_163615468.1713401183387--