path: root/b8/073ba72198ffa8148659cf2cb8159df3ea1482

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <zgenjix@yahoo.com>) id 1RcLmD-00040V-BI
	for bitcoin-development@lists.sourceforge.net;
	Sun, 18 Dec 2011 18:48:01 +0000
X-ACL-Warn: 
Received: from nm12-vm0.bullet.mail.ne1.yahoo.com ([98.138.91.51])
	by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76)
	id 1RcLmC-0007rl-8i for bitcoin-development@lists.sourceforge.net;
	Sun, 18 Dec 2011 18:48:01 +0000
Received: from [98.138.90.48] by nm12.bullet.mail.ne1.yahoo.com with NNFMP;
	18 Dec 2011 18:47:55 -0000
Received: from [98.138.89.163] by tm1.bullet.mail.ne1.yahoo.com with NNFMP;
	18 Dec 2011 18:47:55 -0000
Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP;
	18 Dec 2011 18:47:55 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 120742.20381.bm@omp1019.mail.ne1.yahoo.com
Received: (qmail 64250 invoked by uid 60001); 18 Dec 2011 18:47:54 -0000
X-YMail-OSG: 0vgpCccVM1ktZc5NIz5srwOiNbDWsrBdSVAFUoaBkcSy4M1
	_amHTh_0U5_hIzRHAZirRwDhmc7LxC1BqMosrQHnySSaLIt3y8TvylApHbAx
	QE1GCzE38GiwiLxj7qpN0NOttwd1feBd8h4BmfZfDEaFsAlZr1474fNlSR6j
	_YfTtzA9V.3XivXcXu09DLKIHEAKtz_b3oOxPZDzUXJjsqsWmXiOAepNp_.F
	qOvSgpf0IwoLCLNWEjeonSsx28_wv_EeP0xbn1r9twJgCY2jc4Ql7npy1NBY
	SLyZFO_lUUW6d0kU8IzRU2MQLrNEBWRQz1dx5VzKbz9KbJEE1AXa_eveutG2
	8W2IAcCRLgkEl86FoB1GYM_vrsIaaWi6dIDsZEs8cnTVthZCOQZbYp3YBrmW
	WUT84iKHfarBtoHRatAdo1qqYPvipFnlb6dz5Mf_C07AmlHIJnCtS3rc_cbD
	sQvKhREYfHw--
Received: from [92.20.168.44] by web121006.mail.ne1.yahoo.com via HTTP;
	Sun, 18 Dec 2011 10:47:54 PST
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com><82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com><CALxbBHUXEJLRDZ=RS1vuvkm7rDjFUPir0sU__f6TJXiTTQxWzA@mail.gmail.com><CABsx9T0puk3CWH1cfNHMSVEoCPaLJJWNJ+H5ObCERZrzMbrTyA@mail.gmail.com><CABsx9T06-GA5+KNdr_XzP_M4Av8nEsnMXL29tk078wooZg=RZw@mail.gmail.com><1324158558.26106.140661012932641@webmail.messagingengine.com>
	<4EED416E.3010902@parhelic.com>
	<1324228179.7053.140661013136581@webmail.messagingengine.com>
	<4EEE2B91.1050908@gmail.com>
Message-ID: <1324234074.548.YahooMailNeo@web121006.mail.ne1.yahoo.com>
Date: Sun, 18 Dec 2011 10:47:54 -0800 (PST)
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <4EEE2B91.1050908@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="285087016-2030097772-1324234074=:548"
X-Spam-Score: -2.0 (--)
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.5 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.4 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RcLmC-0007rl-8i
Subject: Re: [Bitcoin-development] Protocol extensions
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: Sun, 18 Dec 2011 18:48:01 -0000

--285087016-2030097772-1324234074=:548
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Has anyone considered 'snapshot' frames (blocks).=0A=0AMessage to node:=0A=
=0Agetsnapshot: hash=0A=0ANode responds with a 'block' message.=0A=0AThen t=
he hash for that particular snapshot is hardcoded into the sourcecode. It w=
ould replace the checkpoints and use the last hash in that list.=0A=0AValid=
ating blocks is pretty fast right up until block 135k, which is where time =
taken balloons and starts become exponentially slower. As blockchain grows =
linearly, resources needed grows exponentially if you think about it.=0A=0A=
=0A=0A________________________________=0A From: Alan Reiner <etotheipi@gmai=
l.com>=0ATo: bitcoin-development@lists.sourceforge.net =0ASent: Sunday, Dec=
ember 18, 2011 6:06 PM=0ASubject: Re: [Bitcoin-development] Protocol extens=
ions=0A =0A=0AThe whole point of having headers built at a constant size an=
d generation rate is to minimize the amount of data needed to "understand" =
of the blockchain while simultaneously maximizing integrity/security in the=
 presence of untrusted nodes.=A0 Barring the 50%-attack, you only need a co=
uple honest nodes out of 50 to stay safe (as long as you're waiting for you=
r 6 confirmations).=A0=A0 In fact, I would argue that a full node (Satoshi =
client), has the same level of security as a headers-only client... because=
 they both base all their verification decisions on computations that end w=
ith comparing hashes to the longest-chain headers.=0A=0AIn the case that an=
 attacker figures out how to isolate your node=0A    entirely and start fee=
ing you poisoned blocks, then you are=0A    vulnerable with any kind of nod=
e, full or lightweight.=A0 I don't see=0A    where the reduced security is.=
=A0 =0A=0AThe only issue I see is that a truly light-weight, headers-only n=
ode=0A    will be having to download an entire block to get one transaction=
 it=0A    needs.=A0 This would be significantly alleviated if nodes can sta=
rt=0A    requesting merkle-trees directly, even without=0A    merkle-branch=
-pruning. =A0 If a node can ask for a tx and the=0A    tx-hash-list of the =
block that incorporated that tx,=A0 he can easily=0A    verify his tx again=
st his no-need-to-trust-anyone headers, and=0A    doesn't have to download =
MBs for every one.=A0 =0A=0AAs for blockchain pruning... I think it's absol=
utely critical to=0A    find a way to do this, for all nodes.=A0 I am swaye=
d by Dan Kaminsky's scalability warnings, and my instinct tells me that lea=
ving full verification to a select few deep-pockets nodes in the future ope=
ns up all sorts of centralization/power-corporation issues that is contrary=
 to the Bitcoin concept.=A0 It is in everyone's best interest to make it as=
 easy as possible for anyone to act as a full node (if possible).=A0 As suc=
h, I believe that the current system of minimizing TxOut size is the right =
one.=A0 TxIns take up 0 bytes space in the long-run when taking into accoun=
t any blockchain pruning/snapshot idea (except for nLocktime/seq transactio=
ns where the TxIn might have to be saved).=A0 =0A=0A-Alan=0A=0A=0A=0A=0A=0A=
On 12/18/2011 12:09 PM, theymos wrote: =0AOn Sat, Dec 17, 2011, at 05:27 PM=
, Jordan Mack wrote: =0A>I don't like the idea of a header only client, unl=
ess this is just an=0Ainterim action until the full block chain is download=
ed in the=0Abackground. Development of these types of clients is probably=
=0Ainevitable, but I believe that this breaks the most fundamental=0Aaspect=
s of Bitcoin's security model. If a client has only headers, it=0Acannot do=
 full verification, and it is trusting the data from random=0Aanonymous pee=
rs. =0A>A headers-only client is much better than trusting anyone, since an=
=0Aattacker needs >50% of the network's computational power to trick=0Asuch=
 clients. For everyone to keep being a full node, hardware costs would need=
 to=0Aconstantly go down enough for all nodes to be able to handle enough=
=0Atransactions to meet demand. If hardware doesn't become cheap enough=0Aq=
uickly enough, either some people would be unable to handle being full=0Ano=
des, or the max block size wouldn't rise enough to meet demand and=0Atransa=
ction fees would become noncompetitive. -----------------------------------=
-------------------------------------------=0ALearn Windows Azure Live!  Tu=
esday, Dec 13, 2011=0AMicrosoft is holding a special Learn Windows Azure tr=
aining event for =0Adevelopers. It will provide a great way to learn Window=
s Azure and what it =0Aprovides. You can attend the event by watching it st=
reamed LIVE online.  =0ALearn more at http://p.sf.net/sfu/ms-windowsazure=
=0A_______________________________________________=0ABitcoin-development ma=
iling list Bitcoin-development@lists.sourceforge.net https://lists.sourcefo=
rge.net/lists/listinfo/bitcoin-development =0A=0A--------------------------=
----------------------------------------------------=0ALearn Windows Azure =
Live!=A0 Tuesday, Dec 13, 2011=0AMicrosoft is holding a special Learn Windo=
ws Azure training event for =0Adevelopers. It will provide a great way to l=
earn Windows Azure and what it =0Aprovides. You can attend the event by wat=
ching it streamed LIVE online.=A0 =0ALearn more at http://p.sf.net/sfu/ms-w=
indowsazure=0A_______________________________________________=0ABitcoin-dev=
elopment mailing list=0ABitcoin-development@lists.sourceforge.net=0Ahttps:/=
/lists.sourceforge.net/lists/listinfo/bitcoin-development
--285087016-2030097772-1324234074=:548
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>Has anyone=
 considered 'snapshot' frames (blocks).</span></div><div><br><span></span><=
/div><div><span>Message to node:</span></div><div><br><span></span></div><d=
iv><span>getsnapshot: hash</span></div><div><br><span></span></div><div><sp=
an>Node responds with a 'block' message.</span></div><div><br><span></span>=
</div><div><span>Then the hash for that particular snapshot is hardcoded in=
to the sourcecode. It would replace the checkpoints and use the last hash i=
n that list.</span></div><div><br><span></span></div><div><span>Validating =
blocks is pretty fast right up until block 135k, which is where time taken =
balloons and starts become exponentially slower. As blockchain grows linear=
ly, resources needed grows exponentially if you think about it.<br></span><=
/div><div><br></div>  <div style=3D"font-family: times new roman, new
 york, times, serif; font-size: 12pt;"> <div style=3D"font-family: times ne=
w roman, new york, times, serif; font-size: 12pt;"> <font face=3D"Arial" si=
ze=3D"2"> <hr size=3D"1">  <b><span style=3D"font-weight:bold;">From:</span=
></b> Alan Reiner &lt;etotheipi@gmail.com&gt;<br> <b><span style=3D"font-we=
ight: bold;">To:</span></b> bitcoin-development@lists.sourceforge.net <br> =
<b><span style=3D"font-weight: bold;">Sent:</span></b> Sunday, December 18,=
 2011 6:06 PM<br> <b><span style=3D"font-weight: bold;">Subject:</span></b>=
 Re: [Bitcoin-development] Protocol extensions<br> </font> <br>=0A<meta htt=
p-equiv=3D"x-dns-prefetch-control" content=3D"off"><div id=3D"yiv655927743"=
>=0A=0A  =0A=0A    =0A  =0A  <div>=0A    The whole point of having headers =
built at a constant size and=0A    generation rate is to minimize the amoun=
t of data needed to=0A    "understand" of the blockchain while simultaneous=
ly maximizing=0A    integrity/security in the presence of untrusted nodes.&=
nbsp; Barring the=0A    50%-attack, you only need a couple honest nodes out=
 of 50 to stay=0A    safe (as long as you're waiting for your 6 confirmatio=
ns).&nbsp;&nbsp; In=0A    fact, I would argue that a full node (Satoshi cli=
ent), has the same=0A    level of security as a headers-only client... beca=
use they both base=0A    <b>all</b> their verification decisions on computa=
tions that end=0A    with comparing hashes to the longest-chain headers.<br=
>=0A    <br>=0A    In the case that an attacker figures out how to isolate =
your node=0A    entirely and start feeing you poisoned blocks, then you are=
=0A    vulnerable with any kind of node, full or lightweight.&nbsp; I don't=
 see=0A    where the reduced security is.&nbsp; <br>=0A    <br>=0A    The o=
nly issue I see is that a truly light-weight, headers-only node=0A    will =
be having to download an entire block to get one transaction it=0A    needs=
.&nbsp; This would be significantly alleviated if nodes can start=0A    req=
uesting merkle-trees directly, even without=0A    merkle-branch-pruning. &n=
bsp; If a node can ask for a tx and the=0A    tx-hash-list of the block tha=
t incorporated that tx,&nbsp; he can easily=0A    verify his tx against his=
 no-need-to-trust-anyone headers, and=0A    doesn't have to download MBs fo=
r every one.&nbsp; <br>=0A    <br>=0A    As for blockchain pruning... I thi=
nk it's absolutely critical to=0A    find a way to do this, <i>for all node=
s</i>.&nbsp; I am swayed by Dan=0A    Kaminsky's scalability warnings, and =
my instinct tells me that=0A    leaving full verification to a select few d=
eep-pockets nodes in the=0A    future opens up all sorts of centralization/=
power-corporation issues=0A    that is contrary to the Bitcoin concept.&nbs=
p; It is in everyone's best=0A    interest to make it as easy as possible f=
or <i>anyone</i> to act as=0A    a full node (if possible).&nbsp; As such, =
I believe that the current=0A    system of minimizing TxOut size is the rig=
ht one.&nbsp; TxIns take up 0=0A    bytes space in the long-run when taking=
 into account any blockchain=0A    pruning/snapshot idea (except for nLockt=
ime/seq transactions where=0A    the TxIn might have to be saved).&nbsp; <b=
r>=0A    <br>=0A    -Alan<br>=0A    <br>=0A    <br>=0A    <br>=0A    <br>=
=0A    <br>=0A    On 12/18/2011 12:09 PM, theymos wrote:=0A    <blockquote =
type=3D"cite">=0A      <pre>On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack =
wrote:=0A</pre>=0A      <blockquote type=3D"cite">=0A        <pre>I don't l=
ike the idea of a header only client, unless this is just an=0Ainterim acti=
on until the full block chain is downloaded in the=0Abackground. Developmen=
t of these types of clients is probably=0Ainevitable, but I believe that th=
is breaks the most fundamental=0Aaspects of Bitcoin's security model. If a =
client has only headers, it=0Acannot do full verification, and it is trusti=
ng the data from random=0Aanonymous peers.=0A</pre>=0A      </blockquote>=
=0A      <pre>A headers-only client is much better than trusting anyone, si=
nce an=0Aattacker needs &gt;50% of the network's computational power to tri=
ck=0Asuch clients.=0A=0AFor everyone to keep being a full node, hardware co=
sts would need to=0Aconstantly go down enough for all nodes to be able to h=
andle enough=0Atransactions to meet demand. If hardware doesn't become chea=
p enough=0Aquickly enough, either some people would be unable to handle bei=
ng full=0Anodes, or the max block size wouldn't rise enough to meet demand =
and=0Atransaction fees would become noncompetitive.=0A=0A------------------=
------------------------------------------------------------=0ALearn Window=
s Azure Live!  Tuesday, Dec 13, 2011=0AMicrosoft is holding a special Learn=
 Windows Azure training event for =0Adevelopers. It will provide a great wa=
y to learn Windows Azure and what it =0Aprovides. You can attend the event =
by watching it streamed LIVE online.  =0ALearn more at http://p.sf.net/sfu/=
ms-windowsazure=0A_______________________________________________=0ABitcoin=
-development mailing list=0A<a rel=3D"nofollow" class=3D"yiv655927743moz-tx=
t-link-abbreviated" ymailto=3D"mailto:Bitcoin-development@lists.sourceforge=
.net" target=3D"_blank" href=3D"mailto:Bitcoin-development@lists.sourceforg=
e.net">Bitcoin-development@lists.sourceforge.net</a>=0A<a rel=3D"nofollow" =
class=3D"yiv655927743moz-txt-link-freetext" target=3D"_blank" href=3D"https=
://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.=
sourceforge.net/lists/listinfo/bitcoin-development</a>=0A</pre>=0A    </blo=
ckquote>=0A    <br>=0A  </div>=0A=0A</div><meta http-equiv=3D"x-dns-prefetc=
h-control" content=3D"on"><br>---------------------------------------------=
---------------------------------<br>Learn Windows Azure Live!&nbsp; Tuesda=
y, Dec 13, 2011<br>Microsoft is holding a special Learn Windows Azure train=
ing event for <br>developers. It will provide a great way to learn Windows =
Azure and what it <br>provides. You can attend the event by watching it str=
eamed LIVE online.&nbsp; <br>Learn more at <a href=3D"http://p.sf.net/sfu/m=
s-windowsazure" target=3D"_blank">http://p.sf.net/sfu/ms-windowsazure</a><b=
r>_______________________________________________<br>Bitcoin-development ma=
iling list<br><a ymailto=3D"mailto:Bitcoin-development@lists.sourceforge.ne=
t" href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br><a href=3D"https://lists.sourceforge.net=
/lists/listinfo/bitcoin-development"
 target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-dev=
elopment</a><br><br><br> </div> </div>  </div></body></html>
--285087016-2030097772-1324234074=:548--