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 ) 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 ; 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 To: Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 > > 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,

Thanks for reviewing the BIP draft and sugge= sting improvements.

>=C2=A0 I would suggest t= he following areas of
improvement

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.

>=C2=A0 I appreciate that the signaling mechanism you propose would introduce
= a cost to signaling.=C2=A0

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.

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

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

>= ; Someone that may have sent a batched payments transaction might consider = splitting it into multiple separate transactions instead to increase their = signaling

This depends on the analysis and I wou= ld give more weight to the batch payment using nLockTime for signaling.

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

Lot of transactions use zero as nLockTi= me so signaling could work fine for at least next 12 years:=C2=A0https://blockchair.com/bitcoin= /transactions?s=3Dtime(desc)&q=3Dlock_time(0),time(2024-01-01..)#f=3Dti= me,lock_time

> Most wallet software does = not support setting the locktime manually, so some users that might want to= signal support cannot without switching software.

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.

= > This introduces a new fingerprint for transactions pertaining to softw= are that supports setting locktime manually.

I a= m not sure if this can be used to track anything meaningful which affects p= rivacy.

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

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

This depends on analysis and could be interp= reted differently. Let me share an example:

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.

> Your proposal does not allow distinguishing = between apathy and opposition: not signaling could mean either.
<= br />
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.

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

/dev/fd0
floppy disk guy
<= div>

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 introduc= e=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 = otherwise=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 i= t=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 switchin= g=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 signa= l=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 B= IP=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= unclear=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=99= m 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 t= o=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 o= f=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 tha= t=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 fla= g day
> after `nLockTime` signaling and discussion.
>=20
> ## Motivation
>=20
> BIP 8 and BIP 9 are controversial. This BIP is an alternative whic= h
> addresses the problems with other activation methods.
>=20
> ## Specification
>=20
> - Assign numbers to different soft fork proposals or use their BIP= numbers
> - Users can broadcast their transactions with one of these numbers= used as
> `nLockTime` to show support
> - Miners inlcuding a transaction in block would signal readiness f= or a soft
> fork
> - Community can analyze these transactions after 3 months and prep= are 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:
> https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb204= 3c24f0f377f1cf514.diff
>=20
> Exclusion in relay or mining:
> https://github.com/bitcoinknots/bitcoin/commit/18cd7b0e= f6eaeacd06678c6d192b6cacc9d7eee5.diff
>=20
> ---
>=20
> If a transaction does not get included in block for a long time, u= sers can
> replace it with another transaction spending same inputs and use a
> different `nLockTime`.
>=20
> /dev/fd0
> floppy disk guy
>=20

--
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/00e0601c-ed59-4245-a79d-0c36f1c8795bn%40googlegroups.com.=
------=_Part_286831_750641228.1724327039493-- ------=_Part_286830_41419725.1724327039493--