đź“… Original date posted:2015-08-03
đź“ť Original message:On 3 August 2015 at 09:38, Eric Lombrozo <elombrozo at gmail.com> wrote:
> We already have much more efficient, far more scalable systems that allow
> this kind of cooperation you speak of without the inconveniences of
> blockchains and such.
>
There is a degree of difference between cooperation in day-to-day usage of
the system and cooperation in the rare cases the system has a bug.
These incidents do, fortunately, present some of the better sides of
> humanity…but…the design of the network *broke* - and for reasons that are
> now well understood to be only worsened by larger blocks. These incidents
> are *not supposed to happen* - and if they do, it means we’ve botched
> something up and need to fix it. And by fix it, I mean fix the protocol so
> that given our best understanding of things in the present we can
> significantly reduce the potential for its occurrence in the future.
>
Distribution by consensus is inherently a fragile system. The network will
continue to break again and again as long as programmers are fallible. But
the types of bugs that occur will change over time as we learn the best
practices for maintaining the system.
The correct incentives here were not due to people potentially losing a lot
> of money. The incentives here were well-intentioned altruism. Some miners
> lost money as a result of these actions…and they didn’t put up a fight. if
> you want to design a system around the assumption that this is how all such
> incidents will be resolved, please don’t spoil this for the rest of us.
>
Altruism is a facade that hides other motivations. The party cooperating
with the miners losing money were doing so to maintain good relationships
with those miners and to make sure those miners stay within the system and
not attack it.
>
> - Eric
>
> On Aug 3, 2015, at 1:31 AM, Hector Chu <hectorchu at gmail.com> wrote:
>
> What's wrong with a little cooperation to resolve things now and then? Man
> is not an island unto himself, we compete with each other and we cooperate
> with each other occasionally if it's mutually beneficial.
>
> You said yourself that a lot of money would have been lost if the two hard
> forks cited weren't resolved - that's the correct incentives at work again.
>
> On 3 August 2015 at 09:20, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
>> 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> 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/6a96c793/attachment.html>;
Hector Chu [ARCHIVE] /
npub170…jr45x
2023-06-07 17:32:18
in reply to nevent1q…x5zr
Author Public Key
npub170s9de2ganthnna75443h70tnsn2lvmcq5365r0juk8nfa93lthqwjr45xPublished at
2023-06-07 17:32:18Event JSON
{
"id": "584fd37f40313f95a2ba6bfd06697b0d09ab4e536a4289ad405d04b3f08c37ca",
"pubkey": "f3e056e548ecd779cfbea56b1bf9eb9c26afb3780523aa0df2e58f34f4b1faee",
"created_at": 1686159138,
"kind": 1,
"tags": [
[
"e",
"cffce533907d183637b3b6f017c0882a6c0be1ca94c65db4a20ef6fee5ebd9c3",
"",
"root"
],
[
"e",
"c6ffdcfd2830bbea0c0c70eaf4172bf9c053314206235a389f11631192af2b57",
"",
"reply"
],
[
"p",
"e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f"
]
],
"content": "📅 Original date posted:2015-08-03\n📝 Original message:On 3 August 2015 at 09:38, Eric Lombrozo \u003celombrozo at gmail.com\u003e wrote:\n\n\u003e We already have much more efficient, far more scalable systems that allow\n\u003e this kind of cooperation you speak of without the inconveniences of\n\u003e blockchains and such.\n\u003e\n\nThere is a degree of difference between cooperation in day-to-day usage of\nthe system and cooperation in the rare cases the system has a bug.\n\nThese incidents do, fortunately, present some of the better sides of\n\u003e humanity…but…the design of the network *broke* - and for reasons that are\n\u003e now well understood to be only worsened by larger blocks. These incidents\n\u003e are *not supposed to happen* - and if they do, it means we’ve botched\n\u003e something up and need to fix it. And by fix it, I mean fix the protocol so\n\u003e that given our best understanding of things in the present we can\n\u003e significantly reduce the potential for its occurrence in the future.\n\u003e\n\nDistribution by consensus is inherently a fragile system. The network will\ncontinue to break again and again as long as programmers are fallible. But\nthe types of bugs that occur will change over time as we learn the best\npractices for maintaining the system.\n\nThe correct incentives here were not due to people potentially losing a lot\n\u003e of money. The incentives here were well-intentioned altruism. Some miners\n\u003e lost money as a result of these actions…and they didn’t put up a fight. if\n\u003e you want to design a system around the assumption that this is how all such\n\u003e incidents will be resolved, please don’t spoil this for the rest of us.\n\u003e\n\nAltruism is a facade that hides other motivations. The party cooperating\nwith the miners losing money were doing so to maintain good relationships\nwith those miners and to make sure those miners stay within the system and\nnot attack it.\n\n\n\u003e\n\u003e - Eric\n\u003e\n\u003e On Aug 3, 2015, at 1:31 AM, Hector Chu \u003chectorchu at gmail.com\u003e wrote:\n\u003e\n\u003e What's wrong with a little cooperation to resolve things now and then? Man\n\u003e is not an island unto himself, we compete with each other and we cooperate\n\u003e with each other occasionally if it's mutually beneficial.\n\u003e\n\u003e You said yourself that a lot of money would have been lost if the two hard\n\u003e forks cited weren't resolved - that's the correct incentives at work again.\n\u003e\n\u003e On 3 August 2015 at 09:20, Eric Lombrozo \u003celombrozo at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e There have already been two notable incidents requiring manual\n\u003e\u003e intervention and good-faith cooperation between core devs and mining pool\n\u003e\u003e operators that would have either never gotten resolved alone or would have\n\u003e\u003e ended up costing a lot of people a lot of money had no action been taken\n\u003e\u003e (March 2013 and July 2015). They were both caused by consensus disagreement\n\u003e\u003e that directly or indirectly were brought about by bigger blocks. There is\n\u003e\u003e *strong* evidence…and a great deal of theory explaining it…that links\n\u003e\u003e larger blocks with the propensity for consensus forks that require manual\n\u003e\u003e intervention.\n\u003e\u003e\n\u003e\u003e Please, can we stop saying this is merely about decentralization and\n\u003e\u003e trustlessness? The very model upon which the security of the system is\n\u003e\u003e based *broke*…as in, we were only able to recover because a few individuals\n\u003e\u003e deliberately manipulated the consensus rules to fix it manually. Shouldn’t\n\u003e\u003e we more highly prioritize fixing the issues that can lead to these\n\u003e\u003e incidents than trying to increase throughput? Increasing block size cannot\n\u003e\u003e possibly make these forking tendencies better…but it very well could make\n\u003e\u003e them worse.\n\u003e\u003e\n\u003e\u003e - Eric\n\u003e\u003e\n\u003e\u003e On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e On 3 August 2015 at 08:53, Adam Back \u003cadam at cypherspace.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Again this should not be a political or business compromise model - we\n\u003e\u003e\u003e must focus on scientific evaluation, technical requirements and\n\u003e\u003e\u003e security.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e I will assert that the block size is political because it affects nearly\n\u003e\u003e all users to some degree and not all those users are technically inclined\n\u003e\u003e or care to keep decentralisation in the current configuration as you do.\n\u003e\u003e This debate has forgotten the current and future users of Bitcoin. Most of\n\u003e\u003e them think the hit to node count in the short term preferable to making it\n\u003e\u003e expensive and competitive to transact.\n\u003e\u003e\n\u003e\u003e We all need a little faith that the system will reorganise and readjust\n\u003e\u003e after the move to big blocks in a way that still has a reasonable degree of\n\u003e\u003e decentralisation and trustlessness. The incentives of Bitcoin remain, so\n\u003e\u003e everyone's decentralised decision throughout the system, from miners,\n\u003e\u003e merchants and users, will continue to act according to those incentives.\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150803/6a96c793/attachment.html\u003e",
"sig": "01bba46bf53961ddd6830180453089dc738212bbda05714848d0d966027f9c0ec531a898fb2082b6c8d03adb328fb3f5a02fc345b7cf2c35ba1486d18abb964f"
}