path: root/97/8775d71722b2328e0153daff74a0d70bd02d59

Delivery-date: Tue, 20 May 2025 19:13:39 -0700
Received: from mail-oi1-f190.google.com ([209.85.167.190])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDOZFSV74ALBBR7NWTAQMGQEEGQ2D7A@googlegroups.com>)
	id 1uHYxd-0006OW-Cm
	for bitcoindev@gnusha.org; Tue, 20 May 2025 19:13:39 -0700
Received: by mail-oi1-f190.google.com with SMTP id 5614622812f47-401c6b8b674sf7887713b6e.2
        for <bitcoindev@gnusha.org>; Tue, 20 May 2025 19:13:37 -0700 (PDT)
ARC-Seal: i=3; a=rsa-sha256; t=1747793612; cv=pass;
        d=google.com; s=arc-20240605;
        b=V5N9QcqI3JzGrwLCZI5LNa2Zl5gSjB3u9DP+nMywtxK1ERGbU2ga5aegPUQ/NkgiOb
         mIWvwPw92hXEOC0x4WGmogtdGA+hEXf6KCFG6zsWGsQrmddnh42YV7URAJjVR0ucMRKK
         QknJjoxZ4HKbbNlJKwU/5jz9OA9mM3TP+qpYvxnh4naDsO9WsV21b/NgatdlDJzhR9NF
         X1/KiN0Jijk/oQM/TwKG0rr1KuNBDm79hmNBMW0E20mNs5v883DC3GOUe2hfOLu3SVls
         n9zxHd5m5354vecehV0YGN4Uo8ROxmHCvG5L6+DmU50CbuN0mmxIUnop0hqARZnsux5V
         Pv2g==
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:cc:to:from:sender:dkim-signature;
        bh=USFnwzSp0SUH2foFG7dlQdhE3egznlM8xSucjWt5/u4=;
        fh=XiWDVQiyyA92AjlYWv/bkHiFEIIBqcS78nsw4e0e/iE=;
        b=CGqIRFugA4St+MnUDKyUS67F53cAA54f/2HmkZFI+L4L84NcWDuAwwuthga/DGcRSV
         MWdLNVQit+XYZrPtk1w3LWFE6oO74wIqOrB6rSET3+kVQsMAygUlUMEqf57Vg+jksCH7
         fawf+jyPPjNz8tsSvv4nktK2OOfBq8ybrqHbZQoy6yCu7VJshke+JipnMcMFgdcTFOw7
         NdHdHlMQ/s+Pr2zXBBJlscD1xh3gciyWwfrXkkkvKuuAGNbJH+yrBgVrgZN/sF0ug1R1
         9s7lLgbYORKD7uDDkj9Qo6rrrIFLNylimkZMD43NfNS/G+YBblyf6oFOjIy22O1DNnhz
         n6Yw==;
        darn=gnusha.org
ARC-Authentication-Results: i=3; gmr-mx.google.com;
       dkim=pass header.i=@barefootmining.com header.s=selector1 header.b=vupQVplj;
       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:2009::71d 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=1747793612; x=1748398412; 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:cc:to:from:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=USFnwzSp0SUH2foFG7dlQdhE3egznlM8xSucjWt5/u4=;
        b=cJF7YXwE6Gv1UWyzwQz0mYyHzusvAeFSO7AiHhEr6OpE14AZIn+UVu2ZFf5YAz4FDl
         KHRG56ZOJoN5X8JnmUx8Ze/YJ+ugaI5BBUfuJhb7fh6an2vSgyCnlLp6idQOnBwQV3wL
         XHu1kZ2OHOockayB8pl/sQd/Nw6pWW9xtBYgAzDibF1Vh/A6BkyQ9M4yehVCkxyHIiwP
         0JREdVV5u4L/1H9QXT5Uv++kHuSksUm+T/B09Eb5WpULhXNcjZC94S4bnyLdk8FOc9eo
         ROrbpYCiGcc1+DLY6+9TSSd6wRqgiBbTw2VjWEHM9ajgGic03SCkJTc6Jb3lRaJ2FdyK
         ijZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747793612; x=1748398412;
        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:cc:to:from:x-beenthere:x-gm-message-state:sender:from:to:cc
         :subject:date:message-id:reply-to;
        bh=USFnwzSp0SUH2foFG7dlQdhE3egznlM8xSucjWt5/u4=;
        b=wcea/rvzqubVl4zu9Q68mpxLQGEUulTJzV19hsIMv1e8PeEJTg1tH9/2fhmLVdaQl0
         oXBTxmb05jP563udLf90ZTzP+uT1zqhnrZJyZyin5M2fIyxBZPD9n/87zNN7Vz4PWRr6
         rBC4j9B5g3Z0u9xHMtzgzRfID2AEI4GDLIVHqYNGNfIuHmg+wUGKGdun0ag3XdNcGTGL
         b6TltsCYkY/usL+nwKtWWhl7/Pldec7rq55jgsU5KOkvnGcbHe3UaAkIO8x4pTL2sWLw
         UvEv4uaNC+xouorVpAB/quc4s8YWRjvfr9to0lhF5xtLIVC+wsReQmdZu8MEaJap40t0
         ElmA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=3; AJvYcCVVnSzSkr+uaAJclUZOJdXlawFkDSK1t4Bp94LAZGFBrqxHZdUkXNKs+dHKkWt8VWoECH+gEdQ48ZTO@gnusha.org
X-Gm-Message-State: AOJu0YwGBfELI9vFQuDqfps4STmbCaninF6E8h4AQ1nxuaIgkdhh42FA
	Ou1aU11IkWD8u0Dyol1JO+FqCL6rPOoRP962SkxG53cRJnvg0Z9okO/9
X-Google-Smtp-Source: AGHT+IEGdp/l+R1BCGxbfResVYjzYnCNE6c8EeSr27K0aRZgS3kyK18/F54V899bdASXdN6s4Yjs3w==
X-Received: by 2002:a05:6808:6b97:b0:403:5150:c351 with SMTP id 5614622812f47-404d8679935mr11947415b6e.6.1747793611630;
        Tue, 20 May 2025 19:13:31 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBEF7KQOXTk4IkXaMfvR0M0db0v02JDMWHMBBv1CTSJ3Ww==
Received: by 2002:a05:6820:828b:b0:609:1093:ed15 with SMTP id
 006d021491bc7-609ea3111c4ls1007217eaf.0.-pod-prod-09-us; Tue, 20 May 2025
 19:13:27 -0700 (PDT)
X-Forwarded-Encrypted: i=3; AJvYcCXMz+5Pdmz7b5XcXrEushT9vkk0Oty15oxOCqRH1XLDjkQgKer9395EKc6AcCExO6zcetrsEtnFHAdL@googlegroups.com
X-Received: by 2002:a05:6808:6a98:b0:3f8:e55c:16ea with SMTP id 5614622812f47-404d886375fmr12708365b6e.24.1747793607406;
        Tue, 20 May 2025 19:13:27 -0700 (PDT)
Received: by 2002:a05:6808:82c7:b0:3f6:a384:eb6f with SMTP id 5614622812f47-404da00d5efmsb6e;
        Tue, 20 May 2025 19:10:20 -0700 (PDT)
X-Forwarded-Encrypted: i=3; AJvYcCWsp4yULMsxhuCzW7s24IIY/0Qga+X3iL4DAfvW5lP6VnxocjYS2l/Uly9CbweXZJX1+jnsKr01+4WS@googlegroups.com
X-Received: by 2002:a05:6820:1e17:b0:60a:7f9:c897 with SMTP id 006d021491bc7-60a07f9ca67mr8244704eaf.7.1747793419542;
        Tue, 20 May 2025 19:10:19 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1747793419; cv=pass;
        d=google.com; s=arc-20240605;
        b=Mn5Ha01jQ8BpPj6NtW8q215LK7yzjvBbRJYKyu8+O+9cUvPBH4F7Qvr+HAHx5U55cL
         i8EulobcFGc1HIxRclQsTesvHpixf77RF06VFddQb8P4k0QBUv9uwi/LIRt+3ZUcPXii
         D0/Gm53GfaNBk+vWjrtT5tnU7PWcCWfA7Z8pLTdnBfPtjmwejOQdqYzP32lDwaPwOxRN
         u6F4sJretrikRiuHwwWlPiyKnn1MnKVZLdf3CiA1pzs81F40jcQZ0nuI9iTZRCc6ZgAv
         /KoN9Yqxi+NwSYCQZ3nuo/hjbmtMqpvAqQtATVd1U7ze2IcfnM0xtnlpHBw+E3Fh8kT+
         IxBw==
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:cc:to
         :from:dkim-signature;
        bh=5ddrN/U1+DDWSHIzoRwfmqRXIC0PMOzY3yQqZQEy92c=;
        fh=5ZEk39Hi3lAqaNyvlP6HrDc8ASwxPbo/wOHfifaukbU=;
        b=BXb/DKgeLP+aVUNsVdwHNCf+sCRXPUSYTnM24/I3ugVK/mVCxAudrsKXtETpunxIIH
         qhoTff0j/6QFQaUOFVnmniwLASeCivnUcXklrHqYRH5qhsBs7EFehNq6Fw9GrXKwsJX4
         sueBF5nmwqo9WeFj17mEYCe+pTZ2kKuaT36Y3QGUiPFvTdTEk+aLid1ahM0bHq96BO90
         eQLIyvZk8M9bcH3VGNeCMGdnSIm5+PV5B7H9tmwjgNpZi7u4KK2YJbADRU/Z6KTS5xYH
         GJLyDLEomlFoPWKnjsAH2t9MEL9Kr9FjzjUl4PYhIPMswGnzhYeK4/R7Jhw8RSlXNH1M
         LOag==;
        dara=google.com
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@barefootmining.com header.s=selector1 header.b=vupQVplj;
       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:2009::71d as permitted sender) smtp.mailfrom=bob.burnett@barefootmining.com
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2071d.outbound.protection.outlook.com. [2a01:111:f403:2009::71d])
        by gmr-mx.google.com with ESMTPS id 006d021491bc7-609f2f38ddasi613637eaf.1.2025.05.20.19.10.18
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 20 May 2025 19:10:19 -0700 (PDT)
Received-SPF: pass (google.com: domain of bob.burnett@barefootmining.com designates 2a01:111:f403:2009::71d as permitted sender) client-ip=2a01:111:f403:2009::71d;
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=a6HRlkLNemrB1EMxcmLaRKVS+yQu2jBGe2J7J3Qu9YhoihTCcfCIH3YciJ+mmGOub2YRSh8Q4ZrAaqhdc1MM2Xz9QHUnyKzenofuGBFMi4mjycvsJ1GRg0p4bZpwZHWEbibFsum2IN3N7YGGH0+Rgeq8V4zTeHHppiJVEUUIPiTqDhfndDh8OcnwUSUOK2pwYD2arn69WYBVITwyhZHNGU3A1Q1yaJo1nTbQHKzlHREOkwDH9n+pAaqRcIswKIa50brqI8WBwE7vamk2dMqGg3weZw+gSC6OJZNZlhYPNHTwfxfpA3i6AlJDgpIqux9qdHN/eM/YMi+5hIsN7vzSNA==
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=5ddrN/U1+DDWSHIzoRwfmqRXIC0PMOzY3yQqZQEy92c=;
 b=SUdF1wOkavaeteYcai7FunE0WZFvclQfjo9NQORQkgK5a89ARoDiV6EvnMN1HlyHmdauNpoxraXrfTm66XFGhmJ2sCo1haFza6ZeX3/JzUc4wAn0wpICwJd4LJSO1ES0rdrgQU3BW1d1satbmCWhT/cboGlgt18Zn00SqDCq13fSBrk5scp9PKt/nzy189qNb2rGDiFNXUquGggKHXW9c7DmE6lAPbcqmxIHIN00KC0byoA70P/n3DNnaUKbM9uhZS2VNLslA/4Q+u2kacU/bE2YBaFqyFbtC1xWky6RV/+FxilddCZaCqPLn3jTaNMJUptltp5UsiuM7CKALu0B7A==
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 CO6PR03MB6225.namprd03.prod.outlook.com (2603:10b6:303:13c::23) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.19; Wed, 21 May
 2025 02:10:14 +0000
Received: from BY5PR03MB5171.namprd03.prod.outlook.com
 ([fe80::3749:df95:28d3:fff1]) by BY5PR03MB5171.namprd03.prod.outlook.com
 ([fe80::3749:df95:28d3:fff1%4]) with mapi id 15.20.8746.030; Wed, 21 May 2025
 02:10:13 +0000
From: Bob Burnett <bob.burnett@barefootmining.com>
To: Greg Maxwell <gmaxwell@gmail.com>, Antoine Poinsot
	<darosior@protonmail.com>
CC: Peter Todd <pete@petertodd.org>, Bitcoin Development Mailing List
	<bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Removing OP_Return restrictions: Devil's
 Advocate Position
Thread-Topic: [bitcoindev] Re: Removing OP_Return restrictions: Devil's
 Advocate Position
Thread-Index: AQHbydHGx2/BsIj4Ak2r6IoxpaFlXLPcJcMAgAAjvaM=
Date: Wed, 21 May 2025 02:10:13 +0000
Message-ID: <BY5PR03MB5171FCC38022BF80272729FD969EA@BY5PR03MB5171.namprd03.prod.outlook.com>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2UMRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY=@protonmail.com>
 <aBUlEOBqqrOIGHWC@petertodd.org>
 <7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2M8S0jLORI2GxwNQ7qmfyM2jqQiB6JTiw=@protonmail.com>
 <CAAS2fgRyu1HKHDk_aCyHXqe+sgYpcApjmXx3Ps4ChpBAxeBcpw@mail.gmail.com>
In-Reply-To: <CAAS2fgRyu1HKHDk_aCyHXqe+sgYpcApjmXx3Ps4ChpBAxeBcpw@mail.gmail.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_|CO6PR03MB6225:EE_
x-ms-office365-filtering-correlation-id: 182a3f45-2c94-4349-65cd-08dd980c9f5c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|4022899009|366016|38070700018|8096899003|13003099007;
x-microsoft-antispam-message-info: =?utf-8?B?b0g0SDljV1hpQ0o3Z29pK0ZjUjR1YXk2NWVyYzRVN1dOdEFhTVh0OXlWd1RD?=
 =?utf-8?B?bWF0MjhVUlFoVE03QzY0QzY3NFdWWXhsNnM0WGgxamxtUmdtc2p2ayttZ3hE?=
 =?utf-8?B?Nm16L2VVeTh3UkJKZ0pSRENUclFweFRpZkVCeEdFVzJsMlc4Tkl2R2JKU0xy?=
 =?utf-8?B?dlRLTHp6R1QwR1hNQ2JhUVNKMHBQcThVRW5jNHVocDc2MHc2YWo3cnNlQ29J?=
 =?utf-8?B?NkluWEdYYm1QZW1rUzdoNzNyRm1nUnlyd05EYzMvdDRRSmJBRE5ZeDRTS04y?=
 =?utf-8?B?a2p5R2dNVjBuK05RYlA5cWhzdW5pWm80STBLWEp4dWFVejJIZVd1MHp4OVk1?=
 =?utf-8?B?YytCai9lTUlldmZUNkRqWnZTYjZpUVBMOS9iRUcwNHdobzF4QURDNkEyMG1t?=
 =?utf-8?B?V3V2TVhSNk1KeG5BV0tZaUl1QUZ3NWI5dDVQTWpBUklSYWNnZ1p5anUrb2Jj?=
 =?utf-8?B?RWtIUHRuRFNyU3hiakFGTFl0UWZZS1RweVgzSkxIT2VtYUV4WTZKTDR0Umxl?=
 =?utf-8?B?N3ZiY0l0Q3ZRN3Q5SFRZZmMrUEhHUG9CRTJmVEZ6ZGZLdUFLd3dlTWhpK2ZS?=
 =?utf-8?B?dkFsSmV0Zlc3RUxSWXJXL0FhVUI1U3lGdHE1RjhycHVCV2RpVUhqQ1ltRklK?=
 =?utf-8?B?a2NBb1VSNTNSSk8rampqN0M3eGdZci9NaXA2dkFGSm94djJucnpXaE4wVEFv?=
 =?utf-8?B?MExRc0RRZVhsRm5MNzY5Z2FuY0RzbjZJTWxJUEZJZ3pwUWJ3alFuclpvL0JH?=
 =?utf-8?B?MlgydHVidEZsU2IvTSs1Z1lZMlJGWWJmTWM5WTd5ZU42aWliclo4eXpBV3li?=
 =?utf-8?B?dlhEYWdDY3NQRlMrSUQvQWtRWStLR0srMTlsNFE5YlZzbm5uTG04aTk2bGtC?=
 =?utf-8?B?RHQyV21YQkpERkxpR3BrZXY4eWI3R0xsZXBMOGNaWmRnWXpwNUlXZE4rdWEw?=
 =?utf-8?B?WEMxN0RIZ3lycXc4STZWS0hadEs1ODJkZ3ZNdHRueWNDTnM3M0FGV0NxMGtD?=
 =?utf-8?B?OXhIN0EwRUpmdUV6a2gwUXE1M3QzRW00dG5mT2FaMHFuaklMcWZmNi9NUitU?=
 =?utf-8?B?Q3NQRHVwMDRDOEVBd0MyNXZOdEJlZTBjbUMzL3h6WWJQanRYRjRoNnBDaWg2?=
 =?utf-8?B?elhCWllJUDJFVVNYa1A4MStnb2tZdFNKVkFlUXl6WUlSaytuMXNCdGJWTmtJ?=
 =?utf-8?B?MlQyaGZkQ0FwVzVTekl6azdhWGcrY3RiK3RFRHR6bGVRVXFKS3BOQWhTSTRp?=
 =?utf-8?B?YVlHc3NnYTVaak0rTUI2Z2l5bk1lVjg0cUtrMVQrdFVzbXNBVjdUbzcwU3dz?=
 =?utf-8?B?eWNMRDFWV2RUWkRteEU0a3JKa2dtNFRDZGpPdHE3ODRpYW0rM1pRdW9wenVN?=
 =?utf-8?B?MDVVVjNIcnhIb2NYNTRBU0E2M28zSk9oY0M2K3ZGckpGdHBzWUd5UlBmWDVT?=
 =?utf-8?B?b0kvQk5iRDBrNjB3RnI3QStWMDVqN1VncFJDRmRRVi81eXBqZVhMUEE5VjZQ?=
 =?utf-8?B?b0wwWk9rVHVkc2p2NlI0RytLNjc3WUJJOXBvTCthVW5Ic2diTVVkd01rWGVs?=
 =?utf-8?B?VzFHWFFMdUtIMGVsdHlGcmNnNXBLK3V4RFhBOEEwRisrS09YZU1KN3JZWXJS?=
 =?utf-8?B?ZU5jTzl1YkVIamVHVGpJYzZhZUEzMTc2Ykc5enpLbXgvRXFkN3R3VzNEUytw?=
 =?utf-8?B?dFhNOWJ2WmRibUV1b1pWYkxxV2UvMGpGT2FaRGFzUjZjNndMS2R6UlA0UnFD?=
 =?utf-8?B?aVNtby9jYWxmSHpXa2FpckZCWTZrWlJUNkFOeUU2Q3pHbXluWGRMVVZOZjNN?=
 =?utf-8?B?Q3U5b1NpWk0xV1Rmc3JlbStNcmhMelVKWXlQdGxiNVg3elp5aTBvWjlCN1p1?=
 =?utf-8?B?RVV4RlJJeUFnWUJMNVJGVGcrNVR0SmZ1ZzJ2dU1UUnpHU1FHeWFxaU9FK2Ir?=
 =?utf-8?Q?iAix8pOloKQ=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)(1800799024)(4022899009)(366016)(38070700018)(8096899003)(13003099007);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eGZQSmpwd25WdExIT3o1QTNBYWZJZ3JzeXp1dmYrZzFiUTFaM3p4TnREYlpT?=
 =?utf-8?B?RCtYamcyVGVzTXUxU2QxdnJTRzVmQllsTWR1RERCSXVwbDZiVXJad1RuMlZW?=
 =?utf-8?B?ZmpCWlk1THo1d2JMT0RLM1Y3czNldHdpRUhRVW5ob2Rhd1FsTnYrYnVlSm1X?=
 =?utf-8?B?R1psckVvTlJFVndTQ1l0WCtRUE8vQWVxQ2tpMWh3Uk81UjRpdjhMNlFweVJY?=
 =?utf-8?B?VDdJbkJzQ1NLUDQxOFNvcE4veUlySnQ5aGRobmY1d3I5UUVGZjlhV2lGMkNI?=
 =?utf-8?B?SHBWa0tEZWJmN2prbWhqbHlwTzRxak9rdGpPeWNENUI1STNzVVBRVFhnNzNM?=
 =?utf-8?B?aXF4RFJ1SU4yWW52Zk5oeU5sNTVHSC9rRFNjS0JIa3R3S0pacXUxYjFFMVBB?=
 =?utf-8?B?cTNCd0s1K3l1KzFBdGJDaS85bjd6K3pTMHdoOWRZZy92RWJiak8rTzdFb0t5?=
 =?utf-8?B?WnBLVkF2NDUvMFdLM2JtS3pycDVXRmQvR0FIUUJwWXVnMGdtYmtXdUxvVUpR?=
 =?utf-8?B?dFJDTmw4NmdJcDJIcUZ6YUZuVjBZUjAvQm9lR0dBZzNyQk1hTVdoZmpuWW8w?=
 =?utf-8?B?bnYzY3R1RmZQOFYwSEMvamFISzZ3cXVmQVRLaXN3eWJIOTZPSVpCUlM3UzNG?=
 =?utf-8?B?eUMvVEJudzRDVmRBRS9aVGxEQlE2dTJzUGRqcy9PaE9XU3B0Rzk5c25ZeTdy?=
 =?utf-8?B?OUkzYkhwMzdSMjd6SmptRmFtOExGSmZOMUJRSXJreUhkeGU5QUNVYmpoYU5C?=
 =?utf-8?B?UHdOT1pmeCt6eTVicVJCN21RekJwTW8wZDFveGxFUlJ6cklNVUZSWlFTeFg0?=
 =?utf-8?B?R2hkaEQySFNjWDdOSmJBZ0RCWThKM2Jybnd0Q2ZoQTdtekZRZnBFZVgySzhP?=
 =?utf-8?B?enBFeVlXcy9Hd2UzYXU0N3FXT3VYWnc1Zml0VTQyQjMyNWRxM1J3VEVRWkRy?=
 =?utf-8?B?Z21uRElES3ZWNytvd29XWlNMNFJZQTdlTG0vRTROWHE0NzJ2RWxTOC9tdWhm?=
 =?utf-8?B?dmw3bDFWK2srV2k3QlhZc00wcUhoMStjRlRSSnArcXJMTHd6emVJdnJ0bmdn?=
 =?utf-8?B?eC9EeWtyd09tTWdKMkxLdTI5MFhFNHJib1NPd2d0T2xCTG4vWVo2N1JYeGxx?=
 =?utf-8?B?dHBPZ25UcTZ2ZWZ4UEF4U3RRTlZCc29HMUI1KzBZdkZwdjNvZUtXL0Y1b29D?=
 =?utf-8?B?VmpNeHN5UmJId2NmYVovYWZIZ2NnbXNXZndmd0p4SVNUYU1KZmFCQ3RaSjFw?=
 =?utf-8?B?VXFENHEwUnJlRXJ0ci9QaEVwb01sZ1hzK29ndmdPeWNWd05HaDFZaElFVEFF?=
 =?utf-8?B?OWNRNHpGbFV4akVKTU5KYzh1RXRvLzlnSXNJVGZBa2dxUUV0RmtQWnNEdW9C?=
 =?utf-8?B?RjJlZzdrZnN1YkhrTkE1QVc3QnMrS0FLamFZWVRBR21yWFRFbmw2a1FtUzRI?=
 =?utf-8?B?c2lZdEF5MERQY3ZjQ2dtcGREaE0vZEVLbHA5cnBQOW5XZjI2cmlTZFFuN0N1?=
 =?utf-8?B?cGtaTm80SVRJT2gxRyticDhNSXc4aTR3M1VGS09nTmRoM3ZTamJjR1g0OHlx?=
 =?utf-8?B?dU5pakNHVzFOdHZGVTRrT3Zocm55OEoyMWYrSjBjc2dDTFF1YjZNV1VXaitP?=
 =?utf-8?B?UDdWMnhadG1nK2VXVzgyeWs4Vnh1L0tJM0c5ZVlLMTg5Q0pTVjhTRzE5QjJx?=
 =?utf-8?B?RUlQUVJXenEwQ0s1TXhjVXQ2T0VwblFETXNVMmJBU0VTdVpLT0REZVpwR2dT?=
 =?utf-8?B?bWo1NEI0U05QN29UVTRIYVIxV1YrMnZOdjBNTGtzSkppWmdhcElqeHBVb1Rw?=
 =?utf-8?B?OFUzSW9iQzd5eFNqR2hObG96NUhPWk0wbmgraEIwTGtyRkxjYi9yRUt2b0Fl?=
 =?utf-8?B?U0I1YU9ycnZwL3psbHNhRFpmdzA2SXo3azVSUnNMSnZUZ29LRGZQc3JEeDRW?=
 =?utf-8?B?cjhzUllHSGRIelhpZmNWUTROTWJvMkdRQ21veEhJRWJlVTB6NDVLbDJkcDFh?=
 =?utf-8?B?bEYwYUZBVjA0d3p3NFg5Uk91aFNrZU5YbDFrM3B6bGQvNGljNUM1dGlwWHZC?=
 =?utf-8?B?bXpTK1FoeHN0WmxjczVYMWJiMzMyU3IyZm1ZRkR3RkZvcGFwWkt1OUN6NGNU?=
 =?utf-8?B?MGV5QTBPaWdRNzE1cy9ocENvUjhSTVBCU3RZdGZ2elBVUm9jUmVSYzF0ZkF2?=
 =?utf-8?Q?Tgf71doT7gO+tQe8aZrjx90=3D?=
Content-Type: multipart/alternative;
	boundary="_000_BY5PR03MB5171FCC38022BF80272729FD969EABY5PR03MB5171namp_"
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: 182a3f45-2c94-4349-65cd-08dd980c9f5c
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2025 02:10:13.6612
 (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: PUUcpDLoNmx8/jKWaingLqzOukfCnbYY2BJ220si9QaENbrU+58oyTc5BdgfwOOyP0wg91A5avQ3OxOpB2L5XgPXdo2DLGyhPNM98bxwTD0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR03MB6225
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=vupQVplj;
       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:2009::71d as permitted sender) smtp.mailfrom=bob.burnett@barefootmining.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.7 (/)

--_000_BY5PR03MB5171FCC38022BF80272729FD969EABY5PR03MB5171namp_
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

For those who don=E2=80=99t know me, I run a mining company called Barefoot=
 Mining=E2=80=93 not the biggest mining company but not the smallest either=
.  Whether I would be considered major or not can be judged by others.

That said, I suggest being very careful about projecting the current behavi=
or of major miners as the norm or representative of the future.  We are ext=
remely early in the development of the mining industry and there is a high =
likelihood that over the next few years that there will a dramatic change i=
n the list of major miners =E2=80=93 and there very well may be changes in =
the philosophies and priorities of these miners as well.

I spent most of career in the personal computer industry going back to =E2=
=80=9986 (most notably as the CTO of Gateway) and I learned many things fro=
m my experience.  One important thing was that the pace with which companie=
s could rise to or fall from prominence was jaw-dropping.  Assuming that =
=E2=80=9Cmajor miners=E2=80=9D was meant to mean a group that largely is co=
mprised of pubcos, none of the major players in the mining industry have be=
en doing it for long - with most going public very recently (=E2=80=9922 an=
d =E2=80=9923).   They but pups as companies and we=E2=80=99ve already seen=
 a huge flameout or two.  The next three to five years will likely result i=
n a few more flameouts and some large new entrants that may approach mining=
 from a completely different perspective.  A second learning I will share f=
rom my PC development days was that predicting usages and user behavior is =
next to impossible.  The safest and most accommodating path is to give as m=
uch user optionality/configurability as possible.  My high-level recommenda=
tion is to work on paths that give users more choice not less.  This is app=
lies to OP_RETURN but, even more importantly, I think it is the best design=
 direction in general.

To offer what may be a new lens in which to view miners, I=E2=80=99ll share=
 a bit of my philosophy and vision for my company.  I view Barefoot as bein=
g in the business of block production and I desire the maximum amount of fl=
exibility/choice in making blocks.  My strategy to develop and monetize blo=
ck space goes beyond just fighting for a piece of the block reward.  I beli=
eve that over time many miners will reach the same conclusion that this is =
the best path to differentiation.  If not, the miners become just hashers, =
and I believe that is a very dangerous path for Bitcoin.

Finally, I don=E2=80=99t see any compelling reason for a change in OP_RETUR=
N policy or configurability.  I speak to a lot of other miners as well and =
I don=E2=80=99t know of one a single one that feels any change is beneficia=
l to them now.


From: bitcoindev@googlegroups.com <bitcoindev@googlegroups.com> on behalf o=
f Greg Maxwell <gmaxwell@gmail.com>
Date: Tuesday, May 20, 2025 at 7:41=E2=80=AFPM
To: Antoine Poinsot <darosior@protonmail.com>
Cc: Peter Todd <pete@petertodd.org>, Bitcoin Development Mailing List <bitc=
oindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Removing OP_Return restrictions: Devil's Advo=
cate Position
> Certainly it makes sense to go for instance up to 1 KB. But what is the r=
ationale for going from 1 KB to 99 KB?

Because major miners already allow the  1KB to 99KB, limiting in relay what=
 miners easily mine only causes harm: It doesn't prevent the usage except t=
o the extent that the user prefers to not submit directly (even though web-=
centric developers generally *prefer* the APIs to the p2p network), it keep=
s miners in the business of having to adjust the software for their own nee=
ds, encourages private submission, etc.  Essentially a policy limit that mi=
ners are already bypassing is merely performative.

And then if/when someone *would* want to embed between 1kb and 99kb in outp=
uts, they'll just go ahead and do it with fake outputs to the great detrime=
nt of the system.

I would flip this argument the other way: With a small increase failing to =
actually achieve consistency with mining policy?  Why do it at all?  For th=
e benefit of some single user's narrow use that doesn't even seem to really=
 care?  I don't find that compelling.

> It is easy to relax a standardness limit, but very hard to go back

It's already been relaxed.


On Tue, May 20, 2025 at 9:54=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Devel=
opment Mailing List <bitcoindev@googlegroups.com<mailto:bitcoindev@googlegr=
oups.com>> wrote:
> With that in mind, I thought it'd be worthwhile to Devil's Advocate the c=
hange, and go through
> some technically valid arguments against it:

Let me add a steel man for another argument against the change as proposed.

# Lifting the limit *entirely* is unnecessary

Bitcoin Core's standardness rules fail to deter unwanted Bitcoin usage in t=
he presence of sustained
economic demand. They may only cause a minor and temporary inconvenience to=
 users of such
transactions until they set up a separate transaction relay network or star=
t using competing direct
submission services.

That said they can be an effective barrier to bootstrapping such demand in =
the first place. If we
take the example of inscriptions, it is not hard to imagine that if the lea=
f script size had been
limited by standardness from the get go (which may be undesirable for other=
 reasons) inscriptions
would have never really taken off.

The renewed discussion around relaxing the OP_RETURN standardness limit is =
due to newfound evidence
that people attempting to use the transaction relay network are working aro=
und the limitation by
using fake public keys in forever-unspendable outputs, which impose a much =
greater cost to node
runners than simple OP_RETURN outputs. This was illustrated by Citrea's Bit=
VM bridge design which
requires storing some data specifically in the output(s) of a transaction.

Such design only needs to store a small amount of data there. However we ne=
ed to consider forward
compatibility in changing the limit, as tailoring it to the very specific i=
nstance of Citrea may not
be a good fit for future usecases. We may not notice the publication of a f=
uture design until it is
actively being used, at which point its developers might understandably be =
reluctant to go back and
make the change. Another possibility is that developers of a future applica=
tion might just not be
interested in engaging with our negative externality concerns after the fac=
t, but would have just
used OP_RETURN outputs in the first place if there were an available option=
.

This is a valid argument for leaving some wiggle room for forward compatibi=
lity with yet-unknown
usecases. However if we think on the margin it is not a convincing for goin=
g all the way to the
maximum standard transaction size. Certainly it makes sense to go for insta=
nce up to 1 KB. But what
is the rationale for going from 1 KB to 99 KB?

It is easy to relax a standardness limit, but very hard to go back. In a se=
nse, what we want for
standardness rules is the opposite of what we want for consensus. Relaxing =
the limit on the size of
OP_RETURN outputs may enable unforeseen usages that we would not be able to=
 prevent anymore once it
is done. For this reason, we need to be conservative in picking the new lim=
it.

Lifting the limit is desirable. Lifting the limit *entirely* is unnecessary=
. Instead of the implicit
~100 KB limit, a more conservative limit of 1 KB should be preferred.



On Friday, May 2nd, 2025 at 4:03 PM, Peter Todd <pete@petertodd.org<mailto:=
pete@petertodd.org>> wrote:

>
>
> On Thu, May 01, 2025 at 10:40:19PM +0000, 'Antoine Poinsot' via Bitcoin D=
evelopment Mailing List wrote:
>
> > As i have repeatedly asked people to take conceptual discussions to the=
 mailing list, i am circling back to this thread to answer objections. I ha=
ve also written my point of view and reasons for proposing this change in a=
 blog post which goes into more details: https://antoinep.com/posts/relay_p=
olicy_drama.
>
>
> I agree with the linked write-up: the quality of debate has been
> atrocious. We've had a bunch of people who should know better, making
> points that don't make technical sense, and a bunch of passerby's
> repeating that nonsense (as well as even more nonsensical arguments).
>
> With that in mind, I thought it'd be worthwhile to Devil's Advocate the
> change, and go through some technically valid arguments against it:
>
>
> # Uninterrupted Illicit Data
>
> Credit where credit is due, this was the only reasonable argument
> against that was actually brought up on GitHub. In short, OP_Return,
> unlike other standard ways of embedding data in Bitcoin transactions,
> allows for long uninterrupted, arbitrary, messages to be embedded
> verbatim.
>
> The claimed risk is that this data could then end up peoples' hard
> drives, complicating forensics analysis in the future and potentially
> falsely incriminating people. (if you can encode your illicit data such
> that the right bytes happen to match Bitcoin opcodes, you can already
> embed it verbatim, uninterrupted, as seen by how inscriptions embed data
> in witnesses; Martin Habov=C5=A1tiak already brought this up on this very
> list).
>
> We already have this issue with dumb virus detection software. Which is
> why a few years ago code was added to XOR "encrypt" the block*.dat files
> by default (chainstate is also XOR "encrypted").
>
> The only remaining argument here is if we should go to the trouble of
> adding code to Bitcoin Core to convert existing block*.dat files to the
> XOR scheme, without re-downloading.
>
>
> # Setting Policy Expectations For a Consensus Change
>
> While it is clearly infeasible to prevent people from publishing data
> with Bitcoin's existing consensus rules, it is hypothetically possible
> to make data publication somewhat more expensive with consensus changes.
> Gregory Maxwell outlined how to do so on this mailing list years ago
> (I'm not going to dig up the reference). Basically his approach works as
> follows:
>
> 1) Limit all data in the chain to be either hash digests, signatures,
> pubkeys, or trivial values like true and false.
>
> 2) Require transactions to prove that every item of data is what it
> claims to be with, e.g. a hash digest pre-image, a valid signature (for
> a pubkey), or the fact that a signature was valid. I may be wrong. But I
> believe that with protocol changes it is possible for Lightning and
> Ark to work in this model.
>
> 3) Phase out non-compliant transactions, e.g. applying a block-weight
> multiplier that increases over time to eventually make them entirely
> unaffordable.
>
> Note that such a scheme will require massive ecosystem wide change:
> even existing address standards will need to be modified (and made
> larger) to prove that you are paying to a real address rather than
> something encoding data.
>
> Also note that even this consensus change still won't entirely
> prevent people from publishing data! No-matter what we do you can always
> grind pubkeys and hashes to set the first 4-6 bytes of them to the value
> that you want. Thus if you're pushing 32 bytes of data, encoded as 33
> bytes including the serialized length, and get 5 bytes per push, you
> have an overhead of about 6.6x. Existing data encoders have been happy
> to pay even more money than that in terms of increased fees during fee
> spikes; the difference in cost between witness space and txout space is
> already 4x, and some are happy to publish data that way anyway.
>
> A tricky thing here is upgrade paths. If we make these rules apply to
> all transactions, with any version number, we've radically limited our
> ability to upgrade the Bitcoin protocol in the future. We probably can
> make this not apply to transactions and taproot script types with
> unknown version numbers. However we'd have to do something like ensure
> it only applies to insecure transactions without signatures. And even
> then some miners will bypass this by mining that stuff anyway for a fee.
> That's pretty ugly. Maybe we can make a mechanism where miners signal
> support to allow new version numbers first, prior to an upgrade. But
> that also adds plenty of complexity.
>
> That said, if the Luke's of the world want to make a reasonable
> technical argument, come up with a reasonable scheme like the above and
> show that it has a chance of actually getting implemented.
>
> --
> https://petertodd.org<https://petertodd.org/> 'peter'[:-1]@petertodd.org<=
http://petertodd.org/>

--
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<mailto:bitcoindev%2Bunsubsc=
ribe@googlegroups.com>.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2=
M8S0jLORI2GxwNQ7qmfyM2jqQiB6JTiw%3D%40protonmail.com.
--
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<mailto:bitcoindev+unsubscri=
be@googlegroups.com>.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
CAAS2fgRyu1HKHDk_aCyHXqe%2BsgYpcApjmXx3Ps4ChpBAxeBcpw%40mail.gmail.com<http=
s://groups.google.com/d/msgid/bitcoindev/CAAS2fgRyu1HKHDk_aCyHXqe%2BsgYpcAp=
jmXx3Ps4ChpBAxeBcpw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter=
>.

--=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/=
BY5PR03MB5171FCC38022BF80272729FD969EA%40BY5PR03MB5171.namprd03.prod.outloo=
k.com.

--_000_BY5PR03MB5171FCC38022BF80272729FD969EABY5PR03MB5171namp_
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of=
fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Aptos;
	panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	font-size:10.0pt;
	font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Aptos",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;
	mso-ligatures:none;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style>
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple" style=3D"word-wrap:brea=
k-word">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">For those who don=
=E2=80=99t know me, I run a mining company called Barefoot Mining=E2=80=93 =
not the biggest mining company but not the smallest either.&nbsp; Whether I=
 would be considered major or not can be judged by others.&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p>&nbsp;</o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">That said, I sugges=
t being very careful about projecting the current behavior of major miners =
as the norm or representative of the future.&nbsp; We are extremely early i=
n the development of the mining industry
 and there is a high likelihood that over the next few years that there wil=
l a dramatic change in the list of major miners =E2=80=93 and there very we=
ll may be changes in the philosophies and priorities of these miners as wel=
l.&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p>&nbsp;</o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">I spent most of car=
eer in the personal computer industry going back to =E2=80=9986 (most notab=
ly as the CTO of Gateway) and I learned many things from my experience.&nbs=
p; One important thing was that the pace with which
 companies could rise to or fall from prominence was jaw-dropping.&nbsp; As=
suming that =E2=80=9Cmajor miners=E2=80=9D was meant to mean a group that l=
argely is comprised of pubcos, none of the major players in the mining indu=
stry have been doing it for long - with most going public
 very recently (=E2=80=9922 and =E2=80=9923).&nbsp;&nbsp; They but pups as =
companies and we=E2=80=99ve already seen a huge flameout or two.&nbsp; The =
next three to five years will likely result in a few more flameouts and som=
e large new entrants that may approach mining from a completely different
 perspective.&nbsp; A second learning I will share from my PC development d=
ays was that predicting usages and user behavior is next to impossible.&nbs=
p; The safest and most accommodating path is to give as much user optionali=
ty/configurability as possible.&nbsp; My high-level
 recommendation is to work on paths that give users more choice not less.&n=
bsp; This is applies to OP_RETURN but, even more importantly, I think it is=
 the best design direction in general.&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p>&nbsp;</o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">To offer what may b=
e a new lens in which to view miners, I=E2=80=99ll share a bit of my philos=
ophy and vision for my company. &nbsp;I view Barefoot as being in the busin=
ess of block production and I desire the maximum
 amount of flexibility/choice in making blocks.&nbsp; My strategy to develo=
p and monetize block space goes beyond just fighting for a piece of the blo=
ck reward.&nbsp; I believe that over time many miners will reach the same c=
onclusion that this is the best path to differentiation.&nbsp;
 If not, the miners become just hashers, and I believe that is a very dange=
rous path for Bitcoin. &nbsp;&nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p>&nbsp;</o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt">Finally, I don=E2=
=80=99t see any compelling reason for a change in OP_RETURN policy or confi=
gurability.&nbsp; I speak to a lot of other miners as well and I don=E2=80=
=99t know of one a single one that feels any change is beneficial
 to them now.&nbsp; &nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p>&nbsp;</o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p>&nbsp;</o:p></=
span></p>
<div id=3D"mail-editor-reference-message-container">
<div>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=
t-size:12.0pt;color:black">From:
</span></b><span style=3D"font-size:12.0pt;color:black">bitcoindev@googlegr=
oups.com &lt;bitcoindev@googlegroups.com&gt; on behalf of Greg Maxwell &lt;=
gmaxwell@gmail.com&gt;<br>
<b>Date: </b>Tuesday, May 20, 2025 at 7:41</span><span style=3D"font-size:1=
2.0pt;font-family:&quot;Arial&quot;,sans-serif;color:black">=E2=80=AF</span=
><span style=3D"font-size:12.0pt;color:black">PM<br>
<b>To: </b>Antoine Poinsot &lt;darosior@protonmail.com&gt;<br>
<b>Cc: </b>Peter Todd &lt;pete@petertodd.org&gt;, Bitcoin Development Maili=
ng List &lt;bitcoindev@googlegroups.com&gt;<br>
<b>Subject: </b>Re: [bitcoindev] Re: Removing OP_Return restrictions: Devil=
's Advocate Position<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">&gt; Certainly it m=
akes sense to go for instance up to 1 KB. But what is the rationale for goi=
ng from 1 KB to 99 KB?<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt"><o:p>&nbsp;</o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">Because major miner=
s already allow the&nbsp; 1KB to 99KB, limiting in relay what miners easily=
 mine only causes harm: It doesn't prevent the usage except to the extent t=
hat the user prefers to not submit directly
 (even though web-centric developers generally *prefer* the APIs to the p2p=
 network), it keeps miners in the business of having to adjust the software=
 for their own needs, encourages private submission, etc.&nbsp; Essentially=
 a policy limit that miners are already
 bypassing is merely performative.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt"><o:p>&nbsp;</o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">And then if/when so=
meone *would* want to embed between 1kb and 99kb in outputs, they'll just g=
o ahead and do it with fake outputs to the great detriment of the system.
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt"><o:p>&nbsp;</o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">I would flip this a=
rgument the other way: With a small increase failing to actually achieve co=
nsistency with mining policy?&nbsp; Why do it at all?&nbsp; For the benefit=
 of some single user's narrow use that doesn't
 even seem to really care?&nbsp; I don't find that compelling.<o:p></o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt"><o:p>&nbsp;</o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">&gt; It is easy to =
relax a standardness limit, but very hard to go back<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt"><o:p>&nbsp;</o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">It's already been r=
elaxed.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt"><o:p>&nbsp;</o:p></=
span></p>
</div>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt"><o:p>&nbsp;</o:p></=
span></p>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">On Tue, May 20, 202=
5 at 9:54</span><span style=3D"font-size:12.0pt;font-family:&quot;Arial&quo=
t;,sans-serif">=E2=80=AF</span><span style=3D"font-size:12.0pt">PM 'Antoine=
 Poinsot' via Bitcoin Development Mailing List &lt;<a href=3D"mailto:bitcoi=
ndev@googlegroups.com">bitcoindev@googlegroups.com</a>&gt;
 wrote:<o:p></o:p></span></p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=
n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">&gt; With that in m=
ind, I thought it'd be worthwhile to Devil's Advocate the change, and go th=
rough<br>
&gt; some technically valid arguments against it:<br>
<br>
Let me add a steel man for another argument against the change as proposed.=
<br>
<br>
# Lifting the limit *entirely* is unnecessary<br>
<br>
Bitcoin Core's standardness rules fail to deter unwanted Bitcoin usage in t=
he presence of sustained<br>
economic demand. They may only cause a minor and temporary inconvenience to=
 users of such<br>
transactions until they set up a separate transaction relay network or star=
t using competing direct<br>
submission services.<br>
<br>
That said they can be an effective barrier to bootstrapping such demand in =
the first place. If we<br>
take the example of inscriptions, it is not hard to imagine that if the lea=
f script size had been<br>
limited by standardness from the get go (which may be undesirable for other=
 reasons) inscriptions<br>
would have never really taken off.<br>
<br>
The renewed discussion around relaxing the OP_RETURN standardness limit is =
due to newfound evidence<br>
that people attempting to use the transaction relay network are working aro=
und the limitation by<br>
using fake public keys in forever-unspendable outputs, which impose a much =
greater cost to node<br>
runners than simple OP_RETURN outputs. This was illustrated by Citrea's Bit=
VM bridge design which<br>
requires storing some data specifically in the output(s) of a transaction.<=
br>
<br>
Such design only needs to store a small amount of data there. However we ne=
ed to consider forward<br>
compatibility in changing the limit, as tailoring it to the very specific i=
nstance of Citrea may not<br>
be a good fit for future usecases. We may not notice the publication of a f=
uture design until it is<br>
actively being used, at which point its developers might understandably be =
reluctant to go back and<br>
make the change. Another possibility is that developers of a future applica=
tion might just not be<br>
interested in engaging with our negative externality concerns after the fac=
t, but would have just<br>
used OP_RETURN outputs in the first place if there were an available option=
.<br>
<br>
This is a valid argument for leaving some wiggle room for forward compatibi=
lity with yet-unknown<br>
usecases. However if we think on the margin it is not a convincing for goin=
g all the way to the<br>
maximum standard transaction size. Certainly it makes sense to go for insta=
nce up to 1 KB. But what<br>
is the rationale for going from 1 KB to 99 KB?<br>
<br>
It is easy to relax a standardness limit, but very hard to go back. In a se=
nse, what we want for<br>
standardness rules is the opposite of what we want for consensus. Relaxing =
the limit on the size of<br>
OP_RETURN outputs may enable unforeseen usages that we would not be able to=
 prevent anymore once it<br>
is done. For this reason, we need to be conservative in picking the new lim=
it.<br>
<br>
Lifting the limit is desirable. Lifting the limit *entirely* is unnecessary=
. Instead of the implicit<br>
~100 KB limit, a more conservative limit of 1 KB should be preferred.<br>
<br>
<br>
<br>
On Friday, May 2nd, 2025 at 4:03 PM, Peter Todd &lt;<a href=3D"mailto:pete@=
petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt; wrote:<br>
<br>
&gt; <br>
&gt; <br>
&gt; On Thu, May 01, 2025 at 10:40:19PM +0000, 'Antoine Poinsot' via Bitcoi=
n Development Mailing List wrote:<br>
&gt; <br>
&gt; &gt; As i have repeatedly asked people to take conceptual discussions =
to the mailing list, i am circling back to this thread to answer objections=
. I have also written my point of view and reasons for proposing this chang=
e in a blog post which goes into more
 details: <a href=3D"https://antoinep.com/posts/relay_policy_drama" target=
=3D"_blank">
https://antoinep.com/posts/relay_policy_drama</a>.<br>
&gt; <br>
&gt; <br>
&gt; I agree with the linked write-up: the quality of debate has been<br>
&gt; atrocious. We've had a bunch of people who should know better, making<=
br>
&gt; points that don't make technical sense, and a bunch of passerby's<br>
&gt; repeating that nonsense (as well as even more nonsensical arguments).<=
br>
&gt; <br>
&gt; With that in mind, I thought it'd be worthwhile to Devil's Advocate th=
e<br>
&gt; change, and go through some technically valid arguments against it:<br=
>
&gt; <br>
&gt; <br>
&gt; # Uninterrupted Illicit Data<br>
&gt; <br>
&gt; Credit where credit is due, this was the only reasonable argument<br>
&gt; against that was actually brought up on GitHub. In short, OP_Return,<b=
r>
&gt; unlike other standard ways of embedding data in Bitcoin transactions,<=
br>
&gt; allows for long uninterrupted, arbitrary, messages to be embedded<br>
&gt; verbatim.<br>
&gt; <br>
&gt; The claimed risk is that this data could then end up peoples' hard<br>
&gt; drives, complicating forensics analysis in the future and potentially<=
br>
&gt; falsely incriminating people. (if you can encode your illicit data suc=
h<br>
&gt; that the right bytes happen to match Bitcoin opcodes, you can already<=
br>
&gt; embed it verbatim, uninterrupted, as seen by how inscriptions embed da=
ta<br>
&gt; in witnesses; Martin Habov=C5=A1tiak already brought this up on this v=
ery<br>
&gt; list).<br>
&gt; <br>
&gt; We already have this issue with dumb virus detection software. Which i=
s<br>
&gt; why a few years ago code was added to XOR &quot;encrypt&quot; the bloc=
k*.dat files<br>
&gt; by default (chainstate is also XOR &quot;encrypted&quot;).<br>
&gt; <br>
&gt; The only remaining argument here is if we should go to the trouble of<=
br>
&gt; adding code to Bitcoin Core to convert existing block*.dat files to th=
e<br>
&gt; XOR scheme, without re-downloading.<br>
&gt; <br>
&gt; <br>
&gt; # Setting Policy Expectations For a Consensus Change<br>
&gt; <br>
&gt; While it is clearly infeasible to prevent people from publishing data<=
br>
&gt; with Bitcoin's existing consensus rules, it is hypothetically possible=
<br>
&gt; to make data publication somewhat more expensive with consensus change=
s.<br>
&gt; Gregory Maxwell outlined how to do so on this mailing list years ago<b=
r>
&gt; (I'm not going to dig up the reference). Basically his approach works =
as<br>
&gt; follows:<br>
&gt; <br>
&gt; 1) Limit all data in the chain to be either hash digests, signatures,<=
br>
&gt; pubkeys, or trivial values like true and false.<br>
&gt; <br>
&gt; 2) Require transactions to prove that every item of data is what it<br=
>
&gt; claims to be with, e.g. a hash digest pre-image, a valid signature (fo=
r<br>
&gt; a pubkey), or the fact that a signature was valid. I may be wrong. But=
 I<br>
&gt; believe that with protocol changes it is possible for Lightning and<br=
>
&gt; Ark to work in this model.<br>
&gt; <br>
&gt; 3) Phase out non-compliant transactions, e.g. applying a block-weight<=
br>
&gt; multiplier that increases over time to eventually make them entirely<b=
r>
&gt; unaffordable.<br>
&gt; <br>
&gt; Note that such a scheme will require massive ecosystem wide change:<br=
>
&gt; even existing address standards will need to be modified (and made<br>
&gt; larger) to prove that you are paying to a real address rather than<br>
&gt; something encoding data.<br>
&gt; <br>
&gt; Also note that even this consensus change still won't entirely<br>
&gt; prevent people from publishing data! No-matter what we do you can alwa=
ys<br>
&gt; grind pubkeys and hashes to set the first 4-6 bytes of them to the val=
ue<br>
&gt; that you want. Thus if you're pushing 32 bytes of data, encoded as 33<=
br>
&gt; bytes including the serialized length, and get 5 bytes per push, you<b=
r>
&gt; have an overhead of about 6.6x. Existing data encoders have been happy=
<br>
&gt; to pay even more money than that in terms of increased fees during fee=
<br>
&gt; spikes; the difference in cost between witness space and txout space i=
s<br>
&gt; already 4x, and some are happy to publish data that way anyway.<br>
&gt; <br>
&gt; A tricky thing here is upgrade paths. If we make these rules apply to<=
br>
&gt; all transactions, with any version number, we've radically limited our=
<br>
&gt; ability to upgrade the Bitcoin protocol in the future. We probably can=
<br>
&gt; make this not apply to transactions and taproot script types with<br>
&gt; unknown version numbers. However we'd have to do something like ensure=
<br>
&gt; it only applies to insecure transactions without signatures. And even<=
br>
&gt; then some miners will bypass this by mining that stuff anyway for a fe=
e.<br>
&gt; That's pretty ugly. Maybe we can make a mechanism where miners signal<=
br>
&gt; support to allow new version numbers first, prior to an upgrade. But<b=
r>
&gt; that also adds plenty of complexity.<br>
&gt; <br>
&gt; That said, if the Luke's of the world want to make a reasonable<br>
&gt; technical argument, come up with a reasonable scheme like the above an=
d<br>
&gt; show that it has a chance of actually getting implemented.<br>
&gt; <br>
&gt; --<br>
&gt; <a href=3D"https://petertodd.org/" target=3D"_blank">https://petertodd=
.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org/" target=3D"_blank">p=
etertodd.org</a><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to
<a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" target=3D"_bla=
nk">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtn=
nsa8YWgn1A2M8S0jLORI2GxwNQ7qmfyM2jqQiB6JTiw%3D%40protonmail.com" target=3D"=
_blank">
https://groups.google.com/d/msgid/bitcoindev/7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u=
8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2M8S0jLORI2GxwNQ7qmfyM2jqQiB6JT=
iw%3D%40protonmail.com</a>.<o:p></o:p></span></p>
</blockquote>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to
<a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsub=
scribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAAS2fgRyu1HKHDk_aCyHXqe%2BsgYpcApjmXx3Ps4ChpBAxeBcpw%40mail.gma=
il.com?utm_medium=3Demail&amp;utm_source=3Dfooter">
https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRyu1HKHDk_aCyHXqe%2BsgY=
pcApjmXx3Ps4ChpBAxeBcpw%40mail.gmail.com</a>.<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/BY5PR03MB5171FCC38022BF80272729FD969EA%40BY5PR03MB5171.namprd03.=
prod.outlook.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/d/msgid/bitcoindev/BY5PR03MB5171FCC38022BF80272729FD969EA%40BY5PR03=
MB5171.namprd03.prod.outlook.com</a>.<br />

--_000_BY5PR03MB5171FCC38022BF80272729FD969EABY5PR03MB5171namp_--