馃搮 Original date posted:2013-03-12
馃摑 Original message:A related question...some people mentioned yesterday on #bitcoin-dev
that 0.5 appeared to be compatible with 0.8.
Was that only for the "fatal block" and would have forked 0.8 later
too or is it something else?
I'm having a hard time understanding this 0.5 thing, if someone can
bring some light to it I would appreciate it.
Thanks in advance
On 3/12/13, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> On Tue, Mar 12, 2013 at 11:13:09AM +0100, Michael Gronager wrote:
>> Yes, 0.7 (yes 0.7!) was not sufficiently tested it had an undocumented and
>> unknown criteria for block rejection, hence the upgrade went wrong.
>
> We're using "0.7" as a short moniker for all clients, but this was a
> limitation that all
> BDB-based bitcoins ever had. The bug is simply a limit in the number of lock
> objects
> that was reached.
>
> It's ironic that 0.8 was supposed to solve all problems we had due to BDB
> (except the
> wallet...), but now it seems it's still coming back to haunt us. I really
> hated telling
> miners to go back to 0.7, given all efforts to make 0.8 signficantly more
> tolerable...
>
>> More space in the block is needed indeed, but the real problem you are
>> describing is actually not missing space in the block, but proper handling
>> of mem-pool transactions. They should be pruned on two criteria:
>>
>> 1. if they gets to old >24hr
>> 2. if the client is running out of space, then the oldest should probably
>> be pruned
>>
>> clients are anyway keeping, and re-relaying, their own transactions and
>> hence it would mean only little, and only little for clients. Dropping
>> free / old transaction is a much a better behavior than dying... Even a
>> scheme where the client dropped all or random mempool txes would be a
>> tolerable way of handling things (dropping all is similar to a restart,
>> except for no user intervention).
>
> Right now, mempools are relatively small in memory usage, but with small
> block sizes,
> it indeed risks going up. In 0.8, conflicting (=double spending)
> transactions in the
> chain cause clearing the mempool of conflicts, so at least the mempool is
> bounded by
> the size of the UTXO subset being spent. Dropping transactions from the
> memory pool
> when they run out of space seems a correct solution. I'm less convinced
> about a
> deterministic time-based rule, as that creates a double spending incentive
> at that
> time, and a counter incentive to spam the network with your
> risking-to-be-cleared
> transaction as well.
>
> Regarding the block space, we've seen the pct% of one single block chain
> space consumer
> grow simultaneously with the introduction of larger blocks, so I'm not
> actually convinced
> there is right now a big need for larger blocks (note: right now). The
> competition for
> block chain space is mostly an issue for client software which doesn't deal
> correctly
> with non-confirming transactions, and misleading users. It's mostly a
> usability problem
> now, but increasing block sizes isn't guaranteed to fix that; it may just
> make more
> space for spam.
>
> However, the presence of this bug, and the fact that a full solution is
> available (0.8),
> probably helps achieving consensus fixing it (=a hardfork) is needed, and we
> should take
> advantage of that. But please, let's not rush things...
>
> --
> Piter
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jorge Tim贸n
http://freico.in/
http://archive.ripple-project.org/
Jorge Tim贸n [ARCHIVE] /
npub1fx鈥l2d8
2023-06-07 11:37:19
in reply to nevent1q鈥rh2
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 11:37:19Event JSON
{
"id": "121158be705c18a4334537a00ec9b336ae1e67d4d12e913ece6abc5f6d520c0d",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686137839,
"kind": 1,
"tags": [
[
"e",
"bf6db92ac74ed2040908c22a007eaccc4dacca3e534709bcb8876ea849933631",
"",
"root"
],
[
"e",
"7e410f207a5308d630e03baa0f3a15075fe588f4fb0a73954b02a388086f60f8",
"",
"reply"
],
[
"p",
"9e3c76fd7eb862ca37f150391debc7baa4f8423eaa3f894c476a7d4360de9a02"
]
],
"content": "馃搮 Original date posted:2013-03-12\n馃摑 Original message:A related question...some people mentioned yesterday on #bitcoin-dev\nthat 0.5 appeared to be compatible with 0.8.\nWas that only for the \"fatal block\" and would have forked 0.8 later\ntoo or is it something else?\nI'm having a hard time understanding this 0.5 thing, if someone can\nbring some light to it I would appreciate it.\n\nThanks in advance\n\nOn 3/12/13, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e wrote:\n\u003e On Tue, Mar 12, 2013 at 11:13:09AM +0100, Michael Gronager wrote:\n\u003e\u003e Yes, 0.7 (yes 0.7!) was not sufficiently tested it had an undocumented and\n\u003e\u003e unknown criteria for block rejection, hence the upgrade went wrong.\n\u003e\n\u003e We're using \"0.7\" as a short moniker for all clients, but this was a\n\u003e limitation that all\n\u003e BDB-based bitcoins ever had. The bug is simply a limit in the number of lock\n\u003e objects\n\u003e that was reached.\n\u003e\n\u003e It's ironic that 0.8 was supposed to solve all problems we had due to BDB\n\u003e (except the\n\u003e wallet...), but now it seems it's still coming back to haunt us. I really\n\u003e hated telling\n\u003e miners to go back to 0.7, given all efforts to make 0.8 signficantly more\n\u003e tolerable...\n\u003e\n\u003e\u003e More space in the block is needed indeed, but the real problem you are\n\u003e\u003e describing is actually not missing space in the block, but proper handling\n\u003e\u003e of mem-pool transactions. They should be pruned on two criteria:\n\u003e\u003e\n\u003e\u003e 1. if they gets to old \u003e24hr\n\u003e\u003e 2. if the client is running out of space, then the oldest should probably\n\u003e\u003e be pruned\n\u003e\u003e\n\u003e\u003e clients are anyway keeping, and re-relaying, their own transactions and\n\u003e\u003e hence it would mean only little, and only little for clients. Dropping\n\u003e\u003e free / old transaction is a much a better behavior than dying... Even a\n\u003e\u003e scheme where the client dropped all or random mempool txes would be a\n\u003e\u003e tolerable way of handling things (dropping all is similar to a restart,\n\u003e\u003e except for no user intervention).\n\u003e\n\u003e Right now, mempools are relatively small in memory usage, but with small\n\u003e block sizes,\n\u003e it indeed risks going up. In 0.8, conflicting (=double spending)\n\u003e transactions in the\n\u003e chain cause clearing the mempool of conflicts, so at least the mempool is\n\u003e bounded by\n\u003e the size of the UTXO subset being spent. Dropping transactions from the\n\u003e memory pool\n\u003e when they run out of space seems a correct solution. I'm less convinced\n\u003e about a\n\u003e deterministic time-based rule, as that creates a double spending incentive\n\u003e at that\n\u003e time, and a counter incentive to spam the network with your\n\u003e risking-to-be-cleared\n\u003e transaction as well.\n\u003e\n\u003e Regarding the block space, we've seen the pct% of one single block chain\n\u003e space consumer\n\u003e grow simultaneously with the introduction of larger blocks, so I'm not\n\u003e actually convinced\n\u003e there is right now a big need for larger blocks (note: right now). The\n\u003e competition for\n\u003e block chain space is mostly an issue for client software which doesn't deal\n\u003e correctly\n\u003e with non-confirming transactions, and misleading users. It's mostly a\n\u003e usability problem\n\u003e now, but increasing block sizes isn't guaranteed to fix that; it may just\n\u003e make more\n\u003e space for spam.\n\u003e\n\u003e However, the presence of this bug, and the fact that a full solution is\n\u003e available (0.8),\n\u003e probably helps achieving consensus fixing it (=a hardfork) is needed, and we\n\u003e should take\n\u003e advantage of that. But please, let's not rush things...\n\u003e\n\u003e --\n\u003e Piter\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester\n\u003e Wave(TM): Endpoint Security, Q1 2013 and \"remains a good choice\" in the\n\u003e endpoint security space. For insight on selecting the right partner to\n\u003e tackle endpoint security challenges, access the full report.\n\u003e http://p.sf.net/sfu/symantec-dev2dev\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\n\n-- \nJorge Tim贸n\n\nhttp://freico.in/\nhttp://archive.ripple-project.org/",
"sig": "4cce43912127157146382570020964405ff0ba662ad5b7b58575af70bc576eebb848514a1d0436aa390d8f1f865fa7ff028dcf59326a378fa9573e7dea6c6b0e"
}