On Wed, Jun 4, 2014 at 8:37 AM, Wladimir wrote:
> Bitcoin Core version 0.9.2rc1 is now available from:
>
> https://bitcoin.org/bin/0.9.2/test
>
> This is a release candidate for a new minor version release, bringing
> mostly bug fixes and some minor improvements.
Almost forgot to mention: new t
Hi Ron,
FYI your mail is being spamfoldered due to Yahoo's DMARC policy and the
brokenness of the SF.net mailing list software. I would not expect to get
replies reliably whilst this is the case. I think we should move away from
SF.net for hosting mailing lists personally, because it's this list t
>
>
> assert() should have *no* side effects, that is the problem.
>>
>
I'm pretty sure that all the side effects of assertions have been removed
before 0.9.0.
However, the assertion checks are extremely important to the proper sanity
of the client and network, so IMHO it's fair to still require
On Wed, Jun 4, 2014 at 2:51 AM, Mike Hearn wrote:
> Hi Ron,
>
> FYI your mail is being spamfoldered due to Yahoo's DMARC policy and the
> brokenness of the SF.net mailing list software. I would not expect to get
> replies reliably whilst this is the case. I think we should move away from
> SF.net
>
> As a matter of procedure we do not use assertions with side effects— the
> codebase did at one point, but have cleaned them up. In an abundance of
> caution we also made it refuse to compile without assertions enabled: A
> decision who's wisdom was clearly demonstrated when not long after, som
On Wed, Jun 4, 2014 at 3:20 AM, Mike Hearn wrote:
>> As a matter of procedure we do not use assertions with side effects— the
>> codebase did at one point, but have cleaned them up. In an abundance of
>> caution we also made it refuse to compile without assertions enabled: A
>> decision who's wis
There are reasons to have assertions enabled by default in software like
Bitcoin Core, where incorrect behaviour can be costly. But this comes at
a prize: our assertions have to satisfy certain performance
requirements. It's no longer possible to do expensive, redundant checks
in performance critic
Currently expensive checks are guarded with command line flags. It'd be
nice if there could be one unified command line flag -expensivechecks that
subsumes -checkmempool and so on.
On Wed, Jun 4, 2014 at 6:42 PM, Jannis Froese wrote:
> There are reasons to have assertions enabled by default in
On Wed, Jun 4, 2014 at 12:42 PM, Jannis Froese <
s9jaf...@stud.uni-saarland.de> wrote:
> I think most concerns about the current use of asserts would be resolved
> if the currently used asserts would be changed to a nicer definition which
> is independent of NDEBUG, and a second class of debuggin
Yes, check macros like that can be useful.
I like the kernel's policy, which parallels our direction:
1) Enable and use lightweight assertions for most users.
2) No assertions with side effects
If you want to compile them out, that's fine, but they should always
be present in production software.
Decided to take a break yesterday and write some code...
Timelock
Create a secret key that can be decrypted in a known amount of time
using parallel-serial hash chains. The creator can compute the timelock
in parallel, taking advantage of the large amount of cheap parallelism
available
Message: 2
Date: Wed, 4 Jun 2014 08:15:08 -0400
From: Jeff Garzik
Subject: Re: [Bitcoin-development] # error "Bitcoin cannot
be compiled
without assertions." <<<
Cc: "bitcoin-development@lists.sourceforge.net"
,
Ron
Messag
Bitcoin development team,
I recently started implementing my own Python full-node, and had an idea, so
I’m prowling through BIP 001 for this proposal, which says to e-mail you kind
folks to make sure the idea is original (enough) and that there aren’t other
existing means to accomplish what I w
Why do you want to optimise this? getheaders is used by SPV clients not
full nodes. SPV clients like bitcoinj can and do simply ship with gist
files in them, then getheaders from the last "checkpoint" (I wish I
hadn't reused terminology like that but this is what bitcoinj calls them).
In practic
Charlie 'Charles' Shrem writes:
> Hey Rusty,
>
> This is intriguing, do you have a writeup somewhere I can read more about ?
OK, ignore the FIXMEs, but I rehashed my stupid sim code, added some
graphs to the (clearly unfinished) paper and uploaded it to github:
https://github.com/rustyrussell/bi
15 matches
Mail list logo
