Blockchain Group [ARCHIVE] on Nostr: đź“… Original date posted:2018-08-29 đź“ť Original message:Thanks! That is what my ...
đź“… Original date posted:2018-08-29
đź“ť Original message:Thanks! That is what my main point is.
On Wed, Aug 29, 2018, 8:10 PM Eric Voskuil <eric at voskuil.org> wrote:
> The API implementation is not what is centralizing, nor is full indexation
> non-scalable. The centralization is in not running the API from a node
> under your own control. This is of course implied by the comment, “without
> the need for syncing”. In other words it is the deployment cost of the node
> that is centralizing.
>
> Yet if people relied only on bitcoind and never centralized services there
> would be *no* block explorers (and no secure light wallets), because it
> does not provide remote query and does not fully index.
>
> Block explorers and light wallets are pretty useful, so presumably some
> API must provide these features (ideally with reduced deployment cost).
> That will either be centralized or decentralized services. As such it seems
> wise to encourage the latter, as opposed to questioning whether there is
> any valid block explorer use case.
>
> e
>
>
> > On Aug 28, 2018, at 11:36, Jonas Schnelli via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Hi
> >
> > To give a critical viewpoint on a such API:
> >
> > Such APIs usually result in central validation, meaning that users trust
> API services rather the validating their own data. It break some of the
> fundamental properties of Bitcoin (avoid trusted third parties).
> > Systems or applications depending on a full indexed blockchain (a thus
> such API) do usually scale pretty bad.
> >
> > I’d like to hear some concrete use-cases for a such block explorer(ish)
> API.
> >
> > Thanks
> > —
> > Jonas
> >
> >> Am 26.08.2018 um 21:58 schrieb Blockchain Group via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
> >>
> >> Hello everyone,
> >>
> >> I am C++ & Node.js developer. I want to propose making a new Bitcoin
> API that supports fast quering of Bitcoin blocks and transactions without
> the need for syncing with all previous nodes.
> >>
> >> In a typical case where I want to build a full fleged Bitcoin explorer
> cum wallet system on my end with external APIs, I need to sync my node and
> then query for the information I need to show separately. I am proposing a
> unified method of finding/quering the blockchain data with a standardized
> template containing minimal information about the actual mined block or
> transaction yet satify the need of what I want to query.
> >>
> >> I am working on making a template and a support mechanism on Node.js. I
> want to propose it as an improvement (BIP). It will be a great help to
> future web developers who want to make something similar.
> >>
> >> Thanks
> >> Sumit Lahiri.
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180829/4a0ea125/attachment-0001.html>
đź“ť Original message:Thanks! That is what my main point is.
On Wed, Aug 29, 2018, 8:10 PM Eric Voskuil <eric at voskuil.org> wrote:
> The API implementation is not what is centralizing, nor is full indexation
> non-scalable. The centralization is in not running the API from a node
> under your own control. This is of course implied by the comment, “without
> the need for syncing”. In other words it is the deployment cost of the node
> that is centralizing.
>
> Yet if people relied only on bitcoind and never centralized services there
> would be *no* block explorers (and no secure light wallets), because it
> does not provide remote query and does not fully index.
>
> Block explorers and light wallets are pretty useful, so presumably some
> API must provide these features (ideally with reduced deployment cost).
> That will either be centralized or decentralized services. As such it seems
> wise to encourage the latter, as opposed to questioning whether there is
> any valid block explorer use case.
>
> e
>
>
> > On Aug 28, 2018, at 11:36, Jonas Schnelli via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Hi
> >
> > To give a critical viewpoint on a such API:
> >
> > Such APIs usually result in central validation, meaning that users trust
> API services rather the validating their own data. It break some of the
> fundamental properties of Bitcoin (avoid trusted third parties).
> > Systems or applications depending on a full indexed blockchain (a thus
> such API) do usually scale pretty bad.
> >
> > I’d like to hear some concrete use-cases for a such block explorer(ish)
> API.
> >
> > Thanks
> > —
> > Jonas
> >
> >> Am 26.08.2018 um 21:58 schrieb Blockchain Group via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
> >>
> >> Hello everyone,
> >>
> >> I am C++ & Node.js developer. I want to propose making a new Bitcoin
> API that supports fast quering of Bitcoin blocks and transactions without
> the need for syncing with all previous nodes.
> >>
> >> In a typical case where I want to build a full fleged Bitcoin explorer
> cum wallet system on my end with external APIs, I need to sync my node and
> then query for the information I need to show separately. I am proposing a
> unified method of finding/quering the blockchain data with a standardized
> template containing minimal information about the actual mined block or
> transaction yet satify the need of what I want to query.
> >>
> >> I am working on making a template and a support mechanism on Node.js. I
> want to propose it as an improvement (BIP). It will be a great help to
> future web developers who want to make something similar.
> >>
> >> Thanks
> >> Sumit Lahiri.
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180829/4a0ea125/attachment-0001.html>