Re: [bitcoin-dev] Concern about "Inscriptions"

From: Luke Dashjr <luke@dashjr•org>
To: GamedevAlice <gamedevalice256@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
Date: Wed, 2 Aug 2023 11:46:21 -0400	[thread overview]
Message-ID: <f0c26b59-f75a-8831-fa9e-51ef4a129d67@dashjr.org> (raw)
In-Reply-To: <CAJCwDN-CFyyJhyp_5YTMtSNTN41zp5uJ1qa8vdmVqC2YCW8A6Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 27016 bytes --]

Storage is not and never has been the trouble with block sizes. Please, 
before participating in discussions of this topic, at least get a basic 
understanding of it. Here's a talk I did a few years ago to get you 
started: https://www.youtube.com/watch?v=CqNEQS80-h4&t=7s

Luke

On 8/2/23 07:07, GamedevAlice via bitcoin-dev wrote:
> > If the rate of growth of the blockchain is too high, Ordinals aren't the
> > cause, it's rather that the theoretical limit of the amount of 
> storage that
> > can be added per block isn't sufficiently limited. (Whether they are 
> used
> > to produce Ordinals or something else)
>
>
> True, the real question is whether the storage is in fact sufficiently 
> limited. And I believe the answer to be 'yes'.
>
> Why? Consider a worst case scenario using the maximum block size of 
> 4MB and a block time of 10min, that's a growth of 210.24GB per year. 
> Some of that can be pruned, but let's just assume that you don't want 
> to. And currently the entire blockchain is roughly 500GB.
>
> Now that looks like a lot of growth potential based on where we are at 
> now. However, with the current cost of hardware, you can get a 5 TB 
> hard drive for less than $150. That will last you 21 years before you 
> run out of space. That's less than $0.02 per day.
>
> That is a worst case scenario.
>
> Consider that since cost of hardware drops over time, it will become 
> less of a burden over time.
>
> Also, keep in mind there are efforts to optimize how much of that 
> actually needs to be stored by nodes. For example, the aforementioned 
> topic announcing Floresta which seems to be a node implementation that 
> uses utreexo to allow nodes to run without needing to maintain the 
> full UTXO set. Other initiatives exist as well.
>
> There is definitely a lot of optimization potential for drastically 
> reducing how much space is actually needed by individual nodes.
>
>
>
> On Wed, Aug 2, 2023, 5:40 AM , 
> <bitcoin-dev-request@lists•linuxfoundation.org> wrote:
>
>     Send bitcoin-dev mailing list submissions to
>     bitcoin-dev@lists•linuxfoundation.org
>
>     To subscribe or unsubscribe via the World Wide Web, visit
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     or, via email, send a message with subject or body 'help' to
>     bitcoin-dev-request@lists•linuxfoundation.org
>
>     You can reach the person managing the list at
>     bitcoin-dev-owner@lists•linuxfoundation.org
>
>     When replying, please edit your Subject line so it is more specific
>     than "Re: Contents of bitcoin-dev digest..."
>
>
>     Today's Topics:
>
>        1. Re: Pull-req to enable Full-RBF by default (Peter Todd)
>        2. Re: Concern about "Inscriptions". (ashneverdawn)
>           (Keagan McClelland)
>
>
>     ----------------------------------------------------------------------
>
>     Message: 1
>     Date: Wed, 2 Aug 2023 01:28:06 +0000
>     From: Peter Todd <pete@petertodd•org>
>     To: Daniel Lipshitz <daniel@gap600•com>
>     Cc: Bitcoin Protocol Discussion
>             <bitcoin-dev@lists•linuxfoundation.org>
>     Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by default
>     Message-ID: <ZMmxJoL1ZH4//8Fg@petertodd•org>
>     Content-Type: text/plain; charset="us-ascii"
>
>     On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote:
>     > Your research is not thorough and reaches an incorrect conclusion.
>     >
>     > As stated many times - we service payment processors and some
>     merchants
>     > directly  - Coinspaid services multiple merchants and process a
>     > significant amount of BTC they are a well known and active in
>     the space -
>     > as I provided back in December 2022 a email from Max the CEO of
>     Coinspaid
>     > confirming their use of 0-conf as well as providing there
>     cluster addresses
>     > to validate there deposit flows see here again -
>     >
>     https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
>     > - if this is not sufficient then please email
>     support@coinspaid•com and ask
>     > to be connected to Max or someone from the team who can confirm
>     Conspaid is
>     > clients of GAP600. Max also at the time was open to do a call, I
>     can check
>     > again now and see if this is still the case and connect you.
>     >
>     > That on its own is enough of a sample to validate our statistics.
>
>     Why don't you just give me an example of some merchants using
>     Coinspaid, and
>     another example using Coinpayments, who rely on unconfirmed
>     transactions? If
>     those merchants actually exist it should be very easy to give me
>     some names of
>     them.
>
>     Without actual concrete examples for everyone to see for
>     themselves, why should
>     we believe you?
>
>     > I have also spoken to Changelly earlier today and they offered
>     to email pro
>     > @ changelly.com <http://changelly.com> and they will be able to
>     confirm GAP600 as a service
>
>     Emailed; waiting on a reply.
>
>     > provider. Also please send me the 1 trx hash you tested and I
>     can see if it
>     > was queried to our system and if so offer some info as to why it
>     wasnt
>     > approved. Also if you can elaborate how you integrated with
>     Changelly - I
>     > can check with them if that area is not integrated with GAP600.
>
>     Why don't you just tell me exactly what service Changelly offers
>     that relies on
>     unconfirmed transactions, and what characteristics would meet
>     GAP600's risk
>     criteria? I and others on this mailing list could easily do test
>     transactions
>     if you told us what we can actually test. If your service actually
>     works, then
>     you can safely provide that information.
>
>     I'm not going to give you any exact tx hashes of transactions I've
>     already
>     done, as I don't want to cause any problems for the owners of the
>     accounts I
>     borrowed for testing. Given your lack of honesty so far I have
>     every reason to
>     believe they might be retalliated against in some way.
>
>     > As the architect of such a major change to the status of 0-conf
>     > transactions I would think you would welcome the opportunity to
>     speak to
>     > business and users who actual activities will be impacted by
>     full RBF
>     > becoming dominant.
>
>     Funny how you say this, without actually giving any concrete
>     examples of
>     businesses that will be affected. Who exactly are these
>     businesses? Payment
>     processors obviously don't count.
>
>     > Are you able to provide the same i.e emails and contacts of
>     people at
>     > the mining pools who can confirm they have adopted FULL RBF ?
>
>     I've already had multiple mining pools complain to me that they
>     and their
>     employees have been harassed over full-rbf, so obviously I'm not
>     going to
>     provide you with any private contact information I have. There's
>     no need to
>     expose them to further harassment.
>
>     If you actually offered an unconfirmed transaction guarantee
>     service, with real
>     customers getting an actual benefit, you'd be doing test transactions
>     frequently and would already have a very good idea of what pools
>     do full-rbf.
>     Why don't you already have this data?
>
>     -- 
>     https://petertodd.org 'peter'[:-1]@petertodd.org
>     <http://petertodd.org>
>     -------------- next part --------------
>     A non-text attachment was scrubbed...
>     Name: signature.asc
>     Type: application/pgp-signature
>     Size: 833 bytes
>     Desc: not available
>     URL:
>     <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/7f826021/attachment-0001.sig>
>
>     ------------------------------
>
>     Message: 2
>     Date: Tue, 1 Aug 2023 22:58:53 -0700
>     From: Keagan McClelland <keagan.mcclelland@gmail•com>
>     To: Hugo L <ashneverdawn@gmail•com>, Bitcoin Protocol Discussion
>             <bitcoin-dev@lists•linuxfoundation.org>
>     Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
>             (ashneverdawn)
>     Message-ID:
>            
>     <CALeFGL2Z3q90Esnu0qV0mqpHZaCnOV-5aks2TKGOjY4L+14d3w@mail•gmail.com
>     <mailto:CALeFGL2Z3q90Esnu0qV0mqpHZaCnOV-5aks2TKGOjY4L%2B14d3w@mail•gmail.com>>
>     Content-Type: text/plain; charset="utf-8"
>
>     There is an open question as to whether or not we should figure
>     out a way
>     to price space in the UTXO set. I think it is fair to say that
>     given the
>     fact that the UTXO set space remains unpriced that we actually
>     have no way
>     to determine whether some of these transactions are spam or not.
>     The UTXO
>     set must be maintained by all nodes including pruned nodes,
>     whereas main
>     block and witness data do not have the same type of indefinite
>     footprint,
>     so in some sense it is an even more significant resource than
>     chain space.
>     We may very well discover that if we price UTXOs in a way that
>     reflect the
>     resource costs that usage of inscriptions would vanish. The
>     trouble though
>     is that such a mechanism would imply having to pay "rent" for an
>     "account"
>     with Bitcoin, a proposition that would likely be offensive to a
>     significant
>     portion of the Bitcoin user base.
>
>     Cheers,
>     Keags
>
>     On Mon, Jul 31, 2023 at 4:55?AM Hugo L via bitcoin-dev <
>     bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>     > I don't think it's anyone's place to judge which types of
>     transactions
>     > should be allowed or not on the network, in fact, when it comes
>     to privacy
>     > and censorship resistance, it would be better if we were not
>     even able to
>     > distinguish different types of transactions from one another in
>     the first
>     > place.
>     >
>     > We have limited resources on the blockchain and so they should
>     go to the
>     > highest bidder. This is already how the network functions and how it
>     > ensures it's security.
>     >
>     > Rather than thinking about this as "spam", I think it's useful to
>     > objectively think about it in terms of value to the marketplace
>     (fees
>     > they're willing to pay) against cost to the network (storage
>     consumed). It
>     > comes down to supply and demand.
>     >
>     > If the rate of growth of the blockchain is too high, Ordinals
>     aren't the
>     > cause, it's rather that the theoretical limit of the amount of
>     storage that
>     > can be added per block isn't sufficiently limited. (Whether they
>     are used
>     > to produce Ordinals or something else)
>     >
>     >
>     >
>     > On Sun, Jul 30, 2023, 5:51 PM , <
>     > bitcoin-dev-request@lists•linuxfoundation.org> wrote:
>     >
>     >> Send bitcoin-dev mailing list submissions to
>     >> bitcoin-dev@lists•linuxfoundation.org
>     >>
>     >> To subscribe or unsubscribe via the World Wide Web, visit
>     >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     >> or, via email, send a message with subject or body 'help' to
>     >> bitcoin-dev-request@lists•linuxfoundation.org
>     >>
>     >> You can reach the person managing the list at
>     >> bitcoin-dev-owner@lists•linuxfoundation.org
>     >>
>     >> When replying, please edit your Subject line so it is more specific
>     >> than "Re: Contents of bitcoin-dev digest..."
>     >>
>     >>
>     >> Today's Topics:
>     >>
>     >>    1. Re: Concern about "Inscriptions". (rot13maxi)
>     >>
>     >>
>     >>
>     ----------------------------------------------------------------------
>     >>
>     >> Message: 1
>     >> Date: Sun, 30 Jul 2023 18:34:12 +0000
>     >> From: rot13maxi <rot13maxi@protonmail•com>
>     >> To: L?o Haf <leohaf@orangepill•ovh>, "vjudeu@gazeta•pl"
>     >>         <vjudeu@gazeta•pl>
>     >> Cc: Bitcoin Protocol Discussion
>     >>         <bitcoin-dev@lists•linuxfoundation.org>
>     >> Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
>     >> Message-ID:
>     >>
>     >>
>     <RIqguuebFmAhEDqCY_0T8KRqHBXEfcvPw6-MbDIyWsAWpLenFFeOVx88-068QFZr7xowg-6Zg988HsRCKdswtZC6QUKPXnrTyTAc_l5jphg=@
>     >> protonmail.com <http://protonmail.com>>
>     >>
>     >> Content-Type: text/plain; charset="utf-8"
>     >>
>     >> Hello,
>     >>
>     >> > This cat and mouse game can be won by bitcoin defenders. Why
>     ? Because
>     >> it is easier to detect these transactions and make them a
>     standardization
>     >> rule than to create new types of spam transactions.
>     >>
>     >> One of the things discussed during the mempoolfullrbf
>     discussion is that
>     >> a small (~10%) of nodes willing to relay a class of transaction
>     is enough
>     >> for that class of transaction to consistently reach miners.
>     That means you
>     >> would need to get nearly the entire network to run updated
>     relay policy to
>     >> prevent inscriptions from trivially reaching miners and being
>     included in
>     >> blocks. Inscription users have shown that they are willing and
>     able to send
>     >> non-standard transactions to miners out of band (
>     >>
>     https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae),
>     >> so even if you managed to get enough of the network running the
>     new rule to
>     >> prevent propagation to miners, those users can just go out of
>     band. Or,
>     >> they can simply change the script that is used to embed an
>     inscription in
>     >> the transaction witness. For example, instead of 0 OP_IF?,
>     maybe they do 0
>     >> OP_DUP OP_DROP OP_IF. When the anti-inscription people detect
>     this, they
>     >> have to update the rule and wait for 90%
>     >>  + of the network to upgrade. When the pro-inscription people
>     see this,
>     >> they only have to convince other inscription enthusiasts and
>     businesses to
>     >> update.
>     >>
>     >> The anti-inscription patch has to be run by many more
>     participants (most
>     >> of whom don?t care), while the pro-inscription update has to be
>     run by a
>     >> small number of people who care a lot. It?s a losing battle for the
>     >> anti-inscription people.
>     >>
>     >> If you want to prevent inscriptions, the best answer we know of
>     today is
>     >> economic: the cost of the blockspace needs to be more expensive
>     than
>     >> inscribers are willing to pay, either because its too expensive
>     or because
>     >> there?s no market demand for inscriptions. The former relies on
>     Bitcoin
>     >> becoming more useful to more people, the latter is the natural
>     course of
>     >> collectibles.
>     >>
>     >> > Finally, I would like to quote satoshi himself who wrote
>     about spam
>     >> here is the link:
>     >> https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
>     >>
>     >> Appeals to Satoshi are not compelling arguments.
>     >>
>     >> Cheers,
>     >> Rijndael
>     >>
>     >> On Sun, Jul 30, 2023 at 2:04 PM, L?o Haf via bitcoin-dev <[
>     >> bitcoin-dev@lists•linuxfoundation.org](mailto:On Sun, Jul 30,
>     2023 at
>     >> 2:04 PM, L?o Haf via bitcoin-dev <<a href=)> wrote:
>     >>
>     >> > ?According to you, the rules of standardization are useless
>     but in this
>     >> case why were they introduced? The opreturn limit can be
>     circumvented by
>     >> miners, yet it is rare to see any, the same for maxancestorcount,
>     >> minrelayfee or even the dust limit.
>     >> >
>     >> > This cat and mouse game can be won by bitcoin defenders. Why
>     ? Because
>     >> it is easier to detect these transactions and make them a
>     standardization
>     >> rule than to create new types of spam transactions.
>     >> >
>     >> > As for the default policy, it can be a weakness but also a
>     strength
>     >> because if the patch is integrated into Bitcoin Core by being
>     activated by
>     >> default, the patch will become more and more effective as the
>     nodes update.
>     >> >
>     >> > Also, when it came to using a pre-segwit node, it is not a
>     solution
>     >> because this type of node cannot initiate new ones, which is
>     obviously a
>     >> big problem.
>     >> >
>     >> > Finally, I would like to quote satoshi himself who wrote
>     about spam
>     >> here is the link:
>     >> https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
>     >> >
>     >> >> Le 27 juil. 2023 ? 07:10, vjudeu@gazeta•pl a ?crit :
>     >> >
>     >> >>
>     >> >
>     >> >> ?
>     >> >
>     >> >>> not taking action against these inscription could be
>     interpreted by
>     >> spammers as tacit acceptance of their practice.
>     >> >
>     >> >>
>     >> >
>     >> >> Note that some people, even on this mailing list, do not
>     consider
>     >> Ordinals as spam:
>     >>
>     https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021464.html
>     >> >
>     >> >>
>     >> >
>     >> >> See? It was discussed when it started. Some people believe that
>     >> blocking Ordinals is censorship, and could lead to blocking regular
>     >> transactions in the future, just based on other criteria. That
>     means, even
>     >> if developers would create some official version with that
>     option, then
>     >> some people would not follow them, or even block
>     Ordinals-filtering nodes,
>     >> exactly as described in the linked thread:
>     >>
>     https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021487.html
>     >> >
>     >> >>
>     >> >
>     >> >>> as spammers might perceive that the Bitcoin network
>     tolerates this
>     >> kind of behavior
>     >> >
>     >> >>
>     >> >
>     >> >> But it is true, you have the whole pages, where you can find
>     images,
>     >> files, or other data, that was pushed on-chain long before
>     Ordinals. The
>     >> whole whitepaper was uploaded just on 1-of-3 multisig outputs, see
>     >> transaction
>     >>
>     54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713.
>     You have
>     >> the whole altcoins that are connected to Bitcoin by using part
>     of the
>     >> Bitcoin's UTXO set as their database.
>     >> >
>     >> >>
>     >> >
>     >> >> That means, as long as you won't solve IBD problem and UTXO set
>     >> growing problem, you will go nowhere, because if you block Ordinals
>     >> specifically, people won't learn "this is bad, don't do that",
>     they could
>     >> read it as "use the old way instead", as long as you won't
>     block all
>     >> possible ways. And doing that, requires for example creating
>     new nodes,
>     >> without synchronizing non-consensus data, like it could be done
>     in "assume
>     >> UTXO" model.
>     >> >
>     >> >>
>     >> >
>     >> >> Also note that as long as people use Taproot to upload a lot
>     of data,
>     >> you can still turn off the witness, and become a pre-Segwit
>     node. But if
>     >> you block those ways, then people will push data into legacy
>     parts, and
>     >> then you will need more code to strip it correctly. The block
>     774628 maybe
>     >> contains almost 4 MB of data from the perspective of Segwit
>     node, but the
>     >> legacy part is actually very small, so by turning witness off,
>     you can
>     >> strip it to maybe just a few kilobytes.
>     >> >
>     >> >>
>     >> >
>     >> >>> I want to emphasize that my proposal does not involve
>     implementing a
>     >> soft fork in any way. On the contrary, what I am asking is
>     simply to
>     >> consider adding a standardization option. This option would
>     allow the
>     >> community to freely decide whether it should be activated or not.
>     >> >
>     >> >>
>     >> >
>     >> >> 1. Without a soft-fork, those data will be pushed by mining
>     pools
>     >> anyway, as it happened in the block 774628.
>     >> >
>     >> >> 2. Adding some settings won't help, as most people use the
>     default
>     >> configuration. For example, people can configure their nodes to
>     allow free
>     >> transactions, without recompiling anything. The same with
>     disabling dust
>     >> amounts. But good luck finding a node in the wild that does
>     anything
>     >> unusual.
>     >> >
>     >> >> 3. This patch produced by Luke Dashjr does not address all
>     cases. You
>     >> could use "OP_TRUE OP_NOTIF" instead of "OP_FALSE OP_IF" used
>     by Ordinals,
>     >> and easily bypass those restrictions. This will be just a cat
>     and mouse
>     >> game, where spammers will even use P2PK, if they will be forced
>     to. The
>     >> Pandora's box is already opened, that fix could be good for
>     February or
>     >> March, but not now.
>     >> >
>     >> >>
>     >> >
>     >> >>
>     >> >
>     >> >>
>     >> >
>     >> >>> On 2023-07-26 11:47:09 user leohaf@orangepill•ovh wrote:
>     >> >
>     >> >>> I understand your point of view. However, inscription
>     represent by
>     >> far the largest spam attack due to their ability to embed
>     themselves in the
>     >> witness with a fee reduction.
>     >> >
>     >> >>
>     >> >
>     >> >> Unlike other methods, such as using the op_return field
>     which could
>     >> also be used to spam the chain, the associated fees and the
>     standardization
>     >> rule limiting op_return to 80 bytes have so far prevented
>     similar abuses.
>     >> >
>     >> >>
>     >> >
>     >> >> Although attempting to stop inscription could lead to more
>     serious
>     >> issues, not taking action against these inscription could be
>     interpreted by
>     >> spammers as tacit acceptance of their practice. This could
>     encourage more
>     >> similar spam attacks in the future, as spammers might perceive
>     that the
>     >> Bitcoin network tolerates this kind of behavior.
>     >> >
>     >> >>
>     >> >
>     >> >> I want to emphasize that my proposal does not involve
>     implementing a
>     >> soft fork in any way. On the contrary, what I am asking is
>     simply to
>     >> consider adding a standardization option. This option would
>     allow the
>     >> community to freely decide whether it should be activated or not.
>     >> >
>     >> >>
>     >> >
>     >> >>
>     >> >
>     >> >>>> Le 26 juil. 2023 ? 07:30, vjudeu@gazeta•pl a ?crit :
>     >> >
>     >> >>>> and I would like to understand why this problem has not been
>     >> addressed more seriously
>     >> >
>     >> >>> Because if nobody has any good solution, then status quo is
>     >> preserved. If tomorrow ECDSA would be broken, the default state
>     of the
>     >> network would be "just do nothing", and every solution would be
>     >> backward-compatible with that approach. Burn old coins, and
>     people will
>     >> call it "Tether", redistribute them, and people will call it
>     "BSV". Leave
>     >> everything untouched, and the network will split into N parts,
>     and then you
>     >> pick the strongest chain to decide, what should be done.
>     >> >
>     >> >>>> However, when it comes to inscriptions, there are no available
>     >> options except for a patch produced by Luke Dashjr.
>     >> >
>     >> >>> Because the real solution should address some different
>     problem, that
>     >> was always there, and nobody knows, how to deal with it: the
>     problem of
>     >> forever-growing initial blockchain download time, and
>     forever-growing UTXO
>     >> set. Some changes with "assume UTXO" are trying to address just
>     that, but
>     >> this code is not yet completed.
>     >> >
>     >> >>>> So, I wonder why there are no options to reject
>     inscriptions in the
>     >> mempool of a node.
>     >> >
>     >> >>> Because it will lead you to never ending chase. You will
>     block one
>     >> inscriptions, and different ones will be created. Now, they are
>     present
>     >> even on chains, where there is no Taproot, or even Segwit. That
>     means, if
>     >> you try to kill them, then they will be replaced by N regular
>     >> indistinguishable transactions, and then you will go back to
>     those more
>     >> serious problems under the hood: IBD time, and UTXO size.
>     >> >
>     >> >>>> Inscriptions are primarily used to sell NFTs or Tokens,
>     concepts
>     >> that the Bitcoin community has consistently rejected.
>     >> >
>     >> >>> The community also rejected things like sidechains, and
>     they are
>     >> still present, just in a more centralized form. There are some
>     unstoppable
>     >> concepts, for example soft-forks. You cannot stop a soft-fork. What
>     >> inscription creators did, is just non-enforced soft-fork. They
>     believe
>     >> their rules are followed to the letter, but this is not the
>     case, as you
>     >> can create a valid Bitcoin transaction, that will be some
>     invalid Ordinals
>     >> transaction (because their additional rules are not enforced by
>     miners and
>     >> nodes).
>     >> -------------- next part --------------
>     >> An HTML attachment was scrubbed...
>     >> URL: <
>     >>
>     http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230730/dfc353d3/attachment.html
>     >> >
>     >>
>     >> ------------------------------
>     >>
>     >> Subject: Digest Footer
>     >>
>     >> _______________________________________________
>     >> bitcoin-dev mailing list
>     >> bitcoin-dev@lists•linuxfoundation.org
>     >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     >>
>     >>
>     >> ------------------------------
>     >>
>     >> End of bitcoin-dev Digest, Vol 98, Issue 20
>     >> *******************************************
>     >>
>     > _______________________________________________
>     > bitcoin-dev mailing list
>     > bitcoin-dev@lists•linuxfoundation.org
>     > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     >
>     -------------- next part --------------
>     An HTML attachment was scrubbed...
>     URL:
>     <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230801/3e3a2496/attachment.html>
>
>     ------------------------------
>
>     Subject: Digest Footer
>
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists•linuxfoundation.org
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>     ------------------------------
>
>     End of bitcoin-dev Digest, Vol 99, Issue 3
>     ******************************************
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 49146 bytes --]