Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts]
193 views
Skip to first unread message
Andrew Poelstra
Sep 26, 2025, 10:16:19 AM (3 days ago) Sep 26
to Bitcoin Development Mailing List
(You sent this message to me personally but it looks like it was
intended for the list. I am replying to the list, which I hope is
okay.)
On Thu, Sep 25, 2025 at 07:37:04PM -0600, Chris Guida wrote:
>
> >The purpose of the mempool is to approximate the contents of blocks, both
> to help individual node operators (who would otherwise get large quantities
> of "surprise transactions" with every block)
>
> This is a new "purpose" for the mempool which did not exist prior to 2016
> when compact block relay was introduced. The original purpose for the
> mempool is, of course, to relay unconfirmed transactions to all mining
> nodes to increase the likelihood that transactions will be confirmed.
>
Yes, it is a "new purpose" introduced almost a decade ago to allow Bitcoin
to scale without unnecessarily causing load on nodes, which are essential
for the decentralization of the system but uncompensated by the network.
> >Any sort of filtering beyond that done by miners is contrary to this
> purpose of the mempool. This is a technical fact.
>
> Again, you appear to be ignoring the existence of things like the dust
> filter, transaction size filters, standardness limits on legacy inputs,
> etc. And also again, you appear to be implying that the mempool is *not*
> useful for relaying transactions to miners so they can be confirmed in
> blocks (and not just so that said blocks can propagate quickly).
>
If the dust filter, transaction size filters, standardness limits, etc.,
were being ignored by miners then they should be removed, yes. Some of
these exist for historical reasons and others for performance reasons,
and in the latter case there might be a movement to enforce the old
rules in consensus. But if it came to "mempool policy vs miner policy"
then it is in the interest of both node operators and the network's
health to change the mempool policy.
> >It has nothing to do with "bitcoin's ethos", except its ethos as a
> consensus system, which directly contradicts your point.
>
> The mempool is not a consensus system, and noderunners are free to relay,
> or not relay, any transactions or blocks they like.
>
Yes, of course, but the goal of Bitcoin Core is not to let people do
"whatever they want" on the network. Core does not support "spy node"
operation, address indexing, or any number of things people have
requested but are unnecessary (or harmful) to the health of the network.
People can do whatever they want. This does not mean that Bitcoin Core
should actively support "whatever people want".
> Yes, in general things work more smoothly if all nodes have roughly the
> same view of the network, but allowing miners absolute control over the
> content of blocks in order to maximize their short-term fee revenue is a
> slippery slope toward a situation in which *only* data transactions are
> mined, rather than payments, and this would be fatal to a network that is
> supposed to be a payment system.
>
> Since there is no permanent way to disallow all data transactions in
> consensus, our only sustainable counterweight to this inevitable slide
> toward more and more short-term concerns by miners (at the expense of the
> network's long-term wellbeing) is mempool policy.
>
Unfortunately, this logic is akin to "We must do something. This is
something. Therefore, we must do this."
You are correct that, in a world where people are willing to pay more
for data publication than for transactions, Bitcoin will be overwhelmed
by data carriers unless it were possible to block data carriers. But
your proposed solution will not achieve this. To the contrary, it will
increase the cost of running a node for anybody who does it, and
increase the time it takes for blocks to propagate across the network,
both of which will have centralizing effects.
> When I say that disallowing filtering is not in keeping with bitcoin's
> ethos, I mean that bitcoin is a voluntary network where no one can coerce
> anyone else, and everyone is assumed to be following his or her own
> rational self-interest. Filtering dust is in the rational self-interest of
> a supermajority of nodes, because the alternative is massive utxoset bloat
> (and potentially node DoS attacks). Filtering data spam is no different; it
> has a very successful track record of helping to preserve bitcoin's
> usefulness as permissionless money, so it is beneficial to everyone.
>
Nodes filtering dust will, at best, prevent people from accidentally
broadcasting dust transactions. If somebody wants to do it, then they
will be able to, and any nodes that filter will be uselessly swimming
against the current.
If a meaningful number of blocks are produced that are full of dust
transactions, that filter should be removed (and perhaps some movement
to consensus-ban dust transactions will appear, which is a technically
much easier thing to accomplish).
> People are going to filter, because doing so is in their rational
> self-interest, so attempting to coerce people into relaying unconfirmed
> transactions that contain data (or designing systems on the assumption that
> everyone's mempools are always identical) is doomed to fail.
>
Nobody is "attempting to coerce people to relay transactions", any more than
you are "attempting to coerce" Core developers by posting polite messages on
the mailing list.
--
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
intended for the list. I am replying to the list, which I hope is
okay.)
On Thu, Sep 25, 2025 at 07:37:04PM -0600, Chris Guida wrote:
>
> >The purpose of the mempool is to approximate the contents of blocks, both
> to help individual node operators (who would otherwise get large quantities
> of "surprise transactions" with every block)
>
> This is a new "purpose" for the mempool which did not exist prior to 2016
> when compact block relay was introduced. The original purpose for the
> mempool is, of course, to relay unconfirmed transactions to all mining
> nodes to increase the likelihood that transactions will be confirmed.
>
Yes, it is a "new purpose" introduced almost a decade ago to allow Bitcoin
to scale without unnecessarily causing load on nodes, which are essential
for the decentralization of the system but uncompensated by the network.
> >Any sort of filtering beyond that done by miners is contrary to this
> purpose of the mempool. This is a technical fact.
>
> Again, you appear to be ignoring the existence of things like the dust
> filter, transaction size filters, standardness limits on legacy inputs,
> etc. And also again, you appear to be implying that the mempool is *not*
> useful for relaying transactions to miners so they can be confirmed in
> blocks (and not just so that said blocks can propagate quickly).
>
If the dust filter, transaction size filters, standardness limits, etc.,
were being ignored by miners then they should be removed, yes. Some of
these exist for historical reasons and others for performance reasons,
and in the latter case there might be a movement to enforce the old
rules in consensus. But if it came to "mempool policy vs miner policy"
then it is in the interest of both node operators and the network's
health to change the mempool policy.
> >It has nothing to do with "bitcoin's ethos", except its ethos as a
> consensus system, which directly contradicts your point.
>
> The mempool is not a consensus system, and noderunners are free to relay,
> or not relay, any transactions or blocks they like.
>
Yes, of course, but the goal of Bitcoin Core is not to let people do
"whatever they want" on the network. Core does not support "spy node"
operation, address indexing, or any number of things people have
requested but are unnecessary (or harmful) to the health of the network.
People can do whatever they want. This does not mean that Bitcoin Core
should actively support "whatever people want".
> Yes, in general things work more smoothly if all nodes have roughly the
> same view of the network, but allowing miners absolute control over the
> content of blocks in order to maximize their short-term fee revenue is a
> slippery slope toward a situation in which *only* data transactions are
> mined, rather than payments, and this would be fatal to a network that is
> supposed to be a payment system.
>
> Since there is no permanent way to disallow all data transactions in
> consensus, our only sustainable counterweight to this inevitable slide
> toward more and more short-term concerns by miners (at the expense of the
> network's long-term wellbeing) is mempool policy.
>
Unfortunately, this logic is akin to "We must do something. This is
something. Therefore, we must do this."
You are correct that, in a world where people are willing to pay more
for data publication than for transactions, Bitcoin will be overwhelmed
by data carriers unless it were possible to block data carriers. But
your proposed solution will not achieve this. To the contrary, it will
increase the cost of running a node for anybody who does it, and
increase the time it takes for blocks to propagate across the network,
both of which will have centralizing effects.
> When I say that disallowing filtering is not in keeping with bitcoin's
> ethos, I mean that bitcoin is a voluntary network where no one can coerce
> anyone else, and everyone is assumed to be following his or her own
> rational self-interest. Filtering dust is in the rational self-interest of
> a supermajority of nodes, because the alternative is massive utxoset bloat
> (and potentially node DoS attacks). Filtering data spam is no different; it
> has a very successful track record of helping to preserve bitcoin's
> usefulness as permissionless money, so it is beneficial to everyone.
>
Nodes filtering dust will, at best, prevent people from accidentally
broadcasting dust transactions. If somebody wants to do it, then they
will be able to, and any nodes that filter will be uselessly swimming
against the current.
If a meaningful number of blocks are produced that are full of dust
transactions, that filter should be removed (and perhaps some movement
to consensus-ban dust transactions will appear, which is a technically
much easier thing to accomplish).
> People are going to filter, because doing so is in their rational
> self-interest, so attempting to coerce people into relaying unconfirmed
> transactions that contain data (or designing systems on the assumption that
> everyone's mempools are always identical) is doomed to fail.
>
Nobody is "attempting to coerce people to relay transactions", any more than
you are "attempting to coerce" Core developers by posting polite messages on
the mailing list.
--
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
Chris Guida
Sep 26, 2025, 6:07:08 PM (3 days ago) Sep 26
to Andrew Poelstra, Bitcoin Development Mailing List
Hi Andrew -
>(You sent this message to me personally but it looks like it was
intended for the list. I am replying to the list, which I hope is
okay.)
intended for the list. I am replying to the list, which I hope is
okay.)
Haha yes, indeed! Thank you sir 🙏
I don't suppose it's worth it to try to "reply all" on my previous email to re-attach this to the previous thread...
>Yes, it is a "new purpose" introduced almost a decade ago to allow Bitcoin
to scale without unnecessarily causing load on nodes
to scale without unnecessarily causing load on nodes
Yes, and my point here is that you seem to be implying that the *only* purpose of the mempool is to make blocks propagate faster, and if that were true, then I would agree with you that spam filters are harmful. But since the mempool predates CBR by several years, your claim cannot be true.
>which are essential for the decentralization of the system but uncompensated by the network.
Yes, and this is exactly the problem with data spam, and also the problem with bitcoin core's recent shift.
The tripling of the utxoset within a couple of years has raised the minimum cost of joining the network from ~$150 to ~$250, which is permanent damage that may never be fixed, and worse, core devs have done nothing to prevent it from happening again (raising the opreturn limit does nothing to prevent brc20 or similar schemes).
Data spam pays an upfront fee, then enjoys bulletproof integrity and availability guarantees for the rest of eternity. A finite quantity (the upfront fee) divided by an infinite quantity (the amount of time the data is hosted) is zero. This is why payment txs can never fairly compete with data txs.
In addition, the fee does not actually go to the noderunners hosting the data; it only goes to the miner who mines the tx. So data txs are an unwanted and unnecessary burden on noderunners, which means they worsen the cost/benefit analysis of running a node, leading to a smaller node network.
Your point about node decentralization being paramount is also why core devs should listen to their users when they report UX difficulties. If the experience of running a node is bad, very few will do it. (I can assure you that the experience of running a useful merchant node is bad).
You appear to be making the claim that a merchant will have a better time running a node if he doesn't filter transactions than if he does. The last two years have proven this wrong. The primary culprit for making life difficult for merchant noderunners is data spam. A merchant's node will still work just fine even if block reconstruction times are quite long. A Lightning implementation such as CLN will not even notice the difference between a 1-second block propagation and a 10-second one. It just doesn't matter.
Conversely, the spam attacks from 2023-4 have directly led to increases in IBD times that are so extreme that the most popular merchant node hardware (the RPi 4B 4GB) can no longer sync the chain in under a month, and the next cheapest hardware that can do so is much more expensive. Reducing data spam (or utxoset workarounds like libbitcoin) are what we should be focusing on to increase participation in the node network. Pro-spam measures like ripping out the opreturn limit only make the problem worse, by fueling demand for shitcoining on-chain.
>If the dust filter, transaction size filters, standardness limits, etc., were being ignored by miners then they should be removed, yes.
Really? This should be trivial to achieve simply by launching a shitcoin metaprotocol on top of one of these filtered tx formats. At that point node DoS attacks would become more commonplace, no?
>Some of these exist for historical reasons and others for performance reasons, and in the latter case there might be a movement to enforce the old rules in consensus.
Interesting, so you're saying if someone launches a shitcoin metaprotocol on top of txs that are DoS vectors, then that might generate support for the Great Consensus Cleanup? Hmm...
>But if it came to "mempool policy vs miner policy" then it is in the interest of both node operators and the network's health to change the mempool policy.
Again, this seems like a slippery slope toward stuffing blocks full of data garbage rather than payments. You're basically saying miners should be in charge of bitcoin, and that non-mining nodes should have no mechanism by which to push back on miners. Am I misunderstanding?
>People can do whatever they want. This does not mean that Bitcoin Core should actively support "whatever people want".
Sure, but see the prior discussion, where you acknowledged that if bitcoin core does not make running bitcoin core a good UX for its users, then very few people will run bitcoin core nodes. So core devs need to strike a balance between disallowing popular user behaviors and discouraging noderunners from participating at all.
>Unfortunately, this logic is akin to "We must do something. This is something. Therefore, we must do this."
No, that's not what I'm saying. I'm saying we can't sustainably fight spam in consensus, and the only other enforcement mechanism besides consensus is what we relay. It's a much weaker enforcement mechanism, but it's much better suited to countering rapidly evolving threats than consensus, and it has historically been very effective at countering data spam. I can think of no other mechanisms besides consensus and standardness to bias the bitcoin network away from data and toward payments, can you?
>You are correct that, in a world where people are willing to pay more for data publication than for transactions, Bitcoin will be overwhelmed by data carriers unless it were possible to block data carriers. But your proposed solution will not achieve this. To the contrary, it will increase the cost of running a node for anybody who does it, and increase the time it takes for blocks to propagate across the network, both of which will have centralizing effects.
This claim is incredibly dubious. Again, there is incontrovertible historical data showing that data spam has been directly responsible for significantly increasing costs on noderunners. Slower block propagation via filters has not produced anywhere near the same effect. I'm actually not even sure what the mechanism for such increased costs would be; can you elaborate on how this works? Anyway no one I know has noticed an increased cost from slow block propagation, but practically everyone with a low-resource node noticed extreme increases in IBD times due to spam. Filtering inscriptions as soon as they started being exploited would have easily prevented this.
>Nodes filtering dust will, at best, prevent people from accidentally broadcasting dust transactions. If somebody wants to do it, then they will be able to, and any nodes that filter will be uselessly swimming against the current.
That is not what the data show. First, the opreturn filter results in a 99% reduction in confirmed nonstandard opreturns. Second, the dust filter itself was implemented as a result of spam attacks, and it has been perfectly effective since the moment it was implemented. Again, the purpose of spam filtration is not to eliminate 100% of spam. The purpose is to raise costs on spammers. Your email spam filter likely leaks a few spam emails once in a while, but I guarantee your reaction is not "it doesn't work; let's get rid of it".
>If a meaningful number of blocks are produced that are full of dust transactions, that filter should be removed (and perhaps some movement to consensus-ban dust transactions will appear, which is a technically much easier thing to accomplish).
Right, but this is unlikely because of the dust filter. Likewise for opreturn.
>Nobody is "attempting to coerce people to relay transactions", any more than you are "attempting to coerce" Core developers by posting polite messages on the mailing list.
Sure, that's why I said "or designing systems on the assumption that everyone's mempools are always identical".
Best,
--Chris
--
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/aNaUjR7QTqWvtZLa%40mail.wpsoftware.net.
Andrew Poelstra
Sep 28, 2025, 8:07:51 PM (21 hours ago) Sep 28
to Bitcoin Development Mailing List
On Fri, Sep 26, 2025 at 03:50:09PM -0600, Chris Guida wrote:
>
> >Yes, it is a "new purpose" introduced almost a decade ago to allow Bitcoin
> to scale without unnecessarily causing load on nodes
>
> Yes, and my point here is that you seem to be implying that the *only*
> purpose of the mempool is to make blocks propagate faster, and if that were
> true, then I would agree with you that spam filters are harmful. But since
> the mempool predates CBR by several years, your claim cannot be true.
>
I certainly didn't mean to imply that the only purpose of the mempool
>
> >Yes, it is a "new purpose" introduced almost a decade ago to allow Bitcoin
> to scale without unnecessarily causing load on nodes
>
> Yes, and my point here is that you seem to be implying that the *only*
> purpose of the mempool is to make blocks propagate faster, and if that were
> true, then I would agree with you that spam filters are harmful. But since
> the mempool predates CBR by several years, your claim cannot be true.
>
was to improve block propagation -- it is also useful for nodes to
validate transactions and cache signature validity and UTXO set updates,
something which filters are also harmful for.
<snip>
>
> Your point about node decentralization being paramount is also why core
> devs should listen to their users when they report UX difficulties. If the
> experience of running a node is bad, very few will do it. (I can assure you
> that the experience of running a useful merchant node is bad).
>
laptop fan spins up and your software freezes because your computer is
suddenly processing a whole block of transactions at once. It's bad when
Netflix needs to pause and re-cache every 10 minutes because your
network connection is saturated by a whole block.
Both of these things happened to me constantly before compact blocks.
<snip>
> >If the dust filter, transaction size filters, standardness limits, etc.,
> were being ignored by miners then they should be removed, yes.
>
> Really? This should be trivial to achieve simply by launching a shitcoin
> metaprotocol on top of one of these filtered tx formats. At that point node
> DoS attacks would become more commonplace, no?
>
> >Some of these exist for historical reasons and others for performance
> reasons, and in the latter case there might be a movement to enforce the
> old rules in consensus.
>
> Interesting, so you're saying if someone launches a shitcoin metaprotocol
> on top of txs that are DoS vectors, then that might generate support for
> the Great Consensus Cleanup? Hmm...
>
level of complexity and you are likely to fail at the first step where
you try to meme something into existence based on some obscure technical
thing :).
> >But if it came to "mempool policy vs miner policy" then it is in the
> interest of both node operators and the network's health to change the
> mempool policy.
>
> Again, this seems like a slippery slope toward stuffing blocks full of data
> garbage rather than payments. You're basically saying miners should be in
> charge of bitcoin, and that non-mining nodes should have no mechanism by
> which to push back on miners. Am I misunderstanding?
>
their ability to do so is constrained by resource usage, which filtering
increases). This prevents miners from processing tranasctions that
violate the rules of the network.
But nodes have no ability to constrain miners' behavior if that behavior
is within the rules of the network -- except by coordinating to execute
a fork to change the consensus rules.
<snip>
> That is not what the data show. First, the opreturn filter results in a 99%
> reduction in confirmed nonstandard opreturns. Second, the dust filter
> itself was implemented as a result of spam attacks, and it has been
> perfectly effective since the moment it was implemented. Again, the purpose
> of spam filtration is not to eliminate 100% of spam. The purpose is to
> raise costs on spammers. Your email spam filter likely leaks a few spam
> emails once in a while, but I guarantee your reaction is not "it doesn't
> work; let's get rid of it".
>
transactions that violate some policy rule, send them to my local node
which will reject them, and then claim that the policy rule was
99.9999999% effective at filtering out such transactions. My point is
that there's no meaningful way to count "transactions that exist but are
neither propagated nor in blocks".
Mempool policy makes it inconvenient for people to use transactions that
violate the mempool policy. It may discourage them from building
protocols that require such transactions. But this discouragement has no
monetary value, which means that as soon as there is any economic
interest in producing such transactions, they will be produced and they
will wind up in blocks. This is what we see -- and it's why we are
talking about eliminating the data carrier filters and not about
eliminating, say, the MINIMALIF rule on pre-segwit transactions.
<snip>
Russell O'Connor
9:12 AM (8 hours ago) 9:12 AM
to Bitcoin Development Mailing List
On Sun, Sep 28, 2025 at 8:07 PM Andrew Poelstra <apoe...@wpsoftware.net> wrote:
Mempool policy makes it inconvenient for people to use transactions that
violate the mempool policy. It may discourage them from building
protocols that require such transactions. But this discouragement has no
monetary value, which means that as soon as there is any economic
interest in producing such transactions, they will be produced and they
will wind up in blocks. This is what we see -- and it's why we are
talking about eliminating the data carrier filters and not about
eliminating, say, the MINIMALIF rule on pre-segwit transactions.
I fully agree that this discouragement has little monetary value. As we can see today, folks are bypassing the existing default mempool minfree rate of 1sat/vbyte and still managing to fill up blocks with these sorts of sub-1sat/vbyte transactions. This lets us measure the monetary cost of bypassing default mempool filters. The cost is less than the cost savings that such folks are achieving by their sub-1sat/vbyte transaction. Eyeballing it, I see that the cost of bypassing default filters is something less than 0.3sat/vbyte or so. Probably there was initially some upfront cost, which is now being amortized.
I'm glad to hear that the default minfree rate is being lowered. I'd even support eliminating the minfee entirely and instead relying on the max mempool size alone.
Also, as Andrew touched on, one valuable role of filters is to try and filter out third-party malleable transactions to the extent reasonably possible, or at least filter out their non-canonical / non-min-cost forms. That is valuable because those sorts of transactions are at great risk of never appearing in blocks.
/dev /fd0
11:30 AM (6 hours ago) 11:30 AM
to Andrew Poelstra, Bitcoin Development Mailing List
Hi Andrew,
> User experience is bad when every 10 minutes a block comes in and your
> laptop fan spins up and your software freezes because your computer is
> suddenly processing a whole block of transactions at once. It's bad when
> Netflix needs to pause and re-cache every 10 minutes because your
> network connection is saturated by a whole block.
> Both of these things happened to me constantly before compact blocks.
Have you tested compact blocks relay with default `blockreconstructionextratxn` in knots v29.1?
floppy disk guy
--
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/aNnIvR5Naea8pXCe%40mail.wpsoftware.net.
Lőrinc
11:30 AM (6 hours ago) 11:30 AM
to Bitcoin Development Mailing List
This is a slightly friendlier version of a previous reply I sent to Chris already:
--------
> The tripling of the utxoset within a couple of years has raised the minimum cost of joining the network from ~$150 to ~$250
I will be short: we want blocks to be full, blockchains are meant to grow, and even cheap nodes were more expensive in the past than what we can have now (which are also a lot more performant).
I bought a node in 2021 for ~$330 (which is ~$400 inflation adjusted) and it struggled with 700k blocks for weeks: https://x.com/L0RINC/status/1968189583180579188
If you're into storing the whole chain for some reason, you can have the same for ~$170 now and it will finish IBD in less than 1 day, depending on your internet speed (with average global speed just downloading it takes ~16 hours), see https://x.com/L0RINC/status/1967679285168386135.
I bought a node in 2021 for ~$330 (which is ~$400 inflation adjusted) and it struggled with 700k blocks for weeks: https://x.com/L0RINC/status/1968189583180579188
If you're into storing the whole chain for some reason, you can have the same for ~$170 now and it will finish IBD in less than 1 day, depending on your internet speed (with average global speed just downloading it takes ~16 hours), see https://x.com/L0RINC/status/1967679285168386135.
But you can also get a very good fully validating pruned node for $111 (e.g. https://gist.github.com/l0rinc/5a44ffa174857bc9c680a8e4bfc40a88), which can likely finish an IBD in ~2-3 days.
You can even buy one for $99, but that would indeed be quite slow, but even that would likely finish IBD in a week. You can go even cheaper with second-hand hardware. But I'm not sure why we would want to go lower than the price of a single night in a hotel...
You can even buy one for $99, but that would indeed be quite slow, but even that would likely finish IBD in a week. You can go even cheaper with second-hand hardware. But I'm not sure why we would want to go lower than the price of a single night in a hotel...
> core devs have done nothing to prevent it from happening again
Core devs progressively made the latest version 250% faster than v23 https://x.com/L0RINC/status/1970918510248575358.
And we still have other unmerged optimizations, so the situation is expected to be even better in upcoming releases. On my laptop our unmerged changes can fully reindex in ~2 hours. And with a SwiftSync prototype I have even done a reindex-chainstate on a battery-powered cheap rpi5 (+ monitoring over wifi) in ~3:14 hours (pi on a pi - and the batteries were still 70% full): https://x.com/L0RINC/status/1972062557835088347.
The situation has never been better, you can now do IBD from batteries!
And we still have other unmerged optimizations, so the situation is expected to be even better in upcoming releases. On my laptop our unmerged changes can fully reindex in ~2 hours. And with a SwiftSync prototype I have even done a reindex-chainstate on a battery-powered cheap rpi5 (+ monitoring over wifi) in ~3:14 hours (pi on a pi - and the batteries were still 70% full): https://x.com/L0RINC/status/1972062557835088347.
The situation has never been better, you can now do IBD from batteries!
> core devs should listen to their users
Twitter is not a representative sample (and neither are you).
In the free market, participants produce stuff and the usage is the feedback, not the online complaining.
> the most popular merchant node hardware (the RPi 4B 4GB) can no longer sync the chain in under a month, and the next cheapest hardware that can do so is much more expensive.
I also retested an old Raspberry Pi 4b with 8gb: IBD with v30 finished in 71h 36m 44s (<3 days) until ~916k blocks with default dbcache.
With a 5GB dbcache it would likely be even faster, I just wanted to see the worst case.
> Reducing data spam (or utxoset workarounds like libbitcoin) are what we should be focusing on to increase participation in the node network.
I don't see how spent + unspent can be smaller than just the unspent set.
> but practically everyone with a low-resource node noticed extreme increases in IBD times due to spam
It's not the "spam", that's very cheap to validate. They just likely forgot to update the node (leaving the assumevalid height early and they're doing too many useless script validations) or are writing on cheap SD cards with 10MB/s rate or are doing IBD over TOR or are leaving the dbcache size at default or increasing it to the total memory size and are constantly swapping, or have enabled all optional indexes, etc.
I agree these should be better documented, it's why https://github.com/bitcoin/bitcoin/pull/33336 and https://github.com/bitcoin/bitcoin/pull/33333 were opened: if only you used all this anger to educate people and help, instead of blaming the firetruck for the fire...
I agree these should be better documented, it's why https://github.com/bitcoin/bitcoin/pull/33336 and https://github.com/bitcoin/bitcoin/pull/33333 were opened: if only you used all this anger to educate people and help, instead of blaming the firetruck for the fire...
> The purpose is to raise costs on spammers
Why do you focus on hating people who disagree with you, even when that hurts honest participants?
Reply all
Reply to author
Forward
0 new messages