On 12/26/2015 06:13 PM, Bryan Bishop wrote:
> I think you'll find that there hasn't been stalling regarding an
> uncontroversial hard-fork deployment. You might be confusing an
> uncontroversial hard-fork decision instead with how developers have
> brought up many issues about various (hard-forking
On Sat, Dec 26, 2015 at 5:15 PM, Justus Ranvier via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote:
> > I think the shortest reasonable timeframe for an uncontroversial
> > hardfork is somewhere in the range between 6 and 1
On Dec 26, 2015, at 3:16 PM, Pieter Wuille wrote:
> I am generally not interested in a system where we rely on miners to make
> that judgement call to fork off nodes that don't pay attention and/or
> disagree with the change. This is not because I don't trust them, but because
> I believe one
On Dec 27, 2015 00:06, "Jonathan Toomim" wrote:
> Given that a supermajority of users and miners have been asking for a
hard fork to increase the blocksize for years, I do not think that
mobilizing people to upgrade their nodes is going to be hard.
>
> When we do the hard fork, we will need to en
On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote:
> I think the shortest reasonable timeframe for an uncontroversial
> hardfork is somewhere in the range between 6 and 12 months.
This argument would hold more weight if it didn't looks like a stalling
tactic in context.
6 months ago, th
On Dec 26, 2015, at 3:01 PM, Pieter Wuille wrote:
> I think that's extremely short, even assuming there is no controversy about
> changing the rules at all. Things like BIP65 and BIP66 already took
> significantly longer than that, were uncontroversial, and only need miner
> adoption. Full nod
On Dec 26, 2015 23:55, "Jonathan Toomim" wrote:
>
> On Dec 26, 2015, at 8:44 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Furthermore, 75% is pretty terrible as a switchover point, as it
guarantees that old nodes will still see a 25% forked off chain temp
On Dec 26, 2015, at 8:44 AM, Pieter Wuille via bitcoin-dev
wrote:
> Furthermore, 75% is pretty terrible as a switchover point, as it guarantees
> that old nodes will still see a 25% forked off chain temporarily.
>
Yes, 75% plus a grace period is better. I prefer a grace period of about 4000
to
On Dec 26, 2015 5:45 PM, "Pieter Wuille via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> My opinion is that the role of Bitcoin Core maintainers is judging
whether consensus for a hard fork exists, and is technically necessary and
safe. We don't need a hashpower vote to decide whe
That's exactly the point: a hard fork does not just affect miners, and
cannot just get decided by miners. All full nodes must have accepted the
new rules, or they will be forked off when the hashrate percentage triggers.
Furthermore, 75% is pretty terrible as a switchover point, as it guarantees
t
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for
> making changes to it in order to satisfy economic demand. If that is
> the case, Bitcoin has failed, in my opinion.
Pieter, what's actually happening is that
I've already publicly declared that I offer one bitcoin to "those who
suffer from a May 5, 2016 hardfork to 2MB blocks" but that's probably way
too sloppy. Here's a better idea that transmits the economic power of
merchants and customers (well, anyone with bitcoin) to the miners on whom
they must
On Dec 18, 2015 2:13 AM, "sick...@gmail.com" wrote:
> 1.75 x 0.5 + 1 x 0.5 = 1.375
>
> after six month.
>
> An hard-fork on the others side would bring 1.75 since the activation, am
I right?
Yes.
However, SW immediately gives a 1.75 capacity increase for anyone who
adopts it, after the softfork,
On Fri, Dec 18, 2015 at 2:56 AM, Pieter Wuille
wrote:
> On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is responsible for making
> >> changes to it in order to satisf
On Fri, Dec 18, 2015 at 8:56 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > - only assuming robust adoption rates by up-layer ecosystem software, and
>
> That's not required. Everyone who individually switches to new
> transactions gets to do 1.75x more tra
On Thu, Dec 17, 2015 at 7:44 PM, Peter Todd wrote:
> If Bitcoin remains decentralized, miners have veto power over any
> blocksize increases. You can always soft-fork in a blocksize reduction
> in a decentralized blockchain that actually works.
>
The actual users of the system have significant p
On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik wrote:
>> You present this as if the Bitcoin Core development team is in charge
>> of deciding the network consensus rules, and is responsible for making
>> changes to it in order to satisfy economic demand. If that is the
>> case, Bitcoin has failed, i
On Thu, Dec 17, 2015 at 8:44 PM, Peter Todd via bitcoin-dev
wrote:
> If Bitcoin remains decentralized, miners have veto power over any
> blocksize increases. You can always soft-fork in a blocksize reduction
> in a decentralized blockchain that actually works.
You can always schism hardfork miner
On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille
wrote:
> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > t
On Thu, Dec 17, 2015 at 04:58:02PM +, Tier Nolan via bitcoin-dev wrote:
> This is really the most important question.
>
> Bitcoin is kind of like a republic where there is separation of powers
> between various groups.
>
> The power blocs in the process include
>
> - Core Devs
> - Miners
> -
On Wed, Dec 16, 2015 at 9:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> We are not avoiding a choice. We don't have the authority to make a choice.
>
This is really the most important question.
Bitcoin is kind of like a republic where there is separation
On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is res
On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I indeed think we can communicate much better that deciding consensus
> rules is not within our power.
I'm not a core dev, so maybe I have the power to change the consensus
rules. No o
On Wed, Dec 16, 2015 at 1:36 PM, jl2012 wrote:
> 4. In the miners round table on the second day, one of the devs mentioned
> that he didn't want to be seen as the decision maker of Bitcoin. On the
> other hand, Chinese miners repeatedly mentioned that they want several
> concrete proposals from d
On Wed, Dec 16, 2015 at 4:24 PM, Jorge Timón wrote:
> Assuming we adopt bip102, eventually you will be able to say exactly the
> same about 2 MB. When does this "let's not change the economics" finishes
> (if ever)?
>
The question is answered in the original email.
In the short term, the risk o
On Dec 16, 2015 10:08 PM, "Jeff Garzik via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille
wrote:
>>
>> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
>> wrote:
>> > 2) If block size stays at 1M, the Bitcoin Core develo
On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik wrote:
>> You present this as if the Bitcoin Core development team is in charge
>> of deciding the network consensus rules, and is responsible for making
>> changes to it in order to satisfy economic demand. If that is the
>> case, Bitcoin has failed,
On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille
wrote:
> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > t
I would also like to summarize my observation and thoughts after the
Hong Kong workshop.
1. I'm so glad that I had this opportunity to meet so many smart
developers who are dedicated to make Bitcoin better. Regular conference
like this is very important for a young project, and it is particula
On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
wrote:
> 2) If block size stays at 1M, the Bitcoin Core developer team should sign a
> collective note stating their desire to transition to a new economic policy,
> that of "healthy fee market" and strongly urge users to examine their f
All,
Following the guiding WP principle of Assume Good Faith, I've been trying
to boil down the essence of the message following Scaling Bitcoin. There
are key bitcoin issues that remain outstanding and pressing, that are*
orthogonal to LN & SW*.
I create multiple proposals and try multiple angl
31 matches
Mail list logo
