summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAdam Back <adam.back@gmail.com>2020-03-25 14:54:18 +0100
committerbitcoindev <bitcoindev@gnusha.org>2020-03-25 13:54:35 +0000
commitaacc3d962c6a398f514f5a952389e5a8b5b4fe5d (patch)
treefbd7c778d7afb0a03a1574a8ea02017443c72d44
parent50b732cb41bfd91fa1cecef647f2c22dc82b7ced (diff)
downloadpi-bitcoindev-aacc3d962c6a398f514f5a952389e5a8b5b4fe5d.tar.gz
pi-bitcoindev-aacc3d962c6a398f514f5a952389e5a8b5b4fe5d.zip
Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains
-rw-r--r--8d/bad709ae212bb12098e12b2f263ddf3e95fc0c399
1 files changed, 399 insertions, 0 deletions
diff --git a/8d/bad709ae212bb12098e12b2f263ddf3e95fc0c b/8d/bad709ae212bb12098e12b2f263ddf3e95fc0c
new file mode 100644
index 000000000..df0cd34ed
--- /dev/null
+++ b/8d/bad709ae212bb12098e12b2f263ddf3e95fc0c
@@ -0,0 +1,399 @@
+Return-Path: <adam.back@gmail.com>
+Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
+ by lists.linuxfoundation.org (Postfix) with ESMTP id F399EC0177
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 25 Mar 2020 13:54:35 +0000 (UTC)
+Received: from localhost (localhost [127.0.0.1])
+ by whitealder.osuosl.org (Postfix) with ESMTP id E296B86BA4
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 25 Mar 2020 13:54:35 +0000 (UTC)
+X-Virus-Scanned: amavisd-new at osuosl.org
+Received: from whitealder.osuosl.org ([127.0.0.1])
+ by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
+ with ESMTP id Yt+StbSqRpWN
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 25 Mar 2020 13:54:34 +0000 (UTC)
+X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
+Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com
+ [209.85.208.180])
+ by whitealder.osuosl.org (Postfix) with ESMTPS id 0B82A86B90
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 25 Mar 2020 13:54:34 +0000 (UTC)
+Received: by mail-lj1-f180.google.com with SMTP id w1so2532754ljh.5
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 25 Mar 2020 06:54:33 -0700 (PDT)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
+ h=mime-version:references:in-reply-to:reply-to:from:date:message-id
+ :subject:to:cc:content-transfer-encoding;
+ bh=pK/VHS0dDhe9ykaKcHJ0mFNZIWAMuSsMf165DL7MNX0=;
+ b=UTczVHqywLLxp2gzShjwnccvOyKm4g2xgvF06PEoaBt48q4vvFHOShuuuVuf6D4ZQg
+ TlcVdmpA69mI8t73Yk/KWr/f2nHUWiQFb4kjPBqo0Zwj41xzXxA0mgGUGsloYMPnvpiA
+ 8+TKRv9tZe6JIJhg5RCrWXinpwRYJVH7Ei6YYcW9AIoMnielQ/SMzzBNXxZMqjGUsep0
+ /9jLJIWXzN/0fWQlWtZncfok9FRlSEx+hGT/5WuEgdmQK2wMrivGEhUGMgshQwTOVN8G
+ eQdF7kvAsMEh/hB3AWm0YrpiZ/rpmF913mIPZOAB+cHHb1RGH3vLNY8ynBQ/By4JycJ3
+ JG/Q==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20161025;
+ h=x-gm-message-state:mime-version:references:in-reply-to:reply-to
+ :from:date:message-id:subject:to:cc:content-transfer-encoding;
+ bh=pK/VHS0dDhe9ykaKcHJ0mFNZIWAMuSsMf165DL7MNX0=;
+ b=pEaAK+5OioIidpffIFG26lT+5QTMwttzNntaoSp2TIxaJNgY458M6Ob5S1HxWZiwRk
+ gFsrGe1cf7iiDAk5x3TCuORcM16on9tUjmucqBnjeeoIJN2hZPIP4VKgKBW99uUnDG5+
+ gFvg1ONJzJBLqljDB3pRHUAa+97zva0Kg0QJh2M/h0ID9XyvIhPo7LVO29mfyi1tCqR2
+ Tfc9vdTF39AWL7p4BR2wvYn752t474mpyrPFLeNGlcSPKd/8q9R4C6JBYE+GswKXRMmF
+ WFy/5Gg3wuS53DXV7HdfwNjSoR4f8s7quD4QU3mylZ6W2kP3iSYNY//UsvuSzqypovyt
+ 5CfA==
+X-Gm-Message-State: AGi0PuYsXSa0ra/X7NmHEyT7bXik/UbbZ9qhKRcgQ2y/pC3EH9+kicpi
+ aAv14HUk15GxtVh0kQbKY+XWcb5vZD/QOhr2Qmo=
+X-Google-Smtp-Source: APiQypI1q0zHPthRKTUJvdBUtWCsmztWzjHbNwA6ed8bdvbiCv7EwWlnyz2YWhjKOjW06UnduRyJpnZD5YtEulN9J+I=
+X-Received: by 2002:a2e:b0c2:: with SMTP id g2mr2140324ljl.102.1585144471841;
+ Wed, 25 Mar 2020 06:54:31 -0700 (PDT)
+MIME-Version: 1.0
+References: <_CC9MLKCy5rmooAmR91_34tQxgDiXDJCdY4W6_X6xqDJUiAEuaWBVi8iBaFipx2KGt5_mf5XqFKMfoNgemTPCMgraWt5CVRifUM5iMolxto=@protonmail.com>
+ <S90SB9DcluBjzhnWrbT1Urh61XgVcn6ynEU7EGsfR-UhGGMxPOXMuJdwM0BPtdAcIaL22B4zR0Pooe4Yaoi0zBPFnnwQ4WSSpL7FoW4OOBA=@protonmail.com>
+ <c7b9bd243e7ae6a5a4e55f4b18d7d656c3690380.camel@timruffing.de>
+In-Reply-To: <c7b9bd243e7ae6a5a4e55f4b18d7d656c3690380.camel@timruffing.de>
+Reply-To: adam@cypherspace.org
+From: Adam Back <adam.back@gmail.com>
+Date: Wed, 25 Mar 2020 14:54:18 +0100
+Message-ID: <CALqxMTH4+WWKDzLh-6gC5GcaHvSMJjY9S8HNy-DwNgefdpuyUA@mail.gmail.com>
+To: Tim Ruffing <crypto@timruffing.de>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Content-Type: text/plain; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+Subject: Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.15
+Precedence: list
+List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
+X-List-Received-Date: Wed, 25 Mar 2020 13:54:36 -0000
+
+I think the point is to use this proposed extension/standard for a
+kind of "seed management" function, set it up on an offline device (an
+always offline laptop, or a modified hardware wallet) where you put
+the master seed. And then you use this as a kind of seed manager and
+transcript the seeds for different sub-wallets into the respective
+wallets as BIP39 mnemonics.
+
+So I do not think it needs any changes from existing wallet authors,
+as the interaction point is a bip 39 seed, which they mostly know how
+to use. Indeed if you were to modify an existing wallet to accept the
+master seed from seed management scheme and derive the seed it needs
+on each wallet, then that would create a weakest link in the chain
+risk - if that wallet was insecure, or compromised then all other
+derived seeds would be also and you want independence for each wallet.
+
+I do think that this use case is a practical problem for people
+managing multiple seeds for various wallets in a bitcoin business
+setting or even power users - you lose the single backup design,
+because it's too cumbersome to create fresh backups for each of
+multiple wallets, especially distributed , fireproof cryptosteel etc
+backups and so in practice for multi wallet scenarios probably they
+are not all full backed up or not backed up as robustly (not as
+geo-redundant, fireproof, secret-shared etc).
+
+Adam
+
+On Tue, 24 Mar 2020 at 09:32, Tim Ruffing via bitcoin-dev
+<bitcoin-dev@lists.linuxfoundation.org> wrote:
+>
+> I think your proposal is simply to use BIP32 for all derivations and
+> the observation that you can work with derived keys with the
+> corresponding suffixes of the path. I believe that this is a good idea.
+>
+> But I don't think that simply writing a standard will help. It's just
+> one step. If all your wallets support incompatible formats, we should
+> work on fixing this because that's the root of the issue. Otherwise you
+> end up converting keys back and forth manually (as Chris pointed out),
+> and this can't be the goal.
+>
+> But then you need to reach out to wallet devs explicitly and get them
+> involved in creating the standard. Otherwise they won't use it. That's
+> a hard process, and it's even harder to make sure that the resulting
+> proposal isn't way too complex because everyone brings their special
+> case to the table.
+>
+> Tim
+>
+> On Sun, 2020-03-22 at 11:58 +0000, Ethan Kosakovsky via bitcoin-dev
+> wrote:
+> > I have completely revised the wording of this proposal I hope to be
+> > clearer in explaining the motivation and methodology.
+> >
+> > https://gist.github.com/ethankosakovsky/268c52f018b94bea29a6e809381c05d=
+6
+> >
+> > Ethan
+> >
+> > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina=
+l Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
+> > On Friday, March 20, 2020 4:44 PM, Ethan Kosakovsky via bitcoin-dev <
+> > bitcoin-dev@lists.linuxfoundation.org> wrote:
+> >
+> > > I would like to present a proposal for discussion and peer review.
+> > > It aims to solve the problem of "too many seeds and too many
+> > > backups" due to the many reasons stipulated in the proposal text.
+> > >
+> > > https://gist.githubusercontent.com/ethankosakovsky/f7d148f588d14e0bb4=
+f70bb6afc509d0/raw/6da51e837b0e1f1b2b21f3d4cbc2c5a87969ffd5/bip-entropy-fro=
+m-bip32.mediawiki
+> > >
+> > > <pre>
+> > > BIP:
+> > > Title: Deterministic Entropy From BIP32 Keychains
+> > > Author: Ethan Kosakovsky ethankosakovsky@protonmail.com
+> > > Comments-Summary: No comments yet.
+> > > Comments-URI:
+> > > Status: Proposed
+> > > Type: Standards Track
+> > > Created: 2020-03-20
+> > > License: BSD-2-Clause
+> > > OPL
+> > > </pre>
+> > >
+> > > =3D=3DAbstract=3D=3D
+> > >
+> > > This proposal provides a way to derive entropy from a HD keychain
+> > > path in order to deterministically derive the initial entropy used
+> > > to create keychain mnemonics and seeds.
+> > >
+> > > =3D=3DMotivation=3D=3D
+> > >
+> > > BIP32 uses some initial entropy as a seed to deterministically
+> > > derive a BIP32 root for hierarchical deterministic keychains. BIP39
+> > > introduced a method of encoding initial entropy into a mnemonic
+> > > phrase which is used as input to a one way hash function in order
+> > > to deterministically derive a BIP32 seed. The motivation behind
+> > > mnemonic phrases was to make it easier for humans to backup and
+> > > store offline. There are also other variations of this theme.
+> > >
+> > > The initial motivation of BIP32 was to make handling of large
+> > > numbers of private keys easier to manage and backup, since you only
+> > > need one BIP32 seed to cover all possible keys in the keychain. In
+> > > practice however, due to various wallet implementations and
+> > > security models, the average user may be faced with the need to
+> > > handle an ever growing number of seeds/mnemonics. This is due to
+> > > incompatible wallet standards, hardware wallets (HWW), seed formats
+> > > and standards, as well as, the need to used a mix of hot and cold
+> > > wallets depending on the application and environment.
+> > >
+> > > Examples would span wallets on mobile phones, online servers
+> > > running protocols like Join Market or Lightning, and the difference
+> > > between Electrum and BIP39 mnemonic seed formats. The reference
+> > > implementation of Bitcoin Core uses BIP32, while other
+> > > cryptocurrencies like Monero use different mnemonic encoding
+> > > schemes.
+> > >
+> > > We must also consider the different variety of physical backups
+> > > including paper, metal and other physical storage devices, as well
+> > > as the potentially splitting backups across different geographical
+> > > locations. This complexity may result in less care being taken with
+> > > subsequently generated seeds for new wallets need to be stored and
+> > > it ultimately results in less security. In reality, the idea of
+> > > having "one seed for all" has proven to be more difficult in
+> > > practice than originally thought.
+> > >
+> > > Since all these derivation schemes are deterministic based on some
+> > > initial entropy, this proposal aims to solve the above problems by
+> > > detailing a way to deterministically derive the initial entropy
+> > > used for new root keychains using a single BIP32 style "master root
+> > > key". This will allow one root key or mnemonic to derive any
+> > > variety of different root keychains in whatever format is required
+> > > (like BIP32 and BIP39 etc).
+> > >
+> > > =3D=3DSpecification=3D=3D
+> > >
+> > > Input starts with a BIP32 seed. Derivation scheme uses the format
+> > > `m/83696968'/type'/index'` where `type` is the final seed type, and
+> > > `index` in the key index of the hardened child private key.
+> > >
+> > > type
+> > >
+> > > bits
+> > >
+> > > output
+> > >
+> > > 0
+> > >
+> > > 128
+> > >
+> > > 12 word BIP39 mnemonic
+> > >
+> > > 1
+> > >
+> > > 256
+> > >
+> > > 24 word BIP39 mnemonic
+> > >
+> > > 2
+> > >
+> > > 128
+> > >
+> > > 12 word Electrum mnemonic
+> > >
+> > > 3
+> > >
+> > > 256
+> > >
+> > > 24 word Electrum mnemonic
+> > >
+> > > 4
+> > >
+> > > 256
+> > >
+> > > WIF for Bitcoin Core
+> > >
+> > > 5
+> > >
+> > > 256
+> > >
+> > > 25 word Monero mnemonic
+> > >
+> > > Entropy is calculated from the HMAC-SHA512(key=3Dk, msg=3D'bip-entrop=
+y-
+> > > from-bip32') of the derived 32 byte private key (k). Entropy is
+> > > taken from the result according to the number of bits required.
+> > > This entropy can then be used as input to derive a mnemonic, wallet
+> > > etc according to the`type` specified.
+> > >
+> > > =3D=3DCompatibility=3D=3D
+> > >
+> > > In order to maintain the widest compatibility, the input to this
+> > > function is a BIP32 seed, which may or may not have been derived
+> > > from a BIP39 like mnemonic scheme. This maintains the original
+> > > motivation that one backup can store any and all child derivation
+> > > schemes depending on the user's preference or hardware signing
+> > > devices. For example, devices that store the HD seed as a BIP39
+> > > mnemonic, Electrum seed, or BIP32 root key would all be able to
+> > > implement this standard.
+> > >
+> > > =3D=3DDiscussion=3D=3D
+> > >
+> > > This proposal could be split into multiple discrete BIPs in the
+> > > same way that BIP32 described the derivation mechanics, BIP39 the
+> > > input encoding with mnemonics, and the derivation paths like BIP44,
+> > > BIP49 and BIP84. This has been avoided to reduce complexity. The
+> > > resulting private key processed with HMAC-SHA512 and truncated as
+> > > necessary. HMAC-SHA512 was chosen because it may have better
+> > > compatibility in embedded devices as it's already required in
+> > > devices supporting BIP32.
+> > >
+> > > =3D=3DTest Vectors=3D=3D
+> > >
+> > > =3D=3D=3DTest case 1=3D=3D=3D
+> > >
+> > > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind
+> > > employ giant era attitude exit final oval one finger decorate pair
+> > > useless super method float toddler dance
+> > > MASTER BIP32 ROOT KEY:
+> > > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG
+> > > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
+> > > PATH: m/83696968'/0'/0'
+> > > BITS REQUIRED: 128
+> > >
+> > > DERIVED CHILD
+> > > WIF=3DL3cefeCHyo8jczVjckMxaiPBaPUunc3D8CsjRxYbYp3FhasGpsV3
+> > > DERIVED CHILD
+> > > k=3Dbed343b04ba0216d9eeebff0366b61c4179d90d44b61c716ef6d568836ba4d23
+> > > CHILD ENTROPY=3D6458698fae3578b48a64124ea3514e12
+> > > CONVERT ENTROPY TO
+> > > WIF=3DKwDiBf89QgGbjEhKnhXJuH7T2Vv72UKQA8KRkmNwVFS2znAS5xb9
+> > > CHILD BIP39 MNEMONIC=3Dgold select glue fragile fiscal fog civil
+> > > liquid exchange box fatal caught
+> > > CHILD BIP39
+> > > SEED=3D2a2720e5590d4ec3140e51ba1b0b0a5183222c1668977c8a57572b0ea55d23
+> > > 8cd8e899b3b1870e48894ca837e41e5d0db07554715efb21556fdde27f9f7ba153
+> > > CHILD BIP32 ROOT
+> > > KEY=3Dxprv9s21ZrQH143K2ZH5qacptquLGvcYpHSNeyFVCU8Ur4u9kocajbBgcaCbHkG
+> > > bwDsBR661H29F54j5mz14kwXbY9PZKdNRdjgRcGfshBK9XXb
+> > >
+> > > =3D=3D=3DTest case 2=3D=3D=3D
+> > >
+> > > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind
+> > > employ giant era attitude exit final oval one finger decorate pair
+> > > useless super method float toddler dance
+> > > MASTER BIP32 ROOT KEY:
+> > > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG
+> > > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
+> > > PATH: m/83696968'/1'/0'
+> > > BITS REQUIRED: 256
+> > >
+> > > DERIVED CHILD
+> > > WIF=3DL1zCbtnDWUN4vJA3De4sxmJnoRim57CQUuBb4KBoRNs2EMEq2Brg
+> > > DERIVED CHILD
+> > > k=3D8e3ca6054a6303f4a6a1bcbda6134c9802f4f0a0d76b0ee6b69b06b1e80b2192
+> > > CHILD
+> > > ENTROPY=3Dec4e2f7e2c3fca9a34fa29747bf8ba0ab7f05136f37e134e2457e9e5363
+> > > 9670b
+> > > CONVERT ENTROPY TO
+> > > WIF=3DL594JSCygt2wBaB9mCpXjiLkkxkEojpBdNXG8UrrdLd2LvPBRMUs
+> > > CHILD BIP39 MNEMONIC=3Dunable imitate test flash witness escape
+> > > stadium early inner thank company betray lecture chuckle swift hurt
+> > > battle illness bicycle stable fat bronze order high
+> > > CHILD BIP39
+> > > SEED=3D73509b0e847ee66bddeb098a55063d73e8c6dd5f1c1db6969c668bb54c19bd
+> > > e6eae8acc29a81118d1d9719fa1bc620fee7edd7c15a17bcaf70b0fdfc0c0c3803
+> > > CHILD BIP32 ROOT
+> > > KEY=3Dxprv9s21ZrQH143K4PfLyyjYLVmKbnUTNFK6Y7jPKWfRZB3iSw1Gy9qowEzkYHf
+> > > etVabfmjHEEPrcTJbh7chae33Sm9uAjuXzhSL6Li8dcwM9Bm
+> > >
+> > > =3D=3D=3DTest case 3=3D=3D=3D
+> > >
+> > > MASTER BIP39 SEED INPUT: angle fabric town envelope music diet bind
+> > > employ giant era attitude exit final oval one finger decorate pair
+> > > useless super method float toddler dance
+> > > MASTER BIP32 ROOT KEY:
+> > > xprv9s21ZrQH143K2xNoceSiUtx8Wb8Fcrk9FUfzD3MLT4eFx5NbBuof9Mwrf7CCbfG
+> > > JNehNRHvrXnWvy9FtWVaeNggsSKT57GNk7jpk1PRzZDp
+> > > PATH: m/83696968'/4'/0'
+> > > BITS REQUIRED: 256
+> > >
+> > > DERIVED CHILD
+> > > WIF=3DKwdD5PYnCU3xQDfFJ6XBf6UDaLrTUxrKmBpdjRuuavWyqAQtpaA2
+> > > DERIVED CHILD
+> > > k=3D0c169ce2c17bea08512a7519769e365242a1562bd63c4c903daef516000efbf2
+> > > CHILD
+> > > ENTROPY=3D25573247f8a76799f7abc086b9286b5a7ccb03cb8d3550f48ac1e71d908
+> > > 32974
+> > > CONVERT ENTROPY TO
+> > > WIF=3DKxUJ8VzMk7uWDEcwYjLRzRMGE6sSpwCfQxkE9GEwAvXhFSDNba9G
+> > > CHILD BIP39 MNEMONIC=3Dcensus ridge music vanish island smooth team
+> > > job mammal sing bracket reject smile limit comfort pluck extend
+> > > picture race soda suit dose place obtain
+> > > CHILD BIP39
+> > > SEED=3D4e5c82be6455ecf0884d9475435e29a9afb9acf70b07296d7e5039c866e4d5
+> > > 4647706918b9d14909dfbd7071a4b7aee8a4ad0ac2bf48f0a09a8899dd28564418
+> > > CHILD BIP32 ROOT
+> > > KEY=3Dxprv9s21ZrQH143K2kekJsK9V6t4ZKwHkY1Q3umxuaAhdZKGxCMpHiddLdYUQBo
+> > > ynszpwnk5upoC788LiT5MZ5q1vUABXG7AMyZK5UjD9iyL7Am
+> > >
+> > > =3D=3DReferences=3D=3D
+> > >
+> > > BIP32, BIP39
+> > >
+> > > =3D=3DCopyright=3D=3D
+> > >
+> > > This BIP is dual-licensed under the Open Publication License and
+> > > BSD 2-clause license.
+> > >
+> > > bitcoin-dev mailing list
+> > > bitcoin-dev@lists.linuxfoundation.org
+> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+> >
+> > _______________________________________________
+> > bitcoin-dev mailing list
+> > bitcoin-dev@lists.linuxfoundation.org
+> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+> _______________________________________________
+> bitcoin-dev mailing list
+> bitcoin-dev@lists.linuxfoundation.org
+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+