From: Peter Todd <pete@petertodd•org>
To: Pieter Wuille <pieter.wuille@gmail•com>, Wladimir <laanwj@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
Date: Thu, 10 Apr 2014 07:43:21 -0400 [thread overview]
Message-ID: <9b2cddd4-0c46-422e-ac34-0598d47b6a75@email.android.com> (raw)
In-Reply-To: <CAPg+sBjWL_hKhWW-6i=WAHnx+Ue5JE=A9RrxnWuAYOXw19qiDw@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 10 April 2014 07:32:44 GMT-04:00, Pieter Wuille <pieter.wuille@gmail•com> wrote:
>There were earlier discussions.
>
>The two ideas were either using one or a few service bits to indicate
>availability of blocks, or to extend addr messages with some flags to
>indicate this information.
>
>I wonder whether we can't have a hybrid: bits to indicate general
>degree of availability of blocks (none, only recent, everything), but
>indicate actual availability only upon actually connecting (through a
>"version" extension, or - preferably - a separate message). Reason is
>that the actual blocks available are likely to change frequently (if
>you keep the last week of blocks, a 3-day old addr entry will have
>quite outdated information), and not that important to actual peer
>selection - only to drive the decision which blocks to ask after
>connection.
Why not just put an expiration date on that information and delay deletion until the expiration is reached?
Also, its worth noting how the node bit solution you proposed can be done as a gradual upgrade path for SPV client. From the perspective of nodes that don't know about it they just see the pruned nodes as SPV nodes without any chain data at all. The only issue would be if large numbers of uses turned off their full nodes, but that's a possibility regardless. Done with partial UTXO set mode this may even result in an eventual increase in the number of full nodes.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFQBAEBCgA6BQJTRoPZMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhetrCACA02EJQ0VpcYvafuNc
7pvqMVeirJRu3Uv7Wy8rcl9jW5irM5fmNdznARtv2vwpEZN7MU0wp3ZY1FYOCv2f
PvWC7DBCSBs2BuyGkvPuwnXEppTrYmWFT3qjg+99lF1IlOV4yWFacja2RGDuJkea
fYUkODosHJjFVcXi5aMkBPQ5sOFdlUVbC94YV4d4PDSmF2fHLGG8uEfEweYb6Pv+
gj1CsfuAWf8DWzygDeL8x/wOG9HeqYqEbjxyOb9hxlp1ByUof+4WJtz3QfGsR2Xt
fvkmgS8vkUxSIZorMdypj7oLBOnfDW1bEK5He2SlqPdYi5FEQusZ/jMMX3Fw74GV
fJKt
=Wyv8
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-04-10 11:43 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-09 15:29 Wladimir
2014-04-09 15:37 ` Tamas Blummer
2014-04-09 15:41 ` Natanael
2014-04-09 15:54 ` Gregory Maxwell
2014-04-09 16:09 ` Thomas Voegtlin
2014-04-09 19:25 ` Wladimir
2014-04-10 6:04 ` Tamas Blummer
2014-04-10 11:09 ` Wladimir
2014-04-10 11:29 ` Mike Hearn
2014-04-10 11:32 ` Pieter Wuille
2014-04-10 11:43 ` Peter Todd [this message]
2014-04-10 11:50 ` Gregory Maxwell
2014-04-10 11:54 ` Peter Todd
2014-04-10 17:30 ` Tier Nolan
2014-04-11 16:54 ` Gregory Maxwell
2014-05-04 21:11 ` Tier Nolan
2014-04-09 17:31 ` Wladimir
2014-04-09 15:42 ` Brian Hoffman
2014-04-09 15:57 ` Gregory Maxwell
2014-04-09 16:09 ` Tamas Blummer
2014-04-09 15:47 ` Mark Friedenbach
2014-04-09 16:27 ` Tamas Blummer
2014-04-09 17:46 ` Peter Todd
2014-04-09 17:50 ` Tamas Blummer
2014-04-09 18:00 ` Mike Hearn
2014-04-09 18:19 ` Wladimir
2014-04-09 18:35 ` Justus Ranvier
2014-04-09 18:46 ` Wladimir
2014-04-09 18:50 ` Gregory Maxwell
2014-04-09 18:58 ` Justus Ranvier
2014-04-09 19:33 ` Gregory Maxwell
2014-04-09 20:12 ` slush
2014-04-09 20:31 ` slush
2014-04-09 20:36 ` Mark Friedenbach
2014-04-09 21:04 ` Gregory Maxwell
2014-04-09 20:37 ` Wladimir
2014-04-09 20:35 ` Wladimir
2014-04-09 20:50 ` slush
2014-04-09 20:55 ` Laszlo Hanyecz
2014-04-10 6:38 ` Mike Hearn
2014-04-10 6:50 ` Wladimir
2014-04-10 7:09 ` Mike Hearn
2014-04-10 9:33 ` Peter Todd
2014-04-10 7:10 ` Tamas Blummer
2014-04-10 9:17 ` Mike Hearn
2014-04-10 9:39 ` Tamas Blummer
2014-04-10 10:40 ` Mike Hearn
2014-04-10 10:44 ` Tamas Blummer
2014-04-10 11:36 ` Peter Todd
2014-04-10 11:45 ` Mike Hearn
2014-04-10 11:52 ` Peter Todd
2014-04-10 9:47 ` Peter Todd
2014-04-09 18:04 ` Peter Todd
[not found] ` <CA+s+GJBpvqqu=XEojyekx5su+JfYLwz+zsbo8L0=5t6s-_b33w@mail.gmail.com>
2014-04-09 17:35 ` [Bitcoin-development] Fwd: " Wladimir
2014-04-09 16:03 ` [Bitcoin-development] " Peter Todd
2014-04-09 17:33 ` Alex Mizrahi
2014-04-09 17:38 ` Wladimir
2014-04-09 17:38 ` Peter Todd
2014-04-09 18:35 ` Kevin
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=9b2cddd4-0c46-422e-ac34-0598d47b6a75@email.android.com \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=laanwj@gmail$(echo .)com \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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