From: Bitcoin Error Log <bitcoinerrorlog@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.
Date: Thu, 30 Oct 2025 01:55:20 -0700 (PDT) [thread overview]
Message-ID: <09d0aa74-1305-45bd-8da9-03d1506f5784n@googlegroups.com> (raw)
In-Reply-To: <CAAS2fgSNtO6kpfm0XaBCufyExjJnxg87ttLGUgpUU9pkemZTig@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 30197 bytes --]
Greg,
One correction. Bitcoin has significantly restricted a proven use case with
policy in the past. Maybe you won't think this qualifies, but it happened
while you were away so I am curious about your assessment.
During the change to mempoolfullrbf policy, I, with support from the
original author of the change, and with support of multiple Core devs, and
with the support of multiple businesses providing data on how they provided
zero-conf as a service to users via risk management, tried to stop Bitcoin
from killing first-seen policy, which had been stable for all of the
history of Bitcoin. The change was at least clearly demonstrated as
controversial, and lacking real consensus.
I'm happy to admit that no policy is enforceable, and that zero-conf was
"never safe", but we had a system that worked and made Bitcoin more useful
to people that used it that way. The businesses simply monitored for
doublespends, imposed exposure limits per block, and gated actual delivery
separately from checkout UX. It worked and now it does not and the only
reason was a policy change.
The problem with claiming that policy is not a means of change, is that you
must also admit the lack of need for any RBF flags at all, or for arguing
about data spam relay, or for any wide policy to be a concern of Bitcoin
Core at all. (particularly when speculatively / subjectively applied) .
Thank you, and sorry for the side topic.
~John
On Thursday, October 30, 2025 at 6:40:10 AM UTC Greg Maxwell wrote:
Prior softforks have stuck to using the more explicit "forward
compatibility" mechanisms, so -- e.g. if you use OP_NOP3 or a higher
transaction version number or whatever that had no purpose (and would
literally do nothing), saw ~no use, and was non-standard, or scripts that
just anyone could have immediately taken at any time (e.g. funds free for
the collecting rather than something secure)... then in that case I think
people have felt that the long discussion leading up to a softfork was
enough to acceptably mitigate the risk. Tapscript was specifically
designed to make upgrades even safer and easier by making it so that the
mere presence of any forward compat opcode (OP_SUCCESSn) makes the whole
script insecure until that opcode is in use.
The proposal to limit scriptpubkey size is worse because longer scripts had
purposes and use (e.g. larger multisigs) and unlike some NOP3 or txversions
where you could be argued to deserve issues if you did something so weird
and abused a forward compat mechanism, people running into a 520 limit
could have been pretty boring (and I see my own watching wallets have some
scriptpubkeys beyond that size (big multisigs), in fact-- though I don't
*think* any are still in use, but even I'm not absolutely sure that such a
restriction wouldn't confiscate some of my own funds--- and it's a pain in
the rear to check, having to bring offline stuff online, etc).
Confiscation isn't just limited to timelocks, since the victims of it may
just not know about the consensus change and while they could move their
coins they don't. One of the big advantages many people see in Bitcoin is
that you can put your keys in a time capsule in the foundation of your home
and trust that they're still going to be there and you'll be able to use
your coins a decade later. ... that you don't have to watch out for banks
drilling your safe deposit boxes or people putting public notices in
classified ads laying claim to your property.
I don't even think bitcoin has ever policy restricted something that was in
active use, much less softforked out something like that. I wouldn't say
it was impossible but I think on the balance it would favor a notice period
so that any reasonable person could have taken notice, taken action, or at
least spoke up. But since there is no requirement to monitor and that's
part of bitcoin's value prop the amount of time to consider reasonable
ought to be quite long. Which also is at odds with the emergency measures
position being taken by proponents of such changes.
(which also, I think are just entirely unjustified, even if you accept the
worst version of their narrative with the historical chain being made
_illegal_, one could simply produce node software that starts from a well
known embedded utxo snapshot and doesn't process historical blocks. Such
a thing would be in principle a reduction in the security model, but
balances against the practical and realistic impact of potentially
confiscating coins I think it looks pretty fine by comparison. It would
also be fully consensus compatible, assuming no reorg below that point, and
can be done right now by anyone who cares in a totally permissionless and
coercion free manner)
On Thu, Oct 30, 2025 at 5:13 AM Michael Tidwell <mtidw...@gmail.com> wrote:
Greg,
> Also some risk of creating a new scarce asset class.
Well, Casey Rodarmor is in the thread, so lol maybe.
Anyway, point taken. I want to be 100% sure I understand the hypotheticals:
there could be an off-chain, presigned, transactions that needs more than
520 bytes for the scriptPubKey and, as Poelstra said, could even form a
chain of presigned transactions under some complex, previously unknown,
scheme that only becomes public after this change is made. Can you confirm?
Would it also be a worry that a chain of transactions using said utxo could
commit to some bizarre scheme, for instance a taproot transaction utxo that
later is presigned committed back to P2MS larger than 520 bytes? If so, I
think I get it, you're saying to essentially guarantee no confiscation we'd
never be able to upgrade old UTXOs and we'd need to track them forever to
prevent unlikely edge cases?
Does the presigned chain at least stop needing to be tracked once the given
UTXO co-mingles with a post-update coinbase utxo?
If so, this is indeed complex! This seems pretty insane both for the
complexity of implementing and the unlikely edge cases. Has Core ever made
a decision of (acceptable risk) to upgrade with protection of onchain utxos
but not hypothetical unpublished ones?
Aren't we going to run into the same situation if we do an op code clean up
in the future if we had people presign/commit to op codes that are no
longer consensus valid?
Tidwell
On Wednesday, October 29, 2025 at 10:32:10 PM UTC-4 Greg Maxwell wrote:
"A few bytes" might be on the order of forever 10% increase in the UTXO set
size, plus a full from-network resync of all pruned nodes and a full (e.g.
most of day outage) reindex of all unpruned nodes. Not insignificant but
also not nothing. Such a portion of the existing utxo size is not from
outputs over 520 bytes in size, so as a scheme for utxo set size reduction
the addition of MHT tracking would probably make it a failure.
Also some risk of creating some new scarce asset class, txouts consisting
of primordial coins that aren't subject to the new rules... sounds like the
sort of thing that NFT degens would absolutely love. That might not be an
issue *generally* for some change with confiscation risk, but for a change
that is specifically intended to lobotomize bitcoin to make it less useful
to NFT degens, maybe not such a great idea. :P
I mentioned it at all because I thought it could potentially be of some
use, I'm just more skeptical of it for the current context. Also luke-jr
and crew has moved on to actually propose even more invasive changes than
just limiting the script size, which I anticipated, and has much more
significant issues. Just size limiting outputs likely doesn't harm any
interests or usages-- and so probably could be viable if the confiscation
issue was addressed, but it also doesn't stick it to people transacting in
ways the priests of ocean mining dislike.
> I believe you're pointing out the idea of non economically-rational
spammers?
I think it's a mistake to conclude the spammers are economically
irrational-- they're often just responding to different economics which may
be less legible to your analysis. In particular, NFT degens prefer the
high cost of transactions as a thing that makes their tokens scarce and
gives them value. -- otherwise they wouldn't be swapping for one less
efficient encoding for another, they're just be using another blockchain
(perhaps their own) entirely.
On Thu, Oct 30, 2025 at 1:16 AM Michael Tidwell <mtidw...@gmail.com> wrote:
> MRH tracking might make that acceptable, but comes at a high cost which I
think would clearly not be justified.
Greg, I want to ask/challenge how bad this is, this seems like a generally
reusable primitive that could make other upgrades more feasible that also
have the same strict confiscation risk profile.
IIUC, the major pain is, 1 big reindex cost + a few bytes per utxo?
Poelstra,
> I don't think this is a great idea -- it would be technically hard to
implement and slow deployment indefinitely.
I would like to know how much of a deal breaker this is in your opinion. Is
MRH tracking off the table? In terms of the hypothetical presigned
transactions that may exist using P2MS, is this a hard enough reason to
require a MRH idea?
Greg,
> So, paradoxically this limit might increase the amount of non-prunable
data
I believe you're pointing out the idea of non economically-rational
spammers? We already see actors ignoring cheaper witness inscription
methods. If spam shifts to many sub-520 fake pubkey outputs (which I
believe is less harmful than stamps), that imo is a separate UTXO cost
discussion. (like a SF to add weight to outputs). Anywho, this point alone
doesn't seem sufficient to add as a clear negative reason for someone
opposed to the proposal.
Thanks,
Tidwell
On Wednesday, October 22, 2025 at 5:55:58 AM UTC-4 moonsettler wrote:
> Confiscation is a problem because of presigned transactions
Allow 10000 bytes of total scriptPubKey size in each block counting only
those outputs that are larger than x (520 as proposed).
The code change is pretty minimal from the most obvious implementation of
the original rule.
That makes it technically non-confiscatory. Still non-standard, but if
anyone out there so obnoxiously foot-gunned themselves, they can't claim
they were rugged by the devs.
BR,
moonsettler
On Saturday, October 18th, 2025 at 3:15 PM, PortlandHODL <ad...@qrsnap.io>
wrote:
> Hey,
>
> First, thank you to everyone who responded, and please continue to do so.
There were many thought provoking responses and this did shift my
perspective quite a bit from the original post, which in of itself was the
goal to a degree.
>
> I am currently only going to respond to all of the current concerns.
Acks; though I like them will be ignored unless new discoveries are
included.
>
> Tl;dr (Portlands Perspective)
> - Confiscation is a problem because of presigned transactions
> - DoS mitigation could also occur through marking UTXOs as unspendable if
> 520 bytes, this would preserve the proof of publication.
> - Timeout / Sunset logic is compelling
> - The (n) value of acceptable needed bytes is contentious with the lower
suggested limit being 67
> - Congestion control is worth a look?
>
> Next Step:
> - Deeper discussion at the individual level: Antoine Poinsot and GCC
overlap?
> - Write an implementation.
> - Decide to pursue BIP
>
> Responses
>
> Andrew Poelstra:
> > There is a risk of confiscation of coins which have pre-signed but
> > unpublished transactions spending them to new outputs with large
> > scriptPubKeys. Due to long-standing standardness rules, and the
presence
> > of P2SH (and now P2WSH) for well over a decade, I'm skeptical that any
> > such transactions exist.
>
> PortlandHODL: This is a risk that can be incurred and likely not possible
to mitigate as there could be possible chains of transactions so even when
recursively iterating over a chain there is a chance that a presigned
breaks this rule. Every idea I have had from block redemption limits on
prevouts seems to just be a coverage issue where you can make the
confiscation less likely but not completely mitigated.
>
> Second, there are already TXs that effectively have been confiscated at
the policy level (P2SH Cleanstack violation) where the user can not find
any miner with a policy to accept these into their mempool. (3 years)
>
> /dev /fd0
> > so it would be great if this was restricted to OP_RETURN
>
> PortlandHODL: I reject this completely as this would remove the UTXOset
omission for the scriptPubkey and encourage miners to subvert the OP_RETURN
restriction and instead just use another op_code, this also do not hit on
some of the most important factors such as DoS mitigation and legacy script
attack surface reduction.
>
> Peter Todd
> > NACK ...
>
> PortlandHODL: You NACK'd for the same reasons that I stated in my OP,
without including any additional context or reasoning.
>
> jeremy
> > I think that this type of rule is OK if we do it as a "sunsetting"
restriction -- e.g. a soft fork active for the next N blocks (N = e.g. 2
years, 5 years, 10 years).
>
> If action is taken, this is the most reasonable approach. Alleviating
confiscatory concerns through deferral.
>
> > You can argue against this example probably, but it is worth
considering that absence of evidence of use is not evidence of absence of
use and I myself feel that overall our understanding of Bitcoin transaction
programming possibilities is still early. If you don't like this example, I
can give you others (probably).
>
> Agreed and this also falls into the reasoning for deciding to utilize
point 1 in your response. My thoughts on this would be along the lines of
proof of publication as this change only has the effect of stripping away
the executable portion of a script between 521 and 10_000 bytes or the
published data portion if > 10_000 bytes which the same data could likely
be published in chunked segments using outpoints.
>
> Andrew Poelstra:
> > Aside from proof-of-publication (i.e. data storage directly in the UTXO
> > set) there is no usage of script which can't be equally (or better)
> > accomplished by using a Segwit v0 or Taproot script.
>
> This sums up the majority of future usecase concern
>
> Anthony Towns:
> > (If you restricted the change to only applying to scripts that used
> non-push operators, that would probably still provide upgrade flexibility
> while also preventing potential script abuses. But it wouldn't do
anything
> to prevent publishing data)
>
> Could this not be done as segments in multiple outpoints using a
coordination outpoint? I fail to see why publication proof must be in a
single chunk. This does though however bring another alternative to mind,
just making these outpoints unspendable but not invalidate the block
through inclusion...
>
> > As far as the "but contiguous data will be regulated more strictly"
> argument goes; I don't think "your honour, my offensive content has
> strings of 4d0802 every 520 bytes
>
> Correct, this was never meant to resolve this issue.
>
> Luke Dashjr:
> > If we're going this route, we should just close all the gaps for the
immediate future:
>
> To put it nicely, this is completely beyond the scope of what is being
proposed.
>
> Guus Ellenkamp:
> > If there are really so few OP_RETURN outputs more than 144 bytes, then
> why increase the limit if that change is so controversial? It seems
> people who want to use a larger OP_RETURN size do it anyway, even with
> the current default limits.
>
> Completely off topic and irrelevant
>
> Greg Tonoski:
> > Limiting the maximum size of the scriptPubKey of a transaction to 67
bytes.
>
> This leave no room to deal with broken hashing algorithms and very little
future upgradability for hooks. The rest of these points should be merged
with Lukes response and either hijack my thread or start a new one with the
increased scope, any approach I take will only be related to the
ScriptPubkey
>
> Keagan McClelland:
> > Hard NACK on capping the witness size as that would effectively ban
large scripts even in the P2SH wrapper which undermines Bitcoin's ability
to be an effectively programmable money.
>
> This has nothing to do with the witness size or even the P2SH wrapper
>
> Casey Rodarmor:
> > I think that "Bitcoin could need it in the future?" might be a good
enough
> reason not to do this.
>
> > Script pubkeys are the only variable-length transaction fields which
can be
> covered by input signatures, which might make them useful for future soft
> forks. I can imagine confidential asset schemes or post-quantum coin
recovery
> schemes requiring large proofs in the outputs, where the validity of the
proof
> determined whether or not the transaction is valid, and thus require the
> proofs to be in the outputs, and not just a hash commitment.
>
> Would the ability to publish the data alone be enough? Example make the
output unspendable but allow for the existence of the bytes to be covered
through the signature?
>
>
> Antoine Poinsot:
> > Limiting the size of created scriptPubKeys is not a sufficient
mitigation on its own
> I fail to see how this would not be sufficient? To DoS you need 2 things
inputs with ScriptPubkey redemptions + heavy op_codes that require unique
checks. Example DUPing stack element again and again doesn't work. This
then leads to the next part is you could get up to unique complex
operations with the current (n) limit included per input.
>
> > One of the goal of BIP54 is to address objections to Matt's earlier
proposal, notably the (in my
> opinion reasonable) confiscation concerns voiced by Russell O'Connor.
Limiting the size of
> scriptPubKeys would in this regard be moving in the opposite direction.
>
> Some notes is I would actually go as far as to say the confiscation risk
is higher with the TX limit proposed in BIP54 as we actually have proof of
redemption of TXs that break that rule and the input set to do this already
exists on-chain no need to even wonder about the whole presigned.
bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08
>
> Please let me know if I am incorrect on any of this.
>
> > Furthermore, it's always possible to get the biggest bang for our buck
in a first step
>
> Agreed on bang for the buck regarding DoS.
>
> My final point here would be that I would like to discuss more, and this
is response is from the initial view of your response and could be
incomplete or incorrect, This is just my in the moment response.
>
> Antoine Riard:
> > Anyway, in the sleeping pond of consensus fixes fishes, I'm more in
favor of prioritizing
> a timewarp fix and limiting dosy spends by old redeem scripts
>
> The idea of congestion control is interesting, but this solution should
significantly reduce the total DoS severity of known vectors.
>
> On Saturday, October 18, 2025 at 2:25:18 AM UTC-7 Greg Maxwell wrote:
>
> > Limits on block construction that cross transactions make it harder to
accurately estimate fees and greatly complicate optimal block
construction-- the latter being important because smarter and more computer
powered mining code generating higher profits is a pro centralization
factor.
> >
> > In terms of effectiveness the "spam" will just make itself
indistinguishable from the most common transaction traffic from the
perspective of such metrics-- and might well drive up "spam" levels because
the higher embedding cost may make some of them use more transactions. The
competition for these buckets by other traffic could make it effectively a
block size reduction even against very boring ordinary transactions. ...
which is probably not what most people want.
> >
> > I think it's important to keep in mind that bitcoin fee levels even at
0.1s/vb are far beyond what other hosting services and other blockchains
cost-- so anyone still embedding data in bitcoin *really* want to be there
for some reason and aren't too fee sensitive or else they'd already be
using something else... some are even in favor of higher costs since the
high fees are what create the scarcity needed for their seigniorage.
> >
> > But yeah I think your comments on priorities are correct.
> >
> >
> >
> > On Sat, Oct 18, 2025 at 1:20 AM Antoine Riard <antoin...@gmail.com>
wrote:
> >
> > > Hi list,
> > >
> > > Thanks to the annex covered by the signature, I don't see how the
concern about limiting
> > > the extensibility of bitcoin script with future (post-quantum)
cryptographic schemes.
> > > Previous proposal of the annex were deliberately designed with
variable-length fields
> > > to flexibly accomodate a wide range of things.
> > >
> > > I believe there is one thing that has not been proposed to limit
unpredictable utterance
> > > of spams on the blockchain, namely congestion control of categories
of outputs (e.g "fat"
> > > scriptpubkeys). Let's say P a block period, T a type of scriptpubkey
and L a limiting
> > > threshold for the number of T occurences during the period P. Beyond
the L threshold, any
> > > additional T scriptpubkey is making the block invalid. Or
alternatively, any additional
> > > T generating / spending transaction must pay some weight penalty...
> > >
> > > Congestion control, which of course comes with its lot of
shenanigans, is not very a novel
> > > idea as I believe it has been floated few times in the context of
lightning to solve mass
> > > closure, where channels out-priced at current feerate would have
their safety timelocks scale
> > > ups.
> > >
> > > No need anymore to come to social consensus on what is quantitative
"spam" or not. The blockchain
> > > would automatically throttle out the block space spamming
transaction. Qualitative spam it's another
> > > question, for anyone who has ever read shannon's theory of
communication only effective thing can
> > > be to limit the size of data payload. But probably we're kickly back
to a non-mathematically solvable
> > > linguistical question again [0].
> > >
> > > Anyway, in the sleeping pond of consensus fixes fishes, I'm more in
favor of prioritizing
> > > a timewarp fix and limiting dosy spends by old redeem scripts, rather
than engaging in shooting
> > > ourselves in the foot with ill-designed "spam" consensus mitigations.
> > >
> > > [0] If you have a soul of logician, it would be an interesting
demonstration to come with
> > > to establish that we cannot come up with mathematically or
cryptographically consensus means
> > > to solve qualitative "spam", which in a very pure sense is a
linguistical issue.
> > >
> > > Best,
> > > Antoine
> > > OTS hash:
6cb50fe36ca0ec5cb9a88517dd4ce9bb50dd6ad1d2d6a640dd4a31d72f0e4999
> > > Le vendredi 17 octobre 2025 à 19:45:44 UTC+1, Antoine Poinsot a écrit
:
> > >
> > > > Hi,
> > > >
> > > > This approach was discussed last year when evaluating the best way
to mitigate DoS blocks in terms
> > > > of gains compared to confiscatory surface. Limiting the size of
created scriptPubKeys is not a
> > > > sufficient mitigation on its own, and has a non-trivial
confiscatory surface.
> > > >
> > > > One of the goal of BIP54 is to address objections to Matt's earlier
proposal, notably the (in my
> > > > opinion reasonable) confiscation concerns voiced by Russell
O'Connor. Limiting the size of
> > > > scriptPubKeys would in this regard be moving in the opposite
direction.
> > > >
> > > > Various approaches of limiting the size of spent scriptPubKeys were
discussed, in forms that would
> > > > mitigate the confiscatory surface, to adopt in addition to (what
eventually became) the BIP54 sigops
> > > > limit. However i decided against including this additional measure
in BIP54 because:
> > > > - of the inherent complexity of the discussed schemes, which would
make it hard to reason about
> > > > constructing transactions spending legacy inputs, and equally hard
to evaluate the reduction of
> > > > the confiscatory surface;
> > > > - more importantly, there is steep diminishing returns to piling on
more mitigations. The BIP54
> > > > limit on its own prevents an externally-motivated attacker from
*unevenly* stalling the network
> > > > for dozens of minutes, and a revenue-maximizing miner from
regularly stalling its competitions
> > > > for dozens of seconds, at a minimized cost in confiscatory surface.
Additional mitigations reduce
> > > > the worst case validation time by a smaller factor at a higher cost
in terms of confiscatory
> > > > surface. It "feels right" to further reduce those numbers, but it's
less clear what the tangible
> > > > gains would be.
> > > >
> > > > Furthermore, it's always possible to get the biggest bang for our
buck in a first step and going the
> > > > extra mile in a later, more controversial, soft fork. I previously
floated the idea of a "cleanup
> > > > v2" in private discussions, and i think besides a reduction of the
maximum scriptPubKey size it
> > > > should feature a consensus-enforced maximum transaction size for
the reasons stated here:
> > > >
https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/8.
I wouldn't hold my
> > > > breath on such a "cleanup v2", but it may be useful to have it
documented somewhere.
> > > >
> > > > I'm trying to not go into much details regarding which mitigations
were considered in designing
> > > > BIP54, because they are tightly related to the design of various
DoS blocks. But i'm always happy to
> > > > rehash the decisions made there and (re-)consider alternative
approaches on the semi-private Delving
> > > > thread [0] dedicated to this purpose. Feel free to ping me to get
access if i know you.
> > > >
> > > > Best,
> > > > Antoine Poinsot
> > > >
> > > > [0]:
https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711
> > > >
> > > >
> > > >
> > > >
> > > > On Friday, October 17th, 2025 at 1:12 PM, Brandon Black <
fre...@reardencode.com> wrote:
> > > >
> > > > >
> > > > >
> > > > > On 2025-10-16 (Thu) at 00:06:41 +0000, Greg Maxwell wrote:
> > > > >
> > > > > > But also given that there are essentially no violations and no
reason to
> > > > > > expect any I'm not sure the proposal is worth time relative to
fixes of
> > > > > > actual moderately serious DOS attack issues.
> > > > >
> > > > >
> > > > > I believe this limit would also stop most (all?) of
PortlandHODL's
> > > > > DoSblocks without having to make some of the other changes in
GCC. I
> > > > > think it's worthwhile to compare this approach to those proposed
by
> > > > > Antoine in solving these DoS vectors.
> > > > >
> > > > > Best,
> > > > >
> > > > > --Brandon
> > > > >
> > > > > --
> > > > > 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/aPJ3w6bEoaye3WJ6%40console.
> > >
> > > --
> > > 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/5135a031-a94e-49b9-ab31-a1eb48875ff2n%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/78475572-3e52-44e4-8116-8f1a917995a4n%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/f4755fb6-b031-4c60-b304-f123ba2ff473n%40googlegroups.com
<https://groups.google.com/d/msgid/bitcoindev/f4755fb6-b031-4c60-b304-f123ba2ff473n%40googlegroups.com?utm_medium=email&utm_source=footer>
.
--
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/c208e054-b85a-4a5c-9193-c28ef0d225c5n%40googlegroups.com
<https://groups.google.com/d/msgid/bitcoindev/c208e054-b85a-4a5c-9193-c28ef0d225c5n%40googlegroups.com?utm_medium=email&utm_source=footer>
.
--
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/09d0aa74-1305-45bd-8da9-03d1506f5784n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 36103 bytes --]
next prev parent reply other threads:[~2025-10-30 11:39 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-02 20:42 [bitcoindev] " PortlandHODL
2025-10-02 22:19 ` Andrew Poelstra
2025-10-02 22:46 ` Andrew Poelstra
2025-10-02 22:47 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-03 7:11 ` Garlo Nicon
2025-10-02 22:27 ` Brandon Black
2025-10-03 1:21 ` [bitcoindev] " /dev /fd0
2025-10-03 10:46 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-03 11:26 ` /dev /fd0
2025-10-03 13:35 ` jeremy
2025-10-03 13:59 ` Andrew Poelstra
2025-10-03 14:18 ` /dev /fd0
2025-10-03 14:59 ` Andrew Poelstra
2025-10-03 16:15 ` Anthony Towns
2025-10-05 9:59 ` Guus Ellenkamp
2025-10-03 13:21 ` [bitcoindev] " Peter Todd
2025-10-03 16:52 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-03 15:42 ` Anthony Towns
2025-10-03 20:02 ` Luke Dashjr
2025-10-03 20:52 ` /dev /fd0
2025-10-04 23:12 ` jeremy
2025-10-05 10:59 ` Luke Dashjr
2025-10-08 15:03 ` Greg Tonoski
2025-10-08 18:15 ` Keagan McClelland
2025-10-15 20:04 ` [bitcoindev] " Casey Rodarmor
2025-10-16 0:06 ` Greg Maxwell
2025-10-17 17:07 ` Brandon Black
2025-10-17 18:05 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-10-18 1:01 ` Antoine Riard
2025-10-18 4:03 ` Greg Maxwell
2025-10-18 12:06 ` PortlandHODL
2025-10-18 16:44 ` Greg Tonoski
2025-10-18 16:54 ` /dev /fd0
2025-10-22 8:07 ` 'moonsettler' via Bitcoin Development Mailing List
2025-10-27 23:44 ` Michael Tidwell
2025-10-30 2:26 ` Greg Maxwell
2025-10-30 3:36 ` Michael Tidwell
2025-10-30 6:15 ` Greg Maxwell
2025-10-30 8:55 ` Bitcoin Error Log [this message]
2025-10-30 17:40 ` Greg Maxwell
2025-10-30 20:27 ` [bitcoindev] Policy restrictions Was: " 'Russell O'Connor' via Bitcoin Development Mailing List
2025-10-30 22:23 ` [bitcoindev] " 'Russell O'Connor' via Bitcoin Development Mailing List
2025-10-30 16:10 ` [bitcoindev] " Tom Harding
2025-10-30 22:15 ` Doctor Buzz
2025-10-20 15:22 ` Greg Maxwell
2025-10-21 19:05 ` Garlo Nicon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=09d0aa74-1305-45bd-8da9-03d1506f5784n@googlegroups.com \
--to=bitcoinerrorlog@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox