<unnamed>

Public Key

npub16t7f9mxe6a2slagy5m9vxssf54772e2crdczpyk4c97nvletewhq0jv5ke

Profile Code

nprofile1qqsd9lyjanvaw4g075z2djkrggy62l09v4vpkupqjt2uzlfk0u4uhtspzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmc8k23j2

Publishing to

nostr.wine

relay.damus.io

Last Notes

2023-06-07 17:49:29 UTC

- reply

📅 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

2023-06-07 17:45:23 UTC

- reply

📅 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

2023-06-07 17:43:17 UTC

- reply

📅 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