From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 28 Dec 2024 08:26:01 -0800 Received: from mail-yb1-f184.google.com ([209.85.219.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tRZdY-00018b-S7 for bitcoindev@gnusha.org; Sat, 28 Dec 2024 08:26:01 -0800 Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e3a0f608b88sf13628442276.0 for ; Sat, 28 Dec 2024 08:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1735403154; x=1736007954; 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=WlCHtWa1+11S5htgMBmH54VNgQLmFUCDyfM41+HgTIo=; b=uzajbApRT72sY62xx7e8IVMiz+ctc5Nh7FVnxEOQeGMwBwoIiRLOGFLTHvM7y8bb83 Koe+Kudzu9YnYUB+BX1vthK4w9N4/QYx+H2bSBvA3ph3Mphvcw1XPcumSiQpoiIRHpcE v6FpKCBO9dhA1GSzQIdHAyisEHVXGlcE4iofUIwqEzmE4JS7ycT41zXnwrhH1Pd1mI+i yVzYqR7d3J+4Llyw7IQUHCwZP9mHD6HnNJCnIt24GQU1o9AvzWH6TptQ5xvtKub/KVqV swZx+ROh9EBEdTmV3usvG8lgGTc03CVP4WZ6GZE1ZrIiqJg7jLdioEL3nhF1agNvG3M3 ipag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735403154; x=1736007954; 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=WlCHtWa1+11S5htgMBmH54VNgQLmFUCDyfM41+HgTIo=; b=AV2MW4+Ak6HxHCvGYrLeDHqtKs9ogiJ9s0PA2a5+VpIq8nP6eD/rSt6Nu1dh4VbKNF y5JSKHaYS40Ia19S2R21LuhPo6IJUduatWVO7XNNGgZrJ69m5U8Y4ZgRHiOoPxmPkBL9 1Dxx2YKdIg6zUe1F4lKhQHYv5WvQNCyzHWBsnC1OTtnSpUqYl+s9w/CluxJA3E2v6Gh4 NPFtyJalYFjBpoYOf6EKXtFemY0uqsiDs9UG0rR+ZLgnaXpCBIWkbXsRqU5VZH8YTs09 khfY4d21pVENdvgphCJKWY/ajK0aEs+yVf8UvhFPSw/9V6ILrY7V7cOsrclQM92qVOfG 9QZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735403154; x=1736007954; 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=WlCHtWa1+11S5htgMBmH54VNgQLmFUCDyfM41+HgTIo=; b=OwxaBYce7a+uRSGtGswpqyEsTZxnpg6tczkJGLPhZ1Kl3X+JLzSE3jhweX1S+yjQLK pwy5HaM82yzlKfwkoAIY4DccgWy4FU3ljkilEvujFkF0cBhQKMLXpt+F1osp3CDDGsZ1 vBZ/wMyNLzIUF1SQZdn3bnZZsp/TQPZ+7zyA0fXFSeGgaZjRAKWytb5x4//aFHBBg0E8 z77zH53LUzO9KhORs1nxLSdcAUUtqx4YNUvp+zsh8pXeQr00CoyeXyn01zFlxz0QZzHg RHNVebEAtlxz5NpeW1KaKT8iI4MAXVZuv+L+iv5rczFrQOxE/QJ2lRJ7HzhoWQv6ixFz z/eA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVKlbvIVe8agqSvsG0gOOGy/1ZhideF3/3t06PXWnAkhImSE07T7TxWrMU1bTwaSyTEXaintwFfSzjN@gnusha.org X-Gm-Message-State: AOJu0YyZqaIbprxoT97Dan9wujq0ssr/QI1eS9N31FVsy8zKbNycOw9I UgDhp/kqNlHk7kkUf4Zi26N4CG34eP5U9CYS067m61Z0KtIoK5o9 X-Google-Smtp-Source: AGHT+IGEV2Q8tLsmAfp6PHStI5icV4nPsKPzgEbTjBvn7iF9Zegz6GSWPWZomfSw8WHxzYxlvPUkRA== X-Received: by 2002:a05:6902:1a48:b0:e49:5f2d:e71d with SMTP id 3f1490d57ef6-e538c267d16mr23430767276.21.1735403154384; Sat, 28 Dec 2024 08:25:54 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:ad4f:0:b0:e22:6000:7f32 with SMTP id 3f1490d57ef6-e537600e8acls335259276.1.-pod-prod-08-us; Sat, 28 Dec 2024 08:25:51 -0800 (PST) X-Received: by 2002:a05:690c:67c7:b0:6ef:57ad:9d6e with SMTP id 00721157ae682-6f3f8118d2fmr248003427b3.15.1735403151382; Sat, 28 Dec 2024 08:25:51 -0800 (PST) Received: by 2002:a05:690c:951:b0:6ef:b1a3:15f0 with SMTP id 00721157ae682-6f3f552f45fms7b3; Sat, 28 Dec 2024 08:23:04 -0800 (PST) X-Received: by 2002:a05:690c:6e05:b0:6ef:7d51:ebb9 with SMTP id 00721157ae682-6f3f8201373mr233379767b3.34.1735402983670; Sat, 28 Dec 2024 08:23:03 -0800 (PST) Date: Sat, 28 Dec 2024 08:23:03 -0800 (PST) From: Owen Kemeys To: Bitcoin Development Mailing List Message-Id: <1b011053-d041-4a42-b56b-a4edd269391bn@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: Mandatory Inclusion of Old Transactions in Blocks MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_579634_14508257.1735402983243" X-Original-Sender: owenjk@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_579634_14508257.1735402983243 Content-Type: multipart/alternative; boundary="----=_Part_579635_1963714354.1735402983243" ------=_Part_579635_1963714354.1735402983243 Content-Type: text/plain; charset="UTF-8" Hi, Mempools are local to each node and there can never be any guarantee any given node has seen any given transaction. This proposal would result in regular chainsplits as some nodes reject blocks for failing to include ancient transactions that the miner simply did not know about. If we could be sure that all nodes had seen all transactions and agreed on their age and ordering, we would not need to bother with mining. On Saturday, 28 December 2024 at 09:58:16 UTC-6 developer wrote: > Status: Draft > Type: Standards Track > Created: December 27, 2024 > Abstract > > This proposal mandates miners to include at least 0.1% of transactions in > their blocks from the oldest transactions by date, even if they have low > fees. This mechanism helps prevent mining centralization and censorship, > encouraging miners not to exclude certain transactions. > Motivation > > The increasing centralization of Bitcoin mining and potential regulations > that may require miners to censor or exclude certain transactions pose a > threat to the Bitcoin network. Mandating the inclusion of a small > percentage of old transactions, even with low fees, ensures that no single > miner can censor block contents without sacrificing their own rewards. > Specification > > Mandatory Inclusion of Old even if with Low-Fee Transactions > Each miner is required to include at least 0.1% of the total > transactions in a block from the oldest transactions in the mempool, even > if their fees are below the current market average. > These transactions must be added to blocks regardless of their > fees, prioritizing their age. > > Block Validation > Bitcoin network nodes will validate blocks only if they contain > the required percentage of old transactions. > If a block fails to meet this criterion, it will be deemed invalid > and rejected by the network. > > Incentives > Miners are incentivized to include these transactions to ensure > their blocks are valid and to avoid losing block rewards. > > Advantages > > Censorship Resistance: Miners cannot censor transactions without > forfeiting their rewards. > Greater Inclusivity: Old and low-fee transactions are assured of being > confirmed. > Decentralization Prevention: Reducing the potential for centralized > censorship keeps the Bitcoin network decentralized. > > Considerations > > Impact on the Mempool: The mempool may become more dynamic and > up-to-date with fewer old, stagnant transactions. > Resource Management: Miners will need to adjust their systems to > automatically identify and include relevant transactions. > > Conclusion > > Implementing this BIP will help maintain the integrity and > decentralization of the Bitcoin network, preventing censorship and ensuring > all transactions have a fair chance of confirmation. -- 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 email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1b011053-d041-4a42-b56b-a4edd269391bn%40googlegroups.com. ------=_Part_579635_1963714354.1735402983243 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Mempools are local to each node and there can never be a= ny guarantee any given node has seen any given transaction. This proposal w= ould result in regular chainsplits as some nodes reject blocks for failing = to include ancient transactions that the miner simply did not know about.
If we could be sure that all nodes had seen all transactions= and agreed on their age and ordering, we would not need to bother with min= ing.

On Saturday, 28 December 2024 at 09:58:16 UTC-6 developer wrot= e:
Status: Dr= aft
Type: Standards Track
Created: December 27, 2024
Abstract
<= br>This proposal mandates miners to include at least 0.1% of transactions i= n their blocks from the oldest transactions by date, even if they have low = fees. This mechanism helps prevent mining centralization and censorship, en= couraging miners not to exclude certain transactions.
Motivation

= The increasing centralization of Bitcoin mining and potential regulations t= hat may require miners to censor or exclude certain transactions pose a thr= eat to the Bitcoin network. Mandating the inclusion of a small percentage o= f old transactions, even with low fees, ensures that no single miner can ce= nsor block contents without sacrificing their own rewards.
Specification=

=C2=A0 =C2=A0 Mandatory Inclusion of Old even if with Low-Fee Trans= actions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Each miner is required to include at= least 0.1% of the total transactions in a block from the oldest transactio= ns in the mempool, even if their fees are below the current market average.=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 These transactions must be added to blocks = regardless of their fees, prioritizing their age.

=C2=A0 =C2=A0 Bloc= k Validation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bitcoin network nodes will vali= date blocks only if they contain the required percentage of old transaction= s.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If a block fails to meet this criterion, = it will be deemed invalid and rejected by the network.

=C2=A0 =C2=A0= Incentives
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Miners are incentivized to inclu= de these transactions to ensure their blocks are valid and to avoid losing = block rewards.

Advantages

=C2=A0 =C2=A0 Censorship Resistance= : Miners cannot censor transactions without forfeiting their rewards.
= =C2=A0 =C2=A0 Greater Inclusivity: Old and low-fee transactions are assured= of being confirmed.
=C2=A0 =C2=A0 Decentralization Prevention: Reducing= the potential for centralized censorship keeps the Bitcoin network decentr= alized.

Considerations

=C2=A0 =C2=A0 Impact on the Mempool: T= he mempool may become more dynamic and up-to-date with fewer old, stagnant = transactions.
=C2=A0 =C2=A0 Resource Management: Miners will need to adj= ust their systems to automatically identify and include relevant transactio= ns.

Conclusion

Implementing this BIP will help maintain the i= ntegrity and decentralization of the Bitcoin network, preventing censorship= and ensuring all transactions have a fair chance of confirmation.

--
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 visit https://groups.google.com/d/msgid/bitcoind= ev/1b011053-d041-4a42-b56b-a4edd269391bn%40googlegroups.com.
------=_Part_579635_1963714354.1735402983243-- ------=_Part_579634_14508257.1735402983243--