> Sent: Friday, July 24, 2015 at 10:52 AM
> From: "Thomas Zander via bitcoin-dev"
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
>
>
> The reference to bandwidth increases makes no sense, the ba
On Friday 17. July 2015 20.29.16 Luke Dashjr via bitcoin-dev wrote:
> We are unlikely to approach 1 MB of actual volume by November, so I would
> prefer to see the activation date on this moved later - maybe November
> 2016, if not 2017. It would also be an improvement to try to follow
> reasonab
Peter Todd, as discussed on IRC, I'm not opposed to median time, which
has many of the properties nheight has, I'm just opposed to just using
nTime which is what all "hardfork proposals" I've seen so far
(including this one) do.
On Wed, Jul 22, 2015 at 12:05 AM, Ross Nicoll wrote:
> On 21/07/2015
Quoting Peter Todd via bitcoin-dev :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sorry, but I think you need to re-read my first message. What you've
written below has nothing to do with what I actually said re: how
you're BIP102 and associated pull-req doesn't measure miner consensus.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sorry, but I think you need to re-read my first message. What you've written
below has nothing to do with what I actually said re: how you're BIP102 and
associated pull-req doesn't measure miner consensus.
On 22 July 2015 13:43:19 GMT-04:00, Jeff
On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I don't agree with you at all.
>
> This is a case where if Jeff doesn't understand that issue, he's
> proposing changes that he's not competent enough to understand, and it'd
> save us a l
On Wed, Jul 22, 2015 at 10:32 PM, Sriram Karra wrote:
>
> On Tue, Jul 21, 2015 at 7:28 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
>> I personally *don't* think he's doing that, rather I believe he knows
>> full well it's a bad patch and is proposing it be
Quoting Peter Todd via bitcoin-dev :
Having said that, in general triggering events without verifying a
supermajority of miner support can be very dangerous. Without miner
support the chain is insecure, and can be attacked. For instance a
blocksize limit increase that a majority of miners choo
On Tue, Jul 21, 2015 at 7:28 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I personally *don't* think he's doing that, rather I believe he knows
> full well it's a bad patch and is proposing it because he wants to push
> discussion towards a solution. Often trol
On 7/21/2015 6:58 AM, Peter Todd via bitcoin-dev wrote:
Re: BIP #'s, we explicitly have a policy of allocating them for stupid
ideas, to avoid having to be gatekeepers. Ironically that makes it
harder to get a BIP # if you know what you're doing, because Gregory
Maxwell will argue against you i
Not so much that the implementation is difficult, as it requires context
to validate a block size, rather than being able to validate it without
requiring the preceeding blocks. Yes, time on different machines may
vary, but block time is safe to use for this, because it's a
straight-forward tes
On Tue, Jul 21, 2015 at 09:04:12AM -0400, Peter Todd via bitcoin-dev wrote:
> For that reason I think BIP102 is extremely poorly designed. I can only
> conclude that Jeff Garzik is either deliberately trolling us and/or
> manipulating discussion with a badly designed proposal that he doesn't
> actu
On Tue, Jul 21, 2015 at 11:26:35AM +0200, Jorge Timón via bitcoin-dev wrote:
> I still disagree. Using height instead of time may make the
> implementation more complex by requiring some additional preparations
> but using height is in fact a simpler design. Why relay on clocks that
> we know will
I still disagree. Using height instead of time may make the
implementation more complex by requiring some additional preparations
but using height is in fact a simpler design. Why relay on clocks that
we know will differ in different computers and places when we have a
universal tick with every blo
Further to that - please disregard what I said about using block height.
Had failed to realise that in using contextual information (block
height) it complicates block validation (i.e. it would be impossible to
tell if a block is too big, without having all previous blocks first).
Block time is
Sorry...
More specifically, how many people made it to
https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#uncontroversial-hardforks
On Sat, Jul 18, 2015 at 11:22 AM, Jorge Timón wrote:
> On Sat, Jul 18, 2015 at 12:25 AM, Tier Nolan via bitcoin-dev
> wrote:
>> On Fri, Jul 17, 2015 at 9:2
On Sat, Jul 18, 2015 at 12:25 AM, Tier Nolan via bitcoin-dev
wrote:
> On Fri, Jul 17, 2015 at 9:29 PM, Luke Dashjr wrote:
>>
>> Hardforks are not something where voting makes sense. They need consensus
>> among /nodes/, not majority among /miners/. No hardfork has ever had such
>> a
>> vote.
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As an alternative to the preferred BIP100 this proposal is good
because it establishes a plan of action for dealing with the recent
ramp-up (100% increase) in number of transactions and transaction
size. Arguably, a transitory spam attack, yes, but wit
> I'm concerned that miners are prematurely bumping their soft limit to 1 MB lately.
By what measure do you call this premature?
On 17 Jul 2015 1:30 pm, Luke Dashjr via bitcoin-dev wrote:
On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote:
> BIP PR: https://github.com
On Fri, Jul 17, 2015 at 9:29 PM, Luke Dashjr wrote:
> Hardforks are not something where voting makes sense. They need consensus
> among /nodes/, not majority among /miners/. No hardfork has ever had such a
> vote.
>
Agreed.
I meant that since some of the new hard fork proposals use a voting sys
When blocks are found under or over the 10 minute threshold, hashing
difficulty is raised or reduced dinamically to keep a balance. This
intelligent measure has avoided us having discussions and kept a balance.
The same way you can't assume how much hashpower there will be to find the
next blocks,
On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote:
> BIP PR: https://github.com/bitcoin/bips/pull/173
I'm concerned that miners are prematurely bumping their soft limit to 1 MB
lately. The only reason block size limit lifting is remotely reasonable is if
we can trust miners t
I'll leave others to comment on whether we can get consensus on that,
but your years listed are inconsistent with everything else you've
written. Should be:
block 400,000 = 2MB (2016)
block 500,000 = 4MB (2018)
block 600,000 = 8MB (2020)
On 17/07/2015 20:06, Chris Wardell via bitcoin-dev wrote
I would prefer a dynamic solution that did not necessitate a second hard
fork down the road.
I propose doubling the block size every 100k blocks (~2 years)
block 400,000 = 2MB (2016)
block 500,000 = 4MB (2017)
block 600,000 = 8MB (2018)
Chris
On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bi
I'd back this if we can't find a permanent solution - 2MB gives us a lot
more wiggle room in the interim at least; one of my concerns with block
size is 3 transactions per second is absolutely tiny, and we need space
for the network to search for an equilibrium between volume and pricing
withou
On Fri, Jul 17, 2015 at 5:12 PM, Tier Nolan wrote:
> While this isn't technically a change, it does mean that both are no
> longer linked together.
>
I meant both block and transaction sizes are no longer linked together.
___
bitcoin-dev mailing list
b
Transaction sizes are still limited to 1MB with this patch. While this
isn't technically a change, it does mean that both are no longer linked
together.
Since this has no voting step, I assume the intention is that as a
compromise suggestion, it would have full support.
It establishes a preceden
What are you trying to do? Break the ice with a hard fork so that later it
becomes easier to do so, with people more complacent towards it? There are
many solutions to the scaling problem that do not require a hard fork and
are quite simple to implement actually, and don't come with the
complicatio
28 matches
Mail list logo
