Francisco Cabañas

My recommendation is slightly higher in the 19 to 25 range. 25 being the maximum while keeping the size of a 2 in 2 out transaction under 3000 bytes.after BP+....

First I confirm the validity and seriousness of this issue. A the most basic level, an external event can cause the short term median to fall after 51 blocks to...

Hi @UkoeHB Thanks so much for your comments and feedback. > If the former is true, then I agree it should limit long term median change to [+2x, -0.5x] over...

The proposed specification Document is https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2021.pdf Summary of the Proposal 1) Consensus Changes: a) Increase the rate of growth for the long term median from 1.4x to 2x. b) Limit...

First many thanks to @UkoeHB for your work in reviewing this proposal. Also many thanks to all those who commented and made suggestions. I updated the definition to clarify the...

It is possible to implement the proposal including the proposed fees using 1.7 and 1/1.7 rather than 2 and 1/2. This fee structure works because it is using a less...

> I ran @UkoeHB's Seraphis perf tests on my relatively medium-end-ish machine (core i7 - 1.8 GHz - 4 cores/8 threads and 32gb of RAM). I suspect this is a...

>it's not, time to verify a block is divided by 8 for number of threads If one has 1024 transactions to verify and 8 threads (virtual cores) there is no...

@UkoeHB So a factor of 8. This is at the very high end of my estimate.

One question that comes to mind is the impact of GPU verification on verification cost per tx especially with large batch sizes 25 txs, 100 txs etc. if a performance...