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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YAEdN-00085V-Tv for bitcoin-development@lists.sourceforge.net; Sun, 11 Jan 2015 09:16:37 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of riseup.net designates 198.252.153.129 as permitted sender) client-ip=198.252.153.129; envelope-from=odinn.cyberguerrilla@riseup.net; helo=mx1.riseup.net; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YAEdN-00034Z-D9 for bitcoin-development@lists.sourceforge.net; Sun, 11 Jan 2015 09:16:33 +0000 Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 789C242246 for ; Sun, 11 Jan 2015 09:16:27 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla) with ESMTPSA id 353DE420AE Message-ID: <54B23F7F.5000408@riseup.net> Date: Sun, 11 Jan 2015 09:16:47 +0000 From: odinn MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 X-Virus-Scanned: clamav-milter 0.98.5 at mx1 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-Headers-End: 1YAEdN-00034Z-D9 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 09:16:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Please comment if possible on some of the techno-cultural implications of ongoing development of bi-directional micropayment channels? For example, consider zakat example(s): www[dot]hidaya[dot]org/publications/zakat-information/10-what-is-zakat-ob= ligatory-charity That involves a system based on trust and which is somewhat circular in nature (such funds as are going in one direction may also be going simultaneously on balance in another direction somewhere else), where the trustless bitcoin utilizes math, rather than personal trust in order to keep the system going. Here is some more on zakat: en[dot]wikipedia[dot]org/wiki/Zakat en[dot]wikipedia[dot]org/wiki/Ridda_wars (Discusses in depth some differences between Sunni and Shiite on the subject of Zakat) A sort of traditional philanthropic historic overview in the USA from the 1900s forward is seen here, but it is fairly minimal and not too revealing: www[dot]nptrust[dot]org/history-of-giving/timeline/1900s/ A general microgiving example(s) (not yet fully modeled but for which some prototype software ideas and concepts are in process today): abis[dot]io Cheers, - -O Mike Hearn: > The original design is documented at the bottom of here: >=20 > https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28mic= ro.29payments_to_a_pre-determined_party > > > >=20 In this design, time locked transactions can be broadcast across > the network and replaced by broadcasting a new transaction that=20 > uses higher sequence numbers. That's what the sequence number field > is for. It was intended to allow arbitrary high frequency trading > between a set of parties, though the "channel" notion is a simple > way to think about the two party case. >=20 > The issue is that you can broadcast transactions with a lock time=20 > far in the future to fill up memory, and keep broadcasting=20 > replacements to use up CPU time and bandwidth. >=20 > Additionally, there is a school of thought that says Bitcoin must=20 > work even if lots of miners are malicious and willing to break=20 > arbitrary things in order to try and get more money. I don't think > Bitcoin can really be a mainstream success under such a threat=20 > model, for a whole bunch of reasons (e.g. the economy relies pretty > heavily on unconfirmed transactions), but under such a threat model > there's nothing that forces miners to actually include the latest > version in the block chain. They could pick any version. In the > 2-of-2 channel model it takes both parties to sign, so clients can > enforce that all versions have the same fee attached. >=20 > I disagree with Gregory that people refuse to use protocols that=20 > are affected by malleability. There aren't any user-friendly apps=20 > that use refunds currently, so we have no idea whether people would > refuse to use them or not. It's an open question. The answer would > probably depend on the real prevalence of attacks, which is=20 > currently unknowable and likely application specific. >=20 >=20 >=20 > -----------------------------------------------------------------------= ------- > > > >=20 Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot=20 > Media, is your hub for all things parallel software development,=20 > 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 >=20 >=20 >=20 > _______________________________________________ Bitcoin-development > mailing list Bitcoin-development@lists.sourceforge.net=20 > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 - --=20 http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJUsj9+AAoJEGxwq/inSG8Cvu8H/RutYcVPdN+GrtAYxNkm2x7n v/NtBIZwGs7iN6g14Te/ynEfBQRzYwVABL+d1nEuNdlYl6IB4mCXkFrz7hlFJNgK 2WOq4iKApS1tV9MFAcaxnYy6W8z5T8VpQRqxNbbFEG145cGP2l/5CYwXOmPOBdp7 qTnLs9oVyhixcfb/piFhd/4xRvlvwxVyvCamrAXBUIpgpW/VB/kfG8ikCazvcJB6 lSY+CogSGqObjlO7PhKcsZz/gTNrSIp40upyktfqZvQxWLp4WR7+GYz7vUXoofQO Obt3ya6lZBLLL0EHYkJzAiKRy4aoIgIUzyshIHTdiQIwZC6HWnv2++sJdneng8g=3D =3D+e6h -----END PGP SIGNATURE-----