Delivery-date: Thu, 22 Aug 2024 05:57:22 -0700
Sender: bitcoindev@googlegroups.com
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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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--