Re: [bitcoin-dev] Bitcoin XT 0.11A

[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

> On Aug 20, 2015, at 14:29, Milly Bitcoin via bitcoin-dev 
>  wrote:
> 
>> 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Milly Bitcoin 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
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[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
 wrote:
>> 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Milly Bitcoin 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
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[s7r via bitcoin-dev]

On 8/20/2015 1:28 AM, Jorge Timón wrote:
[snip]
>> 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.

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

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

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

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Peter Todd via bitcoin-dev]

On Wed, Aug 19, 2015 at 03:45:48PM -0700, Adam Back via bitcoin-dev wrote:
> 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.

-- 
'peter'[:-1]@petertodd.org
0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d


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

Re: [bitcoin-dev] Bitcoin XT 0.11A

[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
 wrote:
> On Wed, Aug 19, 2015 at 5:41 PM, s7r  wrote:
>> 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.
>
>> 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.
> "
>
>> 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.
>
>> 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.
>
>> 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" 

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 5:41 PM, s7r  wrote:
> 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.

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

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

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

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

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

Re: [bitcoin-dev] Bitcoin XT 0.11A

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

On 8/19/2015 1:09 PM, Jorge Timón via bitcoin-dev wrote:
> On Mon, Aug 17, 2015 at 1:02 AM, Cameron Garnham via bitcoin-dev
>  wrote:
>> 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 1
>> 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.
>> [...]
>> 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

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Jorge Timón via bitcoin-dev]

On Mon, Aug 17, 2015 at 1:02 AM, Cameron Garnham via bitcoin-dev
 wrote:
> 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 1
> 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.
> [...]
> 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.

> 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
 wrote:
> 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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Matt Corallo via bitcoin-dev]

On 08/16/15 23:22, Andrew LeCody via bitcoin-dev wrote:
> Cam, your scenario makes no sense.
> 
>> 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.
> 
> 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

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

> On Aug 17, 2015, at 5:29 AM, Andrew LeCody via bitcoin-dev 
>  wrote:
> 
> Wouldn't that require a fork that lasts for more than 100 blocks?
> 
> On Mon, Aug 17, 2015, 01:43 Peter Todd  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> 
>> 
>> On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Andrew LeCody via bitcoin-dev]

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

On Mon, Aug 17, 2015, 01:43 Peter Todd  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >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
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Peter Todd via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev 
 wrote:
>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
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Cameron Garnham via bitcoin-dev]

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


On 17/8/2015 7:22 AM, Andrew LeCody wrote:
>> 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.



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Andrew LeCody via bitcoin-dev]

Cam, your scenario makes no sense.

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

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

> 3. Setup good Atomic Swap markets.

Who would bother writing this code, let alone trading on these 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).

I doubt this is even possible.

On Sun, Aug 16, 2015 at 6:02 PM Cameron Garnham via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 1
> 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.
>
>
>
> On 16/8/2015 6:39 AM, muyuubyou via bitcoin-dev wrote:
> > 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.
> >
> > -
> > 為せば成る
> >
> >
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

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



On 16/8/2015 6:39 AM, muyuubyou via bitcoin-dev wrote:
> 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.
> 
> -
> 為せば成る
> 
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[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
thought it more than appropriate to quote from the libbitcoin manifesto:

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

On 08/15/2015 10:02 AM, Mike Hearn via bitcoin-dev wrote:
> 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.
> 
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Andrew LeCody 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 <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.
>
> -
> 為せば成る
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[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

> On Aug 16, 2015, at 19:01, Adam Back  wrote:
> 
> 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
>  wrote:
>> 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
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[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
 wrote:
> 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[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

Tamas Blummer via bitcoin-dev 
schrieb am So., 16. Aug. 2015 um 18:07 Uhr:

> 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Anthony Towns via bitcoin-dev]

On 16 August 2015 at 15:49, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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

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

Re: [bitcoin-dev] Bitcoin XT 0.11A

[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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

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

https://www.youtube.com/watch?v=DB9goUDBAR0

Mike Hearn's "Worst Case" XT Fork Scenario: Checkpoints, Ignore Longest
Chain.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Milly Bitcoin 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

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

Re: [bitcoin-dev] Bitcoin XT 0.11A

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

On Sat, Aug 15, 2015 at 7:40 PM, Mark Friedenbach 
wrote:

> 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 <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> 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.
>>
>> On Sat, Aug 15, 2015 at 6:55 PM, Mark Friedenbach 
>> wrote:
>>
>>> 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" <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 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 Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo 
 wrote:

>
> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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
>

Re: [bitcoin-dev] Bitcoin XT 0.11A

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

> 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 <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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.
>
> On Sat, Aug 15, 2015 at 6:55 PM, Mark Friedenbach 
> wrote:
>
>> 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" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> 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 Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo 
>>> wrote:
>>>

 On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
 bitcoin-dev@lists.linuxfoundation.org> wrote:

 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

Re: [bitcoin-dev] Bitcoin XT 0.11A

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

> 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 <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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.
>
> On Sat, Aug 15, 2015 at 6:55 PM, Mark Friedenbach 
> wrote:
>
>> 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" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> 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 Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo 
>>> wrote:
>>>

 On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
 bitcoin-dev@lists.linuxfoundation.org> wrote:

 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 th

Re: [bitcoin-dev] Bitcoin XT 0.11A

[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 
>  wrote:
> 
> 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.
> 
> On Sat, Aug 15, 2015 at 6:55 PM, Mark Friedenbach  > wrote:
> 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" 
>  > wrote:
> 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 Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo  > wrote:
> 
>> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev 
>> > > wrote:
>> 
>> 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 publish

Re: [bitcoin-dev] Bitcoin XT 0.11A

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

On Sat, Aug 15, 2015 at 6:55 PM, Mark Friedenbach 
wrote:

> 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" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo 
>> wrote:
>>
>>>
>>> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>> 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.
>>>
>

Re: [bitcoin-dev] Bitcoin XT 0.11A

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

> 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 Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo 
> wrote:
>
>>
>> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> 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

Re: [bitcoin-dev] Bitcoin XT 0.11A

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

-
為せば成る
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[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 Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo  wrote:

>
> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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

Re: [bitcoin-dev] Bitcoin XT 0.11A

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

>
> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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 t

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Eric Lombrozo via bitcoin-dev]

> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev 
>  wrote:
> 
> 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 
>  > wrote:
> 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

Re: [bitcoin-dev] Bitcoin XT 0.11A

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

> 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 <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.li

Re: [bitcoin-dev] Bitcoin XT 0.11A

[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 
>  > wrote:
> 
> 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.
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org 
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Milly Bitcoin 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


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

Re: [bitcoin-dev] Bitcoin XT 0.11A

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

> 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.
>>
>
> 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Bryan Bishop via bitcoin-dev]

On Sat, Aug 15, 2015 at 3:36 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Milly Bitcoin via bitcoin-dev]

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.


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
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Mike Hearn 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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

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


On 8/15/2015 8:02 PM, Mike Hearn via bitcoin-dev wrote:
> 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.
> 
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[s7r via bitcoin-dev]

On 8/15/2015 8:02 PM, Mike Hearn via bitcoin-dev wrote:

> 
> 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev