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 <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<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"
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Precedence: list
Reply-To: Amir Taaki <zgenjix@yahoo.com>

---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 <theymos@mm.st>=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

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt"><div><span>This is ma=
ybe the best idea. I added it:</span></div><div><span>https://en.bitcoin.it=
/wiki/BIP_0015#IP_Transactions</span></div><div><br><span></span></div><div=
><span>Things I like about this:</span></div><div><span>- IP transactions a=
re useful, but have a security flaw. This mitigates their security problems=
.</span></div><div><span>- 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.</span></div><div>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.<br>=0A</div><div>- We can have a proxy node running 24/7 for us, serving=
 our public keys in lieu of us.<br><span></span></div><br><div style=3D"fon=
t-family: times new roman, new york, times, serif; font-size: 12pt;"> <div =
style=3D"font-family: times new roman, new york, times, serif; font-size: 1=
2pt;"> <font face=3D"Arial" size=3D"2"> <hr size=3D"1">  <b><span style=3D"=
font-weight:bold;">From:</span></b> theymos &lt;theymos@mm.st&gt;<br> <b><s=
pan style=3D"font-weight: bold;">To:</span></b> bitcoin-development@lists.s=
ourceforge.net <br> <b><span style=3D"font-weight: bold;">Sent:</span></b> =
Thursday, December 15, 2011 7:59 PM<br> <b><span style=3D"font-weight: bold=
;">Subject:</span></b> Re: [Bitcoin-development] [BIP 15] Aliases<br> </fon=
t> <br>=0ABitcoin already has code and a protocol for transactions to IP<br=
>addresses. Why not reuse that for dynamic address lookup? Just a few<br>ch=
anges are necessary to enable complete <a ymailto=3D"mailto:user@server.com=
" href=3D"mailto:user@server.com">user@server.com</a> handling:<br>- Extend=
 the protocol so that "reply" messages can be signed by a fixed<br>&nbsp; p=
ublic key<br>- Extend "checkorder" messages so they can specify an account =
to<br>&nbsp; send BTC to. Or standardize on how to put the account into the=
<br>&nbsp; message field.<br>- Enable DNS lookups for IP transactions. The =
DNS-only proposals could<br>&nbsp; also be used here to avoid having to use=
 the IP transaction protocol<br>&nbsp; sometimes. The public key for signin=
g "reply" messages can be gotten<br>&nbsp; from TXT records. This will be s=
afe with DNSSEC and Namecoin. With<br>&nbsp; plain DNS Bitcoin could take a=
 SSH-like approach and ask the user to<br>&nbsp; verify the public key the =
first
 time it is used, remembering it later.<br><br>DoS attacks are already hand=
led by the IP transactions code: the same IP<br>address is always given the=
 same bitcoin address until it pays to that<br>bitcoin address.<br><br>----=
--------------------------------------------------------------------------<=
br>10 Tips for Better Server Consolidation<br>Server virtualization is bein=
g driven by many needs.&nbsp; <br>But none more important than the need to =
reduce IT complexity <br>while improving strategic productivity.&nbsp; Lear=
n More! <br>http://www.accelacomm.com/jaw/sdnl/114/51507609/<br>___________=
____________________________________<br>Bitcoin-development mailing list<br=
><a ymailto=3D"mailto:Bitcoin-development@lists.sourceforge.net" href=3D"ma=
ilto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.s=
ourceforge.net</a><br><a href=3D"https://lists.sourceforge.net/lists/listin=
fo/bitcoin-development"
 target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-dev=
elopment</a><br><br><br> </div> </div>  </div></body></html>
---599881721-1948761763-1323993362=:62644--