<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 3, 2015, at 1:52 AM, Hector Chu <<a href="mailto:hectorchu@gmail.com" class="">hectorchu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On 3 August 2015 at 09:38, Eric Lombrozo <span dir="ltr" class=""><<a href="mailto:elombrozo@gmail.com" target="_blank" class="">elombrozo@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>If it’s an as-of-yet unidentified issue that comes up, yes…obviously we can’t plan for everything and we’ll make some mistakes. But here we’re talking about specific well-known issues (or at least well-known today) for which several people have proposed potential solutions. However, these things have been all but ignored in the public discourse.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><div><br class=""></div>I agree. But again, once we’ve identified specific issues, it is irresponsible to continue to pretend they don’t exist…and to more highly prioritize changes that can only make the problem worse.</div><div><br class=""></div><div>Again, for the record, I am not against ultimately allowing bigger blocks. I think it would be a good thing to be able to do this…and my main concerns are not around things like equipment costs or typical household bandwidth. I just think security is a more important feature than greater throughput and prioritize it thusly.<br class=""><div><br class=""></div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">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.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><div><br class=""></div>I don’t disagree…clearly even the miners that lost money believed that consensus was more valuable to them than a few bitcoins. However, it seems to be EXTREMELY dangerous to assume that it will always work out this way. What’s to stop a mining majority from deciding on-the-fly they want to keep a particular consensus rule that benefits them even if the core developers disagree?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""></div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">- Eric</div></font></span><div class=""><div class="h5"><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 3, 2015, at 1:31 AM, Hector Chu <<a href="mailto:hectorchu@gmail.com" target="_blank" class="">hectorchu@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">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.</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On 3 August 2015 at 09:20, Eric Lombrozo <span dir="ltr" class=""><<a href="mailto:elombrozo@gmail.com" target="_blank" class="">elombrozo@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">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.<div class=""><br class=""></div><div class="">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.</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">- Eric</div></font></span><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" class="">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On 3 August 2015 at 08:53, Adam Back <span dir="ltr" class=""><<a href="mailto:adam@cypherspace.org" target="_blank" class="">adam@cypherspace.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Again this should not be a political or business compromise model - we<br class="">
must focus on scientific evaluation, technical requirements and<br class="">
security.<br class=""></blockquote><div class=""><br class=""></div>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.</div><div class="gmail_quote"><br class=""></div><div class="gmail_quote">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.</div></div></div></div></div><span class="">
_______________________________________________<br class="">bitcoin-dev mailing list<br class=""><a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" class="">bitcoin-dev@lists.linuxfoundation.org</a><br class=""><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank" class="">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=""></span></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>