📅 Original date posted:2013-03-13
📝 Original message:On Wednesday, March 13, 2013 5:41:29 PM you wrote:
> I'm not sure I understand the need for hard forks. We can get through this
> crisis by mining pool collusion to prevent forking blocks until there is
> widespread adoption of patched clients.
Anything requiring widespread adoption of patched clients *is by definition* a
hard fork.
> Proposal:
>
> 1) Patch the pre-0.8 branches to support an increased lock count, whatever
> number is required to make sure that this problem never shows up again at
> the current block size (I defer to Luke-Jr and gmaxwell's numbers on this).
This is a hard fork.
The only way to avoid a hard fork is to apply the existing lock limit to all
clients forever. That would be fine, except that pre-0.8 clients cannot reorg
N blocks without dividing that limit by (N * 2) + 1; that leaves us with the
limit of around 1000 locks per block on average. Each transaction uses at
least 3 locks on average (many times more). So about 300 transactions per
block. This is a much smaller limit than the 1 MB we've been assuming is the
bottleneck so far, and the need to increase it is much more urgent - as Pieter
noted on IRC, we are probably already using more than that even ignoring DP
spam. The only reason pre-0.8 clients have survived as well as they have thus
far is because the blockchain has managed to avoid very deep reorgs.
Luke
Luke-Jr [ARCHIVE] /
npub1dt…u7wrs
2023-06-07 11:38:55
in reply to nevent1q…qzz9
Author Public Key
npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrsPublished at
2023-06-07 11:38:55Event JSON
{
"id": "44c58df66daef24f7395cc0d3734876bbf4434bfdd8039706a9b06e095646a8c",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686137935,
"kind": 1,
"tags": [
[
"e",
"02fd249c82d4dd10181a617a5dadf9d8b2d27a405e04f833fafa551fe0bc94b8",
"",
"root"
],
[
"e",
"cce16b660ea698c707bc2eaa1f5697070261dcdcb1fe522722c402ff55c8f781",
"",
"reply"
],
[
"p",
"6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1"
]
],
"content": "📅 Original date posted:2013-03-13\n📝 Original message:On Wednesday, March 13, 2013 5:41:29 PM you wrote:\n\u003e I'm not sure I understand the need for hard forks. We can get through this\n\u003e crisis by mining pool collusion to prevent forking blocks until there is\n\u003e widespread adoption of patched clients.\n\nAnything requiring widespread adoption of patched clients *is by definition* a \nhard fork.\n\n\u003e Proposal:\n\u003e \n\u003e 1) Patch the pre-0.8 branches to support an increased lock count, whatever\n\u003e number is required to make sure that this problem never shows up again at\n\u003e the current block size (I defer to Luke-Jr and gmaxwell's numbers on this).\n\nThis is a hard fork.\n\nThe only way to avoid a hard fork is to apply the existing lock limit to all \nclients forever. That would be fine, except that pre-0.8 clients cannot reorg \nN blocks without dividing that limit by (N * 2) + 1; that leaves us with the \nlimit of around 1000 locks per block on average. Each transaction uses at \nleast 3 locks on average (many times more). So about 300 transactions per \nblock. This is a much smaller limit than the 1 MB we've been assuming is the \nbottleneck so far, and the need to increase it is much more urgent - as Pieter \nnoted on IRC, we are probably already using more than that even ignoring DP \nspam. The only reason pre-0.8 clients have survived as well as they have thus \nfar is because the blockchain has managed to avoid very deep reorgs.\n\nLuke",
"sig": "d93adc5ceea87087418e165a7b12ffa0e22cfdf70696800ec88abdfa6228ecd19cc1a22eb747697605a392973b3c78d3d3a1372d1d5f05a8f10222f106598e0d"
}