From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 08 May 2025 01:17:13 -0700 Received: from mail-oo1-f55.google.com ([209.85.161.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uCwRM-0007Y1-IA for bitcoindev@gnusha.org; Thu, 08 May 2025 01:17:13 -0700 Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-60214b7cdbcsf680400eaf.0 for ; Thu, 08 May 2025 01:17:12 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1746692226; cv=pass; d=google.com; s=arc-20240605; b=ZBp2rw/9pwV1MSeWm3ZwNTUMrWfcoao0GiC+dZMsnum8UieJeNXX00aJZAvlB0YaTn owcMqzjE3ncV663h7K3/wUpEnxoul2EuicNDSNk2YKVKDBJs5b1DH2Uc4M5vkxu54v1p nFnJv9uR3HTHcRW8nMG3j9a4QWJzmqRNxsbURaHaSvWRKi4Ve3LJDClG2pTry9AhaZ4J udb6rNVJQzHS6FjnWpSmqpvFCVXdiUTrCqbIDosEqYvYeXKXrIOnG/PU0YSFxoRt29Ba vBLmhP2UBagKdAK/TkJKOhC5hdBNPVoIANMFlKBAHf/7FvmiBDZdyLJhhSYMJZZTrq7o kggg== 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:date:message-id:mime-version :references:in-reply-to:subject:cc:to:from:sender:dkim-signature; bh=7FsVN33aXNYwFRjRndyWYmPI4eCTS9SiovrV3PvbMp4=; fh=I2E16PE5KzTG30Um20UuCGCwzHqgW3iQAY+an0YHKqc=; b=erbfqyatt9or/8lkgr5SnJOFYiGWTxNPGuzGwcx5EA99f4lhZBlcvPJ5RLiXPhb8F4 CBLdzy/aZwAExw2aRieYMY20HPfSUEIgKHhmM1yIVNZRiVPGmaPY1y5WTVTxDu8cUyAm IA+kvUMhH141ALsYBrwkECTuMeLUhSOesDw6LwXNEQi97Ev4DEQLttaZ3ZGHCCy4QaM0 02BzZw4LELg/lZKMo8gQyIaTmpLZDU1gzcx6vzD2ZVplYi03FwkqenKnj/K5Lk55WCSA FIz47y2/BfaFXzYMd84jwmS0bGS/OXxkZdwXXDIrpDKbvX7YxxMhFp9XmbUKYu50RHTA JXdg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; spf=pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) smtp.mailfrom=pithosian@i2pmail.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1746692226; x=1747297026; 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:date:message-id:mime-version:references :in-reply-to:subject:cc:to:from:sender:from:to:cc:subject:date :message-id:reply-to; bh=7FsVN33aXNYwFRjRndyWYmPI4eCTS9SiovrV3PvbMp4=; b=vxULlkI3ukytUJkjY/Ufp7xNK6ymIvzlT3zeW4GXOZVrcgawlcEBazFNPBiNUkHV2R qADvxcW173lSIk6HMUDxF+nXEGYIBKQKburZdKAXaH5RYdd8h0exhUR8G5a1QBuiVSlb vspPly1nDow5ylVDlxua6ImUTg3wmCA9uOPm7/xRicPvji9S6viG/sew3U3yyBs5nShY 6hHkU7foNWfUL8v3YHZ92h4FXQJOaV7r0pE0tm9dz0zOFWm6/yxemVhsNSRA+VRv8K+/ czmeOHx0TDnug4zwNA5PtfGbUEIRpImjfgSwseXoXJMBgzvPyDZLSC+vBEhLRDAZSbPc XRvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746692226; x=1747297026; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:date:message-id:mime-version:references :in-reply-to:subject:cc:to:from:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=7FsVN33aXNYwFRjRndyWYmPI4eCTS9SiovrV3PvbMp4=; b=j1FqUUS2Y8YbeHEUAavJcqqoRP4I3EkcxA0WKZ4tYOvTBFY3XboSziUKiZnTPo54gP vtqFFbYQzps95gdD5eM4uCE7BddD605t2n4U0KDowqU+MBoTddGcu5e7K713vWHoPJI/ BYNNa2tcmakIwpbJbiHDwTQmIp3Ix+Dpe4DAeR2WAvECzCS4lB2nZj6rVeydE1R3P9HE W0PHglw1L0BOMdVZbCbbbajmpqA9mirXiprf3vVRPhvIo1z3QezIlSlqRThTDd5B+MB3 qRvCvNMLeL3wSyraLMbTS4b8erjSQGnz7gnD55W6toV8dyLDWbvvPuDFbSxqfeP7k2zC +/+Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXUo0dohNgDQAXXU+sW3bvvwN5Y2wTjR5c1grpjAKRn/6qL9OzHV+xW4yOR5GROqc5hiXF8GWt3B1yh@gnusha.org X-Gm-Message-State: AOJu0YxqaVsWd0hlcppL7Ul01U1269fOsvxL5Eg3FL/pfMs36xR4D0x0 jywJL8SB+mO0RSepQwClZWz13FHL9w44g5mm6xhZKKJuTq9sp+XG X-Google-Smtp-Source: AGHT+IE9+CGLxPS3X0Mbct6tI9sBOUswoigHbnuba/P/PD7OQ7A2BBtq4W7iBpJFNNHR1NUMFpHL3A== X-Received: by 2002:a05:6820:3108:b0:600:5673:69ef with SMTP id 006d021491bc7-608333af26amr1732489eaf.1.1746692226421; Thu, 08 May 2025 01:17:06 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBHNXKAMksIEWc9kJQ77woYVa0xfWl0kWwf1TcVG5nb3kA== Received: by 2002:a4a:db61:0:b0:602:a14b:beba with SMTP id 006d021491bc7-60832e0e9c8ls214258eaf.0.-pod-prod-00-us; Thu, 08 May 2025 01:17:03 -0700 (PDT) X-Received: by 2002:a05:6808:2f18:b0:3f6:a851:fe85 with SMTP id 5614622812f47-403779c8baamr1760697b6e.14.1746692223348; Thu, 08 May 2025 01:17:03 -0700 (PDT) Received: by 2002:a05:600c:458a:b0:43c:fd8b:faa8 with SMTP id 5b1f17b1804b1-441d45adb72ms5e9; Wed, 7 May 2025 21:30:16 -0700 (PDT) X-Received: by 2002:a05:600c:1e24:b0:43d:745a:5a50 with SMTP id 5b1f17b1804b1-441d44c7d80mr47980425e9.19.1746678613961; Wed, 07 May 2025 21:30:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1746678613; cv=none; d=google.com; s=arc-20240605; b=eHMvu1q/1xRtM9rFKHimSpu/Yz51vYF1xY0QvwwSZ96K6y59tg79BiIcydoBp8Ikld dx1CeVApQKSiR26ZIZzSxPPG0ELTjPfgyf3++QzkfojOAI0RyLC+SLfy02Ar3utYR/Fm fvv7TLEEnWGX8KpNInezz9WI6TWPLOph8yMUJmd0doekta9oriCXtKPaoMdhqE3HA15J 8SW8XPocIIn83zhdg6MUZmQk8DkRvnHJj5v7hlstGl5Rhti3DToFYgyR/sJM7mnDtpm2 /Bivsj+/aRqtI8Yu3Eb+5x3TJnIpJuSkgcqXxnYKWl3QFS69/CHFBfOYxvp8eg0u8Fdy wOlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=date:message-id:content-transfer-encoding:mime-version:references :in-reply-to:subject:cc:to:from; bh=YwIF7fBRw8WtFdfFGrq3blH2eXgtd0ZvDU6kK9gDrfQ=; fh=1eoIOSo2S/txxE0ejC06v22yyqVju0HqmQsQrJwdf+c=; b=KpfI8IFGlG4BTNq/QTeiuU1SyP+eMGm+KQ7VHkgQ1vcJ8N0bAaTsbLCsSQQsXyAaG8 +PLgaEkFu2prgFKHeOWr7XDA3tDufF95Asw7T78VXJ2MOPjRDO83uUk6e8/b6ixsKdW6 0al75Jtw0RHl3TS0N/LVNE3FgtmjBw8uWA/Nck696THyOeJQtucghcG4dT/wqLBq3lj0 GIlA9EejQnI5FtgtvzFiCFi4UD2G/bv95axhb9qwivbmwdqo4U2ZaORCVy30eu8Em9Q1 2mQXllVIQpdni2ja+2tYtFU2MhLOqJqCrmFW4VAVgZ9IWJ5S24QlfAivr6NQj3S6pUI9 8XyQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) smtp.mailfrom=pithosian@i2pmail.org Received: from mail.i2pproject.net (mail.i2pproject.net. [91.143.83.7]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-442cd3310e5si355775e9.2.2025.05.07.21.30.13 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 May 2025 21:30:13 -0700 (PDT) Received-SPF: pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) client-ip=91.143.83.7; Received: from i2prouter.i2p.net ([81.7.8.99] helo=smtp.postman.i2p) by mail.i2pproject.net with esmtp (Exim 4.96) (envelope-from ) id 1uCstf-001J7s-18; Thu, 08 May 2025 06:30:13 +0200 X-Mailer: smtp.postman.i2p - Official I2P Mailer From: pithosian To: Greg Maxwell Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions In-Reply-To: <20250507121109.6CEA77C0AAF@smtp.postman.i2p> References: <20250502064744.92B057C0EE2@smtp.postman.i2p> <20250507012038.3EAE07C10F1@smtp.postman.i2p> <20250507121109.6CEA77C0AAF@smtp.postman.i2p> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Virus-Scanned: clamav-milter 0.103.X on milter.postman.i2p Message-Id: <20250507165518.0B5037C0EEB@smtp.postman.i2p> Date: Wed, 7 May 2025 16:55:18 +0000 (UTC) X-Spam-Score: -2.9 (--) X-Original-Sender: pithosian@i2pmail.org X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) smtp.mailfrom=pithosian@i2pmail.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.9 (/) On Wed, 7 May 2025 12:11:09 +0000 (UTC) Greg Maxwell wrote: > That creates a withholding attack where you announce a block then > withhold some transactions entirely. > > It does already relay to other full nodes before validating > everything, but the nodes need to have the data. > > Of course the recipient's mining is also still delayed until > validation so even if not for the withholding issue it would only > reduce the hop by hop component. (As the recipient would presumably > not have the transaction either with its relay blocked in the network > and the transaction submitted directly to the party that included.) > > There are, of course, numerous optimizations that could be done to > reduce the impact... but none so effective as actually having the > transaction and even having already validated it, and all with > considerable development effort. > That creates a withholding attack where you announce a block then > withhold some transactions entirely. A miner can already do this to all of their direct peers. The only difference is whether it gets passed along. What's the functional difference between this, and a miner delaying broadcast of a block entirely, besides the fact withholding transactions is network-visible? > It does already relay to other full nodes before validating > everything, but the nodes need to have the data. It relays once it has all of the transactions, and has done preliminary validation up to BLOCK_VALID_TRANSACTIONS. To finish validating the block, nodes of course will need to have all the transactions. But relay of the compact block doesn't need to be slowed down by nodes who don't have all transactions yet. Minimal validation (POW, header, merkleroot) should be sufficient for relay. > Of course the recipient's mining is also still delayed until > validation so even if not for the withholding issue it would only > reduce the hop by hop component. Which is the block propagation part. Right now, your miner won't receive the compact block until every node along whichever path reaches them first has all the transactions locally. Every node who was missing some of those transactions will slow down propagation. The miner could already have all the transactions locally, and still, they could be delayed. If they don't, it takes longer for them to even know that they're missing transactions. If we relay compact blocks before we have all the transactions locally, the miner gets the compact block without any missing TX delay. If they already have all transactions, they can finish validation and get to work no questions asked. If they don't, the only delay in building on the new block is because transactions were missing *from their own mempool*. Whether miners choose to start mining an empty block on top of this new block, which they haven't yet fully validated, or continue with existing work until validation completes is up to them. A decision they already have to make. > As the recipient would presumably not have the transaction either > with its relay blocked in the network and the transaction submitted > directly to the party that included. As full-RBF demonstrated, transaction relay doesn't require every node to have the same mempool policy. A small percentage of nodes running permissive policy can get transactions to miners. You don't need to try to force people to all use the same relay policy. Never mind that it's impossible. The transaction can, and will be able to reach miners via mempool relay by simply giving users more control over their own node's policy, and lobbying enough of them to choose more permissive relay policy. -- 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 visit https://groups.google.com/d/msgid/bitcoindev/20250507165518.0B5037C0EEB%40smtp.postman.i2p.