From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Rbe72-00023J-RZ for bitcoin-development@lists.sourceforge.net; Fri, 16 Dec 2011 20:10:36 +0000 X-ACL-Warn: Received: from nm18-vm3.bullet.mail.ne1.yahoo.com ([98.138.91.148]) by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1Rbe71-0007YS-MV for bitcoin-development@lists.sourceforge.net; Fri, 16 Dec 2011 20:10:36 +0000 Received: from [98.138.90.51] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 16 Dec 2011 20:10:30 -0000 Received: from [98.138.87.5] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 16 Dec 2011 20:10:30 -0000 Received: from [127.0.0.1] by omp1005.mail.ne1.yahoo.com with NNFMP; 16 Dec 2011 20:10:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 446017.1471.bm@omp1005.mail.ne1.yahoo.com Received: (qmail 64055 invoked by uid 60001); 16 Dec 2011 20:10:30 -0000 X-YMail-OSG: DnSpj8MVM1mYcpFfrl1hJu.hcKq2NJQ7xRzgcq.CZruE_jo ULVEDCFADkWjbVFsExsW5T33wHdcezIHP6CZ1Oz4Ig7JYLbhSC5jotocCpYi I2OIicLt450_uhZ59RATRcRxAG8JcbK_av_S2cHeHOtbkQoakfF034tPY2vs gK1aWqsOjzweLQu9hD8Rf5UFTY5L09f8tlaYZIqj__uJN5M85tQXNvdN1_MQ q3Glpy0sr.5L0GrdnRzZ6twcyubHGn9ZTL.izbGuswnBbgn9d19USbuj2AwH vQWpBaXKQDJTNFstEGoH9BKGJbyNz0dcJbounLKGUK2aqW5PpIU.WPvnDVgD ByUNAmTyfrExzRTbtSNEhYw03v_lY6zHeeoA8bAbsW69CBq8SRJ7bMdOPGJl HXAIlrThcSt4XiZ8ZFIfDbRwJ1zH2oPrKV_rz8Ffjmpjrc908oVMlXUU.hSd Ug94ArZgHllYH8s5YHxN7bIN9TaxNTORqFZPuen4WPccaXE3aUsDPDuqwtQ- - Received: from [2.97.168.202] by web121004.mail.ne1.yahoo.com via HTTP; Fri, 16 Dec 2011 12:10:30 PST X-Mailer: YahooMailWebService/0.8.115.331698 References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com> <1323979147.27319.140661012141129@webmail.messagingengine.com> <4EEB7E98.8030006@dot-bit.org> Message-ID: <1324066230.24980.YahooMailNeo@web121004.mail.ne1.yahoo.com> Date: Fri, 16 Dec 2011 12:10:30 -0800 (PST) From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1562933420-1444682373-1324066230=:24980" X-Spam-Score: -0.7 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zgenjix[at]yahoo.com) -2.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.0 HTML_MESSAGE BODY: HTML included in message -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 0.7 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Rbe71-0007YS-MV Subject: Re: [Bitcoin-development] [BIP 15] Aliases X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Amir Taaki List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 20:10:36 -0000 ---1562933420-1444682373-1324066230=:24980 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I think IBANs are not such a good idea. Note that as someone who has spent = the last year of my life dealing with hundreds of bank transactions a day a= nd interacting with the banking system (both on a technical, systematic and= personnel level), the entire system is a gigantic mess.=0A=0AThe banks are= in fact looking to us for answers. That's why we (Bitcoin Consultancy) wer= e invited to the SWIFT conference to join their panel on bank 2.0.=0A=0AI d= on't even mind the maxim "take everything the banks have done and do the co= mplete opposite" :)=0A=0AI invite anyone who is skeptical to read the ECB's= specification on SEPA payments. It really is an example of a system made t= o work alongside legacy systems that rely on inefficient people. The interc= hange fees are dependent on a totally arbitrary test of merchant indifferen= ce and various antitrust regulations.=0A=0AThese systems are usually built = not by engineers or hackers, but by finance people. IBAN has no place in bi= tcoin IMO.=0A=0AI don't mean to sound too critical, but I'm skeptical of it= s usefulness. Especially when we already have bitcoin addresses with their = own checksums- what value do IBANs add? Nothing except negatives.=0A=0A=0A= =0A________________________________=0A From: slush =0ATo:= Khalahan =0ACc: bitcoin-development@lists.sourceforge.n= et =0ASent: Friday, December 16, 2011 7:54 PM=0ASubject: Re: [Bitcoin-devel= opment] [BIP 15] Aliases=0A =0A=0AKhalahan, honestly, using namecoin for al= iases is (for me) clean example of over-engineering. I mean - it will defin= itely work if implemented properly. I played with a namecoin a bit (as my p= ool was the first 'big' pool supporting merged mining), but I think there's= really long way to provide such alias system in namecoin and *cleanly inte= grate it with bitcoin*. Don't forget that people who want to do lookup need= to maintain also namecoin blockchain with their bitcoin client. It goes ag= ainst my instinct of keeping stuff easy.=0A=0AFor example, yesterday I impl= emented HTTPS lookup for addresses into my fork of Electrum client. I did i= t in 15 minutes, it works as expected, it does the job and the implementati= on is really transparent, becuase implementation is 20 lines of code. There= 's no magic transformation, no forced "?handle=3D" parameters or whatever. = And I don't care if somebody provide URL https://some.strange.domain/name-o= f-my-dog?myhandle=3D5678iop&anything_else=3DTrue=0A=0AAnd everybody can do = the same in their clients, in their merchant solutions, websites or whateve= r. Everybody can do HTTPS lookup. But try to explain DNS, Namecoin, IIBAN, = email aliases to other programmers...=0A=0A=0AThose IIBAN - well, why not. = At least I see the potential in PR. So far I understand it as some teoretic= concept which is not supported by anything else right now. Give it few yea= rs until it matures and then add IIBAN alias to Bitcoin client too.=0A=0AMa= ybe I'm repeating myself already, but the way to go is to make aliases as e= asy as possible, so everybody can implement it in their own solution and th= us practially remove the need of using standard bitcoin addresses for norma= l users. Using some superior technology, which is hard to implement or even= understand won't solve the situation, because it will ends up with some re= ference implementation in standard client only and nobody else will use it.= =0A=0Aslush=0A=0A=0AOn Fri, Dec 16, 2011 at 6:23 PM, Khalahan wrote:=0A=0A =0A>Namecoin is a peer-to-peer generic name/value datast= ore system.=0A>Don't forget it's not limited to .bit usage ! So, directly m= apping=0A things to .bit url would not be the optimal way of using namec= oin.=0A>=0A>=0A------------------------------------------------------------= ------------------=0ALearn Windows Azure Live!=A0 Tuesday, Dec 13, 2011=0AM= icrosoft is holding a special Learn Windows Azure training event for =0Adev= elopers. It will provide a great way to learn Windows Azure and what it =0A= provides. You can attend the event by watching it streamed LIVE online.=A0 = =0ALearn more at http://p.sf.net/sfu/ms-windowsazure=0A____________________= ___________________________=0ABitcoin-development mailing list=0ABitcoin-de= velopment@lists.sourceforge.net=0Ahttps://lists.sourceforge.net/lists/listi= nfo/bitcoin-development ---1562933420-1444682373-1324066230=:24980 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I think IB= ANs are not such a good idea. Note that as someone who has spent the last y= ear of my life dealing with hundreds of bank transactions a day and interac= ting with the banking system (both on a technical, systematic and personnel= level), the entire system is a gigantic mess.

<= /span>
The banks are in fact looking to us for answers. Tha= t's why we (Bitcoin Consultancy) were invited to the SWIFT conference to jo= in their panel on bank 2.0.

I don't even mind the maxim "take everything the banks have done and do= the complete opposite" :)

I invite anyone who is skeptical to read the ECB's specification on SEPA= payments. It really is an example of a system made to work alongside legacy systems that rely on inefficient people. The interchange fees are d= ependent on a totally arbitrary test of merchant indifference and various a= ntitrust regulations.

Th= ese systems are usually built not by engineers or hackers, but by finance p= eople. IBAN has no place in bitcoin IMO.

=
I don't mean to sound too critical, but I'm skeptical of i= ts usefulness. Especially when we already have bitcoin addresses with their= own checksums- what value do IBANs add? Nothing except negatives.

From:<= /b> slush <slush@centrum.cz>
To: Khalahan <khal@dot-bit.org>
Cc: bitcoin-development@lists.sourceforg= e.net
Sent: Friday, D= ecember 16, 2011 7:54 PM
Subject:= Re: [Bitcoin-development] [BIP 15] Aliases
=0A<= meta http-equiv=3D"x-dns-prefetch-control" content=3D"off">
Khalahan, honestly, using namecoin for aliases is (for me) clean = example of over-engineering. I mean - it will definitely work if implemente= d properly. I played with a namecoin a bit (as my pool was the first 'big' = pool supporting merged mining), but I think there's really long way to prov= ide such alias system in namecoin and *cleanly integrate it with bitcoin*. = Don't forget that people who want to do lookup need to maintain also nameco= in blockchain with their bitcoin client. It goes against my instinct of kee= ping stuff easy.
=0A=0A
For example, yesterday I implemen= ted HTTPS lookup for addresses into my fork of Electrum client. I did it in= 15 minutes, it works as expected, it does the job and the implementation i= s really transparent, becuase implementation is 20 lines of code. There's n= o magic transformation, no forced "?handle=3D" parameters or whatever. And = I don't care if somebody provide URL https://some.strange.domain/name-of-my-dog?myhandle=3D= 5678iop&anything_else=3DTrue
=0A=0A

And eve= rybody can do the same in their clients, in their merchant solutions, websi= tes or whatever. Everybody can do HTTPS lookup. But try to explain DNS, Nam= ecoin, IIBAN, email aliases to other programmers...
=0A=0A

Those IIBAN - well, why not. At least I see the potential in PR. So f= ar I understand it as some teoretic concept which is not supported by anyth= ing else right now. Give it few years until it matures and then add IIBAN a= lias to Bitcoin client too.
=0A=0A

Maybe I'm repeat= ing myself already, but the way to go is to make aliases as easy as possibl= e, so everybody can implement it in their own solution and thus practially = remove the need of using standard bitcoin addresses for normal users. Using= some superior technology, which is hard to implement or even understand wo= n't solve the situation, because it will ends up with some reference implem= entation in standard client only and nobody else will use it.
=0A=0A
slush

On F= ri, Dec 16, 2011 at 6:23 PM, Khalahan <khal@dot-bit.org> wrote:
=0A=0A=0A=0A =0A =0A =0A
=0A Namecoin is a peer-to-peer generic = name/value datastore system.
=0A Don't forget it's not limited to .bi= t usage ! So, directly mapping=0A things to .bit url would not be the op= timal way of using namecoin.

=0A

--------------------------------------------------------------------= ----------
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Micr= osoft is holding a special Learn Windows Azure training event for
devel= opers. It will provide a great way to learn Windows Azure and what it
p= rovides. You can attend the event by watching it streamed LIVE online. = ;
Learn more at http://p.sf.net/sfu/ms-windowsazure
____________________= ___________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforg= e.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-dev= elopment


---1562933420-1444682373-1324066230=:24980--