tevador

> Basically, all outputs older than a certain block height can be totally forgotten by nodes That's not entirely true. Historical transactions are needed for chain verification. Otherwise you can't...

> Putting a subaddress hash on every output will clearly publicly identify the relationship between outputs arriving at the same subaddress (but not to the same wallet). I find it...

I can now see some merit to this proposal. A few observations about the revised protocol: > there should not be these type of hashes on change outputs, in order...

I have implemented a proof-of-concept blockchain data selector. It turns out that selecting random blockchain data is more complicated than I thought when writing this proposal. Firstly, we should clarify...

After some discussion with @hyc on IRC, it seems that the low performance of the data selector is not caused by the database file fragmentation per se. The problem might...

@minexmr2 Your "solution" doesn't remove the pool operator's ability to use the pool hashrate for malicious purposes. So it doesn't actually solve anything.

> prove MineXMR2 is indeed running open source code Such a proof would be of little value. Since the pool admin is in control of the server, they can deploy...

I haven't studied Seraphis in detail, but I'm wondering if there could also be another option: |Type|    Tier 1| Tier 2 (+ Tier 1)| Tier 3 (+ Tiers 1 &...

There is no doubt that Seraphis will bring quite large user-facing changes regardless of which exact addressing scheme is used. It may be worthwhile to take this opportunity to rethink...

> @tevador I like payment requests, but if LN has taught us anything its that people want both payment requests _AND_ a short, offline string they can pass around (lnurl)....