From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YDgQi-0007K9-W7 for bitcoin-development@lists.sourceforge.net; Tue, 20 Jan 2015 21:33:45 +0000 Received-SPF: pass (sog-mx-2.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-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YDgQh-0006d5-C0 for bitcoin-development@lists.sourceforge.net; Tue, 20 Jan 2015 21:33:44 +0000 Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121]) (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 8E8D640E5B for ; Tue, 20 Jan 2015 21:33:37 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla) with ESMTPSA id D169A21D50 Message-ID: <54BEC9C1.3000600@riseup.net> Date: Tue, 20 Jan 2015 21:33:53 +0000 From: odinn MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <20150120154641.GA32556@muck> <54BE94AB.3020207@monetas.net> 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-Spam-Score: -1.4 (-) 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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.252.153.129 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Headers-End: 1YDgQh-0006d5-C0 Subject: Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships 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, 20 Jan 2015 21:33:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Um ~ "jurisdiction of wallet provider?" If that's the (perhaps ot) bit you want to run on this thread then my comments are: Get out of web wallet businesses now. It's not a jurisdictional question anymore, although I think there used to be very valid long running debates on where it would be best to do business. Now it just feels like you will be bouncing from one place to another - determining where your exit is as soon as you establish a (physical) presence, because jurisdictions sense a serious threat from the advancement of financial cryptography as it will evolve in the next several years. So you have to be mobile, or do something like what they are establishing at blueseed (see http://blueseed.com which is just off coast of San Francisco). Please perk up and don't just swipe to delete, read the whole e-mail. There are some configurations (e.g. the zero knowledge bit) you can do to mitigate the issues but if you are asking users to log in and log out of a service that relies on a web site then in the end you doom them (and any service you provide) to mandatory storage of customer data and ultimately loss of customer resources due to identification of the customer. I think you need to stop quibbling about the details and just get over it and understand that the problem of web wallet users and corporations that serve web wallet customers being forced to give up information constantly to governments means that web wallets are certainly no longer a viable solution. And post-cromnibus with the extra financial surveillance provisions now passed on 3rd party matters, it's even worse. This is not subject to debate, it's just a fact. Period. Web wallet corps exist now only on a model that exists to burn the users. Convenient? Yes. But is it good for the users in the long haul? Absolutely not. Do alternative to the web wallets exist? Absolutely. Back off.. Go to p2p. Stop advocating for webby solutions. In fact, I don't think that anyone working for coinbase or bitpay should be, anymore. I think that on principle you should withdraw and end your employment from such services. Core? Good. Electrum Wallet? good. Mycelium? Local Trader? Open Bazaar? Could be better, but great. These are the kind of things we need. No signups, avoids centralizations, no grabbing your data, no ID collection and requirements. As to the issue of auto-updating itself... I think the simplest answer to this question (personally) is that (go ahead and attack me here) there shouldn't be auto-updates... but that there should be auto-notifications for update when (a) update is available, but that (b) this notification should never "push" the user to update (e.g. the notification should never say "oh hey user if you don't update by such and such a date, your wallet will not work or satoshis will die because of your inaction" (stays quiet while likely 100-e-mail thread is spawned from this) - -O Tamas Blummer: > Justus, >=20 > In contrary. >=20 > Not being in the jurisdiction of the wallet provider makes it > harder for the user to reclaim funds taken by the wallet provider.=20 > The legal hurdle to force confiscation through a wallet provider > might also be lower if the target user is not domestic. >=20 > Tamas Blummer >=20 >=20 >=20 > -----------------------------------------------------------------------= ------- > >=20 New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in > Ashburn. Choose from 2 high performing configs, both with 100TB of > bandwidth. Higher redundancy.Lower latency.Increased > capacity.Completely compliant. http://p.sf.net/sfu/gigenet >=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----- iQEcBAEBCgAGBQJUvsnBAAoJEGxwq/inSG8CGekIAJH4lUdk81sVfQqxZ4sKOKFM 5iAvCD4JNuV+xcCZBiNNr1GxIZEVoDRQYupo7wB1A5uGW+STLHDGsEMuDNyiOcNl oSsJQFZJabxL7dIn8g89Gw+8J8LtYKEkHHZLk5J5QF0DkRljXjEcOV4KL6WXhdl5 ToV01POMUBbSJsQt2lLznmCvQ+4QW5/GJ9Hk04HIub+kzuil0R23CgRH9QFevC9S 2/RT3NnfGFu+jU5+K/o8RbuUuzExq94x4w266IEmJc0NsLHxnxsg2PefabQbfdzp P7FU7+D9NsIOaBGTXnQK80kpgRCJ49Gf9HXHKFYg2KCFuqgJYa8DnHm1Xlfo7DQ=3D =3DyS8H -----END PGP SIGNATURE-----