From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RbQYa-0007eA-Qm for bitcoin-development@lists.sourceforge.net; Fri, 16 Dec 2011 05:42:08 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.175 as permitted sender) client-ip=209.85.212.175; envelope-from=walter.stanish@gmail.com; helo=mail-wi0-f175.google.com; Received: from mail-wi0-f175.google.com ([209.85.212.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RbQYa-0006ZV-1X for bitcoin-development@lists.sourceforge.net; Fri, 16 Dec 2011 05:42:08 +0000 Received: by wibhq7 with SMTP id hq7so227977wib.34 for ; Thu, 15 Dec 2011 21:42:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.102.233 with SMTP id fr9mr10129138wib.40.1324014121917; Thu, 15 Dec 2011 21:42:01 -0800 (PST) Sender: walter.stanish@gmail.com Received: by 10.223.69.139 with HTTP; Thu, 15 Dec 2011 21:42:01 -0800 (PST) In-Reply-To: References: <1323929094.37881.YahooMailClassic@web120902.mail.ne1.yahoo.com> Date: Fri, 16 Dec 2011 13:42:01 +0800 X-Google-Sender-Auth: ocnAalTYJVEtwvmXuE0xK43E9l8 Message-ID: From: Walter Stanish To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.3 (-) 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 (walter.stanish[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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 0.2 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RbQYa-0006ZV-1X Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases 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: Fri, 16 Dec 2011 05:42:08 -0000 >> Interaction is a requirement, since there seems to be a widely felt >> need to preserve anonymity through the use of temporary addresses. >> Generating a temporary address requires some actual processing to >> achieve, since the issuing of the new address cannot be done without >> interacting with the entity hosting the wallet (unless I'm missing >> something?). > > I thought the interaction was just the server answering with an > address (maybe also amount and other details). But we don't have to > define how the server will get that address. > Some possibilities: > > -A static address: less anonymity, but some people may not care. Say a > donation address. Sure, but this falls short of requirements for most users. > -The servers stores the recipient private keys and generates a new one > for each payment. Equivalent to hosted wallet, which is decentralization in a BIG way, but apparently a very popular choice (for pragmatic reasons). Probably not going away. > -The server stores a set of addresses provided by the recipient and it > manages what address it gives in each request (like in the web service > I told you I can't find). True. However, probably a poor user experience for most users re: provision of temporary addresses to the alias host. Also the knowledge of which entity for which inbound payment has been allocated which temporary address would be a significant complexity in the alias host / end user relationship that you gloss over. This is important for businesses, since inbound payments are only really possible to track - AFAIK (correct me if I'm wrong, the two exceptions being the edge case of people requesting inbound transactions where every single transaction is of a unique amount and no 'partial payment' (2x transactions for one inbound payment) and the case where every single inbound payer's sending address is previously known) - by issuing unique recipient addresses to each client. In short, it's kind of similar to hosted wallet as well, since you need to absolutely trust your host (they could tell people wishing to make payments to you to pay someone else instead!). > IANA reserves some namespace for bitcoin. All right. > The problem comes later. > " > * Systems such as [BITCOIN] have quirks that require slightly > delayed settlement due to the nature of their decentralized, > consensus-based approach to fiscal transfer. Users requiring > instant settlement MAY thus see benefit in the use of a > centralized proxy system or organization as an instantaneous > financial settlement provider (the 'institution'). > " > As I understand it (probably I'm wrong, because I haven't read the > whole IIBAN draft) there would be a "bitcoin institution" that would > map bitcoin addresses to the bitcoin subspace of the IIBAN. Many people can get namespace management rights as 'institutions' (in the current draft's terminology), then manage the assignement of IIBANs within that space as they wish. There would be many institutions with many IIBANs. The association of a bitcoin address (or many addresses, or the capacity to generate temporary addresses as required) with an IIBAN would be the responsibility of either that namespace manager ('institution') or the individual who has acquired that IIBAN via that namespace manager ('insitution'). > " * IANA MAY delegate management of portions of the IIBAN name space > through such institutions." > > If we can find a deterministic method to map the subspace the all > possible bitcoin addresses, everything's fine again. But if that's not > possible, we would need a central institution to manage the mapping > and that would be a step back in decentralization. Many institutions, many policies, no absolute centralization, though admittedly increased centralization. However, this is a problem shared with two of your proposals (the subset not disqualified as failing to meet most user's requirements) when you consider that most users (if you consider 'the whole world's mobile devices' a potential userbase, as I prefer to do) do not have the technical skills to configure, secure and manage their own 'always on' alias service hosts, nor the capacity to host blockchain copies on those devices (either due to space or bandwidth requirements. As an aside, this is a large part of the unfortunate reality that is tending to push Bitcoin towards hosted wallet solutions) > I can't find the answer of Gavin's question "How is the mapping done?" > in your post. I'll re-read it though. Near the top, beginning "It seems a clarification is in order, apologies for not being clearer." (Re-reading, it's still not that clear!) Regards, Walter Stanish Payward, Inc.