From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YAQwO-0003Y4-V7 for bitcoin-development@lists.sourceforge.net; Sun, 11 Jan 2015 22:25:00 +0000 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; Received: from outmail148107.authsmtp.com ([62.13.148.107]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YAQwM-00053w-B1 for bitcoin-development@lists.sourceforge.net; Sun, 11 Jan 2015 22:25:00 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t0BMOpZf065417; Sun, 11 Jan 2015 22:24:51 GMT Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t0BMOlwv032309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 11 Jan 2015 22:24:50 GMT Date: Sun, 11 Jan 2015 17:24:47 -0500 From: Peter Todd To: Nathan Cook Message-ID: <20150111222447.GA15168@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: a897091f-99e0-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwMUElQaAgsB AmMbWVZeUll7XGM7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRxz e2FCFV9ydAdFeHc+ bUBlWD4KVE19dU98 FFNdHDgGeGZhPWQC WRZfcx5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4hH3sw RgoPFikuGksMQ202 Lhc8LUYVDUMcNFl6 OlsoX1QVNwRaFQxC HyMFKw90DHolYAEI MSJ/cHAzKhxzcE8C X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1YAQwM-00053w-B1 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY 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: Sun, 11 Jan 2015 22:25:01 -0000 --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--