From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 26 Jun 2026 02:41:53 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wd34K-0000k4-N0 for bitcoindev@gnusha.org; Fri, 26 Jun 2026 02:41:53 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-446c8d2bbf8sf920533fac.2 for ; Fri, 26 Jun 2026 02:41:52 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1782466906; cv=pass; d=google.com; s=arc-20260327; b=F3j0MdCc5tGMwXFXEv+UnsF14RB0ZzWnjsBNjir+ZI1AD6ztn9+reNtY+2mpNp4dtn 7gMe7wpM2kEHmSXabrZu6o1xe0N3hHbBaAUlP+bb3P+bmtBid1t7T9MB2oq6H7beTqB3 4o/iNsiw+dgZN8W8A2+1UTaF31SGhwgvmTJnxbhaBgnaV0hKEpgi4wm7AFDQRR0KcigN kR8XAoCW3Hy8GuXvFwiL6YV9mTCoSk1vkBvFpmHKvP49ZrcqCZymQWEsMUeQVL3WRUqu B+uMJavIjkrj+88KJspHPyU737YyvqWyYdr854jgXEmBIKtN2jS9RMYRAUgzoPbOMbVZ +1Ug== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding:cc:to :subject:message-id:date:from:in-reply-to:references:mime-version :sender:dkim-signature:dkim-signature; bh=vCUZDHI1Q8NjD7C2REt7/Q7YdQEq+s503d1GuZhu8PI=; fh=muU6fodEoQX1Vjx9pVvneFdbvt+PLkh/m5SyU4PH9OM=; b=KSwItQDIiA90aozNFnlV7SfY047fOYQEKiK4KAqn48lhWlZ7U5xjvWRUdwwDLivbfo cZgB9F8/IjCxP2VSuG5LmteUSVWJvslEYdLE0lecGpfw1yEzg+BDG52w7CE2E9PwerCR bOQllaUvySkaR7VYqHanadYfA8ntVnqS8dizOendO+RKvls0AYvyUFaXTjd82A1Yv528 WcGYcWwnyq6zmYT2Opp+Oky3vNIVZsq1lb+2/LXMXg7Dbbnd7Qm1XNzao3YcqUjIAA2I pw3YgWupdQicqaNz02FUdVbbvQ09Aer9T0f6E8HQjp5Vr2HL7JmiDQzSdXXdm0nTGu9i FQ+Q==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=ovXHIDmr; arc=pass (i=1); spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::1331 as permitted sender) smtp.mailfrom=bnagaev@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1782466906; x=1783071706; 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:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:sender :from:to:cc:subject:date:message-id:reply-to; bh=vCUZDHI1Q8NjD7C2REt7/Q7YdQEq+s503d1GuZhu8PI=; b=C8592whI2zL0a0nZGlkwkwjISbrv+AvCcSFTeK+cbaroeGtYYq1Kwt6O7ixtJoMk0G ugMm8jgpATM5EPBQ1qhFG61QwnJipTn84n8mjAm6fv/5zTPuMBk2aXIdpSEjkIcTiywK zybkZEku255Y1u0ZcWtk2m9mEfHeUtOmXyAdC5HliPB6k3By/8h06FlFRDE0GeMaT+wK MdzKj/8ZdxEcr8ID3D+97opcKSY/MD+84XJ2Wpqgjp03UCBtp0lA7U+EB9DBlBTuzqVg JHt1IlbnxucZZLpQ1/j/l5KDfD98RKheCbCQ6buelGA5fJSKQ2ZYX6gBzwbD38wWOspS zDJw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782466906; x=1783071706; 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:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=vCUZDHI1Q8NjD7C2REt7/Q7YdQEq+s503d1GuZhu8PI=; b=moV/eyG+6JTo0qersSDe5dZYEysyDpLpJFR2l3cIk2UcORqjlGGuk+P/cqNFXIeHt3 f0OqS7ZTv9mylBCnsCmiOALU3kNu7xlYOthO4/i2ZD5KJt6CI2s/d5t5qqYaV2lWmYYd ZtOcttJYNe1Jliq6udvOVprsW1+r0YFlmGZOdrw8tpL2Fkytd58DI6nRA4rk7nl3ZwLH EmQkCyzdEHX2dEh7jJa5shoGgoE4ft07/5wNZiuKodLvD4WRzz2+/nFyImvGprKFCmKc RdG/IBdSHVSXkoICLORFZ86Dp8uA6Blnd2qVngkBMNLVF30GwSTI02szMYt0sqnLsvJ9 FB0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782466906; x=1783071706; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:x-gm-gg :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=vCUZDHI1Q8NjD7C2REt7/Q7YdQEq+s503d1GuZhu8PI=; b=Lg36T7w4HJ4VROYms3wXcJrb1rOZI5rT4xnGuyjtIA+JmdGSpTNCuRt/SKTN2+dRVh ZOewNGnbr4HvsKv/1QzVKwB317t3qEP0ytulmSNhRHVyhvGJEukjLaPrZGfFOI6JM5JS alCsqygVDVxZLvtMREE3KQfZx+HsqHu5HixaO+4mWJ8r+Du96rX1KjOaGWRj1jNUT2Ob pFerBWXt7OYXPV1+vEQqMNVn8M5tqJvfHyljrVULgPUtdFPKSPfPDnjJkIyHq1MRbrDk msisVZK5CjW/gWmq4O6/asgCh1NINcm90Ubw7ce9ChRM0BzAOOYW6vb+guelNyz0D2me mc3A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AHgh+RrnxW2T4xR0ABTcNGHiV305A3rCfXpqGvM50rFVu0lha/WVWPzUg952j7Y/QWPem+bMxsTj7//CKhu0@gnusha.org X-Gm-Message-State: AOJu0YwGqChc6bWFVwCOa6mo2aDWKvbLf1GyYBm3x0bJ1NZrmJ/seZtC P+atk8LzYyiSYKcGbRk8YfkvVYprV2nK+fZzpsPIi82wahNKXl2Gyugw X-Received: by 2002:a05:6870:21c8:b0:447:1ceb:52d3 with SMTP id 586e51a60fabf-44811d14547mr5122033fac.31.1782466906110; Fri, 26 Jun 2026 02:41:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUdibZ7s5i10pj3ro/rPcPl+WrN86EI+ApnBJkrHvfHThw==" Received: by 2002:a05:6871:339a:b0:446:c845:deee with SMTP id 586e51a60fabf-446dfbc5400ls7148358fac.2.-pod-prod-01-us; Fri, 26 Jun 2026 02:41:41 -0700 (PDT) X-Received: by 2002:a05:6808:4fcb:b0:491:eac0:d56b with SMTP id 5614622812f47-4921890a19amr5524285b6e.38.1782466901141; Fri, 26 Jun 2026 02:41:41 -0700 (PDT) Received: by 2002:a05:6808:8198:20b0:487:5060:f86f with SMTP id 5614622812f47-4934a5ce1a0msb6e; Thu, 25 Jun 2026 20:41:33 -0700 (PDT) X-Received: by 2002:a05:6820:1985:b0:69d:fee4:2381 with SMTP id 006d021491bc7-6a13525d065mr4127862eaf.55.1782445293023; Thu, 25 Jun 2026 20:41:33 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1782445293; cv=pass; d=google.com; s=arc-20260327; b=j0QRyzpgKaMjjlDCaTbaJ6nwGU5MhHxMOmF0g6MV+TGo7hSWjQQLiCwQCZJZ3DZxVh nreBeJg5fNPssKTuKm3gpE+YBf6N60/a/4bNO4wLDSBJvx2dqXCTuTgtky8mWnflz83o Vzcj5BD+45+MZqbLmuIEsg1nlCJrlnZnwXyDFGsrdbBZ0JP5oAlrQgoOiGj8cXMylcFz l62HXh81hOlxU3m3MhV6gcgQ9cHkjv4Xx/8Y609+cjT6O0EpMLkO1AD9s9MVgf7VmrTw zzyTzwhxPNb4xtwV1amHeqMKLMzCrBb/uUJc3w+rqMmMtCDOBriCN6w4xy6ZQrnIemZ/ yxNA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=3iquS/BQhEPizIcRYBOl+M2gQlHufJ06t9EVXI6qudk=; fh=dRl5MJeON1RwI+/xO4/cP/Y3U38+pgB9/4rd/p1o9tg=; b=Xl9OpU9f8PF3NSE5af0X3B0pcngojXCbfIUokTPw4YPU6CEy6ALFc7mibrjiIgLwuK 6qUdaxP1uMusxhBE0OPgqisnEp6OedcovX4DGKGtxpPaOvLykgihRu48liJU23qaHByT a0neLxdTkegcht4EDiXdzjjtt6iVK4D2qIoqv/KA/SVrHosX0hyoehi8rPgLi1bmZDiO IV0u2or8kgkST8dkYccS95LZF3fTFg8XG4q5npy5apV6xlD0gHsj58OIYNX/p0GULFb+ aHAJyjBC47pGsSWOUWu++s0LromXbCV44o4EhN8IQDiHCpbl+pji6FQ/I/UPWIwJ1efr kAOw==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=ovXHIDmr; arc=pass (i=1); spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::1331 as permitted sender) smtp.mailfrom=bnagaev@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-dy1-x1331.google.com (mail-dy1-x1331.google.com. [2607:f8b0:4864:20::1331]) by gmr-mx.google.com with ESMTPS id 006d021491bc7-6a1415002a8si34774eaf.4.2026.06.25.20.41.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2026 20:41:33 -0700 (PDT) Received-SPF: pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::1331 as permitted sender) client-ip=2607:f8b0:4864:20::1331; Received: by mail-dy1-x1331.google.com with SMTP id 5a478bee46e88-30bf8b2bd20so1302695eec.0 for ; Thu, 25 Jun 2026 20:41:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782445292; cv=none; d=google.com; s=arc-20260327; b=qrHjX5K2KBeSlug/KZ7x6hjRQbIIGSRw+KxUBW6OF6SgmuOPMa748agMWKLSmkjPX4 29txTJJyh3utBa+E0xO6WLn1oFLaVU9KBUKrbGnwqh3XQaQH5LH+cb6c1kDuocmIXDI9 zAt0wcEmDS0vsMfKnQcB9PxPjQMII5Hfba7IA2zq/3QyDzVO9odUFzruyVgxZTrsdhCi B0m0pwYk4wgquK29JhN65yVvh3M+rjIQ5ZwcwkEE5b5YzpT1YnpX55N/E4D3DIQtcZuA LqrIgXysKP5WO76FkLdDANiQ2ZWzHSyh/9czRqF+NjqhS4Qalq2ZzB3Nw3PYMC8j7KEE CmlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=3iquS/BQhEPizIcRYBOl+M2gQlHufJ06t9EVXI6qudk=; fh=dRl5MJeON1RwI+/xO4/cP/Y3U38+pgB9/4rd/p1o9tg=; b=Ny3SLis9po392fa1Z7aKaTVXoqa+BxjKviHb1qhU4GBO9FROwkLZlxNJgvXgjyJmFI fXVu9wmuUBNqE1lARvodPbfPl8FJsRjZMXxMPjIwE9vy58nOSRWOY1PIMT2dJ/49+JfE +D1uZaWCewB3YU+DVXQvBymgc1bvpOoJdwmQeRwtl+jSFslNih68uCiH7u16xi4q8oza MP8bhoftQs89UoVhTCbX1YwXswFM1q3QJyUOHDwYrUedho3A0uKVmWA2Ablrpy7+RpM6 b7qiWwYQvseXSVG2e9Dpom32bvL4KJZBMQo7nVmvLk4aqpVhtbZUnlcsEjypUfZpP9GQ rNiw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AfdE7cm61+RuiTXqHHcvBb0RYnHiDekWAMaZLaAEO69gBunEKATzswRbqSWRj9iU2AR 8/wzrWiGZ70FfMZ3Xa0k2IAbFBuwlJQ4lVBz0D0faUWiIg+Ov2yh5/tFX43r3ILAjsLmRwF3Kgv V2qQuLXou3bhseMxqRZ6A0LZe69zixmt3346HdKwfrUb1ZtuI+7+N2ilHVEG9NEao4ed2AlJ6Vi 0yqHj6OqiZSpM7UEVN4um9PB1NgCwCDnk9pGr0AkZqGw2KwDNNzqbqLmqLERD+1yGBmd4U= X-Received: by 2002:a05:7300:1912:b0:30c:5456:d9cf with SMTP id 5a478bee46e88-30c84b50b42mr5587588eec.1.1782445292249; Thu, 25 Jun 2026 20:41:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nagaev Boris Date: Thu, 25 Jun 2026 22:40:53 -0500 X-Gm-Features: AVVi8Ccoy9ea0IPW7Vg7ldhb2cJ_piAsFrMoX1LbV4QxcvoLUcUHFc7uGlnihF8 Message-ID: Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) To: Pieter Wuille Cc: Bitcoin Development Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: bnagaev@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=ovXHIDmr; arc=pass (i=1); spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::1331 as permitted sender) smtp.mailfrom=bnagaev@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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: 2.6 (++) Hi Pieter, I think Tripwire is an improvement to all "Later" versions of P2MR, P2TRv2, and P2TRH. Given coin owners have pre-agreed to later lockdown, having an upper bound does not harm. For Miner Lockdown, I see a potential false-positive activation. A large classical theft may happen, be misinterpreted as a CRQC event, and miners may lock the EC path with the best intentions, but it turns out to be a false alarm. Shouldn't there be a mechanism for reactivation in this case? We have historical examples of bugs causing large-scale or initially mysterious thefts: Milk Sad, Android SecureRandom 2013, and the LuBian 2020 theft. A similar event in the future could be confused with Q-day, and miners could push the button. Can you elaborate on the scope of EC disabling, please? Does it disable only the main EC path (e.g. key spend in the case of Taproot v2) or all EC involving paths? What will happen to scripts using something else in addition to EC? Some useful constructions may include an EC opcode, e.g. hybrid EC-PQ signatures or HTLCs. Maybe it makes sense to disable the main spending path and keep hash-protected supplementary paths available? Best, Boris On Thu, Jun 25, 2026 at 1:31=E2=80=AFPM Pieter Wuille wrote: > > Hi all, > > In parallel to the threads[1][2][3] discussing the P2TRv2 and P2MR > concepts, I'd like to talk about the possibility of codifying in the > consensus rules the (expectation of) the disabling of EC opcodes/paths > within the new output type. > > The motivation for this is that while P2TRv2 has a "soft" built-in > expectation of a future softfork that will disable EC opcodes/paths (just > within the new output type itself) at the right time, its consensus rules > are identical to P2TR (with the exception of PQC opcodes, if those aren't > also added to P2TR). Plans and intent of protocol designers are one thing= , > but the future ecosystem isn't beholden to those: the only certainty is t= he > adopted consensus rules themselves. Without confidence that the intended > disabling will happen, it becomes unclear what CRQC-resistance the P2TRv2 > type offers. Meanwhile, P2MR as formulated doesn't need/have such an > expectation, but would still benefit from it, as users are otherwise > restricted to (IMO) extremely onerous restrictions on public key sharing. > > To some extent, this is an unsolvable problem: we cannot codify plans tha= t > depend on outside-world conditions like CRQCs existing. Still, > approximations exist which can be added as automatic triggers for this EC > disabling, along with the new output type itself: > > * Tripwire (P2XX-T): use the presence of a NUMS point spend as trigger > (suggested by Tadge Dryja[4]). > > Specifically, as part of the softfork definition, a NUMS point is > picked. Whenever a transaction is mined whose input contains a successf= ul > " OP_CHECKSIG", EC opcodes/paths are disabled within the new > output type, as of the next block. > > Note that the tripwire isn't intended as a replacement for the expected > future EC-disabling softfork; instead, it puts an upper bound on that > disabling. > > * Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to trigge= r > the disabling, allowing a faster reaction time to urgent CRQC threats. > > Practically, this can be achieved by bundling the expected EC-disabling > softfork with the softfork that introduces the new output type, but > giving the disabling one a separate, and very long or infinite, > activation window. This means that in addition to expecting the future > ecosystem to decide when Q-day is too close, the hashrate majority is > allowed to make that call too. (suggested offline by Sjors Provoost) > > * Combination (P2XX-T-ML): trigger EC disabling either through Tripwire, = or > through Miner Lockdown. > > I believe P2TR-T and P2MR-T are unambiguous improvements over P2TRv2 and > P2MR respectively. This is because: > > * With Tripwire, anyone with a CRQC can, without permission, disable the = EC > paths/opcodes in the new output type for everyone. Because of that > possibility, disabling is something all users of the new output type ne= ed > to be prepared for at all times, and thus the later EC-disabling softfo= rk > cannot be considered confiscatory. That could otherwise be a reason to > oppose the future EC-disabling softfork. > > Consider P2TR and P2TRv2. If there are no differences in consensus rule= s > between them, it is worth asking why the future ecosystem should be > expected to disable EC paths & opcodes in one but not the other, just > based on earlier-stated plans. With Tripwire, disabling EC in P2TR-T is > categorically non-confiscatory, making doing it there an objective > choice. > > * Relatedly, for the same reason it likely convinces users and wallet > developers to test, more seriously, the usability of the expected PQC > paths, as not doing so inevitably means risking burning those coins. Th= is > is especially important for P2MR, which has some incentives to use it > beyond CRQC-protecting coins. > > * The only downside I see is some additional technical complexity. The > ability to sign with a NUMS point is an unequivocal proof that the > secp256k1 ECDLP assumption no longer holds, and is thus a clear upper > bound on when EC ought not to be used anymore. Note that this differs > from a canary (an idea which has also been discussed) that uses a weake= r > curve, as the goal of those is to be predictive. The point here is > specifically to just be an upper bound. > > To me, this makes both P2MR-T and P2TR-T more "Later"-style (as I've > defined it in [5] and follow-ups) than P2MR and P2TRv2 respectively, whic= h > I consider an improvement for both. There still is an expectation of a > later softfork that disables the EC paths/opcodes within the PQC output > type, and thus the tripwire isn't actually expected to ever trigger. Stil= l, > I believe that its presence changes the game theory and incentives around > usage of the output type, and future consensus changes. > > Of course, it cannot help with deciding what the right time for the > EC-disabling softfork is, but it can help make it happen. The same is tru= e > for the Miner Lockdown idea. I'm a bit more hesitant about that, as it ma= y > be empowering the (collective of) miners too much. They always have the > ability to just disallow EC spends of course, but the Miner Lockdown idea > makes network nodes start enforcing the same rule too, making it > irreversible. On the other hand, it is still opt-in (users deciding to mo= ve > coins to the new output type), and this becomes them choosing to give > miners a Lockdown button, which can presumably be used on shorter notice > than the ecosystem can agree on a consensus change (even if it's > pre-planned). > > I'd prefer to keep the discussion here just about adding the Tripwire > and/or Miner Lockdown ideas, rather than MR vs TR, as I think this is > orthogonal to the distinction between those. > > Thoughts? > > -- > Pieter > > [1]: https://groups.google.com/g/bitcoindev/c/Qy4gwAGTK2w/m/_CjQ8xvdAAAJ > [2]: https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA/m/T7UWqgnvAAAJ > [3]: https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2= mr-bip-360/2603 > [4]: https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/8nr6I5NIAwAJ > [5]: https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA/m/Gona1fr3AgAJ > > -- > 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/yHRpA2LEJ2AugT4W2KiWO3ggSims4GuHBkr6rWtE-e1uVC2wh3ZqD4bUDyxXq1iEuPrezhZZe= qDoG7uBLNvjbW0sk_UTorI1Pkz6LcKhXRA%3D%40wuille.net. --=20 Best regards, Boris Nagaev --=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/= CAFC_Vt7OfZ-rztFP5D5ycpxe3ZQOJJbY5cHgEk73OMYAmnDBjQ%40mail.gmail.com.