On Sun, Sep 06, 2015 at 08:43:24PM -0400, Peter Todd via bitcoin-dev wrote:
> https://github.com/petertodd/python-bitcoinlib/tree/python-bitcoinlib-v0.5.0rc1
No issues have been reported with the release candidate, so I've
released v0.5.0 officially pretty much as-is:
Hi,
I have an idea for a gamified bitcoin mining app that I'd like to partner
with someone on that is very good with cryptography and knows the bitcoin
code base well. I have received interest in this from some, but I'm looking
for the ideal candidate to work with. If this is of interest, please
Agree with all CLTV and nVersionBits points. We should deploy a lock-time
soft-fork ASAP, using the tried and true IsSuperMajoirty test.
However your information regarding BIPs 68 (sequence numbers), 112
(checksequenceverify) and 113 (median time past) is outdated. Debate
regarding semantics has
On Sun, Sep 27, 2015 at 04:26:12PM -0400, jl2...@xbt.hk wrote:
> +1 for deploying BIP65 immediately without further waiting. Agree
> with all Peter's points.
Thanks!
> By the way, is there any chance to backport it to 0.9? In the
> deployment of BIP66 some miners requested a backport to 0.9 and
Summary
---
It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
I've backported the CLTV op-code and a IsSuperMajority() soft-fork to
the v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A
pull-req for git HEAD for the soft-fork deployment has been open since
June 28th, #6351 -
+1 for deploying BIP65 immediately without further waiting. Agree with
all Peter's points.
If BIP65 has to follow the 0.12 schedule, it will take almost 9 months
from now to complete the softfork. I don't see any good reason to wait
for that long. We have too much talk, too little action.
On Sun, Sep 27, 2015 at 7:50 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly
> delay deployment of CLTV
>
> It's been proposed multiple times that we wait until we can do a single
>
I was mansplaining weak blocks to my wife. She asked a simple question:
Why would I, as a miner, publish a weak block if I find one?
I don't know.
Sure, I will get faster propagation for my solved block, should I find one.
On the other hand everybody else mining a similar block will enjoy the
Hi All
As part of trying to learn more about the bitcoin builds, I am trying to
recreate the travis CI build system using TeamCity.
Some of the builds work fine, but the windows builds seem to be having a
problem with getting mingw dev:
[08:31:21][Step 3/3] E: Package 'mingw-w64-dev' has no
On Sun, Sep 27, 2015 at 2:39 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Unless the weak block transaction list can be a superset of the block
> transaction list size proportional propagation costs are not totally
> eliminated.
>
The POW threshold could
10 matches
Mail list logo
