From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 21 Aug 2024 07:14:55 -0700 Received: from mail-qv1-f62.google.com ([209.85.219.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sgm6w-00074Z-Kt for bitcoindev@gnusha.org; Wed, 21 Aug 2024 07:14:55 -0700 Received: by mail-qv1-f62.google.com with SMTP id 6a1803df08f44-6bf9926ba79sf47404276d6.3 for ; Wed, 21 Aug 2024 07:14:54 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1724249688; cv=pass; d=google.com; s=arc-20160816; b=DU2wLe/aZfxe9l6mSuCU8OeFJfXTeJpY5365GcRKD4fG/SI74QYXV6GnLR9Ps9T1xZ 6NrGDl+mInAWnNVaadbwOA64RKCXyYTA6v3vdcFTDOcFLlS5sZaj1yuITFHbo2kvfOmx OMvo6+BYLcDzhb32RshNaCQ2xxrt0DdrLcJ5VIXdwuWdoP3VHF7MnNRf+pMiR5Wvn37V VKJIlO/NA49QWleHdbj6xY8GNzf4/Um/jdC79zdR/D4OA1PuwOut3xqFULlfvP0qxjOl bqgWYmJD+IO9g5mWIn3JkoAvvyzAY+EJRo4eoYb7R3UrSCsSFsouqEIvUWZ7LjVY00Ua F8BQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding :in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:dkim-signature; bh=KpdCXRqEP7U53MtdKhgtj6Lk/0MuoGvlFrPuFlE6eKE=; fh=sbTdjRvx1TPEVaqwZEbyUJUdk4A8oaOTMcdKNuQMbj0=; b=N9EUJuc3r8aE2GCu7LsY4RMTE3vgMmKc8ghYYmh5nhPmpDPM1dOhld/+3/GUUsHHYg zNSjs2WMxu8dM0SMvKJ3EekeWTm2tmODmr8qxPpGubKNBy7YOwhlpzSZQseqi2vjaPQJ JKavs8s6XrjCfSr4ud6IHUJRRyYsAFNExBJ1FTG7PP3GElv7QllTOISJrvyTa+ueGHzR hsOMdcAjYrYAWPvg+7hichfqMY6CIhn8mgme1nycVQxgVWnQBZVRo+cDlZfkkKUUAIhU B78RJROYm4iBSG20dUKGDZqFlNDdlujVOcBUkh3pWYaUjGmmel8/Mb6COUSVVDRh5hVy NTXg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=FDxe9Z5v; spf=pass (google.com: domain of murch@murch.one designates 185.26.156.235 as permitted sender) smtp.mailfrom=murch@murch.one DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1724249688; x=1724854488; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=KpdCXRqEP7U53MtdKhgtj6Lk/0MuoGvlFrPuFlE6eKE=; b=mm+o8x+03v/a+gBPslA9ymYm5Opgfw1OeUFiYnizkUtF+yr5A3Gs9pKPgLYbC3vddF Uv9/e7Lz6YRqHU0JL+0iPWh8iF9iyV5/HBLPeXT0w94C4yG98fcFvSqsN2iob3eg/dn2 SiCsoth6QNr9mpZsXCU3tTB3zIqLvKaQJVjG7tTUlYpguCMelwtT1kuesEzEfCJYRi3D bhdLG8MpZ1acH8Q7p5ko9DOzQwNUAlNOXQeLBG5aybe+QIasD3y9pNb/tJPbb5vnqn2I qkH8DFrQmxn3GOOGkq9FPuZMgvC8iXegdB7FHLQE5UwPjXwMP7y+FXgOLIihc4ccElWv KHOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724249688; x=1724854488; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=KpdCXRqEP7U53MtdKhgtj6Lk/0MuoGvlFrPuFlE6eKE=; b=JcjnwrtODsAQMP/hg0toX0NbcsDaOJEyrqp2q4OLQl5Ije8QbUsr4K7OeqGGPfK9ma 1oN3BY2+4pZUC3tvhCf/kpqXEKNAh8kagb0fDrfOVN3y2lAGRUlo/v7J5d4+qhRdaTmX 0sj6jWAjrlDPyYkjWm4VzUfgs0DHetnEajpme3G1yVQpJZ0Z3ifFkXn8AoXHoDTLeC7Q zeQ7UghqiXl+EgTdI4T3NjCCDlVH82tPuAVuyUn0YZbdTAKo1DM2a3xrEJsaKZwlgbTd 3Rr8IJT/7ZcZv7H64nz7EkA4yEXNpB/bsY1B1XhyAbV7WFVTgbeZa6JodV2l3o1dNfQA zbig== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVUX/+WwmUq3tniywYBXvV8ynAEcn8XKLL+g57eIfvEBaf4P9x5PKVCysfP3JpmJY+Js5wjioxxCuYU@gnusha.org X-Gm-Message-State: AOJu0YxBiz3bGugdr5iRzZDc9OTekNSP//Ote8mvRm+ZcvJSKjuJbBiT nEULVwYDSmkjiV+4vsYoRgWi+kvhbh4l3vEu31YphjDJmI+fkhle X-Google-Smtp-Source: AGHT+IGHqximan0blRj52UPjuSYwYVm3W2j+IfcO1602Q9pVDzJBh+k+Fc7PM1GdI9GuaV/MPFcDbg== X-Received: by 2002:a05:6214:3b8a:b0:6bb:9b8d:b599 with SMTP id 6a1803df08f44-6c155de8072mr24032806d6.46.1724249687464; Wed, 21 Aug 2024 07:14:47 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6214:20c4:b0:6ad:782a:b4c9 with SMTP id 6a1803df08f44-6c15ac787f2ls12735916d6.1.-pod-prod-01-us; Wed, 21 Aug 2024 07:14:45 -0700 (PDT) X-Received: by 2002:a05:6214:20e2:b0:6bf:808b:a2a2 with SMTP id 6a1803df08f44-6c155d88863mr1595946d6.6.1724249685279; Wed, 21 Aug 2024 07:14:45 -0700 (PDT) Received: by 2002:a05:620a:389d:b0:79c:bd3:58c5 with SMTP id af79cd13be357-7a66b8fd288ms85a; Tue, 20 Aug 2024 11:05:26 -0700 (PDT) X-Received: by 2002:a05:600c:46ce:b0:426:593c:935d with SMTP id 5b1f17b1804b1-42abd21f59fmr1138155e9.5.1724177124413; Tue, 20 Aug 2024 11:05:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1724177124; cv=none; d=google.com; s=arc-20240605; b=QIoe/HnmOkwmneP/QYMb1pqtsLD1Odq5h+SJp3maMXJyVnme3KIrZC9zwHH6KPjGPZ mthFOnnvUAXlsQVslYwodHotKtgVCzxdqE6DXJgYdI8JTeAxbdkPQA/N+0aGdt9V3jun PbPk1X6ZbgUsDO75p6p2mwfcBtkUBuCrI78QfYe/EKmDmb5xbOEsl66x4kctsHu9iI4s s31YyLBAh3d/D54WABBUc1C30sx98IxIHK0V1tX25VEffwkbo3JDq5kjLCfnjeHpbdAb +RbjzhiBn1v6fc6zT1thzStoAkYVxugmAZVA3Zzrq9Qpanpbg/8+vJ9/mP6qQ1BMBTgL qTgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=dkim-signature:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id; bh=m1lgy6jXcYjMM4mOAzcQNU6EN+tKBBto47BN/6RyUEw=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=eCCrkWNEC5vVnB1SfuSbLNz2otfNjmMah03/KrLcQwFP2awiicEz+e5Uj9Fs1utsJP jDtqXeeZ7oiacQ6fA7pQp3Qv05Z6viax9jZaclIAg/ch8gYdS2PXLO8RKIir4N4JxGuk /uTBkX/wY7Dzzd8HqApXs+6AIGVUjijGDVZ7LxKWhAPZCPFs/8dcTa7hGX0vmu+hdDN6 x9WiE39g18b2C2sAqxMWUU5ofJWG7F2tN+xCuPF5tyU8k6N7TXB2F18W0PNs+85a/no+ 9sbQ+cEKbt4hVvY57Kn2iwzP5zvpPnxYk7dmRdFmX0bFCUVxfWhBNZf0pH9S1U28GnHW uo7w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=FDxe9Z5v; spf=pass (google.com: domain of murch@murch.one designates 185.26.156.235 as permitted sender) smtp.mailfrom=murch@murch.one Received: from farbauti.uberspace.de (farbauti.uberspace.de. [185.26.156.235]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-42ab87f8154si1108075e9.1.2024.08.20.11.05.24 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Aug 2024 11:05:24 -0700 (PDT) Received-SPF: pass (google.com: domain of murch@murch.one designates 185.26.156.235 as permitted sender) client-ip=185.26.156.235; Received: (qmail 14352 invoked by uid 989); 20 Aug 2024 18:05:24 -0000 Received: from unknown (HELO unkown) (::1) by farbauti.uberspace.de (Haraka/3.0.1) with ESMTPSA; Tue, 20 Aug 2024 20:05:23 +0200 Message-ID: <4de6a775-f9ed-44f0-bc93-7e74d64e36ad@murch.one> Date: Tue, 20 Aug 2024 14:05:22 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling To: bitcoindev@googlegroups.com References: <29d850d1-912a-4b15-ba41-cc36d05e7074n@googlegroups.com> Content-Language: en-US From: Murch In-Reply-To: <29d850d1-912a-4b15-ba41-cc36d05e7074n@googlegroups.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Bar: --- X-Rspamd-Report: BAYES_HAM(-3) XM_UA_NO_VERSION(0.01) MIME_GOOD(-0.1) X-Rspamd-Score: -3.09 X-Original-Sender: murch@murch.one X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=FDxe9Z5v; spf=pass (google.com: domain of murch@murch.one designates 185.26.156.235 as permitted sender) smtp.mailfrom=murch@murch.one 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.8 (/) 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 othe= rwise=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 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 unc= lear=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 no= t=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 number= s > - Users can broadcast their transactions with one of these numbers used a= s > `nLockTime` to show support > - Miners inlcuding a transaction in block would signal readiness for a so= ft > fork > - Community can analyze these transactions after 3 months and prepare for= a > flag day activation of soft fork >=20 > Example: > Use 119 to signal support for OP_CHECKTEMPLATEVERIFY in `nLockTime` >=20 > ## Reference implementation >=20 > Activation: > https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f3= 77f1cf514.diff >=20 > Exclusion in relay or mining: > 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 ca= n > 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/4de6a775-f9ed-44f0-bc93-7e74d64e36ad%40murch.one.