Return-Path: <earonesty@gmail.com> Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id CAA57C002A for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 20 Apr 2023 13:59:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id AF1C0841DB for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 20 Apr 2023 13:59:21 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org AF1C0841DB Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=q32-com.20221208.gappssmtp.com header.i=@q32-com.20221208.gappssmtp.com header.a=rsa-sha256 header.s=20221208 header.b=x/hJbUAq X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT7Qur1EIeoT for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 20 Apr 2023 13:59:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org BB12C8411D Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) by smtp1.osuosl.org (Postfix) with ESMTPS id BB12C8411D for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 20 Apr 2023 13:59:19 +0000 (UTC) Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-54fdeddabd7so1715917b3.1 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 20 Apr 2023 06:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20221208.gappssmtp.com; s=20221208; t=1681999158; x=1684591158; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=26rnAsB1Y+oMRcGZHGkwEhq79sWcv3Jwi3zUzIE61V8=; b=x/hJbUAqlIncBsYAzzkdlIkom7RmKjqrG6EOqZzjtmXvMiSlRH7oyvNQ0r+SHrOKXX JEFllSVrciCC/nvdBRgi3ou8ZGA1uNwCD3V4u00m4zqVbFAFJjQyiplTwEEbtpm29Mfm RnYG9xS7BFtPYJBOIsseR7TxUiqhrfKJPTuZd6nNIebZZOZAh78vaHBI380H2qkdUYA5 b9nOCK8qW5hvfGkWIkaANzmP3XEd11gq6G/KUuNHmqWsEEVy0tI/SrhsAsBTPsljGEn2 02iH4NYuBTO+4Fq80K3mX4TTgNUkSpXAKUVw3ro0J6iTBbkwuEAGZyeCc9nwY8wOifjO U3fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681999158; x=1684591158; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=26rnAsB1Y+oMRcGZHGkwEhq79sWcv3Jwi3zUzIE61V8=; b=fYuJFu/JHr2c2qTMlY+s6Xt661I451Ugx1TUlo4MmSvCLXhcq6bo4SaAIIO8qlq7kR nbBEcKgW5axDF5GR8dk8yZCd4bvxMEDUdU4hqM1sOciOdO4Jv0JvsKuAlqHQqhRklnu/ KXA6hKR6Sc0eN6+vR3kmOW7/OHHxantd5o/JSAGxT7QfEDdlX7ePsuTVNqeqfcOinXk2 fTpu8VqO1rmE/ZGgXOy8Vn1fqY0VPw/FxjNBEeduqRuASywA0VFaqKrAlfb/IGwsQW3U vknOn8KJ1Agj809o6ttcVg8x/in3fJpXWQxF6GOG3eOKDztBHEb48mmpo/WaOouekfAx XZgw== X-Gm-Message-State: AAQBX9cPgNrFZiTQ+UtqivuSNU3MoNr3mVXgZcgsH8PRcTepON5pQ3I3 He+2PLZcoP0QnkbE/y8NLVXoz/34tygm/z3IAm0Bqso= X-Google-Smtp-Source: AKy350Ykc1f8FGJ8dXlJyDXZ3C0KFrXo13dS/bd3bmKjABmUjW4F9ukv6y8f+9288QCKLRwIftCtZOh/4gYw6ZIMRh8= X-Received: by 2002:a81:1710:0:b0:53c:70c5:45d2 with SMTP id 16-20020a811710000000b0053c70c545d2mr808399ywx.0.1681999158455; Thu, 20 Apr 2023 06:59:18 -0700 (PDT) MIME-Version: 1.0 References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com> <feef7f88-b46d-7355-1716-122afc6359ee@achow101.com> <cfa83206-4ea7-5949-9db4-99fc495641a4@peersm.com> In-Reply-To: <cfa83206-4ea7-5949-9db4-99fc495641a4@peersm.com> From: Erik Aronesty <erik@q32.com> Date: Thu, 20 Apr 2023 09:59:07 -0400 Message-ID: <CAJowKgLh1zS+fFvkVZTLXiqHQ8QMOqxCVooGpby3_o8EHxoihA@mail.gmail.com> To: Aymeric Vitte <aymeric@peersm.com>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> Content-Type: multipart/alternative; boundary="0000000000005a330305f9c4f2c0" X-Mailman-Approved-At: Thu, 20 Apr 2023 14:04:20 +0000 Subject: Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions 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: Thu, 20 Apr 2023 13:59:21 -0000 --0000000000005a330305f9c4f2c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i think the w3c is a very good example of a slow train wreck, and we should do everything possible to avoid the decisions they made On Thu, Apr 20, 2023 at 7:09=E2=80=AFAM Aymeric Vitte via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Personnally I will never criticize the maintainers, but my comment was > about the global process, I thought that for something important like > bitcoin there were many devs/maintainers, and as you point out, a PR > must be done by certified people > > I don't get very well why every company involved in bitcoin do not put > at least one person in this process (a bit like W3C specs), with > different time zone so every time you wake up you don't have to look > at/handle hundreds of requests/comments > > And we can read in the press that bitcoin maintenance is supposed to > cost 200M per year, probably false then, but this is worrying to see > that devs/maintainers are stepping down one after the other > > > Le 19/04/2023 =C3=A0 23:33, Andrew Chow via bitcoin-dev a =C3=A9crit : > > Responses in-line. > > Note that the opinions expressed in this email are my own and are not > > representative of what other maintainers think or believe. > > > > On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev wrote: > > > > > > Communication has been a challenge on Bitcoin Core for what I can > > tell the entire history of the project. Maintainers merge a pull reques= t > > and provide no commentary on why they=E2=80=99ve merged it. > > > > What commentary does there need to be? > > It's self evident that the maintainer believes the code is ready to be > > merged, and has observed enough ACKs from contributors that they are > > comfortable to do so. > > You're welcome to ask for clarification, but frankly, I don't think > > having any commentary on merges is going to be helpful or more elaborat= e > > in any way. > > Requiring maintainers to have to write explanations for every single > > merge is simply going to increase the burden on them and increase the > > rate of burnout and resignations. > > We've had too many maintainers step down already. > > It'll end up being a bunch of boilerplate comments that don't say > > anything meaningful. > > > > There are certainly situations where PRs are merged very quickly or wit= h > > otherwise little apparent review. > > But, as I said, if you ask a maintainer why it was merged, the answer > > will be "I thought it was ready and had enough review". > > There may be other reasons that made the maintainer think it was ready > > sooner, such as the PR fixes a critical bug or security vulnerability, > > but these reasons aren't going to be stated publicly. > > > > > Maintainers leave a pull request with many ACKs and few (if any) > > NACKs for months and provide no commentary on why they haven't merged i= t. > > > > There are currently 320 open PRs and 366 open issues. > > I wake up every morning to 150+ email notifications containing > > everything that went on overnight, and throughout the day, I typically > > get hundreds more. > > It's impossible to keep up with everything that goes on throughout the > repo. > > ACKs come in sporadically, PRs are updated, reviews are posted, etc. > > Often times PRs are not merged simply because the maintainers were not > > aware that a PR was ready to be merged. > > Things can simply fall through the cracks. > > > > Of course there are other reasons why something might not be merged, an= d > > these generally fall into the camp of "I don't think it has had enough > > review". > > It's the maintainer's judgement call to make as to whether something ha= s > > been sufficiently reviewed, and part of the judgement call is to > > consider the quality and competence of the reviewers. > > If a PR had 100 ACKs but all from random people who have never > > contributed to the project in any capacity, then it's not going to be > > merged because those reviewers would be considered low quality. > > It's not just about the numbers, but also about whether the reviewers > > are people the maintainers think are familiar enough with an area and > > have had a history of thoroughly reviewing PRs. > > For example, if a reviewer who primarily works on the mempool reviewed = a > > PR in the wallet, I would consider their review and ACK with less weigh= t > > because they are unlikely to be familiar with the intricacies of the > wallet. > > Obviously that changes over time as they make more reviews. > > For another example, if I see an ACK from a reviewer who posts reviews > > that primarily contain nits on code style and other trivialities, I > > would consider that ACK with less weight. > > > > Furthermore, the maintainers are not necessarily the ones who block a > merge. > > Part of evaluating if something is ready to be merged is to read the > > comments on a PR. > > Other frequent contributors may have commented or asked questions that > > haven't been resolved yet. > > PRs will often not be merged (even if they have ACKs) until a maintaine= r > > deems that those comments and questions have been sufficiently resolved= , > > typically with the commenter stating in some way that their concerns > > were addressed. > > In these situations, no commentary from maintainers is given nor > > necessary as it should be self evident (by reading the comments) that > > something is controversial. > > These kinds of comments are not explicit NACKs (so someone who is only > > counting (N)ACKs won't see them), but are blocking nonetheless. > > > > Lastly, personally I like to review every PR before I merge it. > > This often means that a PR that might otherwise be ready to be merged > > wouldn't be merged by myself as I may not be familiar with that part of > > the codebase. > > It may also mean that I would require more or specific additional peopl= e > > to review a PR before I merge it as I would weight my own review less > > heavily. > > With several long time maintainers stepping away, this may be a factor > > in PRs taking longer to get merged as the remaining maintainers may be > > less familiar with the parts of the codebase that were previously > > maintained by someone else. > > > > > but a casual observer would have only seen Concept ACKs and ACKs wit= h > > 3 stray NACKs. Many of these casual observers inflated the numbers on > > the utxos.org site [4] signalling support for a soft fork activation > > attempt. > > > > Anyone who thinks that maintainers only look at the numbers of (N)ACKs > > is delusional. > > As I explained above, there is a whole lot more nuance to determining > > even just the status of the opinions on a PR, nevermind the code itself= . > > > > In this specific example of a soft fork, there is also consideration of > > the opinions outside of the repo itself, such as on this mailing list > > and elsewhere that people discuss soft forks. > > > > On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote: > > > While some simple changes can allow bitcoin to surpass ethereum, as > > usual, like "Allow several OP_RETURN in one tx and no limited size" > > https://github.com/bitcoin/bitcoin/issues/27043 > > > > > > How long it will take remains mysterious > > > > No one (maintainers or contributors) is obligated to implement anything= . > > A feature request not being implemented is because the people who do > > open PRs are either not interested in implementing the feature, or are > > working on other things that they believe to be higher priority. > > If there is a feature that you want, then you will often need to either > > to it yourself, or pay someone to do it for you. > > > > Additionally, a feature may seem like a good idea to you, but there are > > often interactions with other things that may end up resulting in it > > being rejected or need significant revision, especially for something > > which affects transaction relay. > > > > > > > > Andrew Chow > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- > Sophia-Antipolis, France > CV: https://www.peersm.com/CVAV.pdf > LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26 > GitHub : https://www.github.com/Ayms > A Universal Coin Swap system based on Bitcoin: > https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7 > A bitcoin NFT system: > https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 > Move your coins by yourself (browser version): https://peersm.com/wallet > Bitcoin transactions made simple: > https://github.com/Ayms/bitcoin-transactions > > torrent-live: https://github.com/Ayms/torrent-live > node-Tor : https://www.github.com/Ayms/node-Tor > Anti-spies and private torrents, dynamic blocklist: > http://torrent-live.peersm.com > Peersm : http://www.peersm.com > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000005a330305f9c4f2c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">i think the w3c is a very good example of a slow train wre= ck, and we should do everything possible to avoid the decisions they made= =C2=A0</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_= attr">On Thu, Apr 20, 2023 at 7:09=E2=80=AFAM Aymeric Vitte via bitcoin-dev= <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= ists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail= _quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204= ,204);padding-left:1ex">Personnally I will never criticize the maintainers,= but my comment was<br> about the global process, I thought that for something important like<br> bitcoin there were many devs/maintainers, and as you point out, a PR<br> must be done by certified people<br> <br> I don't get very well why every company involved in bitcoin do not put<= br> at least one person in this process (a bit like W3C specs), with<br> different time zone so every time you wake up you don't have to look<br= > at/handle hundreds of requests/comments<br> <br> And we can read in the press that bitcoin maintenance is supposed to<br> cost 200M per year, probably false then, but this is worrying to see<br> that devs/maintainers are stepping down one after the other<br> <br> <br> Le 19/04/2023 =C3=A0 23:33, Andrew Chow via bitcoin-dev a =C3=A9crit :<br> > Responses in-line.<br> > Note that the opinions expressed in this email are my own and are not<= br> > representative of what other maintainers think or believe.<br> ><br> > On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev wrote:<br> >=C2=A0 ><br> >=C2=A0 > Communication has been a challenge on Bitcoin Core for what= I can<br> > tell the entire history of the project. Maintainers merge a pull reque= st<br> > and provide no commentary on why they=E2=80=99ve merged it.<br> ><br> > What commentary does there need to be?<br> > It's self evident that the maintainer believes the code is ready t= o be<br> > merged, and has observed enough ACKs from contributors that they are<b= r> > comfortable to do so.<br> > You're welcome to ask for clarification, but frankly, I don't = think<br> > having any commentary on merges is going to be helpful or more elabora= te<br> > in any way.<br> > Requiring maintainers to have to write explanations for every single<b= r> > merge is simply going to increase the burden on them and increase the<= br> > rate of burnout and resignations.<br> > We've had too many maintainers step down already.<br> > It'll end up being a bunch of boilerplate comments that don't = say<br> > anything meaningful.<br> ><br> > There are certainly situations where PRs are merged very quickly or wi= th<br> > otherwise little apparent review.<br> > But, as I said, if you ask a maintainer why it was merged, the answer<= br> > will be "I thought it was ready and had enough review".<br> > There may be other reasons that made the maintainer think it was ready= <br> > sooner, such as the PR fixes a critical bug or security vulnerability,= <br> > but these reasons aren't going to be stated publicly.<br> ><br> >=C2=A0 > Maintainers leave a pull request with many ACKs and few (if= any)<br> > NACKs for months and provide no commentary on why they haven't mer= ged it.<br> ><br> > There are currently 320 open PRs and 366 open issues.<br> > I wake up every morning to 150+ email notifications containing<br> > everything that went on overnight, and throughout the day, I typically= <br> > get hundreds more.<br> > It's impossible to keep up with everything that goes on throughout= the repo.<br> > ACKs come in sporadically, PRs are updated, reviews are posted, etc.<b= r> > Often times PRs are not merged simply because the maintainers were not= <br> > aware that a PR was ready to be merged.<br> > Things can simply fall through the cracks.<br> ><br> > Of course there are other reasons why something might not be merged, a= nd<br> > these generally fall into the camp of "I don't think it has h= ad enough<br> > review".<br> > It's the maintainer's judgement call to make as to whether som= ething has<br> > been sufficiently reviewed, and part of the judgement call is to<br> > consider the quality and competence of the reviewers.<br> > If a PR had 100 ACKs but all from random people who have never<br> > contributed to the project in any capacity, then it's not going to= be<br> > merged because those reviewers would be considered low quality.<br> > It's not just about the numbers, but also about whether the review= ers<br> > are people the maintainers think are familiar enough with an area and<= br> > have had a history of thoroughly reviewing PRs.<br> > For example, if a reviewer who primarily works on the mempool reviewed= a<br> > PR in the wallet, I would consider their review and ACK with less weig= ht<br> > because they are unlikely to be familiar with the intricacies of the w= allet.<br> > Obviously that changes over time as they make more reviews.<br> > For another example, if I see an ACK from a reviewer who posts reviews= <br> > that primarily contain nits on code style and other trivialities, I<br= > > would consider that ACK with less weight.<br> ><br> > Furthermore, the maintainers are not necessarily the ones who block a = merge.<br> > Part of evaluating if something is ready to be merged is to read the<b= r> > comments on a PR.<br> > Other frequent contributors may have commented or asked questions that= <br> > haven't been resolved yet.<br> > PRs will often not be merged (even if they have ACKs) until a maintain= er<br> > deems that those comments and questions have been sufficiently resolve= d,<br> > typically with the commenter stating in some way that their concerns<b= r> > were addressed.<br> > In these situations, no commentary from maintainers is given nor<br> > necessary as it should be self evident (by reading the comments) that<= br> > something is controversial.<br> > These kinds of comments are not explicit NACKs (so someone who is only= <br> > counting (N)ACKs won't see them), but are blocking nonetheless.<br= > ><br> > Lastly, personally I like to review every PR before I merge it.<br> > This often means that a PR that might otherwise be ready to be merged<= br> > wouldn't be merged by myself as I may not be familiar with that pa= rt of<br> > the codebase.<br> > It may also mean that I would require more or specific additional peop= le<br> > to review a PR before I merge it as I would weight my own review less<= br> > heavily.<br> > With several long time maintainers stepping away, this may be a factor= <br> > in PRs taking longer to get merged as the remaining maintainers may be= <br> > less familiar with the parts of the codebase that were previously<br> > maintained by someone else.<br> ><br> >=C2=A0 > but a casual observer would have only seen Concept ACKs and= ACKs with<br> > 3 stray NACKs. Many of these casual observers inflated the numbers on<= br> > the <a href=3D"http://utxos.org" rel=3D"noreferrer" target=3D"_blank">= utxos.org</a> site [4] signalling support for a soft fork activation<br> > attempt.<br> ><br> > Anyone who thinks that maintainers only look at the numbers of (N)ACKs= <br> > is delusional.<br> > As I explained above, there is a whole lot more nuance to determining<= br> > even just the status of the opinions on a PR, nevermind the code itsel= f.<br> ><br> > In this specific example of a soft fork, there is also consideration o= f<br> > the opinions outside of the repo itself, such as on this mailing list<= br> > and elsewhere that people discuss soft forks.<br> ><br> > On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote:<br> >=C2=A0 > While some simple changes can allow bitcoin to surpass ethe= reum, as<br> > usual, like "Allow several OP_RETURN in one tx and no limited siz= e"<br> > <a href=3D"https://github.com/bitcoin/bitcoin/issues/27043" rel=3D"nor= eferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/issues/27043<= /a><br> >=C2=A0 ><br> >=C2=A0 > How long it will take remains mysterious<br> ><br> > No one (maintainers or contributors) is obligated to implement anythin= g.<br> > A feature request not being implemented is because the people who do<b= r> > open PRs are either not interested in implementing the feature, or are= <br> > working on other things that they believe to be higher priority.<br> > If there is a feature that you want, then you will often need to eithe= r<br> > to it yourself, or pay someone to do it for you.<br> ><br> > Additionally, a feature may seem like a good idea to you, but there ar= e<br> > often interactions with other things that may end up resulting in it<b= r> > being rejected or need significant revision, especially for something<= br> > which affects transaction relay.<br> ><br> ><br> ><br> > Andrew Chow<br> ><br> > _______________________________________________<br> > bitcoin-dev mailing list<br> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= ank">bitcoin-dev@lists.linuxfoundation.org</a><br> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev</a><br> <br> -- <br> Sophia-Antipolis, France<br> CV: <a href=3D"https://www.peersm.com/CVAV.pdf" rel=3D"noreferrer" target= =3D"_blank">https://www.peersm.com/CVAV.pdf</a><br> LinkedIn: <a href=3D"https://fr.linkedin.com/in/aymeric-vitte-05855b26" rel= =3D"noreferrer" target=3D"_blank">https://fr.linkedin.com/in/aymeric-vitte-= 05855b26</a><br> GitHub : <a href=3D"https://www.github.com/Ayms" rel=3D"noreferrer" target= =3D"_blank">https://www.github.com/Ayms</a><br> A Universal Coin Swap system based on Bitcoin: <a href=3D"https://gist.gith= ub.com/Ayms/029125db2583e1cf9c3209769eb2cdd7" rel=3D"noreferrer" target=3D"= _blank">https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7</a><b= r> A bitcoin NFT system: <a href=3D"https://gist.github.com/Ayms/01dbfebf21996= 5054b4a3beed1bfeba7" rel=3D"noreferrer" target=3D"_blank">https://gist.gith= ub.com/Ayms/01dbfebf219965054b4a3beed1bfeba7</a><br> Move your coins by yourself (browser version): <a href=3D"https://peersm.co= m/wallet" rel=3D"noreferrer" target=3D"_blank">https://peersm.com/wallet</a= ><br> Bitcoin transactions made simple: <a href=3D"https://github.com/Ayms/bitcoi= n-transactions" rel=3D"noreferrer" target=3D"_blank">https://github.com/Aym= s/bitcoin-transactions</a><br> <br> torrent-live: <a href=3D"https://github.com/Ayms/torrent-live" rel=3D"noref= errer" target=3D"_blank">https://github.com/Ayms/torrent-live</a><br> node-Tor : <a href=3D"https://www.github.com/Ayms/node-Tor" rel=3D"noreferr= er" target=3D"_blank">https://www.github.com/Ayms/node-Tor</a><br> Anti-spies and private torrents, dynamic blocklist: <a href=3D"http://torre= nt-live.peersm.com" rel=3D"noreferrer" target=3D"_blank">http://torrent-liv= e.peersm.com</a><br> Peersm : <a href=3D"http://www.peersm.com" rel=3D"noreferrer" target=3D"_bl= ank">http://www.peersm.com</a><br> <br> <br> _______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> </blockquote></div> --0000000000005a330305f9c4f2c0--