public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Protocol extensions
Date: Sun, 18 Dec 2011 10:47:54 -0800 (PST)	[thread overview]
Message-ID: <1324234074.548.YahooMailNeo@web121006.mail.ne1.yahoo.com> (raw)
In-Reply-To: <4EEE2B91.1050908@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5188 bytes --]

Has anyone considered 'snapshot' frames (blocks).

Message to node:

getsnapshot: hash

Node responds with a 'block' message.

Then the hash for that particular snapshot is hardcoded into the sourcecode. It would replace the checkpoints and use the last hash in 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 linearly, resources needed grows exponentially if you think about it.



________________________________
 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
 

The whole point of having headers built at a constant size and 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.  Barring the 50%-attack, you only need a couple honest nodes out of 50 to stay safe (as long as you're waiting for your 6 confirmations).   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 with comparing hashes to the longest-chain headers.

In the case that an attacker figures out how to isolate your node
    entirely and start feeing you poisoned blocks, then you are
    vulnerable with any kind of node, full or lightweight.  I don't see
    where the reduced security is.  

The only issue I see is that a truly light-weight, headers-only node
    will be having to download an entire block to get one transaction it
    needs.  This would be significantly alleviated if nodes can start
    requesting merkle-trees directly, even without
    merkle-branch-pruning.   If a node can ask for a tx and the
    tx-hash-list of the block that incorporated that tx,  he can easily
    verify his tx against his no-need-to-trust-anyone headers, and
    doesn't have to download MBs for every one.  

As for blockchain pruning... I think it's absolutely critical to
    find a way to do this, for all nodes.  I am swayed by Dan Kaminsky's scalability warnings, and my instinct tells me that leaving full verification to a select few deep-pockets nodes in the future opens up all sorts of centralization/power-corporation issues that is contrary to the Bitcoin concept.  It is in everyone's best interest to make it as easy as possible for anyone to act as a full node (if possible).  As such, I believe that the current system of minimizing TxOut size is the right one.  TxIns take up 0 bytes space in the long-run when taking into account any blockchain pruning/snapshot idea (except for nLocktime/seq transactions where the TxIn might have to be saved).  

-Alan





On 12/18/2011 12:09 PM, theymos wrote: 
On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote: 
>I don't like the idea of a header only client, unless this is just an
interim action until the full block chain is downloaded in the
background. Development of these types of clients is probably
inevitable, but I believe that this breaks the most fundamental
aspects of Bitcoin's security model. If a client has only headers, it
cannot do full verification, and it is trusting the data from random
anonymous peers. 
>A headers-only client is much better than trusting anyone, since an
attacker needs >50% of the network's computational power to trick
such clients. For everyone to keep being a full node, hardware costs would need to
constantly go down enough for all nodes to be able to handle enough
transactions to meet demand. If hardware doesn't become cheap enough
quickly enough, either some people would be unable to handle being full
nodes, or the max block size wouldn't rise enough to meet demand and
transaction fees would become noncompetitive. ------------------------------------------------------------------------------
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training 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 streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development 

------------------------------------------------------------------------------
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training 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 streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2: Type: text/html, Size: 7359 bytes --]

  reply	other threads:[~2011-12-18 18:48 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-17  7:41 [Bitcoin-development] Protocol extensions Eric Lombrozo
2011-12-17 13:13 ` Michael Grønager
2011-12-17 13:37   ` Christian Decker
     [not found]     ` <CABsx9T0puk3CWH1cfNHMSVEoCPaLJJWNJ+H5ObCERZrzMbrTyA@mail.gmail.com>
2011-12-17 19:06       ` Gavin Andresen
2011-12-17 21:49         ` theymos
2011-12-18  0:44           ` Jordan Mack
2011-12-18  1:07             ` Jeff Garzik
2011-12-18  1:27           ` Jordan Mack
2011-12-18 14:16             ` Andy Parkins
2011-12-18 17:09             ` theymos
2011-12-18 18:06               ` Alan Reiner
2011-12-18 18:47                 ` Amir Taaki [this message]
2011-12-18 19:37               ` Jorge Timón
2011-12-17 19:28     ` Gregory Maxwell
2011-12-17 20:34       ` Christian Decker
2011-12-18 21:19     ` Stefan Thomas
2011-12-19 21:43       ` Jordan Mack
2011-12-20  9:10         ` Wladimir
2011-12-20 10:44           ` Nicolas Fischer
2011-12-21  0:47         ` Kyle Henderson
2011-12-21  8:50       ` Michael Grønager
2011-12-21 11:42         ` Eric Lombrozo
2011-12-21 12:41           ` Michael Grønager
2011-12-21 16:10             ` Christian Decker
2011-12-22  9:18               ` Michael Grønager
2011-12-22 10:12               ` Andy Parkins
2011-12-22 10:27                 ` Michael Grønager
2011-12-22 11:52                   ` Andy Parkins
2011-12-22 12:14                     ` Joel Joonatan Kaartinen
2011-12-22 12:26                       ` Christian Decker
2011-12-22 12:42                       ` Michael Grønager
2011-12-22 14:46                       ` Andy Parkins
2011-12-25  2:55                         ` Zell Faze
2011-12-21 17:17         ` Jordan Mack
2011-12-22  9:19           ` Michael Grønager
2011-12-21  6:19 Eric Lombrozo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1324234074.548.YahooMailNeo@web121006.mail.ne1.yahoo.com \
    --to=zgenjix@yahoo.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox