On Thu, May 28, 2015 at 1:34 PM, Mike Hearn m...@plan99.net wrote:
As noted, many miners just accept the defaults. With your proposed change
their target would effectively *drop* from 1mb to 800kb today, which
seems crazy. That's the exact opposite of what is needed right now.
I am very
until we have size-independent new block propagation
I don't really believe that is possible. I'll argue why below. To be clear,
this is not an argument against increasing the block size, only against
using the assumption of size-independent propagation.
There are several significant
On Thu, May 28, 2015 at 01:19:44PM -0400, Gavin Andresen wrote:
As for whether there should be fee pressure now or not: I have no
opinion, besides we should make block propagation faster so there is no
technical reason for miners to produce tiny blocks. I don't think us
developers should be
On May 28, 2015 10:42 AM, Raystonn . rayst...@hotmail.com wrote:
I agree that developers should avoid imposing economic policy. It is
dangerous for Bitcoin and the core developers themselves to become such a
central point of attack for those wishing to disrupt Bitcoin.
I could not agree more
Twenty is scary.
To whom? The only justification for the max size is DoS attacks, right?
Back when Bitcoin had an average block size of 10kb, the max block size was
100x the average. Things worked fine, nobody was scared.
The max block size is really a limit set by hardware capability, which
On Thu, May 28, 2015 at 1:59 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
I personally think the block size should increase, by the way, but only if
we can do it under a policy of doing it after technological growth has been
shown to be sufficient to support it without increased risk.
Can we hold off on bike-shedding the particular choice of parameters until
people have a chance to weigh in on whether or not there is SOME set of
dynamic parameters they would support right now?
--
--
Gavin Andresen
--
I agree that developers should avoid imposing economic policy. It is dangerous
for Bitcoin and the core developers themselves to become such a central point
of attack for those wishing to disrupt Bitcoin. My opinion is these things are
better left to a decentralized free market anyhow.
My understanding, which is very likely wrong in one way or another, is
transaction size and block size are two slightly different things but
perhaps it's so negligible that block size is a fine stand-in for total
transaction throughput.
Potentially Doubling the block size everyday is frankly
Agreed, there is no need to misuse the version field as well. There is more
than enough variability you could roll in the merkle tree including and
excluding transactions, and the scriptSig of the coinbase transaction,
which also influences the merkle root.
I have a fundamental dislike of
The prior (and seemingly this) assurance contract proposals pay the
miners who mines a chain supportive of your interests and miners whom
mine against your interests identically.
The same is true today - via inflation I pay for blocks regardless of
whether they contain or double spend my
Can you update it so that it only applies to transactions with version
number 3 and higher. Changing the meaning of a field is exactly what the
version numbers are for.
You could even decode version 3 transactions like that.
Version 3 transactions have a sequence number of 0x and the
On Thu, May 28, 2015 at 11:30:18AM +0100, Tier Nolan wrote:
Can you update it so that it only applies to transactions with version
number 3 and higher. Changing the meaning of a field is exactly what the
version numbers are for.
You could even decode version 3 transactions like that.
On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach m...@friedenbach.org
wrote:
Why 3? Do we have a version 2?
I meant whatever the next version is, so you are right, it's version 2.
As for doing it in serialization, that would alter the txid making it a
hard fork change.
The change is
14 matches
Mail list logo