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 ) 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 ; 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 To: Jan Vornberger 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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