public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Blockchain Group <shekharhiran@gmail.com>
To: Jonas Schnelli <dev@jonasschnelli.ch>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Building a Bitcoin API and query system.
Date: Wed, 29 Aug 2018 23:59:18 +0530	[thread overview]
Message-ID: <CA+9w0-4-BL5dJCTXD80hVfgt-kZY8AtYzLg_2yCn1m7KeeVs=g@mail.gmail.com> (raw)
In-Reply-To: <4EC6599E-D317-4E4F-9E4D-37B7006B8C15@jonasschnelli.ch>

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

Awesome, thanks for the information. I will work on it and keep it in mind.

On Wed, Aug 29, 2018, 11:57 PM Jonas Schnelli <dev@jonasschnelli.ch> 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.
>
> IMO an API that serves non verifiable data is supporting centralised
> validation. The „API" which supports one of the most important properties
> in Bitcoin – the ability to self-validate – is the data available via the
> p2p network.
>
> >
> > 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.
>
> Bitcoin-Core has all required features to partially „index“ data (called
> the wallet) and provides them via the RPC API. If you don’t need to serve
> thousands of wallets (which smells after centralised validation), selective
> indexing (wallets) are the right choice. Also, if you have a proper light
> client architecture, you can use Bitcoin Core in pruned mode (<10GB of
> data) to serve an endless amount of wallets (client/server mode, I guess
> that is what you are referring to with "light clients").
>
> I fail to see the use-cases where a fully index blockchain makes sense
> (the only one I can come up with is instant backup recovery where the
> transaction history needs to be preserved rather then recovering the UTXOs
> only).
>
> Also, the p2p protocol has built in light client support with BIP37 (bloom
> filters) and soon BIP158 will be available on the network which does allow
> privacy-preserving "light clients" in a way where no trusted layer is
> required (client <-> p2p network rather then client <-> API provider <->
> p2p network).
>
> I don’t want to advocate against a full-index blockexplorer-like API. I
> just think its important to define the use case and be aware of the
> consequences and downsides.
>
> /jonas
>

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

  reply	other threads:[~2018-08-29 18:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-26 19:58 [bitcoin-dev] Building a Bitcoin API and query system Blockchain Group
2018-08-28 15:15 ` Joseph Gleason ⑈
2018-08-28 15:47   ` Matias Alejo Garcia
2018-08-28 17:34     ` Blockchain Group
2018-08-28 17:51       ` Guido Dassori
2018-08-28 18:14       ` Eric Voskuil
2018-08-28 18:36 ` Jonas Schnelli
2018-08-29 12:25   ` Blockchain Group
2018-08-29 14:40   ` Eric Voskuil
2018-08-29 16:06     ` Blockchain Group
2018-08-29 18:27     ` Jonas Schnelli
2018-08-29 18:29       ` Blockchain Group [this message]
2018-08-29 18:45       ` Eric Voskuil
2018-08-30 10:03   ` Aymeric Vitte
2018-08-30 11:40     ` Blockchain Group

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='CA+9w0-4-BL5dJCTXD80hVfgt-kZY8AtYzLg_2yCn1m7KeeVs=g@mail.gmail.com' \
    --to=shekharhiran@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dev@jonasschnelli.ch \
    /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