From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 To: Greg Maxwell , Antoine Poinsot CC: Peter Todd , Bitcoin Development Mailing List 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: References: <7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2M8S0jLORI2GxwNQ7qmfyM2jqQiB6JTiw=@protonmail.com> In-Reply-To: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 on behalf o= f Greg Maxwell Date: Tuesday, May 20, 2025 at 7:41=E2=80=AFPM To: Antoine Poinsot Cc: Peter Todd , Bitcoin Development Mailing List 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 > 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 > 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 '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. 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. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CAAS2fgRyu1HKHDk_aCyHXqe%2BsgYpcApjmXx3Ps4ChpBAxeBcpw%40mail.gmail.com. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= BY5PR03MB5171FCC38022BF80272729FD969EA%40BY5PR03MB5171.namprd03.prod.outloo= k.com. --_000_BY5PR03MB5171FCC38022BF80272729FD969EABY5PR03MB5171namp_ Content-Type: text/html; 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 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. 

 

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. 

 

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.   

 

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.   

 

 

From: bitcoindev@googlegr= oups.com <bitcoindev@googlegroups.com> on behalf of 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 Maili= ng List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Removing OP_Return restrictions: Devil= 's Advocate Position

> 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?

 

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.

 

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.

 

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.

 

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

 

It's already been r= elaxed.

 

 

On Tue, May 20, 202= 5 at 9:54=E2=80=AFPM 'Antoine= Poinsot' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:

> With that in m= ind, I thought it'd be worthwhile to Devil's Advocate the change, and go th= rough
> 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.<= br>
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> wrote:

>
>
> On Thu, May 01, 2025 at 10:40:19PM +0000, 'Antoine Poinsot' via Bitcoi= n Development 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 have also written my point of view and reasons for proposing this chang= e in a blog post which goes into more details: https://antoinep.com/posts/relay_policy_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<= br> > points that don't make technical sense, and a bunch of passerby's
> repeating that nonsense (as well as even more nonsensical arguments).<= br> >
> With that in mind, I thought it'd be worthwhile to Devil's Advocate th= e
> 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,<= br> > 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<= br> > falsely incriminating people. (if you can encode your illicit data suc= h
> 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
> in witnesses; Martin Habov=C5=A1tiak already brought this up on this v= ery
> list).
>
> We already have this issue with dumb virus detection software. Which i= s
> why a few years ago code was added to XOR "encrypt" the bloc= k*.dat files
> by default (chainstate is also XOR "encrypted").
>
> 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
> XOR scheme, without re-downloading.
>
>
> # Setting Policy Expectations For a Consensus Change
>
> While it is clearly infeasible to prevent people from publishing data<= br> > with Bitcoin's existing consensus rules, it is hypothetically possible=
> to make data publication somewhat more expensive with consensus change= s.
> 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,<= br> > 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 (fo= r
> 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<= br> > 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 alwa= ys
> grind pubkeys and hashes to set the first 4-6 bytes of them to the val= ue
> 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 > 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 i= s
> 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<= br> > 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<= br> > then some miners will bypass this by mining that stuff anyway for a fe= e.
> 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 > 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 an= d
> show that it has a chance of actually getting implemented.
>
> --
> https://petertodd= .org 'peter'[:-1]@p= etertodd.org

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u= 8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2M8S0jLORI2GxwNQ7qmfyM2jqQiB6JT= iw%3D%40protonmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsub= scribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRyu1HKHDk_aCyHXqe%2BsgY= pcApjmXx3Ps4ChpBAxeBcpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.goo= gle.com/d/msgid/bitcoindev/BY5PR03MB5171FCC38022BF80272729FD969EA%40BY5PR03= MB5171.namprd03.prod.outlook.com.
--_000_BY5PR03MB5171FCC38022BF80272729FD969EABY5PR03MB5171namp_--