path: root/28/ab74287ca90844565cfc72b88c77760dd3c09a

Delivery-date: Thu, 22 Aug 2024 05:57:22 -0700
Received: from mail-yb1-f192.google.com ([209.85.219.192])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCU2P6FJ3EBBBKHLTS3AMGQEFVM3K2A@googlegroups.com>)
	id 1sh7NQ-0002fL-Se
	for bitcoindev@gnusha.org; Thu, 22 Aug 2024 05:57:22 -0700
Received: by mail-yb1-f192.google.com with SMTP id 3f1490d57ef6-e03623b24ddsf1433755276.1
        for <bitcoindev@gnusha.org>; Thu, 22 Aug 2024 05:57:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1724331434; x=1724936234; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=zOmwCmim/XxTkw79GiSjVvpnp8cHsMr3HPW7OdH/pAo=;
        b=t3NZfxZu7vmaXmEd3Y6VhNiCanEq/VyaK7P68UXobgsrHlQVlvhvo5d5Ge6RdRHp6Q
         yEPQx90n2Qoo5uRBlm2gdRySebBcZqnl27PxNjgiwCcduIh1ETsbkK2plVrm9uUBqjYB
         JgTBhmMt0T/C5dSTMEDFqXJ3UoVZ6nxQPwCG+gPqeix34k6kO0zjr8Fy4CovT2D9To4y
         6kjat/0hrN64lyPmgGXc34p+VvYrmum04gzmckxpgkB8im2onYu1U2hHS5tQJlaDeLej
         dNSa0BinMdhNUTs/WMUpmD/nshrAZAYquIgCYOIu9y1i4eBUk22pKYRfkfLrncFm0UJN
         dL1w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1724331434; x=1724936234; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=zOmwCmim/XxTkw79GiSjVvpnp8cHsMr3HPW7OdH/pAo=;
        b=lKbQL+qJd7LyQ2zZ34vvIqfC04uAtQdxCLcjqEP8KeCCx6ltuVSXKNk+1Lpeh08Xfy
         R4uUZKpqkSIy4lSj1NfhtHszFCEl472nIKnd3HgSbQcJS2YMGmFc+9Q840A69E2UBf+X
         g0WXtxriZn3TzIcAH11NSINIU6OEkjM/iZTzlRbnAqCLtw3LJfGU/gOSwnBei0q/tQUA
         yqmAryU2NMX37CaET78BIBzHBR42CnWFuX68WbGMzId73/V4+FR0EfEUvYa7ZK9tCs1w
         0ArXKa6VzOe9WtOo/txaToCyZSznSc9+HbZONnvKV8Vpnf/13hMda49sDcs02uhZRJ+2
         mylQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1724331434; x=1724936234;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=zOmwCmim/XxTkw79GiSjVvpnp8cHsMr3HPW7OdH/pAo=;
        b=CGsFFoLR9FCzQwNjsrXOFJ+JnCcUiILo1GT+/oosfY//gYjWT9wMRISzvR5grrthkK
         jRw2DN/l/XKE16uh6BLMOoZcUmQcja6/GJBZUXOc4CosFT3zOviN9bgUAVJNqPsV+JlG
         R/iIiaG03KAH+OUihqnqT/BzH1k/fWVUVVc4RkArHyjJJTz0wHWPWQdwMLb5lTX3dEtn
         Vm3KFb29pdigwFDSu8lrdi/pHC5Iq1EJ/QAUiBY4iIn6K8OM3GU9I0aC1GQjac4+duJQ
         z8uUL6rjfPvyd2VrjQAMQ/in8vzPkjKk3RlSrvPdCJs5oOIF3xvnKvJ1AQj4f5Caanvt
         i3Rg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWlB1IT2ROMF7udZhHrn8JB2ih36GZI8zWWy3xsYXbjC3juAxgu4PCJuMZ/TTaRHoSzwzbHSEZkjbIy@gnusha.org
X-Gm-Message-State: AOJu0YxqgpSzzlrr3aasvtzTUb+bkPryFGLBCNDTDdKT5JJJMDfI9j1N
	4N8duvQc9Mww+5YecbaCEQW644paFnnjQDc9etqySEeNi7kIeFU+
X-Google-Smtp-Source: AGHT+IFAElbkFkSRnoU8D3L4J3zormRG4iRyj3XLFr5RKzuz1kpDK1KchrcqN4zsWpBxKS63YJTq+g==
X-Received: by 2002:a25:2607:0:b0:e16:6c22:811a with SMTP id 3f1490d57ef6-e166c22865emr5048146276.9.1724331433924;
        Thu, 22 Aug 2024 05:57:13 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:18c4:b0:e05:a345:25b6 with SMTP id
 3f1490d57ef6-e178b862d00ls999010276.0.-pod-prod-07-us; Thu, 22 Aug 2024
 05:57:11 -0700 (PDT)
X-Received: by 2002:a05:690c:3185:b0:6ad:feb0:d01c with SMTP id 00721157ae682-6c09c3adab3mr1191277b3.3.1724331431818;
        Thu, 22 Aug 2024 05:57:11 -0700 (PDT)
Received: by 2002:a05:690c:2a44:b0:627:7f59:2eee with SMTP id 00721157ae682-6c0ebefe879ms7b3;
        Thu, 22 Aug 2024 04:44:00 -0700 (PDT)
X-Received: by 2002:a05:690c:6703:b0:65f:96e9:42f4 with SMTP id 00721157ae682-6c3054f31c8mr28288787b3.15.1724327039732;
        Thu, 22 Aug 2024 04:43:59 -0700 (PDT)
Date: Thu, 22 Aug 2024 04:43:59 -0700 (PDT)
From: /dev /fd0 <alicexbtong@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <00e0601c-ed59-4245-a79d-0c36f1c8795bn@googlegroups.com>
In-Reply-To: <4de6a775-f9ed-44f0-bc93-7e74d64e36ad@murch.one>
References: <29d850d1-912a-4b15-ba41-cc36d05e7074n@googlegroups.com>
 <4de6a775-f9ed-44f0-bc93-7e74d64e36ad@murch.one>
Subject: Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_286830_41419725.1724327039493"
X-Original-Sender: alicexbtong@gmail.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: -0.5 (/)

------=_Part_286830_41419725.1724327039493
Content-Type: multipart/alternative; 
	boundary="----=_Part_286831_750641228.1724327039493"

------=_Part_286831_750641228.1724327039493
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Murch,

Thanks for reviewing the BIP draft and suggesting improvements.

>  I would suggest the following areas of
improvement

I have answered other responses and will reply to your feedback below. I=20
will improve motivation section and add rationale, backwards compatibility,=
=20
syntax etc. by first week of September.

>  I appreciate that the signaling mechanism you propose would introduce
a cost to signaling.=20

This isn't the primary goal of the BIP but exists because bitcoin=20
transactions require fees. Otherwise paid voting is possible on nostr using=
=20
polls.

> if you were going to make a transaction anyway, it=E2=80=99s free, but ot=
herwise=20
you would have to pay to get your signal out there.

The real signal we need to analyze after 3 months comes from users who=20
participate in this signaling with transactions that were going to happen=
=20
anyway. These are the users with some economic activity whose opinion=20
matters the most for changes in consensus rules.=20

> Someone that may have sent a batched payments transaction might consider=
=20
splitting it into multiple separate transactions instead to increase their=
=20
signaling

This depends on the analysis and I would give more weight to the batch=20
payment using nLockTime for signaling.

> Either way, it would be better to use the field for anti-fee sniping,=20
which also is not compatible with your signaling mechanism.

Lot of transactions use zero as nLockTime so signaling could work fine for=
=20
at least next 12 years:=20
https://blockchair.com/bitcoin/transactions?s=3Dtime(desc)&q=3Dlock_time(0)=
,time(2024-01-01..)#f=3Dtime,lock_time

> Most wallet software does not support setting the locktime manually, so=
=20
some users that might want to signal support cannot without switching=20
software.

This signaling is mainly targeting economic nodes and I think most of them=
=20
would be able to do it. I will also create a website which can be used to=
=20
enter unsigned PSBT and change its nLockTime.

> This introduces a new fingerprint for transactions pertaining to software=
=20
that supports setting locktime manually.

I am not sure if this can be used to track anything meaningful which=20
affects privacy.

> A transaction can only set a single nLockTime value, so if there are=20
multiple proposals that are up for debate, a transaction can only signal=20
support for one. This could side-stepped by using nLockTime as a bit array=
=20
where each position signals support for one proposal, much like BIP=E2=80=
=AF9.

I like the idea of using bit array and I will update the draft accordingly.

> but it=E2=80=99s unclear why one out of thousands of transactions should =
be=20
relevant whatsoever. Unless a very large portion of transactions signals=20
support, I=E2=80=99m not sure what we would learn from this signal at all.

This depends on analysis and could be interpreted differently. Let me share=
=20
an example:

Alice and Bob analyze these transactions after 3 months. Some blocks had=20
only 1 transaction that signaled support for a soft fork proposal. Alice=20
marked them red and don't consider helpful or at the bottom in analysis=20
report. Bob looked at each transaction and considered some different from=
=20
others. In a transaction, Bitfinex moved some bitcoin from hot wallet to=20
cold storage so it was given some weight over others and marked with a=20
different color.

> Your proposal does not allow distinguishing between apathy and=20
opposition: not signaling could mean either.

I agree that proposal is focused on looking at support and not opposition.=
=20
Still it could be visible if some nodes and miners try to reject these=20
transactions. If someone really has a genuine problem with any of these=20
soft forks, best way to share it would be a technical review, test etc.=20
posted on mailing list.

> You suggest that miners could choose to exclude signaling transactions if=
=20
they are not ready, but it is much simpler for miners to do nothing, so the=
=20
inclusion of signaling transactions cannot be interpreted as an endorsement=
.

Miners never endorse any soft forks. Neither in this BIP nor BIP 8/9.=20
Miners should always be ready for soft forks, but a coordination exercise=
=20
before activation is always a safe approach in a decentralized network.

/dev/fd0
floppy disk guy


On Wednesday, August 21, 2024 at 2:14:48=E2=80=AFPM UTC Murch wrote:

> Hello floppy and list,
>
> On 8/19/24 01:08, /dev /fd0 wrote:
> > Hi Bitcoin Developers,
> >
> > I am proposing an alternative way to activate soft forks. Please let
> > me know if you see any issues with this method.
>
> While your proposal may address some of the criticisms leveled at BIP=E2=
=80=AF8=20
> and BIP=E2=80=AF9, it introduces new problems.
>
> 1. I appreciate that the signaling mechanism you propose would introduce=
=20
> a cost to signaling. Unfortunately, this cost is unevenly distributed:=20
> if you were going to make a transaction anyway, it=E2=80=99s free, but ot=
herwise=20
> you would have to pay to get your signal out there. It may also lead to=
=20
> a distortion of usage. Someone that may have sent a batched payments=20
> transaction might consider splitting it into multiple separate=20
> transactions instead to increase their signaling for a reduced cost=20
> compared to making transactions just for signaling, but increased=20
> blockspace demand compared to their batched payments transaction.
>
> 2. The `nLockTime` field is not unused. Transactions that have to set it=
=20
> to make use of other protocol functions are inherently prevented from=20
> signaling. Either way, it would be better to use the field for anti-fee=
=20
> sniping, which also is not compatible with your signaling mechanism.
>
> 3. Most wallet software does not support setting the locktime manually,=
=20
> so some users that might want to signal support cannot without switching=
=20
> software.
>
> 4. This introduces a new fingerprint for transactions pertaining to=20
> software that supports setting locktime manually.
>
> 5. A transaction can only set a single nLockTime value, so if there are=
=20
> multiple proposals that are up for debate, a transaction can only signal=
=20
> support for one. This could side-stepped by using nLockTime as a bit=20
> array where each position signals support for one proposal, much like=20
> BIP=E2=80=AF9.
>
> 6. As already surfaced in your conversation with Fabian, it is up for=20
> debate how the signaling data later would be interpreted. You mention=20
> that spam could later be excluded, and blocks that include at least one=
=20
> transaction that signals would be some sort of signal, but it=E2=80=99s u=
nclear=20
> why one out of thousands of transactions should be relevant whatsoever.=
=20
> Unless a very large portion of transactions signals support, I=E2=80=99m =
not=20
> sure what we would learn from this signal at all.
>
> 7. Your proposal does not allow distinguishing between apathy and=20
> opposition: not signaling could mean either.
>
> 8. You suggest that miners could choose to exclude signaling=20
> transactions if they are not ready, but it is much simpler for miners to=
=20
> do nothing, so the inclusion of signaling transactions cannot be=20
> interpreted as an endorsement.
>
> Overall, this approach does not seem expedient to me, but should you=20
> choose to maturate this proposal, I would suggest the following areas of=
=20
> improvement:
>
> - The proposal should address the questions brought up above and by=20
> other responses
> - The motivation should describe in more detail the existing issues that=
=20
> are being addressed, and how this proposal mitigates them
> - A rationale section should explain design choices, and put the=20
> proposal into the context of alternate designs and related work
> - A backwards compatibility section should address how implementers=20
> should think about this proposal in the context of other uses of=20
> nLockTime such as anti-fee sniping
> - The specification should describe the syntax and semantics in=20
> sufficient detail for other developers to implement the proposal
>
> Cheers,
>
> Murch
>
> >=20
> > BIP: XXX
> > Layer: Consensus (soft fork)
> > Title: nLockTime signaling and flag day activation
> > Author: /dev/fd0 <alic...@protonmail.com>
> > Status: Draft
> > Type: Standards Track
> > Created: 2024-08-19
> > License: Public Domain
> >=20
> > ## Abstract
> >=20
> > This document describes a process to activate soft forks using flag day
> > after `nLockTime` signaling and discussion.
> >=20
> > ## Motivation
> >=20
> > BIP 8 and BIP 9 are controversial. This BIP is an alternative which
> > addresses the problems with other activation methods.
> >=20
> > ## Specification
> >=20
> > - Assign numbers to different soft fork proposals or use their BIP=20
> numbers
> > - Users can broadcast their transactions with one of these numbers used=
=20
> as
> > `nLockTime` to show support
> > - Miners inlcuding a transaction in block would signal readiness for a=
=20
> soft
> > fork
> > - Community can analyze these transactions after 3 months and prepare=
=20
> for a
> > flag day activation of soft fork
> >=20
> > Example:
> > Use 119 to signal support for OP_CHECKTEMPLATEVERIFY in `nLockTime`
> >=20
> > ## Reference implementation
> >=20
> > Activation:
> >=20
> https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f3=
77f1cf514.diff
> >=20
> > Exclusion in relay or mining:
> >=20
> https://github.com/bitcoinknots/bitcoin/commit/18cd7b0ef6eaeacd06678c6d19=
2b6cacc9d7eee5.diff
> >=20
> > ---
> >=20
> > If a transaction does not get included in block for a long time, users=
=20
> can
> > replace it with another transaction spending same inputs and use a
> > different `nLockTime`.
> >=20
> > /dev/fd0
> > floppy disk guy
> >=20
>
>

--=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/00e0601c-ed59-4245-a79d-0c36f1c8795bn%40googlegroups.com.

------=_Part_286831_750641228.1724327039493
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Murch,<div><br /></div><div>Thanks for reviewing the BIP draft and sugge=
sting improvements.</div><div><br /></div><div>&gt;=C2=A0 I would suggest t=
he following areas of</div>improvement<div><br /></div><div>I have answered=
 other responses and will reply to your feedback below. I will improve moti=
vation section and add rationale, backwards compatibility, syntax etc. by f=
irst week of September.</div><div><br /></div><div>&gt;=C2=A0

I appreciate that the signaling mechanism you propose would introduce<br />=
a cost to signaling.=C2=A0</div><div><br /></div><div>This isn't the primar=
y goal of the BIP but exists because bitcoin transactions require fees. Oth=
erwise paid voting is possible on nostr using polls.</div><div><br /></div>=
<div>&gt; if you were going to make a transaction anyway, it=E2=80=99s free=
, but otherwise you would have to pay to get your signal out there.</div><d=
iv><br /></div><div>

The real signal we need to analyze after 3 months comes from users who part=
icipate in this signaling with transactions that were going to happen anywa=
y. These are the users with some economic activity whose opinion matters th=
e most for changes in consensus rules.=C2=A0</div><div><br /></div><div>&gt=
; Someone that may have sent a batched payments transaction might consider =
splitting it into multiple separate transactions instead to increase their =
signaling</div><div><br /></div><div>This depends on the analysis and I wou=
ld give more weight to the batch payment using nLockTime for signaling.</di=
v><div><br /></div><div>&gt; Either way, it would be better to use the fiel=
d for anti-fee sniping, which also is not compatible with your signaling me=
chanism.</div><div><br /></div><div>Lot of transactions use zero as nLockTi=
me so signaling could work fine for at least next 12 years:=C2=A0<a href=3D=
"https://blockchair.com/bitcoin/transactions?s=3Dtime(desc)&amp;q=3Dlock_ti=
me(0),time(2024-01-01..)#f=3Dtime,lock_time">https://blockchair.com/bitcoin=
/transactions?s=3Dtime(desc)&amp;q=3Dlock_time(0),time(2024-01-01..)#f=3Dti=
me,lock_time</a></div><div><br /></div><div>&gt; Most wallet software does =
not support setting the locktime manually, so some users that might want to=
 signal support cannot without switching software.</div><div><br /></div><d=
iv>This signaling is mainly targeting economic nodes and I think most of th=
em would be able to do it. I will also create a website which can be used t=
o enter unsigned PSBT and change its nLockTime.</div><div><br /></div><div>=
&gt; This introduces a new fingerprint for transactions pertaining to softw=
are that supports setting locktime manually.</div><div><br /></div><div>I a=
m not sure if this can be used to track anything meaningful which affects p=
rivacy.</div><div><br /></div><div>&gt; A transaction can only set a single=
 nLockTime value, so if there are multiple proposals that are up for debate=
, a transaction can only signal support for one. This could side-stepped by=
 using nLockTime as a bit array where each position signals support for one=
 proposal, much like BIP=E2=80=AF9.<br /><br />I like the idea of using bit=
 array and I will update the draft accordingly.</div><div><br /></div><div>=
&gt; but it=E2=80=99s unclear why one out of thousands of transactions shou=
ld be relevant whatsoever. Unless a very large portion of transactions sign=
als support, I=E2=80=99m not sure what we would learn from this signal at a=
ll.</div><div><br /></div><div>This depends on analysis and could be interp=
reted differently. Let me share an example:</div><div><br /></div><div>Alic=
e and Bob analyze these transactions after 3 months. Some blocks had only 1=
 transaction that signaled support for a soft fork proposal. Alice marked t=
hem red and don't consider helpful or at the bottom in analysis report. Bob=
 looked at each transaction and considered some different from others. In a=
 transaction, Bitfinex moved some bitcoin from hot wallet to cold storage s=
o it was given some weight over others and marked with a different color.</=
div><div><br /></div><div>&gt; Your proposal does not allow distinguishing =
between apathy and opposition: not signaling could mean either.</div><div><=
br /></div><div>I agree that proposal is focused on looking at support and =
not opposition. Still it could be visible if some nodes and miners try to r=
eject these transactions. If someone really has a genuine problem with any =
of these soft forks, best way to share it would be a technical review, test=
 etc. posted on mailing list.</div><div><br /></div><div>&gt; You suggest t=
hat miners could choose to exclude signaling transactions if they are not r=
eady, but it is much simpler for miners to do nothing, so the inclusion of =
signaling transactions cannot be interpreted as an endorsement.</div><div><=
br /></div><div>Miners never endorse any soft forks. Neither in this BIP no=
r BIP 8/9. Miners should always be ready for soft forks, but a coordination=
 exercise before activation is always a safe approach in a decentralized ne=
twork.</div><div><br /></div><div>/dev/fd0</div><div>floppy disk guy</div><=
div><br /></div><div><br /></div><div class=3D"gmail_quote"><div dir=3D"aut=
o" class=3D"gmail_attr">On Wednesday, August 21, 2024 at 2:14:48=E2=80=AFPM=
 UTC Murch wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1=
ex;">Hello floppy and list,
<br>
<br>On 8/19/24 01:08, /dev /fd0 wrote:
<br> &gt; Hi Bitcoin Developers,
<br> &gt;
<br> &gt; I am proposing an alternative way to activate soft forks. Please =
let
<br> &gt; me know if you see any issues with this method.
<br>
<br>While your proposal may address some of the criticisms leveled at BIP=
=E2=80=AF8=20
<br>and BIP=E2=80=AF9, it introduces new problems.
<br>
<br>1. I appreciate that the signaling mechanism you propose would introduc=
e=20
<br>a cost to signaling. Unfortunately, this cost is unevenly distributed:=
=20
<br>if you were going to make a transaction anyway, it=E2=80=99s free, but =
otherwise=20
<br>you would have to pay to get your signal out there. It may also lead to=
=20
<br>a distortion of usage. Someone that may have sent a batched payments=20
<br>transaction might consider splitting it into multiple separate=20
<br>transactions instead to increase their signaling for a reduced cost=20
<br>compared to making transactions just for signaling, but increased=20
<br>blockspace demand compared to their batched payments transaction.
<br>
<br>2. The `nLockTime` field is not unused. Transactions that have to set i=
t=20
<br>to make use of other protocol functions are inherently prevented from=
=20
<br>signaling. Either way, it would be better to use the field for anti-fee=
=20
<br>sniping, which also is not compatible with your signaling mechanism.
<br>
<br>3. Most wallet software does not support setting the locktime manually,=
=20
<br>so some users that might want to signal support cannot without switchin=
g=20
<br>software.
<br>
<br>4. This introduces a new fingerprint for transactions pertaining to=20
<br>software that supports setting locktime manually.
<br>
<br>5. A transaction can only set a single nLockTime value, so if there are=
=20
<br>multiple proposals that are up for debate, a transaction can only signa=
l=20
<br>support for one. This could side-stepped by using nLockTime as a bit=20
<br>array where each position signals support for one proposal, much like B=
IP=E2=80=AF9.
<br>
<br>6. As already surfaced in your conversation with Fabian, it is up for=
=20
<br>debate how the signaling data later would be interpreted. You mention=
=20
<br>that spam could later be excluded, and blocks that include at least one=
=20
<br>transaction that signals would be some sort of signal, but it=E2=80=99s=
 unclear=20
<br>why one out of thousands of transactions should be relevant whatsoever.=
=20
<br>Unless a very large portion of transactions signals support, I=E2=80=99=
m not=20
<br>sure what we would learn from this signal at all.
<br>
<br>7. Your proposal does not allow distinguishing between apathy and=20
<br>opposition: not signaling could mean either.
<br>
<br>8. You suggest that miners could choose to exclude signaling=20
<br>transactions if they are not ready, but it is much simpler for miners t=
o=20
<br>do nothing, so the inclusion of signaling transactions cannot be=20
<br>interpreted as an endorsement.
<br>
<br>Overall, this approach does not seem expedient to me, but should you=20
<br>choose to maturate this proposal, I would suggest the following areas o=
f=20
<br>improvement:
<br>
<br>- The proposal should address the questions brought up above and by=20
<br>other responses
<br>- The motivation should describe in more detail the existing issues tha=
t=20
<br>are being addressed, and how this proposal mitigates them
<br>- A rationale section should explain design choices, and put the=20
<br>proposal into the context of alternate designs and related work
<br>- A backwards compatibility section should address how implementers=20
<br>should think about this proposal in the context of other uses of=20
<br>nLockTime such as anti-fee sniping
<br>- The specification should describe the syntax and semantics in=20
<br>sufficient detail for other developers to implement the proposal
<br>
<br>Cheers,
<br>
<br>Murch
<br>
<br>&gt;=20
<br>&gt;      BIP: XXX
<br>&gt;      Layer: Consensus (soft fork)
<br>&gt;      Title: nLockTime signaling and flag day activation
<br>&gt;      Author: /dev/fd0 &lt;<a href data-email-masked rel=3D"nofollo=
w">alic...@protonmail.com</a>&gt;
<br>&gt;      Status: Draft
<br>&gt;      Type: Standards Track
<br>&gt;      Created: 2024-08-19
<br>&gt;      License: Public Domain
<br>&gt;=20
<br>&gt; ## Abstract
<br>&gt;=20
<br>&gt; This document describes a process to activate soft forks using fla=
g day
<br>&gt; after `nLockTime` signaling and discussion.
<br>&gt;=20
<br>&gt; ## Motivation
<br>&gt;=20
<br>&gt; BIP 8 and BIP 9 are controversial. This BIP is an alternative whic=
h
<br>&gt; addresses the problems with other activation methods.
<br>&gt;=20
<br>&gt; ## Specification
<br>&gt;=20
<br>&gt; - Assign numbers to different soft fork proposals or use their BIP=
 numbers
<br>&gt; - Users can broadcast their transactions with one of these numbers=
 used as
<br>&gt; `nLockTime` to show support
<br>&gt; - Miners inlcuding a transaction in block would signal readiness f=
or a soft
<br>&gt; fork
<br>&gt; - Community can analyze these transactions after 3 months and prep=
are for a
<br>&gt; flag day activation of soft fork
<br>&gt;=20
<br>&gt; Example:
<br>&gt; Use 119 to signal support for OP_CHECKTEMPLATEVERIFY in `nLockTime=
`
<br>&gt;=20
<br>&gt; ## Reference implementation
<br>&gt;=20
<br>&gt; Activation:
<br>&gt; <a href=3D"https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11=
e9c86bb2043c24f0f377f1cf514.diff" target=3D"_blank" rel=3D"nofollow" data-s=
aferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://github=
.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514.diff&a=
mp;source=3Dgmail&amp;ust=3D1724395355117000&amp;usg=3DAOvVaw3jeU2oRHgK7n7a=
FP0LnBDD">https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb204=
3c24f0f377f1cf514.diff</a>
<br>&gt;=20
<br>&gt; Exclusion in relay or mining:
<br>&gt; <a href=3D"https://github.com/bitcoinknots/bitcoin/commit/18cd7b0e=
f6eaeacd06678c6d192b6cacc9d7eee5.diff" target=3D"_blank" rel=3D"nofollow" d=
ata-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://g=
ithub.com/bitcoinknots/bitcoin/commit/18cd7b0ef6eaeacd06678c6d192b6cacc9d7e=
ee5.diff&amp;source=3Dgmail&amp;ust=3D1724395355117000&amp;usg=3DAOvVaw0Z30=
WXkDq_BTiEvRql83-v">https://github.com/bitcoinknots/bitcoin/commit/18cd7b0e=
f6eaeacd06678c6d192b6cacc9d7eee5.diff</a>
<br>&gt;=20
<br>&gt; ---
<br>&gt;=20
<br>&gt; If a transaction does not get included in block for a long time, u=
sers can
<br>&gt; replace it with another transaction spending same inputs and use a
<br>&gt; different `nLockTime`.
<br>&gt;=20
<br>&gt; /dev/fd0
<br>&gt; floppy disk guy
<br>&gt;=20
<br>
<br></blockquote></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/00e0601c-ed59-4245-a79d-0c36f1c8795bn%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/00e0601c-ed59-4245-a79d-0c36f1c8795bn%40googlegroups.com</a>.=
<br />

------=_Part_286831_750641228.1724327039493--

------=_Part_286830_41419725.1724327039493--