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
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
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
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 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 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
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 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
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
Restarting the mining with a new algorithm as a reaction and defence against
centralised hoarding of mining ASICs (as we are seeing now), would be
acceptable. It would not necessarily be contentions *to the economy*, as such
hoarding-miners do not participate in the economy in any meaningful way (
Given the current reddit hubbub, a bit of a cooling off period is IMO
advisable before taking any further action.
2. If so, does the community feel that Mike Hearn has crossed it? (I
personally feel he has. Multiple times.)
I don't believe any posting by Mr. Hearn warrants any actions
On 9/30/2015 3:16 AM, Eric Lombrozo via bitcoin-dev wrote:
I've also got a competition where the object is to build a spaceship
using only a watermelon, two donkeys, some duct tape, and a fire hydrant.
There are many people interested in starting new services and who are
interested in hiring d
Since 2011 and bitcoin-development, the list was always intended to
focus on the highly technical bits of the core software, and avoid
wandering into never-ending philosophical discussions. Example:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2011-June/thread.html
What happened years
On 9/29/2015 7:02 PM, Jonathan Toomim (Toomim Bros) wrote:
Making statements about a developer's personal character is also off-topic for
this list.
If that were true then probably 20-30% of the posting here would be
off-topic. lol.
Russ
___
bi
On 9/29/2015 5:07 PM, Jeff Garzik via bitcoin-dev wrote:
This is off-topic for this list.
You like to go around pretending you are in charge and telling people
what to do. You have no such authority and your time is probably better
spent reviewing your company's Bitcoin handling and security
This is quite off topic,
I see a number of people claiming they know what should be posted to
this list but those claims appear to be without merit.
The list states the subject is "Development discussion list for Bitcoin
protocol and its implementation." That is a pretty broad description
On 9/21/2015 1:04 AM, Corey Haddad via bitcoin-dev wrote:
> If it turns out that the blocksize divide is hinging on differing
> developer views on the nature of the threat posed by governments,
> perhaps it would be better to defer to people who specialize in that
> area. ...
...
> The main idea
Some of us have also been actively working towards developing
a more modular, layered architecture and better implementations that
will afford greater decentralization in software development with less
need for critical code reviews, less pushback from downstream developers
who must continuously r
Larger user base won't necessarily protect against governments if we
still have chokepoints they can go after.
Bitcoin will always have chokepoints governments can go after. Hackers
already targeted routers to divert mining traffic awhile back. Bitcoin
traffic is easily seen and blocked by
therefore ascribing godlike and limitless powers to a government is
again the view of either a shill or someone untutored in history.
Since nobody ever ascribed "godlike and limitless powers to a
government" on this list your comment has no bearing on anything
discussed here. I am sure the wh
Threat models can be developed for things like threats from governments.
The idea in developing a model is to put in the context of other
possible threats. For example, someone with a few million to burn can
easily crash the exchange rate or buy a couple core developers much
easier and cheape
conflicts often justified
by fake evidence, wholesale disregard of law and basic human covenants
such as do not torture, ubiquitous and secret global surveillance.
Anyone who doesn't consider governments the proper threat model is
either a shill or an idiot.
On Sep 20, 2015 12:34 PM, "Mill
Until this is settled, Bitcoin has no clear direction and developers cannot
make effective decisions:
How exactly do things set "settled" in this environment?
People looking at Bitcoin think a small group of developers and miners
"control" these decisions. Not sure if "control" is the right
Government is the group of people that does things ...
Governments (note the plural) are a collection of entities made up of
people that do all sorts of things both good and bad. Attaching your
political agenda to Bitcoin with the hopes people will agree with it
after using Bitcoin is not a
IMO trying to "set up a system" in that kind of environment is silly,
The first step is to define the system that is currently in place.
There is a system in place but it is just close to the vest and
sometimes not discussed in public. This works when Bitcoin has a small
number of stakeholde
We don't want to play at being
lawyer, but our review does point towards this being something worth
coming back to.
In terms of citation, we did reference a case called /Feist/.
I don't see how you can possibly conclude this effort is worth any
additional time. The legal reference is: Feist
I would just like to labour the point that users pay to use the network,
but they have no defined rights, anywhere.
That is an interesting point. That is a feature of Bitcoin, not a bug.
If the user did have rights to sue someone then the system would not
be decentralized. User rights = som
The general points and questions you have raised are covered in the
draft BIP:
No, the BIP makes some weird statements that don't really make sense.
Number one rule here: To put a license on something you have to own it
in the first place.
Let's say for the sake of argument that Miners own
We considered whether data existing before a licence change would be
covered, but we hadn't factored the potential need for gaining
permissions for a change to be considered effective.
We have proposed that miners be the main beneficiaries of licensing and
there is a consideration on whether they
We believe the network requires a block chain licence to supplement the
existing MIT Licence which we believe only covers the core reference
client software.
I suggest talking to a lawyer first. To have a license you need an
entity that holds the license. What entity actually holds the MIT
l
I have been struggling to get port 8333 open all year,
After hours of phone calls and messaging AT&T finally told me the truth
of what was going on,
I went through this Comcast involving another port. When they blocked
the port I asked them the reason (I referenced their privacy policy that
> Bitcoin is a decentralized currency which allows any person the
ability to transact in a way that does not require specific trust in
any particular party.
Bitcoin is only a partial solution to the Byzantine general problem.
Users do need to trust that things such as mining and development
So where is the solution? What to do?
AML-KYC is mostly something that sits on top of the Bitcoin protocol.
Take Coinase, inc. as an example. They check bank accounts before they
open your account and they link your Bitcoin address to your account in
their database. Then they ask for an
can discuss changes in a similar
context.
Russ
On 8/20/2015 8:58 PM, Peter Todd wrote:
On Thu, Aug 20, 2015 at 08:45:53PM -0400, Milly Bitcoin via bitcoin-dev wrote:
You know, I've noticed you've spent a tremendous amount of time and
energy on this list promoting these kinds
The idea is to come up with some sort of standardized metric so as the
tools and issues come up you are comparing similar things.
The first thing you have to do is link "centralization pressure" and
(pressure to merge with a big miner) to some sort of overall
decentralization metric. For inst
Security is provided via POW.
POW is only one aspect of security and that algorithm was created by
developers and adopted by miners. Developers provide security by
creating an algorithm and miners provide security by adopting it. If
the developers and miners decided to do something insecure
The same with -XT, nobody should be able to affect the entire bitcoin
ecosystem regardless how many miners or bitcoin companies you can lobby.
If this is possible, then Bitcoin is not as secure as we thought.
Bitcoin is only as secure as the developers, users, and miners allow it
to be. If you
For the 73th time or so this month on this list:
The maximum block size consensus rule limits mining centralization
(which is currently pretty bad).
Instead of posting all these messages with bald claims why don't you
work on a decentralization metric which you can point to? (instead of
tryi
4.) Investors hate uncertainty, and the blocksize issue is adding a lot
of uncertainty right now, ...
That is true VC investors and people starting companies. People who
invest directly in Bitcoin love all this stuff.
A few weeks back a bunch of stories quoting nonsense spouted by Bitcoin
c
Baseless accusations also have no place on this mailing list. They are
unprofessional, and poisonous to the consensus-building process we all
seek to engage in.
I didn't see any baseless accusations in the message. I saw a
discussion of possible conflicts of interest. Your reply seems to
ind
You may be misremembering; nobody has ever disagreed that you can fork a
source code repository. Perhaps you are thinking instead about the
concerns regarding "asymmetric" rule incompatibilities?
I am not "misremembering" anything. Some people have claimed for years
that Bitcoin development is
So if you want a user vote, that's an issue that'd have to be tackled:
the people who admin the main communication channels Bitcoin users have
vowed to censor any program that doesn't slavishly follow 51%+ hash
power. That attempt to control the conversation is certainly not
libertarian or democra
I have never heard of "develop-by-concerns"? Is that similar to
fire fighting management?
To that I have this reply;
http://www.aleanjourney.com/2009/07/stop-fighting-fires.html
A set of goals is needed and then you develop road maps. At that point
you can propose specific changes that fit wit
I think the point "you don't need to trust anyone to use Bitcoin" remains.
I don't think that is a true statement. Users need to trust the mining
system is working as intended. Users also need to trust the developers
to a certain extent. It is about levels of trust and how much you need
to
Trust takes many different forms and is not a binary function.
Many Bitcoiners have a rather unusual notion of trust. While many state
the established financial systems cannot be trusted they imply that many
within the Bitcoin world need to be trusted. There are some very
irresponsible and
For those wishing to do actual research, esp. people such as profs mentoring
students, ...
But keep in mind that you're wading into a highly politically charged research
field
with billions hanging on the blocksize limit; understand that people aren't
happy when
flawed papers end up on reddi
, Raystonn wrote:
Russ, do you have time to get started on your list? It would add value.
On 30 Jul 2015 5:15 pm, Milly Bitcoin via bitcoin-dev
wrote:
These are the types of things I have been discussing in relation to a
process:
-A list of metrics
-A Risk analysis of the baseline
These are the types of things I have been discussing in relation to a
process:
-A list of metrics
-A Risk analysis of the baseline system. Bitcoin as it is now.
-Mitigation strategies for each risk.
-A set of goals.
-A Road map for each goal that lists the changes or possible avenues to
achiev
GUYS, WE’VE KNOWN ABOUT THESE PROBLEMS AND HAVE TALKED ABOUT THEM FOR
YEARS ALREADY…AND IT SEEMS PRACTICALLY NOTHING HAS HAPPENED…
What is the incentive for someone with high level technical skills to
spend all their time developing and testing code? Especially since the
code is generally the
The ugly thing is I think everyone in this process recognises the
meta-consensus nature of the debate already. Notice how Gavin Andresen's
initial blocksize posts were in the form of a non-technical blog, making
non-technical arguments to the public - not the Core dev team - in ways
not conducive
On 7/23/2015 10:57 PM, Dave Scotese via bitcoin-dev wrote:
I used Google to establish that there is not already a post from 2015
that mentions "roadmap" in the subject line. Such would be a good
skeleton for anyone new to the list (like me).
Just a point about terminology:
Roadmap - A plan of
> Mike has sincerely said that he would like "Bitcoin Core to have a
> benevolent dictator like other free software projects", and I wanted
> to make clear that I wasn't putting words in his mouth
He is just pointing out reality. Decentralization is really just a
collection of centralized proces
On 7/23/2015 10:30 AM, Jorge Timón via bitcoin-dev wrote:
[4] http://lmgtfy.com/?q=mike+hearn+dictator&l=1
___
You spend too much time on reddit. All this drama queen stuff is
getting ridiculous.
Russ
__
default in case of controversy is no change.
I think the result of this would probably be that no controversial
changes ever get implemented via this process so others will hard fork
the code and eventually make this process irrelevant. Since you need
close to 100% agreement the irrelevance
My "relationships" are nothing more than people
being willing to talk to me, ask me for advice, and warn me about
possible threats. They're not legal contracts.
Your actions make it appear as if you attack companies with the hope of
landing consulting fees. I assume if companies hire you as a
(note how Chainalysis's actions were
described(1) as a sybil attack by multiple Bitcoin devs, including
Gregory Maxwell, Wladimir van der Laan, and myself)
As far as I know none of those people are security experts nor do they
engage in systematic risk and threat analysis. Simply because they
Below are 2 examples why a systematic risk analysis needs to be used.
The current situation is that you have developers making hyperbolic,
demonizing statements that users are "spammers" and engaged in Sybil
"attacks." Characterizing these activities as spam and Sybil attacks is
not a systemat
57 matches
Mail list logo
