Peter Todd [ARCHIVE] on Nostr: š Original date posted:2015-08-19 š Original message:On Wed, Aug 19, 2015 at ...
š
Original date posted:2015-08-19
š Original message:On Wed, Aug 19, 2015 at 03:45:48PM -0700, Adam Back via bitcoin-dev wrote:
> Wouldnt the experience for SPV nodes be chaotic? If the full nodes
> are 50:50 XT and bitcoin core, then SPV clients would connect at
> random and because XT and core will diverge immediately after
> activation.
Actually not necessarily!
To my knowledge there aren't any SPV implementations that do address
caching; they all use the peer servers in a centralized fashion every
time they connect. If those peer servers are setup to only return nodes
on one side of the fork or the other, that's all they'll connect too and
they'll never see another chain.
--
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/2982e693/attachment.sig>
š Original message:On Wed, Aug 19, 2015 at 03:45:48PM -0700, Adam Back via bitcoin-dev wrote:
> Wouldnt the experience for SPV nodes be chaotic? If the full nodes
> are 50:50 XT and bitcoin core, then SPV clients would connect at
> random and because XT and core will diverge immediately after
> activation.
Actually not necessarily!
To my knowledge there aren't any SPV implementations that do address
caching; they all use the peer servers in a centralized fashion every
time they connect. If those peer servers are setup to only return nodes
on one side of the fork or the other, that's all they'll connect too and
they'll never see another chain.
--
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/2982e693/attachment.sig>