Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Venzen Khaosan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tell you what, eloquent guy...

Give me 15 minutes in a public open mic session with you and i'll
remove you from your high horse and close your voice in Bitcoin, for
good.

Guaranteed. You're too stupid for me to let you run loose with client
funds and this great innovation.

Anytime, anywhere. I'm ready to dismantle your intellectual bankruptcy
in front of the world.

I'll go for your psychological throat first.

Sincerely,
Venzen Khaosan.



On 10/05/2015 11:56 PM, Mike Hearn via bitcoin-dev wrote:
> Hey Sergio,
> 
> To clarify: my /single/ objection is that CLTV should be a hard
> fork. I haven't been raising never-ending technical objections,
> there's only one.
> 
> I /have/ been answering all the various reasons being brought up
> why I'm wrong and soft forks are awesome  and there do seem to
> be a limitless number of such emails  but on my side it's still
> just a single objection. If CLTV is a hard fork then I won't be
> objecting anymore, right?
> 
> CLTV deployment is clearly controversial. Many developers other
> than me have noted that hard forks are cleaner, and have other
> desirable properties. I'm not the only one who sees a big question
> mark over soft forks.
> 
> As everyone in the Bitcoin community has been clearly told that 
> controversial changes to the consensus rules must not happen, it's
> clear that CLTV cannot happen in its current form.
> 
> Now I'll be frank - you are quite correct that I fully expect the
> Core maintainers to ignore this controversy and do CLTV as a soft
> fork anyway. I'm a cynic. I don't think "everyone must agree" is
> workable and have said so from the start. Faced with a choice of
> going back on their public statements or having to make changes to
> something they clearly want, I expect them to redefine what "real
> consensus" means. I hope I'm wrong, but if I'm not . well, at
> least everyone will see what Gavin and I have been talking about
> for so many months.
> 
> But I'd rather the opcode is tweaked. There's real financial risks
> to a soft fork.
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWFBGjAAoJEGwAhlQc8H1mn2cH/0pTx1C0FK8shPSPaC3xB6sA
DpGTMrLWNai3i9VTwkUw8UvbqeL2QtZDghPdkDcvbmvOMc3UrOMQbc1eQ1eL6i3g
DiUCqUShOIAIvWJXGPTPNBulWBW9VkgK0y3uOprTd5D0VWKpWvDj+DMNqHaAC2Ab
JAfHx0mHlkTfrcBl30eAJWxoqG/ohu5QvTIP64AsK6w53qlbMcB13cES8mS/HJX9
MUtBcCbYRfF3Gu+OeYaEzzzXeuwsqql9qHr2wZYe9rECkSmYgL0DT5+WZiLY8B/x
E3dFtufR7yAHr91/gj9itOKf+unumhduX8LY8ubuIKmuwjdj30MDdNy7fqZ3uGs=
=lftV
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Milly Bitcoin via bitcoin-dev]

This list is about "Development discussion list for Bitcoin protocol and 
its implementation" So legal notices placed on the software is relevant 
to the list.


It is also relevant that you go around speaking with authority when you 
have no idea what you are talking about.  A copyright is a legal notice 
and the courts care how the notice is written.  The purpose of the 
notice is to notify people of potential litigation if they use the 
software in a certain way.  You want to claim "off topic" because you 
caught spouting nonsense and you want to divert attention elsewhere.


Russ



On 10/6/2015 1:53 AM, Luke Dashjr wrote:

Copyright doesn't care how notices are written. They are merely informative
to humans reading them. Anyhow, this is not development related, so please
direct any further discussion of it to me directly (with any applicable CCs)
and NOT to the mailing list.

Thanks,

Luke



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Eric Lombrozo via bitcoin-dev]

I prefer the term "clown".

Can we please move on?

-- Original Message --
From: "cipher anthem via bitcoin-dev" 


To: mi...@bitcoins.info
Cc: bitcoin-dev@lists.linuxfoundation.org
Sent: 10/6/2015 12:17:14 AM
Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork 
technical debate



 Sent: Monday, October 05, 2015 at 8:21 PM
 From: "Milly Bitcoin via bitcoin-dev" 


 To: bitcoin-dev@lists.linuxfoundation.org
 Subject: Re: [bitcoin-dev] This thread is not about the soft/hard 
fork technical debate

 On 10/5/2015 4:05 PM, Steven Pine via bitcoin-dev wrote:

 It's pretty clear Mike has turned into concern troll and bully.



 "troll" and, even worse, "concern troll" are terms generally used by
 teenagers on places like Reddit to complain about someone who doesn't
 agree with them.


They should substitute troll for cultist so they appear more 
professional...

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[naama.kates--- via bitcoin-dev]

Just read the proposal for the dual modes... Think it would be best... Protocol 
question?  Do we discuss the algorithms here on this forum?  Or...

Sorry again for my thick skull!

Nina K

Sent from my iPhone

> On Oct 6, 2015, at 1:34 AM, NotMike Hearn via bitcoin-dev 
>  wrote:
> 
> I think I can solve the debate and give everyone what they want.
> 
> Some people want BIP65, others do not.
> 
> We can roll out 65 in a clever way, such that Greg/PeterT can get it, but 
> Mike and Peter R don't need to have it (both versions can run alongside each 
> other). Even better, people can switch back and forth between versions as 
> much as they like.
> 
> How might this work? Well, paradoxically, we could do this by *imposing 
> additional constraints* on transaction validation, such that transactions 
> made a very specific certain way will always look valid to non-CLTVers, but 
> for CLTVers they will not be valid unless the CLTV rules are followed. The 
> obvious concern is that non-CLTV people might receive invalid payments. 
> However, their software is already set up to request payments in a non-CLTV 
> way, so, luckily, this is actually not a problem at all! SPV clients can 
> elect to only connect to nodes which are non-CLTV.
> 
> Problem solved!
> 
> I am happy to have solved this problem for you all, and ended this discord 
> harmoniously. If we all put our heads together, these words of founding 
> father Aretha Franklin will ring true: "there's nothing we can't overcome".
> 
> 
>> On Tue, Oct 6, 2015 at 3:29 AM, Marcel Jamin via bitcoin-dev 
>>  wrote:
>> This is childish and very disappointing to see.
>> 
>> 2015-10-06 9:20 GMT+02:00 Eric Lombrozo via bitcoin-dev 
>> :
>>> I prefer the term "clown".
>>> 
>>> Can we please move on?
>>> 
>>> -- Original Message --
>>> From: "cipher anthem via bitcoin-dev" 
>>> 
>>> To: mi...@bitcoins.info
>>> Cc: bitcoin-dev@lists.linuxfoundation.org
>>> Sent: 10/6/2015 12:17:14 AM
>>> Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork 
>>> technical debate
>>> 
>  Sent: Monday, October 05, 2015 at 8:21 PM
>  From: "Milly Bitcoin via bitcoin-dev" 
> 
>  To: bitcoin-dev@lists.linuxfoundation.org
>  Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork 
> technical debate
>>  On 10/5/2015 4:05 PM, Steven Pine via bitcoin-dev wrote:
>>  It's pretty clear Mike has turned into concern troll and bully.
 
>  "troll" and, even worse, "concern troll" are terms generally used by
>  teenagers on places like Reddit to complain about someone who doesn't
>  agree with them.
 
 They should substitute troll for cultist so they appear more 
 professional...
 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> 
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
>> 
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[phm via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In any case this is basically the purpose of version tracking software
such as Git or CVS or any other. It would not be hard to figure out who
had done what. I see you're splitting hairs over nothing as usual,
though, Russ, so I'll leave you to it.

phm

Milly Bitcoin via bitcoin-dev wrote:
> Maybe you are confused with a compilation notice that would say "All Content 
> Copyright and other rights reserved by its Respective Owners" or something 
> similar.  That is not the same thing as claiming ownership using the "c" 
> inside the circle. > > There is also a difference between claiming a 
> copyright for
individual works as part of a compilation as opposed to claiming a
copyright on the compilation itself (which is what the current notice
is). > > Russ > > > On 10/6/2015 1:08 AM, Milly Bitcoin wrote: >>> The
copyright notice refers to the fact that each contributor owns >>>
copyright >>> to his own contributions. There is no legal group that
owns copyright >>> to the >>> entirety of the code. >>> >> >> No, that
is not what such a notice means.  The part after the "c" in the >>
circle is the legal owner.  If the legal owners are not properly >>
identified then the notice is not valid. >> >> --- >>  From Nolo: >> >>
What is a valid copyright notice? >> >> A copyright notice should
contain: >> •the word "copyright" >> •a "c" in a circle (©) >> •the date
of publication, and >> •the name of either the author or the owner of
all the copyright rights >> in the published work. >> >> For example,
the correct copyright for the fourth edition of The >> Copyright
Handbook, by Stephen Fishman (Nolo), is Copyright © 1998 by >> Stephen
Fishman. >> >> --- >> from USPTO: >> >> Use of the notice informs the
public that a work is protected by >> copyright, identifies the
copyright owner, and shows the year of first >> publication. >> --- >>
>> Russ >> > > > ___ >
bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org >
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWFEewAAoJEIUV926tz9E87a4P/21Znk1tx/ZCA4eykig75S9I
d0xyLRREVL/SBOBzE8kJh1YmiHAG1ziHzsgpobNn/N2VuKanCKSXuR3niV5WRtYw
+Oa4uVZUNtAtXKSrFSiGpwJoZN5JnUADcx4sK7En3Z5gFEYSAPrMwvm+M0upl9rd
5b2/VQ/dm3fDUnntnz4DfhV3otEbcLo6imaaV6RDIPru61Fc20blHJhQPEX0laex
N1rUiUvsyUL9H66fGFYmm/6YJcO26k3gPNmmODJdApv7uTVfHBj3c2r4xKSIDVES
WxdL+DdyzJQU6Ng95793QTx29Wn8pV1FlMkC9TQ3biQ1ivoAAKbvxzI27swbPx7d
WGu/ATDj3UN2RBY3hzTTpMIVK5kITVo+QGtA8cg+KcLjVPaasYdb13zy/pE6PO8J
4AWd/nYP/bQlkrebeFylY7vQi6TNCDtpfkJE2r8H+3RovqigN+pLLVhuEVlOBtM1
7N5gAvJWqKtUIgzNKte+eS/yaOFBhHp+veC+QfNMDechC4OGM7IDVdf9oVy9DSCX
68XThI62AT+uhKjvs8ZG3L88AUiiYK6RC4YCUZVoydbQHovmvQRL3Wb36n+krcGH
iV3n3lfk7+D9IrX6ieRwmHpa9a7VAIekqUuCSBdsXBCUM5zNz48bRNJSofjWLtSm
5p0mp5jQxte8loevZztf
=psJx
-END PGP SIGNATURE-

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[NotMike Hearn via bitcoin-dev]

I think I can solve the debate and give everyone what they want.

Some people want BIP65, others do not.

We can roll out 65 in a clever way, such that Greg/PeterT can get it, but
Mike and Peter R don't need to have it (both versions can run alongside
each other). Even better, people can switch back and forth between versions
as much as they like.

How might this work? Well, paradoxically, we could do this by *imposing
additional constraints* on transaction validation, such that transactions
made a very specific certain way will always look valid to non-CLTVers, but
for CLTVers they will not be valid unless the CLTV rules are followed. The
obvious concern is that non-CLTV people might receive invalid payments.
However, their software is already set up to request payments in a non-CLTV
way, so, luckily, this is actually not a problem at all! SPV clients can
elect to only connect to nodes which are non-CLTV.

Problem solved!

I am happy to have solved this problem for you all, and ended this discord
harmoniously. If we all put our heads together, these words of founding
father Aretha Franklin will ring true: "there's nothing we can't overcome".


On Tue, Oct 6, 2015 at 3:29 AM, Marcel Jamin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is childish and very disappointing to see.
>
> 2015-10-06 9:20 GMT+02:00 Eric Lombrozo via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>:
>
>> I prefer the term "clown".
>>
>> Can we please move on?
>>
>> -- Original Message --
>> From: "cipher anthem via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org>
>> To: mi...@bitcoins.info
>> Cc: bitcoin-dev@lists.linuxfoundation.org
>> Sent: 10/6/2015 12:17:14 AM
>> Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork
>> technical debate
>>
>>  Sent: Monday, October 05, 2015 at 8:21 PM
  From: "Milly Bitcoin via bitcoin-dev" <
 bitcoin-dev@lists.linuxfoundation.org>
  To: bitcoin-dev@lists.linuxfoundation.org
  Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork
 technical debate
  On 10/5/2015 4:05 PM, Steven Pine via bitcoin-dev wrote:

>  It's pretty clear Mike has turned into concern troll and bully.
>

>>>  "troll" and, even worse, "concern troll" are terms generally used by
  teenagers on places like Reddit to complain about someone who doesn't
  agree with them.

>>>
>>> They should substitute troll for cultist so they appear more
>>> professional...
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Venzen Khaosan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sergio Demain,

You and I have had our altercation, in private, about your assumptions
of authority in this community. That was fine when you told me "for
fuck's sake" on IRC. I'm a man and I made you see your error and
apologize for your trespass.

Now, you present me and the list with an interpretation of some higher
goal that an obviously low-level participant, Mike Hearn, is actioning
here.

No. What you espouse is not what Hearn had premeditated. It all
happened in your mind. "Agent" (quoting popular media) Hearn is a
compulsive contrarian and has a verifiable track record of opposing
and arguing against consensus wherever he endevors. According to
Snowden, he did harm to the public and to colleagues vis-a-vis NSA
surveillance while he held office at Google and he is doing the same
via XT. He is no longer at Google - supposedly by free will. I would
venture, from his own stated goals, that he is in Bitcoin in search of
a salary, even though he displays a fundamental lack of understanding
of Open Source methodology and ideology. And a misconception of
Bitcoin's ability to scale.

The self-proclaimed glory of bitcoinj is a false and empty claim. I
have had to code my nodes to ignore bitjoinj because of its disregard
for protocol policy. For numerous reasons they are more of an irritant
than a positive presence on the network.

You, Lerner, not having an issue with his fallacious position and
actions, speaks about you, too. But you "have nothing for or against
Mike personally" so he's just another participant, regardless of his
behavior and track record, then you give him a thumbs up? Many, maybe
a majority, including Satoshi, have expressed deplorement of O'Hearn
and Andresen. With or without Satoshi you can see the terminal
consensus breach these two populists had engaged in for yourself.
Please answer me and the list how their action does not warrant
rejection from the community?

Yet, for the rest of list members: Agent Hearn, a known co-operative,
shows up with challenges and you respond as if to an equal? A former
head-man, before things fell apart, now an accomplice of Agent Hearn,
Andresen, sprays criticism and you dutifully answer, as if to a Big
Man? Who is he? That self-proclaimed grumpy old-timer? "Run to Google
benchmarks" and there you go. Google? Come on! This is the man who
broke the fundamental consensus rule and now he's got you introducing
Google dependencies into Bitcoin? You're OK with that? Go to XT, you
won't find me or anyone in the community objecting to you and Gavin
playing with Google and all sorts of prefab code there.

Sergio, don't presume to tell me or the list what another man is
saying or what rhythmless jive he's playing. Like everyone here, I
have eyes to see and a mind to comprehend: Hearn is not capable of the
double-play you imply. Nor are you, for that matter. So, thanks for
cutting the cake and showing your true colors, but best you don't
speak for someone else. Speak for yourself so everything is clear and
allegiances don't taint you and whatever you may want to speak, for
yourself, later.


On 10/05/2015 10:56 PM, Sergio Demian Lerner via bitcoin-dev wrote:
> Some of the people on this mailing list are blindly discussing the 
> technicalities of a soft/hard fork without realizing that is not
> Mike's main intention. At least I perceive (and maybe others too)
> something else is happening.
> 
> Let me try to clarify: the discussion has nothing to do with
> technical arguments. I generally like more hard forks than soft
> forks (but I won't explain why because this is not a technical
> thread), but for CLTV this is quite irrelevant (but I won't explain
> why..), and I want CLTV to be deployed asap.
> 
> Mike's intention is to criticize the informal governance model of 
> Bitcoin Core development and he has strategically pushed the
> discussion to a dead-end where the group either:
> 
> 1) ignores him, which is against the established criteria that all 
> technical objections coming from anyone must be addressed until
> that person agrees, so that a change can be uncontroversial. If the
> group moves forward with the change, then the "uncontroversial"
> criteria is violated and then credibility is lost. So a new
> governance model would be required for which the change is within
> the established rules.
> 
> 2) respond to his technical objections one after the other, on
> never ending threads, bringing the project to a standstill.
> 
> As I don't want 2) to happen, then 1) must happen, which is what
> Mike wants. I have nothing for or against Mike personally. I just
> think Mike Hearn has won this battle. But having a more formal
> decision making process may not be too bad for Bitcoin, maybe it
> can actually be good.
> 
> Best regards from a non-developer to my dearest developer friends, 
> Sergio.
> 
> 
> 
> ___ bitcoin-dev mailing
> list 

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Btc Drak via bitcoin-dev]

On Mon, Oct 5, 2015 at 6:26 PM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> History has shown that for many decision making processes this doesn't
> work,
> and this argument has been made to Core.
> Until today this was essentially a rule that hurt the things that Mike was
> really passionate about.
> Today this hurts the things that some other devs are passionate about.
>

If you are referring to some of Mike's PRs that were either refused or
reverted, it was because they where substantial technical objections to
them. This isn't even in the same ballpark.

Surely you see the absurdity of arguing against soft forks after we
successfully used them already for BIP34 and BIP66?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Tom Zander via bitcoin-dev]

On Monday 5. October 2015 18.03.05 Btc Drak via bitcoin-dev wrote:
> However, I would like to challenge your assumption of point 1 that that by
> Mike making a rabble, it somehow makes CLTV deployment controversial. His
> arguments have  been refuted.

Unsuccessfully.

> Simply making a noise does not make something controversial. When it is
> controversial, it is obvious and plain to see.

I think its plain to see the soft fork is controversial.

But that’s not the point.

The point is that Bitcoin Core claims to have a consensus mechanism and sticks 
to "no change" on not reaching a consensus. And that rule is the reason why 
bigger blocks were blocked for years.

History has shown that for many decision making processes this doesn't work, 
and this argument has been made to Core. 
Until today this was essentially a rule that hurt the things that Mike was 
really passionate about.
Today this hurts the things that some other devs are passionate about.

I think today is the day that everyone should agree that the past is the past 
and we all learned our lesson and Bitcoin Core will make decisions a different 
way.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[s7r via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

First, this only makes reference to hard forks not to soft forks. This
is very important because we are trying to apply a hard fork
requirement to a soft fork procedure which obviously won't work.

Your statement that 'all objections coming from anyone must be
addressed until that person agrees' is not applicable in reality. What
if that person objecting is explained several times, with plausible
and verifiable technical arguments, and that person still doesn't
agree (either on purpose, either really doesn't understand the
explanations)? What will we do in this case? Assume it's controversial
because someone refuses to or simply doesn't understand? This seams at
least a little bit unfair.

It's like we are in a court room where a text from a law (like this
requirement from that BIP) can be twisted and interpreted in various
way in an endless debate. We cannot apply everything as-it-is-stated
word-by-word and apply it _blindly_ like robots in every situation,
everything always depends on context and other factors.

For example, I don't see this controversial nor a violation of the BIP
requirements. Mike had some fair objections, they were explained by
gmaxwell and Jorge, everybody understood. The explanation is clear,
with plausible practical examples, so from my point of view the
objections have no arguments to sustain the claim. I don't see
anything controversial here. Now of course it's Mike's right to reject
those explanations, but what's the 'controversial' here?

On 10/5/2015 6:56 PM, Sergio Demian Lerner via bitcoin-dev wrote:
> Some of the people on this mailing list are blindly discussing the 
> technicalities of a soft/hard fork without realizing that is not
> Mike's main intention. At least I perceive (and maybe others too)
> something else is happening.
> 
> Let me try to clarify: the discussion has nothing to do with
> technical arguments. I generally like more hard forks than soft
> forks (but I won't explain why because this is not a technical
> thread), but for CLTV this is quite irrelevant (but I won't explain
> why..), and I want CLTV to be deployed asap.
> 
> Mike's intention is to criticize the informal governance model of 
> Bitcoin Core development and he has strategically pushed the
> discussion to a dead-end where the group either:
> 
> 1) ignores him, which is against the established criteria that all 
> technical objections coming from anyone must be addressed until
> that person agrees, so that a change can be uncontroversial. If the
> group moves forward with the change, then the "uncontroversial"
> criteria is violated and then credibility is lost. So a new
> governance model would be required for which the change is within
> the established rules.
> 
> 2) respond to his technical objections one after the other, on
> never ending threads, bringing the project to a standstill.
> 
> As I don't want 2) to happen, then 1) must happen, which is what
> Mike wants. I have nothing for or against Mike personally. I just
> think Mike Hearn has won this battle. But having a more formal
> decision making process may not be too bad for Bitcoin, maybe it
> can actually be good.
> 
> Best regards from a non-developer to my dearest developer friends, 
> Sergio.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWErRQAAoJEIN/pSyBJlsRxJMIAI9eoPny6B2VOH/wSkfeeVbu
bZ+0ZBLfDIwzQ2Tqn0DZQ8TWHfHPHacA7IxtTRnkSqPTMcDUgZ5/URBE4Tt8p2F2
zDda0NjqMUIJIBkLHRHzApRTK+BcshtarSbGJOr7HUaOb2hyDnQp1bzOMPGpIdTq
YA5EY39SdzzJaF7uto/bhFj6g51kdxux2epbmbaJjUHFUO1+6RAw/irI6hkyzWzi
VS8l6ZpXiaV3Y1pU+Nc60sa4GacYwKvFmvve7DTIYVsPV6KzJmbT924n5TW3191H
JBxRnUUqoWEae/h85pOQiYbJGX/EtXOmy2CZcGm0TkL3vXsAwxiDQyz8NlNyAOI=
=ClSy
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Tom Zander via bitcoin-dev]

On Monday 5. October 2015 20.33.04 s7r via bitcoin-dev wrote:
> For example, I don't see this controversial nor a violation of the BIP
> requirements. Mike had some fair objections, they were explained by
> gmaxwell and Jorge, everybody understood. The explanation is clear,
> with plausible practical examples, so from my point of view the
> objections have no arguments to sustain the claim.

I enjoyed reading them, but I have to admit I'm not convinced and for me the 
objections stand.

Softforks are unnecessarily dangerous and I feel entirely avoidable. It is a 
risk that not worth taking.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Tom Zander via bitcoin-dev]

Gregory,

you are good at language and its easy to write eloquent words.

Looking at this little dialog, for instance;

On Mon, Oct 5, 2015 at 3:56 PM, Sergio Demian Lerner wrote:
> > 1) ignores him, which is against the established criteria that all
> > technical objections coming from anyone must be addressed until that
> > person agrees, so that a change can be uncontroversial.
[snip]
On Monday 5. October 2015 18.35.13 Gregory Maxwell via bitcoin-dev wrote:
> I am aware of no instance where an active contributor to core has made
> the claim that no change to consensus can happen without 100% support

This *seems* to read like the same thing. But it is not.  Your version is more 
polarizing and changes the intent quite dramatically.

It is an eloquent change, but not really the topic we were discussing. It also 
makes you attack Mike (calling him out as having a strawman) without basis.
For the second time in this thread. 
I would suggest arguing on the topic, not on the man.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Btc Drak via bitcoin-dev]

On Mon, Oct 5, 2015 at 5:56 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> CLTV deployment is clearly controversial. Many developers other than me
> have noted that hard forks are cleaner, and have other desirable
> properties. I'm not the only one who sees a big question mark over soft
> forks.
>

No, that is not correct and you are distorting facts to fit your argument.
We have discussed the tradeoffs of each method in general, but that does
not make hard forks or soft forks controversial in an of itself.

There is technical consensus to roll out CLTV by ISM, and if somehow you
are right, it will come out during deployment in much the same way as your
recent attempt at rolling out a controversial hardfork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Tom Zander via bitcoin-dev]

On Monday 5. October 2015 18.04.48 Gregory Maxwell wrote:
> > Unsuccessfully.
> 
> I think rather successfully.

Arguing that BIP66 rollout was a full success is in the same park of 
"successful" ?
Where for weeks people were told not to trust the longest chain until it was 
30 blocks.
Lets put that in perspective. The main functionality of Bitcoin  
Frankly, if that fiasco happened in a company, people would get fired for 
gross misconduct.

Bottom line is that there is a horrible track record of doing soft forks in 
the past, there are some really good technical reasons why this should not 
happen again. 

And the defence against this argument is to do character assassination because 
you think he has ulterior motives?  Like you say in this part;

> That Mike himself continues to misexplain
> things is not surprising since he has all but outright said that his
> motivation here is to disrupt Bitcoin in order to try to force his
> blocksize hardfork on people. 

"all but outright said" is still not said. Is still just a suspicion you have. 
And you are accusing a man of something he didn't do.
That’s just not right.

> > The point is that Bitcoin Core claims to have a consensus mechanism and
> > sticks to "no change" on not reaching a consensus. And that rule is the
> > reason why bigger blocks were blocked for years.
> 
> You're repeating Mike's claims there-- not anyone elses. Take your
> complaint up with him-- not the list.

There is no complaint. Why do you think there is?
Are you claiming that not reaching consensus is NOT the reason that bigger 
blocks are not in Bitcoin Core?


Reaching consensus is an admirable goal. But its exactly that, a goal.
And anyone that is a perfectionist will know that in the real world goals are 
often not reached. That doesn't make them less useful. That makes them goals.
This specific goal is in conflict of building a good product and a well 
functioning community.

A good product and a well functioning community needs rules and needs timely 
decisions and conflict resolution.
It does not need muting of valuable voices, it does not need character 
assassinations and it really doesn't need egos.

I suggest reading this book;
http://www.artofcommunityonline.org/


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[NotMike Hearn via bitcoin-dev]

For soft forks, consensus is required. In fact, we (today) have miners who
individually choose to mine blocks that are completely empty, with no known
input from (or communication with) the outside world. This is a consensus
process. Users can switch back and forth all they like, and this only
happens when there is unanimous miner-developer consensus. Most of the time
they don't even know, that they are under consensus.

It is only "controversial hard forks" which DON'T require wide agreement
and developer endorsements. Hear me out.

This is because, with zero dev-agreement, we have two benefits: first,
there are tremendous security issues which can be fixed by trying more than
one hard fork at once (these fixes can prevent loss of funds), and, second,
because each fork is equally Acked and Nacked (a Schrodinger's Ack, if you
will), they will have equal standing, and therefore users will be equally
indifferent to both forks and they will both live for a long time (and
users will be able to pick the fork that best fits them, empowering the
user).

People have overlooked how simple this issue is because of the political
climate. We need a climate change, pardon the pun.

On Mon, Oct 5, 2015 at 2:33 PM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Monday 5. October 2015 18.04.48 Gregory Maxwell wrote:
> > > Unsuccessfully.
> >
> > I think rather successfully.
>
> Arguing that BIP66 rollout was a full success is in the same park of
> "successful" ?
> Where for weeks people were told not to trust the longest chain until it
> was
> 30 blocks.
> Lets put that in perspective. The main functionality of Bitcoin
> Frankly, if that fiasco happened in a company, people would get fired for
> gross misconduct.
>
> Bottom line is that there is a horrible track record of doing soft forks in
> the past, there are some really good technical reasons why this should not
> happen again.
>
> And the defence against this argument is to do character assassination
> because
> you think he has ulterior motives?  Like you say in this part;
>
> > That Mike himself continues to misexplain
> > things is not surprising since he has all but outright said that his
> > motivation here is to disrupt Bitcoin in order to try to force his
> > blocksize hardfork on people.
>
> "all but outright said" is still not said. Is still just a suspicion you
> have.
> And you are accusing a man of something he didn't do.
> That’s just not right.
>
> > > The point is that Bitcoin Core claims to have a consensus mechanism and
> > > sticks to "no change" on not reaching a consensus. And that rule is the
> > > reason why bigger blocks were blocked for years.
> >
> > You're repeating Mike's claims there-- not anyone elses. Take your
> > complaint up with him-- not the list.
>
> There is no complaint. Why do you think there is?
> Are you claiming that not reaching consensus is NOT the reason that bigger
> blocks are not in Bitcoin Core?
>
>
> Reaching consensus is an admirable goal. But its exactly that, a goal.
> And anyone that is a perfectionist will know that in the real world goals
> are
> often not reached. That doesn't make them less useful. That makes them
> goals.
> This specific goal is in conflict of building a good product and a well
> functioning community.
>
> A good product and a well functioning community needs rules and needs
> timely
> decisions and conflict resolution.
> It does not need muting of valuable voices, it does not need character
> assassinations and it really doesn't need egos.
>
> I suggest reading this book;
> http://www.artofcommunityonline.org/
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[NotMike Hearn via bitcoin-dev]

>
>
> On Mon, Oct 5, 2015 at 11:20 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> > On Oct 5, 2015, at 6:37 PM, Tom Harding via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > On 10/5/2015 1:56 PM, Gregory Maxwell via bitcoin-dev wrote:
> >> In this case, I don't even believe we have any regulator contributors
> >> that disagree.
> >
> > Since Gavin Andresen chose you to be one of 4 people who decides whose
> > contributions are accepted to the Core project, shouldn't you recuse
> > yourself from referencing "regular contributor" as some kind of bar to
> > an opinion being worthy?
> >
> > You don't want to be accused of squelching a person's opinions by
> > nacking or sitting on commits, then turning around and branding those
> > opinions as worthless because they are not from a "regular contributor."
> > Do you?
>
> Great point, Tom!
>
> In fact, you’ve just explained the dynamics that create “centralizing
> pressure” in regards to development:  If the weight of a person’s opinion
> is proportional to how many commits that person has made, and if the
> probability of getting a commit pulled is proportional to the weight of
> that person’s opinion, well…I’m pretty sure this results in a differential
> equation that has a solution that results in ever-increasing centralized
> control of the code base.
>

Really great stuff, Mr. R! We can use differential equations to measure
centralization pressure (I'm pretty sure, good idea). If we want
decentralization (or even mere stability), we must impose a
counterbalancing rule such that each past commit makes one *less* likely to
get their next commit pulled. For example, a "one man one commit" policy.


>
> I believe we should work to deprecate the idea that Core is somehow the
> “core of Bitcoin," in favour of multiple competing implementations. XT and
> btcd are two working examples of this idea.  Let’s make it easier for the
> community to determine the evolution of Bitcoin by making it easier for the
> community to express their vote based on the code we choose to run.
>

Yes, this is essential. Greg, stop making it so hard for me to  determine
the evolution of Bitcoin by making it hard to express my vote based on the
code I choose to run. Blockstream is always doing that I am sick of it.

Mr. R really understands these concepts at a deep level and people need to
pay more attention to what he has to say. Nash equilibriums are very
important mathematical concept, for example:
https://www.reddit.com/r/Bitcoin/comments/3nhq5a/deprecating_bitcoin_core_visualizing_the/


>
> Best regards,
> Peter
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Milly Bitcoin via bitcoin-dev]

The copyright notice refers to the fact that each contributor owns copyright
to his own contributions. There is no legal group that owns copyright to the
entirety of the code.



No, that is not what such a notice means.  The part after the "c" in the 
circle is the legal owner.  If the legal owners are not properly 
identified then the notice is not valid.


---
From Nolo:

What is a valid copyright notice?

A copyright notice should contain:
•the word "copyright"
•a "c" in a circle (©)
•the date of publication, and
•the name of either the author or the owner of all the copyright rights 
in the published work.


For example, the correct copyright for the fourth edition of The 
Copyright Handbook, by Stephen Fishman (Nolo), is Copyright © 1998 by 
Stephen Fishman.


---
from USPTO:

Use of the notice informs the public that a work is protected by 
copyright, identifies the copyright owner, and shows the year of first 
publication.

---

Russ


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Luke Dashjr via bitcoin-dev]

Copyright doesn't care how notices are written. They are merely informative 
to humans reading them. Anyhow, this is not development related, so please 
direct any further discussion of it to me directly (with any applicable CCs) 
and NOT to the mailing list.

Thanks,

Luke

On Tuesday, October 06, 2015 5:49:40 AM Milly Bitcoin via bitcoin-dev wrote:
> Maybe you are confused with a compilation notice that would say "All
> Content Copyright and other rights reserved by its Respective Owners" or
> something similar.  That is not the same thing as claiming ownership
> using the "c" inside the circle.
> 
> There is also a difference between claiming a copyright for individual
> works as part of a compilation as opposed to claiming a copyright on the
> compilation itself (which is what the current notice is).
> 
> Russ
> 
> On 10/6/2015 1:08 AM, Milly Bitcoin wrote:
> >> The copyright notice refers to the fact that each contributor owns
> >> copyright
> >> to his own contributions. There is no legal group that owns copyright
> >> to the
> >> entirety of the code.
> > 
> > No, that is not what such a notice means.  The part after the "c" in the
> > circle is the legal owner.  If the legal owners are not properly
> > identified then the notice is not valid.
> > 
> > ---
> > 
> >  From Nolo:
> > What is a valid copyright notice?
> > 
> > A copyright notice should contain:
> > •the word "copyright"
> > •a "c" in a circle (©)
> > •the date of publication, and
> > •the name of either the author or the owner of all the copyright rights
> > in the published work.
> > 
> > For example, the correct copyright for the fourth edition of The
> > Copyright Handbook, by Stephen Fishman (Nolo), is Copyright © 1998 by
> > Stephen Fishman.
> > 
> > ---
> > from USPTO:
> > 
> > Use of the notice informs the public that a work is protected by
> > copyright, identifies the copyright owner, and shows the year of first
> > publication.
> > ---
> > 
> > Russ
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Peter R via bitcoin-dev]

> If we want decentralization (or even mere stability), we must impose a 
> counterbalancing rule such that each past commit makes one *less* likely to 
> get their next commit pulled. For example, a "one man one commit" policy.

Haha great stuff, NotMike!

Indeed, it’s not enough to keep the block size limit small so that every man 
can run his own node, we also must also implement your proposed “one man, one 
commit” policy!  Think of the decentralization if everyone Bitcoin user is also 
contributing code!/s

Peter



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Milly Bitcoin via bitcoin-dev]

Maybe you are confused with a compilation notice that would say "All 
Content Copyright and other rights reserved by its Respective Owners" or 
something similar.  That is not the same thing as claiming ownership 
using the "c" inside the circle.


There is also a difference between claiming a copyright for individual 
works as part of a compilation as opposed to claiming a copyright on the 
compilation itself (which is what the current notice is).


Russ


On 10/6/2015 1:08 AM, Milly Bitcoin wrote:

The copyright notice refers to the fact that each contributor owns
copyright
to his own contributions. There is no legal group that owns copyright
to the
entirety of the code.



No, that is not what such a notice means.  The part after the "c" in the
circle is the legal owner.  If the legal owners are not properly
identified then the notice is not valid.

---
 From Nolo:

What is a valid copyright notice?

A copyright notice should contain:
•the word "copyright"
•a "c" in a circle (©)
•the date of publication, and
•the name of either the author or the owner of all the copyright rights
in the published work.

For example, the correct copyright for the fourth edition of The
Copyright Handbook, by Stephen Fishman (Nolo), is Copyright © 1998 by
Stephen Fishman.

---
from USPTO:

Use of the notice informs the public that a work is protected by
copyright, identifies the copyright owner, and shows the year of first
publication.
---

Russ




___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Luke Dashjr via bitcoin-dev]

On Tuesday, October 06, 2015 3:39:59 AM Milly Bitcoin via bitcoin-dev wrote:
> In any case if I could get a list of "Core Developers" as referenced in
> the copyright notice that would also be good since that is a legal notice.

The copyright notice refers to the fact that each contributor owns copyright 
to his own contributions. There is no legal group that owns copyright to the 
entirety of the code.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Gregory Maxwell via bitcoin-dev]

On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
 wrote:
> It is an eloquent change, but not really the topic we were discussing. It also
> makes you attack Mike (calling him out as having a strawman) without basis.
> For the second time in this thread.
> I would suggest arguing on the topic, not on the man.

Such a shame you appear to reserve that wisdom for those you disagree
with, biting your tongue when others emit all forms of ad hominem--
such as suggesting we've spent less volunteer time on Bitcoin and thus
our opinion has less merit (or that we haven't written certian kinds
of software (even when, ironically, we have!), and thus our opinion
doesn't have merit, and so on). I think everyone would benefit from
it, especially as that kind of correction is best received from
someone who agrees with you.

In this case, I think, however your correction is also misplaced at
least on this message; though I would otherwise welcome it.  I'm not
complaining about the man; but pointing out the behavior of stating an
opinion no one as held as theirs and attacking it is not a productive
way to hold a discussion. It's an argument or a behavior, not a
person, and beyond calling it bad I attempted to explaining (perhaps
poorly) why its bad.

What Sergio is saying is not the same; Mike argued some established
criteria existed where it didn't-- and I was pointing that out; and
talking about how the situation here is not very similar to the one
that Mike was trying to draw a parallel to. I enumerated a number of
specific reasons why this is the case. If the differences between
Sergio's comments and mine are still unclear after this clarification,
I'd be glad to talk it through with you off-list-- in spite of your
(welcome) compliments, communication is just fundamentally difficult,
and no amount eloquence changes that. If there is continued
misunderstanding, I do not doubt its my fault; but it's probably not a
good use of hundreds/thousands of people's time for you to help me
interactively improve my explanation on list. :)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Gregory Maxwell via bitcoin-dev]

On Mon, Oct 5, 2015 at 8:35 PM, Tom Zander via bitcoin-dev
 wrote:
> Fortunately I can say that while we certainly value your opinion, when peoples
> opinions are hard to read, as you indicated they can be, we should look at
> their actions. The group has followed the consensus rule quite rigorously,
> which I applaud.

What "consensus rule" do you refer to?

Indeed, I suggest you look to actions-- it's not hard to find changes
in Bitcoin Core that one contributor or another disliked. Did you try?
 (In this case, I don't even believe we have any regulator
contributors that disagree).
-- even for changes that effected system consensus, in fact. These
things were not hard-forks, however, as there never has been one (+/-
terminology disputes); and part of the point I was making was that the
standard for that is different, and that these differences begin with
technological fundamentals.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Steven Pine via bitcoin-dev]

It's pretty clear Mike has turned into  concern troll and bully. He insults
people, mischaracterizes others, quibbles over words and definitions and
has stated numerous times in other forums he has no interest in building
consensus changes he doesn't agree with himself.

He's lost his integrity and trust and why the core developers waste their
time with his antics is beyond me, let Mike fork Bitcoin, develop XT, and
ignore his input on core unless some XT feature is deemed good enough to
incorporate, that is how a thousand other open source projects deal with
trolls like Mike.
On Oct 5, 2015 3:41 PM, "Gregory Maxwell via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
>  wrote:
> > It is an eloquent change, but not really the topic we were discussing.
> It also
> > makes you attack Mike (calling him out as having a strawman) without
> basis.
> > For the second time in this thread.
> > I would suggest arguing on the topic, not on the man.
>
> Such a shame you appear to reserve that wisdom for those you disagree
> with, biting your tongue when others emit all forms of ad hominem--
> such as suggesting we've spent less volunteer time on Bitcoin and thus
> our opinion has less merit (or that we haven't written certian kinds
> of software (even when, ironically, we have!), and thus our opinion
> doesn't have merit, and so on). I think everyone would benefit from
> it, especially as that kind of correction is best received from
> someone who agrees with you.
>
> In this case, I think, however your correction is also misplaced at
> least on this message; though I would otherwise welcome it.  I'm not
> complaining about the man; but pointing out the behavior of stating an
> opinion no one as held as theirs and attacking it is not a productive
> way to hold a discussion. It's an argument or a behavior, not a
> person, and beyond calling it bad I attempted to explaining (perhaps
> poorly) why its bad.
>
> What Sergio is saying is not the same; Mike argued some established
> criteria existed where it didn't-- and I was pointing that out; and
> talking about how the situation here is not very similar to the one
> that Mike was trying to draw a parallel to. I enumerated a number of
> specific reasons why this is the case. If the differences between
> Sergio's comments and mine are still unclear after this clarification,
> I'd be glad to talk it through with you off-list-- in spite of your
> (welcome) compliments, communication is just fundamentally difficult,
> and no amount eloquence changes that. If there is continued
> misunderstanding, I do not doubt its my fault; but it's probably not a
> good use of hundreds/thousands of people's time for you to help me
> interactively improve my explanation on list. :)
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Milly Bitcoin via bitcoin-dev]

On 10/5/2015 4:05 PM, Steven Pine via bitcoin-dev wrote:

It's pretty clear Mike has turned into  concern troll and bully.


"troll" and, even worse, "concern troll" are terms generally used by 
teenagers on places like Reddit to complain about someone who doesn't 
agree with them. It is not rally a valid term to use in technical 
discussions. Several of the developers on here act as bullies by 
wielding power they have accumulated in a a system which they claim is 
decentralized.  It is not clear at all so your premise is faulty.



has stated numerous times in other forums he has no
interest in building consensus changes he doesn't agree with himself.


What exactly do you expect?  Bitcoin is not a charity, it is built on 
incentives.



He's lost his integrity and trust and why the core developers


Only a very small minority of the developers have "integrity and trust." 
Most are pretty irrational and untrustworthy if you look at their 
discussions outside of their technical expertise.  Bitcoin is not 
supposed to have a model where users are not forced to trust a small 
group such as the core developers.  It sounds to me like you suggest 
giving that up the idea of decentralization so you can gain control over 
the "official" software releases.


Russ

Russ






___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Tom Harding via bitcoin-dev]

On 10/5/2015 1:56 PM, Gregory Maxwell via bitcoin-dev wrote:
> In this case, I don't even believe we have any regulator contributors
> that disagree.

Since Gavin Andresen chose you to be one of 4 people who decides whose
contributions are accepted to the Core project, shouldn't you recuse
yourself from referencing "regular contributor" as some kind of bar to
an opinion being worthy?

You don't want to be accused of squelching a person's opinions by
nacking or sitting on commits, then turning around and branding those
opinions as worthless because they are not from a "regular contributor."
Do you?


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Milly Bitcoin via bitcoin-dev]

Regular contributor?

Please explain how for a fork in the protocol should you only listen to
regular Bitcoin Core contributors?


This is an artifact of a small centralized group of developers that 
wants to hold on to power.  This is why there is so much objection to 
documenting some sort of process since that would highlight issues such 
as this.


Russ


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Peter R via bitcoin-dev]

> On Oct 5, 2015, at 2:08 PM, Tom Zander via bitcoin-dev 
>  wrote:
> On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote:
>> (In this case, I don't even believe we have any regulator
>> contributors that disagree).
> 
> Regular contributor?
> 
> Please explain how for a fork in the protocol should you only listen to 
> regular Bitcoin Core contributors?

Furthermore, Bitcoin is significantly more than a "software project": it sits 
at a unique intersection of computer science, economics, physics, law and more. 
 While I agree that minor bug-fixes and code-maintenance-type issues should be 
dealt with quietly by developers, decisions regarding Bitcoin’s governance and 
its evolution should be shaped by an interdisciplinary group of stakeholders 
from across the community.  The hard- vs soft-fork debate is not just a code 
maintenance issue.  

Once again, let’s use the current gridlock in Core to rally the growth of new 
forkwise-compatible implementations of the protocol.  Gavin and Mike’s 
initiative with BIP101 and Bitcoin XT should be encouraged as one possible 
model for coming to consensus on hard-forking changes.  

Best regards,
Peter



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Gregory Maxwell via bitcoin-dev]

On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev
 wrote:
> Once again, let’s use the current gridlock

Allow me to state unequivocally-- since we've had problems with people
stating non-factuals as fact without getting adequately clear
correction--, there is no gridlock here and an effort to manufacturer
one for political reasons will not be successful.

Cheers,
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Peter R via bitcoin-dev]

> On Oct 5, 2015, at 2:30 PM, Gregory Maxwell  wrote:
> 
> On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev
>  wrote:
>> Once again, let’s use the current gridlock
> 
> Allow me to state unequivocally-- since we've had problems with people
> stating non-factuals as fact without getting adequately clear
> correction--, there is no gridlock here and an effort to manufacturer
> one for political reasons will not be successful.

I disagree.  There is gridlock in the Core Dev development process.  

Peter

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Milly Bitcoin via bitcoin-dev]

On 10/5/2015 5:30 PM, Gregory Maxwell via bitcoin-dev wrote:

On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev
 wrote:

Once again, let’s use the current gridlock





there is no gridlock here and an effort to manufacturer
one for political reasons will not be successful.


Worthless discussion over the definition of "gridlock."

Russ


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Tom Zander via bitcoin-dev]

On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote:
>  (In this case, I don't even believe we have any regulator
> contributors that disagree).

Regular contributor?

Please explain how for a fork in the protocol should you only listen to 
regular Bitcoin Core contributors?

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Gregory Maxwell via bitcoin-dev]

On Mon, Oct 5, 2015 at 9:08 PM, Tom Zander via bitcoin-dev
 wrote:
> On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote:
>>  (In this case, I don't even believe we have any regulator
>> contributors that disagree).
>
> Regular contributor?
>
> Please explain how for a fork in the protocol should you only listen to
> regular Bitcoin Core contributors?

I'm providing some perspective and scope-- referencing again your
comment about following actions-- what element of the many dozens of
responses suggests to you that _anyone_ is not being listened to?

While I'm sure its not intended; your selective editing ends up
butchering the meaning I pointed out that there have been
disputes, even ones involving regular contributors (and, implicitly,
that I'm not lying by omission in not mentioning that the dispute was
a joke or from someone well known to attack Bitcoin) or-- in other
words, evidence that the disagreement was not less meaningful than
what you're talking about here. That's all, sorry I was unclear again.

Did you see in my message that I invited you to take a look for
examples-- I think they're easily found and you would find it
informative. I really recommend spending some time looking.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Milly Bitcoin via bitcoin-dev]

Even someone trying to disrupt the process and nothing
else can help us learn by acting as an adversary that causes us to
extend our minds and understanding.


Interesting use of terms for a decentralized system.  Can these terms be 
defined?


"the process"

"us" (is there also a "them"?)


Russ





___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Santino Napolitano via bitcoin-dev]

While this isn't really the place to discuss it, I respectfully disagree. Mike 
appears to be making a point concerning Bitcoin protocol authorship and on the 
perceived value of soft-forks. It doesn't look like simple trolling to me. Mike 
and Gregory are both extremely intelligent and well-versed in Bitcoin and both 
should be listened to earnestly and equally while receiving our full 
professional respect.

At this stage it's becoming readily apparent to at least me (and without 
putting words into his mouth it would seem Gavin has experienced a similar 
realisation; please correct if I'm mistaken) that Bitcoin protocol authorship 
and individual implementation development need to be separated asap. I have no 
suggestions for the structure of this separation but as soon as it happens the 
better, IMO. It's likely messages like this would then no longer be seen on 
this list and Bitcoin Core developers could focus on their implementation's 
development free from distraction while other implementers and Core developers 
could discuss protocol issues in a more relevant forum in a more civilized and 
constructive manner.

05.10.2015, 23:05, "Steven Pine via bitcoin-dev" 
:
>  It's pretty clear Mike has turned into  concern troll and bully. He insults 
> people, mischaracterizes others, quibbles over words and definitions and has 
> stated numerous times in other forums he has no interest in building 
> consensus changes he doesn't agree with himself.
>
>  He's lost his integrity and trust and why the core developers waste their 
> time with his antics is beyond me, let Mike fork Bitcoin, develop XT, and 
> ignore his input on core unless some XT feature is deemed good enough to 
> incorporate, that is how a thousand other open source projects deal with 
> trolls like Mike.
>
>  On Oct 5, 2015 3:41 PM, "Gregory Maxwell via bitcoin-dev" 
>  wrote:
>>  On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
>>   wrote:
>>>  It is an eloquent change, but not really the topic we were discussing. It 
>>> also
>>>  makes you attack Mike (calling him out as having a strawman) without basis.
>>>  For the second time in this thread.
>>>  I would suggest arguing on the topic, not on the man.
>>
>>  Such a shame you appear to reserve that wisdom for those you disagree
>>  with, biting your tongue when others emit all forms of ad hominem--
>>  such as suggesting we've spent less volunteer time on Bitcoin and thus
>>  our opinion has less merit (or that we haven't written certian kinds
>>  of software (even when, ironically, we have!), and thus our opinion
>>  doesn't have merit, and so on). I think everyone would benefit from
>>  it, especially as that kind of correction is best received from
>>  someone who agrees with you.
>>
>>  In this case, I think, however your correction is also misplaced at
>>  least on this message; though I would otherwise welcome it.  I'm not
>>  complaining about the man; but pointing out the behavior of stating an
>>  opinion no one as held as theirs and attacking it is not a productive
>>  way to hold a discussion. It's an argument or a behavior, not a
>>  person, and beyond calling it bad I attempted to explaining (perhaps
>>  poorly) why its bad.
>>
>>  What Sergio is saying is not the same; Mike argued some established
>>  criteria existed where it didn't-- and I was pointing that out; and
>>  talking about how the situation here is not very similar to the one
>>  that Mike was trying to draw a parallel to. I enumerated a number of
>>  specific reasons why this is the case. If the differences between
>>  Sergio's comments and mine are still unclear after this clarification,
>>  I'd be glad to talk it through with you off-list-- in spite of your
>>  (welcome) compliments, communication is just fundamentally difficult,
>>  and no amount eloquence changes that. If there is continued
>>  misunderstanding, I do not doubt its my fault; but it's probably not a
>>  good use of hundreds/thousands of people's time for you to help me
>>  interactively improve my explanation on list. :)
>>  ___
>>  bitcoin-dev mailing list
>>  bitcoin-dev@lists.linuxfoundation.org
>>  https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>  ,
>
>  ___
>  bitcoin-dev mailing list
>  bitcoin-dev@lists.linuxfoundation.org
>  https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Tom Zander via bitcoin-dev]

On Monday 5. October 2015 19.41.30 Gregory Maxwell wrote:
> On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
> 
>  wrote:
> > It is an eloquent change, but not really the topic we were discussing. It
> > also makes you attack Mike (calling him out as having a strawman) without
> > basis. For the second time in this thread.
> > I would suggest arguing on the topic, not on the man.
> 
> Such a shame you appear to reserve that wisdom for those you disagree
> with, biting your tongue when others emit all forms of ad hominem--

You are special only in your eloquent use of the language. Consider yourself 
lucky :)

> In this case, I think, however your correction is also misplaced at
> least on this message; though I would otherwise welcome it.

I would not expect anything less.

> I'm not complaining about the man;
> but pointing out the behavior of stating an
> opinion no one has held as theirs and attacking it is not a productive
> way to hold a discussion. It's an argument or a behavior, not a
> person, and beyond calling it bad I attempted to explaining (perhaps
> poorly) why its bad.

Thanks for explaining your thinking.

Fortunately I can say that while we certainly value your opinion, when peoples 
opinions are hard to read, as you indicated they can be, we should look at 
their actions. The group has followed the consensus rule quite rigorously, 
which I applaud.
But next to that people like Black and Laan have given strong verbal 
indications confirming the practice you personally keep explaining is not 
real.


When I was a little boy of maybe 12 years, I remember reading a short story, 
that stuck with me.  It was about a man that had vowed to never lie. He was 
invited to a dinner party and asked to assist with another man's accusation of 
a crime he claimed to not have committed.
The end result was that the accused man was indeed guilty, but he minced his 
words so well that every sentence uttered was true. To the layman he seemed 
truthful and pleasant. Certainly innocent.
But to the man that never lied, his stories quickly fell apart as he himself 
had had years of practice with the same. And the guilty man was jailed.


I really enjoy reading your emails and github posts too, they have an 
eloquence and a brashness.

>  If there is continued
> misunderstanding, I do not doubt its my fault; but it's probably not a
> good use of hundreds/thousands of people's time for you to help me
> interactively improve my explanation on list.

Quite.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Eric Lombrozo via bitcoin-dev]

I agree with you, Sergio, up until the part about someone having won a battle. 
There's a difference between sincere technical objections and someone just 
being a dick. I think in this case this line has been crossed (and I don't 
think I'm alone here).

- Eric

On October 5, 2015 8:56:33 AM PDT, Sergio Demian Lerner via bitcoin-dev 
 wrote:
>Some of the people on this mailing list are blindly discussing the
>technicalities of a soft/hard fork without realizing that is not Mike's
>main intention. At least I perceive (and maybe others too) something
>else
>is happening.
>
>Let me try to clarify: the discussion has nothing to do with technical
>arguments. I generally like more hard forks than soft forks (but I
>won't
>explain why because this is not a technical thread), but for CLTV this
>is
>quite irrelevant (but I won't explain why..), and I want CLTV to be
>deployed asap.
>
>Mike's intention is to criticize the informal governance model of
>Bitcoin
>Core development and he has strategically pushed the discussion to a
>dead-end where the group either:
>
>1) ignores him, which is against the established criteria that all
>technical objections coming from anyone must be addressed until that
>person
>agrees, so that a change can be uncontroversial. If the group moves
>forward
>with the change, then the "uncontroversial" criteria is violated and
>then
>credibility is lost. So a new governance model would be required for
>which
>the change is within the established rules.
>
>2) respond to his technical objections one after the other, on never
>ending
>threads, bringing the project to a standstill.
>
>As I don't want 2) to happen, then 1) must happen, which is what Mike
>wants. I have nothing for or against Mike personally. I just think Mike
>Hearn has won this battle. But having a more formal decision making
>process
>may not be too bad for Bitcoin, maybe it can actually be good.
>
>Best regards
> from a non-developer to my dearest developer friends,
>  Sergio.
>
>
>
>
>___
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Btc Drak via bitcoin-dev]

On Mon, Oct 5, 2015 at 6:33 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I also agree with Mike that Core's requirement for unanimous consensus
> results in development grid lock and should be revisited.
>

There is no development gridlock. Look at the IRC logs for core-dev; look
at the pull requests; look a the merge history: Development is vibrant.
Developers are very active. You are manufacturing a crisis convenient to
your narrative, but it is far from the actual reality on the ground.

Please desist from this intellectual dishonesty and toxicity.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Milly Bitcoin via bitcoin-dev]

On 10/5/2015 6:56 PM, Btc Drak via bitcoin-dev wrote:

There is no development gridlock. Look at the IRC logs for core-dev;



Please desist from this intellectual dishonesty and toxicity.


A system where anyone can veto a change promotes gridlock.  Most people 
not on the devlpoment team see the block size debate as "gridlock." 
Much like "spam" "attack" and "decentralized" everyone has their own 
definition so arguing over it is generally pointless.


Russ


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Peter R via bitcoin-dev]

> On Oct 5, 2015, at 6:37 PM, Tom Harding via bitcoin-dev 
>  wrote:
> 
> On 10/5/2015 1:56 PM, Gregory Maxwell via bitcoin-dev wrote:
>> In this case, I don't even believe we have any regulator contributors
>> that disagree.
> 
> Since Gavin Andresen chose you to be one of 4 people who decides whose
> contributions are accepted to the Core project, shouldn't you recuse
> yourself from referencing "regular contributor" as some kind of bar to
> an opinion being worthy?
> 
> You don't want to be accused of squelching a person's opinions by
> nacking or sitting on commits, then turning around and branding those
> opinions as worthless because they are not from a "regular contributor."
> Do you?

Great point, Tom! 

In fact, you’ve just explained the dynamics that create “centralizing pressure” 
in regards to development:  If the weight of a person’s opinion is proportional 
to how many commits that person has made, and if the probability of getting a 
commit pulled is proportional to the weight of that person’s opinion, well…I’m 
pretty sure this results in a differential equation that has a solution that 
results in ever-increasing centralized control of the code base.  

I believe we should work to deprecate the idea that Core is somehow the “core 
of Bitcoin," in favour of multiple competing implementations. XT and btcd are 
two working examples of this idea.  Let’s make it easier for the community to 
determine the evolution of Bitcoin by making it easier for the community to 
express their vote based on the code we choose to run.  

Best regards,
Peter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Milly Bitcoin via bitcoin-dev]

I believe we should work to deprecate the idea that Core is somehow the “core of 
Bitcoin,"


I never did understand the terminology.  There were "core developers" 
which i understood to mean the primary developers of the Bitcoin 
software.  Then, suddenly, the software's name was changed from QT to 
"Core."  That seemed to me to be different meaning of the word "Core" 
yet it was often treated as the same.  So a developer who is not one of 
the anointed 5 is a "Core developer" because they work on Bitcoin Core. 
 The anointed 5 would be "Core Core Developers?"


In any case if I could get a list of "Core Developers" as referenced in 
the copyright notice that would also be good since that is a legal notice.


Russ



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Luke Dashjr via bitcoin-dev]

On Monday, October 05, 2015 3:56:33 PM Sergio Demian Lerner via bitcoin-dev 
wrote:
> Some of the people on this mailing list are blindly discussing the
> technicalities of a soft/hard fork without realizing that is not Mike's
> main intention. At least I perceive (and maybe others too) something else
> is happening.
> 
> Let me try to clarify: the discussion has nothing to do with technical
> arguments. I generally like more hard forks than soft forks (but I won't
> explain why because this is not a technical thread), but for CLTV this is
> quite irrelevant (but I won't explain why..), and I want CLTV to be
> deployed asap.
> 
> Mike's intention is to criticize the informal governance model of Bitcoin
> Core development and he has strategically pushed the discussion to a
> dead-end where the group either:
> 
> 1) ignores him, which is against the established criteria that all
> technical objections coming from anyone must be addressed until that person
> agrees, so that a change can be uncontroversial. If the group moves forward
> with the change, then the "uncontroversial" criteria is violated and then
> credibility is lost. So a new governance model would be required for which
> the change is within the established rules.
> 
> 2) respond to his technical objections one after the other, on never ending
> threads, bringing the project to a standstill.
> 
> As I don't want 2) to happen, then 1) must happen, which is what Mike
> wants. I have nothing for or against Mike personally. I just think Mike
> Hearn has won this battle. But having a more formal decision making process
> may not be too bad for Bitcoin, maybe it can actually be good.

This discussion is *necessarily* about soft/hard fork technicalities, as 
there is no governance in Bitcoin beyond the *nature* of the consensus 
protocol. The "established criteria" you mention is merely the nature of 
hardforks. It is completely inapplicable and has never been the necessary 
case for softforks, which can be enforced by merely a miner majority.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Paul Sztorc via bitcoin-dev]

On 10/5/2015 12:56 PM, Mike Hearn via bitcoin-dev wrote:
>
> As everyone in the Bitcoin community has been clearly told that
> controversial changes to the consensus rules must not happen, it's
> clear that CLTV cannot happen in its current form.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Mike Hearn via bitcoin-dev]

Hey Sergio,

To clarify: my *single* objection is that CLTV should be a hard fork. I
haven't been raising never-ending technical objections, there's only one.

I *have* been answering all the various reasons being brought up why I'm
wrong and soft forks are awesome  and there do seem to be a limitless
number of such emails  but on my side it's still just a single
objection. If CLTV is a hard fork then I won't be objecting anymore, right?

CLTV deployment is clearly controversial. Many developers other than me
have noted that hard forks are cleaner, and have other desirable
properties. I'm not the only one who sees a big question mark over soft
forks.

As everyone in the Bitcoin community has been clearly told that
controversial changes to the consensus rules must not happen, it's clear
that CLTV cannot happen in its current form.

Now I'll be frank - you are quite correct that I fully expect the Core
maintainers to ignore this controversy and do CLTV as a soft fork anyway.
I'm a cynic. I don't think "everyone must agree" is workable and have said
so from the start. Faced with a choice of going back on their public
statements or having to make changes to something they clearly want, I
expect them to redefine what "real consensus" means. I hope I'm wrong, but
if I'm not . well, at least everyone will see what Gavin and I have
been talking about for so many months.

But I'd rather the opcode is tweaked. There's real financial risks to a
soft fork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev