From: Pepe Hodler <pepehodler@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: The Cat, BIP draft discussion.
Date: Sun, 18 Jan 2026 17:11:10 -0800 (PST) [thread overview]
Message-ID: <cf39fdca-e996-43be-ab52-573aedd619d5n@googlegroups.com> (raw)
In-Reply-To: <c87a50a4-1a1b-4aee-bc1f-bd1c91d675d1n@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 26038 bytes --]
Hi list.
Which brings me to my disagreement, which I know is not shared by a number
of contributors here: just as it is hard to define spam on Bitcoin
I don't understand how anyone could be confused about the concept of spam
on bitcoin. Bitcoins is "A Peer-to-Peer Electronic Cash System" according
to the white paper. As such, anything not intended as a monetary
transaction is spam.
The use of fake pubkeys to store data on chain, that is an unsupported and
unsanctioned use of bitcoin. That is spam, and an attack, not a monetary
transaction.
Same with fake scripthash used to store arbitrary data, unsupported and
unsanctioned use of bitcoin. That is spam, and an attack, not a monetary
transaction.
And the same goes for the Segwit exploit and the Taproot exploit. That is
exploiting bitcoin to store arbitrary data in an unsanctioned way, spam, an
attack on bitcoin.
When Segwit and Taproot were implemented, nobody, absolutely nobody was
welcoming those upgrades as a way to store jpegs and other garbage on
chain. That is not what bitcoin, Segwit, and Taproot were built for.
If you are making use of OpenRelay and/or SlipStream to bypass the policy
of the majority of nodes, you are a spammer and an attacker, not a bitcoiner.
You are trying to skirt the only use case of bitcoin.
When there are blocks like this one:
https://mempool.space/block/00000000000000000000ed962f87a0c350b1401fe546db60e6d78e34ab549378 .
Over 60% of the transactions in that block are not sending or receiving a
single sat. It's all op_returns with no sats in them. That is not what
bitcoin was designed or sanctioned for.
These people are not users, they are attackers and spammers. How can you
look at inscriptions, runes, ordinals, fake pubkeys, fake scripthash,
stamps, and op_return with 0 sats in them and wonder if those are legit
bitcoin monetary transactions?
Now, some have tried to claim "My ordinal is a consensus valid
transaction". And of course it is, otherwise it would not have been added
to a block. But that's like saying the Nigerian prince email followed all
the SMTP and POP protocols of email, therefore it's not spam. Some spam
defenders have tried to claim they have paid their miner fee. Of course
they did, but that's like saying the sender of the Nigerian prince email
paid his internet, therefore it's not spam.
If you are confused about what constitutes spam on bitcoin, please explain.
While I'm sure there are some transactions that could be tricky and
controversial to identify as spam, I"m sure we can all agree that
inscriptions, stamps, jpegs, fake pubkeys, fake scripthash, unusually large
Segwit data, ordinals, runes, etc, are all clearly spam.
it's also very hard to define it in a discussion forum like this one.
I just did it, see above. It really wasn't that hard. How are you confused
about the definition of spam as it pertains to bitcoin? Because bitcoin is
money, they have to obfuscate their spam to make it look like a legitimate
monetary transaction to the system. So you could make the case that it's
harder to distinguish spam from a real monetary transaction. But defining
spam on it's own is pretty easy.
But ultimately, it does not belong to devs to decide what is spam. Don't
think that just because we know C++, that somehow gives us authority to
decide what direction bitcoin should be taking, and what spam is.
That decision belongs to the nodes. And it's clear that the nodes are not
given the tools to decide for themselves what spam is or what spam isn't,
with comprehensive user configurable spam filters.
Notions of motivation of contributors (such as they are paid by such and
such a company) should not be relevant.
Are you suggesting that conflict of interest is not a thing? If someone is
advocating against any and all measures against spam, I would really like
to know where their interests lie.
Everything should be open to discussion which is implementation-technical
(so obviously not e.g. threats of violence or things that bring legal
liability to participants or have zero relevance to Bitcoin's technical
development) even if it's philosophy-motivated. And blocking should be
reserved either as an anti-DOS measure if volume gets out of control, or if
it brings dangers as per the previous parenthetical.
This comes across as a thinly veiled attempt to censor anyone who wants to
combat spam, and their employees/employers. This idea of censoring
"confiscatory" proposals never came up when someone proposed confiscation
though what he called "demorage" or when someone proposed seizing Satoshi's
coin.
If you want to buy or sell pancakes, or JPEgs, or anything else for that
matter, bitcoin is here to serve you. But your pancakes and your JPEGs
don't belong on the bitcoin chain.
Disclaimer: I own bitcoin, I run a bitcoin business in El Salvador. I own
no inscriptions or spam of any kind, and I don't profit from any spam
related companies.
40% of the UTXO set is dust spam UTXOs that contains less than 0.0017% of
the total bitcoin issued. This constitutes an attack on bitcoin. I think we
all should start acknowledging the problem, and stop asking ourselves
dismissive questions like "What is spam anyways?" and use that question as
an excuse to pretend there is no problem.
Cheers, Pepe
On Tuesday, 30 December 2025 at 08:51:56 UTC-6 Antoine Riard wrote:
Hi list,
> Which brings me to my disagreement, which I know is not shared by a
number of contributors here: just as it is hard to define spam on Bitcoin,
it's also very hard to define it in a discussion forum like this one.
Making suggestions which *I* think are terrible, or detrimental, on a list
like this, should never be disallowed here. Notions of motivation of
contributors (such as they are paid by such and such a company) should not
be relevant. Everything should be open to discussion which is
implementation-technical (so obviously not e.g. threats of violence or
things that bring legal liability to participants or have zero relevance to
Bitcoin's technical development) even if it's philosophy-motivated. And
blocking should be reserved either as an anti-DOS measure if volume gets
out of control, or if it brings dangers as per the previous parenthetical.
I'm fully sharing waxwing reasonable opinion. While I can understand gmax's
sentiment being fed
up with poor coin confiscation proposals again and again on the mailing
list, the cure would be
worst than the disease. Maybe, I'm very voltairean here, but you don't
fight ill-founded opinions.
by persecuting their authors (--otherwise, down the road you take the risk
of seeing the bastille
popped up). Rather than you fight them back by doing the work to persuade
and to convince those
ideas you find stupid are indeed *objectively* stupid.
To me, it's a sign of strength and confidence that Bitcoin and its
development process can
withstand and endure the most "outrageous" controversies. For sure, I have
been enough times
in the shoes of someone who has to champion controversial changes (cf.
`mempoolfullrbf`) to not
negate that the strength of the process is kinda traded on the back of the
devs, but this is not
altering my mind on what I think should be *ideally* the development
process in terms of openess
and publicity.
My humble opinion only, as we said.
Best,
Antoine
OTS hash: 5c1c19f589a61787dbf483cd6814f094c3b24888d6d189c5f4d776bda558e1ce
Le mercredi 24 décembre 2025 à 17:23:48 UTC, waxwing/ AdamISZ a écrit :
Hi Greg, list:
> I think the list should adopt a 1 year ban on parties *and their*
employer(s) (if known) for any coin confiscation proposal on the list going
forward (after, of course, making the rule clear on the signup page). It's
tiresome and beyond being a waste of time risks undermining public
confidence in Bitcoin to see the constant trickle of these
outrageous proposals in venues where they previously understood that
serious discussions were to be had. People are, of course, free to discuss
whatever ill-founded concepts they want but they're not entitled to the
time and the reputation of the participants here for offensively misguided
proposals.
I'm a huge agree-er with the motivation of this comment and a huge
disagree-er with the suggestion itself.
Actual confiscation, whatever the reason, hugely undermines Bitcoin's value
to humanity - note I am not saying its financial value, but value as a
project (and if we didn't see such value what the hell are we doing here).
Of course those two types of value are very closely linked, but they are
still distinct. I hold that same belief even when we are talking about
other suggestions of confiscation, such as to address a quantum threat -
something that has recently been discussed here, extensively.
Which brings me to my disagreement, which I know is not shared by a number
of contributors here: just as it is hard to define spam on Bitcoin, it's
also very hard to define it in a discussion forum like this one. Making
suggestions which *I* think are terrible, or detrimental, on a list like
this, should never be disallowed here. Notions of motivation of
contributors (such as they are paid by such and such a company) should not
be relevant. Everything should be open to discussion which is
implementation-technical (so obviously not e.g. threats of violence or
things that bring legal liability to participants or have zero relevance to
Bitcoin's technical development) even if it's philosophy-motivated. And
blocking should be reserved either as an anti-DOS measure if volume gets
out of control, or if it brings dangers as per the previous parenthetical.
Just my opinion of course, I know that moderation of lists is not a simple
matter.
Cheers,
AdamISZ/waxwing
On Tuesday, December 23, 2025 at 10:26:16 PM UTC-3 Greg Maxwell wrote:
The 'dust threshold' isn't a consensus parameter, it's just a number pulled
out of the air that didn't seem unreasonable based on average fee
behavior. But in any particular block transactions may need no particular
fee level at all, including zero fees. And in some cases it may be very
economically advantageous to spend an output even if its face value doesn't
support it, NFT's being a one such example (although one I consider pretty
dumb).
This proposal also appears to have ignored the prior discussion
particularly where it was pointed out that 'deleting' outputs will not
achieve the goal of deleting the tokens connected to them (so won't
eliminate the incentive), or that txouts which are predictably not going to
be accessed (as this proposal claims applies to the txouts it targets)
don't have as significant performance implications (because they don't need
to be cached in ram). It also appears to be uninformed by advances like
utxotree which makes the absolute size of the txout set much less
important, but would make mass removals such as that described
here expensive. Nor has it considered that given the level of fee spending
on NFT traffic a requirement to keep it over some (reasonable) threshold
would not likely discourage it, or the fact that existent NFT outputs are
generally over the dust limit in any case (so the proposals failure to meet
the opcat proponents' delusional goals is already clear).
I think the list should adopt a 1 year ban on parties *and their*
employer(s) (if known) for any coin confiscation proposal on the list going
forward (after, of course, making the rule clear on the signup page). It's
tiresome and beyond being a waste of time risks undermining public
confidence in Bitcoin to see the constant trickle of these
outrageous proposals in venues where they previously understood that
serious discussions were to be had. People are, of course, free to discuss
whatever ill-founded concepts they want but they're not entitled to the
time and the reputation of the participants here for offensively misguided
proposals.
On Tue, Dec 23, 2025 at 6:27 PM John <johnpenn...@gmail.com> wrote:
Good evening all,
Here is a related proposal by Matteo Pellegrini
@matteopelleg
Lynx.
Abstract
This proposal introduces a periodic, consensus-enforced mechanism for
rendering UTXOs below the network's dust threshold permanently unspendable.
At each halving block, UTXOs that have remained below the dust threshold
since the previous halving become unspendable. These UTXOs become
unspendable and may be pruned from the UTXO set entirely, reducing node
storage requirements and eliminating the economic model that incentivizes
their creation.
Motivation
The Bitcoin UTXO set has grown substantially due to various factors,
including inscription protocols, spam attacks, and general dust
accumulation. Recent proposals such as "The Cat" (Non-monetary UTXO
Cleanup) by @ostrom72158
have attempted to address this by creating lists of specific UTXOs to
render unspendable, identified by external protocol indexers.
The Cat's approach has a fatal flaw: it relies on a list.
Using a curated list of "non-monetary UTXOs" introduces several problems:
1) External dependency: The Cat requires reference indexers (Ord, Stamps,
etc.) to define which UTXOs qualify. This introduces consensus-level
dependency on external, non-Bitcoin software that can change, have bugs, or
interpret protocols differently.
2) Protocol targeting: By specifically identifying inscription and stamp
outputs, the proposal makes subjective judgments about which Bitcoin uses
are legitimate. This sets a precedent for protocol-level discrimination.
3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes
workarounds. If Ordinals dust is targeted, protocols will adapt to create
dust that doesn't match the list criteria.
4) Static snapshot: A one-time list cleanup provides temporary relief but
does nothing for future UTXO accumulation.
5) Political vulnerability: Any list-based approach requires ongoing
governance decisions about what belongs on the list, creating a permanent
political attack surface.
A better approach targets the economic reality, not the use case.
UTXOs below the dust threshold are, by definition, economically irrational
to spend under normal fee conditions. The dust limit exists precisely
because spending these outputs costs more in fees than the output is worth.
These UTXOs are already "dead" in practice; this proposal simply makes that
reality explicit at the consensus layer.
By using a threshold rather than a list, Lynx:
- Requires no external indexers
- Makes no judgment about why a UTXO is small
- Applies equally to all participants
- Provides ongoing, predictable maintenance
- Removes political discretion from the process
Impact on Inscription Protocols
The typical Ordinals inscription is stored in a UTXO containing exactly 546
sats; the minimum required to meet the dust limit for P2PKH addresses and
ensure transferability across all address types. This "postage" amount is
standard across inscription tooling and marketplaces.
A threshold of 999 sats captures the vast majority of inscription UTXOs
without requiring any protocol-specific targeting. The economic model of
inscriptions depends on these dust-level UTXOs being spendable; Lynx breaks
that model through neutral, threshold-based rules rather than list-based
discrimination.
Specification
Definitions
- Dust threshold: 999 sats. Any UTXO with a value less than 999 sats is
subject to Lynx enforcement.
- Halving block: A block at height N * 210,000 where N ≥ 1.
- Snapshot block: A halving block at which the current dust threshold and
qualifying UTXOs are recorded.
- Enforcement block: The halving block following a snapshot block (i.e.,
snapshot block + 210,000 blocks).
Lynx UTXOs:
- Existed at the snapshot block
- Had a value less than 999 sats
- Remained unspent through the enforcement period (~4 years)
Consensus Rules
After activation, the following rules apply:
1) Snapshot: At each halving block H, record the set of all UTXOs with
value < 999 sats.
2) Enforcement: At halving block H + 210,000:
- Any UTXO that was in the snapshot set and remains unspent becomes
permanently unspendable
- Transactions attempting to spend these UTXOs are invalid
3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their local
UTXO set. Transactions referencing unknown outpoints are already rejected
as invalid; pruned Lynx UTXOs are simply treated as if they were already
spent.
4) Grace period: The ~4 year window between snapshot and enforcement
provides ample time for holders to consolidate sub-dust UTXOs if they wish
to preserve the value.
Activation
Activation method: TBD (Speedy Trial, BIP8, or other mechanism as
determined by community consensus)
Recommended first snapshot: The halving following activation lock-in
Rationale
Why a fixed threshold?
Using a fixed threshold of 999 sats rather than referencing the dynamic
relay dust limit provides:
- Simplicity: One number, no script-type variations, no need to query
policy settings
- Predictability: Everyone knows exactly what qualifies, forever
- Consensus clarity: No ambiguity about which outputs are affected.
Why tie to the halving?
The halving is Bitcoin's most recognized Schelling point, using it provides:
- Predictability: Everyone knows exactly when halvings occur
- Sufficient notice: ~4 years is generous warning for any cleanup action
- Aligned incentives: As block rewards decrease, fee revenue and UTXO
efficiency become more critical to network sustainability
- Natural cadence: The halving already represents a moment of network-wide
coordination
Why not a one-time cleanup?
A one-time cleanup (as proposed by The Cat) provides temporary relief but
creates no ongoing pressure against dust accumulation. Periodic enforcement:
- Establishes a permanent, predictable norm
- Removes any expectation that dust UTXOs have indefinite longevity
- Discourages business models built on dust creation
- Provides continuous UTXO set maintenance
Why pruning works without a list
A key insight enables pruning without maintaining a separate list: Bitcoin
nodes already reject transactions that reference unknown outpoints. When a
node receives a transaction spending an outpoint not in its UTXO set, it
rejects it as invalid — the node doesn't need to know why the outpoint is
missing (spent? never existed? pruned?).
After enforcement, a Lynx UTXO is functionally equivalent to a spent
output. Nodes can simply delete it from the UTXO set. Any future
transaction attempting to spend it will reference an outpoint the node
doesn't recognize, and will be rejected through existing validation logic.
This means:
- No separate "Lynx list" is required
- No new validation logic is needed
- Pruning is optional; nodes MAY keep Lynx UTXOs if they wish
- The UTXO set shrinks naturally as nodes prune
Why 999 sats?
The threshold of 999 sats is chosen because:
- Above all dust limits: Captures UTXOs at or below the dust limit for all
script types (P2PKH: 546, P2TR: 330, etc.)
- Captures all standard inscriptions: Typical inscription UTXOs contain
exactly 546 sats as "postage"; well under 999
- Simple and memorable: A clean number that's easy to communicate and
reason about
Backward Compatibility
This is a soft fork. Nodes that do not upgrade will:
- Continue to consider all historical transactions valid
- Accept blocks that exclude spends of Lynx UTXOs
- Eventually converge with upgraded nodes (as upgraded miners will not
include invalid spends)
Wallets & Services should:
- Warn users holding sub-threshold UTXOs after a snapshot block
- Provide consolidation tools during the grace period
- Update UTXO selection algorithms to deprioritize or exclude sub-threshold
outputs approaching a snapshot
Security Considerations
No confiscation
This proposal does not transfer value to any party. Sub-threshold UTXOs
become unspendable, similar to:
- Lost private keys
- Provably unspendable OP_RETURN outputs
- Satoshi's untouched coinbase rewards
The bitcoin supply cap remains unchanged; the affected outputs simply
become irrecoverable. Holders receive ~4 years notice to consolidate if
they value the sats.
Lightning Network
Some Lightning implementations create small HTLCs and dust outputs during
channel operations. Analysis is needed to determine:
- Whether current dust thresholds affect normal LN operations
- If LN implementations need adjustment before activation
- Whether channel close scenarios create sub-threshold outputs
Preliminary assessment: LN dust limits are already set conservatively above
relay dust limits, so impact should be minimal. However, this requires
verification from LN implementers.
Fixed threshold vs. future fee markets
The 999 satoshi threshold is fixed in consensus rules and does not adjust
based on fee market conditions.
This is intentional:
- A fixed threshold provides certainty for users and developers
- If fee markets change dramatically, a future soft fork could adjust the
threshold
- The ~4 year grace period allows the community to observe and adapt
If Bitcoin's fee market evolves such that 999 sats becomes economically
significant to spend, this would indicate broader success of the network;
and the community could choose to lower or eliminate the threshold through
a subsequent proposal.
Acknowledgments
This proposal builds on the problem identification in "The Cat"
(Non-monetary UTXO Cleanup) while proposing a list-free alternative
mechanism. The Cat correctly identifies UTXO bloat as a problem worth
solving; Lynx offers a more neutral solution.
https://x.com/matteopelleg/status/2000602318346334449
On Thursday, 18 December 2025 at 21:36:14 UTC-6 Greg Maxwell wrote:
I received no prior response from you, so I suspect the issue is on your
end-- since if you sent one I would normally have been directly copied.
In any case, your message makes no sense. If an output is provably
unspendable then it is unspendable. No amount of "clever steganography"
can change that. If you're imagining that perhaps they are *presumed* to
be unspendable but actually *are* spendable, then sure that would be an
issue but with any change to consensus relevant code great care must be
taken to not introduce errors. Actually *making* a consensus change would
only increase the potential for mistakes.
These costs are just another reason why this hysteria over a non-issue is
misplaced.
But in any case it is better that (any) implementations that care about
stamps put in the effort to define their exclusions in ways that are safe
than to burden everyone with a consensus change that doesn't care about it.
On Fri, Dec 19, 2025 at 1:49 AM Jonathan Voss <k98...@gmail.com> wrote:
This is my third attempt to respond to this. Idk what is going wrong here.
The problem with dropping Bitcoin Stamps UTXOs from the UTXO set without a
consensus change is that a clever use of steganography could cause one of
those otherwise unspendable outputs to be spendable, thus causing a fork
between those nodes that adopted the Stamp pruning method and those that
did not once one of those steganographic Stamps is spent. Though this is
unlikely, it is still technically possible, and I would not put it past the
denizens of the Internet to stir up trouble just for its own sake.
On Friday, December 12, 2025 at 6:49:41 PM UTC-5 Greg Maxwell wrote:
On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98...@gmail.com> wrote:
Since the Bitcoin Stamps outputs are already unspendable, it makes perfect
sense to mark and drop them from the UTXO set.
There is no consensus change involved in not storing a provably unspendable
output, it's just an implementation detail with no interoperability
implications and doesn't need a BIP. Bitcoin core has long done so for
several types of unspendable outputs, e.g. outputs over 10kb and ones
starting with OP_RETURN.
--
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/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com
<https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%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/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com
<https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%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/cf39fdca-e996-43be-ab52-573aedd619d5n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 32530 bytes --]
next prev parent reply other threads:[~2026-01-22 21:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <32f8c689-314d-4a5e-9af6-2e3e704582e6n@googlegroups.com>
[not found] ` <CAAS2fgRR77nZj3-rJo70dnxe8Lma88-C9JqdVTYfXGHRgFu3pA@mail.gmail.com>
2025-12-11 20:54 ` [bitcoindev] " Bitcoin Mechanic
2025-12-12 1:49 ` TwoLargePizzas
2025-12-13 15:02 ` Greg Maxwell
2025-12-14 1:51 ` Pepe Hodler
2025-12-15 10:35 ` Nona YoBidnes
2025-12-15 16:04 ` Greg Maxwell
2025-12-12 17:13 ` [bitcoindev] " Jonathan Voss
2025-12-12 23:40 ` Greg Maxwell
2025-12-13 3:54 ` Melvin Carvalho
2025-12-13 7:07 ` Ataraxia 009
2025-12-17 16:22 ` Jonathan Voss
2025-12-19 3:31 ` Greg Maxwell
2025-12-21 5:07 ` John
2025-12-23 19:12 ` Greg Maxwell
2025-12-24 17:19 ` waxwing/ AdamISZ
2025-12-30 14:36 ` Antoine Riard
2026-01-19 1:11 ` Pepe Hodler [this message]
2026-01-23 3:45 ` Chris Riley
2026-01-23 13:55 ` Galois Field
2026-01-22 1:14 ` Claire Ostrom
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=cf39fdca-e996-43be-ab52-573aedd619d5n@googlegroups.com \
--to=pepehodler@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