On Mon, Aug 3, 2015 at 8:53 AM, Jim Phillips via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Yes I've had a couple other people point that out to me as well and the logic
is sound. Unfortunately that doesn't help solve the actual issue that mining
is currently consolidated
Mike's position is that he wants the block size limit
to eventually be removed. That is of course an extreme view. Meanwhile,
your view that the block size should be artificially constrained below the
organic growth curve (in a way that will penalize a majority of existing
and future users) lies
On Tue, Aug 4, 2015 at 3:12 PM, Gavin Andresen gavinandre...@gmail.com
wrote:
On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I would say that things already demonstrately got terrible. The mining
landscape is very centralized, with
On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
And the preliminary results of using a prediction market to try to wrestle
with the tough tradeoffs looks roughly correct to me, too:
https://blocksizedebate.com/
The scicast
Dear Bitcoin-Dev Mailing list,
I’d like to share a research paper I’ve recently completed titled “A
Transaction Fee Market Exists Without a Block Size Limit.” In addition to
presenting some useful charts such as the cost to produce large spam blocks, I
think the paper convincingly
On 4 August 2015 at 10:03, Pieter Wuille via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
If you want to let a majority decide about economic policy of a currency,
I suggest fiat currencies. They have been using this approach for quite a
while, I hear.
Nearly all the fiat
As now we have some concrete proposals
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html),
I think we should wrap up the endless debate with voting by different
stakeholder groups.
-
Candidate proposals
Candidate proposals must be
Things apparently aren't bad enough to prevent the majority from clamoring
for larger blocks.
If the majority agreed that things had got worse till this point, and that
this was to be blamed on the block size, they would be campaigning for the
other direction. Even yourselves aren't asking for a
Bitcoin's consensus rules are a consensus system
What is your definition of consensus? Do you mean 100% agreement?
Without a vote how do you know there is 100% (or whatever percentage)
agreement?
Find a solution that everyone agrees on, or don't.
Who are the everyone?
Pieter Wuille 於
On 4 August 2015 at 14:13, Jorge Timón jti...@jtimon.cc wrote:
2) It doesn't matter who is to blame about the current centralization:
the fact remains that the blocksize maximum is the only** consensus
rule to limit mining centralization.
Repeating a claim ad-nauseum doesn't make it
On Tue, Aug 4, 2015 at 2:19 PM, Hector Chu hector...@gmail.com wrote:
On 4 August 2015 at 12:59, Jorge Timón jti...@jtimon.cc wrote:
That is not my position. Again, I don't know what the right blocksize
for the short term is (I don't think anybody does).
You have no position (i.e. neutral).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/04/2015 08:28 PM, Hector Chu via bitcoin-dev wrote:
On 4 August 2015 at 14:13, Jorge Timón jti...@jtimon.cc
mailto:jti...@jtimon.cc wrote:
2) It doesn't matter who is to blame about the current
centralization: the fact remains that the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
correction:
My finance readers, in one camp, and Bitcoin investors, in the other,
want to see the XT 8MB hard-fork testing data that you mentioned for
BIP101 (not 100).
- Forwarded Message
Subject: Re: [bitcoin-dev] Block size
On Tue, Aug 4, 2015 at 9:12 AM, Gavin Andresen via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I would say that things already demonstrately got terrible. The mining
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/04/2015 08:12 PM, Gavin Andresen via bitcoin-dev wrote:
On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org
mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
I would say that things
I would like to withdraw my proposal from your self-appointed vote.
If you want to let a majority decide about economic policy of a currency, I
suggest fiat currencies. They have been using this approach for quite a
while, I hear.
Bitcoin's consensus rules are a consensus system, not a
As I mentioned, the candidate proposals must go through usual peer
review process, which includes proper testing, I assume.
Scaling down is always possible with softforks, or miners will simply
produce smaller blocks. BIP100 has a scaling down mechanism but it still
requires miners to vote so
On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I would say that things already demonstrately got terrible. The mining
landscape is very centralized, with apparently a majority depending on
agreements to trust each other's announced
On Tue, Aug 4, 2015 at 1:34 PM, Hector Chu hector...@gmail.com wrote:
Things apparently aren't bad enough to prevent the majority from clamoring
for larger blocks.
Nobody is preventing anyone from claiming anything. Some developers
are encouraging users to ask for bigger blocks.
Others don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/04/2015 06:34 PM, Hector Chu via bitcoin-dev wrote:
Things apparently aren't bad enough to prevent the majority from
clamoring for larger blocks.
If the majority agreed that things had got worse till this point,
and that this was to be
On 4 August 2015 at 12:59, Jorge Timón jti...@jtimon.cc wrote:
That is not my position. Again, I don't know what the right blocksize
for the short term is (I don't think anybody does).
You have no position (i.e. neutral). In other words, keeping the existing
limit.
Therefore how the change
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 4 August 2015 17:30:28 GMT-04:00, Gavin Andresen via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Fundamentally a block
On 4 Aug 2015, at 14:30, Gavin Andresen gavinandre...@gmail.com wrote:
On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org
mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
Fundamentally a block maker (pool or aggregation of pools) does not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 4 August 2015 16:02:53 GMT-04:00, Jorge Timón via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
One thing I've noticed there seems to be disagreement on is whether
miners' upgrade confirmation (aka voting) is necessary for
On Sun, Jun 28, 2015 at 9:50 PM, Peter Todd p...@petertodd.org wrote:
On Thu, Jun 25, 2015 at 06:33:44PM -0400, Peter Todd wrote:
Thoughts? If there are no objections I'll go ahead and write that code,
using the same thresholds as BIP66.
I've opened a pull-req to deploy CHECKLOCKTIMEVERIFY
The paper is nicely done, but I'm concerned that there's a real problem with
equation 4. The orphan rate is not just a function of time; it's also a
function of the block maker's proportion of the network hash rate.
Fundamentally a block maker (pool or aggregation of pools) does not orphan its
On Tue, Aug 4, 2015 at 3:28 PM, Hector Chu hector...@gmail.com wrote:
On 4 August 2015 at 14:13, Jorge Timón jti...@jtimon.cc wrote:
2) It doesn't matter who is to blame about the current centralization:
the fact remains that the blocksize maximum is the only** consensus
rule to limit mining
Given there is no money at stake in these prediction games, it is no surprise
that the results are implausible.
On August 4, 2015 10:22:19 AM EDT, Anthony Towns via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On 4 August 2015 at 01:22, Gavin Andresen via bitcoin-dev
On Thu, Jul 30, 2015 at 8:16 PM, Gavin Andresen gavinandre...@gmail.com wrote:
I still think using the version and timestamp fields in the block header are
simplest and best.
To be clear, all options can use the version.
Advantages:
Available to SPV nodes with no change to the network
Rather than speculating on fake markets, why don’t we use theory, empirical
data, and engineering to fix the damn problems?
On Aug 4, 2015, at 11:28 AM, Owen via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Given there is no money at stake in these prediction games, it is no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 4 August 2015 14:41:53 GMT-04:00, Dave Hudson via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
The paper is nicely done, but I'm concerned that there's a real problem
with equation 4. The orphan rate is not just a function of time;
31 matches
Mail list logo
