public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Aymeric Vitte <vitteaymeric@gmail.com>
To: Jonas Schnelli <dev@jonasschnelli.ch>, Luke Dashjr <luke@dashjr.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits
Date: Thu, 11 May 2017 22:36:33 +0200	[thread overview]
Message-ID: <f0417e14-fb2c-3572-f8e9-06c7adbf3d2b@gmail.com> (raw)
In-Reply-To: <61C68F26-AD36-4AB4-A065-020BD549CEBC@jonasschnelli.ch>

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

Sorry again, is this discussion really serious?

In this thread, previous ones or others, the level of approximation is
obvious, often shadowed by useless maths/papers and strange calculations
that are not helping, at the end nobody knows what would happen "if",
how far the chain can roll back, etc

Then don't make pruning the default if it's the current concern, pruning
is of no use

Again, the priority should be to scale the full nodes


Le 11/05/2017 à 22:10, Jonas Schnelli via bitcoin-dev a écrit :
>> Is 49 days particularly useful? Would it be a problem to instead leave both-
>> bits undefined? I'm thinking this might be better as a way to indicate "7
>> days, plus a deterministically chosen set of historical blocks"…
> I though two service bits allow three states and we should define all three combinations.
> But I guess an adequate „definition“ would be to reserve it for future „definitions“.
> Or use Gregory's proposal of min 2016*2 blocks & keep it „undefined“ for now.
>
> 49 days was chosen to allow SPV peers to be „offline“ for a month and still be capable to catch-up with a peer pruned to a datadir of ~10GB.
>
>> This is technically true right now, but as soon as segwit activates, it will
>> no longer be... Therefore, I suggest striking it from the BIP, expounding on
>> it in greater detail, or making it true for the longer term.
> AFAIK Core does also guaranteed the 288 blocks post segwit activation:
> https://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa62400893f4358c5ae/src/validation.h#L204
> But maybe I’m confused.
>
>>> Peers following this BIP SHOULD connect a limited amount of their available
>>> outbound connections to peers signaling one or both of the
>>> NODE_NETWORK_LIMITED_* service bits if they expect to request less blocks
>>> than the signaled number.
>> This isn't entirely clear whether it refers to peers downloading blocks, or
>> peers serving them. (I assume the former, but it should be clarified.)
> Indeed. I’ll try to make that more clear.
>
>>> Light clients (and such) who are not checking the nServiceFlags (service
>>> bits) from a relayed addr-message may unwillingly connect to a pruned peer
>>> and ask for (filtered) blocks at a depth below their pruned depth.
>> Wouldn't this already be a problem, without the BIP?
> AFAIK, Core does currently only relay NODE_NETWORK addresses.
> But yes, It may be a problem already.
>
> </jonas>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms


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

  reply	other threads:[~2017-05-11 20:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-11 15:13 [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits Jonas Schnelli
2017-05-11 18:17 ` Gregory Maxwell
2017-05-11 19:24 ` Luke Dashjr
2017-05-11 20:10   ` Jonas Schnelli
2017-05-11 20:36     ` Aymeric Vitte [this message]
2017-05-11 21:05       ` Eric Voskuil
2017-05-12  2:22 ` Gregory Maxwell

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=f0417e14-fb2c-3572-f8e9-06c7adbf3d2b@gmail.com \
    --to=vitteaymeric@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dev@jonasschnelli.ch \
    --cc=luke@dashjr.org \
    /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