1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
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 <odinn.cyberguerrilla@riseup.net>) 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 <bitcoin-development@lists.sourceforge.net>;
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 <odinn.cyberguerrilla@riseup.net>
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CAGNXQMSSCtgiyFEGHS2ufuc-RZcAtpEJyFpQMDmNKd1qEDq5qA@mail.gmail.com> <CANEZrP0ZabL2S=UhB2u7en2AfrckPk5CQe0YN-i4eDXQK-LF6A@mail.gmail.com> <CAJHLa0NoDU+DOPfubhbVs8_Y92+uGG=mZ2+ruRCXkeULghWVVg@mail.gmail.com>
<CANEZrP1H-_4XiG+Azm7M4FgLrayuML+kdQ7LineXsU3FUH6=Qw@mail.gmail.com>
In-Reply-To: <CANEZrP1H-_4XiG+Azm7M4FgLrayuML+kdQ7LineXsU3FUH6=Qw@mail.gmail.com>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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-----
|
