From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 18 Apr 2024 17:19:30 -0700 Received: from mail-yb1-f189.google.com ([209.85.219.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rxbyT-0001RC-8U for bitcoindev@gnusha.org; Thu, 18 Apr 2024 17:19:30 -0700 Received: by mail-yb1-f189.google.com with SMTP id 3f1490d57ef6-de46e8d5418sf1743648276.1 for ; Thu, 18 Apr 2024 17:19:28 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713485963; cv=pass; d=google.com; s=arc-20160816; b=C5VPXg8BBJ4wxIlwJj9z6BaoeXtodoSRnJnNMwOxCLDZCDHoLg71u5R2d4fqFe9Hqi N93vDc4qENJfIgRRTXQvMNC2jLVj/wmUmOT51oYMfZ1FztUWiW1EKR7nQGOcp/7LRSvT RD3nBR/gAhZE34zHKcCJ6PVf+nJmRrWAKMAf7GhTXeHPfS1+/LuwPKqocuQ5YYNWhEsa /lFXjnd5H+f/fDqBD2uYWaUDzGocTHLSVGvypBCwm38de/LIUEpoY/qYxMCUXPCRH6sJ D68GPODu159EPsJbllC/BWKca/MGvOIdfux3hO0KdMG07Jpxj05Ld8l9G4eTzWH920VR KdYA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=sh4OVXxWakLpgpbnl+NKT7WW8Q4LmKR1RM4/mURYq7w=; fh=Y+wTkw1cdyeEDni2zad/HXebWRrrUrwB4wjMQdBCW+Q=; b=zvE75wPQgOSkvexjrHlCwB4Ru0EzqwpabXeEoTADe17u9GLKfCTwMgSuzrZDLp1TdK MapXdpdmQw8rcBFD4VE3Wo7qNrAFgTqiduJPYGHJYERZexf6qR1fBYfyBcxmnB33McyM Y7Hm365qaIWyc1DiKIdBhxMJNZSXpfGLu15iz+Bgz9nESRrdXNMbqBGVZ5km4+8UUKsK kDvsWiflZC7DZvYGU+yyOF2zMS8K3Td/xShRPrr06MuuwqBQxfl48M0jVhkcae+yihaF OodZQLrTd4sQAVSlRxGLy5FZyuX/H5s3io7z7N0iOzbYo6ygJpgrbG2+2h6HCMTJuEzv in7Q==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="KUt/ujTf"; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.27 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1713485963; x=1714090763; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=sh4OVXxWakLpgpbnl+NKT7WW8Q4LmKR1RM4/mURYq7w=; b=To70YdsRDw1fWEMDorctcwlQN2+d3AhUf2oPvoXi+nMZ0Pr6WKfpDNLzkB7zTcsOI+ dx8r0Y6OZ0ZyjwTa57Rn87q0ieaHmEpzxT2w6SwYw/TH7d/aQyK2dsJ46rseyd5D7f2U MmZrcShhem7iO+z9+S8LRZ5blNMjJ+S5wHIaseC8dSsmlIRLONMIY8b8gB9DvsBc8Rt2 dAUZHdwIJgi69n7kA/raK/lTTDIAMdL7/cvI9S1suBPiM2XE1/i6sDs8pmEDMzCWaRTG hAfyOCNw9pxCyUWAjIhFtZD28Xza9gH+mFpLzDwTN1xOqW1w320+PUS/Neu47TCStBw/ Q+rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713485963; x=1714090763; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=sh4OVXxWakLpgpbnl+NKT7WW8Q4LmKR1RM4/mURYq7w=; b=k3W9wjukhi3VlzRFUSmuKcUOkQwF9I+/3nyjMa2ZM+hgzQvHxabfLJhXU0YrFCAB9o XQtpQDVP9Vhpc1i2YhthKti/g7UOy0URSZpRJxaEymzlm0bIAIHx+o09TL/TmK4ZE2/g SeqMF6s2MATgTFDGml6fDZ1t8E1eVWtEOiR16ZK6b/M+DwEfuDgK1FdC0z8SZfyFY72a w2W0cDTkujPRnjyMz2IFW9YsviytbKwi5XP5kynwUAgxfAt9PJwhygDy1iqjenInC+Fm uBNBlxhO6KRy7dGeK6+R0D8qErmMjFYTxjZDGq6RS4mQlwd2EO2+s5IoKv+3NGrLEcpk 8faw== X-Forwarded-Encrypted: i=2; AJvYcCUFlNrCtU3/omXQDmqZoU5DyjWlZSovBXVxr96GjDmn/X2eyxMyjh61bVO9uaML1UZvnZOjzxPV+UO3BFeHxtObpAMAVUU= X-Gm-Message-State: AOJu0Yw6pLe0xDzLAC1XFg2oSfkgoRAppEzheTAOySu5RNDkb3akyHZm pQuD8OVqQCXguqmwxbKp5X3PnQ2IjG5BomAUuCnsofmObwVfa+pE X-Google-Smtp-Source: AGHT+IHT5uNz17pYEprSZ1KCUFGoovDBOxWLXxnzP6k7VqRES1//AV37iHqiDTWvGw/NXev3xHk+7A== X-Received: by 2002:a05:6902:102d:b0:de1:848:35e0 with SMTP id x13-20020a056902102d00b00de1084835e0mr543302ybt.45.1713485962835; Thu, 18 Apr 2024 17:19:22 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6214:2a49:b0:69b:4502:4325 with SMTP id 6a1803df08f44-6a05d76e27als4536106d6.1.-pod-prod-04-us; Thu, 18 Apr 2024 17:19:21 -0700 (PDT) X-Received: by 2002:a05:6214:21ed:b0:69b:5e44:588b with SMTP id p13-20020a05621421ed00b0069b5e44588bmr25598qvj.8.1713485961679; Thu, 18 Apr 2024 17:19:21 -0700 (PDT) Received: by 2002:a05:620a:2441:b0:78f:5e9:4781 with SMTP id af79cd13be357-78f092638bems85a; Thu, 18 Apr 2024 03:04:35 -0700 (PDT) X-Received: by 2002:a2e:3217:0:b0:2db:175d:a261 with SMTP id y23-20020a2e3217000000b002db175da261mr1289240ljy.29.1713434673123; Thu, 18 Apr 2024 03:04:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1713434673; cv=none; d=google.com; s=arc-20160816; b=jU4mqijte3G1/tcdvVfeevqnZKDJLudOM5W2LHcOQ32a2Opp/wDH+URboAvjloPNOa 9WI0Yh5WLOKnsPj1zTZCbyeMcPC54+lfAorCq89vnD/Ydp8C0Xark+XS2XVfoXlPB8gw ROVH88McjW1HLIaM749Nd2kbIIzLFFubXzbvXXdzbNSCHvgXXARzhB9yDFvicpPKxUb9 Czz0ZC4zE2EekC9bthAALb1QRKGZyXiaTwjk2368bd1oqBtgd6Ml1U3zLNGONxbvuWa3 VR4E9lsxklIjTUZYtPZVgxxJZlNUpxDJAYvK+9Gx4ukZgY1DlzZ1bQIMmcHE4eZh1b6M 3uGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=HiE1oDD5MOHHABoxI1d0SoC363ZG6IbRron0op9rRnE=; fh=z5oCwwSe7xynrRNykDxv7s/D8xPCywXAYnRLwx1jmZ0=; b=GMvZ187PYP7BRXKLPwZgS2FZezS3xxiSt0JEX6Vr2/FBxxbkrJh1pr77+vaVdl/iRd AJ1+uMFjQfz/mpagMCzO2Fr8saFU0ey6I8RxxcKOam7Jkgts8LZiZ8uAlWj4C8Z7IIvP m9236Nbeqgkzs3n7Xqgd6x6eRVb9hrEwoBL8+BHUXSSBpoOXwp7Z80ZLGS6sDA5l7hUy uo89/8R8Wn2PKhTptLHt6aB5e+cZdWBbO7+WLAtLSQUZzselKssMxgogjCBupS0RKuBv tNcoQ1xL3fegvnVrb5T0Vij4vXpMC8TStuPU7mECkQLfrm3ptCjEy+wfgoy3tJRmqIDU J8NA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="KUt/ujTf"; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.27 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4027.protonmail.ch (mail-4027.protonmail.ch. [185.70.40.27]) by gmr-mx.google.com with ESMTPS id d4-20020adfa404000000b00343ad9e321asi72424wra.2.2024.04.18.03.04.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Apr 2024 03:04:33 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.40.27 as permitted sender) client-ip=185.70.40.27; Date: Thu, 18 Apr 2024 10:04:18 +0000 To: Mark F From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival Message-ID: <8fFFuAU-SN2NrQ2SKhS2eOeLkHIdCQtnivE4LzWe32vk5gejNEwNvr9IIa3JJ-sII2UUIpOx8oRMslzmA1ZL6y1kBuQEB1fpTaXku2QGAC0=@protonmail.com> In-Reply-To: <62640263-077c-4ac7-98a6-d9c17913fca0n@googlegroups.com> References: <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com> <62640263-077c-4ac7-98a6-d9c17913fca0n@googlegroups.com> Feedback-ID: 7060259:user:proton MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_xOlv1nSSowLT3Iuos96tFwR4hkEAOCrBc0qt7oJJao" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="KUt/ujTf"; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.27 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) This is a multi-part message in MIME format. --b1_xOlv1nSSowLT3Iuos96tFwR4hkEAOCrBc0qt7oJJao Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > You are free to criticize Forward Blocks, but please do so by actually ad= dressing the content of the proposal. Let's please hold a standard of intel= lectual excellence on this mailing list in which ideas are debated based on= content-level arguments rather than repeating inaccurate takes from Reddit= /Twitter. You are the one being dishonest here. Look, i understand you came up with a= fun hack exploiting bugs in Bitcoin and you are biased against fixing them= . Yet, the cost of not fixing timewarp objectively far exceeds the cost of = making "forward blocks" impossible. As already addressed in the DelvingBitcoin post: - The timewarp bug significantly changes the 51% attacker threat model. Wit= hout exploiting it a censoring miner needs to continuously keep more hashra= te than the rest of the network combined for as long as he wants to prevent= some people from using Bitcoin. By exploiting timewarp the attacker can pr= event everybody from using Bitcoin within 40 days. - The timewarp bug allows an attacking miner to force on full nodes more bl= ock data than they agreed to. This is actually the attack leveraged by your= proposal. I believe this variant of the attack is more likely to happen, s= imply for the reason that all participants of the system have a short term = incentive to exploit this (yay lower fees! yay more block subsidy!), at the= expense of the long term health of the system. As the block subsidy expone= ntially decreases miners are likely to start playing more games and that's = a particularly attractive one. Given the level of mining centralization we = are witnessing [0] i believe this is particularly worrisome. - I'm very skeptical of arguments about how "we" can stop an attack which r= equires "weeks of forewarning". Who's we? How do we proceed, all Bitcoin us= ers coordinate and arbitrarily decide of the validity of a block? A few wee= ks is very little time if this is at all achievable. If you add on top of t= hat the political implications of the previous point it gets particularly m= essy. I've got better things to do than to play "you are being dishonest! -no it'= s you -no you" games. So unless you bring something new to the table this w= ill be my last reply to your accusations. Antoine [0] https://x.com/0xB10C/status/1780611768081121700 On Thursday, April 18th, 2024 at 2:46 AM, Mark F wro= te: > On Wednesday, March 27, 2024 at 4:00:34=E2=80=AFAM UTC-7 Antoine Poinsot = wrote: > >>> The only beneficial case I can remember about the timewarp issue is "fo= rwarding 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 centralizatio= n pressure of an increased block frequency, leveraging the timewarp to achi= eve it would put the network constantly on the Brink of being seriously (fa= tally?) harmed. And this sets pernicious incentives too. Every individual u= ser has a short-term incentive to get lower fees by the increased block spa= ce, at the expense of all users longer term. And every individual miner has= an incentive to get more block reward at the expense of future miners. (An= d of course bigger miners benefit from an increased block frequency.) > > Every single concern mentioned here is addressed prominently in the paper= /presentation for Forward Blocks: > > * Increased block frequency is only on the compatibility chain, where the= content of blocks is deterministic anyway. There is no centralization pres= sure from the frequency of blocks on the compatibility chain, as the conten= t of the blocks 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 pressur= e. > > * The elastic block size adjustment mechanism proposed in the paper is pu= rposefully constructed so that users or miners wanting to increase the bloc= k size beyond what is currently provided for will have to pay significantly= (multiple orders of magnitude) more than they could possibly acquire from = larger blocks, and the block size would re-adjust downward shortly after th= e cessation of that artificial fee pressure. > > * Increased block frequency of compatibility blocks has no effect on the = total issuance, so miners are not rewarded by faster blocks. > > You are free to criticize Forward Blocks, but please do so by actually ad= dressing the content of the proposal. Let's please hold a standard of intel= lectual excellence on this mailing list in which ideas are debated based on= content-level arguments rather than repeating inaccurate takes from Reddit= /Twitter. > > To the topic of the thread, disabling time-warp will close off an unlikel= y and difficult to pull off subsidy draining attack that to activate would = necessarily require weeks of forewarning and could be easily countered in o= ther ways, with the tradeoff of removing the only known mechanism for upgra= ding the bitcoin protocol to larger effective block sizes while staying 100= % compatible with 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= "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgi= d/bitcoindev/62640263-077c-4ac7-98a6-d9c17913fca0n%40googlegroups.com. --=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/8fFFuAU-SN2NrQ2SKhS2eOeLkHIdCQtnivE4LzWe32vk5gejNEwNvr9IIa3JJ-sI= I2UUIpOx8oRMslzmA1ZL6y1kBuQEB1fpTaXku2QGAC0%3D%40protonmail.com. --b1_xOlv1nSSowLT3Iuos96tFwR4hkEAOCrBc0qt7oJJao Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You are f= ree to criticize Forward Blocks, but please do so by=20 actually addressing the content of the proposal. Let's please hold a=20 standard of intellectual excellence on this mailing list in which ideas=20 are debated based on content-level arguments rather than repeating=20 inaccurate takes from Reddit/Twitter.

You are the one being dishonest here. Look, i= understand you came up with a fun hack exploiting bugs in Bitcoin and you = are biased against fixing them. Yet, the cost of not fixing timewarp= objectively far exceeds the cost of making "forward blocks" impossible.

As a= lready addressed in the DelvingBitcoin post:
  • The ti= mewarp bug significantly changes the 51% attacker threat model. Without exp= loiting it a censoring miner needs to continuously keep more hashrate than = the rest of the network combined for as long as he wants to prevent some pe= ople from using Bitcoin. By exploiting timewarp the attacker can prevent ev= erybody from using Bitcoin within 40 days.
  • The timewarp bug allows an attacking miner= to force on full nodes more block data than they agreed to. This is actual= ly the attack leveraged by your proposal. I believe this variant of the att= ack is more likely to happen, simply for the reason that all participants o= f the system have a short term incentive to exploit this (yay lower fees! y= ay more block subsidy!), at the expense of the long term health of the syst= em. As the block subsidy exponentially decreases miners are likely to start= playing more games and that's a particularly attractive one. Given the lev= el of mining centralization we are witnessing [0] i believe this is particu= larly worrisome.
  • I'm very skeptical of arguments about how "we" can stop an attack wh= ich requires "weeks of forewarning". Who's we? How do we proceed, all Bitco= in users coordinate and arbitrarily decide of the validity of a block? A fe= w weeks is very little time if this is at all achievable. If you add on top= of that the political implications of the previous point it gets particula= rly messy.

    • I've got better things to do= than to play "you are being dishonest! -no it's you -no you" games. So unl= ess you bring something new to the table this will be my last reply to your= accusations.

    Antoine

    [0] https://x.com/0xB10C/s= tatus/1780611768081121700
    On Thursday, April 18th, 2024 at 2:46 AM, Mark F <mark@friedenba= ch.org> wrote:
    On Wednesday, March 27, 2024 at 4:00:34=E2=80=AFAM UTC-7 Antoin= e Poinsot wrote:
    The onl= y beneficial case I can remember about the timewarp issue is "forwarding bl= ocks" by maaku for on-chain scaling:
    I wo= uld not qualify this hack of "beneficial". Besides the centralization press= ure of an increased block frequency, leveraging the timewarp to achieve it = would put the network constantly on the Brink of being seriously (fatally?)= harmed. And this sets pernicious 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 longer term. And every individual miner has an inc= entive to get more block reward at the expense of future miners. (And of co= urse bigger miners benefit from an increased block frequency.)
    <= /blockquote>
    Every single concern mentioned here is address= ed prominently in the paper/presentation for Forward Blocks:

    =
    * Increased block frequency is only on the compatibility chain, = where the content of blocks is deterministic anyway. There is no centraliza= tion pressure from the frequency of blocks on the compatibility chain, as t= he content of the blocks is not miner-editable in economically meaningful w= ays. Only the block frequency of the forward block chain matters, and here = the block frequency is actually *reduced*, thereby decreasing centralizatio= n pressure.

    * The elastic block size adjustment me= chanism 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 tha= n they could possibly acquire from larger blocks, and the block size would = re-adjust downward shortly after the cessation of that artificial fee press= ure.

    * Increased block frequency of compatibility = blocks has no effect on the total issuance, so miners are not rewarded by f= aster blocks.

    You are free to criticize Forward Bl= ocks, but please do so by actually addressing the content of the proposal. = Let's please hold a standard of intellectual excellence on this mailing lis= t in which ideas are debated based on content-level arguments rather than r= epeating inaccurate takes from Reddit/Twitter.

    To = the topic of the thread, disabling time-warp will close off an unlikely and= difficult to pull off subsidy draining attack that to activate would neces= sarily require 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% com= patible with 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 "= Bitcoin Development Mailing List" group.
    To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googl= egroups.com.
    To view this discussion on the web visit https://groups.= google.com/d/msgid/bitcoindev/62640263-077c-4ac7-98a6-d9c17913fca0n%40googl= egroups.com.

    --
    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/msgid/b= itcoindev/8fFFuAU-SN2NrQ2SKhS2eOeLkHIdCQtnivE4LzWe32vk5gejNEwNvr9IIa3JJ-sII= 2UUIpOx8oRMslzmA1ZL6y1kBuQEB1fpTaXku2QGAC0%3D%40protonmail.com.
    --b1_xOlv1nSSowLT3Iuos96tFwR4hkEAOCrBc0qt7oJJao--