<oembed><type>rich</type><version>1.0</version><author_name>npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9</author_name><author_url>https://nostr.ae/npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2017-07-11&#xA;📝 Original message:Pieter,&#xA;&#xA;I think that you have misrepresented Chris&#39; view by taking it out of&#xA;context. His complete quote reads &#34;If drivechains are successful they&#xA;should be viewed as the way we scale -- not hard forking the protocol.&#34;&#xA;Chris is comparing Drivechains/sidechains to a hard fork.&#xA;&#xA;You went on to &#34;disagree&#34;, but every point of contention you introduced&#xA;was something that would apply to both drivechain-sourced capacity and&#xA;hardfork-sourced capacity. Neither improves scalability, and both allow&#xA;users only the opportunity to select a different security model. If I&#xA;understand you, the point at which a security model does not become&#xA;&#34;interesting&#34; to you, would be the exact same point in the drivechain&#xA;and hardfork worlds. Both, at any rate, have the same effect on&#xA;&#34;validation cost to auditors&#34;.&#xA;&#xA;The only true difference is the &#34;extra risk of miners being able to vote&#xA;to steal your money&#34;, but as I have pointed out on this mailing list&#xA;several times, I do not actually believe that there is any marginal risk&#xA;-- miners can already &#34;vote to steal your money&#34; in the double-spend and&#xA;ln-channel-theft contexts. I have also argued that the &#34;risk&#34; is&#xA;actually desirable in an opt-in context, because it puts the burden of&#xA;proof on miners/developers (to convince users that they should move over&#xA;to the sidechain). Since their sidechain coins cannot appreciate in&#xA;value relative to the mainchain coins, users would only opt-in if they&#xA;felt that they were sufficiently compensated for any and all risks.&#xA;Hence, it is difficult to list this item as a drawback when, to the&#xA;user, it is a strict improvement (at least, by any epistemological&#xA;standard that I can think of). If you have new objections to these&#xA;claims, I&#39;m sure we would all benefit from hearing them, myself most of all.&#xA;&#xA;Paul&#xA;&#xA;&#xA;On 7/11/2017 4:01 PM, Pieter Wuille wrote:&#xA;&gt; On Jul 11, 2017 09:18, &#34;Chris Stewart via bitcoin-dev&#34;&#xA;&gt; &lt;bitcoin-dev at lists.linuxfoundation.org&#xA;&gt; &lt;mailto:bitcoin-dev at lists.linuxfoundation.org&gt;&gt; wrote:&#xA;&gt;&#xA;&gt;     Concept ACK.&#xA;&gt;&#xA;&gt;     If drivechains are successful they should be viewed as the way we&#xA;&gt;     scale&#xA;&gt;&#xA;&gt;&#xA;&gt; I strongly disagree with that statement.&#xA;&gt;&#xA;&gt; Drivechains, and several earlier sidechains ideas, are not a&#xA;&gt; scalability improvement, but merely enabling users to opt-in for&#xA;&gt; another security model.&#xA;&gt;&#xA;&gt; While obviously any future with wider adoption will need different&#xA;&gt; technologies that have different trade-offs, and anyone is free to&#xA;&gt; choose their security model, I don&#39;t think this particular one is&#xA;&gt; interesting. In terms of validation cost to auditors, it is as bad as&#xA;&gt; just a capacity increase on chain, while simultaneously adding the&#xA;&gt; extra risk of miners being able to vote to steal your money.&#xA;&gt;&#xA;&gt; Cheers,&#xA;&gt;&#xA;&gt; -- &#xA;&gt; Pieter&#xA;&gt;&#xA;&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/3fa37fbd/attachment.html&gt;</html></oembed>