> Personally I consider this counterproductive. Apart from the complexity,
it’s not healthy. And the chain grows linearly with storage cost falling
exponentially, leading to a straightforward conclusion.
The motivation for this change is not to encourage full archival nodes to
prune, but to make i
On Sun, Feb 28, 2021 at 10:18 AM Leo Wandersleb via bitcoin-dev
mailto:bitcoin-dev@lists.linuxfoundation.org> > wrote:
> Only headers need to be downloaded sequentially so downloading relevant
> blocks from one node is totally possible with gaps in between.
In fact this is exactly how lib
Something to consider adding to this proposal is to keep the idea of
pruning - i.e. retain a sequentially uninterrupted number of the most
recent blocks.
Many users do not run a node for entirely altruistic reasons - they do so,
at least in part, because it allows them to use their wallets private
Only headers need to be downloaded sequentially so downloading relevant blocks
from one node is totally possible with gaps in between.
On 2/27/21 4:10 AM, Igor Cota via bitcoin-dev wrote:
> Hi Keagan,
>
> I had a very similar idea. The only difference being for the node to decide on
> a range of b
On Sat, Feb 27, 2021 at 09:19:34AM -1000, David A. Harding via bitcoin-dev
wrote:
> - Discussion thread 1:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014186.html
Two particularly useful emails from that thread are:
- https://lists.linuxfoundation.org/pipermail/bitcoin-
On Fri, 26 Feb 2021 at 20:57, Keagan McClelland via bitcoin-dev
wrote:
> The goals are to increase data redundancy in a way that more uniformly shares
> the load across nodes, alleviating some of the pressure of full archive nodes
> on the IBD problem. I am working on a draft BIP for this propo
On Sat, 27 Feb 2021 at 22:09, Yuval Kogman wrote:
> and there is work on fountain codes. There is also some work on
apologies, the first half of this line should have been deleted as it
was worked into the next sentence.
___
bitcoin-dev mailing list
bit
On Fri, Feb 26, 2021 at 11:40:35AM -0700, Keagan McClelland via bitcoin-dev
wrote:
> Hi all,
Hi Keagan,
> 4. Once the node's IBD is complete it would advertise this as a peer
> service, advertising its seed and threshold, so that nodes could
> deterministically deduce which of its peers had whic
Hi Keagan,
I had a very similar idea. The only difference being for the node to decide
on a range of blocks to keep beforehand, rather than making the decision
block-by-block like you suggest.
I felt the other nodes would be better served by ranges due to the
sequential nature of IBD. Perhaps thi
Hi all,
I've been thinking for quite some time about the problem of pruned nodes
and ongoing storage costs for full nodes. One of the things that strikes me
as odd is that we only really have two settings.
A. Prune everything except the most recent blocks, down to the cache size
B. Keep everythin
10 matches
Mail list logo
