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

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

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1854 bytes --]

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

[NxtChg]

>I just think Mike Hearn has won this battle.

Unless the Core camp isn't concerned with credibility because they see XT as a disruptive attack.

So it's very easy to justify banning a single individual in the name of "restoring peace and order". We've already seen such suggestion.

Peter R was banned on /r/bitcoin, Mike was banned on IRC.

The new governance model seems to be "consensus by exclusion".

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

[Luke Dashjr]

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

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1745 bytes --]

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

[Paul Sztorc]

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.

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

[Peter R]

[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]

Dear Bitcoin Development Community:

I would like to share my opinion that Mike is correct regarding the soft fork versus hard fork debate. I agree that CLTV should be done with a hard fork for the reasons that Mike has discussed several times in the past (mainly that a hard forks requires active consensus while a soft fork requires only indifference).  I believe this is a controversial change and—if Core Dev believes that controversial changes to the consensus rules must not happen—then my interpretation is that CLTV should not happen in its current form.  

I also agree with Mike that Core's requirement for unanimous consensus results in development grid lock and should be revisited.  In my opinion, the idea that unanimity is required should be replaced with the idea that the longest chain composed of valid transactions is the correct chain.  It shouldn’t matter really how the chain becomes the longest—only that it does.  

I believe that a good way to return power to the bitcoin community is to foster mutiple forkwise-compatible implementations of the protocol.  Each implementation could have its own governance model and design objectives and use techniques like BIP101’s 750/1000 signalling mechanism to activate changes that may be desirable to the community.  If a super majority does not support the change, then it won’t be activated.  I created an animated GIF that visualizes one possibility for how multiple protocol implementations might emerge over time:

https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_bitcoin_core_visualizing_the/ <https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_bitcoin_core_visualizing_the/>

Decentralizing development and supporting multiple forkwise-compatible implementations of the protocol is a worthwhile goal that will simultaneously make Bitcoin more robust and more responsive to the will of the market.

Nodes would express their acceptance of a block by mining on top of it.  Consensus would be determined by the code we choose to run. 

Best regards,
Peter 


> On Oct 5, 2015, at 10:01 AM, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 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


[-- Attachment #2: Type: text/html, Size: 3807 bytes --]

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

[NxtChg]

>Each implementation could have its own governance model 
>and design objectives and use techniques like BIP101’s 750/1000 
>signalling mechanism to activate changes that may be desirable to 
>the community.

I was shushed here 3 months ago for the same suggestion :)

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009294.html

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

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1140 bytes --]

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

[Milly Bitcoin]

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

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

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1156 bytes --]

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

[Venzen Khaosan]

-----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-----

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

[Venzen Khaosan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That's for Mike Hearn. Sooner the better. Hong Kong, December?
Venzen Khaosan


On 10/07/2015 01:23 AM, Venzen Khaosan via bitcoin-dev wrote:
> 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
> 
> _______________________________________________ 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)

iQEcBAEBAgAGBQJWFBLWAAoJEGwAhlQc8H1mRM8H/0p2sz0gtu62bB+NrllRgU20
C4imzMr904X7JicqDsGhtySGdyk8DuHBSK4k1A3pOgPb+DoNQhcOUfZ2ZTNgR2tT
yjJHrJP2X+g8YixyQiQNBf65bogTgeBGEizh/H33RSGzdHwoIfeVS5Qja/AMUnk1
4XO8d+t5OdtYdKANmR/uUZikrnOXd6KIt9rmJhYUjqmLWXbHzQkhES0mFvJ1BdVZ
ZHNjnWzoE74NAEmPqhhhtU/GCFKQhBq7HHAnqkMoeWk0mgJoGCc+b/4/PwchmUJq
CmVO2TJFrnHb4tYAFgw14tdbSe5ERYT0pHW4qM3gJlYL1ik03k0iQDZZ0eStaXM=
=bwvw
-----END PGP SIGNATURE-----

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

[naama.kates]

Hey all, nice to meet you... I'm new to the community and thus, after taking that first step of signing up, have been reading/scanning these threads over the last few days without contributing my own two ¢-- not, um, 'trolling', just, you know, educating myself and getting familiar with the group ethos and etiquette.  

It wasn't until I'd read ~10 posts that I  understood the initial purpose of the thread!  As few others have mentioned, I'm a bit surprised, at all the back and forth à la hip-hop 'battling' ;-) It certainly obfuscates-- while entertaining-- to the point where a newbie like myself might drop out... Perhaps this is intentional-- to maintain exclusivity and weed out the uninitiated.  I dunno.  But if not, I'm just noting, as something of an outsider, that it took a while.

But I'd like to contribute.  With what little knowledge I possess, I'm inclined to favor hardfork... Is there a more suitable place to address this?  Perhaps to work on code?  For this specific project, that is...  Anyone point me to a map somewhere?  LOL.

Thanks to all for reading, and much admiration to you all and the work you've done, my latter comments notwithstanding!  

Cheers,
N



> On Oct 6, 2015, at 11:28 AM, Venzen Khaosan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> That's for Mike Hearn. Sooner the better. Hong Kong, December?
> Venzen Khaosan
> 
> 
>> On 10/07/2015 01:23 AM, Venzen Khaosan via bitcoin-dev wrote:
>> 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
>> 
>> _______________________________________________ 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)
> 
> iQEcBAEBAgAGBQJWFBLWAAoJEGwAhlQc8H1mRM8H/0p2sz0gtu62bB+NrllRgU20
> C4imzMr904X7JicqDsGhtySGdyk8DuHBSK4k1A3pOgPb+DoNQhcOUfZ2ZTNgR2tT
> yjJHrJP2X+g8YixyQiQNBf65bogTgeBGEizh/H33RSGzdHwoIfeVS5Qja/AMUnk1
> 4XO8d+t5OdtYdKANmR/uUZikrnOXd6KIt9rmJhYUjqmLWXbHzQkhES0mFvJ1BdVZ
> ZHNjnWzoE74NAEmPqhhhtU/GCFKQhBq7HHAnqkMoeWk0mgJoGCc+b/4/PwchmUJq
> CmVO2TJFrnHb4tYAFgw14tdbSe5ERYT0pHW4qM3gJlYL1ik03k0iQDZZ0eStaXM=
> =bwvw
> -----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

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]

You are absolutely right and this is something I have often unsuccessfully
tried to explain as "disruption strategies". The problem is that most
people in the technical community assume good faith at all times, which
plays right into the frame required for disruption.

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.

Mike has not presented anything convincing and history actually shows that
ISM works, and we have learned how to make it even more streamlined. We
know ISM has consensus because miners have accepted ISM for past softfork
rollouts.

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

On Mon, Oct 5, 2015 at 4:56 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3543 bytes --]

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

[Tom Zander]

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.

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

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 1219 bytes --]

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

[Gregory Maxwell]

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

I think rather successfully. 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. Since this motivation is uncorrelated
with any property of soft-forks or CLTV we should not expect his
position to change.

> 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.

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

[Tom Zander]

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/

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

[NotMike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3908 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4884 bytes --]

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

[s7r]

-----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-----

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

[Tom Zander]

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.

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

[Gregory Maxwell]

On Mon, Oct 5, 2015 at 3:56 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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. 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.

I don't agree-- I think you've made the mistake of just accepting the
particular framing that Mike has provide; one that (no shock) only
supports his conclusions.

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
(and doubly so, 100% including people who are expressly trying to
disrupt the project by posing opposition which, as you note, is
largely unrelated to the merits of the proposals). Mike has lead you
to believe people have claimed this, but no one has-- it's a view
which is simple, clear, and completely not reflecting reality. Don't
fall for strawman arguments.

In this situation it is also a particularly strong apples/oranges comparison:

Soft forks can happen at any time at the whim of miners-- no
technology which we are aware of (beyond the technology of
centralization) is able to prevent them-- they are not necessarily
even detectable; on this basis they are categorically different than
hard forks.

Moreover, the space of soft-forks the contributors to Bitcoin Core
would ever consider is a tiny space of all possible soft-forks, and
are ones which cannot be rationally understood to meaningfully
undermine the properties provided by the rules enforced within the
software; again making them different from some other proposals and of
a lesser concern.

Finally, the behavior of the technology arising from the inherent
compatibility, radically lowers (in most of our experience and
opinion) the cost of deployment; again-- making them different. They
prevent a industry wide flag day, and tight release synchronization
which is harmful to decentralization promoting software diversity.

As I think I commented in one of my messages-- I respond to the
technical arguments not because I believe they are earnestly
motivated, but because they provide an avenue for learning for myself
and others. 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. The process for CLTV has been
ongoing for something like a year and a half and has little risk of
being substantially disrupted at this point.

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

[Tom Zander]

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.

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

[Gregory Maxwell]

On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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. :)

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

[Steven Pine]

[-- Attachment #1: Type: text/plain, Size: 3044 bytes --]

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
> <bitcoin-dev@lists.linuxfoundation.org> 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
>

[-- Attachment #2: Type: text/html, Size: 3739 bytes --]

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

[Milly Bitcoin]

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

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

[cipher anthem]

> 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...

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

[Eric Lombrozo]

I prefer the term "clown".

Can we please move on?

------ Original Message ------
From: "cipher anthem via bitcoin-dev" 
<bitcoin-dev@lists.linuxfoundation.org>
To: milly@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

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

[Marcel Jamin]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

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: milly@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
>

[-- Attachment #2: Type: text/html, Size: 3205 bytes --]

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

[NotMike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3086 bytes --]

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: milly@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
>
>

[-- Attachment #2: Type: text/html, Size: 5285 bytes --]

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

[naama.kates]

[-- Attachment #1: Type: text/plain, Size: 3687 bytes --]

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 <bitcoin-dev@lists.linuxfoundation.org> 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 <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: milly@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

[-- Attachment #2: Type: text/html, Size: 6310 bytes --]

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

[Santino Napolitano]

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" <bitcoin-dev@lists.linuxfoundation.org>:
>  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
>>  <bitcoin-dev@lists.linuxfoundation.org> 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

[Tom Zander]

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
> 
> <bitcoin-dev@lists.linuxfoundation.org> 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.

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

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

I prefer the hard fork because the complexity introduced by soft forks
scares me.

At
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011309.html
Gregory wrote: "Security requires a bit of vigilance, inherently." and
[A non-upgraded miner will end up] "*> producing invalid blocks forever
until** the owner shuts it down and upgrades. * This is the outcome
guaranteed for absentee miners with a hard fork, but it is not guaranteed
for a soft fork."

It seems that the main benefit of a soft-fork is that it allows
participants on the network to keep participating even if they aren't
vigilant enough to notice and upgrade when that is safest.  Are there other
reasons that might entice me if that one by itself is not enough?

Gregory provided two more: [Using soft-forks] "radically lowers (in most of
our experience and
opinion) the cost of deployment; again-- making them different. They
prevent a industry wide flag day, and tight release synchronization  which
is harmful to decentralization promoting software diversity."

I understand these benefits.  The cost in complexity is still too high for
me, and I think most of the pain in "cost of deployment", "industry-wide
flag days," and "tight release synchronization," as well as the
centralizing effect of those things can be minimized with waiting periods.
The promotion of software diversity offered by soft-forks is pretty cool,
but that gets close to messing with fungibility.
<http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011309.html>

[-- Attachment #2: Type: text/html, Size: 2029 bytes --]

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

[Gregory Maxwell]

On Mon, Oct 5, 2015 at 8:35 PM, Tom Zander via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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.

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

[Tom Zander]

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?

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

[Milly Bitcoin]

> 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

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

[Gregory Maxwell]

On Mon, Oct 5, 2015 at 9:08 PM, Tom Zander via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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.

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

[Tom Zander]

On Monday 5. October 2015 21.26.01 Gregory Maxwell wrote:
> On Mon, Oct 5, 2015 at 9:08 PM, Tom Zander via bitcoin-dev
> 
> <bitcoin-dev@lists.linuxfoundation.org> 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?

Have you ever been at a meeting where you didn't feel like you were being 
listened to?
You get comments like;
 «I respond to the technical arguments not because I believe they are
 earnestly motivated, but because they provide an avenue for learning for
 myself and others.»

 «"there is no gridlock here» After several respected members stated there is
 disagreement.

 «That Mike himself continues to misexplain things is not surprising since he
 has all but outright said that »[snip]  Which is putting words in the mouth 
of someone you disagree with.


But what really gives a lot of people here the suggestion that members of the 
community that are against the softfork are not being listened to is the 
simple undeniable fact that an alternative or a remedy is not even considered.
There is no code. There is no question posted by the authors which flags to 
use.

Actions speak much louder than words. Read the topic of this thread!
The actions show a disregard for the many objections.  Consensus is not build 
by repeating again and again the arguments that you belief will convince your 
debate-opponent. It is about reaching a middle ground. If either side of the 
debate refuses to budge from their position, you have gridlock.

What came of the request made to PeterT to document the risks and required 
changes in wallets should this soft fork continue?

Why is it soo bad to use a hardfork (with proper voting) instead of a softfork 
that we are in a place that the Bitcoin Core team is willing to throw out a 
lot of goodwill and show their true colours in hundreds of mails that leave 
the opposing side of this debate feeling ignored and left out?


I don't feel specifically unique or special. Nobody needs to reply to this 
email. I don't claim peoples time.

All I'm doing is spelling out what has been living in the back of my head, and 
with me a great deal of others, about how this is playing out.

If you choose to ignore this and you force a softfork, I belief you may be 
surprised at how many active players in the Bitcoin marketplace may see that 
the "Bitcoin Core" team is not an ally any longer.
It is good to remember that the graveyards are filled with people that 
believed to be unreplaceable.
Bitcoin will go on.

Have a nice day!

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

[Peter R]

> On Oct 5, 2015, at 2:08 PM, Tom Zander via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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

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

[Gregory Maxwell]

On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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,

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

[Milly Bitcoin]

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
> <bitcoin-dev@lists.linuxfoundation.org> 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

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

[Peter R]

> On Oct 5, 2015, at 2:30 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> 
> On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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

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

[Tom Harding]

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?

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

[Peter R]

> 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.  

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

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

[Milly Bitcoin]

> 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

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

[Luke Dashjr]

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

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

[Milly Bitcoin]

> 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

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

[Milly Bitcoin]

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
>

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

[Luke Dashjr]

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

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

[Milly Bitcoin]

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

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

[phm]

-----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-----

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

[NotMike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2909 bytes --]

>
>
> 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
>

[-- Attachment #2: Type: text/html, Size: 4386 bytes --]

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

[Peter R]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]


> 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




[-- Attachment #2: Type: text/html, Size: 1449 bytes --]

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

[Milly Bitcoin]

>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

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

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

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 <bitcoin-dev@lists.linuxfoundation.org> 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.

[-- Attachment #2: Type: text/html, Size: 2914 bytes --]

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

[Venzen Khaosan]

-----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 bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWFATEAAoJEGwAhlQc8H1mlBgH/288r/v0J0FFj2HukN3l4YLj
5+2d4WRJk/r4jfTUQvBiinmEph0cNuY8gtCYssCsipiOe5Ep0k8oQ3Jd/KWx0fIn
v7eCRzHBLkPTDHd7gnrGSnIsHy1xpO7MGM79ROMOMjoQJUZqborxSxRfJVt5Mdqo
bxMcDL0n+tJbKa4dbmjLtARH6EbTIWvE7kKh8c5ZHbLkXTOPSt6gCL9GKSVM+i1u
mlF1m1TEBLSq4jQ2WJk/8aHHbN5IQr2KzpAEneP3tKqSvl/33b2oaW42LVKbxk95
kDnbtKrBChrHGbLeQ/SRb9NADmvIcnDim4NviphsEarPdl/9OyTW36x2u1j0Slk=
=zgDh
-----END PGP SIGNATURE-----

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

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

Hi Venzen,
 I don't know you and I never said "for fuck's sake" to anyone on IRC. I
don't use IRC, and almost never say 4 letter words.

I wonder how technically savvy people trust IRC ids. Could you send me the
link where such an impostor said something to you in my name?

Your e-mail reads like a TV plot. To me, agent Hearn is just Mike. Agent
Lerner is just an Argentinian dude with some spare time to write here. But
maybe you know something I don't....

Best regards!
 Sergio.

[-- Attachment #2: Type: text/html, Size: 628 bytes --]