Jeff Garzik [ARCHIVE] on Nostr: š Original date posted:2013-05-06 š Original message:On Mon, May 6, 2013 at ...
š
Original date posted:2013-05-06
š Original message:On Mon, May 6, 2013 at 12:12 PM, Peter Todd <pete at petertodd.org> wrote:
> I've noticed on my Android phone how it often takes quite awhile to find
> a peer that will actually accept an incoming connection, which isn't
> surprising really: why should a regular node care about responding to
> SPV nodes quickly?
>
> For fast startup you would be better served with dedicated nodes that
> are backed by fast hardware and high bandwidth internet connections.
> You can discourage non-SPV use by refusing to relay full blocks.
>
> You can have trusted individuals vouch for these special servers with
> SSL certificates so you run less of a risk of connecting to a malicious
> one trying to limit what information you see. For the initial
> implementation, maybe just make a quick SSL accessible service with HTTP
> GET so you don't have to integrate SSL into the network protocol and
> have a couple of these HTTP GETable servers running. (IE, the trust is
> actually that the SPV seed is honest)
>
> Security will be no worse than before - if any one server/seed is honest
> you're ok - and hopefully better due to the accountability. Obviously
Indeed, the DNS seeds are just servers run by trusted individuals anyway.
In either case, bitcoinj definitely wants fixing for its over-reliance
on DNS seeds. This has been noted as a problem for a while.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com
š Original message:On Mon, May 6, 2013 at 12:12 PM, Peter Todd <pete at petertodd.org> wrote:
> I've noticed on my Android phone how it often takes quite awhile to find
> a peer that will actually accept an incoming connection, which isn't
> surprising really: why should a regular node care about responding to
> SPV nodes quickly?
>
> For fast startup you would be better served with dedicated nodes that
> are backed by fast hardware and high bandwidth internet connections.
> You can discourage non-SPV use by refusing to relay full blocks.
>
> You can have trusted individuals vouch for these special servers with
> SSL certificates so you run less of a risk of connecting to a malicious
> one trying to limit what information you see. For the initial
> implementation, maybe just make a quick SSL accessible service with HTTP
> GET so you don't have to integrate SSL into the network protocol and
> have a couple of these HTTP GETable servers running. (IE, the trust is
> actually that the SPV seed is honest)
>
> Security will be no worse than before - if any one server/seed is honest
> you're ok - and hopefully better due to the accountability. Obviously
Indeed, the DNS seeds are just servers run by trusted individuals anyway.
In either case, bitcoinj definitely wants fixing for its over-reliance
on DNS seeds. This has been noted as a problem for a while.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com