From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 27 Feb 2025 18:41:14 -0800 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tnqJN-0004qf-29 for bitcoindev@gnusha.org; Thu, 27 Feb 2025 18:41:14 -0800 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-2acd587d640sf1482026fac.0 for ; Thu, 27 Feb 2025 18:41:13 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1740710467; cv=pass; d=google.com; s=arc-20240605; b=Ft8W+PlalgXNAtlhkJJXpHmXIt3tQiEQSX/NvrY+2TqVMST9qyhrwfwN+gKrJAa/D7 P0mG9j1Uo6vYd0FoksPlnUP+/DF3o/RrQz53m0ac27jMCncQamDj6DSRTrsRqGfsDMtj EY/+A+fJPlEpbdXqPvV/SrWWRAn4UhIZrTAVFdsouKvhYMe9xL0PZt7oAU1ooDb6dnX8 CAxOKfOE1LVzmuBqjY4Ll1FNc4IH+03LGvj7wSSj7i4tYZBZgLtB0m5sqlemPOrzM3qd kk019ozO5aFbEbG9GZ5Ju/TOi8gJMtDoW8vFy2oIKo/VzXlZqk4ILNvsBiF/+9Qh9anZ 3+GA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding :in-reply-to:from:content-language:references:cc:to:subject :mime-version:date:message-id:sender:dkim-signature; bh=2XEphGbm3CJLDZx+SgQflFD2haDIem+7PaFMl67wzXk=; fh=HvKWDoD1/ex/PHeejw8d/oEYUP3aF/y5hg+GRvOLtOo=; b=j9TYuGVcXY/+s+UoUSby3YJhMJcQEDk3LKXx7RNUVAi5/ayKVU+UOWPGFzpJqto8Fh ETtexICgzMUAS4w5elfbWuK7zuwBN9PcotUjXvFyDvhw+whtsDlTInbmAlOXkeTJDZ2A sP+3ev5U/W6PP0WUYFE7lihJVoqHSIy4yrjht8VqJx7fPb20Q5j39cyGRLyFojFuakDr fib3pnHeb++z8qjtV+B/Kt3xcbYgU2aL6VpbYaaVYnYfSeY+hro1fBOMuWScnhD3i+n8 BOvZOSi1UOIQV/zVzNkcOhldvbi6fYcniVeFAQsYgDKV0TWIlf9K2ITEiBOz+/mNvs0R 3jwQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1740595262 header.b=Wcg+y03M; dkim=pass header.i=@clients.mail.as397444.net header.s=1740595265 header.b=eat8JtHY; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1740710467; x=1741315267; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=2XEphGbm3CJLDZx+SgQflFD2haDIem+7PaFMl67wzXk=; b=Mb8g/ziGBh4AwQhVcUukgI4H9ICAzVFVhmGUw7xP75GCBFvg/dZp58eVv3enQFeV9I CVAhqlxYy32loS1BP7B6VX6doVg2iZyDuG0G/NRX4BlnJzysvB56zMvy07ZsuxEjHKmY nZ7q+2QqWpiaPv4Vyz5QCKHz17i5yde07/WQoL5b/kWK8XqcIk7POPCfbmQ9bFTFeBRh 7tXgh8bnt0RLiB2dX86MdI8EpB45MD6VcTBIDfO4c/MVdSzsZkatjHHxRiU7Ess7oDeA Cs0Yohl2b8XhqloH4e+rT0UFAoIgBHt84y+giyDte+bXe4uZlmWRLoI0OVJfpiufASh4 b5tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740710467; x=1741315267; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:mime-version:date :message-id:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=2XEphGbm3CJLDZx+SgQflFD2haDIem+7PaFMl67wzXk=; b=o2q7AD/IgUfdPU2HJEQZEue3740tPS52hRDS26AKJi45y9bxOyGTVqMdhjb8nr6KUP iOGY1R8dl0Y7xIUwwMrzJrzK47aqJY2qSc7/ETQ0ICtKcLAZUHte3z8lR+ov2s/E/7Ze W845MRGSfq8+zVoZBMet498U3CtlTWFy+8jvrEFon4C7yrGgK6RNnRjTzBEOgM10AVe4 c+VPozX1vwjOU/4POsvxku3jPEc1TIA71oLpyRtfH19ToA5e4Hny9kfRtgpguG6Hnoqv yfw78+b3li1vXwsANY5QIUkRucbZL6cPrINOLcK/6AJ90O+WXRS/l7DoIOVKDxVZ5AcL xRlw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCU1m6mprS5kCBzHF2AuLzEaVmm4Dala+3vA8TvfiUovt5DxoQnzFd2aXoyrpQfoy88RWwjY8VArlNLp@gnusha.org X-Gm-Message-State: AOJu0YyJKugKWfbnLdUTlBNiVExQzUwAwuBxBNWON16IDq0EUh4bDFYO 57PNAn/1OQAQ7/6/yq/wS6goxe1rZbptQIu0vSjD4XBB9ufTVGdD X-Google-Smtp-Source: AGHT+IFfqu0PRKNPMuQ6tEjytXvtvH2884r3p2JiiVRlVndUPqUFoKMpaw84j2VFLA6RJyta6LkwLA== X-Received: by 2002:a05:6870:56a1:b0:29e:5d4e:a4c9 with SMTP id 586e51a60fabf-2c1786cb58bmr992205fac.32.1740710467333; Thu, 27 Feb 2025 18:41:07 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVE8pTmoljYwH2kbsCQiY2RJuT6Ad0N/EHmAU/qlKaixAw== Received: by 2002:a05:6870:bac3:b0:2a0:1e92:8674 with SMTP id 586e51a60fabf-2c154686b8bls1286229fac.1.-pod-prod-08-us; Thu, 27 Feb 2025 18:41:04 -0800 (PST) X-Received: by 2002:a05:6808:2dca:b0:3f3:e9d5:7790 with SMTP id 5614622812f47-3f5584f4a08mr1101339b6e.6.1740710464233; Thu, 27 Feb 2025 18:41:04 -0800 (PST) Received: by 2002:a05:6808:6148:b0:3f4:10e6:fe26 with SMTP id 5614622812f47-3f54e5ffbd4msb6e; Wed, 26 Feb 2025 11:11:57 -0800 (PST) X-Received: by 2002:a17:90b:54cd:b0:2f2:8bdd:cd8b with SMTP id 98e67ed59e1d1-2fe7e3b1756mr7169509a91.29.1740597115819; Wed, 26 Feb 2025 11:11:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1740597115; cv=none; d=google.com; s=arc-20240605; b=fX4bd55b1kOfezL1ciVqhM2rNphRiGAbQB1K4tq8Q4fiYmyKJuboYEKFNeyM2HLvhc E2SEy+4JXTMVmAa+GPPADbsnkyWyDQjNyihNf/B1QFd8AI8BDY1ipXvItyEUwwD3c0Jc hFQuPEDV6pDOKS4SMU3QUrriMzmChM9hVGEab3n2dLXABmsZBVuySxmK+00XQnuuFVkV UOjwL6MKGUkAW+s218SGV0UIdT6WoLV9Pl9YaKU/mqpTXhtpGAiq9tN+22kS6Hn/+FNK 4SYlU9xSCKNdnA2Celroz95N4iDmMnLN1WU1e9ZAZ8Qb5I64NkZb5NaRSw/MH/PxI+wC Rj5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id :dkim-signature:dkim-signature; bh=iRa5RfI1WA2JC3QKn0q15y2OCkwAXlUvF83i5XdXVRU=; fh=mW9lOiD7mqEUjAQlepuZbxptdx3xzS6Su6myLcEVL/g=; b=hzERpKlR/3Tupkdvu3Mw43g50SUpV8aHiGlm9RouHbCHzqgAymHDTNU1UvkWrO/KAy wkyJdcG+OTBdJblPDMJi4FcSwQ9gbc90sHZk5giZKiMxzuGEjfwTGHZgy5fgfxS6464u nZUJ4iOKJ91YfCJ616SJC4/694aoPyDOF2QOlYT5ZZ4RItwDrcYi+fA5qh6O2tGlV/cm uuctR4E424RiRvwyjKjMBNt8Mj5bfy/m7w1qtSN9kpCRz/qgVhEVyAOPTSWVgWTCMq9f l185DVK7P4fjaVmBRw+Prko7JDZPtSCQNEnU8fvXZx9XLmVo7GCaLgcKpmnmP0BeA83c uA1A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1740595262 header.b=Wcg+y03M; dkim=pass header.i=@clients.mail.as397444.net header.s=1740595265 header.b=eat8JtHY; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [69.59.18.99]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-2230a00ac16si2083855ad.4.2025.02.26.11.11.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Feb 2025 11:11:55 -0800 (PST) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1tnMoy-0015ae-20; Wed, 26 Feb 2025 19:11:52 +0000 Message-ID: <58247311-171f-4228-8db9-53363f764880@mattcorallo.com> Date: Wed, 26 Feb 2025 14:11:51 -0500 MIME-Version: 1.0 Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival To: Antoine Poinsot Cc: bitcoindev@googlegroups.com References: <25482CCA-1F9D-4971-914F-674DF15C3414@mattcorallo.com> Content-Language: en-US From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1740595262 header.b=Wcg+y03M; dkim=pass header.i=@clients.mail.as397444.net header.s=1740595265 header.b=eat8JtHY; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com 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.8 (/) On 2/23/25 5:35 PM, Antoine Poinsot wrote: > A 40x decrease to a validation time of 30 seconds probably is worth a= bit of risk for a further > improvement. >=20 >=20 > Depends on what hardware. I don't think a worst case of 30 seconds for en= d users is worth more=20 > risks. A worst case of 30 seconds for miners would probably be concerning= . Sure, I'm not super concerned with an RPi. I am concerned with relatively c= heap miner hardware, tho. > In addition, although the worst case is important to limit the damage an = attacker can do without=20 > being economically rational, what we care about for miners attacking each= other is economically=20 > viable attacks. At the moment the optimal "validation time / cost to atta= cker" ratio is not the=20 > worst case, by a large margin [0]. >=20 > I believe we should take into account the worst case to miners even if no= t economically viable for=20 > an attacker as a safety margin. But we should keep in mind this is alread= y overestimating the attack=20 > risk since in this scenario what we should look at is the worst case vali= dation time of blocks that=20 > may have positive returns to an attacker. Fair enough. > Can you put numbers to this? >=20 >=20 > Sure. Using my functional test which runs the worst case today and the wo= rst case under various=20 > mitigations [1] on a Dell XPS 15 9520 laptop (the model with an i5-12500H= ) i get 120 seconds for the=20 > worst case today and 10 seconds for the worst block with a limited of 250= 0 (potentially) executed=20 > sigops per transaction. To (maybe, they could be running more powerful ma= chines than my laptop)=20 > impose such a validation time to other miners an attacker would have to i= nvest 89 (!!) preparation=20 > blocks. Sure, with low fees the opportunity cost of mining preparation tr= ansactions is not as high=20 > as it could be. But still. Okay! That's a much better outcome than I was thinking. I assume this was w= ith parallelization=20 across the 4+8 available cores? Do you happen to have numbers handy for the= worst-case with, for=20 example, one block of prep? Matt > [0] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/= 70 delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/70?u=3Dantoi= nep> > [1] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/= 61 delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/61?u=3Dantoi= nep> > On Thursday, February 20th, 2025 at 8:22 PM, Matt Corallo wrote: >> In the delving post you said =E2=80=9CThis provides a 40x decrease in th= e worst case validation time with=20 >> a straightforward and flexible rule minimizing the confiscatory surface.= A further 7x decrease is=20 >> possible by combining it with another rule, which is in my opinion not w= orth the additional=20 >> confiscatory surface.=E2=80=9D >> >> Can you put numbers to this? How long does it take to validate a full bl= ock with this 40x decrease=20 >> and how long would it take with the further 7x decrease? >> >> A 40x decrease to a validation time of 30 seconds probably is worth a bi= t of risk for a further=20 >> improvement. A 40x decrease to 1 second is obviously fine :). >> >>> On Feb 5, 2025, at 19:57, 'Antoine Poinsot' via Bitcoin Development Mai= ling List=20 >>> wrote: >>> >>> =EF=BB=BFHi everyone, >>> >>> A bit over a year ago i started working on revisiting the 2019 Great Co= nsensus Cleanup proposal from >>> Matt Corallo [0]. His proposal included: >>> - making <=3D64 bytes transactions invalid to fix merkle tree weaknesse= s; >>> - making non-pushonly scriptSigs, FindAndDelete matches, OP_CODESEPARAT= OR and non-standard sighash >>> =C2=A0types fail script validation to mitigate the worst case block val= idation time; >>> - restrict the nTime field of the first block in each difficulty adjust= ment interval to be no less >>> =C2=A0than 600 seconds lower than the previous block's; >>> >>> I set out to research the impact of each of the vulnerabilities this in= tended to patch, the >>> alternative fixes possible for each and finally if there was any other = protocol bug fix we'd want to >>> include if we went through the considerable effort of soft forking Bitc= oin already. >>> >>> Later in March i shared some first findings on Delving [1] and advertiz= ed the effort on this mailing >>> list [2]. I also created a companion thread on Delving, kept private, t= o discuss the details of the >>> worst case block validation time [3]. As one would expect due to the la= rger design space available >>> to fix this issue, this private thread is where most of the discussion = would happen. Thank you to >>> everyone who contributed feedback, insights, ideas and argumented opini= ons on the different issues >>> all along the process. >>> >>> Now i would like to update the broader Bitcoin development community on= the outcome of this effort. >>> I believe a Consensus Cleanup proposal should include the following. >>> - A fix for vulnerabilities surrounding the use of timestamps in the di= fficulty adjustment >>> =C2=A0algorithm. =C2=A0In particular, a fix for the timewarp attack wit= h a 7200 seconds grace period as well >>> =C2=A0as a fix for the Murch-Zawy attack [4] by making invalid any diff= iculty adjustment period with a >>> =C2=A0negative duration. >>> - A fix for long block validation times with a minimal "confiscation su= rface", by introducing a >>> =C2=A0per-transaction limit on the number of legacy sigops in the input= s. >>> - A fix for merkle tree weaknesses by making transactions which seriali= ze to exactly 64 bytes >>> =C2=A0invalid. >>> - A fix for duplicate transactions to supplement BIP34 in order to avoi= d resuming unnecessary BIP30 >>> =C2=A0validation in the future. This is achieved by mandating the nLock= Time field of coinbase >>> =C2=A0transaction to be set to the height of their block minus 1. >>> >>> I have started drafting a BIP draft with the detailed specs for this. >>> >>> Antoine Poinsot >>> >>> >>> [0] https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197= d3eabe661050c2/bip-=20 >>> XXXX.mediawiki >>> [1] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710 >>> [2] https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAAJ >>> [3] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/71= 1 >>> [4] https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/10= 62#variant-on-zawys-attack-2 >>> >>> --=20 >>> You received this message because you are subscribed to the Google Grou= ps "Bitcoin Development=20 >>> Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send = an email to=20 >>> bitcoindev+unsubscribe@googlegroups.com. >>> To view this discussion visit https://groups.google.com/d/msgid/bitcoin= dev/=20 >>> jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG= 0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI%3D%40protonmail.com. >=20 --=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 visit https://groups.google.com/d/msgid/bitcoindev/= 58247311-171f-4228-8db9-53363f764880%40mattcorallo.com.