diff options
| author | developer <estensioni.app@gmail.com> | 2024-12-29 08:35:01 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2024-12-29 08:41:46 -0800 |
| commit | 7d0df1d7e5642532cf43d6f48888f11332a4aaac (patch) | |
| tree | b1373f4b95a122ab76380b55db7e002281ddcfa2 | |
| parent | fcc2701905b6476098a57c5d9e02e01ac7390810 (diff) | |
| download | pi-bitcoindev-7d0df1d7e5642532cf43d6f48888f11332a4aaac.tar.gz pi-bitcoindev-7d0df1d7e5642532cf43d6f48888f11332a4aaac.zip | |
Re: [bitcoindev] Mandatory Inclusion of Old Transactions in Blocks
| -rw-r--r-- | 79/b93d3c8f40715707d41cd1b4a2e8158496005e | 824 |
1 files changed, 824 insertions, 0 deletions
diff --git a/79/b93d3c8f40715707d41cd1b4a2e8158496005e b/79/b93d3c8f40715707d41cd1b4a2e8158496005e new file mode 100644 index 000000000..cee79e699 --- /dev/null +++ b/79/b93d3c8f40715707d41cd1b4a2e8158496005e @@ -0,0 +1,824 @@ +Delivery-date: Sun, 29 Dec 2024 08:41:46 -0800 +Received: from mail-yb1-f188.google.com ([209.85.219.188]) + by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + (Exim 4.94.2) + (envelope-from <bitcoindev+bncBCHP5NV7XEGBBP7XYW5QMGQEFRJJZXQ@googlegroups.com>) + id 1tRwMK-0005dx-V0 + for bitcoindev@gnusha.org; Sun, 29 Dec 2024 08:41:46 -0800 +Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e391a40d431sf16820816276.0 + for <bitcoindev@gnusha.org>; Sun, 29 Dec 2024 08:41:44 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=googlegroups.com; s=20230601; t=1735490498; x=1736095298; 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=ip0An1eTJJw/mAtFRYik4/fcyczyUTxXlsviE3yXbSw=; + b=j3KXgS5Tts0Q4+bixLwpWi15Kc9ArVsxFhwXf2NQXY8aU1PV6nHqnaxjl4NTEUylZ/ + YdHpm5VQacQm3NI/f86UDT7X/8XGfhK8r4f7YoJci/wboVaQudmsoPsyd8x1HK6MFqfh + G//wYRmh3SyFz/cGMM1xpG8O688dzXT4KYovvt9/6fWo7/OPGzY0vWyApCc0c1sDjq1W + daiLL1OwO6GeEwX18z+GEt0q9jARz45TMkr+JzFUIjoq7EXATGqcAze7qARh/7Qv/Fs6 + 8fxoiN84kyQ3X8NnuR6tuY/ieldzO3caU5MTLiCts4IoHsBql9wsWLJIOL5wlQ9cIvcj + 7OZA== +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1735490498; x=1736095298; 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=ip0An1eTJJw/mAtFRYik4/fcyczyUTxXlsviE3yXbSw=; + b=T1HC44x3RKihrefzreuL25ZoDQ5hQqKpC81tYyEIpm/JQQ8LWspqwfiluzjpPRHrNH + eY3nB8u0aOWrzFQtXitRmZg0TUiYLpLc6CKBzintHK7wODsgUOANfjP1W59KrWe7JNOv + 2seS9cDuGQGWX6vTgf6OH3p19uQIdi9t2wTdN6I30E8Fo3c1ODXSZYkd6r/yp8bC3Cj2 + H2fuZTxGq+ZEabH3EiCWXX2ikSEarwaeH9RoOS0rqyvb4y14JXV/bwQQVzPU3rwzqSX9 + P3saXMmCLAzjMNBtWME2RbfdAyBNAuM5zOn4JoYVwnkOBYsbxs+nos0/LEUKZDS3kyud + 9Umg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1735490498; x=1736095298; + 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=ip0An1eTJJw/mAtFRYik4/fcyczyUTxXlsviE3yXbSw=; + b=ChX2xwcNU6wzB78FTRZ3hFN0nDByHbKLbYjbDvTvACiCBRR6jJIYZurHCE8y6afDEv + ak6piYwWn/0c8soaNRsc5+jVWXTFnY6acHvSK/ouWM2HwVZo8zOOWYmk0wEQ6zPSH0nq + PkoxntEn+3rDOirtoeicS7qAJvt+hoSYwWyeWZwcAqvPGsO4imrtaX1MM05rSZ2C7din + bPp2heZXdHKxB1UFEDlFbGh1U8+JvIXybdHUy3rXoKmlDBjMcxVOCrfeqqxliMdGx44o + wCnYJbjjCz00sinDtgl77ptMQV1IS6sQN0g2F0IEp2oT4TzMnR52VRjnRIPb6G20vuh9 + 2GyQ== +Sender: bitcoindev@googlegroups.com +X-Forwarded-Encrypted: i=1; AJvYcCU9pILfRiHImX+RZCt5Cy3PQNyfVqKQ9WL59jrzcpebbgK2WFGzQK1kIZHKC7mIK6WAME7RM/eyxxeM@gnusha.org +X-Gm-Message-State: AOJu0Yxdy3AXWqsWInohJXvbpm+wasnVf2xlrVmOpMOf5Pn32z49QGDh + SabHr7LufRBBoKI6OsvOUcTwJkwA39meB06oEqwPlMOtFs4gut8a +X-Google-Smtp-Source: AGHT+IEpVoM/uQjXRHkVd0kouisBd5bO/3VyOjaPJ/OM12nl3CWxTqOwkPBuoAqv1lnkNo4QHJPCWA== +X-Received: by 2002:a05:6902:1b84:b0:e4b:fe5:5dc7 with SMTP id 3f1490d57ef6-e538c42758emr25251353276.43.1735490498263; + Sun, 29 Dec 2024 08:41:38 -0800 (PST) +X-BeenThere: bitcoindev@googlegroups.com +Received: by 2002:a25:6f0b:0:b0:e38:94e3:87e with SMTP id 3f1490d57ef6-e5375c61225ls1408636276.0.-pod-prod-07-us; + Sun, 29 Dec 2024 08:41:34 -0800 (PST) +X-Received: by 2002:a05:690c:f0f:b0:6ef:6107:69c9 with SMTP id 00721157ae682-6f3f80cdf67mr179685657b3.4.1735490494629; + Sun, 29 Dec 2024 08:41:34 -0800 (PST) +Received: by 2002:a05:690c:b10:b0:6ef:9b37:85ef with SMTP id 00721157ae682-6f484ea9c59ms7b3; + Sun, 29 Dec 2024 08:35:03 -0800 (PST) +X-Received: by 2002:a05:690c:102:b0:6f2:9533:8fb1 with SMTP id 00721157ae682-6f3f80cdf5cmr213411297b3.7.1735490101944; + Sun, 29 Dec 2024 08:35:01 -0800 (PST) +Date: Sun, 29 Dec 2024 08:35:01 -0800 (PST) +From: developer <estensioni.app@gmail.com> +To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com> +Message-Id: <fa02c975-8cac-40ec-8497-71f288dda177n@googlegroups.com> +In-Reply-To: <CAEM=y+V5RTz2g8JvbLuZ3zs2RAmNPrN3WvKVfU7X69pD2j-8nw@mail.gmail.com> +References: <fa4a8cd3-778c-4793-8dd4-5662475b6601n@googlegroups.com> + <CAAg3Je3k4RrQzUQ-x-D81NeMPsFuZTVYFKem9uN9MYP-CnmdRg@mail.gmail.com> + <CAEM=y+V5RTz2g8JvbLuZ3zs2RAmNPrN3WvKVfU7X69pD2j-8nw@mail.gmail.com> +Subject: Re: [bitcoindev] Mandatory Inclusion of Old Transactions in Blocks +MIME-Version: 1.0 +Content-Type: multipart/mixed; + boundary="----=_Part_619762_26719530.1735490101606" +X-Original-Sender: estensioni.app@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_619762_26719530.1735490101606 +Content-Type: multipart/alternative; + boundary="----=_Part_619763_734060683.1735490101606" + +------=_Part_619763_734060683.1735490101606 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +=20 + +I would like to explain the concept better. I am not very technical, but I= +=20 +would like to leave a contribution by talking about this topic that could= +=20 +become reality. In a context of censorship and control, even a seemingly=20 +infallible system like Bitcoin could be subject to impositions by strong=20 +powers. The goal is to make the entire structure more robust, proposing a= +=20 +desirable improvement for the future. How invasive it can be is to be=20 +tested, but the idea is to exploit everything that already exists without= +=20 +introducing new things. + +Assumption =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +I start from the basic assumption that a wallet, when signing and sending= +=20 +the transaction, inserts the sending timestamp in the "nLockTime" field=20 +(usually set to 0). + +=E2=80=9CnLockTime=E2=80=9D is designed to indicate the earliest time a tra= +nsaction is=20 +eligible to be included in a block (USUALLY USED FOR THEFT) and is only=20 +considered if the nSequence field is less than 0xFFFFFFFF (for example,=20 +0xFFFFFFFE). Today I imagine that most transactions with RBF already set=20 +this field in a way to allow users to create a transaction that can be=20 +replaced by a new transaction with a higher fee if necessary. + +Using =E2=80=9CnLockTime=E2=80=9D is therefore possible and legal. + +Inserting the timestamp would not be an improper use at all, but only a=20 +confirmation of the will to insert the block starting from the timestamp=20 +(immediately). + +Analysis =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Getting into practice, the ordering of transactions occurs mainly in the=20 +data structure called indexed_transaction_set, defined using Boost=20 +MultiIndex. The mempool uses an index based on the fee rate to classify the= +=20 +transactions. The CompareTxMemPoolEntryByFee function compares transactions= +=20 +based on the fee rate, which is the ratio of the total transaction fee=20 +(GetFee()) to the size of the transaction (GetTxSize()). This structure=20 +allows the mempool to maintain a natural order based on fees per byte=20 +(sat/vByte). + +The txmempool.cpp file implements the main functions for adding and=20 +removing transactions from the mempool, maintaining the order. The size_t= +=20 +CTxMemPool::TrimToSize(size_t sizelimit) function adds an unchecked=20 +transaction to the mempool and updates the indexes (including the fee rate= +=20 +index). + +(Removing Transactions) + +Transactions can be removed from the mempool if: + +=E2=80=A2 They are included in a block. + +=E2=80=A2 They exceed the space limits of the mempool. + +=E2=80=A2 They are replaced by other transactions with a higher fee rate=20 +(Replace-by-Fee, or RBF). + +When the mempool reaches the memory limit (mempoollimit), transactions with= +=20 +lower fee rates are removed to make room for those with higher fee rates.= +=20 +The TrimToSize() function in txmempool.cpp handles this logic, keeping only= +=20 +the transactions with the highest fee rates. + +Intervention =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Integrating nLockTime-based sorting along with fee rate into the Boost=20 +MultiIndex indexed_transaction_set structure in the mempool would require= +=20 +some fine-grained, but not overly invasive, changes. The complexity depends= +=20 +on how you want to balance the two criteria (fee rate and nLockTime) and=20 +the philosophy with which these rules should interact. Here is one possible= +=20 +version: + +1. Updating the data structure + +The indexed_transaction_set uses Boost MultiIndex, allowing you to define= +=20 +multiple indexes for ranking. Currently, one of the main indexes is the=20 +CompareTxMemPoolEntryByFee for fee rate. To add nLockTime support, we need= +=20 +to implement a new comparator that takes both the fee rate and the=20 +nLockTime into account. + +To implement the logic that removes the transactions with the lowest fee=20 +rate and the most recent timestamp from the mempool (so that older=20 +transactions are taken into account), we need to change the eviction=20 +criterion in the TrimToSize function. + +2. Updating the TrimToSize function + +In the txmempool.cpp file, I modify the TrimToSize function to use a new=20 +sorting that considers the fee rate first (in ascending order) and then the= +=20 +nLockTime (in descending order, to give importance to older transactions). + +Example of a hypothetical implementation of the TrimToSize function: + +size_t CTxMemPool::TrimToSize(size_t sizelimit) { + +LOCK(cs); + +while (DynamicMemoryUsage() > sizelimit) { + +// Use the primary index to get the transaction with the lowest fee rate + +// and the most recent nLockTime + +auto it =3D mapTx.get<0>().begin(); // The order is based on the new=20 +comparator + + +// Remove the selected transaction + +removeUnchecked(mapTx.project<0>(it)); + +} + +return DynamicMemoryUsage(); + +} + + +This code assumes that the sort order of mapTx has already been updated to= +=20 +reflect the desired order. + +3. Modify the CompareTxMemPoolEntryByFeeAndLockTime comparator + +To ensure that the transaction selected by mapTx.get<0>() is the one with= +=20 +the lowest fee rate and the most recent timestamp, we update the comparator= +: + +struct CompareTxMemPoolEntryByFeeAndLockTime { + +bool operator()(const CTxMemPoolEntry& a, const CTxMemPoolEntry& b) const { + +// First priority: Fee rate (increasing, to remove the lowest fees first) + +if (a.GetFeeRate() !=3D b.GetFeeRate()) { + +return a.GetFeeRate() < b.GetFeeRate(); + +} + +// Second priority: nLockTime (decreasing, to remove the most recent=20 +timestamps first) + +return a.GetTx().nLockTime > b.GetTx().nLockTime; + +} + +}; + +With this comparator: + +1. Transactions with the lowest fee rate are selected first. + +2. For the same fee rate, those with the most recent nLockTime (highest=20 +timestamp) are selected. + +Conclusion + +With these changes: + +=E2=80=A2 The mempool removes transactions with the lowest fee rate first. + +=E2=80=A2 Among transactions with the same fee rate, those with the most re= +cent=20 +nLockTime (highest timestamp) are removed first. + +=E2=80=A2 This ensures that older transactions, even with low fees, have a = +higher=20 +chance of being included in a block, reducing the risk of stagnating in the= +=20 +mempool. + +This could be a first approach, it would then be possible to evaluate a=20 +greater weight to the timestamp in order to introduce at least a part of=20 +stagnant transactions in new blocks. It is not a question of forcing the=20 +mempool to implement the changes since these are ethical and cooperation=20 +issues. Nature is cooperative, there is no free market. +Il giorno sabato 28 dicembre 2024 alle 19:50:43 UTC+1 Ethan Heilman ha=20 +scritto: + +> You say: +> +> > Bitcoin network nodes will validate blocks only if they contain the=20 +> required percentage of old transactions. If a block fails to meet this=20 +> criterion, it will be deemed invalid and rejected by the network. +> +> This requires that network nodes reach consensus on what the oldest +> transactions are. This is the technical problem you need to solve to +> make your proposal practical, but I don't see that as a bad thing as +> it is a very interesting problem. If you can solve this problem, you +> can probably also solve the problem of how to enforce that Bitcoin +> miners only include the transactions with the highest fee rate. +> Enforcing the highest fee rate at the consensus level may be an +> effective tool against MEVil. +> +> This does seem like a hard problem to solve, because reaching +> consensus on transactions in mempool is very similar to what bitcoin +> blocks are already trying to achieve. Perhaps there is a more creative +> solution. It is worth looking at but it doesn't seem ready for a BIP. +> +> On Sat, Dec 28, 2024 at 11:26=E2=80=AFAM Michael Cassano <mcas...@gmail.c= +om>=20 +> wrote: +> > +> > I reject the premise of this proposed BIP. Mandating miners to include = +a=20 +> specific percentage of transactions based on age fundamentally undermines= +=20 +> the core principles of Bitcoin: decentralization, voluntary participation= +,=20 +> and free market dynamics. +> > +> > Bitcoin thrives because of its permissionless, free-market system.=20 +> Miners are incentivized to prioritize transactions based on fees and=20 +> network conditions, not arbitrary mandates. Imposing a rule like this=20 +> introduces central planning into what is a decentralized system. +> > +> > The proposal claims to fight centralization, but will likely backfire.= +=20 +> Mandates like this add operational complexity and reduce efficiency for= +=20 +> miners. Smaller miners, who are already operating on thin margins, will b= +e=20 +> disproportionately impacted, driving them out of the market and further= +=20 +> centralizing mining power. If censorship-resistant mining is valuable, le= +t=20 +> the free market reward those who provide it. If there=E2=80=99s demand fo= +r miners=20 +> to include old or low-fee transactions, let someone build tools and pools= +=20 +> that prioritize this voluntarily. Solutions shall arise from innovation,= +=20 +> not coercion. +> > +> > Best regards, +> > Mike +> > +> > On Sat, Dec 28, 2024 at 8:58=E2=80=AFAM developer <estensi...@gmail.com= +> wrote: +> >> +> >> Status: Draft +> >> Type: Standards Track +> >> Created: December 27, 2024 +> >> Abstract +> >> +> >> This proposal mandates miners to include at least 0.1% of transactions= +=20 +> in their blocks from the oldest transactions by date, even if they have l= +ow=20 +> fees. This mechanism helps prevent mining centralization and censorship,= +=20 +> encouraging miners not to exclude certain transactions. +> >> Motivation +> >> +> >> The increasing centralization of Bitcoin mining and potential=20 +> regulations that may require miners to censor or exclude certain=20 +> transactions pose a threat to the Bitcoin network. Mandating the inclusio= +n=20 +> of a small percentage of old transactions, even with low fees, ensures th= +at=20 +> no single miner can censor block contents without sacrificing their own= +=20 +> 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=20 +> transactions in a block from the oldest transactions in the mempool, even= +=20 +> if their fees are below the current market average. +> >> These transactions must be added to blocks regardless of their fees,= +=20 +> prioritizing their age. +> >> +> >> Block Validation +> >> Bitcoin network nodes will validate blocks only if they contain the=20 +> required percentage of old transactions. +> >> If a block fails to meet this criterion, it will be deemed invalid and= +=20 +> rejected by the network. +> >> +> >> Incentives +> >> Miners are incentivized to include these transactions to ensure their= +=20 +> blocks are valid and to avoid losing block rewards. +> >> +> >> Advantages +> >> +> >> Censorship Resistance: Miners cannot censor transactions without=20 +> forfeiting their rewards. +> >> Greater Inclusivity: Old and low-fee transactions are assured of being= +=20 +> confirmed. +> >> Decentralization Prevention: Reducing the potential for centralized=20 +> censorship keeps the Bitcoin network decentralized. +> >> +> >> Considerations +> >> +> >> Impact on the Mempool: The mempool may become more dynamic and=20 +> up-to-date with fewer old, stagnant transactions. +> >> Resource Management: Miners will need to adjust their systems to=20 +> automatically identify and include relevant transactions. +> >> +> >> Conclusion +> >> +> >> Implementing this BIP will help maintain the integrity and=20 +> decentralization of the Bitcoin network, preventing censorship and ensuri= +ng=20 +> all transactions have a fair chance of confirmation. +> >> +> >> -- +> >> You received this message because you are subscribed to the Google=20 +> Groups "Bitcoin Development Mailing List" group. +> >> To unsubscribe from this group and stop receiving emails from it, send= +=20 +> an email to bitcoindev+...@googlegroups.com. +> >> To view this discussion visit=20 +> https://groups.google.com/d/msgid/bitcoindev/fa4a8cd3-778c-4793-8dd4-5662= +475b6601n%40googlegroups.com +> . +> > +> > -- +> > You received this message because you are subscribed to the Google=20 +> Groups "Bitcoin Development Mailing List" group. +> > To unsubscribe from this group and stop receiving emails from it, send= +=20 +> an email to bitcoindev+...@googlegroups.com. +> > To view this discussion visit=20 +> https://groups.google.com/d/msgid/bitcoindev/CAAg3Je3k4RrQzUQ-x-D81NeMPsF= +uZTVYFKem9uN9MYP-CnmdRg%40mail.gmail.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 visit https://groups.google.com/d/msgid/bitcoindev/= +fa02c975-8cac-40ec-8497-71f288dda177n%40googlegroups.com. + +------=_Part_619763_734060683.1735490101606 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + + + + +=09 + <span></span> +=09 +=09 + +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm; break-bef= +ore: page;"> +I would like to explain the concept better. I am not very technical, +but I would like to leave a contribution by talking about this topic +that could become reality. In a context of censorship and control, +even a seemingly infallible system like Bitcoin could be subject to +impositions by strong powers. The goal is to make the entire +structure more robust, proposing a desirable improvement for the +future. How invasive it can be is to be tested, but the idea is to +exploit everything that already exists without introducing new +things.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">Assumpti= +on +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">I start +from the basic assumption that a wallet, when signing and sending the +transaction, inserts the sending timestamp in the "nLockTime" +field (usually set to 0).</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">=E2=80= +=9CnLockTime=E2=80=9D +is designed to indicate the earliest time a transaction is eligible +to be included in a block (USUALLY USED FOR THEFT) and is only +considered if the nSequence field is less than 0xFFFFFFFF (for +example, 0xFFFFFFFE). Today I imagine that most transactions with RBF +already set this field in a way to allow users to create a +transaction that can be replaced by a new transaction with a higher +fee if necessary.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">Using +=E2=80=9CnLockTime=E2=80=9D is therefore possible and legal.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">Insertin= +g +the timestamp would not be an improper use at all, but only a +confirmation of the will to insert the block starting from the +timestamp (immediately).</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">Analysis +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">Getting +into practice, the ordering of transactions occurs mainly in the data +structure called indexed_transaction_set, defined using Boost +MultiIndex. The mempool uses an index based on the fee rate to +classify the transactions. The CompareTxMemPoolEntryByFee function +compares transactions based on the fee rate, which is the ratio of +the total transaction fee (GetFee()) to the size of the transaction +(GetTxSize()). This structure allows the mempool to maintain a +natural order based on fees per byte (sat/vByte).</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">The +txmempool.cpp file implements the main functions for adding and +removing transactions from the mempool, maintaining the order. The +size_t CTxMemPool::TrimToSize(size_t sizelimit) function adds an +unchecked transaction to the mempool and updates the indexes +(including the fee rate index).</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">(Removin= +g +Transactions)</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">Transact= +ions +can be removed from the mempool if:</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">=E2=80= +=A2 +They are included in a block.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">=E2=80= +=A2 +They exceed the space limits of the mempool.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">=E2=80= +=A2 +They are replaced by other transactions with a higher fee rate +(Replace-by-Fee, or RBF).</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">When +the mempool reaches the memory limit (mempoollimit), transactions +with lower fee rates are removed to make room for those with higher +fee rates. The TrimToSize() function in txmempool.cpp handles this +logic, keeping only the transactions with the highest fee rates.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">Interven= +tion +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">Integrat= +ing +nLockTime-based sorting along with fee rate into the Boost MultiIndex +indexed_transaction_set structure in the mempool would require some +fine-grained, but not overly invasive, changes. The complexity +depends on how you want to balance the two criteria (fee rate and +nLockTime) and the philosophy with which these rules should interact. +Here is one possible version:</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">1. +Updating the data structure</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">The +indexed_transaction_set uses Boost MultiIndex, allowing you to define +multiple indexes for ranking. Currently, one of the main indexes is +the CompareTxMemPoolEntryByFee for fee rate. To add nLockTime +support, we need to implement a new comparator that takes both the +fee rate and the nLockTime into account.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">To +implement the logic that removes the transactions with the lowest fee +rate and the most recent timestamp from the mempool (so that older +transactions are taken into account), we need to change the eviction +criterion in the TrimToSize function.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">2. +Updating the TrimToSize function</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">In the +txmempool.cpp file, I modify the TrimToSize function to use a new +sorting that considers the fee rate first (in ascending order) and +then the nLockTime (in descending order, to give importance to older +transactions).</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">Example +of a hypothetical implementation of the TrimToSize function:</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">size_t +CTxMemPool::TrimToSize(size_t sizelimit) {</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">LOCK(cs)= +;</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">while +(DynamicMemoryUsage() > sizelimit) {</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">// Use +the primary index to get the transaction with the lowest fee rate</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">// and +the most recent nLockTime</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">auto it +=3D mapTx.get<0>().begin(); // The order is based on the new +comparator</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;"><br /> + +</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">// +Remove the selected transaction</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">removeUn= +checked(mapTx.project<0>(it));</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">}</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">return +DynamicMemoryUsage();</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">}</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;"><br /> + +</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">This +code assumes that the sort order of mapTx has already been updated to +reflect the desired order.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">3. +Modify the CompareTxMemPoolEntryByFeeAndLockTime comparator</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">To +ensure that the transaction selected by mapTx.get<0>() is the +one with the lowest fee rate and the most recent timestamp, we update +the comparator:</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">struct +CompareTxMemPoolEntryByFeeAndLockTime {</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">bool +operator()(const CTxMemPoolEntry& a, const CTxMemPoolEntry& +b) const {</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">// +First priority: Fee rate (increasing, to remove the lowest fees +first)</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">if +(a.GetFeeRate() !=3D b.GetFeeRate()) {</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">return +a.GetFeeRate() < b.GetFeeRate();</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">}</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">// +Second priority: nLockTime (decreasing, to remove the most recent +timestamps first)</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">return +a.GetTx().nLockTime > b.GetTx().nLockTime;</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">}</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">};</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">With +this comparator:</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">1. +Transactions with the lowest fee rate are selected first.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">2. For +the same fee rate, those with the most recent nLockTime (highest +timestamp) are selected.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">Conclusi= +on</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">With +these changes:</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">=E2=80= +=A2 The +mempool removes transactions with the lowest fee rate first.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">=E2=80= +=A2 +Among transactions with the same fee rate, those with the most recent +nLockTime (highest timestamp) are removed first.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">=E2=80= +=A2 +This ensures that older transactions, even with low fees, have a +higher chance of being included in a block, reducing the risk of +stagnating in the mempool.</p> +<p align=3D"left" style=3D"line-height: 100%; margin-bottom: 0cm;">This +could be a first approach, it would then be possible to evaluate a +greater weight to the timestamp in order to introduce at least a part +of stagnant transactions in new blocks. It is not a question of +forcing the mempool to implement the changes since these are ethical +and cooperation issues. Nature is cooperative, there is no free +market.</p> + +<div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Il giorno= + sabato 28 dicembre 2024 alle 19:50:43 UTC+1 Ethan Heilman ha scritto:<br/>= +</div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; borde= +r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">You say: +<br> +<br>> Bitcoin network nodes will validate blocks only if they contain th= +e required percentage of old transactions. If a block fails to meet this cr= +iterion, it will be deemed invalid and rejected by the network. +<br> +<br>This requires that network nodes reach consensus on what the oldest +<br>transactions are. This is the technical problem you need to solve to +<br>make your proposal practical, but I don't see that as a bad thing a= +s +<br>it is a very interesting problem. If you can solve this problem, you +<br>can probably also solve the problem of how to enforce that Bitcoin +<br>miners only include the transactions with the highest fee rate. +<br>Enforcing the highest fee rate at the consensus level may be an +<br>effective tool against MEVil. +<br> +<br>This does seem like a hard problem to solve, because reaching +<br>consensus on transactions in mempool is very similar to what bitcoin +<br>blocks are already trying to achieve. Perhaps there is a more creative +<br>solution. It is worth looking at but it doesn't seem ready for a BI= +P. +<br> +<br>On Sat, Dec 28, 2024 at 11:26=E2=80=AFAM Michael Cassano <<a href da= +ta-email-masked rel=3D"nofollow">mcas...@gmail.com</a>> wrote: +<br>> +<br>> I reject the premise of this proposed BIP. Mandating miners to in= +clude a specific percentage of transactions based on age fundamentally unde= +rmines the core principles of Bitcoin: decentralization, voluntary particip= +ation, and free market dynamics. +<br>> +<br>> Bitcoin thrives because of its permissionless, free-market system.= + Miners are incentivized to prioritize transactions based on fees and netwo= +rk conditions, not arbitrary mandates. Imposing a rule like this introduces= + central planning into what is a decentralized system. +<br>> +<br>> The proposal claims to fight centralization, but will likely backf= +ire. Mandates like this add operational complexity and reduce efficiency fo= +r miners. Smaller miners, who are already operating on thin margins, will b= +e disproportionately impacted, driving them out of the market and further c= +entralizing mining power. If censorship-resistant mining is valuable, let t= +he free market reward those who provide it. If there=E2=80=99s demand for = +miners to include old or low-fee transactions, let someone build tools and = +pools that prioritize this voluntarily. Solutions shall arise from innovat= +ion, not coercion. +<br>> +<br>> Best regards, +<br>> Mike +<br>> +<br>> On Sat, Dec 28, 2024 at 8:58=E2=80=AFAM developer <<a href data= +-email-masked rel=3D"nofollow">estensi...@gmail.com</a>> wrote: +<br>>> +<br>>> Status: Draft +<br>>> Type: Standards Track +<br>>> Created: December 27, 2024 +<br>>> Abstract +<br>>> +<br>>> This proposal mandates miners to include at least 0.1% of tran= +sactions in their blocks from the oldest transactions by date, even if they= + have low fees. This mechanism helps prevent mining centralization and cens= +orship, encouraging miners not to exclude certain transactions. +<br>>> Motivation +<br>>> +<br>>> The increasing centralization of Bitcoin mining and potential = +regulations that may require miners to censor or exclude certain transactio= +ns 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. +<br>>> Specification +<br>>> +<br>>> Mandatory Inclusion of Old even if with Low-Fee Transactio= +ns +<br>>> 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. +<br>>> These transactions must be added to blocks regardless = +of their fees, prioritizing their age. +<br>>> +<br>>> Block Validation +<br>>> Bitcoin network nodes will validate blocks only if the= +y contain the required percentage of old transactions. +<br>>> If a block fails to meet this criterion, it will be de= +emed invalid and rejected by the network. +<br>>> +<br>>> Incentives +<br>>> Miners are incentivized to include these transactions = +to ensure their blocks are valid and to avoid losing block rewards. +<br>>> +<br>>> Advantages +<br>>> +<br>>> Censorship Resistance: Miners cannot censor transactions w= +ithout forfeiting their rewards. +<br>>> Greater Inclusivity: Old and low-fee transactions are assu= +red of being confirmed. +<br>>> Decentralization Prevention: Reducing the potential for ce= +ntralized censorship keeps the Bitcoin network decentralized. +<br>>> +<br>>> Considerations +<br>>> +<br>>> Impact on the Mempool: The mempool may become more dynamic= + and up-to-date with fewer old, stagnant transactions. +<br>>> Resource Management: Miners will need to adjust their syst= +ems to automatically identify and include relevant transactions. +<br>>> +<br>>> Conclusion +<br>>> +<br>>> Implementing this BIP will help maintain the integrity and dec= +entralization of the Bitcoin network, preventing censorship and ensuring al= +l transactions have a fair chance of confirmation. +<br>>> +<br>>> -- +<br>>> You received this message because you are subscribed to the Go= +ogle Groups "Bitcoin Development Mailing List" group. +<br>>> To unsubscribe from this group and stop receiving emails from = +it, send an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+= +...@googlegroups.com</a>. +<br>>> To view this discussion visit <a href=3D"https://groups.google= +.com/d/msgid/bitcoindev/fa4a8cd3-778c-4793-8dd4-5662475b6601n%40googlegroup= +s.com" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://w= +ww.google.com/url?hl=3Dit&q=3Dhttps://groups.google.com/d/msgid/bitcoin= +dev/fa4a8cd3-778c-4793-8dd4-5662475b6601n%2540googlegroups.com&source= +=3Dgmail&ust=3D1735575652966000&usg=3DAOvVaw0VkW_MpUNgOjCUD_WJMAT3"= +>https://groups.google.com/d/msgid/bitcoindev/fa4a8cd3-778c-4793-8dd4-56624= +75b6601n%40googlegroups.com</a>. +<br>> +<br>> -- +<br>> You received this message because you are subscribed to the Google= + Groups "Bitcoin Development Mailing List" group. +<br>> To unsubscribe from this group and stop receiving emails from it, = +send an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@= +googlegroups.com</a>. +<br>> To view this discussion visit <a href=3D"https://groups.google.com= +/d/msgid/bitcoindev/CAAg3Je3k4RrQzUQ-x-D81NeMPsFuZTVYFKem9uN9MYP-CnmdRg%40m= +ail.gmail.com" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"h= +ttps://www.google.com/url?hl=3Dit&q=3Dhttps://groups.google.com/d/msgid= +/bitcoindev/CAAg3Je3k4RrQzUQ-x-D81NeMPsFuZTVYFKem9uN9MYP-CnmdRg%2540mail.gm= +ail.com&source=3Dgmail&ust=3D1735575652966000&usg=3DAOvVaw1U1hM= +1BqtI2ad00__Q0Ji9">https://groups.google.com/d/msgid/bitcoindev/CAAg3Je3k4R= +rQzUQ-x-D81NeMPsFuZTVYFKem9uN9MYP-CnmdRg%40mail.gmail.com</a>. +<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 visit <a href=3D"https://groups.google.com/d/msgid/= +bitcoindev/fa02c975-8cac-40ec-8497-71f288dda177n%40googlegroups.com?utm_med= +ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind= +ev/fa02c975-8cac-40ec-8497-71f288dda177n%40googlegroups.com</a>.<br /> + +------=_Part_619763_734060683.1735490101606-- + +------=_Part_619762_26719530.1735490101606-- + |