Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.107 as permitted sender)
	client-ip=62.13.148.107; envelope-from=pete@petertodd.org;
	helo=outmail148107.authsmtp.com; 
Date: Sun, 11 Jan 2015 17:24:47 -0500
From: Peter Todd <pete@petertodd.org>
To: Nathan Cook <nathan.cook@gmail.com>
Message-ID: <20150111222447.GA15168@savin.petertodd.org>
References: <CAGNXQMSSCtgiyFEGHS2ufuc-RZcAtpEJyFpQMDmNKd1qEDq5qA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm"
Content-Disposition: inline
In-Reply-To: <CAGNXQMSSCtgiyFEGHS2ufuc-RZcAtpEJyFpQMDmNKd1qEDq5qA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Bi-directional micropayment channels with
 CHECKLOCKTIMEVERIFY
Precedence: list


--uAKRQypu60I7Lcqm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 09, 2015 at 01:40:53PM +0200, Nathan Cook wrote:

Would you mind doing up some actual scriptPubKeys/transactions using
this idea as an example? I think it'd make the review process a lot
easier for everyone if there was something more concrete. (equally,
sorry I haven't had a chance to look at this, very busy for the rest of
the month)

You may find my CLTV-using micropayment channel demo useful reference
material too:

https://github.com/petertodd/checklocktimeverify-demos/blob/master/micropay=
ment-channel.py

> A limitation on most existing micropayment channel ideas is that payments
> can only flow in one direction. This is because the payment receiver can
> sign -any- transaction you send them, not just the most recent one, and so
> it's possible to just sign the transaction transferring the largest amount
> into their control. This is easily remedied by opening a second payment
> channel in the opposite direction, but now both parties have to deposit
> funds over the lifetime of the two channels. If one party doesn't know
> ahead of time whether or not the other party will go into credit, having
> only one channel may save the use of a deposit.

--=20
'peter'[:-1]@petertodd.org
00000000000000000d41f9ac3e2a4a621769f4f077c490bf2b2a967ebfd04e42

--uAKRQypu60I7Lcqm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJUsvgqXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwZDQxZjlhYzNlMmE0YTYyMTc2OWY0ZjA3N2M0OTBiZjJi
MmE5NjdlYmZkMDRlNDIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftHPwgAsd9iha4iJDcVScp/SYXC9vsm
nz1LRP2XPhkIuOnCFHdVbuRnjJ9+bQn5ry09DswSje4+x35vdZvi8ANoFDBI1WOg
EmAYDy4XM3LuTkTGVUwPetxEia4PIFVZzWN3GxHp754qStGzg6O4+JX9nyPUoNj4
sb3RuW08ZGlhVvHDgdZG0Uut+HqEQD/cRkD4jSqntMBu9DWrtstVfeukF1rAl49p
2anjr53xSZm0yIyi5kNmQbXGtDf7/RWJxicXPWtxHavQb6CP0MQlI7aBCJLdP8Gw
WABgBIqli0JMFSwdGtb8MZ5/wSxxSM0oXbMHmax9JR5AbFLohoNQrrR5DANr4Q==
=EDnU
-----END PGP SIGNATURE-----

--uAKRQypu60I7Lcqm--