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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <29d850d1-912a-4b15-ba41-cc36d05e7074n@googlegroups.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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 = =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 =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,

Thanks for your feedback.

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

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.

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

Spam could be analyzed and filtered by different develo= pers, users etc. in the discussion before flag day activation.
>=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.

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

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

- Miners are not si= gnaling support in this process
- Its easy for a mining pool to e= xclude these transactions in their blocks if they aren't ready for a soft f= ork
- Its a feature and not bug that miners leave some money on t= he table for signaling=C2=A0reluctance

Signaling= in this BIP or BIP 8/9 is just a coordination mechanism and miners can alw= ays false-signal.=C2=A0

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

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.

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

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

>= "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.

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.
nLockTime signaling is to record the overall sentiment witho= ut social media debates.

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

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

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

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

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.

>=C2=A0Miners may "signal" by inclu= ding high fee transactions even though they don't know about the process at= all

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.

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

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

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

It is possible to differentiate spam from regular tra= nsactions and analysis by different developers after 3 months would make th= is easier.

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

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.

Its neither= a question nor the first time I am trying to improve BIP 8:=C2=A0https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020= 452.html

>=C2=A0And please don't self-ass= ign BIP numbers, it's irritating.

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.

/dev/fd0
floppy disk guy

On Monday, August 19, 2024 at 2= :13:25=E2=80=AFPM UTC Fabian wrote:
Hi,
=
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:

  • 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= 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.
  • Depending on= whether the users pay high or low fees in these signaling transactions, th= ey can choose their own adventure of misaligned incentives...
  • If the users pay high fees in these tra= nsactions some miners that don'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.
  • 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.=
  • 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.
  • 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?
  • "Community can analyze the= se transactions" That won't work.=C2=A0What 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's really not a lot of transactions that would ne= ed to get into blocks via one of the manipulation methods I mentioned above= .
  • 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'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'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.
  • I a= lso don't think that the readiness signaling mechanism is actually the = reason why bip8/9 are controversial so I don't think your proposal real= ly 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 with off the top of my head why this wouldn't wo= rk:
  • Miners may &= quot;signal" by including high fee transactions even though they don&#= 39;t know about the process at all
  • 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
  • Spammers = have many avenues today to exploit this mechanism at minimal cost, all of t= hese loop holes would need to be closed/defended

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.
<= br>
And please don't self-assign BIP numbers, it's irrita= ting.

Best,
Fabian
On Monday, August 19th, 2024 at 7:08 AM, /dev /fd0 <alice...@gmail.com> wrote:
Hi Bitcoin Developers,

I am proposing an alt= ernative way to activate soft forks. Please let me know if you see any issu= es with this method.

BIP: XXX
Layer: Consensus (soft fo= rk)
Title: nLockTime signaling and flag day activation
Auth= or: /dev/fd0 <alic...@protonm= ail.com>
Status: Draft
Type: Standards Track
= Created: 2024-08-19
License: Public Domain

## Abstract<= br>
This document describes a process to activate soft forks using flag = day after `nLockTime` signaling and discussion.

## Motivation
BIP 8 and BIP 9 are controversial. This BIP is an alternative which addres= ses the problems with other activation methods.

## Specification
=
- Assign numbers to different soft fork proposals or use their BIP numb= ers
- Users can broadcast their transactions with one of these numbers u= sed as `nLockTime` to show support
- Miners inlcuding a transaction in b= lock would signal readiness for a soft fork
- Community can analyze thes= e transactions after 3 months and prepare for a flag day activation of soft= fork

Example:
Use 119 to signal support for OP_CHECKTEMPLATEVERI= FY in `nLockTime`

## Reference implementation

Activation: https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9= c86bb2043c24f0f377f1cf514.diff

Exclusion in relay or mining: https://github.com/bitcoinknots/bitcoin/commit/= 18cd7b0ef6eaeacd06678c6d192b6cacc9d7eee5.diff

---

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

/dev/fd0
floppy disk guy

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitc= oindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/29d850d1-912a= -4b15-ba41-cc36d05e7074n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/eeedc7ff-de37-4180-a657-116a5efcec98n%40googlegroups.com.=
------=_Part_453331_1905020670.1724089807136-- ------=_Part_453330_1340198926.1724089807136--