path: root/d4/5faf348c4d6ff9b7a87019770ad6967382bd2a

Delivery-date: Thu, 09 Jan 2025 04:36:19 -0800
Received: from mail-qt1-f187.google.com ([209.85.160.187])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDFIP6H73EBBBN4F765QMGQESYK67TI@googlegroups.com>)
	id 1tVrlp-0006xA-Fd
	for bitcoindev@gnusha.org; Thu, 09 Jan 2025 04:36:19 -0800
Received: by mail-qt1-f187.google.com with SMTP id d75a77b69052e-467944446a0sf12331461cf.1
        for <bitcoindev@gnusha.org>; Thu, 09 Jan 2025 04:36:16 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1736426171; cv=pass;
        d=google.com; s=arc-20240605;
        b=EdHTgur93HiBO883vp7mQWrutmGXTEz4ZtiWiXeHkBekekmgD4fdCmQeYDlre7wuEq
         y4KJnmO+yA4hTQ4XNwLZexS2LXcAL1J4zBu7q1FJfkm1gqpWk3u1dgaVm6qZRYU70jdu
         NQNnpqBg9BX31meC4YK7l8OvV5IASJc3tnEsxbkXSJpuY6+ncYaQlvMgC0mims1lyZvh
         cE4o7VPiYew+f3xvlkEuwAW5g96tl9K62o40JmYKiYVCm/RUYdhhSF9yMdsaGdnhVNs2
         DwUVLzMXjRt4XVQaw4lqa4kknxZH2QwwVlAdNPb78fBsQ5qEPAKlp1FZAZtc5zVr3YBG
         +l5Q==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=1Gje8Ye3empcg5KZgritZ50dAqi1Wi73urQ2bgTswWI=;
        fh=6OmNPUT7NKZWHneDQEZmvEBMAJXy3fd6XPx8ffjNyXs=;
        b=P4rlmlF7V+1rEA2XcumODOZx8taf+ZdbFQFD6SN7ISaRCKX4kjgAnuJ5N84TrMUa/x
         kA/qrA/K+WCed9smfFtlrsZqypgLoVIGtxxcAkOpGczwGaMBO2lyk810e7CrUzsVI5yM
         6trFaX/b5QSCKttBlmXS4BMaSgkEOh7wCLODFlqv3yZT7aE51JB4rBwDGr0emtVDsgnP
         F3a5Zkr/HPJk3oDmzGLJLLPuczTmLMuEGS85J/piUvKifutQvE4Akd9buG5zQLId+6iQ
         QIbaOD61psohVtz3bMyNzWfpAqoJnE8PTsUUTIm64cR0U6EZl7HOA+PBOL6FVTkRTmV0
         i+zw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=hFVnryQx;
       spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12e as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1736426171; x=1737030971; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=1Gje8Ye3empcg5KZgritZ50dAqi1Wi73urQ2bgTswWI=;
        b=vTFVALavVDkQEMi0dzL5/JIb+5X7aJAy75g2Jy4DyFBGZyWUeYudJ266D2esqCQ7Kw
         EExr6G6aiND8tQRT2FGSaL48ZLiZfUtEKVHgMtd5sKPD2256DGNPFHlKhXJTMG/690R1
         fBA37HOI2MQ5RcupfW3i8SPyBF6zGHOdZBEuLsUJ6crUr6/5sO4+KHoAHOP8Ye7sqlUS
         I9ebpnw8P0kB9Uj1812XUXbihz72ckdpOR0D21ADf2BYrTm00w5rKz2hr2cWaDHIzEpD
         vKbVXzs04H4B0IGh6EGL/+W/1P4DlH62CDO2Igt9oLVsqjzd/Lh72ZIvrY+wfeNceK9b
         m/kw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1736426171; x=1737030971; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=1Gje8Ye3empcg5KZgritZ50dAqi1Wi73urQ2bgTswWI=;
        b=lUs3DIcx2vMYIaQg6Q7vp3bU2IoVNZbAZTuNGGzOyNx+cXH82hv9qj5anJEhhe0e6J
         GsHTSXrhSB49kNGhKdeRLdmImauGgLcQMnNhCFbfZT4IHKbm1waLqec1eArPEWe6Fu4A
         lJQHG77KdW2bHfpVuOOzLar73FMaA8n3L2MKlQEUd+ht5OiP7qrfVweRn/XnfnwgVbop
         gmAc3e5qHyDZCAm8eP+RiaUQd/i9O8lZhmS1QXsxCGN4RpHIPGwZFCh/BAFuO3l7YsOL
         iir1pkRXkG1WlVgG1I+q09PpZzgTsW8+hWBtFf/0omOeoqBOvfkRx7PIThHJK0cg4aMp
         bw/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1736426171; x=1737030971;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=1Gje8Ye3empcg5KZgritZ50dAqi1Wi73urQ2bgTswWI=;
        b=jz8dTiJhCmUU/anPb6dVehLNhPjW7dlaxKBVKTqjbHD5pPQraq++5mjt/+ZQQBwNxF
         tc+BF0kv6S6JG2R0m8wOoqESwBbCK2wR3XYhQMcQty/IRg+x1KrTphRaOieLfXKrTwlV
         FpVn3wbX543ZrKZopsNL+9phEjffP8ynMJDGquvLUp7ytRbF7tIiHRgVlreR+rJjxzbQ
         gnVlGhulDc5cY6CC+6I7zOYcIiVgXew6JrDoxADTZFjpRmF9ww1oXmtMKJH/CwPrOO8j
         73TnWbQ2Q0Y3KGAmpMCKbqsVZo9K3yhIGY+967+B2vdTrQOEH9YjgsoqztYQAcjrCM7i
         qWHw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXH6yz7cYOrtxzL6Wp1l8CYR6QLY2LoqXAkWRGzA3TGjDyEFTndxCDTKKsuyxqzrKTLroepmSUumK1O@gnusha.org
X-Gm-Message-State: AOJu0YwYFpf5IF/rXo9jS6QmvimRmdNBkAU2zU6CcfVYuvatCvJAz5Y/
	9vzPheTRimICzX0Gd3Z34r50iVzvO3+IrsKRw453hTBjE4llTXkf
X-Google-Smtp-Source: AGHT+IFcdT9ZA0n3aedudwYHoyJMFPRWhcqjOILV2zwyzp1ZfQczaOvc47/nw5yStgoDUuE0Uvp8OA==
X-Received: by 2002:a05:622a:314:b0:467:8783:e48b with SMTP id d75a77b69052e-46c7107a577mr97182481cf.35.1736426170494;
        Thu, 09 Jan 2025 04:36:10 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:ac8:4083:0:b0:467:77d8:69e7 with SMTP id d75a77b69052e-46c7ab7a101ls13294131cf.2.-pod-prod-05-us;
 Thu, 09 Jan 2025 04:36:07 -0800 (PST)
X-Received: by 2002:a05:620a:4626:b0:7b6:eab3:cdd6 with SMTP id af79cd13be357-7bcd9762276mr946796985a.46.1736426167562;
        Thu, 09 Jan 2025 04:36:07 -0800 (PST)
Received: by 2002:a05:620a:37a9:b0:7b6:67a8:4fcd with SMTP id af79cd13be357-7bce2953860ms85a;
        Thu, 9 Jan 2025 04:25:06 -0800 (PST)
X-Received: by 2002:a05:600c:4f0d:b0:434:ffe3:bc7d with SMTP id 5b1f17b1804b1-436e26ba521mr66989265e9.16.1736425503706;
        Thu, 09 Jan 2025 04:25:03 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1736425503; cv=none;
        d=google.com; s=arc-20240605;
        b=A4EXVWK/MjRoyZaHvTIyJ9ZtPKLYthYY+s0BujjjHIR2w4G4yY150jI0FJdFDFUDwL
         lm+hbdUrhkcK+ghN3K7hsaqg8/C4C4lGTG8ctF8olMw04Airqw6rvAFxqnv+flCxTgqV
         Qcwv/PQg0nUAnyvSeCxOKJIWm5H5+zEm3g/AW/SeEemgQeqZRuSVndrw6LgTEcMahPIk
         cU63H7aMulF42klycLbLZcuHxg78OF+6b0cEk9KyruPdk4j19vMJwkK1StVqkfcyXH7B
         kRls8iMhvwEEtnFh1Pq91BmtRpxuihcBtrGtKcDpV1twto4uN84KWrnCIg/4F7EO4AOn
         C/rw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=LpKVQSBZCthSE3vdVSaBI+w2N1lj8oT45TRn1mscVdw=;
        fh=P1ygcw3H6dBtfWvAhRJ4jmcb8QOhKmb5A/ONyZKZxxQ=;
        b=I/IDrx5nWodb+W2S8gBMefM2Xyb0x4fZJ2atlU9T5PnMOhyQlEzyPkZVTAO4BuS5rA
         c2U7Zf2fsjrhWRE/M5UGmrzJHxSyvnzwdZ6Qokl0/4kHfT2Y+9ay9Uwnek04IH7J1ZIK
         pgxIQyTSjNhYJ9pRdqlIbEKkXIrj5fyX74oZjpHpdSF7VG+Ze+hjByKKITfuqFCDRwxE
         RVUNtRHeLZz1s1ees2OzLQcstJGQLxWxUCka0YDbSEEoFYpwiwaoxwlWW54e4Dq6v7tt
         UoiAF/4abNN5XRDYsuFdfIbmLgPOP1M8M60sqSttYnIqjHQ0nh+HHfYc5WC4f5lEIg+J
         7Oig==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=hFVnryQx;
       spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12e as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com. [2a00:1450:4864:20::12e])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-436dd0fd098si4759575e9.1.2025.01.09.04.25.03
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 09 Jan 2025 04:25:03 -0800 (PST)
Received-SPF: pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12e as permitted sender) client-ip=2a00:1450:4864:20::12e;
Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-53e384e3481so789227e87.2
        for <bitcoindev@googlegroups.com>; Thu, 09 Jan 2025 04:25:03 -0800 (PST)
X-Gm-Gg: ASbGncu0PtoaQudAVAyUCqxdedSS5+prCZbq72qv1i3+67nPM5k7Hltypwg/Qzv8feS
	PpNPKMQbXafLsXhRX6v3bUlymPX85SsZYahFJ4Rs=
X-Received: by 2002:a05:6512:12c9:b0:53e:383a:639a with SMTP id
 2adb3069b0e04-542847fec04mr1866822e87.37.1736425502490; Thu, 09 Jan 2025
 04:25:02 -0800 (PST)
MIME-Version: 1.0
References: <fa4a8cd3-778c-4793-8dd4-5662475b6601n@googlegroups.com>
 <CAAg3Je3k4RrQzUQ-x-D81NeMPsFuZTVYFKem9uN9MYP-CnmdRg@mail.gmail.com>
 <CAEM=y+V5RTz2g8JvbLuZ3zs2RAmNPrN3WvKVfU7X69pD2j-8nw@mail.gmail.com> <fa02c975-8cac-40ec-8497-71f288dda177n@googlegroups.com>
In-Reply-To: <fa02c975-8cac-40ec-8497-71f288dda177n@googlegroups.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
Date: Thu, 9 Jan 2025 07:24:50 -0500
X-Gm-Features: AbW1kvYaNcLtNJcJF16iKOo3PGnZ-02B3lsvAiInCU9WHBT538jwiiVs73YwXMc
Message-ID: <CADL_X_cUGs_4urm6A73i7becQQPAL=LVBjBW0ejt4=0Mud-Rag@mail.gmail.com>
Subject: Re: [bitcoindev] Mandatory Inclusion of Old Transactions in Blocks
To: developer <estensioni.app@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000004147b7062b451171"
X-Original-Sender: jameson.lopp@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=hFVnryQx;       spf=pass
 (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12e
 as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.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 (/)

--0000000000004147b7062b451171
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Any timestamp data that is added to a transaction is not trustworthy,
including nLockTime.

This proposal doesn't withstand adversaries who would seek to game the
system to their advantage. If I wanted to benefit from these rules then I'd
just construct my transactions with an nLockTime of many years ago. But
then other Bitcoin users would notice and start doing the same thing, which
would turn into a race to the bottom and eventually the new prioritization
rules would be effectively null.

On Sun, Dec 29, 2024 at 11:41=E2=80=AFAM developer <estensioni.app@gmail.co=
m> wrote:

> 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.
>
> 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
> the transaction, inserts the sending timestamp in the "nLockTime" field
> (usually set to 0).
>
> =E2=80=9CnLockTime=E2=80=9D is designed to indicate the earliest time a t=
ransaction 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.
>
> 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
> confirmation of the will to insert the block starting from the timestamp
> (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
> data structure called indexed_transaction_set, defined using Boost
> MultiIndex. The mempool uses an index based on the fee rate to classify t=
he
> transactions. The CompareTxMemPoolEntryByFee function compares transactio=
ns
> 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).
>
> 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 rat=
e
> 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
> (Replace-by-Fee, or RBF).
>
> 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.
>
> 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
> MultiIndex indexed_transaction_set structure in the mempool would require
> some fine-grained, but not overly invasive, changes. The complexity depen=
ds
> 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 possib=
le
> version:
>
> 1. Updating the data structure
>
> 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 nee=
d
> to implement a new comparator that takes both the fee rate and the
> nLockTime into account.
>
> 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.
>
> 2. Updating the TrimToSize function
>
> 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 t=
he
> 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
> 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 t=
o
> reflect the desired order.
>
> 3. Modify the CompareTxMemPoolEntryByFeeAndLockTime comparator
>
> 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 comparat=
or:
>
> 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
> 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
> 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 =
recent
> nLockTime (highest timestamp) are removed first.
>
> =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 t=
he
> mempool.
>
> 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.
> Il giorno sabato 28 dicembre 2024 alle 19:50:43 UTC+1 Ethan Heilman ha
> scritto:
>
>> You say:
>>
>> > 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.
>>
>> 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.=
com>
>> wrote:
>> >
>> > I reject the premise of this proposed BIP. Mandating miners to include
>> a specific percentage of transactions based on age fundamentally undermi=
nes
>> the core principles of Bitcoin: decentralization, voluntary participatio=
n,
>> and free market dynamics.
>> >
>> > Bitcoin thrives because of its permissionless, free-market system.
>> Miners are incentivized to prioritize transactions based on fees and
>> network conditions, not arbitrary mandates. Imposing a rule like this
>> introduces central planning into what is a decentralized system.
>> >
>> > The proposal claims to fight centralization, but will likely backfire.
>> Mandates like this add operational complexity and reduce efficiency for
>> miners. Smaller miners, who are already operating on thin margins, will =
be
>> disproportionately impacted, driving them out of the market and further
>> centralizing mining power. If censorship-resistant mining is valuable, l=
et
>> the free market reward those who provide it. If there=E2=80=99s demand f=
or miners
>> to include old or low-fee transactions, let someone build tools and pool=
s
>> that prioritize this voluntarily. Solutions shall arise from innovation,
>> not coercion.
>> >
>> > Best regards,
>> > Mike
>> >
>> > On Sat, Dec 28, 2024 at 8:58=E2=80=AFAM developer <estensi...@gmail.co=
m>
>> wrote:
>> >>
>> >> Status: Draft
>> >> Type: Standards Track
>> >> Created: December 27, 2024
>> >> Abstract
>> >>
>> >> This proposal mandates miners to include at least 0.1% of transaction=
s
>> 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 inclusi=
on
>> of a small percentage of old transactions, even with low fees, ensures t=
hat
>> 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, eve=
n
>> 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 an=
d
>> 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 bein=
g
>> 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 ensur=
ing
>> 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, sen=
d
>> an email to bitcoindev+...@googlegroups.com.
>> >> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/fa4a8cd3-778c-4793-8dd4-566=
2475b6601n%40googlegroups.com.
>>
>> >
>> > --
>> > 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+...@googlegroups.com.
>> > To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/CAAg3Je3k4RrQzUQ-x-D81NeMPs=
FuZTVYFKem9uN9MYP-CnmdRg%40mail.gmail.com.
>>
>>
> --
> 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/fa02c975-8cac-40ec-8497-71f2=
88dda177n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/fa02c975-8cac-40ec-8497-71f=
288dda177n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=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/=
CADL_X_cUGs_4urm6A73i7becQQPAL%3DLVBjBW0ejt4%3D0Mud-Rag%40mail.gmail.com.

--0000000000004147b7062b451171
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Any timestamp data that is added to a transaction is not t=
rustworthy, including nLockTime.<div><br></div><div>This proposal doesn&#39=
;t withstand adversaries who would seek to game the system to their advanta=
ge. If I wanted to benefit from these rules then I&#39;d just construct my =
transactions with an nLockTime of many years ago. But then other Bitcoin us=
ers would notice and start doing the same thing, which would turn into a ra=
ce to the bottom and eventually the new prioritization rules would be effec=
tively null.</div></div><br><div class=3D"gmail_quote gmail_quote_container=
"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Dec 29, 2024 at 11:41=E2=80=
=AFAM developer &lt;<a href=3D"mailto:estensioni.app@gmail.com">estensioni.=
app@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">


=09
	<span></span>
=09
=09

<p align=3D"left" style=3D"line-height:100%;margin-bottom:0cm;break-before:=
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">Assumption
=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 &quot;nLockTime&quot;
field (usually set to 0).</p>
<p align=3D"left" style=3D"line-height:100%;margin-bottom:0cm">=E2=80=9CnLo=
ckTime=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">Inserting
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">(Removing
Transactions)</p>
<p align=3D"left" style=3D"line-height:100%;margin-bottom:0cm">Transactions
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">Intervention
=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">Integrating
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() &gt; 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&lt;0&gt;().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">removeUnchec=
ked(mapTx.project&lt;0&gt;(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&lt;0&gt;() 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&amp; a, const CTxMemPoolEntry&amp;
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() &lt; 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 &gt; 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">Conclusion</=
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 Th=
e
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:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">You say:
<br>
<br>&gt; 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&#39;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&#39;t seem ready for a BI=
P.
<br>
<br>On Sat, Dec 28, 2024 at 11:26=E2=80=AFAM Michael Cassano &lt;<a rel=3D"=
nofollow">mcas...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; 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>&gt;
<br>&gt; 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>&gt;
<br>&gt; 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>&gt;
<br>&gt; Best regards,
<br>&gt; Mike
<br>&gt;
<br>&gt; On Sat, Dec 28, 2024 at 8:58=E2=80=AFAM developer &lt;<a rel=3D"no=
follow">estensi...@gmail.com</a>&gt; wrote:
<br>&gt;&gt;
<br>&gt;&gt; Status: Draft
<br>&gt;&gt; Type: Standards Track
<br>&gt;&gt; Created: December 27, 2024
<br>&gt;&gt; Abstract
<br>&gt;&gt;
<br>&gt;&gt; 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>&gt;&gt; Motivation
<br>&gt;&gt;
<br>&gt;&gt; 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>&gt;&gt; Specification
<br>&gt;&gt;
<br>&gt;&gt;     Mandatory Inclusion of Old even if with Low-Fee Transactio=
ns
<br>&gt;&gt;         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>&gt;&gt;         These transactions must be added to blocks regardless =
of their fees, prioritizing their age.
<br>&gt;&gt;
<br>&gt;&gt;     Block Validation
<br>&gt;&gt;         Bitcoin network nodes will validate blocks only if the=
y contain the required percentage of old transactions.
<br>&gt;&gt;         If a block fails to meet this criterion, it will be de=
emed invalid and rejected by the network.
<br>&gt;&gt;
<br>&gt;&gt;     Incentives
<br>&gt;&gt;         Miners are incentivized to include these transactions =
to ensure their blocks are valid and to avoid losing block rewards.
<br>&gt;&gt;
<br>&gt;&gt; Advantages
<br>&gt;&gt;
<br>&gt;&gt;     Censorship Resistance: Miners cannot censor transactions w=
ithout forfeiting their rewards.
<br>&gt;&gt;     Greater Inclusivity: Old and low-fee transactions are assu=
red of being confirmed.
<br>&gt;&gt;     Decentralization Prevention: Reducing the potential for ce=
ntralized censorship keeps the Bitcoin network decentralized.
<br>&gt;&gt;
<br>&gt;&gt; Considerations
<br>&gt;&gt;
<br>&gt;&gt;     Impact on the Mempool: The mempool may become more dynamic=
 and up-to-date with fewer old, stagnant transactions.
<br>&gt;&gt;     Resource Management: Miners will need to adjust their syst=
ems to automatically identify and include relevant transactions.
<br>&gt;&gt;
<br>&gt;&gt; Conclusion
<br>&gt;&gt;
<br>&gt;&gt; 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>&gt;&gt;
<br>&gt;&gt; --
<br>&gt;&gt; You received this message because you are subscribed to the Go=
ogle Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt;&gt; To unsubscribe from this group and stop receiving emails from =
it, send an email to <a rel=3D"nofollow">bitcoindev+...@googlegroups.com</a=
>.
<br>&gt;&gt; To view this discussion visit <a href=3D"https://groups.google=
.com/d/msgid/bitcoindev/fa4a8cd3-778c-4793-8dd4-5662475b6601n%40googlegroup=
s.com" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/d/msgid=
/bitcoindev/fa4a8cd3-778c-4793-8dd4-5662475b6601n%40googlegroups.com</a>.
<br>&gt;
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a rel=3D"nofollow">bitcoindev+...@googlegroups.com</a>.
<br>&gt; To view this discussion visit <a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/CAAg3Je3k4RrQzUQ-x-D81NeMPsFuZTVYFKem9uN9MYP-CnmdRg%40m=
ail.gmail.com" rel=3D"nofollow" target=3D"_blank">https://groups.google.com=
/d/msgid/bitcoindev/CAAg3Je3k4RrQzUQ-x-D81NeMPsFuZTVYFKem9uN9MYP-CnmdRg%40m=
ail.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&quot; 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" target=
=3D"_blank">bitcoindev+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&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/fa02c975-8cac-40ec-8497-71f288dda177n%40googlegrou=
ps.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&quot; 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/CADL_X_cUGs_4urm6A73i7becQQPAL%3DLVBjBW0ejt4%3D0Mud-Rag%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CADL_X_cUGs_4urm6A73i7becQQPAL%3DLVBjBW0ejt4%3D0Mud-Rag%=
40mail.gmail.com</a>.<br />

--0000000000004147b7062b451171--