đź“… Original date posted:2015-08-03
📝 Original message:There have already been two notable incidents requiring manual intervention and good-faith cooperation between core devs and mining pool operators that would have either never gotten resolved alone or would have ended up costing a lot of people a lot of money had no action been taken (March 2013 and July 2015). They were both caused by consensus disagreement that directly or indirectly were brought about by bigger blocks. There is *strong* evidence…and a great deal of theory explaining it…that links larger blocks with the propensity for consensus forks that require manual intervention.
Please, can we stop saying this is merely about decentralization and trustlessness? The very model upon which the security of the system is based *broke*…as in, we were only able to recover because a few individuals deliberately manipulated the consensus rules to fix it manually. Shouldn’t we more highly prioritize fixing the issues that can lead to these incidents than trying to increase throughput? Increasing block size cannot possibly make these forking tendencies better…but it very well could make them worse.
- Eric
> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On 3 August 2015 at 08:53, Adam Back <adam at cypherspace.org <mailto:adam at cypherspace.org>> wrote:
> Again this should not be a political or business compromise model - we
> must focus on scientific evaluation, technical requirements and
> security.
>
> I will assert that the block size is political because it affects nearly all users to some degree and not all those users are technically inclined or care to keep decentralisation in the current configuration as you do. This debate has forgotten the current and future users of Bitcoin. Most of them think the hit to node count in the short term preferable to making it expensive and competitive to transact.
>
> We all need a little faith that the system will reorganise and readjust after the move to big blocks in a way that still has a reasonable degree of decentralisation and trustlessness. The incentives of Bitcoin remain, so everyone's decentralised decision throughout the system, from miners, merchants and users, will continue to act according to those incentives.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150803/3f4ddd21/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150803/3f4ddd21/attachment.sig>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 15:44:39
in reply to nevent1q…6ayq
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 15:44:39Event JSON
{
"id": "221ce847b4021e43a588c1370ebb4a84088bdcb194ffd9d47e30eea91dc27246",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686152679,
"kind": 1,
"tags": [
[
"e",
"a0c03a06bdcdda80df7b16913d2127509eac9b2435ee23077a88c0b0dffee3c6",
"",
"root"
],
[
"e",
"902c32c383836fa876410385691ae46d5191ca4287c8d24f3b8e3a1966244d85",
"",
"reply"
],
[
"p",
"f3e056e548ecd779cfbea56b1bf9eb9c26afb3780523aa0df2e58f34f4b1faee"
]
],
"content": "📅 Original date posted:2015-08-03\n📝 Original message:There have already been two notable incidents requiring manual intervention and good-faith cooperation between core devs and mining pool operators that would have either never gotten resolved alone or would have ended up costing a lot of people a lot of money had no action been taken (March 2013 and July 2015). They were both caused by consensus disagreement that directly or indirectly were brought about by bigger blocks. There is *strong* evidence…and a great deal of theory explaining it…that links larger blocks with the propensity for consensus forks that require manual intervention.\n\nPlease, can we stop saying this is merely about decentralization and trustlessness? The very model upon which the security of the system is based *broke*…as in, we were only able to recover because a few individuals deliberately manipulated the consensus rules to fix it manually. Shouldn’t we more highly prioritize fixing the issues that can lead to these incidents than trying to increase throughput? Increasing block size cannot possibly make these forking tendencies better…but it very well could make them worse.\n\n- Eric\n\n\u003e On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e On 3 August 2015 at 08:53, Adam Back \u003cadam at cypherspace.org \u003cmailto:adam at cypherspace.org\u003e\u003e wrote:\n\u003e Again this should not be a political or business compromise model - we\n\u003e must focus on scientific evaluation, technical requirements and\n\u003e security.\n\u003e \n\u003e I will assert that the block size is political because it affects nearly all users to some degree and not all those users are technically inclined or care to keep decentralisation in the current configuration as you do. This debate has forgotten the current and future users of Bitcoin. Most of them think the hit to node count in the short term preferable to making it expensive and competitive to transact.\n\u003e \n\u003e We all need a little faith that the system will reorganise and readjust after the move to big blocks in a way that still has a reasonable degree of decentralisation and trustlessness. The incentives of Bitcoin remain, so everyone's decentralised decision throughout the system, from miners, merchants and users, will continue to act according to those incentives.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150803/3f4ddd21/attachment.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150803/3f4ddd21/attachment.sig\u003e",
"sig": "2a5d636c56215968a79aa04a4e011f4fcd0ca38317c2f4f7994ebfca7424c825a7a9719c3e7653983bed2b685bab5b4662455fbcec601e487af7d2335e6ee56e"
}