diff options
| author | /dev /fd0 <alicexbtong@gmail.com> | 2024-08-22 04:43:59 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2024-08-22 05:57:22 -0700 |
| commit | 6ec2e63fcf7794ec5ae071cb51731b491829deda (patch) | |
| tree | 0fff4c2e11ed146aa323ba3a5655607a67be35f9 /28 | |
| parent | 6a45029d587e48c598b509a46f7603c798fb42a6 (diff) | |
| download | pi-bitcoindev-6ec2e63fcf7794ec5ae071cb51731b491829deda.tar.gz pi-bitcoindev-6ec2e63fcf7794ec5ae071cb51731b491829deda.zip | |
Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
Diffstat (limited to '28')
| -rw-r--r-- | 28/ab74287ca90844565cfc72b88c77760dd3c09a | 652 |
1 files changed, 652 insertions, 0 deletions
diff --git a/28/ab74287ca90844565cfc72b88c77760dd3c09a b/28/ab74287ca90844565cfc72b88c77760dd3c09a new file mode 100644 index 000000000..1f4904481 --- /dev/null +++ b/28/ab74287ca90844565cfc72b88c77760dd3c09a @@ -0,0 +1,652 @@ +Delivery-date: Thu, 22 Aug 2024 05:57:22 -0700 +Received: from mail-yb1-f192.google.com ([209.85.219.192]) + by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + (Exim 4.94.2) + (envelope-from <bitcoindev+bncBCU2P6FJ3EBBBKHLTS3AMGQEFVM3K2A@googlegroups.com>) + id 1sh7NQ-0002fL-Se + for bitcoindev@gnusha.org; Thu, 22 Aug 2024 05:57:22 -0700 +Received: by mail-yb1-f192.google.com with SMTP id 3f1490d57ef6-e03623b24ddsf1433755276.1 + for <bitcoindev@gnusha.org>; Thu, 22 Aug 2024 05:57:20 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=googlegroups.com; s=20230601; t=1724331434; x=1724936234; darn=gnusha.org; + h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post + :list-id:mailing-list:precedence:x-original-sender:mime-version + :subject:references:in-reply-to:message-id:to:from:date:sender:from + :to:cc:subject:date:message-id:reply-to; + bh=zOmwCmim/XxTkw79GiSjVvpnp8cHsMr3HPW7OdH/pAo=; + b=t3NZfxZu7vmaXmEd3Y6VhNiCanEq/VyaK7P68UXobgsrHlQVlvhvo5d5Ge6RdRHp6Q + yEPQx90n2Qoo5uRBlm2gdRySebBcZqnl27PxNjgiwCcduIh1ETsbkK2plVrm9uUBqjYB + JgTBhmMt0T/C5dSTMEDFqXJ3UoVZ6nxQPwCG+gPqeix34k6kO0zjr8Fy4CovT2D9To4y + 6kjat/0hrN64lyPmgGXc34p+VvYrmum04gzmckxpgkB8im2onYu1U2hHS5tQJlaDeLej + dNSa0BinMdhNUTs/WMUpmD/nshrAZAYquIgCYOIu9y1i4eBUk22pKYRfkfLrncFm0UJN + dL1w== +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1724331434; x=1724936234; darn=gnusha.org; + h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post + :list-id:mailing-list:precedence:x-original-sender:mime-version + :subject:references:in-reply-to:message-id:to:from:date:from:to:cc + :subject:date:message-id:reply-to; + bh=zOmwCmim/XxTkw79GiSjVvpnp8cHsMr3HPW7OdH/pAo=; + b=lKbQL+qJd7LyQ2zZ34vvIqfC04uAtQdxCLcjqEP8KeCCx6ltuVSXKNk+1Lpeh08Xfy + R4uUZKpqkSIy4lSj1NfhtHszFCEl472nIKnd3HgSbQcJS2YMGmFc+9Q840A69E2UBf+X + g0WXtxriZn3TzIcAH11NSINIU6OEkjM/iZTzlRbnAqCLtw3LJfGU/gOSwnBei0q/tQUA + yqmAryU2NMX37CaET78BIBzHBR42CnWFuX68WbGMzId73/V4+FR0EfEUvYa7ZK9tCs1w + 0ArXKa6VzOe9WtOo/txaToCyZSznSc9+HbZONnvKV8Vpnf/13hMda49sDcs02uhZRJ+2 + mylQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1724331434; x=1724936234; + h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post + :list-id:mailing-list:precedence:x-original-sender:mime-version + :subject:references:in-reply-to:message-id:to:from:date:x-beenthere + :x-gm-message-state:sender:from:to:cc:subject:date:message-id + :reply-to; + bh=zOmwCmim/XxTkw79GiSjVvpnp8cHsMr3HPW7OdH/pAo=; + b=CGsFFoLR9FCzQwNjsrXOFJ+JnCcUiILo1GT+/oosfY//gYjWT9wMRISzvR5grrthkK + jRw2DN/l/XKE16uh6BLMOoZcUmQcja6/GJBZUXOc4CosFT3zOviN9bgUAVJNqPsV+JlG + R/iIiaG03KAH+OUihqnqT/BzH1k/fWVUVVc4RkArHyjJJTz0wHWPWQdwMLb5lTX3dEtn + Vm3KFb29pdigwFDSu8lrdi/pHC5Iq1EJ/QAUiBY4iIn6K8OM3GU9I0aC1GQjac4+duJQ + z8uUL6rjfPvyd2VrjQAMQ/in8vzPkjKk3RlSrvPdCJs5oOIF3xvnKvJ1AQj4f5Caanvt + i3Rg== +Sender: bitcoindev@googlegroups.com +X-Forwarded-Encrypted: i=1; AJvYcCWlB1IT2ROMF7udZhHrn8JB2ih36GZI8zWWy3xsYXbjC3juAxgu4PCJuMZ/TTaRHoSzwzbHSEZkjbIy@gnusha.org +X-Gm-Message-State: AOJu0YxqgpSzzlrr3aasvtzTUb+bkPryFGLBCNDTDdKT5JJJMDfI9j1N + 4N8duvQc9Mww+5YecbaCEQW644paFnnjQDc9etqySEeNi7kIeFU+ +X-Google-Smtp-Source: AGHT+IFAElbkFkSRnoU8D3L4J3zormRG4iRyj3XLFr5RKzuz1kpDK1KchrcqN4zsWpBxKS63YJTq+g== +X-Received: by 2002:a25:2607:0:b0:e16:6c22:811a with SMTP id 3f1490d57ef6-e166c22865emr5048146276.9.1724331433924; + Thu, 22 Aug 2024 05:57:13 -0700 (PDT) +X-BeenThere: bitcoindev@googlegroups.com +Received: by 2002:a05:6902:18c4:b0:e05:a345:25b6 with SMTP id + 3f1490d57ef6-e178b862d00ls999010276.0.-pod-prod-07-us; Thu, 22 Aug 2024 + 05:57:11 -0700 (PDT) +X-Received: by 2002:a05:690c:3185:b0:6ad:feb0:d01c with SMTP id 00721157ae682-6c09c3adab3mr1191277b3.3.1724331431818; + Thu, 22 Aug 2024 05:57:11 -0700 (PDT) +Received: by 2002:a05:690c:2a44:b0:627:7f59:2eee with SMTP id 00721157ae682-6c0ebefe879ms7b3; + Thu, 22 Aug 2024 04:44:00 -0700 (PDT) +X-Received: by 2002:a05:690c:6703:b0:65f:96e9:42f4 with SMTP id 00721157ae682-6c3054f31c8mr28288787b3.15.1724327039732; + Thu, 22 Aug 2024 04:43:59 -0700 (PDT) +Date: Thu, 22 Aug 2024 04:43:59 -0700 (PDT) +From: /dev /fd0 <alicexbtong@gmail.com> +To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com> +Message-Id: <00e0601c-ed59-4245-a79d-0c36f1c8795bn@googlegroups.com> +In-Reply-To: <4de6a775-f9ed-44f0-bc93-7e74d64e36ad@murch.one> +References: <29d850d1-912a-4b15-ba41-cc36d05e7074n@googlegroups.com> + <4de6a775-f9ed-44f0-bc93-7e74d64e36ad@murch.one> +Subject: Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling +MIME-Version: 1.0 +Content-Type: multipart/mixed; + boundary="----=_Part_286830_41419725.1724327039493" +X-Original-Sender: alicexbtong@gmail.com +Precedence: list +Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com +List-ID: <bitcoindev.googlegroups.com> +X-Google-Group-Id: 786775582512 +List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com> +List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com> +List-Archive: <https://groups.google.com/group/bitcoindev +List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com> +List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>, + <https://groups.google.com/group/bitcoindev/subscribe> +X-Spam-Score: -0.5 (/) + +------=_Part_286830_41419725.1724327039493 +Content-Type: multipart/alternative; + boundary="----=_Part_286831_750641228.1724327039493" + +------=_Part_286831_750641228.1724327039493 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi Murch, + +Thanks for reviewing the BIP draft and suggesting improvements. + +> I would suggest the following areas of +improvement + +I have answered other responses and will reply to your feedback below. I=20 +will improve motivation section and add rationale, backwards compatibility,= +=20 +syntax etc. by first week of September. + +> I appreciate that the signaling mechanism you propose would introduce +a cost to signaling.=20 + +This isn't the primary goal of the BIP but exists because bitcoin=20 +transactions require fees. Otherwise paid voting is possible on nostr using= +=20 +polls. + +> if you were going to make a transaction anyway, it=E2=80=99s free, but ot= +herwise=20 +you would have to pay to get your signal out there. + +The real signal we need to analyze after 3 months comes from users who=20 +participate in this signaling with transactions that were going to happen= +=20 +anyway. These are the users with some economic activity whose opinion=20 +matters the most for changes in consensus rules.=20 + +> Someone that may have sent a batched payments transaction might consider= +=20 +splitting it into multiple separate transactions instead to increase their= +=20 +signaling + +This depends on the analysis and I would give more weight to the batch=20 +payment using nLockTime for signaling. + +> Either way, it would be better to use the field for anti-fee sniping,=20 +which also is not compatible with your signaling mechanism. + +Lot of transactions use zero as nLockTime so signaling could work fine for= +=20 +at least next 12 years:=20 +https://blockchair.com/bitcoin/transactions?s=3Dtime(desc)&q=3Dlock_time(0)= +,time(2024-01-01..)#f=3Dtime,lock_time + +> Most wallet software does not support setting the locktime manually, so= +=20 +some users that might want to signal support cannot without switching=20 +software. + +This signaling is mainly targeting economic nodes and I think most of them= +=20 +would be able to do it. I will also create a website which can be used to= +=20 +enter unsigned PSBT and change its nLockTime. + +> This introduces a new fingerprint for transactions pertaining to software= +=20 +that supports setting locktime manually. + +I am not sure if this can be used to track anything meaningful which=20 +affects privacy. + +> A transaction can only set a single nLockTime value, so if there are=20 +multiple proposals that are up for debate, a transaction can only signal=20 +support for one. This could side-stepped by using nLockTime as a bit array= +=20 +where each position signals support for one proposal, much like BIP=E2=80= +=AF9. + +I like the idea of using bit array and I will update the draft accordingly. + +> but it=E2=80=99s unclear why one out of thousands of transactions should = +be=20 +relevant whatsoever. Unless a very large portion of transactions signals=20 +support, I=E2=80=99m not sure what we would learn from this signal at all. + +This depends on analysis and could be interpreted differently. Let me share= +=20 +an example: + +Alice and Bob analyze these transactions after 3 months. Some blocks had=20 +only 1 transaction that signaled support for a soft fork proposal. Alice=20 +marked them red and don't consider helpful or at the bottom in analysis=20 +report. Bob looked at each transaction and considered some different from= +=20 +others. In a transaction, Bitfinex moved some bitcoin from hot wallet to=20 +cold storage so it was given some weight over others and marked with a=20 +different color. + +> Your proposal does not allow distinguishing between apathy and=20 +opposition: not signaling could mean either. + +I agree that proposal is focused on looking at support and not opposition.= +=20 +Still it could be visible if some nodes and miners try to reject these=20 +transactions. If someone really has a genuine problem with any of these=20 +soft forks, best way to share it would be a technical review, test etc.=20 +posted on mailing list. + +> You suggest that miners could choose to exclude signaling transactions if= +=20 +they are not ready, but it is much simpler for miners to do nothing, so the= +=20 +inclusion of signaling transactions cannot be interpreted as an endorsement= +. + +Miners never endorse any soft forks. Neither in this BIP nor BIP 8/9.=20 +Miners should always be ready for soft forks, but a coordination exercise= +=20 +before activation is always a safe approach in a decentralized network. + +/dev/fd0 +floppy disk guy + + +On Wednesday, August 21, 2024 at 2:14:48=E2=80=AFPM UTC Murch wrote: + +> Hello floppy and list, +> +> On 8/19/24 01:08, /dev /fd0 wrote: +> > Hi Bitcoin Developers, +> > +> > I am proposing an alternative way to activate soft forks. Please let +> > me know if you see any issues with this method. +> +> While your proposal may address some of the criticisms leveled at BIP=E2= +=80=AF8=20 +> and BIP=E2=80=AF9, it introduces new problems. +> +> 1. I appreciate that the signaling mechanism you propose would introduce= +=20 +> a cost to signaling. Unfortunately, this cost is unevenly distributed:=20 +> if you were going to make a transaction anyway, it=E2=80=99s free, but ot= +herwise=20 +> you would have to pay to get your signal out there. It may also lead to= +=20 +> a distortion of usage. Someone that may have sent a batched payments=20 +> transaction might consider splitting it into multiple separate=20 +> transactions instead to increase their signaling for a reduced cost=20 +> compared to making transactions just for signaling, but increased=20 +> blockspace demand compared to their batched payments transaction. +> +> 2. The `nLockTime` field is not unused. Transactions that have to set it= +=20 +> to make use of other protocol functions are inherently prevented from=20 +> signaling. Either way, it would be better to use the field for anti-fee= +=20 +> sniping, which also is not compatible with your signaling mechanism. +> +> 3. Most wallet software does not support setting the locktime manually,= +=20 +> so some users that might want to signal support cannot without switching= +=20 +> software. +> +> 4. This introduces a new fingerprint for transactions pertaining to=20 +> software that supports setting locktime manually. +> +> 5. A transaction can only set a single nLockTime value, so if there are= +=20 +> multiple proposals that are up for debate, a transaction can only signal= +=20 +> support for one. This could side-stepped by using nLockTime as a bit=20 +> array where each position signals support for one proposal, much like=20 +> BIP=E2=80=AF9. +> +> 6. As already surfaced in your conversation with Fabian, it is up for=20 +> debate how the signaling data later would be interpreted. You mention=20 +> that spam could later be excluded, and blocks that include at least one= +=20 +> transaction that signals would be some sort of signal, but it=E2=80=99s u= +nclear=20 +> why one out of thousands of transactions should be relevant whatsoever.= +=20 +> Unless a very large portion of transactions signals support, I=E2=80=99m = +not=20 +> sure what we would learn from this signal at all. +> +> 7. Your proposal does not allow distinguishing between apathy and=20 +> opposition: not signaling could mean either. +> +> 8. You suggest that miners could choose to exclude signaling=20 +> transactions if they are not ready, but it is much simpler for miners to= +=20 +> do nothing, so the inclusion of signaling transactions cannot be=20 +> interpreted as an endorsement. +> +> Overall, this approach does not seem expedient to me, but should you=20 +> choose to maturate this proposal, I would suggest the following areas of= +=20 +> improvement: +> +> - The proposal should address the questions brought up above and by=20 +> other responses +> - The motivation should describe in more detail the existing issues that= +=20 +> are being addressed, and how this proposal mitigates them +> - A rationale section should explain design choices, and put the=20 +> proposal into the context of alternate designs and related work +> - A backwards compatibility section should address how implementers=20 +> should think about this proposal in the context of other uses of=20 +> nLockTime such as anti-fee sniping +> - The specification should describe the syntax and semantics in=20 +> sufficient detail for other developers to implement the proposal +> +> Cheers, +> +> Murch +> +> >=20 +> > BIP: XXX +> > Layer: Consensus (soft fork) +> > Title: nLockTime signaling and flag day activation +> > Author: /dev/fd0 <alic...@protonmail.com> +> > Status: Draft +> > Type: Standards Track +> > Created: 2024-08-19 +> > License: Public Domain +> >=20 +> > ## Abstract +> >=20 +> > This document describes a process to activate soft forks using flag day +> > after `nLockTime` signaling and discussion. +> >=20 +> > ## Motivation +> >=20 +> > BIP 8 and BIP 9 are controversial. This BIP is an alternative which +> > addresses the problems with other activation methods. +> >=20 +> > ## Specification +> >=20 +> > - Assign numbers to different soft fork proposals or use their BIP=20 +> numbers +> > - Users can broadcast their transactions with one of these numbers used= +=20 +> as +> > `nLockTime` to show support +> > - Miners inlcuding a transaction in block would signal readiness for a= +=20 +> soft +> > fork +> > - Community can analyze these transactions after 3 months and prepare= +=20 +> for a +> > flag day activation of soft fork +> >=20 +> > Example: +> > Use 119 to signal support for OP_CHECKTEMPLATEVERIFY in `nLockTime` +> >=20 +> > ## Reference implementation +> >=20 +> > Activation: +> >=20 +> https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f3= +77f1cf514.diff +> >=20 +> > Exclusion in relay or mining: +> >=20 +> https://github.com/bitcoinknots/bitcoin/commit/18cd7b0ef6eaeacd06678c6d19= +2b6cacc9d7eee5.diff +> >=20 +> > --- +> >=20 +> > If a transaction does not get included in block for a long time, users= +=20 +> can +> > replace it with another transaction spending same inputs and use a +> > different `nLockTime`. +> >=20 +> > /dev/fd0 +> > floppy disk guy +> >=20 +> +> + +--=20 +You received this message because you are subscribed to the Google Groups "= +Bitcoin Development Mailing List" group. +To unsubscribe from this group and stop receiving emails from it, send an e= +mail to bitcoindev+unsubscribe@googlegroups.com. +To view this discussion on the web visit https://groups.google.com/d/msgid/= +bitcoindev/00e0601c-ed59-4245-a79d-0c36f1c8795bn%40googlegroups.com. + +------=_Part_286831_750641228.1724327039493 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi Murch,<div><br /></div><div>Thanks for reviewing the BIP draft and sugge= +sting improvements.</div><div><br /></div><div>>=C2=A0 I would suggest t= +he following areas of</div>improvement<div><br /></div><div>I have answered= + other responses and will reply to your feedback below. I will improve moti= +vation section and add rationale, backwards compatibility, syntax etc. by f= +irst week of September.</div><div><br /></div><div>>=C2=A0 + +I appreciate that the signaling mechanism you propose would introduce<br />= +a cost to signaling.=C2=A0</div><div><br /></div><div>This isn't the primar= +y goal of the BIP but exists because bitcoin transactions require fees. Oth= +erwise paid voting is possible on nostr using polls.</div><div><br /></div>= +<div>> if you were going to make a transaction anyway, it=E2=80=99s free= +, but otherwise you would have to pay to get your signal out there.</div><d= +iv><br /></div><div> + +The real signal we need to analyze after 3 months comes from users who part= +icipate in this signaling with transactions that were going to happen anywa= +y. These are the users with some economic activity whose opinion matters th= +e most for changes in consensus rules.=C2=A0</div><div><br /></div><div>>= +; Someone that may have sent a batched payments transaction might consider = +splitting it into multiple separate transactions instead to increase their = +signaling</div><div><br /></div><div>This depends on the analysis and I wou= +ld give more weight to the batch payment using nLockTime for signaling.</di= +v><div><br /></div><div>> Either way, it would be better to use the fiel= +d for anti-fee sniping, which also is not compatible with your signaling me= +chanism.</div><div><br /></div><div>Lot of transactions use zero as nLockTi= +me so signaling could work fine for at least next 12 years:=C2=A0<a href=3D= +"https://blockchair.com/bitcoin/transactions?s=3Dtime(desc)&q=3Dlock_ti= +me(0),time(2024-01-01..)#f=3Dtime,lock_time">https://blockchair.com/bitcoin= +/transactions?s=3Dtime(desc)&q=3Dlock_time(0),time(2024-01-01..)#f=3Dti= +me,lock_time</a></div><div><br /></div><div>> Most wallet software does = +not support setting the locktime manually, so some users that might want to= + signal support cannot without switching software.</div><div><br /></div><d= +iv>This signaling is mainly targeting economic nodes and I think most of th= +em would be able to do it. I will also create a website which can be used t= +o enter unsigned PSBT and change its nLockTime.</div><div><br /></div><div>= +> This introduces a new fingerprint for transactions pertaining to softw= +are that supports setting locktime manually.</div><div><br /></div><div>I a= +m not sure if this can be used to track anything meaningful which affects p= +rivacy.</div><div><br /></div><div>> A transaction can only set a single= + nLockTime value, so if there are multiple proposals that are up for debate= +, a transaction can only signal support for one. This could side-stepped by= + using nLockTime as a bit array where each position signals support for one= + proposal, much like BIP=E2=80=AF9.<br /><br />I like the idea of using bit= + array and I will update the draft accordingly.</div><div><br /></div><div>= +> but it=E2=80=99s unclear why one out of thousands of transactions shou= +ld be relevant whatsoever. Unless a very large portion of transactions sign= +als support, I=E2=80=99m not sure what we would learn from this signal at a= +ll.</div><div><br /></div><div>This depends on analysis and could be interp= +reted differently. Let me share an example:</div><div><br /></div><div>Alic= +e and Bob analyze these transactions after 3 months. Some blocks had only 1= + transaction that signaled support for a soft fork proposal. Alice marked t= +hem red and don't consider helpful or at the bottom in analysis report. Bob= + looked at each transaction and considered some different from others. In a= + transaction, Bitfinex moved some bitcoin from hot wallet to cold storage s= +o it was given some weight over others and marked with a different color.</= +div><div><br /></div><div>> Your proposal does not allow distinguishing = +between apathy and opposition: not signaling could mean either.</div><div><= +br /></div><div>I agree that proposal is focused on looking at support and = +not opposition. Still it could be visible if some nodes and miners try to r= +eject these transactions. If someone really has a genuine problem with any = +of these soft forks, best way to share it would be a technical review, test= + etc. posted on mailing list.</div><div><br /></div><div>> You suggest t= +hat miners could choose to exclude signaling transactions if they are not r= +eady, but it is much simpler for miners to do nothing, so the inclusion of = +signaling transactions cannot be interpreted as an endorsement.</div><div><= +br /></div><div>Miners never endorse any soft forks. Neither in this BIP no= +r BIP 8/9. Miners should always be ready for soft forks, but a coordination= + exercise before activation is always a safe approach in a decentralized ne= +twork.</div><div><br /></div><div>/dev/fd0</div><div>floppy disk guy</div><= +div><br /></div><div><br /></div><div class=3D"gmail_quote"><div dir=3D"aut= +o" class=3D"gmail_attr">On Wednesday, August 21, 2024 at 2:14:48=E2=80=AFPM= + UTC Murch wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D"marg= +in: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1= +ex;">Hello floppy and list, +<br> +<br>On 8/19/24 01:08, /dev /fd0 wrote: +<br> > Hi Bitcoin Developers, +<br> > +<br> > I am proposing an alternative way to activate soft forks. Please = +let +<br> > me know if you see any issues with this method. +<br> +<br>While your proposal may address some of the criticisms leveled at BIP= +=E2=80=AF8=20 +<br>and BIP=E2=80=AF9, it introduces new problems. +<br> +<br>1. I appreciate that the signaling mechanism you propose would introduc= +e=20 +<br>a cost to signaling. Unfortunately, this cost is unevenly distributed:= +=20 +<br>if you were going to make a transaction anyway, it=E2=80=99s free, but = +otherwise=20 +<br>you would have to pay to get your signal out there. It may also lead to= +=20 +<br>a distortion of usage. Someone that may have sent a batched payments=20 +<br>transaction might consider splitting it into multiple separate=20 +<br>transactions instead to increase their signaling for a reduced cost=20 +<br>compared to making transactions just for signaling, but increased=20 +<br>blockspace demand compared to their batched payments transaction. +<br> +<br>2. The `nLockTime` field is not unused. Transactions that have to set i= +t=20 +<br>to make use of other protocol functions are inherently prevented from= +=20 +<br>signaling. Either way, it would be better to use the field for anti-fee= +=20 +<br>sniping, which also is not compatible with your signaling mechanism. +<br> +<br>3. Most wallet software does not support setting the locktime manually,= +=20 +<br>so some users that might want to signal support cannot without switchin= +g=20 +<br>software. +<br> +<br>4. This introduces a new fingerprint for transactions pertaining to=20 +<br>software that supports setting locktime manually. +<br> +<br>5. A transaction can only set a single nLockTime value, so if there are= +=20 +<br>multiple proposals that are up for debate, a transaction can only signa= +l=20 +<br>support for one. This could side-stepped by using nLockTime as a bit=20 +<br>array where each position signals support for one proposal, much like B= +IP=E2=80=AF9. +<br> +<br>6. As already surfaced in your conversation with Fabian, it is up for= +=20 +<br>debate how the signaling data later would be interpreted. You mention= +=20 +<br>that spam could later be excluded, and blocks that include at least one= +=20 +<br>transaction that signals would be some sort of signal, but it=E2=80=99s= + unclear=20 +<br>why one out of thousands of transactions should be relevant whatsoever.= +=20 +<br>Unless a very large portion of transactions signals support, I=E2=80=99= +m not=20 +<br>sure what we would learn from this signal at all. +<br> +<br>7. Your proposal does not allow distinguishing between apathy and=20 +<br>opposition: not signaling could mean either. +<br> +<br>8. You suggest that miners could choose to exclude signaling=20 +<br>transactions if they are not ready, but it is much simpler for miners t= +o=20 +<br>do nothing, so the inclusion of signaling transactions cannot be=20 +<br>interpreted as an endorsement. +<br> +<br>Overall, this approach does not seem expedient to me, but should you=20 +<br>choose to maturate this proposal, I would suggest the following areas o= +f=20 +<br>improvement: +<br> +<br>- The proposal should address the questions brought up above and by=20 +<br>other responses +<br>- The motivation should describe in more detail the existing issues tha= +t=20 +<br>are being addressed, and how this proposal mitigates them +<br>- A rationale section should explain design choices, and put the=20 +<br>proposal into the context of alternate designs and related work +<br>- A backwards compatibility section should address how implementers=20 +<br>should think about this proposal in the context of other uses of=20 +<br>nLockTime such as anti-fee sniping +<br>- The specification should describe the syntax and semantics in=20 +<br>sufficient detail for other developers to implement the proposal +<br> +<br>Cheers, +<br> +<br>Murch +<br> +<br>>=20 +<br>> BIP: XXX +<br>> Layer: Consensus (soft fork) +<br>> Title: nLockTime signaling and flag day activation +<br>> Author: /dev/fd0 <<a href data-email-masked rel=3D"nofollo= +w">alic...@protonmail.com</a>> +<br>> Status: Draft +<br>> Type: Standards Track +<br>> Created: 2024-08-19 +<br>> License: Public Domain +<br>>=20 +<br>> ## Abstract +<br>>=20 +<br>> This document describes a process to activate soft forks using fla= +g day +<br>> after `nLockTime` signaling and discussion. +<br>>=20 +<br>> ## Motivation +<br>>=20 +<br>> BIP 8 and BIP 9 are controversial. This BIP is an alternative whic= +h +<br>> addresses the problems with other activation methods. +<br>>=20 +<br>> ## Specification +<br>>=20 +<br>> - Assign numbers to different soft fork proposals or use their BIP= + numbers +<br>> - Users can broadcast their transactions with one of these numbers= + used as +<br>> `nLockTime` to show support +<br>> - Miners inlcuding a transaction in block would signal readiness f= +or a soft +<br>> fork +<br>> - Community can analyze these transactions after 3 months and prep= +are for a +<br>> flag day activation of soft fork +<br>>=20 +<br>> Example: +<br>> Use 119 to signal support for OP_CHECKTEMPLATEVERIFY in `nLockTime= +` +<br>>=20 +<br>> ## Reference implementation +<br>>=20 +<br>> Activation: +<br>> <a href=3D"https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11= +e9c86bb2043c24f0f377f1cf514.diff" target=3D"_blank" rel=3D"nofollow" data-s= +aferedirecturl=3D"https://www.google.com/url?hl=3Den&q=3Dhttps://github= +.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514.diff&a= +mp;source=3Dgmail&ust=3D1724395355117000&usg=3DAOvVaw3jeU2oRHgK7n7a= +FP0LnBDD">https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb204= +3c24f0f377f1cf514.diff</a> +<br>>=20 +<br>> Exclusion in relay or mining: +<br>> <a href=3D"https://github.com/bitcoinknots/bitcoin/commit/18cd7b0e= +f6eaeacd06678c6d192b6cacc9d7eee5.diff" target=3D"_blank" rel=3D"nofollow" d= +ata-saferedirecturl=3D"https://www.google.com/url?hl=3Den&q=3Dhttps://g= +ithub.com/bitcoinknots/bitcoin/commit/18cd7b0ef6eaeacd06678c6d192b6cacc9d7e= +ee5.diff&source=3Dgmail&ust=3D1724395355117000&usg=3DAOvVaw0Z30= +WXkDq_BTiEvRql83-v">https://github.com/bitcoinknots/bitcoin/commit/18cd7b0e= +f6eaeacd06678c6d192b6cacc9d7eee5.diff</a> +<br>>=20 +<br>> --- +<br>>=20 +<br>> If a transaction does not get included in block for a long time, u= +sers can +<br>> replace it with another transaction spending same inputs and use a +<br>> different `nLockTime`. +<br>>=20 +<br>> /dev/fd0 +<br>> floppy disk guy +<br>>=20 +<br> +<br></blockquote></div> + +<p></p> + +-- <br /> +You received this message because you are subscribed to the Google Groups &= +quot;Bitcoin Development Mailing List" group.<br /> +To unsubscribe from this group and stop receiving emails from it, send an e= +mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind= +ev+unsubscribe@googlegroups.com</a>.<br /> +To view this discussion on the web visit <a href=3D"https://groups.google.c= +om/d/msgid/bitcoindev/00e0601c-ed59-4245-a79d-0c36f1c8795bn%40googlegroups.= +com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg= +id/bitcoindev/00e0601c-ed59-4245-a79d-0c36f1c8795bn%40googlegroups.com</a>.= +<br /> + +------=_Part_286831_750641228.1724327039493-- + +------=_Part_286830_41419725.1724327039493-- + |