Or, you know, enter some discussions on what exactly are the issues that SPV
clients face during soft forks and see if anything can be done (on all
sides) to mitigate the risks.
Crazy stuff, I know ;-)
From: NotMike Hearn via bitcoin-dev
Reply-To: NotMike Hearn
Date: Friday, 2 October 2015
On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev
wrote:
> There is no consensus on using a soft fork to deploy this feature. It will
> result in the same problems as all the other soft forks - SPV wallets will
> become less reliable during the rollout period. I am against that, as it's
>
Rusty Russell via bitcoin-dev
writes:
> Gregory Maxwell writes:
>> I can, however, argue it the other way (and probably have in the
>> past): The bit is easily checked by thin clients, so thin clients
>> could use it to reject potentially ill-fated blocks from non-upgraded
>> miners post switch
Given the current reddit hubbub, a bit of a cooling off period is IMO
advisable before taking any further action.
2. If so, does the community feel that Mike Hearn has crossed it? (I
personally feel he has. Multiple times.)
I don't believe any posting by Mr. Hearn warrants any actions
On Thursday, October 01, 2015 9:41:25 AM Marcel Jamin via bitcoin-dev wrote:
> I guess the question then becomes why bitcoin still is <1.0.0
>
> I'd say it's safe to say that it's used in production.
But it's not *ready* to be used in production. :(
For 1.0, I would expect:
libbitcoinconsensus:
To reduce the list noise level, drama level and promote inclusion, my own
personal preference (list admin hat: off, community member hat: on) is for
temporal bans based on temporal circumstances. Default to
pro-forgiveness. Also, focus on disruption of the list as a metric, rather
than focusing o
Dear list,
Mike has made a variety of false and damaging statements about Bitcoin, of
which this is but one:
> On Sep 30, 2015, at 2:01 PM, Mike Hearn via bitcoin-dev
> wrote:
> I coined the term SPV so I know exactly what it means, and bitcoinj
> implements it, as does BreadWallet (the other
On 9/30/2015 10:58 AM, Jorge Timón via bitcoin-dev wrote:
> I don't think we need to wait for you to understand the advantages of
> softforks to move forward with BIP65, just like we didn't need to wait
> for every developer and user to understand BIP66 to deploy it.
What a bad example. BIP66 de
On Thu, Oct 1, 2015 at 5:41 AM, Marcel Jamin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I guess the question then becomes why bitcoin still is <1.0.0
>
I've said the same thing years ago. Originally the "1.0" was a target for
whenever "client mode" as planned by Satoshi wa
On Thu, Sep 24, 2015 at 7:25 AM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 2015-11-01
> ---
> - Open Transifex translations for 0.12
> - Soft translation string freeze (no large or unnecessary changes)
> - Finalize and close translation for
2015-10-01 12:15 GMT+02:00 Wladimir J. van der Laan :
> On Thu, Oct 01, 2015 at 12:10:45PM +0200, Marcel Jamin wrote:
> > I think the question has already been answered for you by the companies
> > that build on top of it, the investments being made and the $3.5 billion
> > market cap. The 1.0.0 t
any large code changes will no
>> longer go into 0.12, unless fixing critical bugs.
>>
>> I'm not keen on postponing 0.12 for such reasons - after the HK workshop
>> I'm sure that it will take some development/testing/review before code
>> makes it into anything. Apart from that th
On Thu, Oct 01, 2015 at 12:10:45PM +0200, Marcel Jamin wrote:
> I think the question has already been answered for you by the companies
> that build on top of it, the investments being made and the $3.5 billion
> market cap. The 1.0.0 tag is probably long overdue.
May I remind you that by far, mos
> Mostly because we don't use the numbers as a signaling mechanism. They
just count up, every half year.
OK, but then it's not semantic versioning (as btcdrak claims).
> Otherwise, one'd have to ask hard questions like 'is the software mature
enough to be called 1.0.0'
I think the question has a
On Thu, Oct 01, 2015 at 11:41:25AM +0200, Marcel Jamin wrote:
> I guess the question then becomes why bitcoin still is <1.0.0
I'll interpret the question as "why is the Bitcoin Core software still <1.0.0".
Bitcoin the currency doesn't have a version, the block/transaction versions are
at v3/v1 r
-- Forwarded message --
From: Marcel Jamin
Date: 2015-10-01 11:39 GMT+02:00
Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule
To: Btc Drak
I guess the question then becomes why bitcoin still is <1.0.0
I'd say it's safe to say that it's used in production.
2015-10
On Thu, Oct 1, 2015 at 10:05 AM, Marcel Jamin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Any particular reason bitcoin versioning doesn't follow the SemVer spec?
>
We do: a.b.c, the next major version is, 0.12.0, and maintenance releases
are 0.12.1 etc. Release candidates a
Any particular reason bitcoin versioning doesn't follow the SemVer spec?
2015-10-01 10:50 GMT+02:00 Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> On Wed, Sep 30, 2015 at 05:57:42PM +, Luke Dashjr wrote:
> > On Thursday, September 24, 2015 11:25:56 AM Wla
On Wed, Sep 30, 2015 at 05:57:42PM +, Luke Dashjr wrote:
> On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via
> bitcoin-dev wrote:
> > 2015-12-01
> > ---
> > - Feature freeze
>
> Where is "Consensus freeze"? Shouldn't this be put off until after the HK
> worksho
19 matches
Mail list logo