Good morning Pieter,
> Indeed - UTXO set size is an externality that unfortunately Bitcoin's
> consensus rules fail to account
> for. Having a relay policy that avoids at the very least economically
> irrational behavior makes
> perfect sense to me.
>
> It's also not obvious how consensus rules
Proof of stake systems attempt to create red light - green light types of
things with non-gameable attributes (eg collaborative random numbers). This
can't be done with mining because mining is completely random - its not
possible to know which miner will mine a block. If it were, it wouldn't be
pr
Good morning shymaa,
> The suggested idea I was replying to is to make all dust TXs invalid by some
> nodes.
Is this supposed to be consensus change or not?
Why "some" nodes and not all?
I think the important bit is for full nodes.
Non-full-nodes already work at reduced security; what is import
The suggested idea I was replying to is to make all dust TXs invalid by
some nodes. I suggested a compromise by keeping them in secondary storage
for full nodes, and in a separate Merkle Tree for bridge servers.
-In bridge servers they won't increase any worstcase, on the contrary this
will enhance
If u allow me to discuss,,,
I previously suggested storing dust UTXOS in a separate Merkle tree or
strucutre in general if we are talking about the original set.
I'm a kind of person who doesn't like to throw any thing; if it's not
needed now keep it in the basement for example.
So, if dust UTXOS m
