path: root/be/480cec49e533bb29046e5df4957a3da9f653ba

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <etotheipi@gmail.com>) id 1YLzEF-0005m1-NE
	for bitcoin-development@lists.sourceforge.net;
	Thu, 12 Feb 2015 19:15:11 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.49 as permitted sender)
	client-ip=209.85.215.49; envelope-from=etotheipi@gmail.com;
	helo=mail-la0-f49.google.com; 
Received: from mail-la0-f49.google.com ([209.85.215.49])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YLzED-0006c7-P2
	for bitcoin-development@lists.sourceforge.net;
	Thu, 12 Feb 2015 19:15:11 +0000
Received: by labgq15 with SMTP id gq15so12219171lab.6
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 12 Feb 2015 11:15:03 -0800 (PST)
X-Received: by 10.112.92.204 with SMTP id co12mr4688743lbb.43.1423768503319;
	Thu, 12 Feb 2015 11:15:03 -0800 (PST)
Received: from [192.168.48.173] (static-212-247-176-200.cust.tele2.se.
	[212.247.176.200])
	by mx.google.com with ESMTPSA id j9sm936924lbp.7.2015.02.12.11.15.01
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 12 Feb 2015 11:15:02 -0800 (PST)
Message-ID: <54DCFBB5.3080202@gmail.com>
Date: Thu, 12 Feb 2015 20:15:01 +0100
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <20150212064719.GA6563@savin.petertodd.org>	<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>	<CAE28kUQ87jWhq1p6RK1eKEuEP1ERxN_P2SS0=YsFEGAqRyMPLA@mail.gmail.com>	<CANEZrP2H2T2QFZceCc=YzwwiApJy7kY7FN0LoAZODGbW12SYsw@mail.gmail.com>	<CAE28kURa8g3YTPi-GHKAt4v0csxXe=QhGhV3aQcDZGSr=Lb7RQ@mail.gmail.com>	<CANEZrP2hAUsRfeXUo-DLiiRmG5uJcwFuP4=o1S6Fb7ts5Ud=bw@mail.gmail.com>	<CADJgMztrzMh8=Y6SD-JV1hpTTbGB8Y2u=59bQhGtF6h3+Ei_Ew@mail.gmail.com>	<356E7F6E-300A-4127-9885-2183FB1DE447@gmail.com>	<54DCECE4.3020802@riseup.net>
	<CAJfRnm4OBEJPW-6CiY5fQ1kUYppDnTtZfLF_YpBEaB8ovzx9og@mail.gmail.com>
In-Reply-To: <CAJfRnm4OBEJPW-6CiY5fQ1kUYppDnTtZfLF_YpBEaB8ovzx9og@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------000106090506080900010408"
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(etotheipi[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YLzED-0006c7-P2
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2015 19:15:11 -0000

This is a multi-part message in MIME format.
--------------000106090506080900010408
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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.=20

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.=20
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.=20
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.

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.).

-Alan


On 02/12/2015 07:37 PM, Allen Piscitello wrote:
> You cannot close Pandora's box.  Whether or not this type of patch shou=
ld 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.
>
> On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier
<justusranvier@riseup.net <mailto:justusranvier@riseup.net>> wrote:
>
> On 02/12/2015 05:24 PM, Oleg Andreev wrote:
>
> >> 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 are
> >> happening a lot more frequently than is being admitted here,
> >> according to Peter from work with various clients.
> >>
> >> 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.
>
> > Here's value-free assessment of the issue here:
>
> > 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer
> > instant payments solution if possible. 3. As a social artifact,
> > today zeroconf txs happen to work for some people in some
> > situations. 4. Replace-by-fee will break #3 and probably hasten
> > development of #2.
>
> > The discussion boils down to whether we should make #2 happen
> > sooner by breaking remnants of #3 sooner.
>
> > 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).
>
> > 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.
>
> You've left out of the discussion that many (or all) proposed
> solutions for 2 either reduce privacy, or security, or both.
>
> That fact should not be ignored or swept under the rug.
>
> There's also no mention of the degree to which child-pays-for-parent
> achieves the stated aims of the original proposal (clearing mempool of
> stuck transactions, increasing payee assurance of conformation)
> without introducing incentives to double spend or forcing people into
> privacy/security sacrifices.
>
>
>
>   =20
-------------------------------------------------------------------------=
-----
>     Dive into the World of Parallel Programming. The Go Parallel Websit=
e,
>     sponsored by Intel and developed in partnership with Slashdot
Media, is your
>     hub for all things parallel software development, from weekly thoug=
ht
>     leadership blogs to news, videos, case studies, tutorials and
more. Take a
>     look and join the conversation now. http://goparallel.sourceforge.n=
et/
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists.sourceforge.net
<mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
-------------------------------------------------------------------------=
-----
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media,
is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Tak=
e a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--------------000106090506080900010408
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<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>

--------------000106090506080900010408--