[bitcoin-dev] Bitcoin XT 0.11A

[Mike Hearn via bitcoin-dev]

Hello,

As promised, we have released Bitcoin XT 0.11A which includes the bigger
blocks patch set. You can get it from

https://bitcoinxt.software/

I feel sad that it's come to this, but there is no other way. The Bitcoin
Core project has drifted so far from the principles myself and many others
feel are important, that a fork is the only way to fix things.

Forking is a natural thing in the open source community, Bitcoin is not the
first and won't be the last project to go through this. Often in forks,
people say there was insufficient communication. So to ensure everything is
crystal clear I've written a blog post and a kind of "manifesto" to
describe why this is happening and how XT plans to be different from Core
(assuming adoption, of course).

The article is here:

https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1

It makes no attempt to be neutral: this explains things from our point of
view.

The manifesto is on the website.

I say to all developers on this list: if you also feel that Core is no
longer serving the interests of Bitcoin users, come join us. We don't bite.

[s7r via bitcoin-dev]

Post by Mike Hearn via bitcoin-dev
I say to all developers on this list: if you also feel that Core is no
longer serving the interests of Bitcoin users, come join us. We don't bite.

Bwhahahahahahahhahahahahah

[s7r via bitcoin-dev]

Fair enough, this is what open source is all about. Good things
sometimes come out of controversial actions. I briefly read the
manifesto, saw the migration plan, it is not that greedy and in theory
it is possible to migrate safely with no (big) incidents.

What seams a little bit unfair is that only miners get to vote and
decide, and the users will have nothing to say about it. Not even
individual miners will vote, since it will be mostly only mining pools
(individual small miners will accept whatever their mining pool runs
on). There are more users than miners obviously, the miners just mine
transactions for the users, it is the users who keep the btc/usd price.

I use bitcoin heavily (not from time to time) but I don't mine - can I
vote? The way I see it I cannot, and I am not saying it is a bad thing,
but I missed the argument explaining why users don't matter and only
miners do.

The btc/usd rate is based on supply and demand, only users take part in
this. If 20% of the miners (hashing power) go away, the network will
still operate normally (lower nethash and probably difficulty) and the
btc/usd price will be the same, but if 20% of the users go away the
btc/usd price will drop -> mining will be less profitable -> miners
could be forced to quit. In other words, the users have more control
over the miners. Why ignore?

Post by Mike Hearn via bitcoin-dev
Hello,
As promised, we have released Bitcoin XT 0.11A which includes the bigger
blocks patch set. You can get it from
https://bitcoinxt.software/
I feel sad that it's come to this, but there is no other way. The
Bitcoin Core project has drifted so far from the principles myself and
many others feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is not
the first and won't be the last project to go through this. Often in
forks, people say there was insufficient communication. So to ensure
everything is crystal clear I've written a blog post and a kind of
"manifesto" to describe why this is happening and how XT plans to be
different from Core (assuming adoption, of course).
It makes no attempt to be neutral: this explains things from our point
of view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is no
longer serving the interests of Bitcoin users, come join us. We don't bite.

[Mike Hearn via bitcoin-dev]

Post by s7r via bitcoin-dev
I use bitcoin heavily (not from time to time) but I don't mine - can I
vote? The way I see it I cannot, and I am not saying it is a bad thing,
but I missed the argument explaining why users don't matter and only
miners do.

It is a reasonable question. Let me try and explain why it's done this way.

*In theory*, you do have a vote. If a majority of miners were to club
together and decide to change the protocol against the wishes of the wider
user base, then we'd get a fight between the hashpower majority and the
so-called economic majority. And because bitcoins only have value because
you can buy things with them, in theory, the wishes of the economic
majority should always win.

*In practice*, the code we have today doesn't let us measure what the
economic majority wants. It's not even really clear how that term is
defined. Intuitively we can understand that people who are trading real
goods and services for bitcoin have the final say, because they can always
just refuse to accept BTC. But defining it precisely enough to put in an
algorithm is tricky.

Then you have the question of how to express the vote? For miners, it's
easy: they express their vote by switching to a different full node
implementation that gives them different blocks.

For users, it'd mean switching to a different wallet. If their wallet is
fully validating and the decision is implemented via hard fork, this is
sufficient. If the wallet is *not* fully validating and cannot detect the
fork point by itself, then it'd need help in the form of checkpointing.
Some months ago I pointed out this possibility and a whole bunch of people
freaked out - then bitcoin.org decided to start censoring any wallet that
said it'd ignore what miners wanted.

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
democratic in nature, but there you go.

We can also imagine voting via proof-of-stake. This might be useful as a
form of opinion poll, but wallet developers would have to actually add
support for such a protocol to their apps, and then we're back to the same
issue as with mining pools. Plus, of course, static wealth does not equal
economic importance.

Luckily the wallet market is a decentralisation success story. There are
wallets everywhere these days. Man+dog make their own wallet, it seems. So
it's not silly to think a coin voting protocol could one day happen.

[Milly Bitcoin via bitcoin-dev]

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 democratic in nature, but there you go.

These types of actions are immediately apparent to anyone who looks at
the Bitcoin ecosystem (Bitcoin.org, Githib, Wiki, bitcointalk, etc.) and
were readily apparent long before any block size debate. It is almost a
taboo subject and anyone who raises these types of issues is immediately
labeled as a "troll." These are the people who used to run around
saying that Bitcoin development is "decentralized" because anyone can
fork the code and now many of the same people claim a fork will destroy
everything.

The problem is that a small group of highly irrational and inexperienced
people (outside of the small and unusual Bitcoin ecosystem) have control
over the majority of the resources. I think over time the problem will
even itself out but currently it is an obstacle in moving Bitcoin forward.

Russ

[Bryan Bishop via bitcoin-dev]

On Sat, Aug 15, 2015 at 3:36 PM, Milly Bitcoin via bitcoin-dev <

These are the people who used to run around saying that Bitcoin
development is "decentralized" because anyone can fork the code and now
many of the same people claim a fork will destroy everything.

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?

- Bryan
http://heybryan.org/
1 512 203 0507

[Milly Bitcoin via bitcoin-dev]

Post by Bryan Bishop via bitcoin-dev
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 "decentralized" because anyone can fork the
code. I have often pointed out to them that such a process is not
decentralization similar to the process of Bitcoin mining. It is
probably closer to checks and balances you see in political systems. The
response is usually that I am "troll" or that I am somehow attacking the
developers by simply describing the system. The result is that the
issues and risks associated with development are often not properly
evaluated. It is the same sorts of problems you have when a central
bank or Fed is controlled by a small group. It is just human nature and
Bitcoin is not immune.

Russ

[Micha Bailey via bitcoin-dev]

If this proposal has less than half of the total hashpower (or is it even
less than 75%? Haven't quite thought it through completely) supporting it,
I can see the following happening if the sum of supporters and people who
want to screw the supporters out of money is at least 75%:
Non-supporters create blocks with the new version, but don't actually
implement the rule. Then after the new rule is locked in, miners will
create too-large blocks that are rejected by the majority. If the
percentage is less than half, then from their perspective, they will
essentially be on the losing side of a soft fork, and they'll be losing
money by mining for nothing, even from their perspective and that of e.g.
users and merchants who have upgraded.

On Saturday, August 15, 2015, Milly Bitcoin via bitcoin-dev <

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 democratic in nature, but there you go.

These types of actions are immediately apparent to anyone who looks at the
Bitcoin ecosystem (Bitcoin.org, Githib, Wiki, bitcointalk, etc.) and were
readily apparent long before any block size debate. It is almost a taboo
subject and anyone who raises these types of issues is immediately labeled
as a "troll." These are the people who used to run around saying that
Bitcoin development is "decentralized" because anyone can fork the code and
now many of the same people claim a fork will destroy everything.
The problem is that a small group of highly irrational and inexperienced
people (outside of the small and unusual Bitcoin ecosystem) have control
over the majority of the resources. I think over time the problem will
even itself out but currently it is an obstacle in moving Bitcoin forward.
Russ
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Eric Lombrozo via bitcoin-dev]

You deeply disappoint me, Mike.

Not only do you misrepresent many cogent, well thought out positions from a great number of people who have published and posted a number of articles detailing an explaining in-depth technical concerns
you also seem to fancy yourself more capable of reading into the intentions of someone who disappeared from the scene years ago, before we even were fully aware of many things we now know that bring the original “plan” into question.

I ask of you, as a civilized human being, to stop doing this divisive crap. Despite your protestations to the contrary, YOU are the one who is proposing a radical departure from the direction of the project. Also, as several of us have clearly stated before, equating the fork of an open source project with a fork of a cryptoledger is completely bogus - there’s a lot of other people’s money at stake. This isn’t a democracy - consensus is all or nothing. The fact that a good number of the people most intimately familiar with the inner workings of Satoshi’s invention do not believe doing this is a good idea should give you pause.

Please stop using Bitcoin as your own political football
for the sake of Bitcoin
and for your own sake. Despite your obvious technical abilities (and I sincerely do believe you have them) you are discrediting yourself and hurting your own reputation.


- Eric

Post by Mike Hearn via bitcoin-dev
Hello,
As promised, we have released Bitcoin XT 0.11A which includes the bigger blocks patch set. You can get it from
https://bitcoinxt.software/ <https://bitcoinxt.software/>
I feel sad that it's come to this, but there is no other way. The Bitcoin Core project has drifted so far from the principles myself and many others feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is not the first and won't be the last project to go through this. Often in forks, people say there was insufficient communication. So to ensure everything is crystal clear I've written a blog post and a kind of "manifesto" to describe why this is happening and how XT plans to be different from Core (assuming adoption, of course).
It makes no attempt to be neutral: this explains things from our point of view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is no longer serving the interests of Bitcoin users, come join us. We don't bite.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Ken Friece via bitcoin-dev]

What are you so afraid of, Eric? If Mike's fork is successful, consensus is
reached around larger blocks. If it is rejected, the status quo will remain
for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the only thing
that matters, and those that go against network consensus will be severely
punished with complete loss of income.

I'm not sure who appointed the core devs some sort of Bitcoin Gods that can
hold up any change that they happen to disagree with. It seems like the
core devs are scared to death that the bitcoin network may change without
their blessing, so they go on and on about how terrible hard forks are.
Hard forks are the only way to keep core devs in check.

Despite significant past technical bitcoin achievements, two of the most
vocal opponents to a reasonable blocksize increase work for a company
(Blockstream) that stands to profit directly from artificially limiting the
blocksize. The whole situation reeks. Because of such a blatant conflict of
interest, the ethical thing to do would be for them to either resign from
Blockstream or immediately withdraw themselves from the blocksize debate.
This is the type of stuff that I hoped would end with Bitcoin, but alas, I
guess human nature never changes.

Personally, I think miners should give Bitcoin XT a serious look. Miners
need to realize that they are in direct competition with the lightning
network and sidechains for fees. Miners, ask yourselves if you think you'll
earn more fees with 1 MB blocks and more off-chain transactions or with 8
MB blocks and more on-chain transactions...

The longer this debate drags on, the more I agree with BIP 100 and Jeff
Garzik because the core devs are already being influenced by outside forces
and should not have complete control of the blocksize. It's also
interesting to note that most of the mining hashpower is already voting for
8MB blocks BIP100 style.

On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev
You deeply disappoint me, Mike.
Not only do you misrepresent many cogent, well thought out positions from
a great number of people who have published and posted a number of articles
detailing an explaining in-depth technical concerns
you also seem to fancy
yourself more capable of reading into the intentions of someone who
disappeared from the scene years ago, before we even were fully aware of
many things we now know that bring the original “plan” into question.
I ask of you, as a civilized human being, to stop doing this divisive
crap. Despite your protestations to the contrary, YOU are the one who is
proposing a radical departure from the direction of the project. Also, as
several of us have clearly stated before, equating the fork of an open
source project with a fork of a cryptoledger is completely bogus - there’s
a lot of other people’s money at stake. This isn’t a democracy - consensus
is all or nothing. The fact that a good number of the people most
intimately familiar with the inner workings of Satoshi’s invention do not
believe doing this is a good idea should give you pause.
Please stop using Bitcoin as your own political football
for the sake of
Bitcoin
and for your own sake. Despite your obvious technical abilities
(and I sincerely do believe you have them) you are discrediting yourself
and hurting your own reputation.
- Eric
On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <
Hello,
As promised, we have released Bitcoin XT 0.11A which includes the bigger
blocks patch set. You can get it from
https://bitcoinxt.software/
I feel sad that it's come to this, but there is no other way. The Bitcoin
Core project has drifted so far from the principles myself and many others
feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is not
the first and won't be the last project to go through this. Often in forks,
people say there was insufficient communication. So to ensure everything is
crystal clear I've written a blog post and a kind of "manifesto" to
describe why this is happening and how XT plans to be different from Core
(assuming adoption, of course).
It makes no attempt to be neutral: this explains things from our point of view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is no
longer serving the interests of Bitcoin users, come join us. We don't bite.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Eric Lombrozo via bitcoin-dev]

What are you so afraid of, Eric? If Mike's fork is successful, consensus is reached around larger blocks. If it is rejected, the status quo will remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the only thing that matters, and those that go against network consensus will be severely punished with complete loss of income.

I fully agree that core developers are not the only people who should have a say in this. But again, we’re not talking about merely forking some open source project - we’re talking about forking a ledger representing real assets that real people are holding
and I think it’s fair to say that the risk of permanent ledger forks far outweighs whatever benefits any change in the protocol might bring. And this would be true even if there were unanimous agreement that the change is good (which there clearly IS NOT in this case) but the deployment mechanism could still break things.

If anything we should attempt a hard fork with a less contentious change first, just to test deployability.

I'm not sure who appointed the core devs some sort of Bitcoin Gods that can hold up any change that they happen to disagree with. It seems like the core devs are scared to death that the bitcoin network may change without their blessing, so they go on and on about how terrible hard forks are. Hard forks are the only way to keep core devs in check.

Again, let’s figure out a hard fork mechanism and test it with a far less contentious change first

Despite significant past technical bitcoin achievements, two of the most vocal opponents to a reasonable blocksize increase work for a company (Blockstream) that stands to profit directly from artificially limiting the blocksize. The whole situation reeks. Because of such a blatant conflict of interest, the ethical thing to do would be for them to either resign from Blockstream or immediately withdraw themselves from the blocksize debate. This is the type of stuff that I hoped would end with Bitcoin, but alas, I guess human nature never changes.

For the record, I do not work for Blockstream. Neither do a bunch of other people who have published a number of concerns. Very few of the concerns I’ve seen from the technical community seem to be motivated primarily by profit motives.

It should also be pointed out that *not* making drastic changes is the default consensus policy
and the burden of justifying a change falls on those who want to make the change. Again, the risk of permanent ledger forks far outweighs whatever benefits protocol changes might bring.

Personally, I think miners should give Bitcoin XT a serious look. Miners need to realize that they are in direct competition with the lightning network and sidechains for fees. Miners, ask yourselves if you think you'll earn more fees with 1 MB blocks and more off-chain transactions or with 8 MB blocks and more on-chain transactions


Miners are NOT in direct competition with the lightning network and sidechains - these claims are patently false. I recommend you take a look at these ideas and understand them a little better before trying to make any such claims. Again, I do not work for Blockstream
and my agenda in this post is not to promote either of these ideas
but with all due respect, I do not think you properly understand them at all.

The longer this debate drags on, the more I agree with BIP 100 and Jeff Garzik because the core devs are already being influenced by outside forces and should not have complete control of the blocksize. It's also interesting to note that most of the mining hashpower is already voting for 8MB blocks BIP100 style.

I don’t think the concern here is so much that some people want to increase block size. It’s the *way* in which this change is being pushed that is deeply problematic.

You deeply disappoint me, Mike.
Not only do you misrepresent many cogent, well thought out positions from a great number of people who have published and posted a number of articles detailing an explaining in-depth technical concerns
you also seem to fancy yourself more capable of reading into the intentions of someone who disappeared from the scene years ago, before we even were fully aware of many things we now know that bring the original “plan” into question.
I ask of you, as a civilized human being, to stop doing this divisive crap. Despite your protestations to the contrary, YOU are the one who is proposing a radical departure from the direction of the project. Also, as several of us have clearly stated before, equating the fork of an open source project with a fork of a cryptoledger is completely bogus - there’s a lot of other people’s money at stake. This isn’t a democracy - consensus is all or nothing. The fact that a good number of the people most intimately familiar with the inner workings of Satoshi’s invention do not believe doing this is a good idea should give you pause.
Please stop using Bitcoin as your own political football
for the sake of Bitcoin
and for your own sake. Despite your obvious technical abilities (and I sincerely do believe you have them) you are discrediting yourself and hurting your own reputation.
- Eric

Post by Mike Hearn via bitcoin-dev
Hello,
As promised, we have released Bitcoin XT 0.11A which includes the bigger blocks patch set. You can get it from
https://bitcoinxt.software/ <https://bitcoinxt.software/>
I feel sad that it's come to this, but there is no other way. The Bitcoin Core project has drifted so far from the principles myself and many others feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is not the first and won't be the last project to go through this. Often in forks, people say there was insufficient communication. So to ensure everything is crystal clear I've written a blog post and a kind of "manifesto" to describe why this is happening and how XT plans to be different from Core (assuming adoption, of course).
It makes no attempt to be neutral: this explains things from our point of view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is no longer serving the interests of Bitcoin users, come join us. We don't bite.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Angel Leon via bitcoin-dev]

"I don’t think the concern here is so much that some people want to
increase block size. It’s the *way* in which this change is being pushed
that is deeply problematic."

As a developer on the side lines, bitcoin holder, bitcoin entrepreneur, and
someone who thinks block size limits should be dynamic, I applaud Mike and
Co. for this initiative, some of us that have different ideas on how to
deal with the blocksize issue will certainly not be afraid of wasting time
sending patches to the Bitcoin XT project where it seems they're a bit more
open minded about this issue. I bet sending the same patch to Bitcoin-Core
would be rejected on the spot. Bitcoin XT, I hope, will give room to allow
for scalability, it seems the other camp is bent on using Bitcoin their own
way and their own way only and that's far more problematic because that
will allienate the entire user base eventually.

http://twitter.com/gubatron

On Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo via bitcoin-dev <

On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
What are you so afraid of, Eric? If Mike's fork is successful, consensus
is reached around larger blocks. If it is rejected, the status quo will
remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the
only thing that matters, and those that go against network consensus will
be severely punished with complete loss of income.
I fully agree that core developers are not the only people who should have
a say in this. But again, we’re not talking about merely forking some open
source project - we’re talking about forking a ledger representing real
assets that real people are holding
and I think it’s fair to say that the
risk of permanent ledger forks far outweighs whatever benefits any change
in the protocol might bring. And this would be true even if there were
unanimous agreement that the change is good (which there clearly IS NOT in
this case) but the deployment mechanism could still break things.
If anything we should attempt a hard fork with a less contentious change
first, just to test deployability.
I'm not sure who appointed the core devs some sort of Bitcoin Gods that
can hold up any change that they happen to disagree with. It seems like the
core devs are scared to death that the bitcoin network may change without
their blessing, so they go on and on about how terrible hard forks are.
Hard forks are the only way to keep core devs in check.
Again, let’s figure out a hard fork mechanism and test it with a far less
contentious change first
Despite significant past technical bitcoin achievements, two of the most
vocal opponents to a reasonable blocksize increase work for a company
(Blockstream) that stands to profit directly from artificially limiting the
blocksize. The whole situation reeks. Because of such a blatant conflict of
interest, the ethical thing to do would be for them to either resign from
Blockstream or immediately withdraw themselves from the blocksize debate.
This is the type of stuff that I hoped would end with Bitcoin, but alas, I
guess human nature never changes.
For the record, I do not work for Blockstream. Neither do a bunch of other
people who have published a number of concerns. Very few of the concerns
I’ve seen from the technical community seem to be motivated primarily by
profit motives.
It should also be pointed out that *not* making drastic changes is the
default consensus policy
and the burden of justifying a change falls on
those who want to make the change. Again, the risk of permanent ledger
forks far outweighs whatever benefits protocol changes might bring.
Personally, I think miners should give Bitcoin XT a serious look. Miners
need to realize that they are in direct competition with the lightning
network and sidechains for fees. Miners, ask yourselves if you think you'll
earn more fees with 1 MB blocks and more off-chain transactions or with 8
MB blocks and more on-chain transactions

Miners are NOT in direct competition with the lightning network and
sidechains - these claims are patently false. I recommend you take a look
at these ideas and understand them a little better before trying to make
any such claims. Again, I do not work for Blockstream
and my agenda in this
post is not to promote either of these ideas
but with all due respect, I do
not think you properly understand them at all.
The longer this debate drags on, the more I agree with BIP 100 and Jeff
Garzik because the core devs are already being influenced by outside forces
and should not have complete control of the blocksize. It's also
interesting to note that most of the mining hashpower is already voting for
8MB blocks BIP100 style.
I don’t think the concern here is so much that some people want to
increase block size. It’s the *way* in which this change is being pushed
that is deeply problematic.
On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev
You deeply disappoint me, Mike.
Not only do you misrepresent many cogent, well thought out positions from
a great number of people who have published and posted a number of articles
detailing an explaining in-depth technical concerns
you also seem to fancy
yourself more capable of reading into the intentions of someone who
disappeared from the scene years ago, before we even were fully aware of
many things we now know that bring the original “plan” into question.
I ask of you, as a civilized human being, to stop doing this divisive
crap. Despite your protestations to the contrary, YOU are the one who is
proposing a radical departure from the direction of the project. Also, as
several of us have clearly stated before, equating the fork of an open
source project with a fork of a cryptoledger is completely bogus - there’s
a lot of other people’s money at stake. This isn’t a democracy - consensus
is all or nothing. The fact that a good number of the people most
intimately familiar with the inner workings of Satoshi’s invention do not
believe doing this is a good idea should give you pause.
Please stop using Bitcoin as your own political football
for the sake of
Bitcoin
and for your own sake. Despite your obvious technical abilities
(and I sincerely do believe you have them) you are discrediting yourself
and hurting your own reputation.
- Eric
On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <
Hello,
As promised, we have released Bitcoin XT 0.11A which includes the bigger
blocks patch set. You can get it from
https://bitcoinxt.software/
I feel sad that it's come to this, but there is no other way. The Bitcoin
Core project has drifted so far from the principles myself and many others
feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is not
the first and won't be the last project to go through this. Often in forks,
people say there was insufficient communication. So to ensure everything is
crystal clear I've written a blog post and a kind of "manifesto" to
describe why this is happening and how XT plans to be different from Core
(assuming adoption, of course).
It makes no attempt to be neutral: this explains things from our point of view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is no
longer serving the interests of Bitcoin users, come join us. We don't bite.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Ken Friece via bitcoin-dev]

I know full well who works for Blockstream and I know you're not one of
those folks. The Blockstream core devs are very vocal against a reasonable
blocksize increase (17% growth per year in Pieter's BIP is not what I
consider reasonable because it doesn't come close to keeping with
technological increases). I think we can both agree that more on-chain
space means less demand for lightning, and vice versa, which is a blatant
conflict of interest.

I'm also trying to figure out how things like lightning are not competing
directly with miners for fees. More off-chain transactions means less
blockchain demand, which would lower on-chain fees. I'm not sure what is
controversial about that statement.

The lightning network concept is actually a brilliant way to take fees away
from miners without having to make any investment at all in SSH-256 ASIC
mining hardware.

On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
What are you so afraid of, Eric? If Mike's fork is successful, consensus
is reached around larger blocks. If it is rejected, the status quo will
remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the
only thing that matters, and those that go against network consensus will
be severely punished with complete loss of income.
I fully agree that core developers are not the only people who should have
a say in this. But again, we’re not talking about merely forking some open
source project - we’re talking about forking a ledger representing real
assets that real people are holding
and I think it’s fair to say that the
risk of permanent ledger forks far outweighs whatever benefits any change
in the protocol might bring. And this would be true even if there were
unanimous agreement that the change is good (which there clearly IS NOT in
this case) but the deployment mechanism could still break things.
If anything we should attempt a hard fork with a less contentious change
first, just to test deployability.
I'm not sure who appointed the core devs some sort of Bitcoin Gods that
can hold up any change that they happen to disagree with. It seems like the
core devs are scared to death that the bitcoin network may change without
their blessing, so they go on and on about how terrible hard forks are.
Hard forks are the only way to keep core devs in check.
Again, let’s figure out a hard fork mechanism and test it with a far less
contentious change first
Despite significant past technical bitcoin achievements, two of the most
vocal opponents to a reasonable blocksize increase work for a company
(Blockstream) that stands to profit directly from artificially limiting the
blocksize. The whole situation reeks. Because of such a blatant conflict of
interest, the ethical thing to do would be for them to either resign from
Blockstream or immediately withdraw themselves from the blocksize debate.
This is the type of stuff that I hoped would end with Bitcoin, but alas, I
guess human nature never changes.
For the record, I do not work for Blockstream. Neither do a bunch of other
people who have published a number of concerns. Very few of the concerns
I’ve seen from the technical community seem to be motivated primarily by
profit motives.
It should also be pointed out that *not* making drastic changes is the
default consensus policy
and the burden of justifying a change falls on
those who want to make the change. Again, the risk of permanent ledger
forks far outweighs whatever benefits protocol changes might bring.
Personally, I think miners should give Bitcoin XT a serious look. Miners
need to realize that they are in direct competition with the lightning
network and sidechains for fees. Miners, ask yourselves if you think you'll
earn more fees with 1 MB blocks and more off-chain transactions or with 8
MB blocks and more on-chain transactions

Miners are NOT in direct competition with the lightning network and
sidechains - these claims are patently false. I recommend you take a look
at these ideas and understand them a little better before trying to make
any such claims. Again, I do not work for Blockstream
and my agenda in this
post is not to promote either of these ideas
but with all due respect, I do
not think you properly understand them at all.
The longer this debate drags on, the more I agree with BIP 100 and Jeff
Garzik because the core devs are already being influenced by outside forces
and should not have complete control of the blocksize. It's also
interesting to note that most of the mining hashpower is already voting for
8MB blocks BIP100 style.
I don’t think the concern here is so much that some people want to
increase block size. It’s the *way* in which this change is being pushed
that is deeply problematic.
On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev
You deeply disappoint me, Mike.
Not only do you misrepresent many cogent, well thought out positions from
a great number of people who have published and posted a number of articles
detailing an explaining in-depth technical concerns
you also seem to fancy
yourself more capable of reading into the intentions of someone who
disappeared from the scene years ago, before we even were fully aware of
many things we now know that bring the original “plan” into question.
I ask of you, as a civilized human being, to stop doing this divisive
crap. Despite your protestations to the contrary, YOU are the one who is
proposing a radical departure from the direction of the project. Also, as
several of us have clearly stated before, equating the fork of an open
source project with a fork of a cryptoledger is completely bogus - there’s
a lot of other people’s money at stake. This isn’t a democracy - consensus
is all or nothing. The fact that a good number of the people most
intimately familiar with the inner workings of Satoshi’s invention do not
believe doing this is a good idea should give you pause.
Please stop using Bitcoin as your own political football
for the sake of
Bitcoin
and for your own sake. Despite your obvious technical abilities
(and I sincerely do believe you have them) you are discrediting yourself
and hurting your own reputation.
- Eric
On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <
Hello,
As promised, we have released Bitcoin XT 0.11A which includes the bigger
blocks patch set. You can get it from
https://bitcoinxt.software/
I feel sad that it's come to this, but there is no other way. The Bitcoin
Core project has drifted so far from the principles myself and many others
feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is not
the first and won't be the last project to go through this. Often in forks,
people say there was insufficient communication. So to ensure everything is
crystal clear I've written a blog post and a kind of "manifesto" to
describe why this is happening and how XT plans to be different from Core
(assuming adoption, of course).
It makes no attempt to be neutral: this explains things from our point of view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is no
longer serving the interests of Bitcoin users, come join us. We don't bite.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Mark Friedenbach via bitcoin-dev]

I would like very much to know how it is that we're supposed to be making
money off of lightning, and therefore how it represents a conflict of
interest. Apparently there is tons of money to be made in releasing
open-source protocols! I would hate to miss out on that.

We are working on lightning because Mike of all people said, essentially, "
if you're so fond of micro payment channels, why aren't you working on
them?" And he was right! So we looked around and found the best proposal
and funded it.
On Aug 15, 2015 3:28 PM, "Ken Friece via bitcoin-dev" <

Post by Ken Friece via bitcoin-dev
I know full well who works for Blockstream and I know you're not one of
those folks. The Blockstream core devs are very vocal against a reasonable
blocksize increase (17% growth per year in Pieter's BIP is not what I
consider reasonable because it doesn't come close to keeping with
technological increases). I think we can both agree that more on-chain
space means less demand for lightning, and vice versa, which is a blatant
conflict of interest.
I'm also trying to figure out how things like lightning are not competing
directly with miners for fees. More off-chain transactions means less
blockchain demand, which would lower on-chain fees. I'm not sure what is
controversial about that statement.
The lightning network concept is actually a brilliant way to take fees
away from miners without having to make any investment at all in SSH-256
ASIC mining hardware.

On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
What are you so afraid of, Eric? If Mike's fork is successful, consensus
is reached around larger blocks. If it is rejected, the status quo will
remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the
only thing that matters, and those that go against network consensus will
be severely punished with complete loss of income.
I fully agree that core developers are not the only people who should
have a say in this. But again, we’re not talking about merely forking some
open source project - we’re talking about forking a ledger representing
real assets that real people are holding
and I think it’s fair to say that
the risk of permanent ledger forks far outweighs whatever benefits any
change in the protocol might bring. And this would be true even if there
were unanimous agreement that the change is good (which there clearly IS
NOT in this case) but the deployment mechanism could still break things.
If anything we should attempt a hard fork with a less contentious change
first, just to test deployability.
I'm not sure who appointed the core devs some sort of Bitcoin Gods that
can hold up any change that they happen to disagree with. It seems like the
core devs are scared to death that the bitcoin network may change without
their blessing, so they go on and on about how terrible hard forks are.
Hard forks are the only way to keep core devs in check.
Again, let’s figure out a hard fork mechanism and test it with a far less
contentious change first
Despite significant past technical bitcoin achievements, two of the most
vocal opponents to a reasonable blocksize increase work for a company
(Blockstream) that stands to profit directly from artificially limiting the
blocksize. The whole situation reeks. Because of such a blatant conflict of
interest, the ethical thing to do would be for them to either resign from
Blockstream or immediately withdraw themselves from the blocksize debate.
This is the type of stuff that I hoped would end with Bitcoin, but alas, I
guess human nature never changes.
For the record, I do not work for Blockstream. Neither do a bunch of
other people who have published a number of concerns. Very few of the
concerns I’ve seen from the technical community seem to be motivated
primarily by profit motives.
It should also be pointed out that *not* making drastic changes is the
default consensus policy
and the burden of justifying a change falls on
those who want to make the change. Again, the risk of permanent ledger
forks far outweighs whatever benefits protocol changes might bring.
Personally, I think miners should give Bitcoin XT a serious look. Miners
need to realize that they are in direct competition with the lightning
network and sidechains for fees. Miners, ask yourselves if you think you'll
earn more fees with 1 MB blocks and more off-chain transactions or with 8
MB blocks and more on-chain transactions

Miners are NOT in direct competition with the lightning network and
sidechains - these claims are patently false. I recommend you take a look
at these ideas and understand them a little better before trying to make
any such claims. Again, I do not work for Blockstream
and my agenda in this
post is not to promote either of these ideas
but with all due respect, I do
not think you properly understand them at all.
The longer this debate drags on, the more I agree with BIP 100 and Jeff
Garzik because the core devs are already being influenced by outside forces
and should not have complete control of the blocksize. It's also
interesting to note that most of the mining hashpower is already voting for
8MB blocks BIP100 style.
I don’t think the concern here is so much that some people want to
increase block size. It’s the *way* in which this change is being pushed
that is deeply problematic.
On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev
You deeply disappoint me, Mike.
Not only do you misrepresent many cogent, well thought out positions
from a great number of people who have published and posted a number of
articles detailing an explaining in-depth technical concerns
you also seem
to fancy yourself more capable of reading into the intentions of someone
who disappeared from the scene years ago, before we even were fully aware
of many things we now know that bring the original “plan” into question.
I ask of you, as a civilized human being, to stop doing this divisive
crap. Despite your protestations to the contrary, YOU are the one who is
proposing a radical departure from the direction of the project. Also, as
several of us have clearly stated before, equating the fork of an open
source project with a fork of a cryptoledger is completely bogus - there’s
a lot of other people’s money at stake. This isn’t a democracy - consensus
is all or nothing. The fact that a good number of the people most
intimately familiar with the inner workings of Satoshi’s invention do not
believe doing this is a good idea should give you pause.
Please stop using Bitcoin as your own political football
for the sake of
Bitcoin
and for your own sake. Despite your obvious technical abilities
(and I sincerely do believe you have them) you are discrediting yourself
and hurting your own reputation.
- Eric
On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <
Hello,
As promised, we have released Bitcoin XT 0.11A which includes the bigger
blocks patch set. You can get it from
https://bitcoinxt.software/
I feel sad that it's come to this, but there is no other way. The
Bitcoin Core project has drifted so far from the principles myself and many
others feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is not
the first and won't be the last project to go through this. Often in forks,
people say there was insufficient communication. So to ensure everything is
crystal clear I've written a blog post and a kind of "manifesto" to
describe why this is happening and how XT plans to be different from Core
(assuming adoption, of course).
It makes no attempt to be neutral: this explains things from our point of view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is no
longer serving the interests of Bitcoin users, come join us. We don't bite.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

[Ken Friece via bitcoin-dev]

Being an early hub provider would be an obvious place to start capitalizing
on lightning. Early lightning adopters would be in the best position to do
this.

Long term, Bitcoin needs to scale the blockchain in a reasonable manner and
implement things like lightning.

Limiting the blocksize is a blatant conflict of interest because it creates
artificial demand for lightning that would not otherwise exist if the
blockchain scaled in a reasonable manner.

Post by Mark Friedenbach via bitcoin-dev
I would like very much to know how it is that we're supposed to be making
money off of lightning, and therefore how it represents a conflict of
interest. Apparently there is tons of money to be made in releasing
open-source protocols! I would hate to miss out on that.
We are working on lightning because Mike of all people said, essentially,
" if you're so fond of micro payment channels, why aren't you working on
them?" And he was right! So we looked around and found the best proposal
and funded it.
On Aug 15, 2015 3:28 PM, "Ken Friece via bitcoin-dev" <

Post by Ken Friece via bitcoin-dev
I know full well who works for Blockstream and I know you're not one of
those folks. The Blockstream core devs are very vocal against a reasonable
blocksize increase (17% growth per year in Pieter's BIP is not what I
consider reasonable because it doesn't come close to keeping with
technological increases). I think we can both agree that more on-chain
space means less demand for lightning, and vice versa, which is a blatant
conflict of interest.
I'm also trying to figure out how things like lightning are not competing
directly with miners for fees. More off-chain transactions means less
blockchain demand, which would lower on-chain fees. I'm not sure what is
controversial about that statement.
The lightning network concept is actually a brilliant way to take fees
away from miners without having to make any investment at all in SSH-256
ASIC mining hardware.

On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
What are you so afraid of, Eric? If Mike's fork is successful, consensus
is reached around larger blocks. If it is rejected, the status quo will
remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the
only thing that matters, and those that go against network consensus will
be severely punished with complete loss of income.
I fully agree that core developers are not the only people who should
have a say in this. But again, we’re not talking about merely forking some
open source project - we’re talking about forking a ledger representing
real assets that real people are holding
and I think it’s fair to say that
the risk of permanent ledger forks far outweighs whatever benefits any
change in the protocol might bring. And this would be true even if there
were unanimous agreement that the change is good (which there clearly IS
NOT in this case) but the deployment mechanism could still break things.
If anything we should attempt a hard fork with a less contentious change
first, just to test deployability.
I'm not sure who appointed the core devs some sort of Bitcoin Gods that
can hold up any change that they happen to disagree with. It seems like the
core devs are scared to death that the bitcoin network may change without
their blessing, so they go on and on about how terrible hard forks are.
Hard forks are the only way to keep core devs in check.
Again, let’s figure out a hard fork mechanism and test it with a far
less contentious change first
Despite significant past technical bitcoin achievements, two of the most
vocal opponents to a reasonable blocksize increase work for a company
(Blockstream) that stands to profit directly from artificially limiting the
blocksize. The whole situation reeks. Because of such a blatant conflict of
interest, the ethical thing to do would be for them to either resign from
Blockstream or immediately withdraw themselves from the blocksize debate.
This is the type of stuff that I hoped would end with Bitcoin, but alas, I
guess human nature never changes.
For the record, I do not work for Blockstream. Neither do a bunch of
other people who have published a number of concerns. Very few of the
concerns I’ve seen from the technical community seem to be motivated
primarily by profit motives.
It should also be pointed out that *not* making drastic changes is the
default consensus policy
and the burden of justifying a change falls on
those who want to make the change. Again, the risk of permanent ledger
forks far outweighs whatever benefits protocol changes might bring.
Personally, I think miners should give Bitcoin XT a serious look. Miners
need to realize that they are in direct competition with the lightning
network and sidechains for fees. Miners, ask yourselves if you think you'll
earn more fees with 1 MB blocks and more off-chain transactions or with 8
MB blocks and more on-chain transactions

Miners are NOT in direct competition with the lightning network and
sidechains - these claims are patently false. I recommend you take a look
at these ideas and understand them a little better before trying to make
any such claims. Again, I do not work for Blockstream
and my agenda in this
post is not to promote either of these ideas
but with all due respect, I do
not think you properly understand them at all.
The longer this debate drags on, the more I agree with BIP 100 and Jeff
Garzik because the core devs are already being influenced by outside forces
and should not have complete control of the blocksize. It's also
interesting to note that most of the mining hashpower is already voting for
8MB blocks BIP100 style.
I don’t think the concern here is so much that some people want to
increase block size. It’s the *way* in which this change is being pushed
that is deeply problematic.
On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev
You deeply disappoint me, Mike.
Not only do you misrepresent many cogent, well thought out positions
from a great number of people who have published and posted a number of
articles detailing an explaining in-depth technical concerns
you also seem
to fancy yourself more capable of reading into the intentions of someone
who disappeared from the scene years ago, before we even were fully aware
of many things we now know that bring the original “plan” into question.
I ask of you, as a civilized human being, to stop doing this divisive
crap. Despite your protestations to the contrary, YOU are the one who is
proposing a radical departure from the direction of the project. Also, as
several of us have clearly stated before, equating the fork of an open
source project with a fork of a cryptoledger is completely bogus - there’s
a lot of other people’s money at stake. This isn’t a democracy - consensus
is all or nothing. The fact that a good number of the people most
intimately familiar with the inner workings of Satoshi’s invention do not
believe doing this is a good idea should give you pause.
Please stop using Bitcoin as your own political football
for the sake
of Bitcoin
and for your own sake. Despite your obvious technical abilities
(and I sincerely do believe you have them) you are discrediting yourself
and hurting your own reputation.
- Eric
On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <
Hello,
As promised, we have released Bitcoin XT 0.11A which includes the
bigger blocks patch set. You can get it from
https://bitcoinxt.software/
I feel sad that it's come to this, but there is no other way. The
Bitcoin Core project has drifted so far from the principles myself and many
others feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is not
the first and won't be the last project to go through this. Often in forks,
people say there was insufficient communication. So to ensure everything is
crystal clear I've written a blog post and a kind of "manifesto" to
describe why this is happening and how XT plans to be different from Core
(assuming adoption, of course).
It makes no attempt to be neutral: this explains things from our point of view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is no
longer serving the interests of Bitcoin users, come join us. We don't bite.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

[Eric Lombrozo via bitcoin-dev]

Please take the lightning 101 discussion to another thread.

The main point I was trying to make was that Mike is clearly misrepresenting the views of a great number of people who have deep, intimate knowledge of how things work and are almost certainly not primarily motivated by their own potential for profits.

Being an early hub provider would be an obvious place to start capitalizing on lightning. Early lightning adopters would be in the best position to do this.
Long term, Bitcoin needs to scale the blockchain in a reasonable manner and implement things like lightning.
Limiting the blocksize is a blatant conflict of interest because it creates artificial demand for lightning that would not otherwise exist if the blockchain scaled in a reasonable manner.
I would like very much to know how it is that we're supposed to be making money off of lightning, and therefore how it represents a conflict of interest. Apparently there is tons of money to be made in releasing open-source protocols! I would hate to miss out on that.
We are working on lightning because Mike of all people said, essentially, " if you're so fond of micro payment channels, why aren't you working on them?" And he was right! So we looked around and found the best proposal and funded it.
I know full well who works for Blockstream and I know you're not one of those folks. The Blockstream core devs are very vocal against a reasonable blocksize increase (17% growth per year in Pieter's BIP is not what I consider reasonable because it doesn't come close to keeping with technological increases). I think we can both agree that more on-chain space means less demand for lightning, and vice versa, which is a blatant conflict of interest.
I'm also trying to figure out how things like lightning are not competing directly with miners for fees. More off-chain transactions means less blockchain demand, which would lower on-chain fees. I'm not sure what is controversial about that statement.
The lightning network concept is actually a brilliant way to take fees away from miners without having to make any investment at all in SSH-256 ASIC mining hardware.

What are you so afraid of, Eric? If Mike's fork is successful, consensus is reached around larger blocks. If it is rejected, the status quo will remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the only thing that matters, and those that go against network consensus will be severely punished with complete loss of income.

I fully agree that core developers are not the only people who should have a say in this. But again, we’re not talking about merely forking some open source project - we’re talking about forking a ledger representing real assets that real people are holding
and I think it’s fair to say that the risk of permanent ledger forks far outweighs whatever benefits any change in the protocol might bring. And this would be true even if there were unanimous agreement that the change is good (which there clearly IS NOT in this case) but the deployment mechanism could still break things.
If anything we should attempt a hard fork with a less contentious change first, just to test deployability.

I'm not sure who appointed the core devs some sort of Bitcoin Gods that can hold up any change that they happen to disagree with. It seems like the core devs are scared to death that the bitcoin network may change without their blessing, so they go on and on about how terrible hard forks are. Hard forks are the only way to keep core devs in check.

Again, let’s figure out a hard fork mechanism and test it with a far less contentious change first

Despite significant past technical bitcoin achievements, two of the most vocal opponents to a reasonable blocksize increase work for a company (Blockstream) that stands to profit directly from artificially limiting the blocksize. The whole situation reeks. Because of such a blatant conflict of interest, the ethical thing to do would be for them to either resign from Blockstream or immediately withdraw themselves from the blocksize debate. This is the type of stuff that I hoped would end with Bitcoin, but alas, I guess human nature never changes.

For the record, I do not work for Blockstream. Neither do a bunch of other people who have published a number of concerns. Very few of the concerns I’ve seen from the technical community seem to be motivated primarily by profit motives.
It should also be pointed out that *not* making drastic changes is the default consensus policy
and the burden of justifying a change falls on those who want to make the change. Again, the risk of permanent ledger forks far outweighs whatever benefits protocol changes might bring.

Personally, I think miners should give Bitcoin XT a serious look. Miners need to realize that they are in direct competition with the lightning network and sidechains for fees. Miners, ask yourselves if you think you'll earn more fees with 1 MB blocks and more off-chain transactions or with 8 MB blocks and more on-chain transactions


Miners are NOT in direct competition with the lightning network and sidechains - these claims are patently false. I recommend you take a look at these ideas and understand them a little better before trying to make any such claims. Again, I do not work for Blockstream
and my agenda in this post is not to promote either of these ideas
but with all due respect, I do not think you properly understand them at all.

The longer this debate drags on, the more I agree with BIP 100 and Jeff Garzik because the core devs are already being influenced by outside forces and should not have complete control of the blocksize. It's also interesting to note that most of the mining hashpower is already voting for 8MB blocks BIP100 style.

I don’t think the concern here is so much that some people want to increase block size. It’s the *way* in which this change is being pushed that is deeply problematic.

You deeply disappoint me, Mike.
Not only do you misrepresent many cogent, well thought out positions from a great number of people who have published and posted a number of articles detailing an explaining in-depth technical concerns
you also seem to fancy yourself more capable of reading into the intentions of someone who disappeared from the scene years ago, before we even were fully aware of many things we now know that bring the original “plan” into question.
I ask of you, as a civilized human being, to stop doing this divisive crap. Despite your protestations to the contrary, YOU are the one who is proposing a radical departure from the direction of the project. Also, as several of us have clearly stated before, equating the fork of an open source project with a fork of a cryptoledger is completely bogus - there’s a lot of other people’s money at stake. This isn’t a democracy - consensus is all or nothing. The fact that a good number of the people most intimately familiar with the inner workings of Satoshi’s invention do not believe doing this is a good idea should give you pause.
Please stop using Bitcoin as your own political football
for the sake of Bitcoin
and for your own sake. Despite your obvious technical abilities (and I sincerely do believe you have them) you are discrediting yourself and hurting your own reputation.
- Eric

Post by Mike Hearn via bitcoin-dev
Hello,
As promised, we have released Bitcoin XT 0.11A which includes the bigger blocks patch set. You can get it from
https://bitcoinxt.software/ <https://bitcoinxt.software/>
I feel sad that it's come to this, but there is no other way. The Bitcoin Core project has drifted so far from the principles myself and many others feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is not the first and won't be the last project to go through this. Often in forks, people say there was insufficient communication. So to ensure everything is crystal clear I've written a blog post and a kind of "manifesto" to describe why this is happening and how XT plans to be different from Core (assuming adoption, of course).
It makes no attempt to be neutral: this explains things from our point of view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is no longer serving the interests of Bitcoin users, come join us. We don't bite.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Michael Naber via bitcoin-dev]

Bitcoin has no elections; it has no courts. If not through attempting a
hard-fork, how should we properly resolve irreconcilable disagreements?

On Sat, Aug 15, 2015 at 6:07 PM, Eric Lombrozo via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev
Please take the lightning 101 discussion to another thread.
The main point I was trying to make was that Mike is clearly
misrepresenting the views of a great number of people who have deep,
intimate knowledge of how things work and are almost certainly not
primarily motivated by their own potential for profits.
On Aug 15, 2015, at 4:04 PM, Ken Friece via bitcoin-dev <
Being an early hub provider would be an obvious place to start
capitalizing on lightning. Early lightning adopters would be in the best
position to do this.
Long term, Bitcoin needs to scale the blockchain in a reasonable manner
and implement things like lightning.
Limiting the blocksize is a blatant conflict of interest because it
creates artificial demand for lightning that would not otherwise exist if
the blockchain scaled in a reasonable manner.

Post by Mark Friedenbach via bitcoin-dev
I would like very much to know how it is that we're supposed to be making
money off of lightning, and therefore how it represents a conflict of
interest. Apparently there is tons of money to be made in releasing
open-source protocols! I would hate to miss out on that.
We are working on lightning because Mike of all people said, essentially,
" if you're so fond of micro payment channels, why aren't you working on
them?" And he was right! So we looked around and found the best proposal
and funded it.
On Aug 15, 2015 3:28 PM, "Ken Friece via bitcoin-dev" <

Post by Ken Friece via bitcoin-dev
I know full well who works for Blockstream and I know you're not one of
those folks. The Blockstream core devs are very vocal against a reasonable
blocksize increase (17% growth per year in Pieter's BIP is not what I
consider reasonable because it doesn't come close to keeping with
technological increases). I think we can both agree that more on-chain
space means less demand for lightning, and vice versa, which is a blatant
conflict of interest.
I'm also trying to figure out how things like lightning are not
competing directly with miners for fees. More off-chain transactions means
less blockchain demand, which would lower on-chain fees. I'm not sure what
is controversial about that statement.
The lightning network concept is actually a brilliant way to take fees
away from miners without having to make any investment at all in SSH-256
ASIC mining hardware.

On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
What are you so afraid of, Eric? If Mike's fork is successful,
consensus is reached around larger blocks. If it is rejected, the status
quo will remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS,
is the only thing that matters, and those that go against network consensus
will be severely punished with complete loss of income.
I fully agree that core developers are not the only people who should
have a say in this. But again, we’re not talking about merely forking some
open source project - we’re talking about forking a ledger representing
real assets that real people are holding
and I think it’s fair to say that
the risk of permanent ledger forks far outweighs whatever benefits any
change in the protocol might bring. And this would be true even if there
were unanimous agreement that the change is good (which there clearly IS
NOT in this case) but the deployment mechanism could still break things.
If anything we should attempt a hard fork with a less contentious
change first, just to test deployability.
I'm not sure who appointed the core devs some sort of Bitcoin Gods that
can hold up any change that they happen to disagree with. It seems like the
core devs are scared to death that the bitcoin network may change without
their blessing, so they go on and on about how terrible hard forks are.
Hard forks are the only way to keep core devs in check.
Again, let’s figure out a hard fork mechanism and test it with a far
less contentious change first
Despite significant past technical bitcoin achievements, two of the
most vocal opponents to a reasonable blocksize increase work for a company
(Blockstream) that stands to profit directly from artificially limiting the
blocksize. The whole situation reeks. Because of such a blatant conflict of
interest, the ethical thing to do would be for them to either resign from
Blockstream or immediately withdraw themselves from the blocksize debate.
This is the type of stuff that I hoped would end with Bitcoin, but alas, I
guess human nature never changes.
For the record, I do not work for Blockstream. Neither do a bunch of
other people who have published a number of concerns. Very few of the
concerns I’ve seen from the technical community seem to be motivated
primarily by profit motives.
It should also be pointed out that *not* making drastic changes is the
default consensus policy
and the burden of justifying a change falls on
those who want to make the change. Again, the risk of permanent ledger
forks far outweighs whatever benefits protocol changes might bring.
Personally, I think miners should give Bitcoin XT a serious look.
Miners need to realize that they are in direct competition with the
lightning network and sidechains for fees. Miners, ask yourselves if you
think you'll earn more fees with 1 MB blocks and more off-chain
transactions or with 8 MB blocks and more on-chain transactions

Miners are NOT in direct competition with the lightning network and
sidechains - these claims are patently false. I recommend you take a look
at these ideas and understand them a little better before trying to make
any such claims. Again, I do not work for Blockstream
and my agenda in this
post is not to promote either of these ideas
but with all due respect, I do
not think you properly understand them at all.
The longer this debate drags on, the more I agree with BIP 100 and Jeff
Garzik because the core devs are already being influenced by outside forces
and should not have complete control of the blocksize. It's also
interesting to note that most of the mining hashpower is already voting for
8MB blocks BIP100 style.
I don’t think the concern here is so much that some people want to
increase block size. It’s the *way* in which this change is being pushed
that is deeply problematic.
On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev
You deeply disappoint me, Mike.
Not only do you misrepresent many cogent, well thought out positions
from a great number of people who have published and posted a number of
articles detailing an explaining in-depth technical concerns
you also seem
to fancy yourself more capable of reading into the intentions of someone
who disappeared from the scene years ago, before we even were fully aware
of many things we now know that bring the original “plan” into question.
I ask of you, as a civilized human being, to stop doing this divisive
crap. Despite your protestations to the contrary, YOU are the one who is
proposing a radical departure from the direction of the project. Also, as
several of us have clearly stated before, equating the fork of an open
source project with a fork of a cryptoledger is completely bogus - there’s
a lot of other people’s money at stake. This isn’t a democracy - consensus
is all or nothing. The fact that a good number of the people most
intimately familiar with the inner workings of Satoshi’s invention do not
believe doing this is a good idea should give you pause.
Please stop using Bitcoin as your own political football
for the sake
of Bitcoin
and for your own sake. Despite your obvious technical abilities
(and I sincerely do believe you have them) you are discrediting yourself
and hurting your own reputation.
- Eric
On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <
Hello,
As promised, we have released Bitcoin XT 0.11A which includes the
bigger blocks patch set. You can get it from
https://bitcoinxt.software/
I feel sad that it's come to this, but there is no other way. The
Bitcoin Core project has drifted so far from the principles myself and many
others feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is
not the first and won't be the last project to go through this. Often in
forks, people say there was insufficient communication. So to ensure
everything is crystal clear I've written a blog post and a kind of
"manifesto" to describe why this is happening and how XT plans to be
different from Core (assuming adoption, of course).
It makes no attempt to be neutral: this explains things from our point of view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is no
longer serving the interests of Bitcoin users, come join us. We don't bite.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

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

[Mark Friedenbach via bitcoin-dev]

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.

The Lightning Network effort at Blockstream is purposefully structured to
avoid any conflict of interest. ALL code related to lightning is available
on Github. There is absolutely nothing that we are holding back, and the
protocol itself is entirely p2p. There is no privileged entity, Blockstream
or otherwise.

On Sat, Aug 15, 2015 at 4:07 PM, Eric Lombrozo via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev
Please take the lightning 101 discussion to another thread.
The main point I was trying to make was that Mike is clearly
misrepresenting the views of a great number of people who have deep,
intimate knowledge of how things work and are almost certainly not
primarily motivated by their own potential for profits.
On Aug 15, 2015, at 4:04 PM, Ken Friece via bitcoin-dev <
Being an early hub provider would be an obvious place to start
capitalizing on lightning. Early lightning adopters would be in the best
position to do this.
Long term, Bitcoin needs to scale the blockchain in a reasonable manner
and implement things like lightning.
Limiting the blocksize is a blatant conflict of interest because it
creates artificial demand for lightning that would not otherwise exist if
the blockchain scaled in a reasonable manner.

Post by Mark Friedenbach via bitcoin-dev
I would like very much to know how it is that we're supposed to be making
money off of lightning, and therefore how it represents a conflict of
interest. Apparently there is tons of money to be made in releasing
open-source protocols! I would hate to miss out on that.
We are working on lightning because Mike of all people said, essentially,
" if you're so fond of micro payment channels, why aren't you working on
them?" And he was right! So we looked around and found the best proposal
and funded it.
On Aug 15, 2015 3:28 PM, "Ken Friece via bitcoin-dev" <

Post by Ken Friece via bitcoin-dev
I know full well who works for Blockstream and I know you're not one of
those folks. The Blockstream core devs are very vocal against a reasonable
blocksize increase (17% growth per year in Pieter's BIP is not what I
consider reasonable because it doesn't come close to keeping with
technological increases). I think we can both agree that more on-chain
space means less demand for lightning, and vice versa, which is a blatant
conflict of interest.
I'm also trying to figure out how things like lightning are not
competing directly with miners for fees. More off-chain transactions means
less blockchain demand, which would lower on-chain fees. I'm not sure what
is controversial about that statement.
The lightning network concept is actually a brilliant way to take fees
away from miners without having to make any investment at all in SSH-256
ASIC mining hardware.

On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
What are you so afraid of, Eric? If Mike's fork is successful,
consensus is reached around larger blocks. If it is rejected, the status
quo will remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS,
is the only thing that matters, and those that go against network consensus
will be severely punished with complete loss of income.
I fully agree that core developers are not the only people who should
have a say in this. But again, we’re not talking about merely forking some
open source project - we’re talking about forking a ledger representing
real assets that real people are holding
and I think it’s fair to say that
the risk of permanent ledger forks far outweighs whatever benefits any
change in the protocol might bring. And this would be true even if there
were unanimous agreement that the change is good (which there clearly IS
NOT in this case) but the deployment mechanism could still break things.
If anything we should attempt a hard fork with a less contentious
change first, just to test deployability.
I'm not sure who appointed the core devs some sort of Bitcoin Gods that
can hold up any change that they happen to disagree with. It seems like the
core devs are scared to death that the bitcoin network may change without
their blessing, so they go on and on about how terrible hard forks are.
Hard forks are the only way to keep core devs in check.
Again, let’s figure out a hard fork mechanism and test it with a far
less contentious change first
Despite significant past technical bitcoin achievements, two of the
most vocal opponents to a reasonable blocksize increase work for a company
(Blockstream) that stands to profit directly from artificially limiting the
blocksize. The whole situation reeks. Because of such a blatant conflict of
interest, the ethical thing to do would be for them to either resign from
Blockstream or immediately withdraw themselves from the blocksize debate.
This is the type of stuff that I hoped would end with Bitcoin, but alas, I
guess human nature never changes.
For the record, I do not work for Blockstream. Neither do a bunch of
other people who have published a number of concerns. Very few of the
concerns I’ve seen from the technical community seem to be motivated
primarily by profit motives.
It should also be pointed out that *not* making drastic changes is the
default consensus policy
and the burden of justifying a change falls on
those who want to make the change. Again, the risk of permanent ledger
forks far outweighs whatever benefits protocol changes might bring.
Personally, I think miners should give Bitcoin XT a serious look.
Miners need to realize that they are in direct competition with the
lightning network and sidechains for fees. Miners, ask yourselves if you
think you'll earn more fees with 1 MB blocks and more off-chain
transactions or with 8 MB blocks and more on-chain transactions

Miners are NOT in direct competition with the lightning network and
sidechains - these claims are patently false. I recommend you take a look
at these ideas and understand them a little better before trying to make
any such claims. Again, I do not work for Blockstream
and my agenda in this
post is not to promote either of these ideas
but with all due respect, I do
not think you properly understand them at all.
The longer this debate drags on, the more I agree with BIP 100 and Jeff
Garzik because the core devs are already being influenced by outside forces
and should not have complete control of the blocksize. It's also
interesting to note that most of the mining hashpower is already voting for
8MB blocks BIP100 style.
I don’t think the concern here is so much that some people want to
increase block size. It’s the *way* in which this change is being pushed
that is deeply problematic.
On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev
You deeply disappoint me, Mike.
Not only do you misrepresent many cogent, well thought out positions
from a great number of people who have published and posted a number of
articles detailing an explaining in-depth technical concerns
you also seem
to fancy yourself more capable of reading into the intentions of someone
who disappeared from the scene years ago, before we even were fully aware
of many things we now know that bring the original “plan” into question.
I ask of you, as a civilized human being, to stop doing this divisive
crap. Despite your protestations to the contrary, YOU are the one who is
proposing a radical departure from the direction of the project. Also, as
several of us have clearly stated before, equating the fork of an open
source project with a fork of a cryptoledger is completely bogus - there’s
a lot of other people’s money at stake. This isn’t a democracy - consensus
is all or nothing. The fact that a good number of the people most
intimately familiar with the inner workings of Satoshi’s invention do not
believe doing this is a good idea should give you pause.
Please stop using Bitcoin as your own political football
for the sake
of Bitcoin
and for your own sake. Despite your obvious technical abilities
(and I sincerely do believe you have them) you are discrediting yourself
and hurting your own reputation.
- Eric
On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <
Hello,
As promised, we have released Bitcoin XT 0.11A which includes the
bigger blocks patch set. You can get it from
https://bitcoinxt.software/
I feel sad that it's come to this, but there is no other way. The
Bitcoin Core project has drifted so far from the principles myself and many
others feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is
not the first and won't be the last project to go through this. Often in
forks, people say there was insufficient communication. So to ensure
everything is crystal clear I've written a blog post and a kind of
"manifesto" to describe why this is happening and how XT plans to be
different from Core (assuming adoption, of course).
It makes no attempt to be neutral: this explains things from our point of view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is no
longer serving the interests of Bitcoin users, come join us. We don't bite.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

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

[Ken Friece via bitcoin-dev]

Let's start with the definition of a conflict of interest before we go any
further:
A *conflict of interest* (COI) is a situation in which a person or
organization is involved in multiple interests (financial, emotional, or
otherwise), one of which could possibly corrupt the motivation of the
individual or organization.

Just because a conflict of interest exists does not necessarily mean the
individual with a conflict of interest has engaged in any wrongdoing. They
could be a saint. However, to not even be able to acknowledge that such a
conflict of interest exists when debating such a serious issue as the
bitcoin blocksize is incredibly naive.

Post by Mark Friedenbach via bitcoin-dev
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.
The Lightning Network effort at Blockstream is purposefully structured to
avoid any conflict of interest. ALL code related to lightning is available
on Github. There is absolutely nothing that we are holding back, and the
protocol itself is entirely p2p. There is no privileged entity, Blockstream
or otherwise.
On Sat, Aug 15, 2015 at 4:07 PM, Eric Lombrozo via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev
Please take the lightning 101 discussion to another thread.
The main point I was trying to make was that Mike is clearly
misrepresenting the views of a great number of people who have deep,
intimate knowledge of how things work and are almost certainly not
primarily motivated by their own potential for profits.
On Aug 15, 2015, at 4:04 PM, Ken Friece via bitcoin-dev <
Being an early hub provider would be an obvious place to start
capitalizing on lightning. Early lightning adopters would be in the best
position to do this.
Long term, Bitcoin needs to scale the blockchain in a reasonable manner
and implement things like lightning.
Limiting the blocksize is a blatant conflict of interest because it
creates artificial demand for lightning that would not otherwise exist if
the blockchain scaled in a reasonable manner.

Post by Mark Friedenbach via bitcoin-dev
I would like very much to know how it is that we're supposed to be
making money off of lightning, and therefore how it represents a conflict
of interest. Apparently there is tons of money to be made in releasing
open-source protocols! I would hate to miss out on that.
We are working on lightning because Mike of all people said,
essentially, " if you're so fond of micro payment channels, why aren't you
working on them?" And he was right! So we looked around and found the best
proposal and funded it.
On Aug 15, 2015 3:28 PM, "Ken Friece via bitcoin-dev" <

Post by Ken Friece via bitcoin-dev
I know full well who works for Blockstream and I know you're not one of
those folks. The Blockstream core devs are very vocal against a reasonable
blocksize increase (17% growth per year in Pieter's BIP is not what I
consider reasonable because it doesn't come close to keeping with
technological increases). I think we can both agree that more on-chain
space means less demand for lightning, and vice versa, which is a blatant
conflict of interest.
I'm also trying to figure out how things like lightning are not
competing directly with miners for fees. More off-chain transactions means
less blockchain demand, which would lower on-chain fees. I'm not sure what
is controversial about that statement.
The lightning network concept is actually a brilliant way to take fees
away from miners without having to make any investment at all in SSH-256
ASIC mining hardware.

On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
What are you so afraid of, Eric? If Mike's fork is successful,
consensus is reached around larger blocks. If it is rejected, the status
quo will remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS,
is the only thing that matters, and those that go against network consensus
will be severely punished with complete loss of income.
I fully agree that core developers are not the only people who should
have a say in this. But again, we’re not talking about merely forking some
open source project - we’re talking about forking a ledger representing
real assets that real people are holding
and I think it’s fair to say that
the risk of permanent ledger forks far outweighs whatever benefits any
change in the protocol might bring. And this would be true even if there
were unanimous agreement that the change is good (which there clearly IS
NOT in this case) but the deployment mechanism could still break things.
If anything we should attempt a hard fork with a less contentious
change first, just to test deployability.
I'm not sure who appointed the core devs some sort of Bitcoin Gods
that can hold up any change that they happen to disagree with. It seems
like the core devs are scared to death that the bitcoin network may change
without their blessing, so they go on and on about how terrible hard forks
are. Hard forks are the only way to keep core devs in check.
Again, let’s figure out a hard fork mechanism and test it with a far
less contentious change first
Despite significant past technical bitcoin achievements, two of the
most vocal opponents to a reasonable blocksize increase work for a company
(Blockstream) that stands to profit directly from artificially limiting the
blocksize. The whole situation reeks. Because of such a blatant conflict of
interest, the ethical thing to do would be for them to either resign from
Blockstream or immediately withdraw themselves from the blocksize debate.
This is the type of stuff that I hoped would end with Bitcoin, but alas, I
guess human nature never changes.
For the record, I do not work for Blockstream. Neither do a bunch of
other people who have published a number of concerns. Very few of the
concerns I’ve seen from the technical community seem to be motivated
primarily by profit motives.
It should also be pointed out that *not* making drastic changes is the
default consensus policy
and the burden of justifying a change falls on
those who want to make the change. Again, the risk of permanent ledger
forks far outweighs whatever benefits protocol changes might bring.
Personally, I think miners should give Bitcoin XT a serious look.
Miners need to realize that they are in direct competition with the
lightning network and sidechains for fees. Miners, ask yourselves if you
think you'll earn more fees with 1 MB blocks and more off-chain
transactions or with 8 MB blocks and more on-chain transactions

Miners are NOT in direct competition with the lightning network and
sidechains - these claims are patently false. I recommend you take a look
at these ideas and understand them a little better before trying to make
any such claims. Again, I do not work for Blockstream
and my agenda in this
post is not to promote either of these ideas
but with all due respect, I do
not think you properly understand them at all.
The longer this debate drags on, the more I agree with BIP 100 and
Jeff Garzik because the core devs are already being influenced by outside
forces and should not have complete control of the blocksize. It's also
interesting to note that most of the mining hashpower is already voting for
8MB blocks BIP100 style.
I don’t think the concern here is so much that some people want to
increase block size. It’s the *way* in which this change is being pushed
that is deeply problematic.
On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev
You deeply disappoint me, Mike.
Not only do you misrepresent many cogent, well thought out positions
from a great number of people who have published and posted a number of
articles detailing an explaining in-depth technical concerns
you also seem
to fancy yourself more capable of reading into the intentions of someone
who disappeared from the scene years ago, before we even were fully aware
of many things we now know that bring the original “plan” into question.
I ask of you, as a civilized human being, to stop doing this divisive
crap. Despite your protestations to the contrary, YOU are the one who is
proposing a radical departure from the direction of the project. Also, as
several of us have clearly stated before, equating the fork of an open
source project with a fork of a cryptoledger is completely bogus - there’s
a lot of other people’s money at stake. This isn’t a democracy - consensus
is all or nothing. The fact that a good number of the people most
intimately familiar with the inner workings of Satoshi’s invention do not
believe doing this is a good idea should give you pause.
Please stop using Bitcoin as your own political football
for the sake
of Bitcoin
and for your own sake. Despite your obvious technical abilities
(and I sincerely do believe you have them) you are discrediting yourself
and hurting your own reputation.
- Eric
On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <
Hello,
As promised, we have released Bitcoin XT 0.11A which includes the
bigger blocks patch set. You can get it from
https://bitcoinxt.software/
I feel sad that it's come to this, but there is no other way. The
Bitcoin Core project has drifted so far from the principles myself and many
others feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is
not the first and won't be the last project to go through this. Often in
forks, people say there was insufficient communication. So to ensure
everything is crystal clear I've written a blog post and a kind of
"manifesto" to describe why this is happening and how XT plans to be
different from Core (assuming adoption, of course).
It makes no attempt to be neutral: this explains things from our point of view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is
no longer serving the interests of Bitcoin users, come join us. We don't
bite.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

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

[Milly Bitcoin via bitcoin-dev]

Post by Mark Friedenbach via bitcoin-dev
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
indicate that somehow conflicts of interest don't exist with the
developers or that the developers are somehow above everyone else. The
fact is the developers on this list discuss conflicts of interest all
the time as it relates to things like mining. Conflicts of interest are
going to be a regular part of Bitcoin development so you should start
getting used it because it is only going to increase as the value increases.

It is your messages attacking people who raise legitimate issues that is
poisonous. It tries to prevent discussions of the risks associated with
the code development. It creates an atmosphere where people are
blackballed if they discuss these issues. This is what happens in
religions all the time and it is time to start treating Bitcoin like the
technology that it is rather than some cult religion.

For all I know is that a hard fork controversy is going to cause the
price to drop temporarily so for all I know this is a scheme to buy some
cheap coins just like when hackers used to attack exchanges and
bitcointalk at the same time to get the price to drop. (I don't think
it is a scheme to do that but such a scheme is certainly possible in the
future and things like that should be expected to happen).

Russ

[Mike Hearn via bitcoin-dev]

Hi Eric,

Sorry you feel that way. I devoted a big part of the article to trying to
fairly represent the top 3 arguments made, but ultimately I can't link to a
clear statement of what Bitcoin Core thinks because there isn't one. Some
people think the block size should increase, but not now, or not by much.
Others think it should stay at 1mb forever, others think everyone should
migrate to Lightning, people who are actually *implementing* Lightning
think it's not a replacement for an increase ..... I think one or two
people even suggested shrinking the block size!

So I've done my best to sum up the top arguments. If you think I've done a
bad job, well, get writing and lay it out how you see it!

I don't think the position of "Bitcoin is open source but touching THESE
parts is completely bogus" is reasonable. Bitcoin is open source or it
isn't. You can't claim to be decentralised and open source, but then only
have 5 people who are allowed to edit the most important parts. That's
actually worse than central banking!

This isn’t a democracy - consensus is all or nothing.
This idea is one of the incorrect beliefs that will hopefully be disproven
in the coming months. Bitcoin cannot possibly be "all or nothing" because
as I pointed out before, that would give people a strong financial
incentive to try and hold the entire community to ransom: "I have 1
terahash/sec of mining power. Pay me 1000 BTC or I'll never agree to the
next upgrade".

Or indeed, me and Gavin could play the same trick.

[Anthony Towns via bitcoin-dev]

On 16 August 2015 at 15:49, Mike Hearn via bitcoin-dev <

Post by Mike Hearn via bitcoin-dev
Sorry you feel that way. I devoted a big part of the article to trying to
fairly represent the top 3 arguments made, but ultimately I can't link to a
clear statement of what Bitcoin Core thinks because there isn't one. Some
people think the block size should increase, but not now, or not by much.
Others think it should stay at 1mb forever, others think everyone should
migrate to Lightning, people who are actually *implementing* Lightning
think it's not a replacement for an increase ..... I think one or two
people even suggested shrinking the block size!

​That's been really unclear to me. Personally, I'd love to see a vote from
the core and XT developers on:

- what should the block size soft limit be in 12 months (min and max)
- what should the block size hard limit be in 12 months (min and max)

- at what rate should the hard limit grow over the next 10 years​ (min and
max)

- what mechanism should be used to update the soft limit
(manual code change, time based, blockchain history, something else)
​ - what me​chanism should be used to update the hard limit
(hard fork code change, time based, blockchain history, something else)

Bonus:

​ - what should the
​transaction ​
fee level be in 12 months (after the reward halves)?​
- what's a good measure of "(de)centralisation" and what value should
everyone aim for in 12 months?

As an interested newbie, I can't actually tell what most people think the
answers to most of those questions are. FWIW, mine would be:

- soft limit in 12 months: 1MB-4MB
- hard limit in 12 months: 2MB-20MB
- hard limit grows at 17-40% a year (and should be >4x average txn volume)
- update the soft limit by code changes or blockchain history
- update the hardlimit by (1) fee level, (2) miner vote, (3) hard coded
time updates at a conservative (low) rate, (4) hard fork every couple of
years
- transaction fees should in 12months should be lower per kB than today's
defaults, say 20%-50% of today's defaults in USD
- number of bitcoin nodes, should be 20% higher in 12 months than it is now

​Cheers,
aj

[Tamas Blummer via bitcoin-dev]

Being a bitcoin software developer an entrepreneur for years I learned that success is not a direct consequence of technology and is not inevitable.
BitcoinXT manifesto (https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto) should resonate with many fellow entrepreneurs.
I applaud Mike and Gavin for creating that choice for us.

Tamas Blummer

[Levin Keller via bitcoin-dev]

Hear hear Tamas,

I agree. I personally prefer to use the "only-bigblocks" branch and not XT
with all its features - but as I am not mining that doesn't mean much
anyhow. Nevertheless I am happy to be able to publicly proclaim my opinion
that the block size should be raised asap.

Thank you for going ahead Mike

Levin

Post by Tamas Blummer via bitcoin-dev
Being a bitcoin software developer an entrepreneur for years I learned
that success is not a direct consequence of technology and is not
inevitable.
BitcoinXT manifesto (
https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto) should resonate
with many fellow entrepreneurs.
I applaud Mike and Gavin for creating that choice for us.
Tamas Blummer
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Adam Back via bitcoin-dev]

Hi Tamas

Do you find BIP 101, BIP 102, BIP 103 and the flexcap proposal
deserving of equal consideration? Just curious because of your post.

Will you be interested to participate in the BIP review process and
perhaps attend the workshop on Bitcoin scaling announced here
recently?

Adam

On 16 August 2015 at 17:07, Tamas Blummer via bitcoin-dev

Post by Tamas Blummer via bitcoin-dev
Being a bitcoin software developer an entrepreneur for years I learned that success is not a direct consequence of technology and is not inevitable.
BitcoinXT manifesto (https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto) should resonate with many fellow entrepreneurs.
I applaud Mike and Gavin for creating that choice for us.
Tamas Blummer
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Tamas Blummer via bitcoin-dev]

Hi Adam,

I welcomed XT for its declared focus on usability with current means.
I think there is also more room for non-consenus relevant P2P protocol flavors than a single code base can accommodate.
XT is also as Jeff just tweeted a relief valve.

It became important, that Bitcoin is able to evolve even if there are conflicting educated opinions.
If a review process serves decision making, then I’d be glad to participate.

Tamas Blummer

Post by Adam Back via bitcoin-dev
Hi Tamas
Do you find BIP 101, BIP 102, BIP 103 and the flexcap proposal
deserving of equal consideration? Just curious because of your post.
Will you be interested to participate in the BIP review process and
perhaps attend the workshop on Bitcoin scaling announced here
recently?
Adam
On 16 August 2015 at 17:07, Tamas Blummer via bitcoin-dev

Post by Tamas Blummer via bitcoin-dev
Being a bitcoin software developer an entrepreneur for years I learned that success is not a direct consequence of technology and is not inevitable.
BitcoinXT manifesto (https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto) should resonate with many fellow entrepreneurs.
I applaud Mike and Gavin for creating that choice for us.
Tamas Blummer
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[muyuubyou via bitcoin-dev]

I posted this to /r/BitcoinMarkets but I thought I might post it here as
well.

---
Currently 0 mined blocks have voted for XT.

If it ever gets close to even 50%, many things can happen that would
reshape the game completely.

For instance:

- Core could start boycotting XT by not relying to them and/or not relying
from them.

- Core could appropriate the version string of XT, making it impossible to
know how much they are progressing and a losing bet to actually execute the
fork.

This kind of node war if the factions were sizeable would make it very
risky to transact at all - balances in new addresses could end up
vanishing. Usability of the system would plummet.

Note that any disagreement between the network and the biggest economic
actors - mainly the exchanges at this point, "wallet services" maybe -
would mean BTC plummets. Hard. And so would confidence.

It's a risky game to play.
---

PS: I consider this attempt at takeover about as foul as it gets. The
equivalent of repeating a referendum until a yes is obtained: the
reasonable reaction to this is actively blocking said "referendum". There
was a fair play alternative which is voting through coinbase scriptSig like
plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment.
Once a majority is obtained in this way, devs have to react or if they
don't then this sort of foul play would be justified. But this wasn't the
case.

-----
為せば成る

[Andrew LeCody via bitcoin-dev]

Post by muyuubyou via bitcoin-dev
PS: I consider this attempt at takeover about as foul as it gets. The

equivalent of repeating a referendum until a yes is obtained: the
reasonable reaction to this is actively blocking said "referendum". There
was a fair play alternative which is voting through coinbase scriptSig like
plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment.
Once a majority is obtained in this way, devs have to react or if they
don't then this sort of foul play would be justified. But this wasn't the
case.

I fail to see how voting with version numbers is different than voting with
coinbase scriptSig. Other than the fact that the voting XT is doing is
formally defined instead of ad-hoc.

On Sat, Aug 15, 2015 at 5:40 PM muyuubyou via bitcoin-dev <

Post by muyuubyou via bitcoin-dev
I posted this to /r/BitcoinMarkets but I thought I might post it here as
well.
---
Currently 0 mined blocks have voted for XT.
If it ever gets close to even 50%, many things can happen that would
reshape the game completely.
- Core could start boycotting XT by not relying to them and/or not relying
from them.
- Core could appropriate the version string of XT, making it impossible to
know how much they are progressing and a losing bet to actually execute the
fork.
This kind of node war if the factions were sizeable would make it very
risky to transact at all - balances in new addresses could end up
vanishing. Usability of the system would plummet.
Note that any disagreement between the network and the biggest economic
actors - mainly the exchanges at this point, "wallet services" maybe -
would mean BTC plummets. Hard. And so would confidence.
It's a risky game to play.
---
PS: I consider this attempt at takeover about as foul as it gets. The
equivalent of repeating a referendum until a yes is obtained: the
reasonable reaction to this is actively blocking said "referendum". There
was a fair play alternative which is voting through coinbase scriptSig like
plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment.
Once a majority is obtained in this way, devs have to react or if they
don't then this sort of foul play would be justified. But this wasn't the
case.
-----
為せば成る
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Cameron Garnham via bitcoin-dev]

I think that it is important to note that Bitcoin XT faces a natural
uphill battle.

Since it is possible to setup atomic inter-fork coin trades. I do not
see how Bitcoin XT could possibly win if Satoshi decides to sell 10000
XTBTC for BTC everyday for the first 100 days after the fork.

In many ways Satoshi gets to decide the winning fork just by his huge
economic investment in Bitcoin.


Here is some simple game-theory for non-consensus forks:

1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
string.

2. Encourage all miners to false vote for the Bitcoin XT fork.

- Now people have no-idea what % of the economy Bitcoin XT holds. -
Making it impossible for people to put economic faith behind Bitcoin XT.

3. Setup good Atomic Swap markets.

4. Setup a fork of Bitcoin XT that allows people to easily make a
transaction only on the XT fork (while leaving the original BTC coins
untouched).


This means that the Bitcoin XT fork will be born per-mature. Probably
with only a small % of hashing power behind it (contrary to the almost
100% that falsely claim to support it). It will be embarrassing that for
the goal of larger blocks, XT instead has blocks (before re-adjustment)
every 2h.


The price for XTBTC coins will plummet, Satoshi progressively dumping
his 1M stash over a year or so will make sure that it doesn't recover
either.


I cannot see how Bitcoin XT is but-not in a extremely weak position from
game theory.

I'm sure smarter people than I could come up with even more ways to
disrupt non-consensus forks.

Cam.

Post by muyuubyou via bitcoin-dev
I posted this to /r/BitcoinMarkets but I thought I might post it here as
well.
---
Currently 0 mined blocks have voted for XT.
If it ever gets close to even 50%, many things can happen that would
reshape the game completely.
- Core could start boycotting XT by not relying to them and/or not relying
from them.
- Core could appropriate the version string of XT, making it impossible to
know how much they are progressing and a losing bet to actually execute the
fork.
This kind of node war if the factions were sizeable would make it very
risky to transact at all - balances in new addresses could end up
vanishing. Usability of the system would plummet.
Note that any disagreement between the network and the biggest economic
actors - mainly the exchanges at this point, "wallet services" maybe -
would mean BTC plummets. Hard. And so would confidence.
It's a risky game to play.
---
PS: I consider this attempt at takeover about as foul as it gets. The
equivalent of repeating a referendum until a yes is obtained: the
reasonable reaction to this is actively blocking said "referendum". There
was a fair play alternative which is voting through coinbase scriptSig like
plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment.
Once a majority is obtained in this way, devs have to react or if they
don't then this sort of foul play would be justified. But this wasn't the
case.
-----
為せば成る
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Andrew LeCody via bitcoin-dev]

Cam, your scenario makes no sense.

Post by Cameron Garnham via bitcoin-dev
1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version

string.

Post by Cameron Garnham via bitcoin-dev
2. Encourage all miners to false vote for the Bitcoin XT fork.

This would obliterate any confidence in Bitcoin Core. I seriously doubt
anyone would actually be ok with a pull request implementing this.

Post by Cameron Garnham via bitcoin-dev
3. Setup good Atomic Swap markets.

Who would bother writing this code, let alone trading on these markets?

Post by Cameron Garnham via bitcoin-dev
4. Setup a fork of Bitcoin XT that allows people to easily make a

transaction only on the XT fork (while leaving the original BTC coins
untouched).

I doubt this is even possible.

On Sun, Aug 16, 2015 at 6:02 PM Cameron Garnham via bitcoin-dev <

Post by Cameron Garnham via bitcoin-dev
I think that it is important to note that Bitcoin XT faces a natural
uphill battle.
Since it is possible to setup atomic inter-fork coin trades. I do not
see how Bitcoin XT could possibly win if Satoshi decides to sell 10000
XTBTC for BTC everyday for the first 100 days after the fork.
In many ways Satoshi gets to decide the winning fork just by his huge
economic investment in Bitcoin.
1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
string.
2. Encourage all miners to false vote for the Bitcoin XT fork.
- Now people have no-idea what % of the economy Bitcoin XT holds. -
Making it impossible for people to put economic faith behind Bitcoin XT.
3. Setup good Atomic Swap markets.
4. Setup a fork of Bitcoin XT that allows people to easily make a
transaction only on the XT fork (while leaving the original BTC coins
untouched).
This means that the Bitcoin XT fork will be born per-mature. Probably
with only a small % of hashing power behind it (contrary to the almost
100% that falsely claim to support it). It will be embarrassing that for
the goal of larger blocks, XT instead has blocks (before re-adjustment)
every 2h.
The price for XTBTC coins will plummet, Satoshi progressively dumping
his 1M stash over a year or so will make sure that it doesn't recover
either.
I cannot see how Bitcoin XT is but-not in a extremely weak position from
game theory.
I'm sure smarter people than I could come up with even more ways to
disrupt non-consensus forks.
Cam.

Post by muyuubyou via bitcoin-dev
I posted this to /r/BitcoinMarkets but I thought I might post it here as
well.
---
Currently 0 mined blocks have voted for XT.
If it ever gets close to even 50%, many things can happen that would
reshape the game completely.
- Core could start boycotting XT by not relying to them and/or not

relying

Post by muyuubyou via bitcoin-dev
from them.
- Core could appropriate the version string of XT, making it impossible

to

Post by muyuubyou via bitcoin-dev
know how much they are progressing and a losing bet to actually execute

the

Post by muyuubyou via bitcoin-dev
fork.
This kind of node war if the factions were sizeable would make it very
risky to transact at all - balances in new addresses could end up
vanishing. Usability of the system would plummet.
Note that any disagreement between the network and the biggest economic
actors - mainly the exchanges at this point, "wallet services" maybe -
would mean BTC plummets. Hard. And so would confidence.
It's a risky game to play.
---
PS: I consider this attempt at takeover about as foul as it gets. The
equivalent of repeating a referendum until a yes is obtained: the
reasonable reaction to this is actively blocking said "referendum". There
was a fair play alternative which is voting through coinbase scriptSig

like

Post by muyuubyou via bitcoin-dev
plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment.
Once a majority is obtained in this way, devs have to react or if they
don't then this sort of foul play would be justified. But this wasn't the
case.
-----
為せば成る
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Cameron Garnham via bitcoin-dev]

Since it was a game theory analysis. I will not address your other comments.

Post by Cameron Garnham via bitcoin-dev

Post by Cameron Garnham via bitcoin-dev
4. Setup a fork of Bitcoin XT that allows people to easily make a

transaction only on the XT fork (while leaving the original BTC coins
untouched).
I doubt this is even possible.

Trivial.

There are a few ways: here is my favorite (for the moment).

1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet 'BitcoinXT'

2. Let these spam tx be in BitcoinXT, however not Bitcoin (easily done).

3. Let the forked XT client includes a unspent dust output with any
transaction. Let the this client create 100 dust outputs for other
people to use in the same transaction.

This transaction will only be possible to confirm with Bitcoin XT. -
Leaving your Bitcoin coins untouched.

I particularly like this approach, as it is ironic as the spam is more
cheaply done with larger blocks.

Cam.


A quick political note:
https://en.wikipedia.org/wiki/Abstentionism

Hard forks are not something that is a democratic process. Thus
frustrating a false-democratic process is completely legitimate.

[Peter Todd via bitcoin-dev]

Post by Cameron Garnham via bitcoin-dev
There are a few ways: here is my favorite (for the moment).
1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet 'BitcoinXT'

Even more direct: use coinbase outputs of XT blocks to create those outputs, as they can't by definition be on the Bitcoin chain.

If you can't get those, using coinbase outputs of Bitcoin blocks to create "definitely Bitcoin-only" outputs, and then spend the inputs to those transactions again on the XT chain. This isn't quite as good, as a big reorg on the XT chain could in theory spend them, but it's a close second.

[Andrew LeCody via bitcoin-dev]

Wouldn't that require a fork that lasts for more than 100 blocks?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev <

Post by Cameron Garnham via bitcoin-dev
There are a few ways: here is my favorite (for the moment).
1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet 'BitcoinXT'

Even more direct: use coinbase outputs of XT blocks to create those
outputs, as they can't by definition be on the Bitcoin chain.
If you can't get those, using coinbase outputs of Bitcoin blocks to create
"definitely Bitcoin-only" outputs, and then spend the inputs to those
transactions again on the XT chain. This isn't quite as good, as a big
reorg on the XT chain could in theory spend them, but it's a close second.
-----BEGIN PGP SIGNATURE-----
iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV0YIS
AAoJEMCF8hzn9Lnc47AH/R9EaGaa0xmD7qBODGUwX3SsDde7DMgO4t8X5GQ9uoaq
qcjdnnvdeXjy5S39QdZFJjlH5bGn+BJy2wIxn0lMciKhEGIFOGeCUsMYEbgnOc03
cLuyYpxdfXe4Amoxf2mqADgBqkAckf4cX6bMm3XXg+v3XAby2llydIGIydTwGWYq
2KwXl9U9zm7UV8b5tJ7WmItCAcZAvTcSoX5SerOmPjjrmLtPTHThj8SfLTGAoWfT
EXsSGkDBJ/9rJMms56FjciWsXHlB9pYK0a1sxh88PJluebqh99imDisJvATCVp2Z
kZX1keZ1nyfG45jibgt6dlY97wU0n919SmQz0Tg6g90=
=OD56
-----END PGP SIGNATURE-----

[Eric Lombrozo via bitcoin-dev]

Or can’t you create a transaction that’s still within the op count and sig ops limits but is larger than 1MB?

Post by Andrew LeCody via bitcoin-dev
Wouldn't that require a fork that lasts for more than 100 blocks?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev <

Post by Cameron Garnham via bitcoin-dev
There are a few ways: here is my favorite (for the moment).
1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet 'BitcoinXT'

Even more direct: use coinbase outputs of XT blocks to create those
outputs, as they can't by definition be on the Bitcoin chain.
If you can't get those, using coinbase outputs of Bitcoin blocks to create
"definitely Bitcoin-only" outputs, and then spend the inputs to those
transactions again on the XT chain. This isn't quite as good, as a big
reorg on the XT chain could in theory spend them, but it's a close second.
-----BEGIN PGP SIGNATURE-----
iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV0YIS
AAoJEMCF8hzn9Lnc47AH/R9EaGaa0xmD7qBODGUwX3SsDde7DMgO4t8X5GQ9uoaq
qcjdnnvdeXjy5S39QdZFJjlH5bGn+BJy2wIxn0lMciKhEGIFOGeCUsMYEbgnOc03
cLuyYpxdfXe4Amoxf2mqADgBqkAckf4cX6bMm3XXg+v3XAby2llydIGIydTwGWYq
2KwXl9U9zm7UV8b5tJ7WmItCAcZAvTcSoX5SerOmPjjrmLtPTHThj8SfLTGAoWfT
EXsSGkDBJ/9rJMms56FjciWsXHlB9pYK0a1sxh88PJluebqh99imDisJvATCVp2Z
kZX1keZ1nyfG45jibgt6dlY97wU0n919SmQz0Tg6g90=
=OD56
-----END PGP SIGNATURE-----

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

[Jorge Timón via bitcoin-dev]

On Mon, Aug 17, 2015 at 1:02 AM, Cameron Garnham via bitcoin-dev

Post by Cameron Garnham via bitcoin-dev
I think that it is important to note that Bitcoin XT faces a natural
uphill battle.
Since it is possible to setup atomic inter-fork coin trades. I do not
see how Bitcoin XT could possibly win if Satoshi decides to sell 10000
XTBTC for BTC everyday for the first 100 days after the fork.
In many ways Satoshi gets to decide the winning fork just by his huge
economic investment in Bitcoin.
1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
string.
2. Encourage all miners to false vote for the Bitcoin XT fork.
- Now people have no-idea what % of the economy Bitcoin XT holds. -
Making it impossible for people to put economic faith behind Bitcoin XT.
3. Setup good Atomic Swap markets.
[...]
The price for XTBTC coins will plummet, Satoshi progressively dumping
his 1M stash over a year or it so will make sure that it doesn't recover
either.

Some XTBTC advocates may sell all their BTC for XTBTC and viceversa.
But I'm afraid that what most currency speculators (thus most Bitcoin
holders) will do is just sell both all their BTC and XTBTC for fiat,
and wait for things to settle before deciding whether to re-enter or
not.
This could result in both currencies' prices going down to 1 usd cent,
nobody knows.

Post by Cameron Garnham via bitcoin-dev
I cannot see how Bitcoin XT is but-not in a extremely weak position from
game theory.

Unfortunately it also puts Bitcoin core in an extremely weaker
position than it was before the Schism hardfork.
Even if XT fails in making blocks bigger, it may destroy Bitcoin.
That's probably not the goal of Bitcoin XT, but I don't think Andresen
and Hearn fully undesrtand the risks of a Schism hardfork (not to
mention their "followers" in the interwebs).

Since we want to discard the assumption that Hearn and Andresen want
to make Bitcoin centralized or destroy it, it's reasonable to conclude
that have serious misunderstandings on how the global consensus works.
This is consistent with some of their strong positions on Bitcoin Core
policy defaults (like maintaining the first seen spending-conflict
replacement policy [the dumbest possible one after "last seen"]
forever).

On Mon, Aug 17, 2015 at 2:33 PM, Eric Lombrozo via bitcoin-dev

Post by Cameron Garnham via bitcoin-dev
Or can’t you create a transaction that’s still within the op count and sig ops limits but is larger than 1MB?

Yes, it seems the simplest way to permanently separate your BTC from
your XTBTC is to move them all in transactions bigger than 1MB. You
may need too many outputs to increase the size (thus also hurting the
utxo size in Bitcoin XT), but that's just a side effect.

[s7r via bitcoin-dev]

Hello Jorge, Eric,

With all this noise on the -dev mail list I had to implement application
level filters so I can treat with priority posts from certain people,
you are on that list. While I agree with your arguments, I think it is
_very_ important to highlight some things. I am neither for the
blocksize increase neither against it, because plain and simple I don't
have enough arguments to take some definitive decision on this topic.
What I am angry about is spreading FUD that a fork could kill Bitcoin
and what we are experiencing now is somehow terrible.

1. Bitcoin XT is not necessarily an attack over Bitcoin and will not
split it into 2 different coins. It is the result of an open source free
system which lacks centralization. It is just at early stage, it could
have thousands for forks (or fork attempts) during its life.

2. We have no proof that Mike Hearn and Gavin Andresen are trying to do
something bad to Bitcoin. So far everything they have done is (or should
be) allowed. They have forked an open source software and implemented a
voting system for a consensus rule change - doesn't sound like they are
committing a crime here (either legally or morally). If they are
qualified enough to maintain the software, or if the decision is
technically correct or not is another story, and it should only matter
to whoever uses / wants to use -XT.

3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
just by 2 people forking the software and submitting a consensus rule to
a vote, it means Bitcoin is dead already and it should be worthless! We
can't go around and panic every time somebody forks Bitcoin and tries to
change something - this should be allowed by the nature of its license.
If tomorrow 5 more people fork 5 different software implementing the
bitcoin protocol and submit 5 different new consensus rules to a vote,
then what? We should all sell so the price will drop to 1 cent, because
it is somehow not good enough, not stable enough?

I can fork tomorrow Bitcoin Core to a Bitcoin-XYZ software which at some
block in the future spends all the longest dusted coins to me, out of
which I give away 50% to the miners (so the hashing power will have
incentive to use my fork).

Can they do it? YES
Will they do it? NO
Should the world care about this? NO

It's as simple as that. We cannot continue to panic that "Bitcoin as a
project" is at threat because somebody forked it.

4. By having a software fork and consensus rule submitted to vote we
actually prove how open Bitcoin is, and how there is lack of control
over it from all parties (developers, miners, engineers on the mail
list). This is reason to increase Bitcoin's value! It is a feature, not
a flaw!


It's very important for everyone in the ecosystem to understand:

- yes, Bitcoin is open source, even you can fork it tomorrow if you want
and you think enough users might follow you.

- no, it's not a requirement for 100% of the nodes in the network to be
running Core, or -XT or other implementation. The more we have, the better.

- yes, there is absolutely no authority in Bitcoin - this is what lead
to this dispute in the first place. This is the truly decentralized
nature of the software, not important if we have 10.000 full nodes or
1000 full nodes.

- no, Bitcoin won't split / die or whatever because of this fork.
Regardless what it happens, if XT will reach the threshold or not,
Bitcoin will go on just because it has some unique advantages and has no
competitor from some points of view.

- Bitcoin by its design has many many advantages, but also the
limitation that it relies on majority being honest / doing the right
thing! This is just the way it is, and the benefits it is offering
heavily win over this fundamental limitation.

Post by Jorge Timón via bitcoin-dev
On Mon, Aug 17, 2015 at 1:02 AM, Cameron Garnham via bitcoin-dev

Post by Cameron Garnham via bitcoin-dev
I think that it is important to note that Bitcoin XT faces a natural
uphill battle.
Since it is possible to setup atomic inter-fork coin trades. I do not
see how Bitcoin XT could possibly win if Satoshi decides to sell 10000
XTBTC for BTC everyday for the first 100 days after the fork.
In many ways Satoshi gets to decide the winning fork just by his huge
economic investment in Bitcoin.
1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
string.
2. Encourage all miners to false vote for the Bitcoin XT fork.
- Now people have no-idea what % of the economy Bitcoin XT holds. -
Making it impossible for people to put economic faith behind Bitcoin XT.
3. Setup good Atomic Swap markets.
[...]
The price for XTBTC coins will plummet, Satoshi progressively dumping
his 1M stash over a year or it so will make sure that it doesn't recover
either.

Some XTBTC advocates may sell all their BTC for XTBTC and viceversa.
But I'm afraid that what most currency speculators (thus most Bitcoin
holders) will do is just sell both all their BTC and XTBTC for fiat,
and wait for things to settle before deciding whether to re-enter or
not.
This could result in both currencies' prices going down to 1 usd cent,
nobody knows.

Post by Cameron Garnham via bitcoin-dev
I cannot see how Bitcoin XT is but-not in a extremely weak position from
game theory.

Unfortunately it also puts Bitcoin core in an extremely weaker
position than it was before the Schism hardfork.
Even if XT fails in making blocks bigger, it may destroy Bitcoin.
That's probably not the goal of Bitcoin XT, but I don't think Andresen
and Hearn fully undesrtand the risks of a Schism hardfork (not to
mention their "followers" in the interwebs).
Since we want to discard the assumption that Hearn and Andresen want
to make Bitcoin centralized or destroy it, it's reasonable to conclude
that have serious misunderstandings on how the global consensus works.
This is consistent with some of their strong positions on Bitcoin Core
policy defaults (like maintaining the first seen spending-conflict
replacement policy [the dumbest possible one after "last seen"]
forever).
On Mon, Aug 17, 2015 at 2:33 PM, Eric Lombrozo via bitcoin-dev

Post by Cameron Garnham via bitcoin-dev
Or can’t you create a transaction that’s still within the op count and sig ops limits but is larger than 1MB?

Yes, it seems the simplest way to permanently separate your BTC from
your XTBTC is to move them all in transactions bigger than 1MB. You
may need too many outputs to increase the size (thus also hurting the
utxo size in Bitcoin XT), but that's just a side effect.

[Jorge Timón via bitcoin-dev]

Post by s7r via bitcoin-dev
Hello Jorge, Eric,
With all this noise on the -dev mail list I had to implement application
level filters so I can treat with priority posts from certain people,
you are on that list. While I agree with your arguments, I think it is
_very_ important to highlight some things. I am neither for the
blocksize increase neither against it, because plain and simple I don't
have enough arguments to take some definitive decision on this topic.

I think everyone is in that position (we just don't have enough data
about the proposed sizes) or it's just too optimistic.

Post by s7r via bitcoin-dev
What I am angry about is spreading FUD that a fork could kill Bitcoin
and what we are experiencing now is somehow terrible.
1. Bitcoin XT is not necessarily an attack over Bitcoin and will not
split it into 2 different coins. It is the result of an open source free
system which lacks centralization. It is just at early stage, it could
have thousands for forks (or fork attempts) during its life.

Bitcoin XT is just a software fork and nobody seem to have a problem
with that (as repeated in other threads), people are worried about the
way bip101 is going to be attempted to be deployed using Bitcoin XT.
We already have more than 5000 software forks and that's totally fine.

A Schism fork may not kill Bitcoin but it will certainly create 2
different coins.
The claim that "there will be a winner and everybody will just move
there" is incredibly naive and uninformative.
Many people will sell their xtbtc and reject the hardfork
independently of its support by miners.
Nobody knows what the result will be, but both currencies' prices
dropping near zero is certainly a possibility that Gavin and Mike are
not aware about or are not informing their followers about.
Here's something a little bit longer about this topic:
https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR137
Note the last part:

"
+This is very disruptive and hopefully will never be needed. But if
+it's needed the best deployment path is just to activate the rule
+changes after certain block height in the future. On the other hand,
+it is healthy decentralization-wise that many independent software
+projects are ready to deploy a schism hardfork.
"

Post by s7r via bitcoin-dev
2. We have no proof that Mike Hearn and Gavin Andresen are trying to do
something bad to Bitcoin. So far everything they have done is (or should
be) allowed. They have forked an open source software and implemented a
voting system for a consensus rule change - doesn't sound like they are
committing a crime here (either legally or morally). If they are
qualified enough to maintain the software, or if the decision is
technically correct or not is another story, and it should only matter
to whoever uses / wants to use -XT.

Again, no problem with the code fork, but the Schism hardfork is very
risky regardless of their intentions.

Post by s7r via bitcoin-dev
3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
just by 2 people forking the software and submitting a consensus rule to
a vote, it means Bitcoin is dead already and it should be worthless! We
can't go around and panic every time somebody forks Bitcoin and tries to
change something - this should be allowed by the nature of its license.
If tomorrow 5 more people fork 5 different software implementing the
bitcoin protocol and submit 5 different new consensus rules to a vote,
then what? We should all sell so the price will drop to 1 cent, because
it is somehow not good enough, not stable enough?

If they don't extensively lobby Bitcoin companies, they don't start a
massive PR campaign labbeling other developers as "obstructionists"
and don't misinform a big part of the Bitcoin users (often using
logical fallacies, intentionally or not), probably those 5 new
currencies will be ignored and nothing bad will happen.
Unfortunately in this case a great division between users is being created.

Post by s7r via bitcoin-dev
I can fork tomorrow Bitcoin Core to a Bitcoin-XYZ software which at some
block in the future spends all the longest dusted coins to me, out of
which I give away 50% to the miners (so the hashing power will have
incentive to use my fork).
Can they do it? YES
Will they do it? NO
Should the world care about this? NO
It's as simple as that. We cannot continue to panic that "Bitcoin as a
project" is at threat because somebody forked it.

Can you please stop conflating "Bitcoin Core as a project" and
"Bitcoin consensus rules".
They are different things and nobody is or can be "in charge" of the
later, face it.

Can you please also stop conflating software fork and
"Schism/controversial/contentious hardfork"? Nobody has anything
against the former and as you point out it is allowed by its free
software license.

Post by s7r via bitcoin-dev
4. By having a software fork and consensus rule submitted to vote we
actually prove how open Bitcoin is, and how there is lack of control
over it from all parties (developers, miners, engineers on the mail
list). This is reason to increase Bitcoin's value! It is a feature, not
a flaw!

Why should miners have a voting power that the rest of the users lack?

Post by s7r via bitcoin-dev
- yes, Bitcoin is open source, even you can fork it tomorrow if you want
and you think enough users might follow you.
- no, it's not a requirement for 100% of the nodes in the network to be
running Core, or -XT or other implementation. The more we have, the better.
- yes, there is absolutely no authority in Bitcoin - this is what lead
to this dispute in the first place. This is the truly decentralized
nature of the software, not important if we have 10.000 full nodes or
1000 full nodes.

All this sounds reasonable.

Post by s7r via bitcoin-dev
- no, Bitcoin won't split / die or whatever because of this fork.
Regardless what it happens, if XT will reach the threshold or not,
Bitcoin will go on just because it has some unique advantages and has no
competitor from some points of view.

But you cannot know this will happen this way!
If the threshold is reached (let's forget about noXT for now), the
remaining miners cannot be forced to adopt bip101.
And users can never be forced to adopt hardforks.
It is possible that 75% of the hashrate moves to the bip101 chain
while 99% of the users remain in the old Bitcoin chain. Or 50/50,
40/60...nobody knows.

Post by s7r via bitcoin-dev
- Bitcoin by its design has many many advantages, but also the
limitation that it relies on majority being honest / doing the right
thing! This is just the way it is, and the benefits it is offering
heavily win over this fundamental limitation.

No, it doesn't rely on that. It just relies on the majority of the
miners not attacking the network for too long (ie the number of
confirmations people are waiting).
If I'm running a full node, I'm not isolated from the network and the
majority of the hashrate is not reorging the chain I am safe no matter
how dishonest the "majority" (whatever that means in this context) is.

[Adam Back via bitcoin-dev]

Wouldnt the experience for SPV nodes be chaotic? If the full nodes
are 50:50 XT and bitcoin core, then SPV clients would connect at
random and because XT and core will diverge immediately after
activation.

Adam


On 19 August 2015 at 15:28, Jorge Timón

Post by Jorge Timón via bitcoin-dev

Post by s7r via bitcoin-dev
Hello Jorge, Eric,
With all this noise on the -dev mail list I had to implement application
level filters so I can treat with priority posts from certain people,
you are on that list. While I agree with your arguments, I think it is
_very_ important to highlight some things. I am neither for the
blocksize increase neither against it, because plain and simple I don't
have enough arguments to take some definitive decision on this topic.

I think everyone is in that position (we just don't have enough data
about the proposed sizes) or it's just too optimistic.

Post by s7r via bitcoin-dev
What I am angry about is spreading FUD that a fork could kill Bitcoin
and what we are experiencing now is somehow terrible.
1. Bitcoin XT is not necessarily an attack over Bitcoin and will not
split it into 2 different coins. It is the result of an open source free
system which lacks centralization. It is just at early stage, it could
have thousands for forks (or fork attempts) during its life.

Bitcoin XT is just a software fork and nobody seem to have a problem
with that (as repeated in other threads), people are worried about the
way bip101 is going to be attempted to be deployed using Bitcoin XT.
We already have more than 5000 software forks and that's totally fine.
A Schism fork may not kill Bitcoin but it will certainly create 2
different coins.
The claim that "there will be a winner and everybody will just move
there" is incredibly naive and uninformative.
Many people will sell their xtbtc and reject the hardfork
independently of its support by miners.
Nobody knows what the result will be, but both currencies' prices
dropping near zero is certainly a possibility that Gavin and Mike are
not aware about or are not informing their followers about.
https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR137
"
+This is very disruptive and hopefully will never be needed. But if
+it's needed the best deployment path is just to activate the rule
+changes after certain block height in the future. On the other hand,
+it is healthy decentralization-wise that many independent software
+projects are ready to deploy a schism hardfork.
"

Post by s7r via bitcoin-dev
2. We have no proof that Mike Hearn and Gavin Andresen are trying to do
something bad to Bitcoin. So far everything they have done is (or should
be) allowed. They have forked an open source software and implemented a
voting system for a consensus rule change - doesn't sound like they are
committing a crime here (either legally or morally). If they are
qualified enough to maintain the software, or if the decision is
technically correct or not is another story, and it should only matter
to whoever uses / wants to use -XT.

Again, no problem with the code fork, but the Schism hardfork is very
risky regardless of their intentions.

Post by s7r via bitcoin-dev
3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
just by 2 people forking the software and submitting a consensus rule to
a vote, it means Bitcoin is dead already and it should be worthless! We
can't go around and panic every time somebody forks Bitcoin and tries to
change something - this should be allowed by the nature of its license.
If tomorrow 5 more people fork 5 different software implementing the
bitcoin protocol and submit 5 different new consensus rules to a vote,
then what? We should all sell so the price will drop to 1 cent, because
it is somehow not good enough, not stable enough?

If they don't extensively lobby Bitcoin companies, they don't start a
massive PR campaign labbeling other developers as "obstructionists"
and don't misinform a big part of the Bitcoin users (often using
logical fallacies, intentionally or not), probably those 5 new
currencies will be ignored and nothing bad will happen.
Unfortunately in this case a great division between users is being created.

Post by s7r via bitcoin-dev
I can fork tomorrow Bitcoin Core to a Bitcoin-XYZ software which at some
block in the future spends all the longest dusted coins to me, out of
which I give away 50% to the miners (so the hashing power will have
incentive to use my fork).
Can they do it? YES
Will they do it? NO
Should the world care about this? NO
It's as simple as that. We cannot continue to panic that "Bitcoin as a
project" is at threat because somebody forked it.

Can you please stop conflating "Bitcoin Core as a project" and
"Bitcoin consensus rules".
They are different things and nobody is or can be "in charge" of the
later, face it.
Can you please also stop conflating software fork and
"Schism/controversial/contentious hardfork"? Nobody has anything
against the former and as you point out it is allowed by its free
software license.

Post by s7r via bitcoin-dev
4. By having a software fork and consensus rule submitted to vote we
actually prove how open Bitcoin is, and how there is lack of control
over it from all parties (developers, miners, engineers on the mail
list). This is reason to increase Bitcoin's value! It is a feature, not
a flaw!

Why should miners have a voting power that the rest of the users lack?

Post by s7r via bitcoin-dev
- yes, Bitcoin is open source, even you can fork it tomorrow if you want
and you think enough users might follow you.
- no, it's not a requirement for 100% of the nodes in the network to be
running Core, or -XT or other implementation. The more we have, the better.
- yes, there is absolutely no authority in Bitcoin - this is what lead
to this dispute in the first place. This is the truly decentralized
nature of the software, not important if we have 10.000 full nodes or
1000 full nodes.

All this sounds reasonable.

Post by s7r via bitcoin-dev
- no, Bitcoin won't split / die or whatever because of this fork.
Regardless what it happens, if XT will reach the threshold or not,
Bitcoin will go on just because it has some unique advantages and has no
competitor from some points of view.

But you cannot know this will happen this way!
If the threshold is reached (let's forget about noXT for now), the
remaining miners cannot be forced to adopt bip101.
And users can never be forced to adopt hardforks.
It is possible that 75% of the hashrate moves to the bip101 chain
while 99% of the users remain in the old Bitcoin chain. Or 50/50,
40/60...nobody knows.

Post by s7r via bitcoin-dev
- Bitcoin by its design has many many advantages, but also the
limitation that it relies on majority being honest / doing the right
thing! This is just the way it is, and the benefits it is offering
heavily win over this fundamental limitation.

No, it doesn't rely on that. It just relies on the majority of the
miners not attacking the network for too long (ie the number of
confirmations people are waiting).
If I'm running a full node, I'm not isolated from the network and the
majority of the hashrate is not reorging the chain I am safe no matter
how dishonest the "majority" (whatever that means in this context) is.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Peter Todd via bitcoin-dev]

Post by Adam Back via bitcoin-dev
Wouldnt the experience for SPV nodes be chaotic? If the full nodes
are 50:50 XT and bitcoin core, then SPV clients would connect at
random and because XT and core will diverge immediately after
activation.

Actually not necessarily!

To my knowledge there aren't any SPV implementations that do address
caching; they all use the peer servers in a centralized fashion every
time they connect. If those peer servers are setup to only return nodes
on one side of the fork or the other, that's all they'll connect too and
they'll never see another chain.

[s7r via bitcoin-dev]

On 8/20/2015 1:28 AM, Jorge Timón wrote:
[snip]

Post by Jorge Timón via bitcoin-dev

Post by s7r via bitcoin-dev
3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
just by 2 people forking the software and submitting a consensus rule to
a vote, it means Bitcoin is dead already and it should be worthless! We
can't go around and panic every time somebody forks Bitcoin and tries to
change something - this should be allowed by the nature of its license.
If tomorrow 5 more people fork 5 different software implementing the
bitcoin protocol and submit 5 different new consensus rules to a vote,
then what? We should all sell so the price will drop to 1 cent, because
it is somehow not good enough, not stable enough?

If they don't extensively lobby Bitcoin companies, they don't start a
massive PR campaign labbeling other developers as "obstructionists"
and don't misinform a big part of the Bitcoin users (often using
logical fallacies, intentionally or not), probably those 5 new
currencies will be ignored and nothing bad will happen.
Unfortunately in this case a great division between users is being created.

This is exactly the point. If shouldn't matter if somebody who forks
also tries lobbying to Bitcoin companies and miners and also trying to
convince users to adopt the fork. Bitcoin should be immune to such
attacks, otherwise it is really flawed.

Think of a very unlikely but not theoretically impossible example:
The Prime Minister of X with a government controlled authority forks
Bitcoin and changes a very important consensus rule. To ensure adoption
at hashing power level, he issues an order and raises electricity cost
for the entire population with 10 cents or so, and compensates the
miners adopting his fork with free electricity to mine Bitcoin. What
better stimulator could a miner get if not this one?

This is a social problem, not a technical one. There is no code in
Bitcoin or rule in the protocol itself to defend against such a thing.

What can and will make this attack impossible?
The users (economic power) which always ultimately should win any
dispute will refuse using the coins mined by the miners adopting the
controversial fork, which means the coins they mine will be worthless.
Even if they are created with low costs / free electricity, the mined
coins will still be worthless so it won't worth it for the miners to
take this step. Better pay for electricity and win something less vs.
not paying for electricity but winning nothing.

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.

Post by Jorge Timón via bitcoin-dev

Post by s7r via bitcoin-dev
I can fork tomorrow Bitcoin Core to a Bitcoin-XYZ software which at some
block in the future spends all the longest dusted coins to me, out of
which I give away 50% to the miners (so the hashing power will have
incentive to use my fork).
Can they do it? YES
Will they do it? NO
Should the world care about this? NO
It's as simple as that. We cannot continue to panic that "Bitcoin as a
project" is at threat because somebody forked it.

Can you please stop conflating "Bitcoin Core as a project" and
"Bitcoin consensus rules".
They are different things and nobody is or can be "in charge" of the
later, face it.
Can you please also stop conflating software fork and
"Schism/controversial/contentious hardfork"? Nobody has anything
against the former and as you point out it is allowed by its free
software license.

I agree, wrongly expressed here - sorry about it. It's true that a
software fork is nothing alike a Schism hardfork. I am still optimistic
that we aren't at a Schism hardfork yet and hope we won't get there and
-XT will rejoin in following the consensus rule and stop this division.

Post by Jorge Timón via bitcoin-dev

Post by s7r via bitcoin-dev
4. By having a software fork and consensus rule submitted to vote we
actually prove how open Bitcoin is, and how there is lack of control
over it from all parties (developers, miners, engineers on the mail
list). This is reason to increase Bitcoin's value! It is a feature, not
a flaw!

Why should miners have a voting power that the rest of the users lack?

This is something which seams very unfair to me as well. This was my
first question after the -XT release which Mike replied to here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010241.html

To be frank the arguments didn't convince me at all. I am against this
model where users will is ignored. By forcing you to stop using
something it's not what exactly I would call a way to express your will,
it is more like a force out.

Post by Jorge Timón via bitcoin-dev

Post by s7r via bitcoin-dev
- yes, Bitcoin is open source, even you can fork it tomorrow if you want
and you think enough users might follow you.
- no, it's not a requirement for 100% of the nodes in the network to be
running Core, or -XT or other implementation. The more we have, the better.
- yes, there is absolutely no authority in Bitcoin - this is what lead
to this dispute in the first place. This is the truly decentralized
nature of the software, not important if we have 10.000 full nodes or
1000 full nodes.

All this sounds reasonable.

Post by s7r via bitcoin-dev
- no, Bitcoin won't split / die or whatever because of this fork.
Regardless what it happens, if XT will reach the threshold or not,
Bitcoin will go on just because it has some unique advantages and has no
competitor from some points of view.

But you cannot know this will happen this way!
If the threshold is reached (let's forget about noXT for now), the
remaining miners cannot be forced to adopt bip101.
And users can never be forced to adopt hardforks.
It is possible that 75% of the hashrate moves to the bip101 chain
while 99% of the users remain in the old Bitcoin chain. Or 50/50,
40/60...nobody knows.

Post by s7r via bitcoin-dev
- Bitcoin by its design has many many advantages, but also the
limitation that it relies on majority being honest / doing the right
thing! This is just the way it is, and the benefits it is offering
heavily win over this fundamental limitation.

No, it doesn't rely on that. It just relies on the majority of the
miners not attacking the network for too long (ie the number of
confirmations people are waiting).
If I'm running a full node, I'm not isolated from the network and the
majority of the hashrate is not reorging the chain I am safe no matter
how dishonest the "majority" (whatever that means in this context) is.

Correct - but the point still stands. If 75% of the hashing power wants
to do something which you don't agree to, as an user you don't have any
real options to prevent them. Only game them as in don't use bitcoin to
decrease its value so they are mining worthless or less valuable coins -
but by this you are hitting Bitcoin as a whole and not just the miners.

[Milly Bitcoin via bitcoin-dev]

Post by s7r via bitcoin-dev
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 can get the majority of developers, users, and miners to
do insecure things then Bitcoin will be insecure.

Russ

[Hector Chu via bitcoin-dev]

Security is provided via POW. If you want the chains to stop attacking
each other, change the POW algorithms.
Then it wouldn't matter if one chain was longer than another, each
fork would select the best chain according to their valid version of
POW algorithm.
If Bitcoin Core loses miner majority to XT this is probably what it
will have to do to maintain security of its chain.

On 20 August 2015 at 12:32, Milly Bitcoin via bitcoin-dev

Post by s7r via bitcoin-dev
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 can get the majority of developers, users, and miners to do
insecure things then Bitcoin will be insecure.
Russ
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Milly Bitcoin via bitcoin-dev]

Post by Hector Chu via bitcoin-dev
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 then Bitcoin
will be insecure. POW is not some outside force.

The security of Bitcoin as a system is a very complex subject that
involve a number of factors that are the result of actions by humans.

Russ

[Tamas Blummer via bitcoin-dev]

POW is by design the voting mechanism for the valid chain continuation.

Many rightfully dislike that the same voting mechanism is used on the validity rules, since ideally
validators (non-mining full nodes), SPV user and even those having an investment in their cold wallet
would all have a vote.

That ideal voting mechanism is not yet in the protocol.

Before XT we used discussions and an informal consensus of those with commit access to github to evolve Bitcoin.
The decision, not the discussion, is now suggested to be replaced with POW vote with XT.

It is not hard to see problems with both approaches.

If XT comes closer to miner majority, validators will also be forced to take side, so they will be able to express
their vote. I think that most Bitcoin entrepreneurs will pick XT if Core has no comparable offer
to scale transactions per second.

XT, Not-XT and a Core with some not-BIP101 offer will potentially set the stage for the perfect hard fork storm.

I still believe, that the idea of Bitcoin is powerful enough to weather that storm.

Tamas Blummer

Post by Hector Chu via bitcoin-dev
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 then Bitcoin will be insecure. POW is not some outside force.
The security of Bitcoin as a system is a very complex subject that involve a number of factors that are the result of actions by humans.
Russ
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Matt Corallo via bitcoin-dev]

Post by Andrew LeCody via bitcoin-dev
Cam, your scenario makes no sense.

Post by Cameron Garnham via bitcoin-dev
1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version

string.

Post by Cameron Garnham via bitcoin-dev
2. Encourage all miners to false vote for the Bitcoin XT fork.

This would obliterate any confidence in Bitcoin Core. I seriously doubt
anyone would actually be ok with a pull request implementing this.

Bitcoin Core doesnt have to do this. It is rational if you have >25% of
hash power (or if you believe 25% of hash power is doing this) to do this.
If a 75% hardfork target is reached, and >25% of the hashpower doesnt
allow the hardfork, and the hardfork is strictly more permissive than
the original (ie it is essentially a reverse softfork - there are no
previously valid blocks which are not still valid), then the miners who
voted for the fork would be constantly generating blocks which are
soft-forked-out by the >25% and non-supporting miners.
I believe this was pointed out to the Bitcoin XT folks weeks ago, but
apparently did not sway the decision to use 75% and a (as far as I can
tell?) strictly more permissive hardfork.

Matt

[muyuubyou via bitcoin-dev]

If someone is surprised with Mike Hearn's antics, I recommend taking a few
minutes to watch this video from 2 months ago:

Mike Hearn's "Worst Case" XT Fork Scenario: Checkpoints, Ignore Longest
Chain.

[Eric Voskuil via bitcoin-dev]

[cross-posted to libbitcoin]

I applaud this effort not for the merits of the hard fork but on the
effects of the code fork. We have been witnessing the self-destruction
of Bitcoin's central authority. This is a necessary outcome.

Understandably, many are concerned that if consensus settles on a larger
block size Bitcoin will suffer greater centralization. The point of
Bitcoin however is that nobody is in control of consensus. If a
consensus decision leads to centralization, the consensus will move.

Yes, when this happens people who bet on the losing fork will lose
money. This is how Bitcoin works. One bets not on personal desires but
on what others will accept. That is how consensus is built.

Some fret that if this process evolves Bitcoin will suffer a
catastrophic loss of "value" and not recover. This may come to pass, but
there is no avoiding the possibility.

The ease with which consensus can move when it wants to is important. In
other words, friction is weakness and a single overly complex codebase
is high friction.

Amir saw this coming before most. While we are posting manifestos, I

If development is too centralised, with a small core infrastructure,
then businesses will put real pressure to have features that destroy
the integrity of the Bitcoin network.
...
The possible malicious scenarios are endless....At the other end of
the spectrum, is putting development effort into diversifying the
ecosystem to protect against censorship... That's where developers
who believe in Bitcoin should devote time to.
...
A diversified Bitcoin of many wallets and implementations is a strong
and pure Bitcoin. To protect the integrity of the network, we need to
eliminate single points of failure. An inbred Bitcoin with the same
software code everywhere shares the same weaknesses, and is
susceptible to the same attacks...
The implications of a diversified Bitcoin is a Bitcoin difficult to
control. It also sets the protocol in stone, as nobody has sole power
over the standard. Consensus from many parties is the way forwards.
...
Viewed over a longer time period, extra or unnecessary features seem
to creep into the system beyond the initial goals and the small code
of 15,000 lines set by Satoshi. The result will be a Bitcoin that
becomes increasingly difficult to understand or implement without a
huge initial investment of resources, time and people. No single
person will fully understand Bitcoin anymore, and development
monopolies will be further enforced.

http://libbitcoin.dyne.org/libbitcoin-manifesto.pdf

e

Hello,
As promised, we have released Bitcoin XT 0.11A which includes the bigger
blocks patch set. You can get it from
https://bitcoinxt.software/
I feel sad that it's come to this, but there is no other way. The
Bitcoin Core project has drifted so far from the principles myself and
many others feel are important, that a fork is the only way to fix things.
Forking is a natural thing in the open source community, Bitcoin is not
the first and won't be the last project to go through this. Often in
forks, people say there was insufficient communication. So to ensure
everything is crystal clear I've written a blog post and a kind of
"manifesto" to describe why this is happening and how XT plans to be
different from Core (assuming adoption, of course).
It makes no attempt to be neutral: this explains things from our point
of view.
The manifesto is on the website.
I say to all developers on this list: if you also feel that Core is no
longer serving the interests of Bitcoin users, come join us. We don't bite.
________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev