path: root/02/aa70aba3129e274ae448d826cccec885507d97

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 <bitcoindev+bncBDPK3QN7WUBRBAVGRW3AMGQE4ALF3MA@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <alicexbtong@gmail.com>
From: "'Fabian' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
Message-ID: <KvOQPbOdGzE0_dViIN57KDCx8X-HdOLNKc8xM9y83vbyxVgujA1YI8MTzFsWV7wBIrQ8nBEzHxVhGt54H20t--FiRh3_iTvJeqqgaAOgZs0=@protonmail.com>
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 <fjahr@protonmail.com>
Reply-To: Fabian <fjahr@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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 <alicexbtong@gmail.com> =
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 <alicexbt@protonmail.com>
> 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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Hi,</div><d=
iv style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><di=
v style=3D"font-family: Arial, sans-serif; font-size: 14px;">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:</div><div style=3D"font-family: Arial, sans-=
serif; font-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-s=
erif; font-size: 14px;"><ul data-editing-info=3D"{&quot;orderedStyleType&qu=
ot;:1,&quot;unorderedStyleType&quot;:2}"><li style=3D"list-style-type: &quo=
t;- &quot;;"><span>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.</span></li><li style=3D"list-style-=
type: &quot;- &quot;;">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.</li><li style=3D"list-style-type: &quot;- =
&quot;;">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...</li><li style=3D"list-style-type: &quot;- &quot;;">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.</li><li style=3D"list-style-type: &quot;- &quot;;">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.</li><li style=3D"list-style-type: &quot;- &quot;;">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.</li><li style=3D"list-style-type: &quot;- &quot;;">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?</li><li style=3D"list-style-t=
ype: &quot;- &quot;; font-family: system-ui, sans-serif;">"<span style=3D"f=
ont-family:system-ui, sans-serif;text-align:start;display:inline !important=
">Community can analyze these transactions" That won't work.&nbsp;</span>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.</li><li style=3D"list-style-type: &quot;- &quot;;">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.</li><li style=3D"list-style-type: &quot;- &q=
uot;;">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.</=
li></ul><div><br></div><div>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=
:</div><div><ul data-editing-info=3D"{&quot;orderedStyleType&quot;:1,&quot;=
unorderedStyleType&quot;:2}"><li style=3D"list-style-type: &quot;- &quot;;"=
>Miners may "signal" by including high fee transactions even though they do=
n't know about the process at all</li><li style=3D"list-style-type: &quot;-=
 &quot;;">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</li><li style=3D"list-style-type: &quot;- &quot;;">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</li></ul><div><br></div=
><div>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.</div><di=
v><br></div><div>And please don't self-assign BIP numbers, it's irritating.=
</div><div><br></div></div><div>Best,</div><div>Fabian</div></div><div clas=
s=3D"protonmail_quote">
        On Monday, August 19th, 2024 at 7:08 AM, /dev /fd0 &lt;alicexbtong@=
gmail.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            Hi Bitcoin Developers,<div><br></div><div>I am proposing an alt=
ernative way to activate soft forks. Please let me know if you see any issu=
es with this method.<br><br>    BIP: XXX  <br>    Layer: Consensus (soft fo=
rk)  <br>    Title: nLockTime signaling and flag day activation<br>    Auth=
or: /dev/fd0 &lt;alicexbt@protonmail.com&gt;  <br>    Status: Draft  <br>  =
  Type: Standards Track  <br>    Created: 2024-08-19  <br>    License: Publ=
ic Domain<br><br>## Abstract<br><br>This document describes a process to ac=
tivate soft forks using flag day after `nLockTime` signaling and discussion=
.<br><br>## Motivation<br><br>BIP 8 and BIP 9 are controversial. This BIP i=
s an alternative which addresses the problems with other activation methods=
.<br><br>## Specification<br><br>- Assign numbers to different soft fork pr=
oposals or use their BIP numbers<br>- Users can broadcast their transaction=
s with one of these numbers used as `nLockTime` to show support<br>- Miners=
 inlcuding a transaction in block would signal readiness for a soft fork<br=
>- Community can analyze these transactions after 3 months and prepare for =
a flag day activation of soft fork<br><br>Example:<br>Use 119 to signal sup=
port for OP_CHECKTEMPLATEVERIFY in `nLockTime`<br><br>## Reference implemen=
tation<br><br>Activation: <a href=3D"https://github.com/bitcoin/bitcoin/com=
mit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514.diff" target=3D"_blank" rel=3D=
"noreferrer nofollow noopener">https://github.com/bitcoin/bitcoin/commit/ab=
91bf39b7c11e9c86bb2043c24f0f377f1cf514.diff</a><br><br>Exclusion in relay o=
r mining: <a href=3D"https://github.com/bitcoinknots/bitcoin/commit/18cd7b0=
ef6eaeacd06678c6d192b6cacc9d7eee5.diff" target=3D"_blank" rel=3D"noreferrer=
 nofollow noopener">https://github.com/bitcoinknots/bitcoin/commit/18cd7b0e=
f6eaeacd06678c6d192b6cacc9d7eee5.diff</a><br><br>---<br><br>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><br>/dev/fd0<br>floppy disk guy</div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer nofollow noopener">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/29d850d1-912a-4b15-ba41-cc36d05e7074n%40googlegroups.=
com" target=3D"_blank" rel=3D"noreferrer nofollow noopener">https://groups.=
google.com/d/msgid/bitcoindev/29d850d1-912a-4b15-ba41-cc36d05e7074n%40googl=
egroups.com</a>.<br>

        </blockquote><br>
    </div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/KvOQPbOdGzE0_dViIN57KDCx8X-HdOLNKc8xM9y83vbyxVgujA1YI=
8MTzFsWV7wBIrQ8nBEzHxVhGt54H20t--FiRh3_iTvJeqqgaAOgZs0%3D%40protonmail.com?=
utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/b=
itcoindev/KvOQPbOdGzE0_dViIN57KDCx8X-HdOLNKc8xM9y83vbyxVgujA1YI8MTzFsWV7wBI=
rQ8nBEzHxVhGt54H20t--FiRh3_iTvJeqqgaAOgZs0%3D%40protonmail.com</a>.<br />

--b1_OH1wDazyaJUoxvHNZiriE0J85W6k98obUAD91PPZOk--