Pavel Janík [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-06-13 to 2016-03-02
💬 Posted a total of 7 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, BIP Draft
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:49:29

- 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:28

- reply

📅 Original date posted:2015-12-02
📝 Original message:> On 02 Dec 2015, at 00:44, Simon Liu <simon at bitcartel.com> wrote:
>
> Hi Matt/Pavel,
>
> Why is it scary/undesirable? Thanks.
Select your preferable compression library and google for it with +CVE.
E.g. in zlib:
http://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-1820/GNU-Zlib.html
…allows remote attackers to cause a denial of service (crash) via a crafted compressed stream…
…allows remote attackers to cause a denial of service (application crash)…
etc.
Do you want to expose such lib to the potential attacker?
--
Pavel Janík

2023-06-07 17:45:23

- 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

- 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

2023-06-07 17:41:51

- reply

📅 Original date posted:2015-09-29
📝 Original message:> On 29 Sep 2015, at 19:29, Mike Hearn via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> There's a simple way to cut down on "noise" that doesn't involve people shouting OFFTOPIC at each other: the maintainer needs to resolve discussions by making decisions and saying, this is how Core does it.
Looks like you are mixing the maintainer of the Bitcoin Core with the bitcoin-dev mailing list moderator. Intentionally?
--
Pavel Janík

2023-06-07 15:22:37

- reply

📅 Original date posted:2014-06-13
📝 Original message:Wladimir,
On Jun 13, 2014, at 12:18 PM, Wladimir wrote:
> If I do not hear anything, I will do a last-minute language import
this import can actually break things. I'd avoid it.
--
Pavel Janík

2023-06-07 15:22:37

- reply

📅 Original date posted:2014-06-13
📝 Original message:On Jun 13, 2014, at 1:58 PM, Wladimir wrote:
> It cannot, it is just data.
The (new) data can break user interface (at least).
--
Pavel Janík