From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 19 Oct 2026 10:36:34 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xIrHm-0005Tk-2c for bitcoindev@gnusha.org; Mon, 19 Oct 2026 10:36:34 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-4a7235ca3a6sf1646460fac.3 for ; Mon, 19 Oct 2026 10:36:33 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1792431388; cv=pass; d=google.com; s=arc-20260327; b=qyvF1PPgWuCYflfZ2Ozm2N6SwqDNZ3ss98XrH6ifeghIZd/4T9vJVvP0ghmLpmHVWk coCPB1qnKxHtabgFnc4FEJbsUrWAJ0ujoU0BB1pmpQUS4HBpDHhCDwXBtkezlQ0feTZC m1gRDzgKgbzd1Zh0H75iQvdbCxJTZSFN+u8NpjRMfq7vAjE1ZkOTBA5mTCx2IF/U8VW7 lshEvOlOccVvxPRcgIui1FtIhaKbtHq2XdLAop97vKU+1oyvT9n9VwHRsguJaPqyBxb7 DEShf2z86hUE91XsnCv5JWO0Gn9/Wftus34ncpEevw/KDka9jAS8Vhjf1xSqeupyBqmP vMpQ== 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:cc:to:subject:message-id:date:from :mime-version:sender:dkim-signature:dkim-signature; bh=PrbsPWlUbab3SXoEnt8U08KuQndn2jSxtRh3ehS4aZU=; fh=vpc85L1Pjrz9TcYsng8td/MNviAGMsSLzdlpfGEiVLM=; b=lEcQ2mPso7i6jewDtu5plKZs0FxXIbWtiANczZV99u7Ypk0NBVCTCXmoIgQXRvqucX diMlH4oa6KuEBv71mulcACFg7R0ROIOKxDFNd3VISV6O8J/TiaXRTNO33lbuFyP0WKaL g8LkYhVLyxJzfxyM/h5JAcaHQ4Wqu9ymWRTz4COeIti/3VCpGGy8tlCCbZ9JULIe4sF3 QCoFfWrpzC3lA2AX+fUUlUn+dHRMZGUvPxoNk+iD0FSRzpBCLobooGXWjvtHxo1tgAX6 MmFKj48Kg5VRRiqNWgg9mQxTixmTyrQ7KNJXTDl8XF6IGzL0y8P+ToKZXmlEgaJqGnAi 41SA==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=QQD48LRe; arc=pass (i=1); spf=pass (google.com: domain of zeenix@gmail.com designates 2607:f8b0:4864:20::72a as permitted sender) smtp.mailfrom=zeenix@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=1792431388; x=1793036188; 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-type:cc:to:subject:message-id:date:from :mime-version:sender:from:to:cc:subject:date:message-id:reply-to :content-type; bh=PrbsPWlUbab3SXoEnt8U08KuQndn2jSxtRh3ehS4aZU=; b=BmKjtEzJhKQzW3GV8FsbfhOy2YraVQa5uKgjevrtmC+zVn57AlGK/kUhUsGL3oy4nJ jyQJE2v0GRATlfTBpfSeRL5j637ZSrq+OyDlr6R6MIvkzgEvhANjf5I+917brll61mlD geqlKcbGnV+UZ/RDRFqcrFSma0GFSfPWqS3wSclKgWB/UL9p8aVZOjxSd1prUMAbDMAu masah+VYA43I167jyYUEiD3vvOQKBvHzvjuKYkwH4fvzOmSwUj7sz6T1uASJqJQTvtUm cymZe79BUNw7W9MwcVsyME05Zc0ikjATL0XU7KH7L4hz8KFm2Zp/i8JMkV3DK7th0KdY xuLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1792431388; x=1793036188; 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-type:cc:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=PrbsPWlUbab3SXoEnt8U08KuQndn2jSxtRh3ehS4aZU=; b=g80jO3Gdn/VHaigUQQcsWxUOlwnQaJMOSLoss90rhcfauDnW967hccLHoRU71VMwJe NzcPPxWftWp1pwWGDK9A9UxxVdGPGQ+w15caQOBKBj2Gu5aviBSXPdYesLiSN/U6ejFd zQfrD5O0VYOBu9ZL13bdI7bLYyo3QIVwtTXWTHpIbZtprSEzhBliOAdzel1rux4WUBKU 0j2gnCPSY/bFPIfTASvwZ18wUn7DxDLpMDb979FWaueDkEr/xhQixGCrKVWFoaGZIo3I wcuO2padYPC4iB+wtPzpUM4M+RRW7Z5ssy3lfYpVecMYx5UzjV5yFP7O5ABCzZmZYbX7 QSgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792431388; x=1793036188; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-type:cc:to:subject:message-id:date:from :mime-version:x-gm-gg:x-beenthere:x-gm-message-state:sender:from:to :cc:subject:date:message-id:reply-to:content-type; bh=PrbsPWlUbab3SXoEnt8U08KuQndn2jSxtRh3ehS4aZU=; b=bdQJOFmQUcJW/CzoLMycMMmyP8bM9Zg4i7JIbXDRN/FtVvxU1POjMNzJH2K3AsG7x8 /fd/OIg6/0e+wzkhXPN1bigcEYJpfZ06WdqfkqSjeRNTeormb0alb72eJWn/+FlcRqGm +E/IUhtKNsszGeEb3IAbBycNjMyYs8DCkh6knqF8LWQTveGoKV00igXNbtoDSzA+gWBN 5UIqHsO2vh0wP+XIWHZnhXSU11wPl51h8Ajx9HE59PhU0nsADxUHhDkYSiiMH5jIZdmH ywaaAkblDOHJ/ptqdD5txcRBo61aqZhClmjS4k8bu7Xq9lLJix7kP12+ZtvEh/EdR4IN Eo4Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AKwUvBznadaj+W/WA4zFnI2HRE17CtpJZGuCNd718D2sI/KlKsAwuo7NXo1g+ctg6b2RbjWVrmVlBVQDCOkQ@gnusha.org X-Gm-Message-State: AFq9FYKeIPVXkp1X+uo48lzhMRqCHq3RPH9dt1gPaTa87Qz54NtKqfEn XI3DymKNp4Ro7KZwONlRXO7zR1mVp74wct8RurCG3QH27TEBxGNTdpfj X-Received: by 2002:a05:6820:1614:b0:6f6:2a5b:7996 with SMTP id 006d021491bc7-70355882eecmr5231028eaf.21.1792431387740; Mon, 19 Oct 2026 10:36:27 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLddjDJeL48tIHeKupwCdObi3ZQ9BShYBCGR84iaHVk0JpA==" Received: by 2002:a05:6870:6248:b0:492:5e72:22c4 with SMTP id 586e51a60fabf-4a7319e0fa0ls2865155fac.2.-pod-prod-06-us; Mon, 19 Oct 2026 10:36:20 -0700 (PDT) X-Received: by 2002:a05:6808:508c:b0:524:884f:d89d with SMTP id 5614622812f47-53ccd010e47mr8361695b6e.21.1792431380277; Mon, 19 Oct 2026 10:36:20 -0700 (PDT) Received: by 2002:a05:620a:a401:10b0:93e:f9f7:7bbe with SMTP id af79cd13be357-93f38784f81ms85a; Mon, 19 Oct 2026 10:29:20 -0700 (PDT) X-Received: by 2002:a05:620a:260a:b0:936:ab1f:6aa4 with SMTP id af79cd13be357-93f29ba04c9mr1292048985a.1.1792430959677; Mon, 19 Oct 2026 10:29:19 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1792430959; cv=pass; d=google.com; s=arc-20260327; b=m8/FFSMMmT0QFmZENDfkI4ZLxlbWOarf5aUAIIis6BxgSM91aqCWnHB4Xo6pPjI/ms x/imwAN25Kz2hKDTOmOir6SHjNhDCt4Xb/tif6qhFtyMIVPzJs1e/8J1TTEC2X+OCM0U xGNf6QTve+D13MFzr2J7OJjqxxd/dzgybw7qbWxq4GvSAkjPGbURUIYBWdW/J6HOca8c fk6ZzJNHSguBNanbV+Nq0EPE00rW8LrvAAj1YVhAD2xZHk2gV2p69natl60vkbnle28t hX69cs1CL6muiYiUXZvfJbYYXJ0si4sssOFdqEz/deT0BPQ/ByvPMcJYESsNHt1tiYcI fKvQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:mime-version:dkim-signature; bh=1/RL90WjePL1ZqOOAiVymuXccMdGmHpmepMXFprjkJw=; fh=fMH9qcdB88kUgg8l0KosgJZj8qZdK1oOpWpfvGB5uoY=; b=MLARNN3AUgAqxq9fa9GRiVwAoAs9pj/A7Bp2JaD9GZqPqVWP6oMYcuYQL8DiKMXtTR za/Ztvo4ozXxab7s5TcLnw0TJKOcSwYDkqxvxsK92kVxbDu0UWdogM2Ex69fJXITGp7s 6mRsjaHvEmpX8B7C9omCRIWm2z0qCgFtuLBrzi8A6cAtLO0moZ/y1ELM3BVmz2b9lZf/ ulON9f1Cl+H6rfJzhgfIg1+r1Ogkzmf9FIM0cSjt18wWizZgKK/MBO/F4TakF6gyuLEr em2Qo+XeLAL/Uu44a9kHXFeXBkYlKsjRtkfRuApV3WjVCbxhnUnQWiIrkRKK8+1a/gCL dqlQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=QQD48LRe; arc=pass (i=1); spf=pass (google.com: domain of zeenix@gmail.com designates 2607:f8b0:4864:20::72a as permitted sender) smtp.mailfrom=zeenix@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com. [2607:f8b0:4864:20::72a]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-91c040c0610si26426d6.12.2026.10.19.10.29.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Oct 2026 10:29:19 -0700 (PDT) Received-SPF: pass (google.com: domain of zeenix@gmail.com designates 2607:f8b0:4864:20::72a as permitted sender) client-ip=2607:f8b0:4864:20::72a; Received: by mail-qk1-x72a.google.com with SMTP id af79cd13be357-93f269e335eso319257285a.3 for ; Mon, 19 Oct 2026 10:29:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1792430959; cv=none; d=google.com; s=arc-20260327; b=HrMHhZSEoq5ZQb9KDUjO5qmbFQmmfZ4Qu3mhHCgGeXDbWNVLTZc5X2fZybxXg+J0Un qKDvV1LHlHiEjkvwG6Edy0zgvcig7lhOrF4GkZKD0yGS+sXJQf9wJBsPgooBmNVsXAui ycUp10+Jq+1dddbVrmMIZ+q9/BcEq82+OIyQp5CGMhgNeC/6vuw8WCAi5NDMBNanx0nP 1jPYE+suvZzcTukPIuESS78VM7fr/vIcTsX98fBath7Yeu/2T58T+mLcejt0FZYT/nEf wNtgyzgPvilXMxjxIvTU7tvBFHMjHNRbqUJ6V7VBUqQqj2Sy0YH4xEg4My5cPqTLoHAs iEAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:mime-version:dkim-signature; bh=1/RL90WjePL1ZqOOAiVymuXccMdGmHpmepMXFprjkJw=; fh=fMH9qcdB88kUgg8l0KosgJZj8qZdK1oOpWpfvGB5uoY=; b=RzxuoYcOnr9fR66pQu465cLrIjMrR504YhA1YWat6l7vU78qYa4vK5GEko00+h/9f9 lGNNgkiAIyDtc+Rvrwm998PJeGfrJA/XfOgbCoNZLBZI/6eNqqCb34lxxFX49bY2u3zW x9spRyww8VCwazud+jprR5cJWcG2eWROiQnbhDq22XjjYgQfnv98g1F4r7GjQ6TANUI+ KngI6Sz7CkmxHF9CVzLebzDNLzZ6se3uV1EE89EKP9lACJZRAwYX3AzkWi8Q/mMbSry1 V0JAtCnae0D1ywPBKK+C+D8Wh44ILlyPaeusdmc8b8h0sNderJRVbh8FUOhSMi/w73/b nkvg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AYBFou25OFm9+zNYU24apOB5ghQFXy+w/DtZDGlGLz1vv4vMvYh/YbAj2WGUnzxU5Xs zWc60AUDOWl2ja+r/EQKmSaRo7rlnH33W7aoQBBKshl3WPSoxxQ3IH5I7mo9yyAiSJKbOjpqU3l 2jnqueLLHzuB13uCkEbyiYdTbE1ApL5+xhNJMlImgAMzIbev5PmFzT0qMU4Gr5T8MNG4bWQjLBy RL0WTzP2GVenFHLABZtHGjVsUi28gBoLnG46UGzlqctvBR/E1ZP+93CSrQRIbjQ76PpSMTKp/Oz J/12+S0zX2hsLoxYIIcvx5nZ/ki4wQxgIGZxfZRcXYKmlMVgZVzRO9WTZ9GBq+AUiPfa7bkRJxb XXI78B5JidiwdkQ== X-Received: by 2002:a05:620a:a0d8:10b0:93f:2ab9:7294 with SMTP id af79cd13be357-93f2ab978a0mr921208885a.29.1792430959000; Mon, 19 Oct 2026 10:29:19 -0700 (PDT) MIME-Version: 1.0 From: Zeeshan Ali Khan Date: Mon, 19 Oct 2026 19:29:08 +0200 X-Gm-Features: AclHuK8hpxhxviO0BV_sM0Btt9-8XW_I26itSDBjZ5CPxQjganMuhYflMlo2Hdg Message-ID: Subject: [bitcoindev] Exposure-aware transaction construction for wallets To: bitcoindev@googlegroups.com Cc: duncan0k@cipherscope.io Content-Type: text/plain; charset="UTF-8" X-Original-Sender: zeenix@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=QQD48LRe; arc=pass (i=1); spf=pass (google.com: domain of zeenix@gmail.com designates 2607:f8b0:4864:20::72a as permitted sender) smtp.mailfrom=zeenix@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 (/) I would like to discuss an opt-in wallet transaction-construction policy for preserving resistance to BIP 360 long exposure attacks [1]. This is a companion to bitcoin/bips PR #2294 [2], which classifies exposure and informatively recommends SWEEP_WHEN_SPENDING for outputs sharing a script. Bitcoin Core's -avoidpartialspends [3] and BitGo's quantum-risk controls [4] already group UTXOs by address, but both are best-effort. The proposal here is a stronger wallet-local rule based on everything the wallet knows it is about to disclose. PR #2294 discussion: Delving Bitcoin [5]; bitcoin-dev [6]. ## Motivation If several P2WPKH outputs pay the same script, spending one reveals the public key needed to spend the others. A wallet preserving long exposure resistance should cover those newly affected outputs in the same spend workflow and send change to a fresh, non-exposed condition. The boundary can cross scripts when key material is reused. Avoiding unnecessary disclosure may also preserve eligibility for future rescue mechanisms that depend on still-hidden one-way-function commitments, such as DropKick [7]. ## Trust boundary A wallet can reason only about disclosures it knows. Its trust boundary is the set of components and parties assumed not to disclose wallet material to the adversary. This mode is intentionally opt-in because restrictions on public-key sharing can be operationally burdensome [8]. Disclosure includes public keys, xpubs/descriptors, relevant PSBT derivation data, reuse in another protocol, and ECDSA signatures over known messages, from which public-key candidates can be recovered. BIP 340 Schnorr signatures do not have that public-key-recovery property [9]. If an account xpub has left the trust boundary, this protection cannot be claimed for that subtree. ## Exposure set Call material hidden when it is hash-committed and a complete spend recipe has not been published. An output becomes long-exposure vulnerable only when disclosed material is enough to reconstruct some complete spend recipe: required key material plus any script, Merkle path, preimage, or other path data. Let D_prior be material already disclosed before this spend, derived from on-chain history (for example PR #2294's classification) plus the wallet's local disclosure metadata. Let S contain the intended inputs. When an output is added, choose one spending path and keep that choice fixed while computing the set: ```text S = intended inputs repeat: previous = S D = D_prior | material disclosed by the chosen paths for S V = wallet outputs whose complete spend recipe is reconstructible from D but not from D_prior alone S = S | V until S == previous R = S ``` Here | is set union. R is the exposure set, and "affected" below means an output in R. Outputs that were already vulnerable before this spend are handled by the remediation workflow and may be added to a protected spend at the user's option; they do not enter V merely because they were already exposed. Example: if D_prior already contains key a and the intended spend reveals b, a standard sortedmulti 2-of-2 {a,b} script may become newly vulnerable once its script is reconstructible. A hash-committed 2-of-3 {a,b,d} script does not: without d the attacker cannot reconstruct the witnessScript. For ordinary P2SH/P2WSH this normally converges in one step; iteration mainly matters when prior disclosure and spending-path choice interact. ## Transaction construction Before new material for R leaves the trust boundary, prepare spends covering every confirmed affected output the current signing workflow can spend now, without waiting for a timelock or additional cooperation. If an affected output cannot be covered, the wallet should not claim protection unless the user explicitly overrides it. If several transactions are required, prepare them before disclosure and hand them to the network in the same batch. Replacements should jointly keep covering R; if coverage is lost through eviction, invalidation or replacement, rebroadcast or reconstruct/fee-bump the affected spends. ### Intended property When new material is deliberately disclosed, every confirmed affected output in `R` that can be spent now has been handed to the network in the same batch. ## Unconfirmed and local state Wallet-authored unconfirmed parents are controllable by the wallet; third-party payments may be replaced by their sender. The default should therefore be to wait for relevant third-party outputs to confirm. After a documented or user-configurable wait bound, ask whether to keep waiting or explicitly relax the guarantee. This creates an unavoidable griefing/DoS tradeoff. Wallet-local disclosure state is deliberately broader than PR #2294's chain-derived classification: once material leaves the trust boundary, keep treating it as disclosed even if the transaction never confirms. A seed/descriptor restore cannot reconstruct every prior off-chain disclosure, so missing disclosure metadata should be reported as unknown rather than safe. ## Change and reused destinations Change must use a condition whose required secp256k1 material is still hidden. Fresh P2WPKH can do this only if its derivation data stays inside the trust boundary, including through PSBT handling [10]. P2TR cannot, because its output key Q is public at rest and consensus accepts a key-path signature for Q however Q was constructed. P2MR is the intended direction once available [1]. Funds later received to an already disclosed destination are vulnerable immediately. Bitcoin Core's avoid_reuse is useful precedent [11]: mark them as reused/exposed, exclude them from the protection claim, warn the user, and offer remediation instead of automatically sweeping every receipt. ## Privacy and scope Cross-script grouping can add input linkage. CoinJoin, Payjoin, explicit coin control, timelocks or unavailable cosigners may prevent full coverage. In those cases the wallet should decline to claim the property or require an explicit override. This is a wallet security/privacy/usability policy, not a consensus rule. ## Open questions 1. Is a separate companion proposal, cross-linked from PR #2294, the right place for this rule? 2. Is complete-spend-recipe exposure the right abstraction for Taproot, Miniscript and future scripts? 3. Should economically insignificant outputs ever be excluded automatically, or only by explicit override? 4. What wait policy should apply to relevant third-party unconfirmed outputs? 5. Could BIP 329 label records [12] carry disclosure metadata across backup/sync, or is separate metadata needed? 6. Are there implementations that go beyond the address grouping of Bitcoin Core APS and BitGo by reasoning across complete spending conditions? The intended guarantee is narrow: wallet behavior should not unnecessarily turn hidden-key outputs into long-exposure-vulnerable outputs while leaving value behind under the newly disclosed spend recipe. ## References [1] BIP 360: https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki [2] bitcoin/bips PR #2294: https://github.com/bitcoin/bips/pull/2294 [3] Bitcoin Core -avoidpartialspends source: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/init.cpp [4] BitGo quantum-risk controls: https://www.bitgo.com/resources/blog/bitgo-adds-new-quantum-risk-management-capabilities-for-bitcoin-wallets/ [5] PR #2294 Delving discussion: https://delvingbitcoin.org/t/standardizing-an-exposure-classification-for-existing-outputs-pre-bip/2866 [6] PR #2294 bitcoin-dev discussion: https://groups.google.com/g/bitcoindev/c/A3MFJt8mOM4 [7] DropKick: https://gnusha.org/pi/bitcoindev/CAHPaHkr5r4+hodZv6F2S1yCq_UcHSr2iCrkYLgZ_vryNgwbRPA@mail.gmail.com/ [8] P2XX thread: https://groups.google.com/g/bitcoindev/c/aWYtPLVPZ3U [9] BIP 340: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki [10] BIP 174 (PSBT): https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki [11] Bitcoin Core avoid_reuse release notes: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.19.0.1.md [12] BIP 329: https://github.com/bitcoin/bips/blob/master/bip-0329.mediawiki -- Regards, Zeeshan Ali Khan -- 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/CAAa3hFNACEoE4KXi06SaqGM0qsOTrgT3HB6X2oiocp--r6-rmg%40mail.gmail.com.