<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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=""><span style="font-family: HelveticaNeue;" class="">I think that is a misdirection on your part. The point of replace-by-fee is to make 0-confirms reliably unreliable. Currently people can "get away" with 0-confirms but it's only because most people arent actively double spending, and when they do it is for higher value targets. Double spend attacks</span>&nbsp;<i class="" style="font-family: HelveticaNeue;">are</i>&nbsp;<span style="font-family: HelveticaNeue;" class="">happening a lot more frequently than is being admitted here, according to Peter from work with various clients.&nbsp;</span></div><div class=""><div style="font-family: HelveticaNeue; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: HelveticaNeue; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Like single address reuse, people have gotten used to something which is bad. Generally accepting 0-conf is also a bad idea(tm) and instant confirmation solutions should be sought elsewhere. There are already interesting solutions and concepts: greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than supporting and promoting risky 0-confirms, we need to spend time on better alternative solutions that will work for everyone and not during the honeymoon phase where attackers are fewer.</div></div></blockquote></div><br class=""><div class="">Here's value-free assessment of the issue here:</div><div class=""><br class=""></div><div class="">1. Zero-conf txs are unsafe.</div><div class="">2. We'd all want to have a safer instant payments solution if possible.</div><div class="">3. As a social artifact, today zeroconf txs happen to work for some people in some situations.</div><div class="">4. Replace-by-fee will break #3 and probably hasten development of #2.</div><div class=""><br class=""></div><div class="">The discussion boils down to whether we should make #2 happen sooner by breaking remnants of #3 sooner.</div><div class=""><br class=""></div><div class="">I personally would rather not break anything, but work as fast as possible on #2 so no matter when and how #3 becomes utterly broken, we have a better solution. This implies that I also don't want to waste time debating with Peter Todd and others. I want to be ready with a working tool when zeroconf completely fails (with that patch or for some other reasons).</div><div class=""><br class=""></div><div class="">TL;DR: those who are against the patch are better off building a decentralized clearing network rather than wasting time on debates. When we have such network, we might all want this patch to be used for all the reasons Peter has already outlined.</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>