public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Andy Parkins <andyparkins@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] HTTP REST API for bitcoind
Date: Tue, 23 Jul 2013 06:17:28 -0400	[thread overview]
Message-ID: <20130723101728.GA2116@savin> (raw)
In-Reply-To: <201307231100.24538.andyparkins@gmail.com>

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

On Tue, Jul 23, 2013 at 11:00:24AM +0100, Andy Parkins wrote:
> > Increasing the resource usage by SPV clients on full nodes is undesirable;
> 
> I don't think that's thinking big enough.  What I imagine is that making it 
> easier and easier to store a partial blockchain would result in lower demand 
> on full nodes.

Read my proposal for "Partial UTXO" mode:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02511.html

> I might run a client that has only fetched blocks that contain transactions 
> needed to verify my balances, right back to the genesis block.  That will be 
> some small subset of the block chain and will take me very little resource to 
> maintain.  I join the network and am my client is willing to verify based on 
> information I have, or supply (by REST or bitcoin protocol) blocks.  Imagine 
> then that everyone with a wallet were doing this.  The blockchain would be 
> distributed massively.  Obviously the miners would still be keeping the entire 
> chain, but we'd have a lot more nodes in the network, each contributing a 
> little bit and so reducing the load on the full nodes.

Actually the really scary thing about partial UTXO mode is miners can
get away without keeping the entire chain provided they don't (often)
try to mine transactions spending UTXO's that they haven't verified
themselves.

They can get away with accepting blocks without checking that the UTXO's
exist, at least until enough miners do so that someone creates an
invalid block and the majority of hashing power never notices. Remember
that only with a complete UTXO set can you know that a UTXO *doesn't*
exist.

We're going to have to force miners to prove they possess the full UTXO
set in the future or the security of Bitcoin will be seriously
threatened.

> > In any case UTXO data currently requires you to have full trust in
> > whomever is providing you with it, and that situation will continue
> > until UTXO commitments are implemented - if they are implemented.
> 
> Almost; because you can go and ask someone else the same question, it's pretty 

How do you know they actually are someone else?

> easy to check if you're being lied to.  Also, it's far easier to maintain a 
> headers-only block chain.  When you fetch your relevant block subset, you can 
> easily see that they are real blocks in your headers-only blockchain; and so 
> it's pretty much impossible to lie to "give me the block containing 
> transaction X".

Do you think you have SPV or full security in that situation?

Do you know the difference?

-- 
'peter'[:-1]@petertodd.org
0000000000000070f3d118303a611e1f44ea6482a3b59a16056e69af088b1ffa

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2013-07-23 10:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22 19:42 [Bitcoin-development] HTTP REST API for bitcoind Jeff Garzik
2013-07-22 22:06 ` Michael Hendricks
2013-07-23  8:27 ` Andreas Schildbach
2013-07-23  8:45   ` Michael Gronager
2013-07-23  9:37   ` Pieter Wuille
2013-07-23  9:53     ` Michael Gronager
2013-07-23 10:17     ` Andreas Schildbach
2013-07-23 10:27       ` Pieter Wuille
2013-07-23  9:30 ` Andy Parkins
2013-07-23  9:42   ` Pieter Wuille
2013-07-23  9:52     ` Andy Parkins
2013-07-23  9:56       ` Pieter Wuille
2013-07-23 10:02         ` Andy Parkins
2013-07-23 10:06           ` Pieter Wuille
2013-07-23  9:47   ` Peter Todd
2013-07-23 10:00     ` Andy Parkins
2013-07-23 10:17       ` Peter Todd [this message]
2013-07-23 11:45         ` Andy Parkins
2013-07-23 10:19       ` Pieter Wuille
2013-07-23 10:29     ` Andreas Schildbach
2013-07-23 10:36       ` Pieter Wuille
2013-07-23 15:48         ` Michael Hendricks
2013-07-23 19:36       ` Mark Friedenbach
2013-08-10 20:30         ` Rune Kjær Svendsen

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=20130723101728.GA2116@savin \
    --to=pete@petertodd.org \
    --cc=andreas@schildbach.de \
    --cc=andyparkins@gmail.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