From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 31 Dec 2024 06:23:42 -0800 Received: from mail-qt1-f189.google.com ([209.85.160.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tSd9p-0001Zu-DM for bitcoindev@gnusha.org; Tue, 31 Dec 2024 06:23:42 -0800 Received: by mail-qt1-f189.google.com with SMTP id d75a77b69052e-467a4f0b53bsf21618811cf.3 for ; Tue, 31 Dec 2024 06:23:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1735655015; cv=pass; d=google.com; s=arc-20240605; b=D2PlARDnHtzigb3xwtIvSodgGgR3bx+8KYKjfW8yvmF0jeDfMTcAHm6DeUVSMDTdpl V20ObNJNHaLAcVC7rpyGU0zisoWMQ/gshuQiaS//0LPZCACH5fb5VbhVWDh3v1Mktsce fe26+VCCQISErJ6P8XwX6hP61AFDTn45ShAe65vDmnJtfdG8B5tRZPOGlZ/GCSHKHf1K AFjD9k58EV6Yk+5gyaEBqX3Je6wMDDJU9aws+JQiASWjRQOtAyu7UNKYzTvBUbbVOcrc 2F0Fve4CKWp/11QvTe9Pk3E7BLSVpaIDX2HdeDuI1GBVsmlRNs09OwpbrmvEz47RuHQ4 KTWQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :from:to:date:dkim-signature; bh=ymEgdasZBgsJ3qfaEs+P2ui0680GDYMPFUF1xzvVYwY=; fh=zPkSYs7al+ynzuaR1g6X8iyRPg+2jLBd/HsqyDDJuE0=; b=cjr1SUnmB2Ars4tMtV/701MZP1ZW2azTOgr+HT2tTSpnzpK2by3IMcGmg8pXq5DUFf qtaD4YBrQm6As9ijK3/uPm4kEt+VOpzOXuZCyPcw+yQKytgEdx/lpxXNaiULcSiqkh7R +f2elqbFHKHQy/LE+1Ju6vqFlQ+qaiZesS481/9nAa4e6wwcn71GFmO9xgVQwzP9r0G9 P3Y92Fj4hCCBC8nEju/jwYh5vxc2nRcI3zTPNsjvtUC9HfHQeGxKGUaXRpmKBnC9e89C 4xTHUkZ9jMeAF2ZcX5qqIviT/T5gZLY2Vb1NwLxC/OP/6gPIvlAj7qwX1m9zsNCT3LGq vZCg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Dcia8T3h; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.19 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1735655015; x=1736259815; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:from:to:date:from:to:cc:subject:date :message-id:reply-to; bh=ymEgdasZBgsJ3qfaEs+P2ui0680GDYMPFUF1xzvVYwY=; b=rCixM0Wc+kKAA6kJADIQ30NsxTk9rDCXSRsm+AmrHh+INI+7TUCApDaQiYmzOTlfnz Js8DB1eznyCLPLJ6o0sfcbSeaSm+qldBomjrVc2YJ1IW9rahhSQcJPuRWXZBDjWqPCFv PpCSzVo4+5v0Kwbv/Jq+4XnRCJ3LF2z9GrVWF/IpzvhAaXOAgI6FgzLINZxQbR5kFcpp FGNDd7kEyI7jet0ufG36roBQU22cr/z7CSbTxe5WneowFw9OP24dgsmWb9Fc1oNTDuVt Bk4VlsY2Li9xH3glCciq2x9XuJLu1ppVdSFSzlEpWZrcaty32GznFIaMVOw0UDlrlZXk s14w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735655015; x=1736259815; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ymEgdasZBgsJ3qfaEs+P2ui0680GDYMPFUF1xzvVYwY=; b=Irkjm+B8x6FiQHFYoA1zr3T1ufpcj2QYUoCYL1HvVKSJBLaY8ti4JLd5ILLFGz1LbN SwWj+NrC8FRKIOb2AcCkB1dCgBBNjW3HgQP9WwhuLzs8Nel5KZdlONcBQDvy7nzZBfMO xIuPC+TfysKvYINBeuJ498zOEenznAkzlPo8HDapG5Rpbt/VRrfboMn2PHCucn+I2A9J kMNOtCKj/iutGc84P0omnscB8xNz191ob/c7hqzJ36VyQdNfAQwgyQXK9f5yKcfEuS4W vI/uCbWJI9fkAxcm8pgIlIf/NdIcS4VRqWr5mCzN68bbhmujrJpWZMVmROpv194C05C4 55Kg== X-Forwarded-Encrypted: i=2; AJvYcCUr2x4rWQbVLN1bPFGHh3DqXxeR3MWbKk6Hc8r72224+5of5+HQ21WEgiG4Dbxw/OSSrqE1KPCBgbtW@gnusha.org X-Gm-Message-State: AOJu0YwqcVOZzPhdBlD0wzf6zP2iDXQOXatfuDulR/jcyYFGaFMLR1TE bCuVGJ05XapxbA3jXMmsCt1xOQ70gT04R6an3j6fnOQnvRo127OL X-Google-Smtp-Source: AGHT+IGm8idcWG27gDafbVl86MJ9TOcpd4ija5ACUKtaJ7hUSPAyKwL0f0BPNIzHFrU35Q15P+7RWw== X-Received: by 2002:a05:622a:587:b0:467:7cda:9388 with SMTP id d75a77b69052e-46a4a8f663emr584654481cf.31.1735655014813; Tue, 31 Dec 2024 06:23:34 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:ac8:4709:0:b0:466:98fc:1e3f with SMTP id d75a77b69052e-46a3b15d199ls19928061cf.1.-pod-prod-04-us; Tue, 31 Dec 2024 06:23:32 -0800 (PST) X-Received: by 2002:a05:620a:28c7:b0:7b1:4fba:b02e with SMTP id af79cd13be357-7b9ba6efacfmr5978254885a.12.1735655012049; Tue, 31 Dec 2024 06:23:32 -0800 (PST) Received: by 2002:a05:620a:1258:b0:7b6:d72a:7c26 with SMTP id af79cd13be357-7b9ab36d14ems85a; Tue, 31 Dec 2024 05:17:33 -0800 (PST) X-Received: by 2002:a05:600c:a0a:b0:434:a04d:1670 with SMTP id 5b1f17b1804b1-436678f5775mr376805225e9.0.1735651052019; Tue, 31 Dec 2024 05:17:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1735651052; cv=none; d=google.com; s=arc-20240605; b=F9W36Tz7gRaTyL4kWu3pOErBZYQYaXbCwap8378PWzXECltHXd43dUC3cj6YP6+9F8 9Wf1u7Rj3Vx8QbXaWSxZDHPS2q8CQcKDS2B/S7f8qJtN58c4UhuWMR3IJwjpBQ2Wprii T3Ew8jvSjdlDK/umNowdERbGGHhG4HSUE9+IcHlwC1t5foNrHaLl51Gk/tkeMvqSNMUV ETiu7wqDtoaa+M2HYLZ0vZKX6cgJ3MI4piHmbLTvh5Sqrg9p1RyJdkFReJfhVHT0pN0K Vp83BLN9ODYJ6lbqe3Mhr8zlfVv7hQQtrmNoomN6/oJjkXwFwbwGMuIVumBmGGO4+iva iP0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:from:to:date:dkim-signature; bh=RxAHGZgLgc26tkSd64BpgHcHirC0iM4psdfOrqh1IFI=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=KfYa9W3jaEruqXqz/cho417ozwXmDAkUuSF78+VYtw0VlEJbDMLKec3BnUH1jAuv0n ugWBkepkVtOAhwR/+D2qmXgKOJdsRevrh5W6l3FtgxoVRrHYzqSYZJR6E18/T8oHobzl KjqjYWpgWQF2kZHyvDGxMQXxNotWo/GORxaL+65008eSpXr+bQGmKhbiNSf4D6heJ5jS 0plrjSOfhjGXcjT94ofnzpWV8YsM/j+r+nXR5TUpZV4kopfrouYkeGXrHPAeoH8fMt3G kvdhLKrWjREnTp97V/SF36zGLe7zP/5aW7VqevDC7aAK0AMUOM6R9ZoRAAQIdmo8d5xT 4IIg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Dcia8T3h; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.19 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch. [185.70.43.19]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4368eaa584fsi9419585e9.0.2024.12.31.05.17.31 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Dec 2024 05:17:31 -0800 (PST) Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.19 as permitted sender) client-ip=185.70.43.19; Date: Tue, 31 Dec 2024 13:17:26 +0000 To: Bitcoin Development Mailing List From: "'moonsettler' via Bitcoin Development Mailing List" Subject: Re: [bitcoindev] Summary: Covenants Support - Bitcoin Wiki Message-ID: In-Reply-To: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com> References: <38a6f252-afe9-4155-a341-11a42a9a9007n@googlegroups.com> Feedback-ID: 38540639:user:proton X-Pm-Message-ID: d9e884b6315b37dd14bd6387449b4864620e4df7 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: moonsettler@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=Dcia8T3h; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.19 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: moonsettler Reply-To: moonsettler 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: -1.0 (-) Hi All, One thing I would like to make clear before people get the wrong idea and t= hink this is some form of voting, OP_INTERNALKEY and OP_PARCOMMIT is part o= f LNhance and will be part of the activation client we release soon. The on= ly way to change that is to demonstrate actual harm. You liking something e= lse more, is your problem. What you can do about it, is write your activati= on client and try to gain consensus on that. There are plenty of version bi= ts available. Replacing PAIRCOMMIT with CAT would be really easy, but while= CAT is indeed very popular and has a wide support base it is also strongly= opposed by many who did not choose to participate. I'm not convinced that = this table represents actual developer, let alone ecosystem consensus. If y= ou decide you want to run an alternative activation effort with CAT instead= of PAIRCOMMIT feel free to fork our repo! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OP_PARCOMMIT=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > OP_PARCOMMIT seems to be controversial at this moment. I strongly disagree. In my book that's not what controversial means. Litera= lly nobody managed to come up with a single use case anyone worth noting ob= jects to for PAIRCOMMIT. Also inclined to ignore the "No" from those that p= refer CAT as plain trolling. This BIP is young, there is a clear correlatio= n between the age of the proposals and their support with the sole exceptio= n of APO. > Adds unnecessary complexity That's a subjective value judgement it enables something that was no possib= le before which is interacting with Merkle trees and multi-element commitme= nts in script. PAIRCOMMIT is not significantly more complicated than CAT, a= nd in a lot of actual use cases CAT was desired for it's more complex and r= esource intensive to safely use CAT than PAIRCOMMIT due to witness malleabi= lity. > Not convinced it is impossible that there is no way to simulate CAT with = PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than CAT. This is sufficiently addressed in the BIP. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OP_VAULT =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > No demand for vaults. It's safe to completely ignore that "argument". BR, moonsettler On Tuesday, December 31st, 2024 at 9:23 AM, /dev /fd0 wrote: > Hi Bitcoin Developers, >=20 > I had shared covenants support wiki page link here on [mailing list][1] i= n the last week of November 2024. Multiple changes were made based on the f= eedback: >=20 > - Removed 'community support' from 'No'. Rephrased definitions for 'Prefe= r' and 'Evaluating'. > - Added LNHANCE category for a combination of opcodes. > - Added links for BIP drafts and a column for 'rationale'. > - Created a separate table for evaluations without a rationale. >=20 > Murch and Gloria shared their feedback in the bitcoin optech [podcast 333= ][2]. I have started working on a [page][3] that lists use cases, prototype= links and primitives used. We can still add more use cases in it. This lis= t does not include use cases enabled by [OP_CHECKSIGFROMSTACK][4] alone or = in combination with other opcodes like [LN SYMMETRY][5]. >=20 > I had verified each entry to avoid spam and fake evaluations. Rearden was= assigned moderator permissions on 8 December 2024 by Theymos to help me wi= th the moderations. Some edits have been approved by other moderators. >=20 > Some insights from the table that could help developers working on differ= ent covenant proposals: >=20 > 1. Multiple ways to achieve LN symmetry were discovered. SIGHASH_APO lack= s interest among developers, contrary to the belief prior to this exercise. > 2. OP_CHECKSIGFROMSTACK has unanimous support and is a part of multiple c= ovenant proposals. > 3. OP_PAIRCOMMIT, OP_INTERNALKEY and OP_CHECKCONTRACTVERIFY are not revie= wed by enough developers. OP_PARCOMMIT seems to be controversial at this mo= ment. >=20 > Objections: >=20 > ``` > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > SIGHASH_APO > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > LN SYMMETRY is possible with combination of a few opcodes which is more e= fficient. Its not the best option for covenants and cannot be used to impro= ve Ark. Some developers prefer opcodes and not sighash flags. >=20 > Seems to be the result of an attempt to fix signatures to make them work = for a specific use-case, but the end-result is hard-to-reason (for me) and = not flexible. In general, SIGHASH flags are an encoding of specific predica= tes on the transaction, and I think the Script is better suited to carry th= e predicate. There is no interesting SIGHASH flag that couldn't be function= ally simulated by introspection + CHECKSIGFROMSTACK (or other Script-based = approaches), and that seems to me a much cleaner and ergonomic way to achie= ve the same goals. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > OP_TXHASH > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > More expressive, many flag configurations, untested and undesirable use c= ases. Unaddressed comments in the BIP and the delay doesn't make sense beca= use OP_CHECKTEMPLATEVERIFY can be upgraded later to achieve the same thing.= Makes hash caching complex, potentially opening up DoS vectors or quadrati= c sighash. >=20 > Most templates you'd obtain with various combinations of parameters are m= eaningless. It implements state-carrying UTXOs in a very dirty way: adding = additional inputs/outputs with no other meaning than "storing some state". = This is ugly, inefficient, and bloats the UTXO set - and it definitely will= happen if TXHASH is enabled without also enabling a clean way to carry sta= te. >=20 > Follow up with an upgrade to OP_CHECKTEMPLATEVERIFY can fine tune it to w= hat people are actually using covenants for, instead of prematurely optimiz= ing everything with no data. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > OP_VAULT > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > No demand for vaults. Customized for a specific use case. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > OP_CAT > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Can be used for various complex scripts including undesirable use cases (= DEX, AMM and Hashrate Escrow). Enables granular transaction introspection t= hrough abuse of schnorr signatures and OP_CHECKSIG. Can be used for interes= ting use cases but alone does it poorly and inefficiently. >=20 > People can and will litter the chain with inefficient/ugly Scripts if act= ivated alone. Since it happens to enable generic introspection by accident,= and therefore an ugly version of state-carrying UTXOs, it shouldn't be ena= bled without more ergonomic opcodes for those use cases. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > OP_INTERNALKEY > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > There are 3 'No' in the table, I couldn't find anything relevant in the r= ationales. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > OP_PAIRCOMMIT > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Adds unnecessary complexity, redundant if OP_CAT is activated in future a= nd added for specific use case. LN SYMMETRY is possible without this opcode= . It does not compose with anything that involves transaction introspection= due to its specified tagged hash. Some developers prefer OP_CAT. >=20 > Not convinced it is impossible that there is no way to simulate CAT with = PAIRCOMMIT, nor confident how much less powerful PAIRCOMMIT is than CAT. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > OP_CHECKTEMPLATEVERIFY > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Limited in scope and not recursive. > ``` >=20 > I have tried my best to remain unbiased in writing this summary and appro= ving edits. There are a few things that I want to share and it could be a r= esult of the aggressive marketing: >=20 > - A spammer had edited the table to remove all evaluations except in favo= r of OP_CAT and it was rejected. > - [Rationale][6] added by Aaron (sCrypt) does not mention anything about = other opcodes and SIGHASH_APO. It is only focused on OP_CAT however evaluat= ions exist in the table. > - I [requested][7] Udev (CatSwap) to add details about evaluation of othe= r opcodes and SIGHASH_APO. > - Last [edit][8] by Roujiamo (bitdollar) has a rationale with incorrect s= ignet stats and seems to be rephrased version of another rationale. Evaluat= ion had 'weak' for OP_CTV before adding the rationale. > - An edit with duplicate rationale (in support of OP_CAT) was rejected be= cause sharing the link for a rationale submitted by other developer adds no= value in the table. >=20 > Evaluations without a rationale have some 'No' in different cells. Althou= gh none of them are backed by a rationale so cannot be considered for conse= nsus discussion. The table is still updated regularly so you may see some o= f them with a rationale in 2025. Any suggestions to help achieve technical = consensus are most welcome. >=20 > What's next? >=20 > - More rationales in the table > - Discuss objections on mailing list (if any) > - Workshops > - Add a table for economic nodes and their opinion > - Build activation client and discuss parameters >=20 > Finally, I would thank all the developers who added their evaluations in = the table and everyone who shared updates on twitter. It was a coordinated = effort to reach some technical consensus. You can read all the rationales i= n detail to understand different perspectives and reasons to support a comb= ination of opcodes over others. >=20 > [1]: https://groups.google.com/g/bitcoindev/c/fdxkE1Al4TI/m/CeEuls2IAQAJ > [2]: https://bitcoinops.org/en/podcast/2024/12/17/ > [3]: https://en.bitcoin.it/wiki/Covenants_Uses > [4]: https://github.com/bitcoin/bips/blob/master/bip-0348.md > [5]: https://gist.github.com/Ademan/4a14614fa850511d63a5b2a9b5104cb7 > [6]: https://gist.github.com/gitzhou/dc92c41db1987db16fe665c26bc56dd9 > [7]: https://gist.github.com/udevswap/b768d20d62549922b9e72428ef9eb608?pe= rmalink_comment_id=3D5359072#gistcomment-5359072 > [8]: https://en.bitcoin.it/w/index.php?title=3DCovenants_support&diff=3Dp= rev&oldid=3D70520 >=20 > /dev/fd0 > floppy disk guy >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/38a6f252-afe9-4155-a341-11a42a9a9007n%40googlegroups.com. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= rp07_AsZrGYA3kFwZweIhzZVonmcuQktAz9r51MgKvrG101_T9NBTTMCFK_q3bMzIH0-QzfFtzC= 6uJGEKOIMi6Hl6qwbDtMWXXV2frBWXac%3D%40protonmail.com.