> * 2 MB, height 210,000 < 420,000; (when 75% of last 1,000 blocks signal
support)
This doesnt give anyone a chance to upgrade and would cause a hard fork the
moment a miner created a >1MB block. Flag day (hard fork) upgrades must
start the change at a sufficient time in the future (greater than t
Hello,
I'd like to announce Jonas Schnelli as the new GUI maintainer of Bitcoin Core.
He's been very active in this area for the last year, as one example he
redesigned all the icons for 0.11.0, has visualized various network statistics,
and has been continuously improving the user experience. So
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi all
I'm a little bit concerned about the future of bitcoin.org.
A neutral website that informs about bitcoin, bitcoin-applications and
bitcoin-exchanges is important at this "early stage".
You might have seen that bitcoin.com does not claim to b
I like your suggestion for the continuity and it gets us up to 2 MB in the
shorter term. Also I just noticed the math error.
Here is a revised spec (incorporating suggestions from Chun Wang):
Specification
* 1 MB, height < 210,000;
* 2 MB, height 210,000 < 420,000; (when 75% of last 1,000 blocks
On Friday, November 13, 2015 2:56:55 AM Chun Wang via bitcoin-dev wrote:
> * 2 MB, 21 <= height < 42;
It's impossible to have the entire network upgraded in the past.
Furthermore, 1 MB is already too large a block size today. While blocks don't
need to be as big as the limit, it's better
How about these specs:
* 1 MB, height < 21;
* 2 MB, 21 <= height < 42;
* 4 MB, 42 <= height < 63;
* 8 MB, 63 <= height < 84;
* 16 MB, 84 <= height < 105;
* 32 MB, height >= 105.
On Fri, Nov 13, 2015 at 7:47 AM, John Sacco via bitcoin-dev
wrote:
> Hi Devs,
Hi Devs,
Please consider the draft proposal below for peer review.
Thanks,
John
BIP
BIP: ?
Title: Block size doubles at each reward halving with max block size of
32M
Author: John Sacco
Status: Draft
Type: Standards Track
Created: 2015-11-11
Abstract
Change max block si
I just wanted to let everyone know that after much considered review, new
lower policy limits on the number and size of related unconfirmed
transactions that will be accepted in to the mempool and relayed have been
merged into the master branch of Bitcoin Core for 0.12 release.
The actual limits w
On Thursday, November 12, 2015 9:21:57 PM Alex Morcos wrote:
> To be clear Luke, its not THAT complicated to maintain the mining policy,
> but preserving the ability of people to place priority based transactions
> in a limited mempool world is quite complicated. See recently closed
> #6992.
> I t
To be clear Luke, its not THAT complicated to maintain the mining policy,
but preserving the ability of people to place priority based transactions
in a limited mempool world is quite complicated. See recently closed
#6992.
I think the biggest issue with #6357 is being sure the logic doesn't break
On Thursday, November 12, 2015 8:43:17 PM Jorge Timón wrote:
> On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev
> wrote:
> > On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev
> > wrote:
> >> * Mining code will use starting priority for ease of implementation
> >
On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev
wrote:
> On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev wrote:
>> * Mining code will use starting priority for ease of implementation
>
> This should be optional, at least for 0.12.
The ease of implementation is
The priority space is causing major mempool bloating and GBT latency right
now since many of the free transactions aren't getting mined and cleared
out of the mempool anymore. From my testing setting minrelaytxfee=0.0001 is
not enough to prevent the mempool from getting large during a spam attack,
On Thursday, November 12, 2015 8:20:45 PM Chun Wang wrote:
> The sort by priority part in the block is always the best place for spam
> nowadays.
What are you saying here? Spammers generally can't use the priority space at
all, and it is a major way for legitimate users to get their transactions
I doubt changing the default value is useful as casual mining had long
dead, and pools all have their own customized policies. But I think
change the priority size to 0 is the right way to do. The sort by
priority part in the block is always the best place for spam nowadays.
I would think about to
On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev wrote:
> With the mempool limiting stuff already in git master, high-priority
> relay is disabled when mempools are full. In addition, there was
> agreement to take the following steps for 0.12:
>
> * Mining code will use star
On the IRC meeting today there was a long discussion on how to handle
the old "transaction priority" stuff in 0.12. Over time the "transaction
priority" stuff has added a huge amount of code and taken a bunch of
otherwise-useful developer effort. There is still some debate about its
usefulness goin
Hi all
As some of you may recall, I tried to throw together a small
code-sprint after the Scaling Bitcoin event in Montreal. There were
several problems stemming from the last-minute-ness and some confusion
about the scope and goals, but I think it was a good thing overall.
Most importantly, it po
18 matches
Mail list logo
