On Sun, May 31, 2015 at 10:59 AM, Jorge Timón jti...@jtimon.cc wrote:
Whatever...let's use the current subsidies, the same argument applies,
it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B.
Miner B would still go out of business, bigger blocks still mean more
mining and
On May 31, 2015 5:08 PM, Gavin Andresen gavinandre...@gmail.com wrote:
On Sun, May 31, 2015 at 10:59 AM, Jorge Timón jti...@jtimon.cc wrote:
Whatever...let's use the current subsidies, the same argument applies,
it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B.
Miner B
On Sun, May 31, 2015 at 3:05 AM, Peter Todd p...@petertodd.org wrote:
Yeah, I'm pretty surprised myself that Gavin never accepted the
compromises offered by others in this space for a slow growth solution
What compromise? I haven't seen a specific proposal that could be turned
into a pull
On Sun, May 31, 2015 at 10:46 AM, Jorge Timón jti...@jtimon.cc wrote:
Here's a thought experiment:
Subsidy is gone, all the block reward comes from fees.
I wrote about long-term hypotheticals and why I think it is a big mistake
to waste time worrying about them here:
Whatever...let's use the current subsidies, the same argument applies, it's
just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B.
Miner B would still go out of business, bigger blocks still mean more
mining and validation centralization. The question is how far I we willing
to go with
On 05/29/15 23:48, Gavin Andresen wrote:
On Fri, May 29, 2015 at 7:25 PM, Matt Corallo bitcoin-l...@bluematt.me
mailto:bitcoin-l...@bluematt.me wrote:
Sadly, this is very far from the whole story. The issue of miners
optimizing for returns has been discussed several times during
Stop trying to dictate block growth limits. Block size will be determined
by competition between miners and availability of transactions, not through
hard-coded limits.
Do you even game theory, bro? It doesn't work that way.
Mike Hearn described the problem in this article:
On Fri, May 29, 2015 at 7:42 PM, Chun Wang 1240...@gmail.com wrote:
Hello. I am from F2Pool. We are currently mining the biggest blocks on
the network.
Thanks for giving your opinion!
Bad miners could attack us and the network with artificial
big blocks.
How?
I ran some simulations,
Matt brought this up on Twitter, I have no idea why I didn't respond weeks
ago (busy writing blog posts, probably):
On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote:
* Though there are many proposals floating around which could
significantly decrease block
On 05/29/15 22:36, Gavin Andresen wrote:
Matt brought this up on Twitter, I have no idea why I didn't respond
weeks ago (busy writing blog posts, probably):
On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me
mailto:bitcoin-l...@bluematt.me wrote:
* Though
Hello. I am from F2Pool. We are currently mining the biggest blocks on
the network. So far top 100 biggest bitcoin blocks are all from us. We
do support bigger blocks and sooner rather than later. But we cannot
handle 20 MB blocks right now. I know most blocks would not be 20 MB
over night. But
On Sat, May 9, 2015 at 4:08 AM, Peter Todd p...@petertodd.org wrote:
I wonder if having a miner flag would be good for the network.
Makes it trivial to find miners and DoS attack them - a huge risk to the
network as a whole, as well as the miners.
To mitigate against this, two chaintips
On Sat, May 16, 2015 at 5:39 AM, Stephen stephencalebmo...@gmail.com
wrote:
I think this could be mitigated by counting confirmations differently. We
should think of confirmations as only coming from blocks following the
miners' more strict rule set. So if a merchant were to see payment for
Comments in line:
On May 8, 2015, at 11:08 PM, Peter Todd p...@petertodd.org wrote:
Makes it trivial to find miners and DoS attack them - a huge risk to the
network as a whole, as well as the miners.
Right now pools already get DoSed all the time through their work
submission systems;
--[remove this line and above]--
On Thu, 7 May 2015, Gregory Maxwell wrote:
Date: Thu, 7 May 2015 00:37:54 +
From: Gregory Maxwell gmaxw...@gmail.com
To: Matt Corallo bitcoin-l...@bluematt.me
Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development]
* Though there are many proposals floating around which could
significantly decrease block propagation latency, none of them are
implemented today.
With a 20mb cap, miners still have the option of the soft limit.
I would actually be quite surprised if there were no point along the road
On Fri, May 08, 2015 at 12:03:04PM +0200, Mike Hearn wrote:
* Though there are many proposals floating around which could
significantly decrease block propagation latency, none of them are
implemented today.
With a 20mb cap, miners still have the option of the soft limit.
The
On Fri, May 8, 2015 at 5:37 PM, Peter Todd p...@petertodd.org wrote:
The soft-limit is there miners themselves produce smaller blocks; the
soft-limit does not prevent other miners from producing larger blocks.
I wonder if having a miner flag would be good for the network.
Clients for general
On Fri, May 08, 2015 at 08:47:52PM +0100, Tier Nolan wrote:
On Fri, May 8, 2015 at 5:37 PM, Peter Todd p...@petertodd.org wrote:
The soft-limit is there miners themselves produce smaller blocks; the
soft-limit does not prevent other miners from producing larger blocks.
I wonder if
Hi Matt,
I agree that starting discussion on how to approach this problem is
necessary and it's difficult taking positions without details on what is
being discussed.
A simple hard 20-megabyte increase will likely create perverse
incentives, perhaps a method can exist with some safe transition.
On Thu, May 07, 2015 at 10:02:09PM +, Matt Corallo wrote:
OK, so lets do that. I've seen a lot of I'm not entirely comfortable
with committing to this right now, but think we should eventually, but
not much I'd be comfortable with committing to this when I see X. In
the interest of
OK, so lets do that. I've seen a lot of I'm not entirely comfortable
with committing to this right now, but think we should eventually, but
not much I'd be comfortable with committing to this when I see X. In
the interest of ignoring debate and pushing people towards a consensus
at all costs, ( ;)
22 matches
Mail list logo
