From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 19 Aug 2024 07:13:32 -0700 Received: from mail-qv1-f58.google.com ([209.85.219.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sg38V-0003AJ-Cs for bitcoindev@gnusha.org; Mon, 19 Aug 2024 07:13:32 -0700 Received: by mail-qv1-f58.google.com with SMTP id 6a1803df08f44-6bf7bb58632sf43828026d6.2 for ; Mon, 19 Aug 2024 07:13:31 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1724076805; cv=pass; d=google.com; s=arc-20160816; b=M9pON4Zb3cN5cmpsX6NELW03jXDgDoHekHLxJNZ5PdD3JAzfQW/D7iP+MnypDrUKxe 2BBqrnnx3LSdqX0yCdoFQ0QHwlFlmLcju2K0Hf7zVOzgr/bmJljPtlSPO4sJ9hqKtQHy l0WLxX4vHvIB8zbhWF85xryURTAszyLSqgoNo5if8OidLJNDrnpYR80vT5GPO7YU6m5+ uIk2BynnbNWC4Z24QHsTRQH23w6YBWVITVhLeuVFpfrE3uT/qlLhzLnanwq3Lg9fQWX9 xBjXQ/GlCKqFzouk+5vFTbjL3+2WwU6yxvqwx7L+joHER3QB+aul3m9FoCFIcwNBaJi6 CLAQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=7GY2pg58I31qfq65qko/hLtGTfiveWsJAXY/P+iSQvc=; fh=rjyYXx2Sy5VE0reqn1dXmsxMTCCLdwgZSQumNN5u8Ag=; b=0bfQw7whDvYIvqf1MSHy8jsfr2IimJFeRpD/29LkfvL+nNEaKvEH8GW83WexWpjS/v PR42WcCeWWN4IS917w9dndyhFqwpoe6SksLyMdJGplmTmYTUyHeNecvNKg1ZHxWKfdrU fpeP1RGUrcv01RERwXmkiXENnLYr/W1s3NRlg025DLRF3CZhbOUiMWegTPWNbwLgqfLD Ko+GI25ZvDY4rz5JrUNlXb9WhZGKk6k0VMGPpVVMGakyJ0z4FLUswQY4xysKY5XgYrjS f7JfqnAFewGYnkJW9f67/BB5x+jccD2bJfB64m6sWKDP2hrIsiACV3dIUqudF2VYCNP+ PRdw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=ze1AxgKw; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.40.133 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1724076805; x=1724681605; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=7GY2pg58I31qfq65qko/hLtGTfiveWsJAXY/P+iSQvc=; b=oJi9ZiKKOSrijkP7VaZCidT/ug6boVrIW+yzF7dTYaldUMrGxM9nxlVh96BXsAp3fw msgIt4IxgKUcRDnIp4TNDS2+v6x9AMCDuP2wDSG1bZVYxyMSumSVLfzh/oip8GiT5hPl ora5Nct9/isx4Th2/sfAxYB6NngJPBwR3RbBrZ3HlHzzA2HOgIvoKhOZ3WOhtokzJvfu ZCW8k3BIaTNcSrq9U/jqm6ETqQP+KV6C7WJrRaJNajC4Hm7N4KcC6YT02EXD742loCsS 8pXW8P9iqb0DsVkrdSG/O9E8gYwuWEyCrJJBHFlN/01zbMmG4kV5tpfeGiox9G7ALuoF Rg2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724076805; x=1724681605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7GY2pg58I31qfq65qko/hLtGTfiveWsJAXY/P+iSQvc=; b=kC3DBkvVLj8rHw/ug2UnZX+zLDLjFnfsxaIfq5iyEKJkpYUqty0LWQZ4WIcKqKZhjC uLVzSPxU3l6OX9Tu3qBEHQf1FCd2Zdl8GoUmJL64MYdot5azS5bhE6CEmSKvaK3Cjw2H TTAqXzXSO18c22jRCBNMRjPxtbYrHaCbnaefvDNs0+ULU3h7e3IPpa4nNx7Hox4+c/KQ WOQtap/a9u0hgv1qxyLb2uj+VzcDFT7HMHngVWS+O3wdqHvhD1zd/imLXsEEeviXWdT/ 5/gpAuQRi5wo+sFmKEXULXvzSOcpHFy0vu4HHJVPaLvIKD98hkRUxudHN/zY/MKVk789 Wa8g== X-Forwarded-Encrypted: i=2; AJvYcCVydsbXup/kEYgPB5BgvNRXdSTF3fC3mEIFfQ8fglwLINZgR2M2J67xSO0ps1dfln5yw/LCFE17gVka@gnusha.org X-Gm-Message-State: AOJu0YwayDjZEsEokU4KvNZzqKJ7oOOCZ7kU79dHMQ4kYBp6BnlYkHgk sRsem4sunrlsBZlSZo95ua5TPNW4KpFNfcHuF8fSqA/ONG5ImAl6 X-Google-Smtp-Source: AGHT+IEJZ3A8kuUP+twcpxGot1q0wXPf5miwrjxyk94ovDch6iSL+wmDxtRNLttJeNd7rh2gRGQCtg== X-Received: by 2002:a05:6214:4608:b0:6bd:70ce:e413 with SMTP id 6a1803df08f44-6bf7cdef914mr134911116d6.30.1724076804807; Mon, 19 Aug 2024 07:13:24 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6214:2a89:b0:6bd:7218:a1b5 with SMTP id 6a1803df08f44-6bf6d8ba584ls69744396d6.1.-pod-prod-07-us; Mon, 19 Aug 2024 07:13:22 -0700 (PDT) X-Received: by 2002:a05:6214:763:b0:6bb:8b90:2dd6 with SMTP id 6a1803df08f44-6bf7cdceca9mr10993226d6.4.1724076802186; Mon, 19 Aug 2024 07:13:22 -0700 (PDT) Received: by 2002:a05:620a:c04:b0:7a1:d643:94b4 with SMTP id af79cd13be357-7a64cc483a3ms85a; Mon, 19 Aug 2024 06:16:57 -0700 (PDT) X-Received: by 2002:a17:906:bc17:b0:a7a:d1ba:af30 with SMTP id a640c23a62f3a-a8392a491f6mr704464666b.57.1724073415256; Mon, 19 Aug 2024 06:16:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1724073415; cv=none; d=google.com; s=arc-20160816; b=0O1PwqpSG/9ce6BeWUZLTU2EX6J4AXUR++SxPWmchdDF+INwLeX/DMJWYx3fpZmf1I tGETaCgpDuMTElHyiaQOgnN6EnieMNJZWlmz+Io7HHVdxbJMp+zO1xF/+nkLq50Z6Kra D8BdVuw0kPQknLhBdRcB9BkKw1twCfvJcHJfpQw0JfYiTcaqMeNozCGE5krD8f4V6nYG +hjsswVQsVJwoCCKAHfeLsmreEX7ESB8lCE2bfHzCPvlYuk9GiS8nSvTBBw2pStUKUks MyrrkUXuwew4q+XBK0wpc6Ry/Ad2CNjcqfGmlXu0btU1XV73PcNhoWd/2AH6p9DtArYH 82iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=4Nu+IE9NF+QlCZpNdhKzAYF72ogROs+VMCUrFEDVjKs=; fh=+67N2uHR2MfeB757DuDnNuhtYMQ1l3OX1mrsWyqvKgo=; b=EHYGY/+z1DVZis9L7Cb22hi740/5xSQgYPXkvXbQFwrCcmEjtp3FdD5iptF2pwY5Uv P4+HeSKfvrNgFW2Ewbmw/Teem4r1CognTOm+j10GuSzFFYj2TAoYRc4tcW0VUaR6A3JZ mxnYuWUMOb3ukCngzXjZWP4H3ucPDzMXfAgu1/aISXWMsd7WGpyXsAeZaIcc/49TQ1/B XOLrc3v6c6zFy6YIC+97qKvIbzbFm6E7MO9avtXNLgx/h86JbH1YZllcNKuMI0qh/wiS n+8bdnovHRCkNgz5qeidbTlNae/aT+MzgVJ83DPkj6wLg+CZZAcXW5lXqPmHq7WRFe2p /fYw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=ze1AxgKw; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.40.133 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch. [185.70.40.133]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-a838393be6asi24033666b.2.2024.08.19.06.16.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Aug 2024 06:16:55 -0700 (PDT) Received-SPF: pass (google.com: domain of fjahr@protonmail.com designates 185.70.40.133 as permitted sender) client-ip=185.70.40.133; Date: Mon, 19 Aug 2024 13:16:48 +0000 To: /dev /fd0 From: "'Fabian' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling Message-ID: In-Reply-To: <29d850d1-912a-4b15-ba41-cc36d05e7074n@googlegroups.com> References: <29d850d1-912a-4b15-ba41-cc36d05e7074n@googlegroups.com> Feedback-ID: 5067558:user:proton X-Pm-Message-ID: 805f2a0c629b7b68e6b5846324a984f2e5729845 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_OH1wDazyaJUoxvHNZiriE0J85W6k98obUAD91PPZOk" X-Original-Sender: fjahr@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=ze1AxgKw; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.40.133 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Fabian Reply-To: Fabian 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: -1.0 (-) This is a multi-part message in MIME format. --b1_OH1wDazyaJUoxvHNZiriE0J85W6k98obUAD91PPZOk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, that would be a NACK from me. I think this idea has many issues, I am just = listing the ones that came to my head first: - Requiring users to make transactions in order to participate in order to = signal is problematic because it comes with economic costs to them that dep= ends a lot on their personal setup. What if they have their funds in a vaul= t? Then they have to go through a lengthy and costly process to get them ou= t. Or if they simply timelocked them for a number of years? Then they can n= ot participate at all. - Motivated spammers can, however, simulate support for low costs if they h= ave the right setup. I would guess spammers have a few UTXOs laying around = in hot wallets and would be willing to invest some money if it serves their= interests. - Depending on whether the users pay high or low fees in these signaling tr= ansactions, they can choose their own adventure of misaligned incentives... - If the users pay high fees in these transactions some miners that don't c= are about this will just mine the transaction not because they want to sign= al but instead because it serves their economic interest. This means you wo= uld need buy-in from all miners (template builders) in the world for this t= o work on not get seemingly great signaling for these high fee transactions= even though the miners just want to earn the fees and may not even know ab= out a softfork proposal. - If the miners pay low fees still all miners that offer out of band accele= ration of transactions would need to buy-in and not allow these transaction= s to be boosted to prevent manipulation. - The low fee transactions would still need to be kept in a mempool somewhe= re to prevent manipulation via eviction from mempools or the signaling tran= sactions simply disappearing. Keeping a transaction in the mempool has many= problems which is apparent from all the L2 research that is going into thi= s topic. - As far as I can tell there are some ordinal protocols that use the lock t= ime field for something, how do you keep these two concepts apart? - "Community can analyze these transactions" That won't work. What do you d= efine as the lock-in mechanism? I suppose you would count the number of blo= cks that had at least one signaling transaction in them. Ok, that could wor= k but that would mean that it's really not a lot of transactions that would= need to get into blocks via one of the manipulation methods I mentioned ab= ove. - Thinking more about the previous point: Users broadcasting their own tran= sactions with signaling is really just an unnecessary misdirection. If a mi= ner signals by including these transactions in a block it doesn't matter if= they include one or 100 of these in a block. A block can just signal or no= t signal. So it would probably play out in a way that users wouldn't send a= ny signaling transactions and miners would just include a single signaling = self payment in their block template. Which then is just a worse way of doi= ng the signaling with the version field. - I also don't think that the readiness signaling mechanism is actually the= reason why bip8/9 are controversial so I don't think your proposal really = would make things better even if the signaling part would work well. That was bit ramblin, so, to summarize the top 3 issues I could come up wit= h off the top of my head why this wouldn't work: - Miners may "signal" by including high fee transactions even though they d= on't know about the process at all - Users (if they would even need/want to participate) would bare economic c= ost or may even have excluded themselves from the process already without k= nowing it - Spammers have many avenues today to exploit this mechanism at minimal cos= t, all of these loop holes would need to be closed/defended If you want to follow up please first take a look at the level of detail th= at BIP8 and BIP9 provide and try to get your proposal at least somewhere cl= ose to that level of detail if you want to have it taken serious as a BIP p= roposal. Otherwise, if this is just an idea or a question then maybe make i= t a Stack Exchange question or maybe a delving bitcoin post. And please don't self-assign BIP numbers, it's irritating. Best, Fabian On Monday, August 19th, 2024 at 7:08 AM, /dev /fd0 = wrote: > Hi Bitcoin Developers, > > I am proposing an alternative way to activate soft forks. Please let me k= now if you see any issues with this method. > > BIP: XXX > Layer: Consensus (soft fork) > Title: nLockTime signaling and flag day activation > Author: /dev/fd0 > Status: Draft > Type: Standards Track > Created: 2024-08-19 > License: Public Domain > > ## Abstract > > This document describes a process to activate soft forks using flag day a= fter `nLockTime` signaling and discussion. > > ## Motivation > > BIP 8 and BIP 9 are controversial. This BIP is an alternative which addre= sses the problems with other activation methods. > > ## Specification > > - Assign numbers to different soft fork proposals or use their BIP number= s > - Users can broadcast their transactions with one of these numbers used a= s `nLockTime` to show support > - Miners inlcuding a transaction in block would signal readiness for a so= ft fork > - Community can analyze these transactions after 3 months and prepare for= a flag day activation of soft fork > > Example: > Use 119 to signal support for OP_CHECKTEMPLATEVERIFY in `nLockTime` > > ## Reference implementation > > Activation: https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86b= b2043c24f0f377f1cf514.diff > > Exclusion in relay or mining: https://github.com/bitcoinknots/bitcoin/com= mit/18cd7b0ef6eaeacd06678c6d192b6cacc9d7eee5.diff > > --- > > If a transaction does not get included in block for a long time, users ca= n replace it with another transaction spending same inputs and use a differ= ent `nLockTime`. > > /dev/fd0 > floppy disk guy > > -- > 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 on the web visit https://groups.google.com/d/msgi= d/bitcoindev/29d850d1-912a-4b15-ba41-cc36d05e7074n%40googlegroups.com. --=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 on the web visit https://groups.google.com/d/msgid/= bitcoindev/KvOQPbOdGzE0_dViIN57KDCx8X-HdOLNKc8xM9y83vbyxVgujA1YI8MTzFsWV7wB= IrQ8nBEzHxVhGt54H20t--FiRh3_iTvJeqqgaAOgZs0%3D%40protonmail.com. --b1_OH1wDazyaJUoxvHNZiriE0J85W6k98obUAD91PPZOk Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

that would be = a NACK from me. I think this idea has many issues, I am just listing the on= es that came to my head first:

  • Requiring users to make transactions in order to partici= pate in order to signal is problematic because it comes with economic costs= to them that depends a lot on their personal setup. What if they have thei= r funds in a vault? Then they have to go through a lengthy and costly proce= ss to get them out. Or if they simply timelocked them for a number of years= ? Then they can not participate at all.
  • Motivated spammers can, however, simulate support fo= r low costs if they have the right setup. I would guess spammers have a few= UTXOs laying around in hot wallets and would be willing to invest some mon= ey if it serves their interests.
  • Depending on whether the users pay high or low fees in these signa= ling transactions, they can choose their own adventure of misaligned incent= ives...
  • If the users pay= high fees in these transactions some miners that don't care about this wil= l just mine the transaction not because they want to signal but instead bec= ause it serves their economic interest. This means you would need buy-in fr= om all miners (template builders) in the world for this to work on not get = seemingly great signaling for these high fee transactions even though the m= iners just want to earn the fees and may not even know about a softfork pro= posal.
  • If the miners pay= low fees still all miners that offer out of band acceleration of transacti= ons would need to buy-in and not allow these transactions to be boosted to = prevent manipulation.
  • Th= e low fee transactions would still need to be kept in a mempool somewhere t= o prevent manipulation via eviction from mempools or the signaling transact= ions simply disappearing. Keeping a transaction in the mempool has many pro= blems which is apparent from all the L2 research that is going into this to= pic.
  • As far as I can tel= l there are some ordinal protocols that use the lock time field for somethi= ng, how do you keep these two concepts apart?
  • "Wh= at do you define as the lock-in mechanism? I suppose you would count the nu= mber of blocks that had at least one signaling transaction in them. Ok, tha= t could work but that would mean that it's really not a lot of transactions= that would need to get into blocks via one of the manipulation methods I m= entioned above.
  • Thinking= more about the previous point: Users broadcasting their own transactions w= ith signaling is really just an unnecessary misdirection. If a miner signal= s by including these transactions in a block it doesn't matter if they incl= ude one or 100 of these in a block. A block can just signal or not signal. = So it would probably play out in a way that users wouldn't send any signali= ng transactions and miners would just include a single signaling self payme= nt in their block template. Which then is just a worse way of doing the sig= naling with the version field.
  • I also don't think that the readiness signaling mechanism is actuall= y the reason why bip8/9 are controversial so I don't think your proposal re= ally would make things better even if the signaling part would work well.

That was bit ramblin, so, to summarize the top = 3 issues I could come up with off the top of my head why this wouldn't work= :
  • Miners may "signal" by including high fee transactions even though they do= n't know about the process at all
  • Users (if they would even need/want to participate) would bare ec= onomic cost or may even have excluded themselves from the process already w= ithout knowing it
  • Spamme= rs have many avenues today to exploit this mechanism at minimal cost, all o= f these loop holes would need to be closed/defended

If you want to follow up please first take a look at the level of det= ail that BIP8 and BIP9 provide and try to get your proposal at least somewh= ere close to that level of detail if you want to have it taken serious as a= BIP proposal. Otherwise, if this is just an idea or a question then maybe = make it a Stack Exchange question or maybe a delving bitcoin post.

And please don't self-assign BIP numbers, it's irritating.=

Best,
Fabian
On Monday, August 19th, 2024 at 7:08 AM, /dev /fd0 <alicexbtong@= gmail.com> wrote:
Hi Bitcoin Developers,

I am proposing an alt= ernative way to activate soft forks. Please let me know if you see any issu= es with this method.

BIP: XXX
Layer: Consensus (soft fo= rk)
Title: nLockTime signaling and flag day activation
Auth= or: /dev/fd0 <alicexbt@protonmail.com>
Status: Draft
= Type: Standards Track
Created: 2024-08-19
License: Publ= ic Domain

## Abstract

This document describes a process to ac= tivate soft forks using flag day after `nLockTime` signaling and discussion= .

## Motivation

BIP 8 and BIP 9 are controversial. This BIP i= s an alternative which addresses the problems with other activation methods= .

## Specification

- Assign numbers to different soft fork pr= oposals or use their BIP numbers
- Users can broadcast their transaction= s with one of these numbers used as `nLockTime` to show support
- Miners= inlcuding a transaction in block would signal readiness for a soft fork- Community can analyze these transactions after 3 months and prepare for = a flag day activation of soft fork

Example:
Use 119 to signal sup= port for OP_CHECKTEMPLATEVERIFY in `nLockTime`

## Reference implemen= tation

Activation: https://github.com/bitcoin/bitcoin/commit/ab= 91bf39b7c11e9c86bb2043c24f0f377f1cf514.diff

Exclusion in relay o= r mining: https://github.com/bitcoinknots/bitcoin/commit/18cd7b0e= f6eaeacd06678c6d192b6cacc9d7eee5.diff

---

If a transactio= n does not get included in block for a long time, users can replace it with= another transaction spending same inputs and use a different `nLockTime`.<= br>
/dev/fd0
floppy disk guy

--
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 on the web visit https://groups.= google.com/d/msgid/bitcoindev/29d850d1-912a-4b15-ba41-cc36d05e7074n%40googl= egroups.com.

--
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 on the web visit https://groups.google.com/d/msgid/b= itcoindev/KvOQPbOdGzE0_dViIN57KDCx8X-HdOLNKc8xM9y83vbyxVgujA1YI8MTzFsWV7wBI= rQ8nBEzHxVhGt54H20t--FiRh3_iTvJeqqgaAOgZs0%3D%40protonmail.com.
--b1_OH1wDazyaJUoxvHNZiriE0J85W6k98obUAD91PPZOk--