From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id E46BFC0032; Fri, 20 Oct 2023 18:35:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id AAA22402E0; Fri, 20 Oct 2023 18:35:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org AAA22402E0 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=gdDTko0k 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQLcggyRwBcg; Fri, 20 Oct 2023 18:35:39 +0000 (UTC) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by smtp2.osuosl.org (Postfix) with ESMTPS id 48632400BA; Fri, 20 Oct 2023 18:35:39 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 48632400BA Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-d9beb863816so1150193276.1; Fri, 20 Oct 2023 11:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697826938; x=1698431738; 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=UYq3vvncXUt0K3VBpwKfwv6wRslWMw0oBUSQEsludXA=; b=gdDTko0k0HMBhYs1hVvmWy0WZlo/c63kFKSQPDB9FQbPB9oS7uxSC7RQdl/UmZh7k4 nMadm2rWc+txI4glOL63ydAVdg63XBJf9E32tuPuQDhAjuEoZVq4Npt2YTMbzLC1g+j6 yl0a3b41WjkoCCqjteLSOvRn9eGUgtWQUb4ZQ/CptpQm7o5YOyRjYX2NFXrwvLZslZiw NU3ib/wVAiIrLRYFmoSUGT7gqHqoIfXGFViI8o2vhuvaEnIG8KaY+b4nPpoP3xb9nspN DW1DDstQYc8ppwZo5BhUf+B05tmyfo/gkACXOI5qsi/WFoLSHys6546Zp+x5lWlmHY4E nE4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697826938; x=1698431738; 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=UYq3vvncXUt0K3VBpwKfwv6wRslWMw0oBUSQEsludXA=; b=TAX2xu/CCdIAZZ2NSM9MF5cvGYZkRGZjvXBE8Le0+8R7X49AV7NP++ujvqe8ecAzna eQdF7yYQkSiVtEXglv0DFLKn2kLnjApzeecSejqbQHjjsY1VE67qbgFhMEvsx+RUQjAJ /YNdfW2kgNAS6+DwUTs3rS5pchE4TckuiaFlNWXkdhyOWfxOK94rtcUTJYuENVBSCcpk +Dy95G4gyjfaHDNmDpUywHRQoClSPs33os5LjZ7oSNBEba5dL25K4BdJewy6ANcHrR3c 2k6pAZy2f6m8s89BuQUFAyEr37jG4Sd5sPGfz4NpBUWG6B356BiUbVUZ/wCScZ4Ud3ml WN0g== X-Gm-Message-State: AOJu0Yw9+Pge3qN9RQ8nqzRAwyFtjefwYW1azWog1cucitlreL2BbewT 0ChQKc+eOTGyprmB7dB0r9SBvZCzYRVcu7sBhS+0qmNy X-Google-Smtp-Source: AGHT+IE850Z+4NHAq9eC32CArE9ne39yUjksZmW7Fm+QWMHa+B01YRIiADs5k9gh9i83j3giQmXVNudP5B36kkjLk9o= X-Received: by 2002:a05:6902:641:b0:d9a:4362:67ac with SMTP id h1-20020a056902064100b00d9a436267acmr2548569ybt.15.1697826937983; Fri, 20 Oct 2023 11:35:37 -0700 (PDT) MIME-Version: 1.0 References: <64VpLnXQLbeoc895Z9aR7C1CfH6IFxPFDrk0om-md1eqvdMczLSnhwH29T6EWCXgiGQiRqQnAYsezbvNvoPCdcfvCvp__Y8BA1ow5UwY2yQ=@protonmail.com> In-Reply-To: From: Matt Morehouse Date: Fri, 20 Oct 2023 18:35:26 +0000 Message-ID: To: Peter Todd , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 20 Oct 2023 18:46:59 +0000 Cc: security@ariard.me, "lightning-dev\\\\\\\\\\\\\\\\@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" 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: Fri, 20 Oct 2023 18:35:41 -0000 I think if we apply this presigned fee multiplier idea to HTLC spends, we can prevent replacement cycles from happening. We could modify HTLC scripts so that *both* parties can only spend the HTLC via presigned second-stage transactions, and we can always sign those with SIGHASH_ALL. This will prevent the attacker from adding inputs to their presigned transaction, so (AFAICT) a replacement cycling attack becomes impossible. The tradeoff is more bookkeeping and less fee granularity when claiming HTLCs on chain. On Fri, Oct 20, 2023 at 11:04=E2=80=AFAM Peter Todd via bitcoin-dev wrote: > > On Fri, Oct 20, 2023 at 10:31:03AM +0000, Peter Todd via bitcoin-dev wrot= e: > > As I have suggested before, the correct way to do pre-signed transactio= ns is to > > pre-sign enough *different* transactions to cover all reasonable needs = for > > bumping fees. Even if you just increase the fee by 2x each time, pre-si= gning 10 > > different replacement transactions covers a fee range of 1024x. And you > > obviously can improve on this by increasing the multiplier towards the = end of > > the range. > > To be clear, when I say "increasing the multiplier", I mean, starting wit= h a > smaller multiplier at the beginning of the range, and ending with a bigge= r one. > > Eg feebumping with fee increases pre-signed for something like: > > 1.1 > 1.2 > 1.4 > 1.8 > 2.6 > 4.2 > 7.4 > > etc. > > That would use most of the range for smaller bumps, as a %, with larger %= bumps > reserved for the end where our strategy is changing to something more > "scorched-earth" > > And of course, applying this idea properly to commitment transactions wil= l mean > that the replacements may have HTLCs removed, when their value drops belo= w the > fees necessary to get those outputs mined. > > Note too that we can sign simultaneous variants of transactions that dedu= ct the > fees from different party's outputs. Eg Alice can give Bob the ability to > broadcast higher and higher fee txs, taking the fees from Bob's output(s)= , and > Bob can give Alice the same ability, taking the fees from Alice's output(= s). I > haven't thought through how this would work with musig. But you can certa= inly > do that with plain old OP_CheckMultisig. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev