Pregunta 7

fees: Introduce Mempool Based Fee Estimation to reduce overestimati...

Kepler 18/06/2026 10:13
Pregunta 7: En el commit ff51bb2 se añade una caché para el mempoolfeerateestimator. ¿Por qué es importante tener esta caché? ¿Qué condiciones hacen que se vuelva a calcular de nuevo?
25/06/2026 17:49
Vamos con las preguntas de la caches!
nebula 25/06/2026 17:50
Como ha dicho anteriormente @Pol Espinasa , para evitar espamear el algoritmo de estimacion.
Cuando el cache tiene mas de 7 segundos o llega un nuevo bloque se vuelve a calcular.
👍 2
Kepler 25/06/2026 17:51
Correcto!
Pol Espinasa 25/06/2026 17:51
Yes!
Kepler 25/06/2026 17:51
Asi se evita ir generando bloques templates
👍 1
Pol Espinasa 25/06/2026 17:51
@nebula porque no queremos calcular el algoritmo? Porque es un problema?
Pol Espinasa 25/06/2026 17:52
yes
👍 1
25/06/2026 17:52
bueno no se si entera, pero mirar la mempool siempre es caro
25/06/2026 17:53
y hay unos cuantos locks que bloquean otras partes del codigo
arejula27 25/06/2026 17:53
Aquí se podría mirar de optimizar a seccionar la mempool, solo evaluar la parte que ha cambiado
25/06/2026 17:53
Cluster memoool creo que va un poco por ahi
sadeeq_ 25/06/2026 17:54
Sin el retraso de la caché, puedes limitar el uso de cs_main bombardeando estimatesmartfee.
👍 2
arejula27 25/06/2026 17:54
Cs_main hace demasiado, lo veo todo el rato 😭
😂 1
Pol Espinasa 25/06/2026 17:55
para dar contexto cs_main es un mutex que quieres bloquear el minimo tiempo possible
👍 2
arejula27 25/06/2026 17:55
(menos validar firmas, para eso tenemos workers dedicados)
sadeeq_ 25/06/2026 17:55
Hay un trabajo paralelo que estoy desarrollando que te permite aumentar la tasa de tarifa de detech en el bloque superior y regenerarla solo cuando hay suficiente entrada, pero aún así necesitas un retraso.
🔥 1 👀 2