From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 14 Jun 2025 16:53:30 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uQagj-0001Hn-NX for bitcoindev@gnusha.org; Sat, 14 Jun 2025 16:53:30 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-2e42bf99e78sf2929621fac.2 for ; Sat, 14 Jun 2025 16:53:29 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749945203; cv=pass; d=google.com; s=arc-20240605; b=NDqhILz6K2WCgK+oHYrrumXkK+qY9pyRjQrSgHST2A5BH14O2jX2sI0lRN/gZzM9Tf BIV24F7tUB0MIBFVtEI8kzZqLC7KnS1rdROyoYncZaHi1nXMaqh32YOg7+Kw7BsJ+T0P 7/9dWnQ7ufPY2snuhSLLDITemXrR8gkXSHe3zHhEmi9AXqdAerTK0KO4HY7aU1q06Eof uVZGwicVODcmw0Mhjk/I4ksUBBu2L6zGZ7jM9H1o66D0CeJOJ8umR48pl0NcIqAb0t1g 7zGWp9eVtSwoIfhIR6EFM2zXTpwcWStwPf3V0VYz1ITMIqH99OEeSwydNS1q0OYq9mjw tbiQ== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=2H7ssuRDdu3NM0jvRQW/xWfbDU+8zlbHVKwz25u1tak=; fh=ofFQmKQs0XWuIJXde2vZPtAj7HdF4nZD0ndVTGlAz8k=; b=dbsSP2Zxk8osi1ZsZDXZBWP/+G91mDF4dg6jR5u3S3SyHu1VhlA2rqIAKQBIC3vBbZ s8l22gyx54QD9F1UJUldXyAb5aSe0Rz3XM4UVTsBpIgL/B45iJclRuH0eUASgi/moSOR iQCrBeo9uM1AsFY1N3LTEcm0fZ3twbfd1gcCoHbCrjGPu8zfx182+KCo1BMzapbBkU3o zlHYZhpdtKCR+oc8gTrCfFdfRg7bAPLIuH7iDdel2qioQMb6F1nh0sNVd9I6wLCGSyvD nEYOxDHTXEBm/hvw9QONheMdbaIyQtOStVISyfwYFK9LMJoXxolHJ+yZVIF/z60ffp4G tLBQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="ij/8xkbM"; spf=pass (google.com: domain of sanket1729@gmail.com designates 2607:f8b0:4864:20::112f as permitted sender) smtp.mailfrom=sanket1729@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=20230601; t=1749945203; x=1750550003; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=2H7ssuRDdu3NM0jvRQW/xWfbDU+8zlbHVKwz25u1tak=; b=cJ1AYz23+8lNwhKcnJBeQFFH2wTg33vZsPHbfJLZUkq/FPtp8YoGmvCyMsJfbuYL21 zSPLbpCs/ehZlaAtkarYZr4tXL+5eMHoRfJUU21hTA2vgwAFd0vrnVk7NuGdT9EUzmx2 k7b5Pk/KygL+VSu5/rY27TckO4R7fFTlS3fAhtNU9hpBTTk74x5+5gYIlwEjVj0WNcYl liGtnDKVMbFfG+WbLhsplxtxH6bsOgrVOiUuqiUtiVbBHdthJDMWdB/yxMichRqlFItO QSjKu+qbK3hx31ei2jl6powGyj2fF11JdHJ0zhzrRsEepEWtMuWtwNNZPON6dZqL9GBR osDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749945203; x=1750550003; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2H7ssuRDdu3NM0jvRQW/xWfbDU+8zlbHVKwz25u1tak=; b=M+QzHIZqPXdMqgwUdy4BrG7KlXyhuYruLIimaNef9gCWqJwWAAqIVF4hZati+KNpSC 7zPvydGSqckKBt3lHsw6RAH/XRsk+JSXfI2mNvgom3GmyyPuVUHr8XLzl2EnieF44WXe vA6QSYnr/c7haDpQs6VkGNRv0bb9XSkVOqVA/4oSLMKy5csDhkQob2V/yr7eRerRmJZL HqRrPlCQeE4dJt+YNTABen2x71q1SdTECiN6vqQCxXskYXZFlNc6Odc5NbmXld+4NRNe mHnM8Og23DI/pOIuVTTsnEaivgGT9o4QUfzFhq+au8cBE1ki1uVEPHMrVaDRpZCexC4D 86Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749945203; x=1750550003; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=2H7ssuRDdu3NM0jvRQW/xWfbDU+8zlbHVKwz25u1tak=; b=Mboc+rFM7glkhTG2m5U7HIHodIwv3xbVLdUisrScupIP4HhzLpzzglg7+VopLMSe1w MjQTkd0xLYhWH5i/MkoSpOZ0Kxk4ryfXxXvHf+JTQ3KN4dLYEm7OWT/D7QgvoM3Ulo14 h7GVVBCSPFnfXaTKpB9cLzRTkb5vZ8xVbcFGCpQQ0DA3+WoeEqyDJNsdcVHcvE7qXnH1 pkU+l86EAOmUaCr2zOvQVN70u+Sgc3rbkAtND/4QUN6AngcJLfxLsI9wHS8C30D5bSqH 0jK8zfC2DhV/MLBcImjssBPLxFv5LK6qP2+iIfqNphBYpwtBR/qr3kw5Q0b6/peM/2dy OElg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUBF1nVsrLbrWJiHwlscOjrkURqKcl90pFQ1SdeWn71NEoRS5K84FP3oJT7GOWKJ1V4QsZaJLY7vH/B@gnusha.org X-Gm-Message-State: AOJu0YzeozM8rXZx5FsPecoQbuCYt2FqUx5o5hg4yh4uuBPAI7/l4jPe wyWZuJ/uGNaJh5qe1a9EwG/x5FkKauWxOYWBhoK6JkaKxBWFvSW9Ccvb X-Google-Smtp-Source: AGHT+IFDc1s6Mmu2+h/+MJfYzGWkWkzLP159xoi+SKzlxDzLWdyfln6I3Hxcowmd9+eBym0zMCIzrw== X-Received: by 2002:a05:6870:9a97:b0:2e8:f84b:84dd with SMTP id 586e51a60fabf-2eaf0825befmr2949377fac.5.1749945203413; Sat, 14 Jun 2025 16:53:23 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcCedJ+bBHNdz2s8JLgyvbMz+vmNJ53ObHdfA+brJotRA== Received: by 2002:a05:6870:2424:b0:29f:bc7e:8f4e with SMTP id 586e51a60fabf-2eab6f71582ls2827484fac.1.-pod-prod-05-us; Sat, 14 Jun 2025 16:53:19 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVAwMHACkIyd3IMT5RNxbvwGgDCbI3Jq+nwIIX8CK2u6024ZnG5+PkC2znCyEDcKVdEywtyW9/GCw3x@googlegroups.com X-Received: by 2002:a05:6808:690b:b0:401:cae9:4dc3 with SMTP id 5614622812f47-40a7c13a8b6mr2995443b6e.8.1749945199032; Sat, 14 Jun 2025 16:53:19 -0700 (PDT) Received: by 2002:a54:4108:0:b0:3f6:a384:eb6f with SMTP id 5614622812f47-40a7187c42amsb6e; Sat, 14 Jun 2025 16:50:27 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXjuOQFvnyDWpVXYmcJrsw2StO7zuTAuHvmIsBUnAF/pKLKLvgMjQ5EVCvTOjPLSpfPe9l30BkBnTfh@googlegroups.com X-Received: by 2002:a17:902:e788:b0:235:2375:7e94 with SMTP id d9443c01a7336-2366b3c5b99mr70534295ad.24.1749945026431; Sat, 14 Jun 2025 16:50:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749945026; cv=none; d=google.com; s=arc-20240605; b=D/K7BiR2xJyJxwka8QLJq0/NoixArrRbbU3YUDCzcV2U/4HRfnQSMF4eBl5C6RS0et TQhMHLhVCcv/d8pc+Bk4CMv5OyG3t4YvjOWqWI878duXMWqscbJ7zAG0EjyiUmMvz9dv RF8IAzkoba537AF0m9gOeZBXq3R5guN9HLpWukBskM1lk/1GutieUv5lYfTus8NuwBcI 5APQfjMlwHA5kgpd9eIZbsAwjEIrjSYito/PYkPyivC6r+24NvX0MzkYULGIEYBtTNp9 hRQB4HGkfFz2McZ8+dnrGO6H92EMQn6cQc0/YpP64FkWF7AMYfWr1t0C3UzvJOJoHHkR ei+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=AZR3fI3Dn5eNxFJtvbzoLHfueMSc6kQEQY0DG/dBBDc=; fh=DhQ7dIDDz7U1zzgNCtlPxYMQlMoY5O+KO6LVoMYT6H4=; b=Z8o8nvgQh5iEoetTuwOvKKo1dGhluXWYRMIIiJcW8aj3rFHIUQXzP155mwUIMAzvpn jjD3K6z+L6sQ9/Iyo9RyQ0wlmrl3FuMUSjUItj5AQFQyDWWFLEx5fNfhFDAlg/7B/8Gu Y0E/FppqAajj0dVw+wIybRWUjg0D8jLMelr4I5YDr0kVccDmJ1mDj3HE8ylhGupYpOIQ MBluIhtLzAy8c8/CP0yYhgygYeDFsWqO2kFdp+vN9uQmrtk6SjcBwSJD3xrAcw6EpO22 WsTTcba5AjMhawJaA9ArKz8L5gosX6Ew5toKR2Oe7S8R5dntbt1T0CCFA+gemm7E2h5o MW5A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="ij/8xkbM"; spf=pass (google.com: domain of sanket1729@gmail.com designates 2607:f8b0:4864:20::112f as permitted sender) smtp.mailfrom=sanket1729@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com. [2607:f8b0:4864:20::112f]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-2365de40d74si1771775ad.8.2025.06.14.16.50.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Jun 2025 16:50:26 -0700 (PDT) Received-SPF: pass (google.com: domain of sanket1729@gmail.com designates 2607:f8b0:4864:20::112f as permitted sender) client-ip=2607:f8b0:4864:20::112f; Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-70e447507a0so24310457b3.0 for ; Sat, 14 Jun 2025 16:50:26 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVM9KuXQlaPH4c7WCIQJgA8oESBRTw9+o40a38j7lnAlkmKoyji3M57rTDDqCTiqB9jEKKpc12k2byF@googlegroups.com X-Gm-Gg: ASbGncsitWv0T7RkiB5PgfWXzecMUlBjLP2el1ND459DPUsyWynxK9zISLvBwg2B/Ps GOrGg9QD+oJHnZmxwA1+4mnv8tKNTgDvm5A9CtfKFEXaUlfdFkJV+Bh5DNl7aG+Zjftb8bJP2vn S0oZXVAYvNywlV8QBVmrCqHLAX4Sy+wwaG/TYtE7daMFA= X-Received: by 2002:a05:690c:39a:b0:70d:f673:140b with SMTP id 00721157ae682-7117538e5b8mr61874357b3.14.1749945025338; Sat, 14 Jun 2025 16:50:25 -0700 (PDT) MIME-Version: 1.0 References: <46349b6c-ccec-4378-8721-aecec22752e7@mattcorallo.com> <8d158e3d-b3cc-44b6-b71b-ab2e733c047c@mattcorallo.com> In-Reply-To: From: Sanket Kanjalkar Date: Sat, 14 Jun 2025 16:50:13 -0700 X-Gm-Features: AX0GCFsXAxOx9-UFWI75YFGv7IKSg9vQ6EZcM7y-h48MCyiRICTWkJ1yENY8cEc Message-ID: Subject: Re: [bitcoindev] CTV + CSFS: a letter To: Greg Maxwell Cc: Jameson Lopp , Antoine Poinsot , Matt Corallo , Andrew Poelstra , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000009ca69c063790d326" X-Original-Sender: sanket1729@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="ij/8xkbM"; spf=pass (google.com: domain of sanket1729@gmail.com designates 2607:f8b0:4864:20::112f as permitted sender) smtp.mailfrom=sanket1729@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: -0.5 (/) --0000000000009ca69c063790d326 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 14, 2025 at 2:40=E2=80=AFPM Greg Maxwell w= rote: > On Sat, Jun 14, 2025 at 8:17=E2=80=AFPM Jameson Lopp > wrote: > >> Sure. As I mentioned in my article years ago, one can technically >> implement covenant functionality today via presigned transactions and >> ephemeral key material. But there is a vast gap between what is technica= lly >> possible and what is practical, which is why I believe you can't find an= y >> such software in existence. Using presigned transactions means you have = to >> regularly update your vault scheme whenever your UTXOs change. This beco= mes >> incredibly problematic if we're talking about a multisignature setup wit= h >> geographically distributed keys. And ephemeral keys relies upon user bei= ng >> able to securely delete key material, which comes with its own host of >> problems. >> > > What's the problem for securely deleting? The operation is atomic-- e.g. > software can be written that performs it as a single step and never even > hands the users the private key. If you need to attest to a third party > the ephemeral key can have 1-N multisigners, which has none of the normal > challenges for multisigning since they don't need to retain information o= r > check anything (in fact, it could even be blinded). > > From a durability perspective you also have the same issue of maintaining > a script, if you're avoiding that by always constructing it > programmatically and backing up the scheme, you can more or less do that > with the presigned approach: just stick the ephemeral signature in a > taproot annex in the transaction paying the coins to the 'vault' script a= nd > then immediately all the participants have the required data to > deterministically construct the intermediate transaction. > > The result is essentially identical properties to a 'vault' constructed > with CTV and needs no consensus change. > > As I see it, a setup where you presign a transaction to sweep funds to an >> emergency address is only particularly useful for the situation in which >> key material becomes inaccessible. It doesn't really help you in the cas= e >> where key material is compromised. Vaults specifically allow for a user = to >> recover from a situation in which a signing threshold of keys have been >> compromised. >> > > But that is the only kind of vault you can construct from CTV isn't it? > One where the stationary output can go to one of multiple preconstructed > outputs, typically one 'immediately' and the other after a delay that > starts when a particular transaction is released. AFAICT, the CTV approa= ch > does not allow you to stage an output address and then either abort or > allow it to continue. > Do you mean arbitrary output address that is unknown at commitment time? Otherwise, I think the current CTV vault does allow abort/allowing from "stage area" to "hot area" or abort to "rescue area". While general purpose recursive vaults will allow funds back into same "cold area", I think it is possible to also move funds back into same back under the same cold keys with a bounded recursion CTV provides. > (though I remain dubious as to the utility of that improvement, since if > you can secure the rescue/abort key you could use the process for the > primary.) > Primary key is used often for regular withdrawals from the vault. The rescue/abort key will only be used in case there is something wrong. If there is something that you don't intent you use at all, you can go 10 extra steps to secure it. Maybe store in secure guarded physical locations, or require offchain security authorization protocols to secure them. You might not do these for regular primary keys if you intend to use them often= . And even if you secure rescue key as the primary key, there is still value because the attacker has to get both of them. We can see that in practice, people use multisig instead of single-sig even though both keys are probably secured to the same degree of security. Finally, on the usefulness of vaults; based on my own observation of all the hacks (bitcoin and wider crypto), in most cases it is not the key that is stolen but rather the authorization process or UI/UX hacks or something else up the signing stack is compromised. Having reactive security to "undo" feels valuable in this scenario. > > > > > -- > 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/bitcoindev/CAAS2fgSmmDmEhi3y39MgQj%2BpK= CbksMoVmV_SgQmqMOqfWY_QLg%40mail.gmail.com > > . > --=20 Sanket1729 --=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/= CAExE9c8oWiy6GUaSMVf2Nxa%2B9a60e2Mw8fg_s8GT4TmfiPMKMQ%40mail.gmail.com. --0000000000009ca69c063790d326 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jun 14,= 2025 at 2:40=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com> wrote:
On Sat, Jun 14, 20= 25 at 8:17=E2=80=AFPM Jameson Lopp <jameson.lopp@gmail.com> wrote:
Sure. As I mentioned in my artic= le years ago, one can technically implement covenant functionality today vi= a presigned transactions and ephemeral key material. But there is a vast ga= p between what is technically possible and what is practical,=C2=A0which is= why I believe you can't find any such software in existence. Using pre= signed=C2=A0transactions means you have to regularly update your vault sche= me whenever your UTXOs change. This becomes incredibly problematic if we= 9;re talking about a multisignature setup with geographically distributed k= eys. And ephemeral keys relies upon user being able to securely delete key = material, which comes with its own host of problems.

What's the problem for securely deleting?= =C2=A0 The operation is atomic-- e.g. software can be written that performs= it as a single step and never even hands the users the private key.=C2=A0 = If you need to attest to a third party the ephemeral key can have 1-N multi= signers, which has none of the normal challenges for multisigning=C2=A0sinc= e they don't need to retain information or check anything (in fact, it = could even be blinded).=C2=A0

From a durability perspective you also have the sam= e issue of maintaining a script, if you're avoiding that by always cons= tructing it programmatically and backing up the scheme, you can more or les= s do that with the presigned approach: just stick the ephemeral signature i= n a taproot annex in the transaction paying the coins to the 'vault'= ; script and then immediately all the participants have the required data t= o deterministically=C2=A0construct the intermediate transaction.
=
The result is essentially identical properties to a 'vau= lt' constructed with CTV and needs no consensus change.

As I see it, a setup where you presign=C2=A0a transaction= to sweep funds to an emergency address is only particularly useful for the= situation in which key material becomes inaccessible. It doesn't reall= y help you in the case where key material is compromised. Vaults specifical= ly allow for a user to recover from a situation in which a signing threshol= d of keys have been compromised.

But that is the only kind of vault you can construct from CTV isn&#= 39;t it?=C2=A0 One where the stationary output can go to one of multiple pr= econstructed outputs, typically one 'immediately' and the other aft= er a delay that starts when a particular transaction is released.=C2=A0 AFA= ICT, the CTV approach does not allow you to stage an output address and the= n either abort or allow it to continue.
= Do you mean arbitrary output address that is unknown at commitment time? Ot= herwise, I think the current CTV vault does allow abort/allowing from "= ;stage area" to "hot area" or abort to "rescue area&quo= t;. While general purpose recursive vaults will allow funds back into same = "cold area", I think it is possible to also move funds back into = same back under the same cold keys with a bounded recursion CTV provides.

(though I remain dubious= as to the utility of that improvement, since if you can secure the rescue/= abort key you could use the process for the primary.)
Primary key is used often for regular withdrawals from the va= ult. The rescue/abort key will only be used in case there is something wron= g. If there is something that you don't intent you use at all, you can = go 10 extra steps to secure it. Maybe store in secure guarded physical loca= tions, or require offchain security authorization protocols to secure them.= You might not do these for regular primary keys if you intend to use them = often.

=C2=A0And even if you secure rescue key as the primary key, t= here is still value because the attacker has to get both of them. We can se= e that in practice, people use multisig instead of single-sig even though b= oth keys are probably secured to the same degree of security.=C2=A0 =C2=A0<= br>

Finally, on the usefulness of vaults; based on my own observatio= n of all the hacks (bitcoin and wider crypto), in most cases it is not the = key that is stolen but rather the authorization process or UI/UX hacks or s= omething else up the signing stack is compromised. Having reactive security= to "undo" feels valuable in this scenario.=C2=A0


=C2=A0

--
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/CAAS2fgSmmDmEhi3y39MgQj%2BpKCbksMoVm= V_SgQmqMOqfWY_QLg%40mail.gmail.com.


--
Sanket1729

--
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.google.com/d/= msgid/bitcoindev/CAExE9c8oWiy6GUaSMVf2Nxa%2B9a60e2Mw8fg_s8GT4TmfiPMKMQ%40ma= il.gmail.com.
--0000000000009ca69c063790d326--