On Sat, Aug 1, 2015 at 10:22 PM, John T. Winslow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Regarding the block size increase, at least conceptually it seems to me
> there should be an easy solution. If we look at what works well with
> bitcoin, for example the block reward
Regarding the block size increase, at least conceptually it seems to me
there should be an easy solution. If we look at what works well with
bitcoin, for example the block reward halving and difficulty regimes
which due to their step function nature both contribute to the stability
and predicta
Forgot to include the list.
> From: Jean-Paul Kogelman
> Date: July 31, 2015 at 4:02:20 PM PDT
> To: Jorge Timón
> Cc: mi...@bitcoins.info
> Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't
> temporary
>
>
> I wrote abo
I generally agree with this as well. I think it is crucial we avoid
controversial hardforks. The risks greatly outweigh the benefits.
This is a good start to making it less controversial.
- Eric
On Jul 31, 2015 2:31 PM, "Jorge Timón" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Fri, Jul
On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev
wrote:
> These are the types of things I have been discussing in relation to a
> process:
>
> -A list of metrics
> -A Risk analysis of the baseline system. Bitcoin as it is now.
> -Mitigation strategies for each risk.
> -A set of goal
Having said that, I must admit that the complex filtering mechanisms are
pretty clever...they almost make it practical to use SPV...now if only we
were committint to structures that can prove the validity of returned
datasets and miners actually validated stuff, it might also offer some
level of se
I would love to be able to increase block size. But I have serious doubts
about being able to do this safely at this time given what we presently
know about the Bitcoin network. And I'm pretty sure I'm not alone in this
sentiment.
Had we been working on fixing the known issues that most complicate
On Thursday 30. July 2015 16.33.16 Eric Lombrozo via bitcoin-dev wrote:
> I don’t think it’s really a matter of whether we agree on whether it’s good
> to raise the block size limit, Gavin. I think it’s a matter of a difference
> in priorities.
Having different priorities is fine, using your time
I have been looking up ways to measure decentralization at the moment.
There are some good discussions as they relate to Bitcoin but they are
scattered in different places. I just took over BitcoinStandards.com so
i thought about using that site to post stuff.
Russ
On 7/30/2015 9:25 PM, Ray
Russ, do you have time to get started on your list? It would add value.
On 30 Jul 2015 5:15 pm, Milly Bitcoin via bitcoin-dev wrote:
These are the types of things I have been discussing in relation to a
process:
-A list of metrics
-A Risk analysis of the baseline system. Bitcoin
> On Jul 30, 2015, at 11:02 AM, Mark Friedenbach via bitcoin-dev
> wrote:
>
> It is possible for a decentralized system like bitcoin to scale via
> distribution in a way that introduces minimal trust, for example by
> probabilistic validation and distribution of fraud proofs. However changes
These are the types of things I have been discussing in relation to a
process:
-A list of metrics
-A Risk analysis of the baseline system. Bitcoin as it is now.
-Mitigation strategies for each risk.
-A set of goals.
-A Road map for each goal that lists the changes or possible avenues to
achiev
> On Jul 30, 2015, at 5:29 AM, Gavin wrote:
>
> it is hard to have a rational conversation about that when even simple
> questions like 'what is s reasonable cost to run a full node' are met with
> silence.
Some of the risks are pretty hard to quantify. But I think this misses the
bigger poi
On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen via bitcoin-dev
wrote:
> On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille
> So what do you think the scalability road map should look like? Should we
> wait to hard fork until Blockstream Elements is ready for deploying on the
> main network, and then
I have just been around for 2 years or so, and its interesting to see you two
argue and give links to the past conversations.
But do realize that if you argue in public about content that is easy to read
by anyone that you have to double check your memory fits the facts.
And I feel you skipped t
On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen
wrote:
> On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille
> wrote:
>
>> Let's scale the block size gradually over time, according to
>> technological growth.
>
>
> Yes, lets do that-- that is EXACTLY what BIP101 intends to do.
>
Oh come on. Immediat
On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille
wrote:
> Let's scale the block size gradually over time, according to technological
> growth.
Yes, lets do that-- that is EXACTLY what BIP101 intends to do.
With the added belt&suspenders reality check of miners, who won't produce
blocks too big f
On Thursday 30. July 2015 14.50.46 Pieter Wuille via bitcoin-dev wrote:
> > I believe the costs and risks of 8MB blocks are minimal, and that the
> > benefits of supporting more transaction FAR outweigh those costs and
> > risks,
> > but it is hard to have a rational conversation about that when ev
On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote:
> >
> > and a number of the people most intimately familiar with the inner
> workings of the system (some of whom are in this thread) think
> On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote:
>
> and a number of the people most intimately familiar with the inner workings
> of the system (some of whom are in this thread) think that given what we now
> today about the Bitcoin network, increasing block size externalizes costs in
> d
> On Jul 30, 2015, at 1:21 AM, Eric Lombrozo wrote:
>
> I usually avoid troll-infested Dunning-Kruger-gone-wild fests like reddit, so
> I’ll leave that to others.
>
> But I do want to clarify a couple things here, though, Andrew.
>
> First of all, the issue is not about whether it is affordabl
I usually avoid troll-infested Dunning-Kruger-gone-wild fests like reddit, so
I’ll leave that to others.
But I do want to clarify a couple things here, though, Andrew.
First of all, the issue is not about whether it is affordable for a highly
motivated, technically skilled person to continue ru
On Wednesday 29. July 2015 20.00.10 Jorge Timón via bitcoin-dev wrote:
> And, of course, short term convenience for users is much more
> important than figuring out the long term viability of the system once
> the seigniorage (spent on the miner's subsidy) goes away.
There are various decades span
On Wed, Jul 29, 2015 at 7:56 PM, Owen via bitcoin-dev
wrote:
> On July 29, 2015 7:15:49 AM EDT, Mike Hearn via bitcoin-dev:
>>Consider this: the highest Bitcoin tx fees can possibly go is perhaps
>>a
>>little higher than what our competition charges. Too much higher than
>>that,
>>and people will
On July 29, 2015 7:15:49 AM EDT, Mike Hearn via bitcoin-dev:
>Consider this: the highest Bitcoin tx fees can possibly go is perhaps
>a
>little higher than what our competition charges. Too much higher than
>that,
>and people will just say, you know what I'll make a bank transfer.
>It's chea
On Wed, Jul 29, 2015 at 6:03 PM, Mike Hearn wrote:
>> It was _well_ understood that the users of Bitcoin would wish to
>> protect its decenteralization by limiting the size of the chain to keep it
>> verifyable on small devices.
>
> No it wasn't. That is something you invented yourself much l
On Wed, Jul 29, 2015 at 12:43 PM, Eric Lombrozo via bitcoin-dev
wrote:
> Erm…most miners just trust mining pool operators to validate blocks for
> them…and some of the biggest pools have been blatantly cutting corners. Yes,
> a few pools might have temporarily bled a little…but properly validating
On Wed, Jul 29, 2015 at 10:23 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
On Wed, Jul 29, 2015 at 9:59 AM, Mike Hearn via bitcoin-dev
>
>
> > Miners who don't validate have a habit of bleeding money: that's the
> > system working as designed.
>
> The infor
On Wed, Jul 29, 2015 at 9:59 AM, Mike Hearn via bitcoin-dev
wrote:
> I do love history lessons from people who weren't actually there.
I doubt the rest of us really enjoy hearing these "lessons" from from
you where you wildly distort history to reflect your views.
> Satoshi explicitly envisioned
On Wednesday 29. July 2015 05.03.45 Eric Lombrozo via bitcoin-dev wrote:
> Point is…processing blocks requires computational resources that someone
> needs to put up. Unless the people who are putting up these resources are
> properly incentivized to continue doing it, the network will fail.
This
> On Jul 29, 2015, at 4:15 AM, Mike Hearn wrote:
>
> Irrelevant what term was used - and as brilliant as Satoshi might have been
> at some things, he obviously got this one wrong.
>
> I don't think it's obvious. You may disagree, but don't pretend any of this
> stuff is obvious.
>
> Consider
On Wednesday 29. July 2015 03.43.50 Eric Lombrozo via bitcoin-dev wrote:
> > > Enter a “temporary” anti-spam measure - a one megabyte block size limit.
> > The one megabyte limit was nothing to do with anti spam. It was a quick
> > kludge to try and avoid the user experience degrading significantl
On Tuesday 28. July 2015 19.40.21 Eric Lombrozo via bitcoin-dev wrote:
> 1) A fee market never really got created, we don’t really know how
> transaction fees would work in practice.
>
> The only way to see how fees would work in practice is to have scarcity.
This skips over the question why you
>
> Irrelevant what term was used - and as brilliant as Satoshi might have
> been at some things, he obviously got this one wrong.
>
I don't think it's obvious. You may disagree, but don't pretend any of this
stuff is obvious.
Consider this: the highest Bitcoin tx fees can possibly go is perhaps
> On Jul 29, 2015, at 2:59 AM, Mike Hearn wrote:
>
> I do love history lessons from people who weren't actually there.
>
> Let me correct your misconceptions.
>
>
> Initially there was no block size limit - it was thought that the fee market
> would naturally develop and would impose economi
I do love history lessons from people who weren't actually there.
Let me correct your misconceptions.
Initially there was no block size limit - it was thought that the fee
> market would naturally develop and would impose economic constraints on
> growth.
The term "fee market" was never used b
> On Jul 28, 2015, at 8:46 PM, Milly Bitcoin via bitcoin-dev
> wrote:
>
>> GUYS, WE’VE KNOWN ABOUT THESE PROBLEMS AND HAVE TALKED ABOUT THEM FOR
>> YEARS ALREADY…AND IT SEEMS PRACTICALLY NOTHING HAS HAPPENED…
>
> What is the incentive for someone with high level technical skills to spend
> al
GUYS, WE’VE KNOWN ABOUT THESE PROBLEMS AND HAVE TALKED ABOUT THEM FOR
YEARS ALREADY…AND IT SEEMS PRACTICALLY NOTHING HAS HAPPENED…
What is the incentive for someone with high level technical skills to
spend all their time developing and testing code? Especially since the
code is generally the
> On Jul 28, 2015, at 7:40 PM, Eric Lombrozo wrote:
>
> Note: many of these ideas are neither my own nor really all that new, but it
> seems in the past we’ve given up too easily on actually moving forward on
> them despite their critical importance.
In retrospect I regret not having made thi
In the interest of promoting some constructive discussion on this, let me start
by making a few proposals to correct the listed issues.
Note: many of these ideas are neither my own nor really all that new, but it
seems in the past we’ve given up too easily on actually moving forward on them
des
I agree that the historical reasons are irrelevant from an engineering
perspective. But they still set a context for the discussion…and might help
shed some insight into the motivations behind some of the participants. It’s
also good to know these things to counter arguments that start with “But
Does it matter even in the slightest why the block size limit was put in
place? It does not. Bitcoin is a decentralized payment network, and the
relationship between utility (block size) and decentralization is
empirical. Why the 1MB limit was put in place at the time might be a
historically intere
> On Jul 28, 2015, at 5:43 PM, Jean-Paul Kogelman
> wrote:
>
>
>> Enter a “temporary” anti-spam measure - a one megabyte block size limit.
>> Let’s test this out, then increase it once we see how things work. So far so
>> good…
>>
>
> The block size limit was put in place as an anti-DoS me
> Enter a “temporary” anti-spam measure - a one megabyte block size limit.
> Let’s test this out, then increase it once we see how things work. So far so
> good…
>
The block size limit was put in place as an anti-DoS measure (monster blocks),
not "anti-spam". It was never intended to have any
I only got into Bitcoin in 2011, after the block size limit was already in
place. After going through some more of the early history of Bitcoin to better
understand the origins of this, things are starting to come into better
perspective.
Initially there was no block size limit - it was thought
45 matches
Mail list logo
