Delivery-date: Mon, 19 Aug 2024 07:13:32 -0700
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
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_OH1wDazyaJUoxvHNZiriE0J85W6k98obUAD91PPZOk"
Reply-To: Fabian <fjahr@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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