Delivery-date: Sun, 21 Jul 2024 11:04:36 -0700 Received: from mail-qk1-f185.google.com ([209.85.222.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sVavD-000294-UE for bitcoindev@gnusha.org; Sun, 21 Jul 2024 11:04:36 -0700 Received: by mail-qk1-f185.google.com with SMTP id af79cd13be357-7a199a3eebfsf377437785a.2 for ; Sun, 21 Jul 2024 11:04:35 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1721585070; cv=pass; d=google.com; s=arc-20160816; b=rES5YC1aTb0N8ogjE0oB2VqjtucU2VIb/gr6g9Ds3Yg9dlyyhb3hTlZXqsz/U6jeOQ fD9qEGOyw1f7HQJ2iNWrqSptSX5LdKnsrBmIDob/gdPCXRSGPfuOkvJ85NaEQckVZv3C tpuoeWQ/JSjH2any3k4UP3CoTqH3PqTzFkibGxlCd6C9daCOP+8RZ80alZFsqQXB1pmQ ahWOHafXphE8QpbN9KroEaU+/m98HkeMezDSBBEqkGL4m401sICke5vjDC5r6sVL67WV XOg6jV4UdGzan/Ww/e9Cd6dhX802bDzPeHvzI5C2L/HLH/73tNxCZbgSIno9xDlLWc3C /TAw== 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:content-transfer-encoding :message-id:references:in-reply-to:subject:cc:to:from:date :mime-version:sender:dkim-signature; bh=oWsTk3RKffKl/SFxypwQEFPz8NJBN0GYLjOR3O0Vu6s=; fh=UVebBCZlnoj0ph4dH8fK/isiWBw9egf2QLTfdbvS9nQ=; b=fZhmHdDS0DxEOhJGjl+FAXg2nUO81TyMAKP2tHTEjUEyr4Bq3hOpxhiIkqYsmbuUIj F/nWgoiYrozHcvFSdUruBaSCVe45csPHNL1Hj6Sme86XBeE4dE985o+zDjHjUI4kqJtL 3/DoyiEDX1Vq0tbnsmWit3BIvOZT5ZryLw0x/GEpPEKaz7IqJhesbz02lwIqx0Bnumtw Mv5Dn1llzRInnU6tOSR8qmtDw5mvtxEojfGg1sc/zy0taH6x/9foblp1MClKckcbdy6L dxLGalOF0gfrPROZzePyhuFh3WddVl6We5z3DFZyvW0hoY1kThV1jCCsSB0UBg+bIuUx NhiQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; spf=pass (google.com: domain of dave@dtrt.org designates 2607:fe70:0:3::d as permitted sender) smtp.mailfrom=dave@dtrt.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721585070; x=1722189870; 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:message-id:references :in-reply-to:subject:cc:to:from:date:mime-version:sender:from:to:cc :subject:date:message-id:reply-to; bh=oWsTk3RKffKl/SFxypwQEFPz8NJBN0GYLjOR3O0Vu6s=; b=up2ED82ar4sUq2LBlyirf3wFN51n2vYUHAqrEqz7fR8dDWVFLJ7QcqI4BdxfEdE0a7 pRZsW0MgQQ/C092hFhepDrRE/9knIJDqidyDSGHzGrYBtznto4PqDiwkukMORJ9O3S+k JcuNeqZhogVaOyuWB/ezCFdjNw8lm6aGfEZDEbiHNqLII1ItIhkPStBpqrlJDxQ3H+Te 7EzasM+ZwhKTfHHB5rk0lDvrF4QeGvifJV7j7TFueXVwZCAy4/iTRc5CP034h746oiVG PQv6ro55ChtIFLwbnF1btbQOtEulV5Di92KgDIh8t3xVEf5XYvFp0mCQM85rEkpAyDPg xNFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721585070; x=1722189870; 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:message-id:references :in-reply-to:subject:cc:to:from:date:mime-version:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=oWsTk3RKffKl/SFxypwQEFPz8NJBN0GYLjOR3O0Vu6s=; b=t08qx0OodZYG3hNJHJPZyuI2FmZprOIUq3pdWNWcW6oR55IMSihPl/E4PTpWysoDfT iOGprTzmmyNAC51Z3BtMg0MXEPbxlNZPbcj1fhLVaXlxp1WSXEETJdlieEkhmyZDyZcN JJiratuW1/s8dSwACqp0HvjSGvUD3VpkESgA02pvcY/83S3vn0LdRvdHzN+/9Ui6L5hU rgCbCSHmVWkGwFsJYw3pc24x2C18eGqLTEJMPyyIjpQstP5ISO2C/uAdzv4sCXjwwu17 kGemaQE9ZDYNhVrkqlGos+oue0iCX9BngPZz3sa2jzJvu4FImB+/Bhz8QJU/jynBJI3G ia2A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVHp87wkD3EpeD5cXh5LNW9O1Nxone31f0AQqHGeDCQRh4XWMbtNMyQAMMEt1rlrmr/yuor1rVBtw6M9iBFFjvnMcX9SUk= X-Gm-Message-State: AOJu0YyimvBCtbTT03Q/qx0r/LL0Wdo99IyVStY04iFPelMEUuAVnwP0 MBNdNIM8+2OScP9s+gsOuj2HFL/y+ksJdremp5ye4s19ACwb/pJD X-Google-Smtp-Source: AGHT+IEfJCA1wgNp74K1yOfmYyZ2Qxg9UEhGKy9C5+tXAbsvICoBJmcMwHhwaSRkCeCE22+/pbPo9w== X-Received: by 2002:a05:6214:d0e:b0:6b5:4b10:7849 with SMTP id 6a1803df08f44-6b9610d4277mr68401796d6.1.1721585069499; Sun, 21 Jul 2024 11:04:29 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6214:acf:b0:6b7:8baa:dce3 with SMTP id 6a1803df08f44-6b79b899cfdls101443926d6.2.-pod-prod-00-us; Sun, 21 Jul 2024 11:04:28 -0700 (PDT) X-Received: by 2002:a05:620a:3181:b0:7a1:417a:9d16 with SMTP id af79cd13be357-7a1a1950277mr19310985a.5.1721585068088; Sun, 21 Jul 2024 11:04:28 -0700 (PDT) Received: by 2002:a05:620a:22da:b0:79c:bd3:58c5 with SMTP id af79cd13be357-7a18f14f124ms85a; Sun, 21 Jul 2024 08:35:36 -0700 (PDT) X-Received: by 2002:a05:6102:4a8a:b0:48f:40be:3a9e with SMTP id ada2fe7eead31-4928ba389c0mr4560978137.21.1721576135558; Sun, 21 Jul 2024 08:35:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1721576135; cv=none; d=google.com; s=arc-20160816; b=fg8Lj1mAAc+HdA23sck+zmaV4hfEr5uGCscNlUPp6Qni+KxIXpHlD/I5GDqJbIn1w+ XbCopHNPG1XuO3RsBNR67/ablGLZ6wzwXYWBVB2jvy86T6e20MLOXr6TBoIADPDp0TRI E+XI9BfxNXcbCw/OGlB+Xq5H37tnAdP3MOd6zqH+EhTXzFFsIc0pt09uImTfnmr9YgaL 1wWV8gW/bNyafIAUNp5ZpGF+0IetVaAVMWmkdpiOloUpeptQ63X93H5AKyd2dR0yMmf7 7ufx/fYvH+oevNDoD3R80e2mW1amVO78QguyhqwFHgleeUGguaDe0k8g+e9EIC2W4I0D EGZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:message-id:references:in-reply-to:subject :cc:to:from:date:mime-version; bh=/jjNuIAPeH5iR75fqavLIgj5Oo34ruCdwyZ1PhZsADI=; fh=psWP3UCtCzzPEOUoUzVM9ZZK8adYsTeWDAKCd6L5Zok=; b=jyLp5hDes7bufEoogylKu25aDwU8TEZI2WoqqI/+C2aBY5UUG4VSjfziSbebzW2uLy YNLEoBG9F00Zkv59l6uPzfxU8Ia8zYyxQPESZBmsmxWrT6ji3DRz+OgVdTY7RUmoh0ik Wevdffe3Q6TXfvhsnefOc/fFLgTfAqvLKN+EPVUfy/bCcdcSiq7jKpWZjlsFDK4JZ+cS 6wR7DufBYPBxzvQsp9UHFODxCVPsbsXh7sAztmd+ut6zQQuOZPMjATfqTFRXndiizDXD MoZAOpmVsTNamUZX3T7q1qxPPT5tHp4QLCjOal4Dk+lm50aDLXcYwc0L0369MWS6S7DX 6rwQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of dave@dtrt.org designates 2607:fe70:0:3::d as permitted sender) smtp.mailfrom=dave@dtrt.org Received: from smtpauth.rollernet.us (smtpauth.rollernet.us. [2607:fe70:0:3::d]) by gmr-mx.google.com with ESMTPS id a1e0cc1a2514c-826df49c219si234711241.1.2024.07.21.08.35.34 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Jul 2024 08:35:35 -0700 (PDT) Received-SPF: pass (google.com: domain of dave@dtrt.org designates 2607:fe70:0:3::d as permitted sender) client-ip=2607:fe70:0:3::d; Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id 897A62800864; Sun, 21 Jul 2024 08:35:32 -0700 (PDT) Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Sun, 21 Jul 2024 08:35:31 -0700 (PDT) MIME-Version: 1.0 Date: Sun, 21 Jul 2024 05:35:31 -1000 From: "David A. Harding" To: Peter Todd Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core In-Reply-To: References: Message-ID: X-Sender: dave@dtrt.org Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 490d.669d2ac3.e94f5.0 X-Original-Sender: dave@dtrt.org X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of dave@dtrt.org designates 2607:fe70:0:3::d as permitted sender) smtp.mailfrom=dave@dtrt.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.8 (/) On 2024-07-20 05:03, Peter Todd wrote: > What other "free" relay attacks can you think of that were fixed? The two you mention were the two I had in mind. > Did you actually read my One-Shot RBFR proposal? Yes. It didn't provide any examples of RBFr free relay and I wanted to see whether a basic RBFr free relay attack would use significantly more, significantly less, or about the same amount of bandwidth per dollar spent as other free relay attacks. My conclusion is that it's about the same. > Weak blocks are not a solution to any of the "free" relay attacks I've > disclosed and your source does not claim that they are a "free" relay > solution. It does not explicitly say that, but it does say: "bonus use-cases: =E2=80=9CForcible insertion=E2=80=9D of transactions that are incentive-com= patible but violate anti-DoS rules". For example, in some of the scenarios you describe, the attacker sends an appealing transaction to miners and then sends less appealing versions of that transaction to relay nodes. If the appealing transaction enters the top mempool and gets included in a weak block, relay nodes will stop relaying less appealing variations minutes to hours before they otherwise would. Weak blocks also provide a decentralized DoS-resistant mechanism for voluntarily communicating all sorts of information from miners to other miners and relay nodes. That makes them an excellent tool for resolving any attack that depends on miners and relay nodes having a divergent set of transactions. > 1) Have you've read my One Shot RBFR proposal? In particular, my > analysis of DoS attacks *including* existing DoS attacks like > simultaneous broadcast. >=20 > 2) Do you agree or disagree with me that these existing DoS attacks > are real? Yes, I've read your proposal, and I agree those attacks are plausible. In my mind, the major difference between those free relay attacks and RBFR free relay attacks is how solvable they are. I think it's easy to sketch a significant mitigation to all free relay attacks (including RBFR): - Reduce the maximum size of both relayable transactions and in-mempool packages, e.g. from 100,000 vbytes to 1,000 vbytes. - Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB. - Increase the default mempool feerate floor, e.g. from e.g. from 1 sat/vb to 100 sat/vb. That would break relay of many existing presigned transactions, potentially leading to money loss, and would break other existing usecases, not to mention introduce other problems. However, I think it's sufficient to prove that a mitigation to free relay is possible without rendering the network unusable. Of course, an ideal solution wouldn't require placing any additional constraints on mempool policy. For the case of free relay due to divergent mempool policies, maybe it's something that could be done with transaction set reconciliation (~erlay), functions for allowing independent nodes to come to consistent conclusions about the best revenue set of transactions (~cluster mempool), P2P relay of non-obvious cluster linearizations[1], and miners voluntarily committing to their mempool contents in candidate blocks and P2P relaying those commitments in weak blocks. Innovations like that don't work for RBFR. If mempool policy is kept the same, free relay attacks with RBFR remain equally effective no matter what mechanisms we implement to improve preconsensus consistency. If pure RBFR is added and clever protocol developers find ways to largely fix other free relay attacks, then devs will either need to significantly restrict mempool policy anyway or will need to restrict or remove RBFR to make Bitcoin Core safe. Given that, it seems to me like a very reasonable decision not to add pure RBFR and to wait until better tools like cluster mempool become available before evaluating significant changes to RBF policy (like one-shot RBFR). Thanks, -Dave [1]=20 https://github.com/bitcoinops/bitcoinops.github.io/pull/1421#discussion_r14= 15834695 --=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/d57a02a84e756dbda03161c9034b9231%40dtrt.org.