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 ) 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: <82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.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 To: "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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 =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
Has anyone= considered 'snapshot' frames (blocks).

<= /div>
Message to node:

getsnapshot: hash

Node responds with a 'block' message.

=
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.

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.
<= /div>

From: Alan Reiner <etotheipi@gmail.com>
To: bitcoin-development@lists.sourceforge.net
= Sent: Sunday, December 18,= 2011 6:06 PM
Subject:= Re: [Bitcoin-development] Protocol extensions
=0A
=0A=0A =0A=0A =0A =0A
=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).   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 all their verification decisions on computa= tions that end=0A with comparing hashes to the longest-chain headers.=0A
=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.  I don't= see=0A where the reduced security is. 
=0A
=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= .  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,  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. 
=0A
=0A As for blockchain pruning... I thi= nk it's absolutely critical to=0A find a way to do this, for all node= s.  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 anyone to act as=0A a full node (if possible).  As such, = I believe that the current=0A system of minimizing TxOut size is the rig= ht one.  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).  =0A
=0A -Alan
=0A
=0A
=0A
=0A
= =0A
=0A On 12/18/2011 12:09 PM, theymos wrote:=0A
=0A 
On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack =
wrote:=0A
=0A
=0A 
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
=0A
= =0A 
A headers-only client is much better than trusting anyone, si=
nce an=0Aattacker needs >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=0ABitcoin-development@lists.sourceforge.net=0Ahttps://lists.=
sourceforge.net/lists/listinfo/bitcoin-development=0A
=0A =0A
=0A
=0A=0A

---------------------------------------------= ---------------------------------
Learn Windows Azure Live!  Tuesda= y, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure train= ing event for
developers. It will provide a great way to learn Windows = Azure and what it
provides. You can attend the event by watching it str= eamed LIVE online. 
Learn more at http://p.sf.net/sfu/ms-windowsazure_______________________________________________
Bitcoin-development ma= iling list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-dev= elopment


--285087016-2030097772-1324234074=:548--