Tamas Blummer [ARCHIVE] on Nostr: 📅 Original date posted:2014-04-08 📝 Original message:Specialization of nodes is ...
📅 Original date posted:2014-04-08
📝 Original message:Specialization of nodes is ongoing most prominent with SPV wallets and mining.
There is a need I see on my own business for software that is able to serve multiple wallets, and is multi tiered,
so the world facing P2P node can be in a DMZ. I target them with a hybrid model that is SPV plus mempool transaction validation
against UTXO and use ‘reference’ implementations as border router. I think that this setup will be common for enterprises
and hence push for a stripped down ‘reference’ border router without wallet, payment protocol, GUI, RPC calls here.
That border router could also serve as archive node evtl. also offering blocks at bulk e.g. through http.
Enterprises that run a multi tiered environment have the bandwith to serve as archives.
Tamas Blummer
http://bitsofproof.com
On 08.04.2014, at 05:44, Jeff Garzik <jgarzik at bitpay.com> wrote:
> Being Mr. Torrent, I've held open the "80% serious" suggestion to
> simply refuse to serve blocks older than X (3 months?).
>
> That forces download by other means (presumably torrent).
>
> I do not feel it is productive for any nodes on the network to waste
> time/bandwidth/etc. serving static, ancient data. There remain, of
> course, issues of older nodes and "getting the word out" that prevents
> this switch from being flipped on tomorrow.
>
>
>
> On Mon, Apr 7, 2014 at 2:49 PM, 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.
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/45cfae92/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/20140408/45cfae92/attachment.sig>;
📝 Original message:Specialization of nodes is ongoing most prominent with SPV wallets and mining.
There is a need I see on my own business for software that is able to serve multiple wallets, and is multi tiered,
so the world facing P2P node can be in a DMZ. I target them with a hybrid model that is SPV plus mempool transaction validation
against UTXO and use ‘reference’ implementations as border router. I think that this setup will be common for enterprises
and hence push for a stripped down ‘reference’ border router without wallet, payment protocol, GUI, RPC calls here.
That border router could also serve as archive node evtl. also offering blocks at bulk e.g. through http.
Enterprises that run a multi tiered environment have the bandwith to serve as archives.
Tamas Blummer
http://bitsofproof.com
On 08.04.2014, at 05:44, Jeff Garzik <jgarzik at bitpay.com> wrote:
> Being Mr. Torrent, I've held open the "80% serious" suggestion to
> simply refuse to serve blocks older than X (3 months?).
>
> That forces download by other means (presumably torrent).
>
> I do not feel it is productive for any nodes on the network to waste
> time/bandwidth/etc. serving static, ancient data. There remain, of
> course, issues of older nodes and "getting the word out" that prevents
> this switch from being flipped on tomorrow.
>
>
>
> On Mon, Apr 7, 2014 at 2:49 PM, 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.
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/45cfae92/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/20140408/45cfae92/attachment.sig>;