diff options
| author | Bob Burnett <bob.burnett@barefootmining.com> | 2025-05-21 02:10:13 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2025-05-20 19:13:39 -0700 |
| commit | 03ebe86a97be67ebfd718429aa9c0dfb1bff156d (patch) | |
| tree | 155ae2dc80dea53ad9305d9f6fe1904a2b071deb | |
| parent | af6b77323b680037a786bc5ba0e93ee90a48775e (diff) | |
| download | pi-bitcoindev-03ebe86a97be67ebfd718429aa9c0dfb1bff156d.tar.gz pi-bitcoindev-03ebe86a97be67ebfd718429aa9c0dfb1bff156d.zip | |
Re: [bitcoindev] Re: Removing OP_Return restrictions: Devil's Advocate Position
| -rw-r--r-- | 97/8775d71722b2328e0153daff74a0d70bd02d59 | 1038 |
1 files changed, 1038 insertions, 0 deletions
diff --git a/97/8775d71722b2328e0153daff74a0d70bd02d59 b/97/8775d71722b2328e0153daff74a0d70bd02d59 new file mode 100644 index 000000000..ca558057a --- /dev/null +++ b/97/8775d71722b2328e0153daff74a0d70bd02d59 @@ -0,0 +1,1038 @@ +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. Whether I= + would be considered major or not can be judged by others. +<o:p></o:p></span></p> +<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p> </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. 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. +<o:p></o:p></span></p> +<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p> </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. 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). 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 in a few more flameouts and som= +e large new entrants that may approach mining from a completely different + perspective. 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. 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. +<o:p></o:p></span></p> +<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p> </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. I view Barefoot as being in the busin= +ess of block production and I desire the maximum + amount of flexibility/choice in making blocks. My strategy to develo= +p and monetize block space goes beyond just fighting for a piece of the blo= +ck reward. I believe that over time many miners will reach the same c= +onclusion that this is the best path to differentiation. + If not, the miners become just hashers, and I believe that is a very dange= +rous path for Bitcoin. <o:p></o:p></span></p> +<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p> </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. 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. <o:p></o:p></span></p> +<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p> </o:p></= +span></p> +<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><o:p> </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 <bitcoindev@googlegroups.com> on behalf of Greg Maxwell <= +gmaxwell@gmail.com><br> +<b>Date: </b>Tuesday, May 20, 2025 at 7:41</span><span style=3D"font-size:1= +2.0pt;font-family:"Arial",sans-serif;color:black">=E2=80=AF</span= +><span style=3D"font-size:12.0pt;color:black">PM<br> +<b>To: </b>Antoine Poinsot <darosior@protonmail.com><br> +<b>Cc: </b>Peter Todd <pete@petertodd.org>, Bitcoin Development Maili= +ng List <bitcoindev@googlegroups.com><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">> 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> </o:p></= +span></p> +</div> +<div> +<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">Because major miner= +s already allow the 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. 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> </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> </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? Why do it at all? For the benefit= + of some single user's narrow use that doesn't + even seem to really care? 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> </o:p></= +span></p> +</div> +<div> +<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">> 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> </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> </o:p></= +span></p> +</div> +</div> +<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt"><o:p> </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:"Arial&quo= +t;,sans-serif">=E2=80=AF</span><span style=3D"font-size:12.0pt">PM 'Antoine= + Poinsot' via Bitcoin Development Mailing List <<a href=3D"mailto:bitcoi= +ndev@googlegroups.com">bitcoindev@googlegroups.com</a>> + 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">> With that in m= +ind, I thought it'd be worthwhile to Devil's Advocate the change, and go th= +rough<br> +> 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 <<a href=3D"mailto:pete@= +petertodd.org" target=3D"_blank">pete@petertodd.org</a>> wrote:<br> +<br> +> <br> +> <br> +> On Thu, May 01, 2025 at 10:40:19PM +0000, 'Antoine Poinsot' via Bitcoi= +n Development Mailing List wrote:<br> +> <br> +> > 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> +> <br> +> <br> +> I agree with the linked write-up: the quality of debate has been<br> +> atrocious. We've had a bunch of people who should know better, making<= +br> +> points that don't make technical sense, and a bunch of passerby's<br> +> repeating that nonsense (as well as even more nonsensical arguments).<= +br> +> <br> +> With that in mind, I thought it'd be worthwhile to Devil's Advocate th= +e<br> +> change, and go through some technically valid arguments against it:<br= +> +> <br> +> <br> +> # Uninterrupted Illicit Data<br> +> <br> +> Credit where credit is due, this was the only reasonable argument<br> +> against that was actually brought up on GitHub. In short, OP_Return,<b= +r> +> unlike other standard ways of embedding data in Bitcoin transactions,<= +br> +> allows for long uninterrupted, arbitrary, messages to be embedded<br> +> verbatim.<br> +> <br> +> The claimed risk is that this data could then end up peoples' hard<br> +> drives, complicating forensics analysis in the future and potentially<= +br> +> falsely incriminating people. (if you can encode your illicit data suc= +h<br> +> that the right bytes happen to match Bitcoin opcodes, you can already<= +br> +> embed it verbatim, uninterrupted, as seen by how inscriptions embed da= +ta<br> +> in witnesses; Martin Habov=C5=A1tiak already brought this up on this v= +ery<br> +> list).<br> +> <br> +> We already have this issue with dumb virus detection software. Which i= +s<br> +> why a few years ago code was added to XOR "encrypt" the bloc= +k*.dat files<br> +> by default (chainstate is also XOR "encrypted").<br> +> <br> +> The only remaining argument here is if we should go to the trouble of<= +br> +> adding code to Bitcoin Core to convert existing block*.dat files to th= +e<br> +> XOR scheme, without re-downloading.<br> +> <br> +> <br> +> # Setting Policy Expectations For a Consensus Change<br> +> <br> +> While it is clearly infeasible to prevent people from publishing data<= +br> +> with Bitcoin's existing consensus rules, it is hypothetically possible= +<br> +> to make data publication somewhat more expensive with consensus change= +s.<br> +> Gregory Maxwell outlined how to do so on this mailing list years ago<b= +r> +> (I'm not going to dig up the reference). Basically his approach works = +as<br> +> follows:<br> +> <br> +> 1) Limit all data in the chain to be either hash digests, signatures,<= +br> +> pubkeys, or trivial values like true and false.<br> +> <br> +> 2) Require transactions to prove that every item of data is what it<br= +> +> claims to be with, e.g. a hash digest pre-image, a valid signature (fo= +r<br> +> a pubkey), or the fact that a signature was valid. I may be wrong. But= + I<br> +> believe that with protocol changes it is possible for Lightning and<br= +> +> Ark to work in this model.<br> +> <br> +> 3) Phase out non-compliant transactions, e.g. applying a block-weight<= +br> +> multiplier that increases over time to eventually make them entirely<b= +r> +> unaffordable.<br> +> <br> +> Note that such a scheme will require massive ecosystem wide change:<br= +> +> even existing address standards will need to be modified (and made<br> +> larger) to prove that you are paying to a real address rather than<br> +> something encoding data.<br> +> <br> +> Also note that even this consensus change still won't entirely<br> +> prevent people from publishing data! No-matter what we do you can alwa= +ys<br> +> grind pubkeys and hashes to set the first 4-6 bytes of them to the val= +ue<br> +> that you want. Thus if you're pushing 32 bytes of data, encoded as 33<= +br> +> bytes including the serialized length, and get 5 bytes per push, you<b= +r> +> have an overhead of about 6.6x. Existing data encoders have been happy= +<br> +> to pay even more money than that in terms of increased fees during fee= +<br> +> spikes; the difference in cost between witness space and txout space i= +s<br> +> already 4x, and some are happy to publish data that way anyway.<br> +> <br> +> A tricky thing here is upgrade paths. If we make these rules apply to<= +br> +> all transactions, with any version number, we've radically limited our= +<br> +> ability to upgrade the Bitcoin protocol in the future. We probably can= +<br> +> make this not apply to transactions and taproot script types with<br> +> unknown version numbers. However we'd have to do something like ensure= +<br> +> it only applies to insecure transactions without signatures. And even<= +br> +> then some miners will bypass this by mining that stuff anyway for a fe= +e.<br> +> That's pretty ugly. Maybe we can make a mechanism where miners signal<= +br> +> support to allow new version numbers first, prior to an upgrade. But<b= +r> +> that also adds plenty of complexity.<br> +> <br> +> That said, if the Luke's of the world want to make a reasonable<br> +> technical argument, come up with a reasonable scheme like the above an= +d<br> +> show that it has a chance of actually getting implemented.<br> +> <br> +> --<br> +> <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" 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" 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&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" 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_-- + |