From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RbL9l-0002aO-2L for bitcoin-development@lists.sourceforge.net; Thu, 15 Dec 2011 23:56:09 +0000 X-ACL-Warn: Received: from nm17-vm0.bullet.mail.ne1.yahoo.com ([98.138.91.58]) by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1RbL9k-0004Aa-3l for bitcoin-development@lists.sourceforge.net; Thu, 15 Dec 2011 23:56:09 +0000 Received: from [98.138.90.56] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 15 Dec 2011 23:56:02 -0000 Received: from [98.138.88.232] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 15 Dec 2011 23:56:02 -0000 Received: from [127.0.0.1] by omp1032.mail.ne1.yahoo.com with NNFMP; 15 Dec 2011 23:56:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 955454.92683.bm@omp1032.mail.ne1.yahoo.com Received: (qmail 83921 invoked by uid 60001); 15 Dec 2011 23:56:02 -0000 X-YMail-OSG: gda5MB0VM1m8sM_SFBSCe6CC5vCvq3b0ablZjUly8vRcNPj nHTGDlBmLt_4U4pWJAU3kLrowNKvLItkv.hXSpvH9bY6RYKilGcu4JW3FlwF B06.HlTnD1aszwV3vayMACtcuZb3fdeMaJ4KlDo2Nl8u4GhNzKg5isYyJTHA JV5J6cFS2L4fUO5UO3Mwmrs95GslvaX_oiIbeDviI10FNys2AWHZI0gdKcWt nDIhjK79RiQZx4CuJqZM1Mo6kFjw1eLP8KTroB69BP_6SdQALCTVbJIaCWAV dfl3mB1QFoylZnNmxiH.o5fVyQjMBNU2ptC8R1SaHLRXo1C.zDjnCHfCTB9_ RMFDvz2koLiofH6Ym1zMJW23oFsroBaILgRUjexVTkDsX4v4bvnHohWXLPIw yjuVDCZhVims_24K4Hf0AstFBOvmo2LLa.tVYW8cDWq3pYWwvVUEmtS5zbWr K1RKKVxNhh7UHPFJZMoaqpYCloyE4uGQy3p1VRLyFhrh.Rj2AzV_PkLnNoAt YzkX_rY5kKqXyJar9sF4AdDJeTrjv4dZIl9Q- Received: from [2.97.168.202] by web121002.mail.ne1.yahoo.com via HTTP; Thu, 15 Dec 2011 15:56:02 PST X-Mailer: YahooMailWebService/0.8.115.331698 References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com> <1323979147.27319.140661012141129@webmail.messagingengine.com> Message-ID: <1323993362.62644.YahooMailNeo@web121002.mail.ne1.yahoo.com> Date: Thu, 15 Dec 2011 15:56:02 -0800 (PST) From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: <1323979147.27319.140661012141129@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-599881721-1948761763-1323993362=:62644" X-Spam-Score: -1.4 (-) 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.3 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 X-Headers-End: 1RbL9k-0004Aa-3l 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: Thu, 15 Dec 2011 23:56:09 -0000 ---599881721-1948761763-1323993362=:62644 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This is maybe the best idea. I added it:=0Ahttps://en.bitcoin.it/wiki/BIP_0= 015#IP_Transactions=0A=0AThings I like about this:=0A- IP transactions are = useful, but have a security flaw. This mitigates their security problems.= =0A- The code for IP transactions is already in Satoshi client. If other cl= ients want to add IP transactions, then it can be done with minimal fuss/bl= oat.=0AI feel that for any protocol extension, less is more. The less code = =0Aneeded, the better the extension. Not always but generally we want to = =0Aavoid bitcoin protocol bloat which *will* happen far in the future. The = =0Aonly way to mitigate how spaghettified the standard will be in the =0Afu= ture, is by careful cautious planning now.=0A=0A- We can have a proxy node = running 24/7 for us, serving our public keys in lieu of us.=0A=0A=0A=0A____= ____________________________=0A From: theymos =0ATo: bitcoin= -development@lists.sourceforge.net =0ASent: Thursday, December 15, 2011 7:5= 9 PM=0ASubject: Re: [Bitcoin-development] [BIP 15] Aliases=0A =0ABitcoin al= ready has code and a protocol for transactions to IP=0Aaddresses. Why not r= euse that for dynamic address lookup? Just a few=0Achanges are necessary to= enable complete user@server.com handling:=0A- Extend the protocol so that = "reply" messages can be signed by a fixed=0A=A0 public key=0A- Extend "chec= korder" messages so they can specify an account to=0A=A0 send BTC to. Or st= andardize on how to put the account into the=0A=A0 message field.=0A- Enabl= e DNS lookups for IP transactions. The DNS-only proposals could=0A=A0 also = be used here to avoid having to use the IP transaction protocol=0A=A0 somet= imes. The public key for signing "reply" messages can be gotten=0A=A0 from = TXT records. This will be safe with DNSSEC and Namecoin. With=0A=A0 plain D= NS Bitcoin could take a SSH-like approach and ask the user to=0A=A0 verify = the public key the first time it is used, remembering it later.=0A=0ADoS at= tacks are already handled by the IP transactions code: the same IP=0Aaddres= s is always given the same bitcoin address until it pays to that=0Abitcoin = address.=0A=0A-------------------------------------------------------------= -----------------=0A10 Tips for Better Server Consolidation=0AServer virtua= lization is being driven by many needs.=A0 =0ABut none more important than = the need to reduce IT complexity =0Awhile improving strategic productivity.= =A0 Learn More! =0Ahttp://www.accelacomm.com/jaw/sdnl/114/51507609/=0A_____= __________________________________________=0ABitcoin-development mailing li= st=0ABitcoin-development@lists.sourceforge.net=0Ahttps://lists.sourceforge.= net/lists/listinfo/bitcoin-development ---599881721-1948761763-1323993362=:62644 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
This is ma= ybe the best idea. I added it:
https://en.bitcoin.it= /wiki/BIP_0015#IP_Transactions

Things I like about this:
- IP transactions a= re useful, but have a security flaw. This mitigates their security problems= .
- The code for IP transactions is already in Satos= hi client. If other clients want to add IP transactions, then it can be don= e with minimal fuss/bloat.
I feel that for any protocol ex= tension, less is more. The less code =0Aneeded, the better the extension. N= ot always but generally we want to =0Aavoid bitcoin protocol bloat which *w= ill* happen far in the future. The =0Aonly way to mitigate how spaghettifie= d the standard will be in the =0Afuture, is by careful cautious planning no= w.
=0A
- We can have a proxy node running 24/7 for us, serving= our public keys in lieu of us.

From: theymos <theymos@mm.st>
To: bitcoin-development@lists.s= ourceforge.net
Sent: = Thursday, December 15, 2011 7:59 PM
Subject: Re: [Bitcoin-development] [BIP 15] Aliases

=0ABitcoin already has code and a protocol for transactions to IPaddresses. Why not reuse that for dynamic address lookup? Just a few
ch= anges are necessary to enable complete user@server.com handling:
- Extend= the protocol so that "reply" messages can be signed by a fixed
  p= ublic key
- Extend "checkorder" messages so they can specify an account = to
  send BTC to. Or standardize on how to put the account into the=
  message field.
- Enable DNS lookups for IP transactions. The = DNS-only proposals could
  also be used here to avoid having to use= the IP transaction protocol
  sometimes. The public key for signin= g "reply" messages can be gotten
  from TXT records. This will be s= afe with DNSSEC and Namecoin. With
  plain DNS Bitcoin could take a= SSH-like approach and ask the user to
  verify the public key the = first time it is used, remembering it later.

DoS attacks are already hand= led by the IP transactions code: the same IP
address is always given the= same bitcoin address until it pays to that
bitcoin address.

----= --------------------------------------------------------------------------<= br>10 Tips for Better Server Consolidation
Server virtualization is bein= g driven by many needs. 
But none more important than the need to = reduce IT complexity
while improving strategic productivity.  Lear= n More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/
___________= ____________________________________
Bitcoin-development mailing listBitcoin-development@lists.s= ourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-dev= elopment


---599881721-1948761763-1323993362=:62644--