path: root/37/fb2c8116f221e2d2d6e01d06e7b65f9ec5bcaf

Delivery-date: Mon, 19 Aug 2024 11:19:27 -0700
Received: from mail-yb1-f187.google.com ([209.85.219.187])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCU2P6FJ3EBBBJMZR23AMGQEVNS46ZQ@googlegroups.com>)
	id 1sg6yT-0006QC-O0
	for bitcoindev@gnusha.org; Mon, 19 Aug 2024 11:19:27 -0700
Received: by mail-yb1-f187.google.com with SMTP id 3f1490d57ef6-e0be2c7c34dsf6936424276.2
        for <bitcoindev@gnusha.org>; Mon, 19 Aug 2024 11:19:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1724091559; x=1724696359; 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=DRTYKd8onx36ELsNa1iTPe+oVmPZeu2JdGZQ0eyF7Qw=;
        b=PX/WM7CZ83cfvE7q5zbov7ff6GVtF8+HTEjldWCdhjuGSS4Wylz0p5dLY+a+e2eX4u
         dxm2XlZI9OSOsY+9DtjRmvE+IqQPebDG5DYXyOBQOZ+L84VNau0hW451pmhqDX8XmFWD
         Y7pYckhx/wALZWVbwvM6d3cjjJwRcSHLghgHw23tji0YS0VB7nIrVggtvc4lfY/tuRyM
         /tR3Kdx+OvApg6KrhA+YbaK0yYcmgQYdA4YJFJ4/9larrhlmvjPGb5k6QY81KNjL+CyY
         eY1gwDkUtE+hfTYsTKeIKeD0VtWz7a86y3b3gDPbqosMTA48hHYdzcJ+w0ec1NgCzwYV
         QibQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1724091559; x=1724696359; 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=DRTYKd8onx36ELsNa1iTPe+oVmPZeu2JdGZQ0eyF7Qw=;
        b=UXPPN+5ZzsFMa1fj/oC0jRtyykdwdfEaCv/Oui7Mnmq1JeFYXrLN0q2QblP2mUF8Sd
         90YnRr9Px4v6Fv/KguKkxIyO9MoPWP6CDuVSLdh+plVp/n7/4pLui3RwSa9lFAt1nDfW
         hiTJ9prg7YZEzmr4qdV1gXKLUlvgZe8XAbI9oTirGBzgFwt2/WR9/E6jAYy77NL9QEiU
         ae/lO0Wg6/IADooOIBs+IEUERinFL0U3cSfhNNAm86X+AhC6VUl3X1ujIwIDeMVW2mkN
         EORD0YO+cV5QrAB1gX4Y7S5wcAYul1CF+QNsVXr1xnD4meFrNPffeFR1wlGexeHXPCpG
         S61Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1724091559; x=1724696359;
        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=DRTYKd8onx36ELsNa1iTPe+oVmPZeu2JdGZQ0eyF7Qw=;
        b=USpD4ClTo6u0sw7nQ1d9bHveZWtlMe/7i2I0DFOoAkyIhO0Hb8n13BLAiDooPrRj3H
         5BP845JzUvdKnEvpeq2SFL22/yLN6maOS+AwtNkP4mA0nWpDTOAAR5XaDg7OfUDPdElM
         of5yhnA/T5GQx7+QiRnNhiKi38hwJZqvnl+MTjWvkPWrQHEea/OoOO+VvImVRk1isfw3
         7ay+2zT4JSuTZU6I8woJMAPwwReFLmDlj3gGQZ5wGOZH2/giCNGTFadI1f/1rA/WR1ka
         TIQUP8nrqYRk0dF5FzuQaWEJ674PUOgRMHFxELFN+gnlcr0R2wkHVS7PtMsSqaVpy1fh
         8S5A==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWF5Q8+jwBln27SFcVu8dX2+qr3a1B/edND7O9A5LUWyeiQpdc0x7Z5+6rDsshz6Mh0m9nRtrIv30ZchKN+HIGc4T/r/do=
X-Gm-Message-State: AOJu0Yz6Fw3tiPMdEo+u+yfADlAexQsCBZ0wJShvjquaeg/RX21EkErK
	GXX2MhUQVpcceVUdnWKX7R3xBgPrTwXvAt4sfLnfqei94j06sUcY
X-Google-Smtp-Source: AGHT+IFnX6xyc7wHcMYQcUgbnPeJokrTVGtwJ+1cJwmENDo655KxG4XrFymHIAgg8ZSAAjDSyuHqhw==
X-Received: by 2002:a05:6902:c0d:b0:e11:7246:9632 with SMTP id 3f1490d57ef6-e1180e84cdamr13193531276.4.1724091559078;
        Mon, 19 Aug 2024 11:19:19 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:1501:b0:e13:da55:4e4e with SMTP id
 3f1490d57ef6-e13da555a49ls85294276.2.-pod-prod-00-us; Mon, 19 Aug 2024
 11:19:17 -0700 (PDT)
X-Received: by 2002:a25:8003:0:b0:e11:5da7:33d with SMTP id 3f1490d57ef6-e164a9696bcmr13860276.2.1724091557470;
        Mon, 19 Aug 2024 11:19:17 -0700 (PDT)
Received: by 2002:a05:690c:6310:b0:699:2980:4ef6 with SMTP id 00721157ae682-6b4729ad948ms7b3;
        Mon, 19 Aug 2024 10:50:08 -0700 (PDT)
X-Received: by 2002:a05:690c:6784:b0:64b:a85:e2c5 with SMTP id 00721157ae682-6b1b7f59763mr10597247b3.3.1724089807402;
        Mon, 19 Aug 2024 10:50:07 -0700 (PDT)
Date: Mon, 19 Aug 2024 10:50:07 -0700 (PDT)
From: /dev /fd0 <alicexbtong@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <eeedc7ff-de37-4180-a657-116a5efcec98n@googlegroups.com>
In-Reply-To: <KvOQPbOdGzE0_dViIN57KDCx8X-HdOLNKc8xM9y83vbyxVgujA1YI8MTzFsWV7wBIrQ8nBEzHxVhGt54H20t--FiRh3_iTvJeqqgaAOgZs0=@protonmail.com>
References: <29d850d1-912a-4b15-ba41-cc36d05e7074n@googlegroups.com>
 <KvOQPbOdGzE0_dViIN57KDCx8X-HdOLNKc8xM9y83vbyxVgujA1YI8MTzFsWV7wBIrQ8nBEzHxVhGt54H20t--FiRh3_iTvJeqqgaAOgZs0=@protonmail.com>
Subject: Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_453330_1340198926.1724089807136"
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_453330_1340198926.1724089807136
Content-Type: multipart/alternative; 
	boundary="----=_Part_453331_1905020670.1724089807136"

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

Hi Fabian,

Thanks for your feedback.

> Requiring users to make transactions in order to participate in order to=
=20
signal is problematic because it comes with economic costs to them that=20
depends a lot on their personal setup. What if they have their funds in a=
=20
vault? Then they have to go through a lengthy and costly process to get=20
them out. Or if they simply timelocked them for a number of years? Then=20
they can not participate at all.

I consider it a feature because users with 'economic activity' would be=20
participating in the process. This is better than social media wars. I am=
=20
sure users who hold bitcoin for long term would have some amount in hot=20
wallets for regular transactions. If not, they can always do transactions=
=20
to create another vault or add to existing vault.

> Motivated spammers can, however, simulate support for low costs if they=
=20
have the right setup. I would guess spammers have a few UTXOs laying around=
=20
in hot wallets and would be willing to invest some money if it serves their=
=20
interests.

Spam could be analyzed and filtered by different developers, users etc. in=
=20
the discussion before flag day activation.

> Depending on whether the users pay high or low fees in these signaling=20
transactions, they can choose their own adventure of misaligned incentives.

I don't see a problem with users competing to pay more fees on-chain.

> If the users pay high fees in these transactions some miners that don't=
=20
care about this will just mine the transaction not because they want to=20
signal but instead because it serves their economic interest. This means=20
you would need buy-in from all miners (template builders) in the world for=
=20
this to work on not get seemingly great signaling for these high fee=20
transactions even though the miners just want to earn the fees and may not=
=20
even know about a softfork proposal.

- Miners are not signaling support in this process
- Its easy for a mining pool to exclude these transactions in their blocks=
=20
if they aren't ready for a soft fork
- Its a feature and not bug that miners leave some money on the table for=
=20
signaling reluctance

Signaling in this BIP or BIP 8/9 is just a coordination mechanism and=20
miners can always false-signal.=20

> The low fee transactions would still need to be kept in a mempool=20
somewhere to prevent manipulation via eviction from mempools or the=20
signaling transactions simply disappearing. Keeping a transaction in the=20
mempool has many problems which is apparent from all the L2 research that=
=20
is going into this topic.

Bitcoin would work as expected and no change in mempool policies is=20
required for this process. Also, these can be everyday transactions and not=
=20
necessarily transactions done with the only purpose of signaling.

> As far as I can tell there are some ordinal protocols that use the lock=
=20
time field for something, how do you keep these two concepts apart?

Nobody is using BIP numbers in nLockTime for ordinals. There is a protocol=
=20
which uses 21 and it won't affect this process.=20

> "Community can analyze these transactions" That won't work. What do you=
=20
define as the lock-in mechanism? I suppose you would count the number of=20
blocks that had at least one signaling transaction in them. Ok, that could=
=20
work but that would mean that it's really not a lot of transactions that=20
would need to get into blocks via one of the manipulation methods I=20
mentioned above.

I am not sure which part won't work because blocks and transactions are=20
often analyzed by different developers, users etc. There is no lock-in=20
mechanism. Everyone would share their analysis after 3 months and it could=
=20
differ from each other. Number of blocks with at least one signaling=20
transaction is a good example. As with any other soft fork activation=20
discussion, these analysis would be evaluated together with technical=20
trade-offs to prepare for a flag day activation.

nLockTime signaling is to record the overall sentiment without social media=
=20
debates.

> Users broadcasting their own transactions with signaling is really just=
=20
an unnecessary misdirection. If a miner signals by including these=20
transactions in a block it doesn't matter if they include one or 100 of=20
these in a block. A block can just signal or not signal. So it would=20
probably play out in a way that users wouldn't send any signaling=20
transactions and miners would just include a single signaling self payment=
=20
in their block template. Which then is just a worse way of doing the=20
signaling with the version field.

Its not a misdirection because such things would be easy to identify in the=
=20
analysis after 3 months.

> I also don't think that the readiness signaling mechanism is actually the=
=20
reason why bip8/9 are controversial so I don't think your proposal really=
=20
would make things better even if the signaling part would work well.

- BIP 9 is controversial because it gives a small amount of hashpower veto=
=20
power over any soft fork activation
- BIP 8 is controversial because there are lot disagreements whether LOT=20
should be TRUE or FALSE

My proposal is flag day activation or UASF which requires economic nodes to=
=20
run the software to activate new consensus rules. nLockTime signaling is=20
only added to gather overall sentiment before moving forward, analyze and=
=20
discuss it which could help in coordination.

> Miners may "signal" by including high fee transactions even though they=
=20
don't know about the process at all

As I said earlier, miners are only required to be active and involved in=20
the process. They aren't voting for or against any soft fork in this=20
process. Steve Lee was able to contact most mining pools recently to make=
=20
them aware of the risks associated with non-standard transactions so I=20
think everyone would know the process if its used at some point.

> Users (if they would even need/want to participate) would bare economic=
=20
cost or may even have excluded themselves from the process already without=
=20
knowing it

Users that are not involved in any economic activity on-chain can continue=
=20
to discuss these proposals on social media.

> Spammers have many avenues today to exploit this mechanism at minimal=20
cost, all of these loop holes would need to be closed/defended

It is possible to differentiate spam from regular transactions and analysis=
=20
by different developers after 3 months would make this easier.

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

The level of detail in this BIP draft is kept minimum to avoid unnecessary=
=20
complexity. I like simple things that can do the job. I have reviewed BIP=
=20
8, 9, 148 and others before writing this draft. Maybe I will add a FAQ=20
section and more details on the website that will be used for this BIP.

Its neither a question nor the first time I am trying to improve BIP 8:=20
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020452.htm=
l

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

BIP has "XXX" mentioned in the draft and 8.5 was the subject to convey the=
=20
idea is to get something between BIP 8 and BIP 9. Its irritating for me as=
=20
well that improvement proposals for a decentralized protocol need numbers=
=20
from a central authority to appease some developers, users etc.

/dev/fd0
floppy disk guy

On Monday, August 19, 2024 at 2:13:25=E2=80=AFPM UTC Fabian wrote:

> Hi,
>
> that would be a NACK from me. I think this idea has many issues, I am jus=
t=20
> listing the ones that came to my head first:
>
>
>    - Requiring users to make transactions in order to participate in=20
>    order to signal is problematic because it comes with economic costs to=
 them=20
>    that depends a lot on their personal setup. What if they have their fu=
nds=20
>    in a vault? Then they have to go through a lengthy and costly process =
to=20
>    get them out. Or if they simply timelocked them for a number of years?=
 Then=20
>    they can not participate at all.
>    - Motivated spammers can, however, simulate support for low costs if=
=20
>    they have the right setup. I would guess spammers have a few UTXOs lay=
ing=20
>    around in hot wallets and would be willing to invest some money if it=
=20
>    serves their interests.
>    - Depending on whether the users pay high or low fees in these=20
>    signaling transactions, they can choose their own adventure of misalig=
ned=20
>    incentives...
>    - If the users pay high fees in these transactions some miners that=20
>    don't care about this will just mine the transaction not because they =
want=20
>    to signal but instead because it serves their economic interest. This =
means=20
>    you would need buy-in from all miners (template builders) in the world=
 for=20
>    this to work on not get seemingly great signaling for these high fee=
=20
>    transactions even though the miners just want to earn the fees and may=
 not=20
>    even know about a softfork proposal.
>    - If the miners pay low fees still all miners that offer out of band=
=20
>    acceleration of transactions would need to buy-in and not allow these=
=20
>    transactions to be boosted to prevent manipulation.
>    - The low fee transactions would still need to be kept in a mempool=20
>    somewhere to prevent manipulation via eviction from mempools or the=20
>    signaling transactions simply disappearing. Keeping a transaction in t=
he=20
>    mempool has many problems which is apparent from all the L2 research t=
hat=20
>    is going into this topic.
>    - As far as I can tell there are some ordinal protocols that use the=
=20
>    lock time field for something, how do you keep these two concepts apar=
t?
>    - "Community can analyze these transactions" That won't work. What do=
=20
>    you define as the lock-in mechanism? I suppose you would count the num=
ber=20
>    of blocks that had at least one signaling transaction in them. Ok, tha=
t=20
>    could work but that would mean that it's really not a lot of transacti=
ons=20
>    that would need to get into blocks via one of the manipulation methods=
 I=20
>    mentioned above.
>    - Thinking more about the previous point: Users broadcasting their own=
=20
>    transactions with signaling is really just an unnecessary misdirection=
. If=20
>    a miner signals by including these transactions in a block it doesn't=
=20
>    matter if they include one or 100 of these in a block. A block can jus=
t=20
>    signal or not signal. So it would probably play out in a way that user=
s=20
>    wouldn't send any signaling transactions and miners would just include=
 a=20
>    single signaling self payment in their block template. Which then is j=
ust a=20
>    worse way of doing the signaling with the version field.
>    - I also don't think that the readiness signaling mechanism is=20
>    actually the reason why bip8/9 are controversial so I don't think your=
=20
>    proposal really would make things better even if the signaling part wo=
uld=20
>    work well.
>
>
> That was bit ramblin, so, to summarize the top 3 issues I could come up=
=20
> with off the top of my head why this wouldn't work:
>
>    - Miners may "signal" by including high fee transactions even though=
=20
>    they don't know about the process at all
>    - Users (if they would even need/want to participate) would bare=20
>    economic cost or may even have excluded themselves from the process al=
ready=20
>    without knowing it
>    - Spammers have many avenues today to exploit this mechanism at=20
>    minimal cost, 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=
=20
> that BIP8 and BIP9 provide and try to get your proposal at least somewher=
e=20
> close to that level of detail if you want to have it taken serious as a B=
IP=20
> proposal. Otherwise, if this is just an idea or a question then maybe mak=
e=20
> it a Stack Exchange question or maybe a delving bitcoin post.
>
> And please don't self-assign BIP numbers, it's irritating.
>
> Best,
> Fabian
> On Monday, August 19th, 2024 at 7:08 AM, /dev /fd0 <alice...@gmail.com>=
=20
> wrote:
>
> Hi Bitcoin Developers,
>
> I am proposing an alternative way to activate soft forks. Please let me=
=20
> know if you see any issues with this method.
>
> BIP: XXX=20
> Layer: Consensus (soft fork)=20
> Title: nLockTime signaling and flag day activation
> Author: /dev/fd0 <alic...@protonmail.com>=20
> Status: Draft=20
> Type: Standards Track=20
> Created: 2024-08-19=20
> License: Public Domain
>
> ## Abstract
>
> This document describes a process to activate soft forks using flag day=
=20
> after `nLockTime` signaling and discussion.
>
> ## Motivation
>
> BIP 8 and BIP 9 are controversial. This BIP is an alternative which=20
> addresses 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=20
> `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 for=
=20
> a flag day activation of soft fork
>
> Example:
> Use 119 to signal support for OP_CHECKTEMPLATEVERIFY in `nLockTime`
>
> ## Reference implementation
>
> Activation:=20
> https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f3=
77f1cf514.diff
>
> Exclusion in relay or mining:=20
> https://github.com/bitcoinknots/bitcoin/commit/18cd7b0ef6eaeacd06678c6d19=
2b6cacc9d7eee5.diff
>
> ---
>
> If a transaction does not get included in block for a long time, users ca=
n=20
> replace it with another transaction spending same inputs and use a=20
> different `nLockTime`.
>
> /dev/fd0
> floppy disk guy
>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to bitcoindev+...@googlegroups.com.
> To view this discussion on the web visit=20
> https://groups.google.com/d/msgid/bitcoindev/29d850d1-912a-4b15-ba41-cc36=
d05e7074n%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/eeedc7ff-de37-4180-a657-116a5efcec98n%40googlegroups.com.

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

Hi Fabian,<div><br /></div><div>Thanks for your feedback.<br /><br />&gt;=
=C2=A0Requiring users to make transactions in order to participate 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 their funds in a =
vault? Then they have to go through a lengthy and costly process to get the=
m out. Or if they simply timelocked them for a number of years? Then they c=
an not participate at all.</div><div><br /></div><div>I consider it a featu=
re because users with 'economic activity' would be participating in the pro=
cess. This is better than social media wars. I am sure users who hold bitco=
in for long term would have some amount in hot wallets for regular transact=
ions. If not, they can always do transactions to create another vault or ad=
d to existing vault.</div><div><br /></div><div>&gt;=C2=A0Motivated spammer=
s can, however, simulate support for 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 money if it serves their interests.</div><d=
iv><br /></div><div>Spam could be analyzed and filtered by different develo=
pers, users etc. in the discussion before flag day activation.</div><div><b=
r /></div><div>&gt;=C2=A0Depending on whether the users pay high or low fee=
s in these signaling transactions, they can choose their own adventure of m=
isaligned incentives.</div><div><br /></div><div>I don't see a problem with=
 users competing to pay more fees on-chain.</div><div><br /></div><div>&gt;=
=C2=A0If the users pay high fees in these transactions some miners that don=
't care about this will just mine the transaction not because they want to =
signal but instead because it serves their economic interest. This means yo=
u would need buy-in from all miners (template builders) in the world for th=
is to work on not get seemingly great signaling for these high fee transact=
ions even though the miners just want to earn the fees and may not even kno=
w about a softfork proposal.</div><div><br /></div><div>- Miners are not si=
gnaling support in this process</div><div>- Its easy for a mining pool to e=
xclude these transactions in their blocks if they aren't ready for a soft f=
ork</div><div>- Its a feature and not bug that miners leave some money on t=
he table for signaling=C2=A0reluctance</div><div><br /></div><div>Signaling=
 in this BIP or BIP 8/9 is just a coordination mechanism and miners can alw=
ays false-signal.=C2=A0<br /></div><div><br /></div><div>&gt;=C2=A0The low =
fee transactions would still need to be kept in a mempool somewhere to prev=
ent manipulation via eviction from mempools or the signaling transactions s=
imply disappearing. Keeping a transaction in the mempool has many problems =
which is apparent from all the L2 research that is going into this topic.</=
div><div><br /></div><div>Bitcoin would work as expected and no change in m=
empool policies is required for this process. Also, these can be everyday t=
ransactions and not necessarily transactions done with the only purpose of =
signaling.</div><div><br /></div><div>&gt;=C2=A0As far as I can tell there =
are some ordinal protocols that use the lock time field for something, how =
do you keep these two concepts apart?</div><div><br /></div><div>Nobody is =
using BIP numbers in nLockTime for ordinals. There is a protocol which uses=
 21 and it won't affect this process.=C2=A0</div><div><br /></div><div>&gt;=
 "Community can analyze these transactions" That won't work. What do you de=
fine as the lock-in mechanism? I suppose you would count the number of bloc=
ks that had at least one signaling transaction in them. Ok, that 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 mentioned abo=
ve.<br /></div><div><br /></div><div>I am not sure which part won't work be=
cause blocks and transactions are often analyzed by different developers, u=
sers etc. There is no lock-in mechanism. Everyone would share their analysi=
s after 3 months and it could differ from each other. Number of blocks with=
 at least one signaling transaction is a good example. As with any other so=
ft fork activation discussion, these analysis would be evaluated together w=
ith technical trade-offs to prepare for a flag day activation.</div><div><b=
r /></div><div>nLockTime signaling is to record the overall sentiment witho=
ut social media debates.</div><div><br /></div><div>&gt;=C2=A0Users broadca=
sting their own transactions with signaling is really just an unnecessary m=
isdirection. If a miner 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 c=
an just signal or not signal. So it would probably play out in a way that u=
sers wouldn't send any signaling transactions and miners would just include=
 a single signaling self payment in their block template. Which then is jus=
t a worse way of doing the signaling with the version field.</div><div><br =
/></div><div>Its not a misdirection because such things would be easy to id=
entify in the analysis after 3 months.</div><div><br /></div><div>&gt;=C2=
=A0I also don't think that the readiness signaling mechanism is actually th=
e 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.</div>=
<div><br /></div><div>- BIP 9 is controversial because it gives a small amo=
unt of hashpower veto power over any soft fork activation</div><div>- BIP 8=
 is controversial because there are lot disagreements whether LOT should be=
 TRUE or FALSE</div><div><br /></div><div>My proposal is flag day activatio=
n or UASF which requires economic nodes to run the software to activate new=
 consensus rules. nLockTime signaling is only added to gather overall senti=
ment before moving forward, analyze and discuss it which could help in coor=
dination.</div><div><br /></div><div>&gt;=C2=A0Miners may "signal" by inclu=
ding high fee transactions even though they don't know about the process at=
 all</div><div><br /></div><div>As I said earlier, miners are only required=
 to be active and involved in the process. They aren't voting for or agains=
t any soft fork in this process. Steve Lee was able to contact most mining =
pools recently to make them aware of the risks associated with non-standard=
 transactions so I think everyone would know the process if its used at som=
e point.</div><div><br /></div><div>&gt;=C2=A0Users (if they would even nee=
d/want to participate) would bare economic cost or may even have excluded t=
hemselves from the process already without knowing it</div><div><br /></div=
><div>Users that are not involved in any economic activity on-chain can con=
tinue to discuss these proposals on social media.</div><div><br /></div><di=
v>&gt;=C2=A0Spammers have many avenues today to exploit this mechanism at m=
inimal cost, all of these loop holes would need to be closed/defended</div>=
<div><br /></div><div>It is possible to differentiate spam from regular tra=
nsactions and analysis by different developers after 3 months would make th=
is easier.</div><div><br /></div><div>&gt;=C2=A0If you want to follow up pl=
ease first take a look at the level of detail that BIP8 and BIP9 provide an=
d try to get your proposal at least somewhere 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><div><br /></div><div>The level of d=
etail in this BIP draft is kept minimum to avoid unnecessary complexity. I =
like simple things that can do the job. I have reviewed BIP 8, 9, 148 and o=
thers before writing this draft. Maybe I will add a FAQ section and more de=
tails on the website that will be used for this BIP.<br /><br />Its neither=
 a question nor the first time I am trying to improve BIP 8:=C2=A0<a href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020452=
.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020=
452.html</a></div><div><br /></div><div>&gt;=C2=A0And please don't self-ass=
ign BIP numbers, it's irritating.</div><div><br /></div><div>BIP has "XXX" =
mentioned in the draft and 8.5 was the subject to convey the idea is to get=
 something between BIP 8 and BIP 9. Its irritating for me as well that impr=
ovement proposals for a decentralized protocol need numbers from a central =
authority to appease some developers, users etc.</div><div><br /></div><div=
>/dev/fd0<br />floppy disk guy</div><div><br /></div><div class=3D"gmail_qu=
ote"><div dir=3D"auto" class=3D"gmail_attr">On Monday, August 19, 2024 at 2=
:13:25=E2=80=AFPM UTC Fabian wrote:<br/></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204=
); padding-left: 1ex;"><div style=3D"font-family:Arial,sans-serif;font-size=
:14px">Hi,</div><div style=3D"font-family:Arial,sans-serif;font-size:14px">=
<br></div><div style=3D"font-family:Arial,sans-serif;font-size:14px">that w=
ould be a NACK from me. I think this idea has many issues, I am just listin=
g the ones 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-=
serif;font-size:14px"><ul><li style=3D"list-style-type:&quot;- &quot;"><spa=
n>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.</span></li><li style=3D"list-style-type:&quot;- &quo=
t;">Motivated spammers can, however, simulate support for low costs if they=
 have the right setup. I would guess spammers have a few UTXOs laying aroun=
d in hot wallets and would be willing to invest some money if it serves the=
ir interests.</li><li style=3D"list-style-type:&quot;- &quot;">Depending on=
 whether the users pay high or low fees in these signaling transactions, th=
ey can choose their own adventure of misaligned incentives...</li><li style=
=3D"list-style-type:&quot;- &quot;">If the users pay high fees in these tra=
nsactions some miners that don&#39;t care about this will just mine the tra=
nsaction not because they want to signal but instead because it serves thei=
r economic interest. This means you would need buy-in from all miners (temp=
late builders) in the world for this to work on not get seemingly great sig=
naling for these high fee transactions even though the miners just want to =
earn the fees and may not even know about a softfork proposal.</li><li styl=
e=3D"list-style-type:&quot;- &quot;">If the miners pay low fees still all m=
iners that offer out of band acceleration of transactions 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;">The low fee transactions =
would still need to be kept in a mempool somewhere to prevent manipulation =
via eviction from mempools or the signaling transactions simply disappearin=
g. Keeping a transaction in the mempool has many problems which is apparent=
 from all the L2 research that is going into this topic.</li><li style=3D"l=
ist-style-type:&quot;- &quot;">As far as I can tell there are some ordinal =
protocols that use the lock time field for something, how do you keep these=
 two concepts apart?</li><li style=3D"list-style-type:&quot;- &quot;;font-f=
amily:system-ui,sans-serif">&quot;<span style=3D"font-family:system-ui,sans=
-serif;text-align:start;display:inline!important">Community can analyze the=
se transactions&quot; That won&#39;t work.=C2=A0</span>What do you define a=
s the lock-in mechanism? I suppose you would count the number of blocks tha=
t had at least one signaling transaction in them. Ok, that could work but t=
hat would mean that it&#39;s really not a lot of transactions that would ne=
ed to get into blocks via one of the manipulation methods I mentioned above=
.</li><li style=3D"list-style-type:&quot;- &quot;">Thinking more about the =
previous point: Users broadcasting their own transactions with signaling is=
 really just an unnecessary misdirection. If a miner signals by including t=
hese transactions in a block it doesn&#39;t matter if they include one or 1=
00 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&#39;t send any signaling trans=
actions and miners would just include a single signaling self payment in th=
eir block template. Which then is just a worse way of doing the signaling w=
ith the version field.</li><li style=3D"list-style-type:&quot;- &quot;">I a=
lso don&#39;t think that the readiness signaling mechanism is actually the =
reason why bip8/9 are controversial so I don&#39;t think your proposal real=
ly 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&#39;t wo=
rk:</div><div><ul><li style=3D"list-style-type:&quot;- &quot;">Miners may &=
quot;signal&quot; by including high fee transactions even though they don&#=
39;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 eco=
nomic cost or may even have excluded themselves from the process already wi=
thout knowing it</li><li style=3D"list-style-type:&quot;- &quot;">Spammers =
have many avenues today to exploit this mechanism at minimal cost, all of t=
hese loop holes would need to be closed/defended</li></ul><div><br></div><d=
iv>If you want to follow up please first take a look at the level of detail=
 that BIP8 and BIP9 provide and try to get your proposal at least somewhere=
 close to that level of detail if you want to have it taken serious as a BI=
P proposal. Otherwise, if this is just an idea or a question then maybe mak=
e it a Stack Exchange question or maybe a delving bitcoin post.</div><div><=
br></div><div>And please don&#39;t self-assign BIP numbers, it&#39;s irrita=
ting.</div><div><br></div></div><div>Best,</div><div>Fabian</div></div><div=
></div><div>
        On Monday, August 19th, 2024 at 7:08 AM, /dev /fd0 &lt;<a href data=
-email-masked rel=3D"nofollow">alice...@gmail.com</a>&gt; wrote:<br>
        </div><div><blockquote 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;<a href data-email-masked rel=3D"nofollow">alic...@protonm=
ail.com</a>&gt;  <br>    Status: Draft  <br>    Type: Standards Track  <br>=
    Created: 2024-08-19  <br>    License: Public Domain<br><br>## Abstract<=
br><br>This document describes a process to activate soft forks using flag =
day after `nLockTime` signaling and discussion.<br><br>## Motivation<br><br=
>BIP 8 and BIP 9 are controversial. This BIP is an alternative which addres=
ses the problems with other activation methods.<br><br>## Specification<br>=
<br>- Assign numbers to different soft fork proposals or use their BIP numb=
ers<br>- Users can broadcast their transactions with one of these numbers u=
sed as `nLockTime` to show support<br>- Miners inlcuding a transaction in b=
lock would signal readiness for a soft fork<br>- Community can analyze thes=
e transactions after 3 months and prepare for a flag day activation of soft=
 fork<br><br>Example:<br>Use 119 to signal support for OP_CHECKTEMPLATEVERI=
FY in `nLockTime`<br><br>## Reference implementation<br><br>Activation: <a =
href=3D"https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c=
24f0f377f1cf514.diff" rel=3D"noreferrer nofollow noopener" target=3D"_blank=
" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps:=
//github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf51=
4.diff&amp;source=3Dgmail&amp;ust=3D1724171117177000&amp;usg=3DAOvVaw3vcJsH=
44fLkipoHnpKA5oB">https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9=
c86bb2043c24f0f377f1cf514.diff</a><br><br>Exclusion in relay or mining: <a =
href=3D"https://github.com/bitcoinknots/bitcoin/commit/18cd7b0ef6eaeacd0667=
8c6d192b6cacc9d7eee5.diff" rel=3D"noreferrer nofollow noopener" target=3D"_=
blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dh=
ttps://github.com/bitcoinknots/bitcoin/commit/18cd7b0ef6eaeacd06678c6d192b6=
cacc9d7eee5.diff&amp;source=3Dgmail&amp;ust=3D1724171117177000&amp;usg=3DAO=
vVaw2cJEsrLoWEG1E5kMhtCCmi">https://github.com/bitcoinknots/bitcoin/commit/=
18cd7b0ef6eaeacd06678c6d192b6cacc9d7eee5.diff</a><br><br>---<br><br>If a tr=
ansaction does not get included in block for a long time, users can replace=
 it with another transaction spending same inputs and use a different `nLoc=
kTime`.<br><br>/dev/fd0<br>floppy disk guy</div>

<p></p></blockquote></div><div><blockquote type=3D"cite">

-- <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 rel=3D"noreferrer nofollow noopener" data-email-masked>bitc=
oindev+...@googlegroups.com</a>.<br>
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" rel=3D"noreferrer nofollow noopener" target=3D"_blank" data-saferedire=
cturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.google.c=
om/d/msgid/bitcoindev/29d850d1-912a-4b15-ba41-cc36d05e7074n%2540googlegroup=
s.com&amp;source=3Dgmail&amp;ust=3D1724171117177000&amp;usg=3DAOvVaw1_a8ZAx=
F5KAE-np57m0b-z">https://groups.google.com/d/msgid/bitcoindev/29d850d1-912a=
-4b15-ba41-cc36d05e7074n%40googlegroups.com</a>.<br>

        </blockquote><br>
    </div></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/eeedc7ff-de37-4180-a657-116a5efcec98n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/eeedc7ff-de37-4180-a657-116a5efcec98n%40googlegroups.com</a>.=
<br />

------=_Part_453331_1905020670.1724089807136--

------=_Part_453330_1340198926.1724089807136--