Tamas Blummer [ARCHIVE] on Nostr: 📅 Original date posted:2014-04-07 📝 Original message:Once a single transaction ...
📅 Original date posted:2014-04-07
📝 Original message:Once a single transaction in pruned in a block, the block is no longer eligible to be served to other nodes.
Which transactions are pruned can be rather custom e.g. even depending on the wallet(s) of the node,
therefore I guess it is more handy to return some bitmap of pruned/full blocks than ranges.
Tamas Blummer
http://bitsofproof.com
On 07.04.2014, at 20:49, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
>> BTW, did we already agree on the service bits for an archive node?
>
> I'm still very concerned that a binary archive bit will cause extreme
> load hot-spotting and the kind of binary "Use lots of resources YES or
> NO" I think we're currently suffering some from, but at that point
> enshrined in the protocol.
>
> It would be much better to extend the addr messages so that nodes can
> indicate a range or two of blocks that they're serving, so that all
> nodes can contribute fractionally according to their means. E.g. if
> you want to offer up 8 GB of distributed storage and contribute to the
> availability of the blockchain, without having to swollow the whole
> 20, 30, 40 ... gigabyte pill.
>
> Already we need that kind of distributed storage for the most recent
> blocks to prevent extreme bandwidth load on archives, so extending it
> to arbitrary ranges is only more complicated because there is
> currently no room to signal it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/e37eb022/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/e37eb022/attachment.sig>;
📝 Original message:Once a single transaction in pruned in a block, the block is no longer eligible to be served to other nodes.
Which transactions are pruned can be rather custom e.g. even depending on the wallet(s) of the node,
therefore I guess it is more handy to return some bitmap of pruned/full blocks than ranges.
Tamas Blummer
http://bitsofproof.com
On 07.04.2014, at 20:49, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
>> BTW, did we already agree on the service bits for an archive node?
>
> I'm still very concerned that a binary archive bit will cause extreme
> load hot-spotting and the kind of binary "Use lots of resources YES or
> NO" I think we're currently suffering some from, but at that point
> enshrined in the protocol.
>
> It would be much better to extend the addr messages so that nodes can
> indicate a range or two of blocks that they're serving, so that all
> nodes can contribute fractionally according to their means. E.g. if
> you want to offer up 8 GB of distributed storage and contribute to the
> availability of the blockchain, without having to swollow the whole
> 20, 30, 40 ... gigabyte pill.
>
> Already we need that kind of distributed storage for the most recent
> blocks to prevent extreme bandwidth load on archives, so extending it
> to arbitrary ranges is only more complicated because there is
> currently no room to signal it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/e37eb022/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/e37eb022/attachment.sig>;