Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Alan Reiner <etotheipi@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6724 bytes --]

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



[-- Attachment #2: Type: text/html, Size: 9193 bytes --]