<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    I'll add fuel to the fire here, and express that I believe that
    replace-by-fee is good in the long-term.  Peter is not breaking the
    zero-conf, it was already broken, and not admitting it creates a
    false sense of security.  I don't want to see systems that are built
    on the assumption that zero-conf tx are safe solely because it has
    always appeared safe.  You can argue about rational miner behaviors
    all day, but in a decentralized system you have no idea what miners
    consider rational, or speculate about their incentives.  <br>
    <br>
    If there's one thing I learned playing poker (many years ago), was
    that always assuming your opponent is rational can lose you a lot of
    money.  You made play that, in hindsight, was terrible given what he
    actually had.  But you assumed no sane or rational person in his
    position would make such a play so you discounted it in your
    decision-making process.  You're "right" that his actions were
    terrible and irrational, but he still won your money because you
    discounted his ability to make such a "bad" play.  Here, you are
    speculating that an "opponent" uses the same
    values/motivations/rationality as yourself, and then building
    systems that depend on that being true.  Even if it "should" be true
    doesn't mean that it is true and will remain that way.  And you will
    get burned by it eventually.<br>
    <br>
    The Bitcoin network achieves something that we didnt' think was
    possible 10 years ago:  a totally trustless, decentralized ledger. 
    The cost?  It takes time for the decentralized network to reach
    consensus that transactions "happened".  That is quite literally the
    trade-off that we make: you can centralize things by putting a bank
    in the middle and getting instant confirmation, or you decentralize
    and let the network reach consensus over time without the central
    authority.   If you want instant confirmations, you're going to need
    to add centralization because Bitcoin never offered it.  I support
    efforts to dispel any such myths as soon as possible and encourage
    building robust solutions (payment channels, insured zero-conf
    services, etc.).<br>
    <br>
    -Alan<br>
    <br>
    <br>
    On 02/12/2015 07:37 PM, Allen Piscitello wrote:<br>
    <span style="white-space: pre;">&gt; You cannot close Pandora's
      box.  Whether or not this type of patch should exist is
      irrelevant.  It does, and there are incentives to use it by
      miners.  These are the bounds we have to deal with and the world
      we must adapt to.<br>
      &gt;<br>
      &gt; On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier
      &lt;<a class="moz-txt-link-abbreviated" href="mailto:justusranvier@riseup.net">justusranvier@riseup.net</a>
      <a class="moz-txt-link-rfc2396E" href="mailto:justusranvier@riseup.net">&lt;mailto:justusranvier@riseup.net&gt;</a>&gt; wrote:<br>
      &gt;</span><br>
    <blockquote type="cite">On 02/12/2015 05:24 PM, Oleg Andreev wrote:<br>
      <br>
      &gt;&gt; I think that is a misdirection on your part. The point of<br>
      &gt;&gt; replace-by-fee is to make 0-confirms reliably unreliable.<br>
      &gt;&gt; Currently people can "get away" with 0-confirms but it's
      only<br>
      &gt;&gt; because most people arent actively double spending, and
      when they<br>
      &gt;&gt; do it is for higher value targets. Double spend attacks
      are<br>
      &gt;&gt; happening a lot more frequently than is being admitted
      here,<br>
      &gt;&gt; according to Peter from work with various clients.<br>
      &gt;&gt;<br>
      &gt;&gt; Like single address reuse, people have gotten used to
      something<br>
      &gt;&gt; which is bad. Generally accepting 0-conf is also a bad
      idea(tm)<br>
      &gt;&gt; and instant confirmation solutions should be sought
      elsewhere.<br>
      &gt;&gt; There are already interesting solutions and concepts:<br>
      &gt;&gt; greenaddress for example, and CHECKLOCKTIMEVERIFY
      micropayment<br>
      &gt;&gt; channels for example. Rather than supporting and
      promoting risky<br>
      &gt;&gt; 0-confirms, we need to spend time on better alternative
      solutions<br>
      &gt;&gt; that will work for everyone and not during the honeymoon
      phase<br>
      &gt;&gt; where attackers are fewer.<br>
      <br>
      &gt; Here's value-free assessment of the issue here:<br>
      <br>
      &gt; 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer<br>
      &gt; instant payments solution if possible. 3. As a social
      artifact,<br>
      &gt; today zeroconf txs happen to work for some people in some<br>
      &gt; situations. 4. Replace-by-fee will break #3 and probably
      hasten<br>
      &gt; development of #2.<br>
      <br>
      &gt; The discussion boils down to whether we should make #2 happen<br>
      &gt; sooner by breaking remnants of #3 sooner.<br>
      <br>
      &gt; I personally would rather not break anything, but work as
      fast as<br>
      &gt; possible on #2 so no matter when and how #3 becomes utterly
      broken,<br>
      &gt; we have a better solution. This implies that I also don't
      want to<br>
      &gt; waste time debating with Peter Todd and others. I want to be
      ready<br>
      &gt; with a working tool when zeroconf completely fails (with that
      patch<br>
      &gt; or for some other reasons).<br>
      <br>
      &gt; TL;DR: those who are against the patch are better off
      building a<br>
      &gt; decentralized clearing network rather than wasting time on
      debates.<br>
      &gt; When we have such network, we might all want this patch to be
      used<br>
      &gt; for all the reasons Peter has already outlined.<br>
      <br>
      You've left out of the discussion that many (or all) proposed<br>
      solutions for 2 either reduce privacy, or security, or both.<br>
      <br>
      That fact should not be ignored or swept under the rug.<br>
      <br>
      There's also no mention of the degree to which
      child-pays-for-parent<br>
      achieves the stated aims of the original proposal (clearing
      mempool of<br>
      stuck transactions, increasing payee assurance of conformation)<br>
      without introducing incentives to double spend or forcing people
      into<br>
      privacy/security sacrifices.<br>
      <br>
      <br>
    </blockquote>
    <span style="white-space: pre;">&gt;<br>
      &gt;    
------------------------------------------------------------------------------<br>
      &gt;     Dive into the World of Parallel Programming. The Go
      Parallel Website,<br>
      &gt;     sponsored by Intel and developed in partnership with
      Slashdot Media, is your<br>
      &gt;     hub for all things parallel software development, from
      weekly thought<br>
      &gt;     leadership blogs to news, videos, case studies, tutorials
      and more. Take a<br>
      &gt;     look and join the conversation now.
      <a class="moz-txt-link-freetext" href="http://goparallel.sourceforge.net/">http://goparallel.sourceforge.net/</a><br>
      &gt;     _______________________________________________<br>
      &gt;     Bitcoin-development mailing list<br>
      &gt;     <a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
      <a class="moz-txt-link-rfc2396E" href="mailto:Bitcoin-development@lists.sourceforge.net">&lt;mailto:Bitcoin-development@lists.sourceforge.net&gt;</a><br>
      &gt;    
      <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
      &gt;<br>
      &gt;<br>
      &gt;<br>
      &gt;<br>
      &gt;
------------------------------------------------------------------------------<br>
      &gt; Dive into the World of Parallel Programming. The Go Parallel
      Website,<br>
      &gt; sponsored by Intel and developed in partnership with Slashdot
      Media, is your<br>
      &gt; hub for all things parallel software development, from weekly
      thought<br>
      &gt; leadership blogs to news, videos, case studies, tutorials and
      more. Take a<br>
      &gt; look and join the conversation now.
      <a class="moz-txt-link-freetext" href="http://goparallel.sourceforge.net/">http://goparallel.sourceforge.net/</a><br>
      &gt;<br>
      &gt;<br>
      &gt; _______________________________________________<br>
      &gt; Bitcoin-development mailing list<br>
      &gt; <a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
      &gt;
      <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a></span><br>
    <br>
    <br>
  </body>
</html>