From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 02 May 2025 08:28:45 -0700 Received: from mail-qt1-f184.google.com ([209.85.160.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uAsJe-0006kf-Jz for bitcoindev@gnusha.org; Fri, 02 May 2025 08:28:44 -0700 Received: by mail-qt1-f184.google.com with SMTP id d75a77b69052e-4768488f4d7sf34809461cf.0 for ; Fri, 02 May 2025 08:28:42 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1746199717; cv=pass; d=google.com; s=arc-20240605; b=VeGrwgrGRk7ZNQJpo2bFZCLrzVyA+1NFf+R1CK2RMjmQpXPHZQV9sCVbZ0BJ6ZmtZO ZmV1fNk6X/ASgO4owJNn/uQcetgQuWxHPRQBuT0kfVpGU3FE5XtaoWOdqrdNigsVdCt4 lcCmcO/FcyLz3gH1msDmGltzyYkI+6z4KwlsaP5efPhQQpu1PTLXACXaUuCPhontyT/m gF4gghzOT2QCvFKESpc9AvMN3vZHcWnvyhFHlUGF7iTdgczwdNCtEN8FE5R1J6+9VU+G LrW2w9OQmY1hqJL/0TR2cZjogX7kRpyDNercC4NSLpLVTfB4HPqjcAAczpOI9RWkx1aq O30A== ARC-Message-Signature: i=3; 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:mime-version:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:to:from:sender:dkim-signature; bh=QoDsleXVfM5GWcUMEd0QmkMUQsw5LiV020pRa5hxjOE=; fh=0mqB+DUvvX4eyhRB/SoFdLb0pMgjYnBioMkKkH/WLek=; b=YTNIAiuZCcD99yY9R3yod46PzvHanEoZY60QGnYpEvDozHC2W2rT9ZwGhoSxf/FVy5 5CPDD7TxqtsvuOWQcCsNE+w5Y1t5nYVP5VMlMVmJmGre+gAAX810zlA46xEn6C7KV/ah ORdRoVxArqdc0vR9owZMXTcOJbRk+NxAd0FDVSenJVEcc8NEmuihHZ/d2NCrhuJOXrXc G8MhitHTvm+NpPoJU2Nua+v3o9pDRapOW8GRSiMh2IQOlMUiP/1CiNHJ/He4McN9dQD7 pYTgb5Fne2y7jr+hkAY7TesoitL4pJn/c8I1i2/wwg2E+oKznJwb03Cme9O79/3TOkA0 bNFQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@barefootmining.com header.s=selector1 header.b=gnnDZjNT; arc=pass (i=1 spf=pass spfdomain=barefootmining.com dkim=pass dkdomain=barefootmining.com dmarc=pass fromdomain=barefootmining.com); spf=pass (google.com: domain of bob.burnett@barefootmining.com designates 2a01:111:f403:c105::5 as permitted sender) smtp.mailfrom=bob.burnett@barefootmining.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1746199717; x=1746804517; 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:mime-version:content-language:accept-language :in-reply-to:references:message-id:date:thread-index:thread-topic :subject:to:from:sender:from:to:cc:subject:date:message-id:reply-to; bh=QoDsleXVfM5GWcUMEd0QmkMUQsw5LiV020pRa5hxjOE=; b=T5GqjHO6L0z27vMA/C9BF120UFp5eXc2xUWizkQ8imSKt1NdXGZBeDWuS1WLb/CE2w IeilcMoboe29F2YdZGG8YhRFk9l/OM9CWhAyoP/ikxlJVA0UwGochH8yRvV8IQsGM57Q rA4U/6yHulZOf6jeuzC73DNBNWCZ0pAIGCNNtPRcSj9Tz2FiV4KfgmQ0idsRPHbxxZJT x/0FqzfaeNnoFfSE7aiOVv1TySj+wh+fl+A0863OUeJbrm6VJHeH7LuemwJMbTEC97bV JX3q4VllikfD+H2mKP/jcS4RyQSZDI7ghagIgnj5mujf/CeaoM9dKnfvqhQN8G2ATzLN JhGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746199717; x=1746804517; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:content-language:accept-language :in-reply-to:references:message-id:date:thread-index:thread-topic :subject:to:from:x-beenthere:x-gm-message-state:sender:from:to:cc :subject:date:message-id:reply-to; bh=QoDsleXVfM5GWcUMEd0QmkMUQsw5LiV020pRa5hxjOE=; b=YYOxxBsW21li0wnrylMneAqgydmek/bRWcOi7z3/lzG75B+xWxODjiVVDvaFQPb+Sc mamyBp0nLE9QS03eNUw8X4ryvUgjt5sGyyQl+dnaEVYiP0A/Itz1PVD9RMuCNIWx9U3w 2YJQjc8AXMFuVyJfcl33UMuJi5u4li2FZYX/eCbCw1dS3u+GIQTVXqNNQynr06eQn1QH dezc3n1VlBN2tbazgFdzYexrORjaue/lHcnognt3T1521Tbj2VXOQtasg+fwYVqSI84S ZUs7MTcG+ltVyV+E/Dliv0owHaQ6N9o/fh7pQbFEfiylX9sD7vkh+jS3rONFSD3BCsOL bFOQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCX165BACioZMEHlOa2nDIrmLwQ1CDIJOYBbB7/VHZVx4iUocDdqm0SATezzXXoocnnfYdv/jIzhecIO@gnusha.org X-Gm-Message-State: AOJu0YxxVf/DL7ULahi6BdOkaj3tWZG0sJgJlbjPw8OTRDDDOWIcac63 vbsS/NTfdehcTnMSsNWMOFaHNK23u7tcV56Iuf6TGJrkSQ1Z/PWY X-Google-Smtp-Source: AGHT+IGXaOphkIK1kzOty0sODGViu4fbvkcQR1kxjjDk+TSLwWF9JpwmQeMDzliwl2I81RTW9I4JPA== X-Received: by 2002:a05:622a:2b0f:b0:476:80ce:a614 with SMTP id d75a77b69052e-48c31354958mr55315661cf.19.1746199716330; Fri, 02 May 2025 08:28:36 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBEyti/VEnjGOUZPl21D5i+RYPBnIOY4PEpdKI4VlToOHg== Received: by 2002:ac8:7081:0:b0:48a:cfb5:ede6 with SMTP id d75a77b69052e-48ad89b1403ls7642781cf.1.-pod-prod-01-us; Fri, 02 May 2025 08:28:33 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXzbt8MCcWEL9TEsWtvJBrLl9Id35/CHzSKm4Xn5+YP094TSrm0awG7oZVWhXI05C+i8VCTdn9HMJ5s@googlegroups.com X-Received: by 2002:a05:620a:2410:b0:7c5:3b3b:c9da with SMTP id af79cd13be357-7cad5b8dbd0mr510651085a.40.1746199712997; Fri, 02 May 2025 08:28:32 -0700 (PDT) Received: by 2002:a05:620a:6221:b0:7c5:495f:5415 with SMTP id af79cd13be357-7cad5c98378ms85a; Fri, 2 May 2025 06:58:49 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWTpUHybPomzZ8Q48HGWM19L3Ydx62S+oOBc+xaEJx/9Vb09iKXmq+OAq5vfH6kE0tQfoGs5Xdq6TE5@googlegroups.com X-Received: by 2002:a05:620a:4316:b0:7c5:94e0:cafb with SMTP id af79cd13be357-7cad5ba38efmr439176485a.48.1746194328403; Fri, 02 May 2025 06:58:48 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1746194328; cv=pass; d=google.com; s=arc-20240605; b=Xt7PMqnKd018AC6y5txSy5USEtOPd0klYpnfh4cAcG5dCZVC2wSEIIqgnOg3tlFw5l rDSMEAT+5buDoJqy4HJOSdLgdd2Nk30gahUMcpKQFVLzPlqJReNTt8QggCog8or3E0PP vlafeoaWbFLYxJDRopJ1J0B7c0p58M5r0zr62uY2FsmsVgJErRAst6VqXHGEKJ3cGm05 uTzXrSN4pzNihtqjfQpvvSONm6OAQ7MVHKidYYMS0r6lFygoeE2oaFu7MQJZgu9Ok4+I 2vSnQjNo9A2we8gDXrQ7izu+MTEkiM2VLecJYYLTJwuLepOEUaqoyae6TzHbFu4IREzb yPgg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:content-language:accept-language:in-reply-to :references:message-id:date:thread-index:thread-topic:subject:to :from:dkim-signature; bh=QjG9ZJsgh7lZ6ZWm2vYpBAZKETAY2Tgn246AYbf/KXc=; fh=lEuO5GbZgvTXUGZuzIYKSN9ppxQ0NxM7JIDWfwkz6Wc=; b=NWASWa68thpQQgHygNOU3haEX/LG5JaOUyS5UdSK573KTIUmzHBNNKWQaaCR4FsUUm SKi4o64xuB+2kuSTlw4L/2YC4wbIU4FnSV0nzWE+qOoHxtoYINLLY2of4UaWaKmuxUbI rdsYFEsMMJPtio/3KZw4emylpJj/FZA7KbZLyKS/aELWSDBUg3G4X3+yfR4JsquRonPu ifNxVNi3YDZz8dpPdKs+zd3u4U8Fs3V/OQINRojWGPXgb7pUxGvnClfsmnT6KG9f0lgn jfmsIEqELDetALtrHsA0rIXXWIfkHwEteTPZe9yg6tiP4RubZn+i6ztgPq5qQbmCoDAb QyiA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@barefootmining.com header.s=selector1 header.b=gnnDZjNT; arc=pass (i=1 spf=pass spfdomain=barefootmining.com dkim=pass dkdomain=barefootmining.com dmarc=pass fromdomain=barefootmining.com); spf=pass (google.com: domain of bob.burnett@barefootmining.com designates 2a01:111:f403:c105::5 as permitted sender) smtp.mailfrom=bob.burnett@barefootmining.com Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com. [2a01:111:f403:c105::5]) by gmr-mx.google.com with ESMTPS id af79cd13be357-7cad23b8476si10517185a.2.2025.05.02.06.58.48 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 May 2025 06:58:48 -0700 (PDT) Received-SPF: pass (google.com: domain of bob.burnett@barefootmining.com designates 2a01:111:f403:c105::5 as permitted sender) client-ip=2a01:111:f403:c105::5; ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kVgzNJCNT/F9uqO4G6FRpdLRtZ7sgcxaGhKRoLbWr1sawtyxHOWk4qDZRveh4LZa1WLzpfchxj9g9s1s0v+6hylvgpqbeCxnL0Jjw8qi6EMg9/ruhktOrZXM4bHuhZqakwkrGflQc0xloZYJ2uMZImHjYu30Y0U/73GuZysLBOM1au1tw44sh3rFPBanzNiCvY0F0tSCr7GlTuGVAYJwMiGhtvTA15QqLArQbqg3XJv2LhHlF+MJmtbEJ3nYpU4nNBFeAR0d5voEZ+7UXh4VG0S8CxOLHRLiymp2+xlhybtZlo2VDlWr0hxsOatRGPAhnKOmZHhtU2cL42+A4spBTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QjG9ZJsgh7lZ6ZWm2vYpBAZKETAY2Tgn246AYbf/KXc=; b=IJ3GTX+W9cXG2Qa0Pqiw2Wjpbupojc4BL8LrYotrjLEeQgwpBUVgvYTCF+fKB95UqgVv3rNNw9stQAqljNxyaykRmS3ojPjSAM/5fRrfO77oqOo2F2SD7Q8XvP+pBKC0RooYvsUUUY4PPnYMFYWeXLXD4vUr6QEiwBGoZrIZghERte3YEBswOcnkPlpKKwqU6F0dduMQ9DVCRNl/m8Q0vSdlXXtxjUVXgGIZ3j2SxkSuZcv/7dRUn01LTcvl6rALtgoV3wKLafMxw1Av8mweC4aIiEYERLRz4nzDniEjtYn18UXeR6U8d0WCrJywNGJDp274WktNgHX2CYuqwfzREQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=barefootmining.com; dmarc=pass action=none header.from=barefootmining.com; dkim=pass header.d=barefootmining.com; arc=none Received: from BY5PR03MB5171.namprd03.prod.outlook.com (2603:10b6:a03:220::13) by IA3PR03MB7547.namprd03.prod.outlook.com (2603:10b6:208:507::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8699.21; Fri, 2 May 2025 13:58:44 +0000 Received: from BY5PR03MB5171.namprd03.prod.outlook.com ([fe80::3749:df95:28d3:fff1]) by BY5PR03MB5171.namprd03.prod.outlook.com ([fe80::3749:df95:28d3:fff1%5]) with mapi id 15.20.8699.022; Fri, 2 May 2025 13:58:44 +0000 From: Bob Burnett To: PandaCute , Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions Thread-Topic: [bitcoindev] Re: Relax OP_RETURN standardness restrictions Thread-Index: AQHbuursmPNU3pealkaRMeOMGA+O4rO+eJKAgADRjso= Date: Fri, 2 May 2025 13:58:44 +0000 Message-ID: References: <68cdce0e-9030-4a6b-92a4-d48d05be3e80n@googlegroups.com> In-Reply-To: <68cdce0e-9030-4a6b-92a4-d48d05be3e80n@googlegroups.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-reactions: allow x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BY5PR03MB5171:EE_|IA3PR03MB7547:EE_ x-ms-office365-filtering-correlation-id: 30e18df8-3402-4934-22fd-08dd898173c2 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|4022899009|366016|1800799024|13003099007|8096899003|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?a1hpejdpYVVZTmJyVWpsQnNjMTZrQnczcmZIWEQzZGRvWG9uZU95TGlwVXgy?= =?utf-8?B?bS9CMGxTcFpqUmZxMTdSbUQvMkxpSG9rYUthZmhpbG5JbG4vUzNYYWxRaWRP?= =?utf-8?B?LzFYQmd2ZytadjNkMCtZa1hZcERYUGZZSzhRK1ZEK2pOT3B6bTFvZ2s2eVZS?= =?utf-8?B?R2lwRG1Md0ZmR0hLZUlmSVFrWjBQczV5TncySk04MjluUEh6cnFRUllnSDZo?= =?utf-8?B?V2pBc1FHWTVaUHFjS3Myb3U5RFkvdWgwUWY5RWY3NlRnK2p0dEZ6T2o4cXg0?= =?utf-8?B?U21NS1BCR00ydkNpNWZ3TUExckFCMExYR2lGeVZsMTlZSjB2aGU5c01mSElD?= =?utf-8?B?NDZZTTdrcnVHcnFmRW50MCtFRU1tZnFFbWt6YWtjMDVDNTZobzZOOC8rU0F6?= =?utf-8?B?NGtLY08yV0xVNlRldFRDK1VlTUtMUllnVGFlQmMzVU9xK2x3elB0eW5ISlU5?= =?utf-8?B?NGszVlBEZjgzSHFveEVrdG1sWHg5K0huMzRobjB1NDhaS2g3ajZLdHZoT3l6?= =?utf-8?B?ZXhtd053UGFhd1grRzBYcHFYMWYyTzlMS2hsTks0TUhFT1Z6djZtQTI4YndJ?= =?utf-8?B?NHRBZ3g0a0crOUNVMlpwbjNYdHRGZnVzSGMwL3lEYVBhbFlldVVZNFpvaytC?= =?utf-8?B?dUtlUG1mWTJSVmlmTkd2b1Vjc28wZFN3NFIrWi9WOUZSRWxESG5vbUxQdGpV?= =?utf-8?B?MTZ0TXB2NnI5Vi9jU0VSS3MxN1ZmZjVLMmpZZEJKUjF5SmEvRXh2NEpzQlFx?= =?utf-8?B?dHhWbFRMS0lodDE5ekhjY3FiNlpxZVpWcEFkN0hYTStsMTZFOXJHMXFKWU5Y?= =?utf-8?B?ckQ0Qy9LeUEzVndUN3F3TG5WV1I1dGl3MTB5WU5RSW9seUxIRUxUMWtYUmps?= =?utf-8?B?a1BOTEdLb1pSTm1FbERhU1EybnE1bVkwSE1iUFlxaHhzdTh2bk13ZmR2SFQ5?= =?utf-8?B?OG9mcmd4UzZuRjljY2MrYVZmT2hOMGZiUmFDR0NSdVh5cWVDbTY2T2FLQnJX?= =?utf-8?B?NlcxMFMxWFdMMmVoeHRzTjg3V29jSW5lWkpDZDA1RUg4VzhKM09xYXZ1MDB4?= =?utf-8?B?dUxGYVdWVFJaRTNScVFSVFdMMk4rcjB6VFZKZkljZ0lEVS92cWlXWC90ZFB1?= =?utf-8?B?TkQzZnFYRTNneThkUTJ2SlY3QXA1anhXalpvc1FhZW5WMHNFRDNQdDFmYnZ2?= =?utf-8?B?Yittd3duRDFldlc2RHJkek5QMWNGTEhTYVdhaExoYjd6SnFwWGl6UlNDNy9s?= =?utf-8?B?akd5NGNuRm1GU0hvUmVyazdRMUlDMXF2TS9pTjhrQUtpeVVSakJ1aUJQZi9M?= =?utf-8?B?cWpPckh5cDQ1OU9yZnQ3V2I0TTFlQWljSG5jMDA1V3ZFbDFDYVM5bVN1eERk?= =?utf-8?B?SllLQjhaZnk0aFRpeFJHd05xMWF3QzFJNExUTXdwaEVYTGpxMHIxY2k1OHdn?= =?utf-8?B?YjVXUzdKODJ1bW9JS1EvUTB0MGZhSGtOSFdJTlczdXRUVFJ3RmhPM0JHaFhM?= =?utf-8?B?cW5VYmMwamFZclVwZDBlMlJuVWtrMFRUdW1XbzVORFNOL012QkJoVGxkSnF0?= =?utf-8?B?M0J1WkVLbjZjbC81NWdUenNZdnJ5YTAvRXVmWnpncWVzTCtRSmJieVlRMHox?= =?utf-8?B?VUFVNjYxTlBFVDNhdkZZUlpjMHpuQjd2ZVNNR0xMYjNMQ3BtLzFqYzZIUHFu?= =?utf-8?B?NWZSL2I0MEJmV2x2T0plM2VWbnAzaUYybmYvTDlLT1JQUzVLSzBIc3Q2b3lB?= =?utf-8?B?NUphd0JpZ2ZySUlENWVNRFN6ZHNKb2laNEdRT3c1Q0V1K2hzQStQTVlWTFNj?= =?utf-8?B?eDlxVm5rSk5lRFBrbExlWnozeHBlc091MEYrV1BMSDh3S25kMkoxN1ZCNmt6?= =?utf-8?B?cVd2VVhMUVIyN1NDd3B0ajcyNnRudmE5R242RTRSK2drL3U0ODVnYUl6QUdF?= =?utf-8?Q?G608TdiWOGQ=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR03MB5171.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(4022899009)(366016)(1800799024)(13003099007)(8096899003)(38070700018);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cWM3TURFY2IvOGVuV2puT2pVZTc2UnBWbHA3UWUvREtiUjF2UHcwb282V0dL?= =?utf-8?B?YjJWMVBpTk5RRC9UMWtWRFg5UGFNbWJiSndTTEZoM3ZmcWkyZmxlSmI4YmFD?= =?utf-8?B?em9TbEhUR0M0OUkrMldic05LcVBHbWhsVzl1UXRMeHNZWWtPbUtFMmViZEF3?= =?utf-8?B?Y2NXTGFvVEsyQ2hZejhMRTU1a2pCd2l0YkhYcDBJQ1YvTldXejM1a2gvcmxh?= =?utf-8?B?bDB6aGExdnZqYy9hcktuSkNXRFZKekMxdHdsSkE3UkdZYTc0SHVUKzdQMURI?= =?utf-8?B?SENjSWdDVFhPNFZsWU1FZEpCb0RUc1ZnOE0yakdHaE8ySVRNMmRHTWg4ZFZU?= =?utf-8?B?Tit5TW8wL3RPNXRYOWZWK0NHUml4ZnFKbEdSR052bWUrQXhtdTJoeTgvMktR?= =?utf-8?B?WGZadUErNWlMdHRCZUhiR1hDMjhzL0JqRXFLNUp6VHNnVjZiN29xbHJCZkds?= =?utf-8?B?STVMUWJhSTRvcnM0RDJzNDlwVnhRN1phU2hxRGNjK3JseVduU1BIazAwaUNx?= =?utf-8?B?clJSWHRIdk90VERRRm5WNGhqWVRhUEc4bklsdWE5eGtnczdDemFoWHZGd0li?= =?utf-8?B?VUlacGh0bjcrWllzYURzSmlrZUlhcjUydEZ0UWlLR3o1eHgzK0dTN1pTM2Vx?= =?utf-8?B?OUJUaGJzLzM5ZE92NUtsQkhhTUlNRW9XNnZBTklPalhRUFNteDY4elRqTWNs?= =?utf-8?B?UWp1ZzltUWpJU2o3MmpDK0FRV3JGY0M5aFpMeFRYV200b0Zta3VCaHZNVFhX?= =?utf-8?B?cDJ4VXVyM1lrdzVaVEZnZVJ3elZuVDNxMVcwM0FaaEZBUjVZVWlVREJiNnNw?= =?utf-8?B?VGRITExaUHAwNytYU0Z2bmJHcDNJR0N1eUUxb2FLQldGQTY3ME16ZHRwamZ4?= =?utf-8?B?WlB0a0c2bnNZT0hpdWJyQlllczJLUVI4SnF6NTdtYkYzN2QyQXNUZU9zTE85?= =?utf-8?B?UFdGaGJpZkdERy9GWDIyT2hyN1M3NUVLak0wVDN1Z2xvcVAwdzRiL3dTWmRj?= =?utf-8?B?UmZvQjVjZS9jbHUvVi83cHppM1F1NGNQNnNobFNFTW92dmU2UXZJWUNzMEMw?= =?utf-8?B?RmJBb0xBMXlFM0J0Sis1QkRvd3k4Ukc1b3BHemVTTmFiMUxuRDBVY0FsUFpq?= =?utf-8?B?WklEN0xLbCtlZzdQODNhaDFlRUllUjVQME50Rm9GSis2N3JjMjg5N3ZUM1lv?= =?utf-8?B?MS95MnczbFZVbytRWFd6L2tPWkJjb2F6Z1V5R0ppUFUvclpxNXhITjJ2cTRX?= =?utf-8?B?cTZJUDdPaGFyempyVllTRzRlRndmK0hjK1crTndOREYrZTJSZmlLaDJtd0dx?= =?utf-8?B?YUVKTnNobnpUQkhSYnNNM2FVcDlWRUZwL1JpYStpS29UR3grQnpjMXFBaTgx?= =?utf-8?B?cE0rZWs1NEZ3RURhbjZ4amJRSzVEd1JlcVdGaCtvN0hUQ1E4YjBNaTlaV29G?= =?utf-8?B?V3lwYUNyWjlJWWcwNGcwT0MyNEQ3TzZSQ1NudjFrd0xtUFFGRWR5K3hQYkZk?= =?utf-8?B?V0wzVGp0UjJxd0VhTkIwekNBL09UV3JqR3F5VVVFZ0NoY1VVbTFDSlRmeVRr?= =?utf-8?B?TjVNWUVxY3VybjJ5YWJnNW9Hb3VSNEJGaWFEckZ5aXYrTFExUW9nM1BRNUZT?= =?utf-8?B?SHdBemdsbk5ObjU1Qkc4bWNkNCtNRXBvV1N4NWNqN3JlWlZzS2tvdkJuWktS?= =?utf-8?B?V0xIUFdaUmhxZGxjdGt1WlR1R1k1SXlhZXpFQ2NWT3FiVUQweGxCcjJBSWs3?= =?utf-8?B?Yk1NVFZ4YUZlTEtFd0Zrck90ZDNucXNhaUFTMzZSekN2RnR1M2djSmkyOGNS?= =?utf-8?B?QXk5Mk9YZDdoZFVDbjQ5V1JKSkR0QU13ditHSml2WWV6eUNNUThiZXNyRTJI?= =?utf-8?B?QzloTVJQNG11NmsrQW9tQitrV1dQbDY2VDEyTFNiZmFIZGFVQ3c4SXQ5UTAr?= =?utf-8?B?Uk1hWmZxd2hPRGk4b29jSkpJY05ucHdHNnBWUVVIcGlZa21OMTNNbXgrTDZp?= =?utf-8?B?N2M5UjlhbDNFd1BiSWIraXpLV0lUVlBMQ05hbU40WTRxc3ErZWF4akYva3hI?= =?utf-8?B?UXd0eGdsOGEzdnpuYlptMGk3ZStJWHdoTjVCS2lqN0tlYzN4OHRvNi9adldi?= =?utf-8?B?MGw3WXFiV1I4RVpIR1pIVHVrSlZuK1ZRS1ZteVlTUjd4OGlDUmJpWnZ6K0Jv?= =?utf-8?Q?9HySW6/orJOs2sYGva+zA24=3D?= Content-Type: multipart/alternative; boundary="_000_BY5PR03MB5171138582C249F82228689A968D2BY5PR03MB5171namp_" MIME-Version: 1.0 X-OriginatorOrg: barefootmining.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR03MB5171.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 30e18df8-3402-4934-22fd-08dd898173c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2025 13:58:44.2054 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ddddd300-8706-4e9f-911b-5396c2549018 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JpK2wtn+1Y6OayXhb3po23Nt+XEwwoAOnU6mrRr+I7KCJjwlniH6mYtbBxMHxSy7mTNM2H+34nZRU5mAV+PlspUJT/27+5KWQVvczLCMLk4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR03MB7547 X-Original-Sender: bob.burnett@barefootmining.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@barefootmining.com header.s=selector1 header.b=gnnDZjNT; arc=pass (i=1 spf=pass spfdomain=barefootmining.com dkim=pass dkdomain=barefootmining.com dmarc=pass fromdomain=barefootmining.com); spf=pass (google.com: domain of bob.burnett@barefootmining.com designates 2a01:111:f403:c105::5 as permitted sender) smtp.mailfrom=bob.burnett@barefootmining.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.0 (/) --_000_BY5PR03MB5171138582C249F82228689A968D2BY5PR03MB5171namp_ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is my first response/comment on this mailing list. I think there are = several issues that have risen to the surface here including this one on a = broken communication link (well written message btw). 1. Those outside of the dev community are perplexed by the process and f= eeling discounted, unheard, and/or rejected. Most of the issues/PRs/BIPs t= hat the dev community deals with are beyond the ability of the general popu= lation to understand, but occasionally there are ones that they grasp (at l= east somewhat) and for which they have opinion. I=E2=80=99ve certainly lea= rned that when someone has an opinion it is really important to let them ex= press it, otherwise, the pressure inside them builds and they erupt like a = volcano. The Bitcoin ecosystem and its members are radically different tod= ay than 5-10 years ago =E2=80=93 it is bigger, wider, and has broader inter= ests now - it appears that process and communication mechanisms currently u= sed by Core are not capable of reaching the community properly anymore. Not= e that communication means two-way as well. When someone buys Bitcoin or starts working within the ecosystem, there is = no membership guide, owner=E2=80=99s manual, or employee on-boarding proces= s. It comes off very badly when someone trying to engage is told that they= don=E2=80=99t count or aren=E2=80=99t using proper channels, especially wh= en they don=E2=80=99t even know where to go learn the rules of engagement. = That isn=E2=80=99t necessarily anyone=E2=80=99s fault, but I=E2=80=99ve be= en involved in Bitcoin since 2017 and even now am still learning new things= about the engagement process, and there definitely have been several surpr= ises and frustrations for me over the past handful of days. 1. The ecosystem is much more complex than ever before with people and c= ompanies developing products and services with assumptions of how Bitcoin w= ill operate. Many of these are being done in stealth-mode as well. Some p= eople are pouring their heart and soul (and money) into their projects and = the expectation of a standard is often crucial. I am one of these folks, b= eyond what I do in mining (CEO of Barefoot Mining) and as a board member at= Ocean, I have been working for two years on a project related to enhancing= block space access. This proposed change in standardness may impact my pr= oject in a negative manner, and, it is certainly possible others might be i= n a similar position. Regardless, changes to standardness are HUGE. I spe= nt most of my career within the Personal Computer space and learned the har= d way that changes to a standards are a dangerous game. I expand a bit on= this in this X post:: https://x.com/boomer_btc/status/1917687830148526095 2. The proposed change also appears to be reduction in flexibility and c= onfigurability. In general, this is never a good thing. IMO, we should be= going in the direction of giving people more choices and flexibility (alth= ough it is fine to make suggestions, set defaults, or provide general guide= lines.) How someone configures their node and creates their mempool is aki= n to free speech within Bitcoin. The same goes for those like me that are m= iners and create our own block templates =E2=80=93 this is also part of our= free speech (and our business). In the end though, whether you are a user= or a miner, the more choices you have, the more freedom of speech you have= . Side note: Ultimately, as a miner I am in the business of creating block sp= ace =E2=80=93 at least that is my view, and contrary to popular belief, min= ers are not always motivated to simply pick transactions that generate the = highest block reward in the immediate block, and as time goes by this will = become even more common and apparent. I=E2=80=99ve spoken a lot on this re= cently in public forums, so I won=E2=80=99t dwell on it here. 1. Finally, there is the issue of an OP_RETURN change, if it encourages = more spam, and if we are just caving into an inevitability. I am against t= he proposed change and, even if that is true that the spam will ultimately = find a way, I feel we are acquiescing way too early. Enough has been said = on this topic in other forums so I won=E2=80=99t go further. From: bitcoindev@googlegroups.com on behalf o= f PandaCute Date: Friday, May 2, 2025 at 7:11=E2=80=AFAM To: Bitcoin Development Mailing List Subject: [bitcoindev] Re: Relax OP_RETURN standardness restrictions You don't often get email from pandacute12345678@gmail.com. Learn why this = is important I think this debate is missing one important part: a communication link bet= ween the developers and the users. The developers are speaking with the dev= elopers, the users are speaking with the users, and no one is really trying= to understand where the other side is coming from. It's been a lot of aggr= essive, unproductive back-and-forth, with both sides accusing each other of= bad intentions and completely dismissing each other's points. This is a technical mailing list aimed at devs, so I'll try to summarize wh= at I've seen in normal_users_land, and the general feeling out there right = now. Obviously, I'm not trying to suggest that users *feelings* should be d= ictate the technical direction of Bitcoin. However, it is important that th= ere is mutual respect and trust between users and devs. Right now, trust is pretty broken. It can be regained, but not without unde= rstanding what went wrong in the first place. I saw on IRC some devs suggesting they spend time on podcasts and social me= dia to explain the motivations behind this proposal *before* merging it, in= stead of merging now and hoping people just accept it. I think that=E2=80= =99s a fantastic idea, and the way to go. I particularly liked jonatack's m= essage - =E2=80=9Cif Core shows humility and patience, it would surprise pe= ople and improve things.=E2=80=9D Now, about the proposal itself and what it *feels* like: It=E2=80=99s a big= change that came out of nowhere, especially at a time when spam doesn=E2= =80=99t seem like a big issue. It=E2=80=99s a bit=E2=80=A6 shocking? Normal= ly Bitcoin changes are discussed for ages, PRs take so long to get merged, = because of all the care that devs put into considering the pros and the con= s, but here? We get a mailing list post (that no user is reading, let=E2=80= =99s be honest) and a PR with a lot of contributors saying =E2=80=9Cyeah, l= et=E2=80=99s do this!=E2=80=9D. There should be a bit more research. (Maybe= there was, but behind closed doors?). We want to know about all the protoc= ols that are bloating the UTXO set and that could be using OP_RETURN instea= d. We want to know how many transactions like these are in each block, and = how many there will be once the new protocols start getting deployed. We wa= nt to see that you did your homework for weeks before trying to change the = policies. It feels weird=E2=80=94like some sort of attack or a bribe. One protocol is= mentioned that would benefit from this change, and then an investor ACKs t= he PR. Someone points out a potential conflict of interest, and their comme= nt gets hidden. That=E2=80=99s shady, no denying it. And then, it feels that users have no say. It's a ""technocracy"", where de= vs have all the power in their hands and can decide where the protocol goes= , while completely dismissing users' concerns. Users do have concerns=E2=80=94lots of them. And I encourage devs to step o= ut and talk to "regular" Bitcoin users. It=E2=80=99s not just a =E2=80=9Clo= ud minority=E2=80=9D=E2=80=94there are many people genuinely worried: =E2= =80=9CCan we trust Core devs anymore? Is there even another option?=E2=80= =9D. But their concerns are dismissed, their comments deleted or hidden, th= ey're treated like "bullies" that devs should ignore, devs should "merge To= dd's PR and call it a day". Without understanding all the technical details, I'd say there's a pretty g= ood chance that the very smart people that work on Core are right once agai= n. Statistically, it's very likely. Communicate to users, explain your moti= vations, and show that you want to listen to our concerns. Lastly, as irritating as that might be, users freaking out and holding core= developers accountable and flooding Github is a feature, not a bug. Devs a= ren't the Bitcoin gods, they are humans, and humans can be bribed, can be = coerced, can have conflict of interest, can fck up. Users care and want to protect Bitcoin. Be grateful. Respectfully, A Bitcoin Dev On Friday, May 2, 2025 at 12:46:20=E2=80=AFAM UTC+2 Antoine Poinsot wrote: As i have repeatedly asked people to take conceptual discussions to the mai= ling list, i am circling back to this thread to answer objections. I have a= lso written my point of view and reasons for proposing this change in a blo= g post which goes into more details: https://antoinep.com/posts/relay_polic= y_drama. Going through the emails in order. Am I the only one left on this list who actually cares about Bitcoin's surv= ival? Thanks Luke for your measured take. It's refreshing to see we have adults o= n both sides of this "debate". With that history in mind, removing limits on OP_RETURN standardness size i= s pointless. Yes, it is pointless for people who want to store massive amount of data. I= t is not for people who want to store a small amount of data in a time-sens= itive transaction's output. Because they need their transaction to be relay= ed on the p2p network, and are therefore pushed to use unspendable outputs = instead. Relaxing OP_RETURN size limits without dealing with the inscriptions This is orthogonal. The harmful behaviour described in OP is possible today= regardless of inscriptions. There's little to no incentive to use OP_RETURN for data storage when using= the 'inscriptions' exploit costs 4x less in transactions. What's the point= of having a "standard" way to store arbitrary data if the exploit method i= s 4x cheaper? And the nonstandard version of the exploit allows 4x the data= ? You have obviously not properly read or understood OP. There is no need to = speculate about what would happen or not. People are using outputs to store= data today=E2=80=8B. The only question now is harm reduction: given that p= eople are storing this data in outputs today, do we want to offer a way to = do it that does not force every single full node on the network to store th= eir data forever? That said i agree that this is not going to change anything for people who = try to store large amount of data onchain, they already have a 4x cheaper w= ay of doing so. For example, let's say I want to distribute malware. Well, might as well ju= st store it in an OP_RETURN. The point about storing data on everyone's disk was addressed by others: it= 's already possible and that's why Core XOR's the content of third-party-co= ntrolled data it writes to disk. But an interesting fact on this specific p= oint about malware and OP_RETURN outputs is how they have already been used= in the past to resiliently update the domain of a malware's C2 servers: ht= tps://news.sophos.com/wp-content/uploads/2020/06/glupteba_final-1.pdf . This is a fundamental change to the nature of what the Bitcoin network itse= lf is in its entirety. [...] Bitcoin as we know it changes forever in the m= ost fundamental way imaginable Wild emotional claims with no ground whatsoever don't convince anybody and = only hurt your credibility. and we might as well give up on Bitcoin ever being a thing if this is the p= ath chosen Well if you believe the whole system is as brittle as relying on people pla= ying nice for security, you might as well give up now. Have the courage to reject this type of thing for the sake of the overall p= roject. Right. We do that, and you go outside and touch some grass for the benefit = of all subscribers to this mailing list. If you don't have confidence in the Bitcoin Core developers, instead of ins= ulting them, you could also just (help) maintain a fork of the project. I o= bviously think you're misguided here, but at least it's better to channel t= his distrust into something constructive. Given the number of people who sh= are your sentiment, such a project should be perfectly viable. Doubt. It was suggested in two different PRs ([0] and [1]) that the conceptual dis= cussion take place in this thread, so I am submitting my comments here. Thank you for taking conceptual discussion to the mailing list. AJ already = addressed your claims, so i won't repeat it here. This is just a temporary cease-fire while the spammers reload their ammunit= ion. There is obviously about to be another wave Between this one and your previous email, you certainly do know a lot about= the future! How's your trading going? otherwise what is the point of eliminating OP_RETURN restrictions? To not force people to bloat the UTxO set to store a trivial amount of data= in the output of a time-sensitive transactions. On the specifics, Citrea s= tores a zk-proof verifying Bitcoin's longest chain composed of a 128-byte G= roth16 proof and 16-byte total accumulated work (sauce: https://x.com/ekrem= bal_/status/1918008476552356202). I don't know and don't care why they do i= t in this way in particular, i just wish they did so in pruneable OP_RETURN= outputs instead of unspendable Taproot outputs as they do today. Or worse,= start thinking about bare multisig. Yes, and then the money printer makes sure that there is always enough easy= money sloshing around in the economy so that more pop up where the old one= s dropped out. This can and will continue indefinitely if we do nothing. Money printer financing working people forever certainly isn't something i = expected to read on the Bitcoin dev mailing list! My proposal is not to counter literally every type of spam. Just the ones t= hat have protocols relying on consistent transaction formats. Creating spec= ific filters against just these worst offenders should This is veering off-topic for this thread. If you want to argue that Core s= hould filter inscriptions could you take it to the appropriate thread? This= thread is just about damage control for people storing data in transaction= outputs. I believe you greatly overestimate the skill and competence of the people w= ho would do this type of thing. You could accomplish what you've laid out. = I could accomplish it. Your hubris gives me second-hand embarrassment. I hope the C2 domain update= i shared above gives you a clue that there does in fact exist other smart = people in the world. Threat actors would laugh pretty hard at your arrogant= emails and emotional breakdowns, but they probably don't care about your f= ilters in the slightest anyways. After reading the whole thread i have yet to read a single sound objection = to lifting the OP_RETURN restrictions. On Thursday, April 17th, 2025 at 2:52 PM, Antoine Poinsot wrote: Hi, Standardness rules exist for 3 mains reasons: mitigate DoS vectors, provide= upgrade hooks, or as a nudge to deter some usages. Bitcoin Core will by default only relay and mine transactions with at most = a single OP_RETURN output, with a scriptPubKey no larger than 83 bytes. Thi= s standardness rule falls into the third category: it aims to mildly deter = data storage while still allowing a less harmful alternative than using non= -provably-unspendable outputs. Developers are now designing constructions that work around these limitatio= ns. An example is Clementine, the recently-announced Citrea bridge, which u= ses unspendable Taproot outputs to store data in its "WatchtowerChallenge" = transaction due to the standardness restrictions on the size of OP_RETURNs[= ^0]. Meanwhile, we have witnessed in recent years that the nudge is ineffec= tive to deter storing data onchain. Since the restrictions on the usage of OP_RETURN outputs encourage harmful = practices while being ineffective in deterring unwanted usage, i propose to= drop them. I suggest to start by lifting the restriction on the size of th= e scriptPubKey for OP_RETURN outputs, as a first minimal step to stop encou= raging harmful behaviour, and to then proceed to lift the restriction on th= e number of OP_RETURN outputs per transactions. Antoine Poinsot [^0]: See section 6.1 of their whitepaper here https://citrea.xyz/clementin= e_whitepaper.pdf -- 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/= 68cdce0e-9030-4a6b-92a4-d48d05be3e80n%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 visit https://groups.google.com/d/msgid/bitcoindev/= BY5PR03MB5171138582C249F82228689A968D2%40BY5PR03MB5171.namprd03.prod.outloo= k.com. --_000_BY5PR03MB5171138582C249F82228689A968D2BY5PR03MB5171namp_ Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This is my first re= sponse/comment on this mailing list.  I think there are several issues= that have risen to the surface here including this one on a broken communi= cation link (well written message btw).

 

  1. Those outside of the dev community a= re perplexed by the process and feeling discounted, unheard, and/or rejecte= d.  Most of the issues/PRs/BIPs that the dev community deals with are beyond the ability of the general population = to understand, but occasionally there are ones that they grasp (at least so= mewhat) and for which they have opinion.  I=E2=80=99ve certainly learn= ed that when someone has an opinion it is really important to let them express it, otherwise, the pressure inside them buil= ds and they erupt like a volcano.  The Bitcoin ecosystem and its membe= rs are radically different today than 5-10 years ago =E2=80=93 it is bigger= , wider, and has broader interests now - it appears that process and communication mechanisms currently used by Core are not c= apable of reaching the community properly anymore. Note that communication = means two-way as well.   

    When someone buys Bitcoin or starts working within the ecosystem, there is = no membership guide, owner=E2=80=99s manual, or employee on-boarding proces= s.  It comes off very badly when someone trying to engage is told that= they don=E2=80=99t count or aren=E2=80=99t using proper channels, especially when they don=E2=80=99t even know where to go learn the rules o= f engagement.  That isn=E2=80=99t necessarily anyone=E2=80=99s fault, = but I=E2=80=99ve been involved in Bitcoin since 2017 and even now am still = learning new things about the engagement process, and there definitely have been several surprises and frustrations for me over the past handful = of days. 

 <= /o:p>

  1. The ecosystem is much more complex t= han ever before with people and companies developing products and services = with assumptions of how Bitcoin will operate.  Many of these are being done in stealth-mode as well.  Some people ar= e pouring their heart and soul (and money) into their projects and the expe= ctation of a standard is often crucial.  I am one of these folks, beyo= nd what I do in mining (CEO of Barefoot Mining) and as a board member at Ocean, I have been working for two years on a pro= ject related to enhancing block space access.  This proposed change in= standardness may impact my project in a negative manner, and, it is certai= nly possible others might be in a similar position.  Regardless, changes to standardness are HUGE.  I spen= t most of my career within the Personal Computer space and learned the hard= way that changes to a standards are a dangerous game.   I expand= a bit on this in this X  post:: https://x.com/bo= omer_btc/status/1917687830148526095

  2. The proposed = change also appears to be reduction in flexibility and configurability.&nbs= p; In general, this is never a good thing.  IMO, we should be going in the direction of giving people more choices and flexibility (although i= t is fine to make suggestions, set defaults, or provide general guidelines.= )  How someone configures their node and creates their mempool is akin= to free speech within Bitcoin. The same goes for those like me that are miners and create our own block templates = =E2=80=93 this is also part of our free speech (and our business).  In= the end though, whether you are a user or a miner, the more choices you ha= ve, the more freedom of speech you have. 


Side note: Ultimately, as a miner I am in the business of creating block sp= ace =E2=80=93 at least that is my view, and contrary to popular belief, min= ers are not always motivated to simply pick transactions that generate the = highest block reward in the immediate block, and as time goes by this will become even more common and apparent.  = I=E2=80=99ve spoken a lot on this recently in public forums, so I won=E2=80= =99t dwell on it here.

  1. Finally, there is the issue of an OP= _RETURN change, if it encourages more spam, and if we are just caving into = an inevitability.  I am against the proposed change and, even if that is true that the spam will ultimately find a way,= I feel we are acquiescing way too early.  Enough has been said on thi= s topic in other forums so I won=E2=80=99t go further. 


 

From: bitcoindev@googlegr= oups.com <bitcoindev@googlegroups.com> on behalf of PandaCute <pan= dacute12345678@gmail.com>
Date: Friday, May 2, 2025 at 7:11=E2=80=AF<= span style=3D"font-size:12.0pt;color:black">AM
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com= >
Subject: [bitcoindev] Re: Relax OP_RETURN standardness restrictions<= o:p>

You don't often get email from pandacute12345678@gmail.com. Learn why this is= important

I think this debate is missing one important part: a communicat= ion link between the developers and the users. The developers are speaking = with the developers, the users are speaking with the users, and no one is really trying to understand where the other = side is coming from. It's been a lot of aggressive, unproductive back-and-f= orth, with both sides accusing each other of bad intentions and completely = dismissing each other's points.

This is a technical mailing list aimed at devs, so I'll try to summarize wh= at I've seen in normal_users_land, and the general feeling out there right = now. Obviously, I'm not trying to suggest that users *feelings* should be d= ictate the technical direction of Bitcoin. However, it is important that there is mutual respect and trust b= etween users and devs.

Right now, trust is pretty broken. It can be regained, but not without unde= rstanding what went wrong in the first place.

I saw on IRC some devs suggesting they spend time on podcasts and social me= dia to explain the motivations behind this proposal *before* merging it, in= stead of merging now and hoping people just accept it. I think that=E2=80= =99s a fantastic idea, and the way to go. I particularly liked jonatack's message - =E2=80=9Cif Core shows humility = and patience, it would surprise people and improve things.=E2=80=9D

Now, about the proposal itself and what it *feels* like: It=E2=80=99s a big= change that came out of nowhere, especially at a time when spam doesn=E2= =80=99t seem like a big issue. It=E2=80=99s a bit=E2=80=A6 shocking? Normal= ly Bitcoin changes are discussed for ages, PRs take so long to get merged, because of all the care that devs put into considering the pros an= d the cons, but here? We get a mailing list post (that no user is reading, = let=E2=80=99s be honest) and a PR with a lot of contributors saying =E2=80= =9Cyeah, let=E2=80=99s do this!=E2=80=9D. There should be a bit more research. (Maybe there was, but behind closed doors?). We want to know abo= ut all the protocols that are bloating the UTXO set and that could be using= OP_RETURN instead. We want to know how many transactions like these are in= each block, and how many there will be once the new protocols start getting deployed. We want to see that= you did your homework for weeks before trying to change the policies.

It feels weird=E2=80=94like some sort of attack or a bribe. One protocol is= mentioned that would benefit from this change, and then an investor ACKs t= he PR. Someone points out a potential conflict of interest, and their comme= nt gets hidden. That=E2=80=99s shady, no denying it.

And then, it feels that users have no say. It's a ""technocracy&q= uot;", where devs have all the power in their hands and can decide whe= re the protocol goes, while completely dismissing users' concerns.

Users do have concerns=E2=80=94lots of them. And I encourage devs to step o= ut and talk to "regular" Bitcoin users. It=E2=80=99s not just a = =E2=80=9Cloud minority=E2=80=9D=E2=80=94there are many people genuinely wor= ried: =E2=80=9CCan we trust Core devs anymore? Is there even another option= ?=E2=80=9D. But their concerns are dismissed, their comments deleted or hidden, they're treated like &quo= t;bullies" that devs should ignore, devs should "merge Todd's PR = and call it a day".

Without understanding all the technical details, I'd say there's a pretty g= ood chance that the very smart people that work on Core are right once agai= n. Statistically, it's very likely. Communicate to users, explain your moti= vations, and show that you want to listen to our concerns.

Lastly, as irritating as that might be, users freaking out and holding core= developers accountable and flooding Github is a feature, not a bug. Devs a= ren't the Bitcoin gods, they are humans, and humans can be bribed,  ca= n be coerced, can have conflict of interest, can fck up.

Users care and want to protect Bitcoin. Be grateful.

Respectfully,
A Bitcoin Dev

On Friday, May 2, 2= 025 at 12:46:20=E2=80=AFAM UT= C+2 Antoine Poinsot wrote:

As i have repeatedl= y asked people to take conceptual discussions to the mailing list, i am cir= cling back to this thread to answer objections. I have also written my poin= t of view and reasons for proposing this change in a blog post which goes into more details: https://ant= oinep.com/posts/relay_policy_drama.

 

Going through the e= mails in order.

 

Am I the only one left on this list who= actually cares about Bitcoin's survival?

 

Thanks Luke for your mea= sured take. It's refreshing to see we have adults on both sides of this &qu= ot;debate".<= /p>

 

With that history in mind, removing lim= its on OP_RETURN standardness size is pointless.

 

Yes, it is pointles= s for people who want to store massive amount of data. It is not for people= who want to store a small amount of data in a time-sensitive transaction's= output. Because they need their transaction to be relayed on the p2p network, and are therefore pushed to use unspenda= ble outputs instead.

 

Relax= ing OP_RETURN size limits without dealing with the inscriptions<= /span>

 

This is orthogonal.= The harmful behaviour described in OP is possible today regardless of insc= riptions.

 

There= 's little to no incentive to use OP_RETURN for data storage when using the = 'inscriptions' exploit costs 4x less in transactions. What's the point of h= aving a "standard" way to store arbitrary data if the exploit method is 4x cheaper? And the nonstandard version of t= he exploit allows 4x the data?

 

You have obviously not p= roperly read or understood OP. There is no need to speculate about wha= t would happen or not. People are using outputs to store data today=E2=80=8B. The only question now is harm reduction:= given that people are storing this data in outputs today, do we want to of= fer a way to do it that does not force every single full node on the networ= k to store their data forever?

 

That said i agree that t= his is not going to change anything for people who try to store large amoun= t of data onchain, they already have a 4x cheaper way of doing so.=

 

For e= xample, let's say I want to distribute malware. Well, might as well just st= ore it in an OP_RETURN.

 

The point about storing = data on everyone's disk was addressed by others: it's already possible and = that's why Core XOR's the content of third-party-controlled data it writes to disk. But an interesting fact on this specific point abo= ut malware and OP_RETURN outputs is how they have already been used in the = past to resiliently update the domain of a malware's C2 servers: https://news.sophos.com/wp-content/uploads/2020/06/glupteba_final-1.pdf= .

 

This = is a fundamental change to the nature of what the Bitcoin network itself is= in its entirety. [...] Bitcoin as we know it changes forever in the most f= undamental way imaginable

 

Wild emotional clai= ms with no ground whatsoever don't convince anybody and only hurt your cred= ibility.

 

and w= e might as well give up on Bitcoin ever being a thing if this is the path c= hosen

 

Well if you believe the = whole system is as brittle as relying on people playing nice for security, = you might as well give up now.=

 

Have = the courage to reject this type of thing for the sake of the overall projec= t.

 

Right. We do that, and y= ou go outside and touch some grass for the benefit of all subscribers to th= is mailing list.<= /p>

 

If you don't have conf= idence in the Bitcoin Core developers, instead of insulting them, you could= also just (help) maintain a fork of the project. I obviously think you're misguided here, but at least it's better to chann= el this distrust into something constructive. Given the number of people wh= o share your sentiment, such a project should be perfectly viable.

 

Doubt.

 

It was suggested in tw= o different PRs ([0] and [1]) that the conceptual discussion take place in = this thread, so I am submitting my comments here.

 

Thank you for taking con= ceptual discussion to the mailing list. AJ already addressed your claims, s= o i won't repeat it here.

 

This is just a tempora= ry cease-fire while the spammers reload their ammunition. There is obviousl= y about to be another wave

 

Between this one an= d your previous email, you certainly do know a lot about the future! How's = your trading going?

 

otherwise what is the = point of eliminating OP_RETURN restrictions?

 

To not force people to b= loat the UTxO set to store a trivial amount of data in the output of a time= -sensitive transactions. On the specifics, Citrea stores a zk-proof verifying Bitcoin's longest chain composed of a 128-byte= Groth16 proof and 16-byte total accumulated work (sauce: https://x.com/ekrembal_/status/1918008476552356202). I don't know= and don't care why they do it in this way in particular, i just wish they = did so in pruneable OP_RETURN outputs instead of unspendable Taproot outputs as they do today. Or worse, start t= hinking about bare multisig.

 

Yes, and then the mone= y printer makes sure that there is always enough easy money sloshing around= in the economy so that more pop up where the old ones dropped out. This can and will continue indefinitely if we do not= hing.

 

Money printer financing = working people forever certainly isn't something i expected to read on the = Bitcoin dev mailing list!

 

My pr= oposal is not to counter literally every type of spam. Just the ones that h= ave protocols relying on consistent transaction formats. Creating specific = filters against just these worst offenders should

 

This is veering off-topi= c for this thread. If you want to argue that Core should filter inscription= s could you take it to the appropriate thread? This thread is just about damage control for people storing data in transa= ction outputs.

 

I bel= ieve you greatly overestimate the skill and competence of the people who wo= uld do this type of thing. You could accomplish what you've laid out. I cou= ld accomplish it.

 

Your hubris gi= ves me second-hand embarrassment. I hope the C2 domain update i shared abov= e gives you a clue that there does in fact exist other smart people in the world. Threat actors would laugh pretty hard at = your arrogant emails and emotional breakdowns, but they probably don't care= about your filters in the slightest anyways.

 

After reading = the whole thread i have yet to read a single sound objection to lifting the= OP_RETURN restrictions.

On Thursday, April = 17th, 2025 at 2:52 PM, Antoine Poinsot <dar= o...@protonmail.com> wrote:

Hi,

Standardness rules exist for 3 mains reasons: mitigate DoS vectors, provide= upgrade hooks, or as a nudge to deter some usages.

 

Bitcoin Core will by default only relay and mine tran= sactions with at most a single OP_RETURN output, with a scriptPubKey no lar= ger than 83 bytes. This standardness rule falls into the third category: it aims to mildly deter data storage while still = allowing a less harmful alternative than using non-provably-unspendable out= puts.

 

Developers are now designing constructions that work = around these limitations. An example is Clementine, the recently-announced = Citrea bridge, which uses unspendable Taproot outputs to store data in its "WatchtowerChallenge" transaction d= ue to the standardness restrictions on the size of OP_RETURNs[^0]. Meanwhil= e, we have witnessed in recent years that the nudge is ineffective to deter= storing data onchain.

 

Since the restrictions on the usage of OP_RETURN outp= uts encourage harmful practices while being ineffective in deterring unwant= ed usage, i propose to drop them. I suggest to start by lifting the restriction on the size of the scriptPubKey for OP_RE= TURN outputs, as a first minimal step to stop encouraging harmful behaviour= , and to then proceed to lift the restriction on the number of OP_RETURN ou= tputs per transactions.

 

Antoine Poinsot

 

[^0]: See section 6.1 of their whitepaper here = https://citrea.xyz/clementine_whitepaper.pdf

 

--
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 bitcoindev+unsub= scribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/68cdce0e-9030-4a6b-92a4-d48d05= be3e80n%40googlegroups.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 visit https://groups.goo= gle.com/d/msgid/bitcoindev/BY5PR03MB5171138582C249F82228689A968D2%40BY5PR03= MB5171.namprd03.prod.outlook.com.
--_000_BY5PR03MB5171138582C249F82228689A968D2BY5PR03MB5171namp_--