On Tue, Jul 23, 2013 at 9:07 PM, Gregory Maxwell 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
--
On Tue, Jul 23, 2013 at 8:54 PM, Wendell 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 protocol is LE
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
Forking for curiosity's sake:
Is there a substantial barrier to endian independence in the Bitcoin codebase?
-wendell
grabhive.com | twitter.com/grabhive
On Jul 24, 2013, at 3:45 AM, Douglas Huff wrote:
> The fact that you're even trying to package and/or at some point have
> packaged and shi
On Tue, Jul 23, 2013 at 7:35 PM, zooko wrote:
> I think some
> package maintainers might perceive this version of the letter as high-handed
> --
> telling someone else how to do their job -- and they might not notice the
> actual facts included in the letter explaining why Bitcoin really *is*
> d
Folks:
With all due respect, I think the letter as I see it at
https://docs.google.com/document/d/1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/edit#heading=h.i7tz3gqh65mi
should be changed before being shown to package maintainers. I think some
package maintainers might perceive this version of th
On Tue, Jul 23, 2013 at 6:26 PM, Luke-Jr 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 competent has
On Tue, Jul 23, 2013 at 9:45 PM, Douglas Huff 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 with
> all the ti
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 wrote:
> Respo
On Tue, Jul 23, 2013 at 4:23 PM, Greg Troxel 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 cross compiling ev
On Tuesday, July 23, 2013 11:23:27 PM Greg Troxel wrote:
> 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
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 infrastructu
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 s
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 4:01 PM, Mike Hearn 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 if you agr
ight too.
The text that had been ACKed last night was a3e52973, available at
http://luke.dashjr.org/tmp/code/20130723-linux-distribution-packaging-and-bitcoin.md
As far as the PGP goes—
I think using the PGP is good: it's making use of the right tools,
avoids issues like we just had where peopl
Yes. Someone decided to actually delete the people who had signed so far
and replace it with a request for PGP signing - no. Not everyone even uses
PGP, which is overkill for this anyway.
I'm going to roll the document back and lock it. Sorry, I had hoped people
would respect my request to not fid
On Tue, Jul 23, 2013 at 1:01 PM, Mike Hearn 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 if you agr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/23/13 3:29 AM, Andreas Schildbach 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 (provi
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 if you agree (I think the wording by now is
fine, so don't edit the conten
On Tue, Jul 23, 2013 at 4:36 AM, Pieter Wuille wrote:
> 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 only thing that sho
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 a
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 t
On Tue, Jul 23, 2013 at 12:29 PM, Andreas Schildbach
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
> resources themselv
On 07/23/2013 11:47 AM, Peter Todd wrote:
>> Is it planned to expose the UXTO set of a given address? That would be
>> useful for SPV wallets to be able to swipe a previously unknown private
>> key (e.g. paper wallet).
>
> The REST API has nothing to do with SPV clients; it's similar to the RPC
>
On Tue, Jul 23, 2013 at 12:17 PM, Andreas Schildbach
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 way to avoid that i
On Tue, Jul 23, 2013 at 12:00 PM, Andy Parkins 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
> lightweight clients) fo
On 07/23/2013 11:37 AM, Pieter Wuille wrote:
>> Is it planned to expose the UXTO set of a given address? That would be
>> useful for SPV wallets to be able to swipe a previously unknown private
>> key (e.g. paper wallet).
>
> Depends what you mean by expose.
>
> Maintaining an address/script-index
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 store a partial blockchain would result in lower dema
On Tue, Jul 23, 2013 at 12:02 PM, Andy Parkins wrote:
> 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 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 b
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 c
On Tue, Jul 23, 2013 at 11:52 AM, Andy Parkins 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 surprised at that. Ho
>
> 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 whe
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
> > ful
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
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
On Tue, Jul 23, 2013 at 10:27:19AM +0200, Andreas Schildbach wrote:
> 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
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
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. Integrating
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
u
41 matches
Mail list logo
