On 07/22/2013 09:42 PM, Jeff Garzik wrote:
The general goal of the HTTP REST interface is to access
unauthenticated, public blockchain information. There is no plan to
add wallet interfacing/manipulation via this API.
Is it planned to expose the UXTO set of a given address? That would be
Hi Andreas / Jeff,
Access to the UTXO set can be done using libcoin (see the coinexplorer
example), which also has a rest interface. Access to the UTXO set pr
address/script requires indexing of all scripts, which was easy in libcoin as
the blockchain is stored in a sqlite database.
On Monday 22 July 2013 20:42:45 Jeff Garzik wrote:
URL: https://github.com/bitcoin/bitcoin/pull/2844
Adding an HTTP REST API for bitcoind has been occasionally tossed
about as a useful thing. Such an API would essentially provide a
decentralized block explorer capability, enabling easy
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
On Tuesday 23 July 2013 10:42:05 Pieter Wuille 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
The only way to do this safely at an SPV security assumption, is by
having an address-indexed committed merkle UTXO-set tree, like the
one proposed by Alan Reiner, and being implemented by Mark
Friedenback. I know Michael Gronager has something similar implemented,
but I don't know whether
On Tue, Jul 23, 2013 at 11:52 AM, Andy Parkins andypark...@gmail.com wrote:
There is actually no such index being maintained by default, and doing so
is an unnecessary burden IMHO (you need to enable -txindex since 0.8 to
get this). Of course, if enabled, it can be exposed.
Wow. I'm
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
On Tuesday 23 July 2013 10:56:02 Pieter Wuille wrote:
The block chain is not involved at all to verify transactions, it's
just a historical
record to serve to other nodes, and to do wallet rescans with.
It must be involved to some extent. Certainly during a temporary fork, there
are two
On Tue, Jul 23, 2013 at 12:00 PM, Andy Parkins andypark...@gmail.com wrote:
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
On Tue, Jul 23, 2013 at 12:17 PM, Andreas Schildbach
andr...@schildbach.de wrote:
Sweeping paper wallets is a common feature request. People switch to
centralized services just for getting that.
That means they value convenience more than the trust-freeness of a
decentralized solution. The only
On Tue, Jul 23, 2013 at 12:29 PM, Andreas Schildbach
andr...@schildbach.de wrote:
Yes, I understand that. For this reason, I would vote for adding the
usual HTTP authentication/SSL stuff to the REST API. That way, SPV users
can decide to run their own instance of the API (providing the needed
I was thinking about a change to the rules for distinguishing between forks
and maybe a BIP..
*Summary*
- Low POW headers should be broadcast by the network
If a header has more than 1/64 of the POW of a block, it should be
broadcast. This provides information on which fork is getting most of
On Tuesday 23 July 2013 11:17:28 Peter Todd wrote:
On Tue, Jul 23, 2013 at 11:00:24AM +0100, Andy Parkins wrote:
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
On Tue, Jul 23, 2013 at 4:36 AM, Pieter Wuille pieter.wui...@gmail.comwrote:
Apart from that, exposing this HTTP-based interface publicly has its
own problems, like security risks and potential DoS risks. If
anything, we should be reducing the attack surface rather than
increase it. IMHO, the
On Tue, Jul 23, 2013 at 4:01 PM, Mike Hearn m...@plan99.net wrote:
Hi,
Some of us have put together an open letter to the Linux packaging
community, outlining why Bitcoin is different to other programs and asking
them to not patch or modify the upstream sources.
Please consider signing it
On Tuesday, July 23, 2013 10:02:28 PM Scott Howard wrote:
1) It appears that the consensus of upstream developers is that any
distributed binary should only be linked against libraries that the
bitcoin developers have tested and audited since any compatibility bug
is a risk to both the user
On Tue, Jul 23, 2013 at 10:01:55PM +0200, Mike Hearn wrote:
The trigger for this is the discovery that Debian bitcoind's got split out
of the consensus some time in April, for reasons that nobody yet figured
out but is presumably related to a patch (eg it uses system leveldb).
Just to make
I find it interesting that this is a linux packaging letter. How much
of this applies to pkgsrc, FreeBSD ports, OpenBSD ports, and other
non-Linux packaging systems (pkgsrc supports Linux as on of 20 operating
systems, but is not a Linux packaging system)?
Is the repeatable build infrastructure
On Tue, Jul 23, 2013 at 4:23 PM, Greg Troxel g...@work.lexort.com wrote:
Is the repeatable build infrastructure portable (to any reasonable
mostly-POSIX-compliant system, with gcc or clang)? I have the vague
It's portable to anything that can run the relevant VMs. Uh
provided you don't mind
Honestly, until I read the quoted part of your response, I actually wasn't in
favor of this whole thing since in general the types of issues being mentioned
are, in large part, the types of issues that maintainers deal with all the time.
On Jul 23, 2013, at 3:02 PM, Scott Howard
On Tue, Jul 23, 2013 at 9:45 PM, Douglas Huff dh...@jrbobdobbs.org wrote:
Honestly, until I read the quoted part of your response, I actually wasn't in
favor of this whole thing since in general the types of issues being
mentioned are, in large part, the types of issues that maintainers deal
On Tue, Jul 23, 2013 at 6:26 PM, Luke-Jr l...@dashjr.org wrote:
This means a lot of additional work for the
maintainers of the library packages, and the security team; for example, the
security team must understand that they *cannot* deploy a critical security
bugfix to LevelDB until someone
On Wednesday, July 24, 2013 3:54:25 AM Wendell wrote:
Is there a substantial barrier to endian independence in the Bitcoin
codebase?
I got the obvious stuff ('endian' branch in my repo), but it still didn't work
when I moved on. I haven't had time to try to figure out why not yet.
Luke
On Tue, Jul 23, 2013 at 8:54 PM, Wendell w...@grabhive.com wrote:
Forking for curiosity's sake:
Is there a substantial barrier to endian independence in the Bitcoin codebase?
Not really. The software was originally written to write out memory
order to and from the wire, which is part of why the
On Tue, Jul 23, 2013 at 9:07 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
order to and from the wire, which is part of why the protocol is LE
everywhere,
*before someone corrects me, it's not LE everywhere (I meant
manywhere :P)— there is just enough BE to keep you on your toes. :P
26 matches
Mail list logo
