Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.170 as permitted sender)
	client-ip=209.85.223.170; envelope-from=gmaxwell@gmail.com;
	helo=mail-ie0-f170.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP0ZabL2S=UhB2u7en2AfrckPk5CQe0YN-i4eDXQK-LF6A@mail.gmail.com>
References: <CAGNXQMSSCtgiyFEGHS2ufuc-RZcAtpEJyFpQMDmNKd1qEDq5qA@mail.gmail.com>
	<CANEZrP0ZabL2S=UhB2u7en2AfrckPk5CQe0YN-i4eDXQK-LF6A@mail.gmail.com>
Date: Fri, 9 Jan 2015 13:26:14 +0000
Message-ID: <CAAS2fgTvLCs-qXONhEVdOyWJLhQzuu-s3Rff5Y3bCiAj9Rjg-w@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bi-directional micropayment channels with
	CHECKLOCKTIMEVERIFY
Precedence: list

On Fri, Jan 9, 2015 at 1:20 PM, Mike Hearn <mike@plan99.net> wrote:
>> A limitation on most existing micropayment channel ideas is that payments
>> can only flow in one direction.
> It's worth noting that the original protocol as designed by Satoshi did not
> have this limitation. It has evolved this way because of ad-hoc DoS fixes
> over time (btw I'm not saying they were the wrong thing to do, as non "ad
> hoc" solutions are significantly more work). But it seems like eventually a
> different approach to handling DoS attacks based on resource prioritisation
> and scheduling will become needed / implemented, and at that point the
> original design could be safely brought back to life.

I don't agree with your understanding.  Expecting replacement to work
and be enforced is completely unsafe. People (sanely) refuse to use
protocols which are broken by refund malleability, which is a much
narrower expectation for miners than expecting the sequence ratchet to
go one way.