Nostr notes by

📅 Original date posted:2016-03-02 📝 Original message:> ...

2023-06-07T17:49:29Z

In reply to nevent1q…szts
_________________________

📅 Original date posted:2016-03-02
📝 Original message:> the network. This would result in a significantly longer block interval, which
> also means a higher per-block transaction volume, which could cause the block
> size limit to legitimately be hit much sooner than expected.

If this happens at all (the exchange rate of the coin can accomodate such expectation), the local fee market will develop, fees will raise and complement mined coins, thus bringing more miners back to the game (together with expected higher exchange rate).
--
Pavel Janík

📅 Original date posted:2015-12-01 📝 Original message:> ...

2023-06-07T17:45:23Z

In reply to nevent1q…e3sv
_________________________

📅 Original date posted:2015-12-01
📝 Original message:> On 01 Dec 2015, at 06:28, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I'm really not a fan of this at all. To start with, adding a compression library that is directly accessible to the network on financial software is a really, really scary idea.

I have the same opinion.

On the other hand, I can imagine using compression on local blocks storage (be it compressed filesystem, or compression in the user space/in the application - compare with https://github.com/bitcoin/bitcoin/issues/2278). Now that we support pruning and obfuscating, this could be another option. Saving ~20% can be interesting in some usecases.
--
Pavel Janík

📅 Original date posted:2015-10-14 📝 Original message:> I ...

2023-06-07T17:43:17Z

In reply to nevent1q…tlsh
_________________________

📅 Original date posted:2015-10-14
📝 Original message:> I just noticed that several of my running bitcoind processes were using around 3+ GB of RAM, even though the mempool itself seemed to be under control.
>
> XXXX at prime:~/bin$ ./bitcoin-cli getmempoolinfo
> {
> "size" : 1896,
> "bytes" : 37341328
> }
>
> [total memory usage not shown -- I restarted bitcoind as soon as I noticed, and didn't copy it down from top]

The newer versions contain much more accurate reporting of memorypool usage that reflect the real memory usage:

{
"size": 58536,
"bytes": 770044257,
"usage": 1652554832
}

See PR #6410 (Implement accurate memory accounting for mempool).
--
Pavel Janík