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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <joel.kaartinen@gmail.com>) id 1RIdqw-0000i5-2w
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Oct 2011 10:03:26 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.47 as permitted sender)
client-ip=209.85.214.47; envelope-from=joel.kaartinen@gmail.com;
helo=mail-bw0-f47.google.com;
Received: from mail-bw0-f47.google.com ([209.85.214.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RIdqq-0002qv-Hz
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Oct 2011 10:03:25 +0000
Received: by bkat8 with SMTP id t8so343223bka.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 25 Oct 2011 03:03:14 -0700 (PDT)
Received: by 10.204.154.203 with SMTP id p11mr19931314bkw.36.1319536994158;
Tue, 25 Oct 2011 03:03:14 -0700 (PDT)
Received: from [10.55.6.70] (agw-sparknet.utu.fi. [130.232.202.233])
by mx.google.com with ESMTPS id e14sm27011200bka.0.2011.10.25.03.03.10
(version=SSLv3 cipher=OTHER); Tue, 25 Oct 2011 03:03:13 -0700 (PDT)
From: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
To: Jan Vornberger <jan@uos.de>
In-Reply-To: <44190.134.106.52.172.1319535941.squirrel@webmail.uni-osnabrueck.de>
References: <44190.134.106.52.172.1319535941.squirrel@webmail.uni-osnabrueck.de>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 25 Oct 2011 13:03:04 +0300
Message-ID: <1319536985.27400.34.camel@mei>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.6 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(joel.kaartinen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1RIdqq-0002qv-Hz
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Determine input addresses of a transaction
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: Tue, 25 Oct 2011 10:03:26 -0000
On Tue, 2011-10-25 at 11:45 +0200, Jan Vornberger wrote:
> 1) Get something working reasonable fast to detect current green address
> style transactions. It's fine if it is a little bit of a hack, as long as
> it's safe, since I don't expect it to be merged with mainline anyway at
> this point.
>
> 2) Rethink how green transactions are created and verified and try to put
> something 'proper' together which has a chance of being merged at some
> point.
>
> For the moment I was going more with 1) because I got the impression, that
> green transactions are too controversial at this point to get them
> included in mainline. Criticism ranging from 'unnecessary, as
> 0-confirmation transactions are fairly safe today' to 'encourages too much
> centralization and therefore evil'. So how to people on this list feel
> about green transactions? Would people be interested in helping me with
> 2)?
One possibility would be to create a peer sourced green address
implementation. That is, each user could, individually decide to trust
certain addresses as "green" and optionally, publish this trust. Basing
things on the published trust, you could dynamically, as opposed to
static hierarchies, evaluate the trustworthiness of each green address
you haven't personally decided to trust.
This would be somewhat involved implementation, though, as it would
require heavy statistical calculations.
- Joel
|
