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
-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.
9:20 GMT+02:00 Eric Lombrozo via bitcoin-dev
>> :
>>> I prefer the term "clown".
>>>
>>> Can we please move on?
>>>
>>> ------ Original Message ------
>>> From: "cipher anthem via bitcoin-dev"
>>>
>>>
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 grou
-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
> rem
-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 an
-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.
No
v@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" <
>
anthem via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>
> To: mi...@bitcoins.info
> Cc: bitcoin-dev@lists.linuxfoundation.org
> Sent: 10/6/2015 12:17:14 AM
> Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork
> technical debate
>
> Sent:
t the soft/hard fork
technical debate
Sent: Monday, October 05, 2015 at 8:21 PM
From: "Milly Bitcoin via bitcoin-dev"
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] This thread is not about the soft/hard
fork technical debate
On 10/5/2015 4:05 PM, Steven Pine
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
>
> 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).
>
> Sent: Monday, October 05, 2015 at 8:21 PM
> From: "Milly Bitcoin via bitcoin-dev"
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork
> technical debate
> On 10/5/2015 4:05 PM, Steven Pine via bitco
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
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,
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 copy
> 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 bloc
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 owne
>
>
> 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:
> >> I
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 cop
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
> On Oct 5, 2015, at 6:37 PM, Tom Harding via bitcoin-dev
> wrote:
>
> On 10/5/2015 1:56 PM, Gregory Maxwell via bitcoin-dev wrote:
>> In this case, I don't even believe we have any regulator contributors
>> that disagree.
>
> Since Gavin Andresen chose you to be one of 4 people who decides wh
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
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,
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
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
> On Oct 5, 2015, at 2:30 PM, Gregory Maxwell wrote:
>
> On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev
> wrote:
>> Once again, let’s use the current gridlock
>
> Allow me to state unequivocally-- since we've had problems with people
> stating non-factuals as fact without getting adeq
On 10/5/2015 5:30 PM, Gregory Maxwell via bitcoin-dev wrote:
On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev
wrote:
Once again, let’s use the current gridlock
there is no gridlock here and an effort to manufacturer
one for political reasons will not be successful.
Worthless discu
On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev
wrote:
> Once again, let’s use the current gridlock
Allow me to state unequivocally-- since we've had problems with people
stating non-factuals as fact without getting adequately clear
correction--, there is no gridlock here and an effort to
> On Oct 5, 2015, at 2:08 PM, Tom Zander via bitcoin-dev
> wrote:
> On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote:
>> (In this case, I don't even believe we have any regulator
>> contributors that disagree).
>
> Regular contributor?
>
> Please explain how for a fork in the protocol s
On Mon, Oct 5, 2015 at 9:08 PM, Tom Zander via bitcoin-dev
wrote:
> On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote:
>> (In this case, I don't even believe we have any regulator
>> contributors that disagree).
>
> Regular contributor?
>
> Please explain how for a fork in the protocol sho
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 pr
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?
_
On Mon, Oct 5, 2015 at 8:35 PM, Tom Zander via bitcoin-dev
wrote:
> Fortunately I can say that while we certainly value your opinion, when peoples
> opinions are hard to read, as you indicated they can be, we should look at
> their actions. The group has followed the consensus rule quite rigorousl
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 blo
On Monday 5. October 2015 19.41.30 Gregory Maxwell wrote:
> On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
>
> wrote:
> > It is an eloquent change, but not really the topic we were discussing. It
> > also makes you attack Mike (calling him out as having a strawman) without
> > basis.
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
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
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
On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
wrote:
> It is an eloquent change, but not really the topic we were discussing. It also
> makes you attack Mike (calling him out as having a strawman) without basis.
> For the second time in this thread.
> I would suggest arguing on the to
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
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
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 practic
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
happ
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 tha
On Mon, Oct 5, 2015 at 3:56 PM, Sergio Demian Lerner via bitcoin-dev
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 forwa
On Mon, Oct 5, 2015 at 5:26 PM, Tom Zander via bitcoin-dev
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
>> argum
>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.o
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
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
-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 f
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 activ
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
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 chal
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.
___
bit
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 li
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 e
>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 b
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
58 matches
Mail list logo
