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 ) 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 ; 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 (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 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> <356E7F6E-300A-4127-9885-2183FB1DE447@gmail.com> <54DCECE4.3020802@riseup.net> In-Reply-To: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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 > 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 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. 

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.

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


>
>     ------------------------------------------------------------------------------
>     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. Take a
>     look and join the conversation now. http://goparallel.sourceforge.net/
>     _______________________________________________
>     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. Take 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--