📅 Original date posted:2016-11-25
📝 Original message:On Thursday, 24 November 2016 22:39:05 CET Sergio Demian Lerner via bitcoin-
dev wrote:
> Without a detailed analysis, unlimited block size seems a risky change to
> Bitcoin, to me.
What exactly do you think is a ‘change’ in bitcoin here?
The concept of proof-of-work is that the longer a chain, the higher
probability that that one will be extended for the simple reason that
another chain will have to show a higher amount of proof of work to ‘win’.
As far as I understand the document from Peter, there is no change there at
all. Only chains with more POW will win.
Or, to answer your example, miners will prefer to extend the chain with the
most POW.
The other fact stays the same as well, if you protect from reorgs by
expecting more confirmations. Nothing changes here either. The common-sense 6
confirmations for things like exchange-deposits keep having the same
security.
The basic idea that we have a 3 or 4 deep fork is a huge problem in Bitcoin.
It hasn’t happened for ages, and we like it that way. The miners like it
that way too. Its disruptive.
The is a problem that is not created by the ‘excessive block’ concept. It
does, however, provide a possible solution to this very far-fetched problem.
You should also realize that the policy of a miner is stored in the
coinbase.
That said, I’m sure there are improvements to be made to the policy that BU
uses. But since this is a node-local policy, the consensus rules are not
affected by it.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
Tom Zander [ARCHIVE] /
npub1mj…dxnq7
2023-06-07 17:54:34
in reply to nevent1q…5gcj
Author Public Key
npub1mju50kqcm07heu967fkq6h4kq666xgekc4yrldf7q52xx9vr8jnsrdxnq7Seen on
wss://relay.noswhere.comPublished at
2023-06-07 17:54:34Event JSON
{
"id": "21c15e8b7581aa236353b70069b49dfe6444950ed35efb5c063c2cff40701c6f",
"pubkey": "dcb947d818dbfd7cf0baf26c0d5eb606b5a32336c5483fb53e05146315833ca7",
"created_at": 1686160474,
"kind": 1,
"tags": [
[
"e",
"f07cece24b81ef9d4508ab160ef6f573f5931943b2ae482e0d5c9a2dc8fb8842",
"",
"root"
],
[
"e",
"86a2df760263d865b5849fbb7e9f27eed80d2e2b121e4183b6ac9a78d24038d5",
"",
"reply"
],
[
"p",
"4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee"
]
],
"content": "📅 Original date posted:2016-11-25\n📝 Original message:On Thursday, 24 November 2016 22:39:05 CET Sergio Demian Lerner via bitcoin-\ndev wrote:\n\u003e Without a detailed analysis, unlimited block size seems a risky change to\n\u003e Bitcoin, to me.\n\nWhat exactly do you think is a ‘change’ in bitcoin here?\n\nThe concept of proof-of-work is that the longer a chain, the higher \nprobability that that one will be extended for the simple reason that \nanother chain will have to show a higher amount of proof of work to ‘win’.\n\nAs far as I understand the document from Peter, there is no change there at \nall. Only chains with more POW will win.\nOr, to answer your example, miners will prefer to extend the chain with the \nmost POW.\n\nThe other fact stays the same as well, if you protect from reorgs by \nexpecting more confirmations. Nothing changes here either. The common-sense 6 \nconfirmations for things like exchange-deposits keep having the same \nsecurity.\n\nThe basic idea that we have a 3 or 4 deep fork is a huge problem in Bitcoin. \nIt hasn’t happened for ages, and we like it that way. The miners like it \nthat way too. Its disruptive.\nThe is a problem that is not created by the ‘excessive block’ concept. It \ndoes, however, provide a possible solution to this very far-fetched problem.\n\nYou should also realize that the policy of a miner is stored in the \ncoinbase.\n\nThat said, I’m sure there are improvements to be made to the policy that BU \nuses. But since this is a node-local policy, the consensus rules are not \naffected by it.\n-- \nTom Zander\nBlog: https://zander.github.io\nVlog: https://vimeo.com/channels/tomscryptochannel",
"sig": "6b335e158ef4fc6c950bfefbeda19ee2361f6c5e380d2b02b46f6f301e70f9bbf3df8a15dd09a47e049b085f4afce16d7208d18ef0db5e72eda48d5527a800aa"
}