1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
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 <zgenjix@yahoo.com>) 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 <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"
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 <zgenjix@yahoo.com>
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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 <theymos@mm.st><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> p=
ublic key<br>- Extend "checkorder" messages so they can specify an account =
to<br> send BTC to. Or standardize on how to put the account into the=
<br> message field.<br>- Enable DNS lookups for IP transactions. The =
DNS-only proposals could<br> also be used here to avoid having to use=
the IP transaction protocol<br> sometimes. The public key for signin=
g "reply" messages can be gotten<br> from TXT records. This will be s=
afe with DNSSEC and Namecoin. With<br> plain DNS Bitcoin could take a=
SSH-like approach and ask the user to<br> 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. <br>But none more important than the need to =
reduce IT complexity <br>while improving strategic productivity. 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--
|
