diff options
| author | Andy Parkins <andyparkins@gmail.com> | 2013-07-23 11:00:24 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-07-23 10:00:35 +0000 |
| commit | 0681aa92854fead3120180f2068fdc919a2197bc (patch) | |
| tree | e9211400a417d08ad04cab35829a13bc663c1234 | |
| parent | cad8874059c11802b5aa4c5233f7213a9b38c6a3 (diff) | |
| download | pi-bitcoindev-0681aa92854fead3120180f2068fdc919a2197bc.tar.gz pi-bitcoindev-0681aa92854fead3120180f2068fdc919a2197bc.zip | |
Re: [Bitcoin-development] HTTP REST API for bitcoind
| -rw-r--r-- | 89/047ca5ab166e89c5bbc744fe17454b7bc13a57 | 120 |
1 files changed, 120 insertions, 0 deletions
diff --git a/89/047ca5ab166e89c5bbc744fe17454b7bc13a57 b/89/047ca5ab166e89c5bbc744fe17454b7bc13a57 new file mode 100644 index 000000000..13c14b96c --- /dev/null +++ b/89/047ca5ab166e89c5bbc744fe17454b7bc13a57 @@ -0,0 +1,120 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <andyparkins@gmail.com>) id 1V1ZOV-0000QB-6Z + for bitcoin-development@lists.sourceforge.net; + Tue, 23 Jul 2013 10:00:35 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 74.125.82.50 as permitted sender) + client-ip=74.125.82.50; envelope-from=andyparkins@gmail.com; + helo=mail-wg0-f50.google.com; +Received: from mail-wg0-f50.google.com ([74.125.82.50]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1V1ZOT-0007O2-BI + for bitcoin-development@lists.sourceforge.net; + Tue, 23 Jul 2013 10:00:35 +0000 +Received: by mail-wg0-f50.google.com with SMTP id m15so1498778wgh.5 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 23 Jul 2013 03:00:27 -0700 (PDT) +X-Received: by 10.180.11.146 with SMTP id q18mr21288013wib.50.1374573627210; + Tue, 23 Jul 2013 03:00:27 -0700 (PDT) +Received: from momentum.localnet ([91.84.15.31]) + by mx.google.com with ESMTPSA id fb2sm4720238wic.4.2013.07.23.03.00.25 + for <multiple recipients> + (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); + Tue, 23 Jul 2013 03:00:26 -0700 (PDT) +From: Andy Parkins <andyparkins@gmail.com> +To: Peter Todd <pete@petertodd.org> +Date: Tue, 23 Jul 2013 11:00:24 +0100 +User-Agent: KMail/1.13.7 (Linux/3.9-1-686-pae; KDE/4.8.4; i686; ; ) +References: <CAJHLa0Ou1xF=LeLVu_wH1-XgJ1PavDV7_NHoDevo3R9+4z-ZfQ@mail.gmail.com> + <201307231030.14139.andyparkins@gmail.com> + <20130723094703.GA25900@savin> +In-Reply-To: <20130723094703.GA25900@savin> +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="iso-8859-15" +Content-Transfer-Encoding: 7bit +Message-Id: <201307231100.24538.andyparkins@gmail.com> +X-Spam-Score: -1.6 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (andyparkins[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1V1ZOT-0007O2-BI +Cc: bitcoin-development@lists.sourceforge.net, + Andreas Schildbach <andreas@schildbach.de> +Subject: Re: [Bitcoin-development] HTTP REST API for bitcoind +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Tue, 23 Jul 2013 10:00:35 -0000 + +On Tuesday 23 July 2013 10:47:03 Peter Todd wrote: +> On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote: +> > One additional URL makes this pretty much perfect: +> > GET /rest/block-with-tx/TX-HASH +> > +> > Construction of the transaction-hash-to-block database is something the +> > full client's have to do anyway, so this query is no harder than the +> > others for them to supply; but suddenly makes it possible for an SPV +> > client to trace the providence of any transaction without needing to +> > maintain the entire chain. + +> The REST API has nothing to do with SPV clients; it's similar to the RPC +> interface and won't be exposed to the network as a whole. + +Yes; I know that. I'm saying that it would make it easier for SPV (and other +lightweight clients) for that matter. + +> Increasing the resource usage by SPV clients on full nodes is undesirable; + +I don't think that's thinking big enough. What I imagine is that making it +easier and easier to store a partial blockchain would result in lower demand +on full nodes. + +I might run a client that has only fetched blocks that contain transactions +needed to verify my balances, right back to the genesis block. That will be +some small subset of the block chain and will take me very little resource to +maintain. I join the network and am my client is willing to verify based on +information I have, or supply (by REST or bitcoin protocol) blocks. Imagine +then that everyone with a wallet were doing this. The blockchain would be +distributed massively. Obviously the miners would still be keeping the entire +chain, but we'd have a lot more nodes in the network, each contributing a +little bit and so reducing the load on the full nodes. + +> In any case UTXO data currently requires you to have full trust in +> whomever is providing you with it, and that situation will continue +> until UTXO commitments are implemented - if they are implemented. + +Almost; because you can go and ask someone else the same question, it's pretty +easy to check if you're being lied to. Also, it's far easier to maintain a +headers-only block chain. When you fetch your relevant block subset, you can +easily see that they are real blocks in your headers-only blockchain; and so +it's pretty much impossible to lie to "give me the block containing +transaction X". + + +Andy + +-- +Dr Andy Parkins +andyparkins@gmail.com + + |