[bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

"We can look at the adoption of the last major Bitcoin core release to
guess how long it might take people to upgrade. 0.11.0 was released on 12
July, 2015. Twenty eight days later, about 38% of full nodes were running
that release. Three months later, about 50% of the network was running that
release, and six months later about 66% of the network was running some
flavor of 0.11."

On what grounds do you think it is reasonable to assume that this update
will roll out 6x faster than previous data suggested, as oppose to your own
observation of 66% adoption in 6 month. or do you believe 38% node
upgrade-coverage ( in 28 days ) on the network for a hard fork is good
enough?

There are no harm in choosing a longer grace period but picking one short
as 28 days you risk on alienating the nodes who do not upgrade with the
aggressive upgrade timeline you proposed.

On Fri, Feb 5, 2016 at 3:51 PM, Gavin Andresen via bitcoin-dev <

Post by Gavin Andresen via bitcoin-dev
This has been reviewed by merchants, miners and exchanges for a couple of
weeks, and has been implemented and tested as part of the Bitcoin Classic
and Bitcoin XT implementations.
Constructive feedback welcome; argument about whether or not it is a good
idea to roll out a hard fork now will be unproductive, so I vote we don't
go there.
https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki
Increase block size limit to 2,000,000 bytes.
After 75% hashpower support then 28-day grace period.
With accurate sigop counting, but existing sigop limit (20,000)
And a new, high limit on signature hashing
http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
http://gavinandresen.ninja/seventyfive-twentyeight
--
--
Gavin Andresen
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
*Yifu Guo*
*"Life is an everlasting self-improvement."*

Gavin Andresen via bitcoin-dev

2016-02-07 17:09:46 UTC

As I feared, request on feedback for this specific BIP has devolved into a
general debate about the merits of soft-forks versus hard-forks (versus
semi-hard Kosher Free Range forks...).

I've replied to several people privately off-list to not waste people's
time rehashing arguments that have been argued to death in the past.

I do want to briefly address all of the concerns that stem from "what if a
significant fraction of hashpower (e.g. 25%) stick with the 1mb branch of
the chain."

Proof of work cannot be spoofed. If there is very little (a few percent) of
hashpower mining a minority chain, confirmations on that chain take orders
of magnitude longer. I wrote about why the incentives are extremely strong
for only the stronger branch to survive here:
http://gavinandresen.ninja/minority-branches

... the debate about whether or not that is correct doesn't belong here in
bitcoin-dev, in my humble opinion.

All of the security concerns I have seen flow from an assumption that
significant hashpower continues on the weaker branch. The BIP that is under
discussion assumes that analysis is correct. I have not seen any evidence
that it is not correct; all experience with previous forks (of both Bitcoin
and altcoins) is that the stronger branch survives and the weaker branch
very quickly dies.

As for the argument that creating and testing a patch for Core would take
longer than 28 days:

The glib answer is "people should just run Classic, then."

A less glib answer is it would be trivial to create a patch for Core that
accepted a more proof-of-work chain with larger blocks, but refused to mine
larger blocks.

That would be a trivial patch that would require very little testing
(extensive testing of 8 and 20mb blocks has already been done), and perhaps
would be the best compromise until we can agree on a permanent solution
that eliminates the arbitrary, contentious limits.

--
--
Gavin Andresen

Btc Drak via bitcoin-dev

2016-02-05 23:04:09 UTC

On Fri, Feb 5, 2016 at 8:51 PM, Gavin Andresen via bitcoin-dev <

It's great to finally see a BIP, although seems strange to ask for feedback
after releasing binaries.

In any case, the issue isn't about "whether or not it is a good idea to
roll out a hard fork", the question has always been about how to do safe
hard fork deployment and what the technological requirements are for doing
so. Your BIP/blogs do not actually address any of this. 75% miner
signalling with a 28 day flag day thereafter gives virtually no time for
the entire ecosystem to migrate and is widely considered unsafe. It's
plainly obvious that an entire ecosystem of 5000 full nodes cannot be
prepared in a month.

Luke Dashjr via bitcoin-dev

2016-02-06 00:12:25 UTC

Post by Gavin Andresen via bitcoin-dev
http://gavinandresen.ninja/seventyfive-twentyeight

Can you put this in the BIP's Rationale section (which appears to be mis-named
"Discussion" in the current draft)?

Post by Gavin Andresen via bitcoin-dev
Signature operations in un-executed branches of a Script are not counted
OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a
1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top
of the execution stack, it is counted as one signature operation. If it is
satisfied by the public key nearest the bottom of the execution stack, it
is counted as twenty signature operations. Signature operations involving
invalidly encoded signatures or public keys are not counted towards the
limit

These seem like they will break static analysis entirely. That was a noted
reason for creating BIP 16 to replace BIP 12. Is it no longer a concern? Would
it make sense to require scripts to commit to the total accurate-sigop count
to fix this?

Post by Gavin Andresen via bitcoin-dev
The amount of data hashed to compute signature hashes is limited to
1,300,000,000 bytes per block.

The rationale for this wasn't in your blog post. I assume it's based on the
current theoretical max at 1 MB blocks? Even a high-end PC would probably take
40-80 seconds just for the hashing, however - maybe a lower limit would be
best?

Post by Gavin Andresen via bitcoin-dev
Miners express their support for this BIP by ...

But miners don't get to decide hardforks. How does the economy express their
support for it? What happens if miners trigger it without consent from the
economy?

If you are intent on using the version bits to trigger the hardfork, I suggest
rephrasing this such that miners should only enable the bit when they have
independently confirmed economic support (this means implementations need a
config option that defaults to off).

Post by Gavin Andresen via bitcoin-dev
SPV (simple payment validation) wallets are compatible with this change.

Would prefer if this is corrected to "Light clients" or something. Actual SPV
wallets do not exist at this time, and would not be compatible with a
hardfork.

Post by Gavin Andresen via bitcoin-dev
In the short term, an increase is needed to continue the current economic
policies with regards to fees and block space, matching market expectations
and preventing market disruption.

IMO this sentence is the most controversial part of your draft, and it
wouldn't suffer a loss to remove it (or at least make it subjective).

I would also prefer to see any hardfork:

1. Address at least the simple tasks on the hardfork wishlist (eg, enable some
disabled opcodes; fix P2SH for N-of->15 multisig; etc).
2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
insecure.

Luke

Jorge Timón via bitcoin-dev

2016-02-06 03:14:03 UTC

If it is to be uncontroversial and everybody will upgrade, there's no
fear of a "veto power" and there's no good reason not to wait for 95%
block version signaling for deployment coordination, ideally using
bip9.
But that's for chosing the exact block where to start. The grace
period to give time to all users to upgrade should be before and not
after miner's final confirmation: that simplifies and accelerates
things. Assuming we chose a grace period that is really adequate,
nearly 100% of miners will have likely upgraded long before everyone
(since miners are a subset of "everyone"). If that is not the case and
miners happen to be the latest to upgrade, using bip9 after the grace
period (aka starting median-time/height) will make sure the hardfork
doesn't get activated without 95% of the miners having upgraded.

28 days seems extremely short (specially if the grace period comes
first), some people have suggested one year for simple hardforks like
this one.

On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev

Post by Gavin Andresen via bitcoin-dev
http://gavinandresen.ninja/seventyfive-twentyeight

Can you put this in the BIP's Rationale section (which appears to be mis-named
"Discussion" in the current draft)?

Post by Gavin Andresen via bitcoin-dev
The amount of data hashed to compute signature hashes is limited to
1,300,000,000 bytes per block.

Post by Gavin Andresen via bitcoin-dev
Miners express their support for this BIP by ...

But miners don't get to decide hardforks. How does the economy express their
support for it? What happens if miners trigger it without consent from the
economy?
If you are intent on using the version bits to trigger the hardfork, I suggest
rephrasing this such that miners should only enable the bit when they have
independently confirmed economic support (this means implementations need a
config option that defaults to off).

Post by Gavin Andresen via bitcoin-dev
SPV (simple payment validation) wallets are compatible with this change.

Would prefer if this is corrected to "Light clients" or something. Actual SPV
wallets do not exist at this time, and would not be compatible with a
hardfork.

IMO this sentence is the most controversial part of your draft, and it
wouldn't suffer a loss to remove it (or at least make it subjective).
1. Address at least the simple tasks on the hardfork wishlist (eg, enable some
disabled opcodes; fix P2SH for N-of->15 multisig; etc).
2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
insecure.
Luke
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Gavin Andresen via bitcoin-dev

2016-02-06 15:37:30 UTC

Responding to "28 days is not long enough" :

I keep seeing this claim made with no evidence to back it up. As I said, I
surveyed several of the biggest infrastructure providers and the btcd lead
developer and they all agree "28 days is plenty of time."

For individuals... why would it take somebody longer than 28 days to either
download and restart their bitcoind, or to patch and then re-run (the patch
can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?

For the Bitcoin Core project: I'm well aware of how long it takes to roll
out new binaries, and 28 days is plenty of time.

I suspect there ARE a significant percentage of un-maintained full nodes--
probably 30 to 40%. Losing those nodes will not be a problem, for three
reasons:
1) The network could shrink by 60% and it would still have plenty of open
connection slots
2) People are committing to spinning up thousands of supports-2mb-nodes
during the grace period.
3) We could wait a year and pick up maybe 10 or 20% more.

I strongly disagree with the statement that there is no cost to a longer
grace period. There is broad agreement that a capacity increase is needed
NOW.

To bring it back to bitcoin-dev territory: are there any TECHNICAL
arguments why an upgrade would take a business or individual longer than 28
days?

Responding to Luke's message:

On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev

On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev

Post by Gavin Andresen via bitcoin-dev
http://gavinandresen.ninja/seventyfive-twentyeight

Can you put this in the BIP's Rationale section (which appears to be

mis-named

"Discussion" in the current draft)?

I'll rename the section and expand it a little. I think standards documents
like BIPs should be concise, though (written for implementors), so I'm not
going to recreate the entire blog post there.

Post by Gavin Andresen via bitcoin-dev
Signature operations in un-executed branches of a Script are not counted
OP_CHECKMULTISIG evaluations are counted accurately; if the signature

for a

Post by Gavin Andresen via bitcoin-dev
1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top
of the execution stack, it is counted as one signature operation. If it

Post by Gavin Andresen via bitcoin-dev
satisfied by the public key nearest the bottom of the execution stack,

Post by Gavin Andresen via bitcoin-dev
is counted as twenty signature operations. Signature operations

involving

Post by Gavin Andresen via bitcoin-dev
invalidly encoded signatures or public keys are not counted towards the
limit

These seem like they will break static analysis entirely. That was a

noted

reason for creating BIP 16 to replace BIP 12. Is it no longer a concern?

Would

it make sense to require scripts to commit to the total accurate-sigop

count

to fix this?

After implementing static counting and accurate counting... I was wrong.
Accurate/dynamic counting/limiting is quick and simple and can be
completely safe (the counting code can be told the limit and can
"early-out" validation).

I think making scripts commit to a total accurate sigop count is a bad
idea-- it would make multisignature signing more complicated for zero
benefit. E.g. if you're circulating a partially signed transaction to that
must be signed by 2 of 5 people, you can end up with a transaction that
requires 2, 3, 4, or 5 signature operations to validate (depending on which
public keys are used to do the signing). The first signer might have no
idea who else would sign and wouldn't know the accurate sigop count.

Post by Gavin Andresen via bitcoin-dev
The amount of data hashed to compute signature hashes is limited to
1,300,000,000 bytes per block.

The rationale for this wasn't in your blog post. I assume it's based on

the

current theoretical max at 1 MB blocks? Even a high-end PC would

probably take

40-80 seconds just for the hashing, however - maybe a lower limit would

best?

It is slightly more hashing than was required to validate block number
364,422.

There are a couple of advantages to a very high limit:

1) When the fork is over, special-case code for dealing with old blocks can
be eliminated, because all old blocks satisfy the new limit.

2) More importantly, if the limit is small enough it might get hit by
standard transactions, then block creation code (CreateNewBlock() /
getblocktemplate / or some external transaction-assembling software) will
have to solve an even more complicated bin-packing problem to optimize for
fees paid.

In practice, the 20,000 sigop limit will always be reached before
MAX_BLOCK_SIGHASH.

Post by Gavin Andresen via bitcoin-dev
Miners express their support for this BIP by ...

But miners don't get to decide hardforks. How does the economy express

their

support for it? What happens if miners trigger it without consent from

the

economy?

"The economy" does support this.

If you are intent on using the version bits to trigger the hardfork, I

suggest

rephrasing this such that miners should only enable the bit when they

have

independently confirmed economic support (this means implementations

need a

config option that defaults to off).

Happy to add words about economic majority.

Classic will not implement a command-line option (the act of running
Classic is "I opt in"), but happy to add one for a pull request to Core,
assuming Core would not see such a pull request as having any hostile
intent.

Post by Gavin Andresen via bitcoin-dev
SPV (simple payment validation) wallets are compatible with this change.

Would prefer if this is corrected to "Light clients" or something.

Actual SPV

wallets do not exist at this time, and would not be compatible with a
hardfork.

Is there an explanation of SPV versus "Light Client" written somewhere more
permanent than a reddit comment or forum post that I can point to?

Post by Gavin Andresen via bitcoin-dev
In the short term, an increase is needed to continue the current

economic

Post by Gavin Andresen via bitcoin-dev
policies with regards to fees and block space, matching market

expectations

Post by Gavin Andresen via bitcoin-dev
and preventing market disruption.

IMO this sentence is the most controversial part of your draft, and it
wouldn't suffer a loss to remove it (or at least make it subjective).

Happy to remove.

1. Address at least the simple tasks on the hardfork wishlist (eg,

enable some

disabled opcodes; fix P2SH for N-of->15 multisig; etc).

Those would be separate BIPs. (according to BIP 1, smaller is better)

After this 2MB bump, I agree we need to agree on a process for the next
hard fork to avoid all of the unnecessary drama.

Post by Luke Dashjr via bitcoin-dev
2. Be deployed as a soft-hardfork so as not to leave old nodes entirely

insecure.

I haven't been paying attention to all of the
"soft-hardfork/hard-softfork/etc" terminology so have no idea what you
mean. Is THAT written up somewhere?

--
--
Gavin Andresen

Adam Back via bitcoin-dev

2016-02-06 17:01:49 UTC

Hi Gavin

It would probably be a good idea to have a security considerations
section, also, is there a list of which exchange, library, wallet,
pool, stats server, hardware etc you have tested this change against?

Do you have a rollback plan in the event the hard-fork triggers via
false voting as seemed to be prevalent during XT? (Or rollback just
as contingency if something unforseen goes wrong).

How do you plan to monitor and manage security through the hard-fork?

Adam

On 6 February 2016 at 16:37, Gavin Andresen via bitcoin-dev

Post by Gavin Andresen via bitcoin-dev
I keep seeing this claim made with no evidence to back it up. As I said, I
surveyed several of the biggest infrastructure providers and the btcd lead
developer and they all agree "28 days is plenty of time."
For individuals... why would it take somebody longer than 28 days to either
download and restart their bitcoind, or to patch and then re-run (the patch
can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?
For the Bitcoin Core project: I'm well aware of how long it takes to roll
out new binaries, and 28 days is plenty of time.
I suspect there ARE a significant percentage of un-maintained full nodes--
probably 30 to 40%. Losing those nodes will not be a problem, for three
1) The network could shrink by 60% and it would still have plenty of open
connection slots
2) People are committing to spinning up thousands of supports-2mb-nodes
during the grace period.
3) We could wait a year and pick up maybe 10 or 20% more.
I strongly disagree with the statement that there is no cost to a longer
grace period. There is broad agreement that a capacity increase is needed
NOW.
To bring it back to bitcoin-dev territory: are there any TECHNICAL
arguments why an upgrade would take a business or individual longer than 28
days?

Post by Jorge TimÃ³n via bitcoin-dev
On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev

Post by Gavin Andresen via bitcoin-dev
http://gavinandresen.ninja/seventyfive-twentyeight

Can you put this in the BIP's Rationale section (which appears to be mis-named
"Discussion" in the current draft)?

I'll rename the section and expand it a little. I think standards documents
like BIPs should be concise, though (written for implementors), so I'm not
going to recreate the entire blog post there.

After implementing static counting and accurate counting... I was wrong.
Accurate/dynamic counting/limiting is quick and simple and can be completely
safe (the counting code can be told the limit and can "early-out"
validation).
I think making scripts commit to a total accurate sigop count is a bad
idea-- it would make multisignature signing more complicated for zero
benefit. E.g. if you're circulating a partially signed transaction to that
must be signed by 2 of 5 people, you can end up with a transaction that
requires 2, 3, 4, or 5 signature operations to validate (depending on which
public keys are used to do the signing). The first signer might have no
idea who else would sign and wouldn't know the accurate sigop count.

Post by Gavin Andresen via bitcoin-dev
The amount of data hashed to compute signature hashes is limited to
1,300,000,000 bytes per block.

It is slightly more hashing than was required to validate block number
364,422.
1) When the fork is over, special-case code for dealing with old blocks can
be eliminated, because all old blocks satisfy the new limit.
2) More importantly, if the limit is small enough it might get hit by
standard transactions, then block creation code (CreateNewBlock() /
getblocktemplate / or some external transaction-assembling software) will
have to solve an even more complicated bin-packing problem to optimize for
fees paid.
In practice, the 20,000 sigop limit will always be reached before
MAX_BLOCK_SIGHASH.

Post by Gavin Andresen via bitcoin-dev
Miners express their support for this BIP by ...

But miners don't get to decide hardforks. How does the economy express their
support for it? What happens if miners trigger it without consent from the
economy?

"The economy" does support this.

Post by Luke Dashjr via bitcoin-dev
If you are intent on using the version bits to trigger the hardfork, I suggest
rephrasing this such that miners should only enable the bit when they have
independently confirmed economic support (this means implementations need a
config option that defaults to off).

Happy to add words about economic majority.
Classic will not implement a command-line option (the act of running Classic
is "I opt in"), but happy to add one for a pull request to Core, assuming
Core would not see such a pull request as having any hostile intent.

Post by Gavin Andresen via bitcoin-dev
SPV (simple payment validation) wallets are compatible with this change.

Would prefer if this is corrected to "Light clients" or something. Actual SPV
wallets do not exist at this time, and would not be compatible with a
hardfork.

Is there an explanation of SPV versus "Light Client" written somewhere more
permanent than a reddit comment or forum post that I can point to?

IMO this sentence is the most controversial part of your draft, and it
wouldn't suffer a loss to remove it (or at least make it subjective).

Happy to remove.

Post by Luke Dashjr via bitcoin-dev
1. Address at least the simple tasks on the hardfork wishlist (eg, enable some
disabled opcodes; fix P2SH for N-of->15 multisig; etc).

Those would be separate BIPs. (according to BIP 1, smaller is better)
After this 2MB bump, I agree we need to agree on a process for the next hard
fork to avoid all of the unnecessary drama.

Post by Luke Dashjr via bitcoin-dev
2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
insecure.

I haven't been paying attention to all of the
"soft-hardfork/hard-softfork/etc" terminology so have no idea what you mean.
Is THAT written up somewhere?
--
--
Gavin Andresen
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Gavin Andresen via bitcoin-dev

2016-02-06 17:45:14 UTC

Post by Adam Back via bitcoin-dev
It would probably be a good idea to have a security considerations
section

Containing what? I'm not aware of any security considerations that are any
different from any other consensus rules change.

(I can write a blog post summarizing our slack discussion of SPV security
immediately after the first greater-than-1mb-block if you like).

Post by Adam Back via bitcoin-dev
, also, is there a list of which exchange, library, wallet,
pool, stats server, hardware etc you have tested this change against?

That testing is happening by the exchange, library, wallet, etc providers
themselves. There is a list on the Classic home page:

https://bitcoinclassic.com/

Post by Adam Back via bitcoin-dev
Do you have a rollback plan in the event the hard-fork triggers via
false voting as seemed to be prevalent during XT? (Or rollback just
as contingency if something unforseen goes wrong).

The only voting in this BIP is done by the miners, and that cannot be faked.

Are you talking about people spinning up pseudo-full-nodes that fake the
user-agent?

As I said, there are people who have said they will spin up thousands of
full nodes to help prevent possible Sybil attacks which would become
marginally easier to accomplish immediately after the first >1mb block was
produced and full nodes that hadn't upgraded were left behind.

Would Blockstream be willing to help out by running a dozen or two extra
full nodes?

I can't imagine any even-remotely-likely sequence of events that would
require a rollback, can you be more specific about what you are imagining?
Miners suddenly getting cold feet?

Post by Adam Back via bitcoin-dev
How do you plan to monitor and manage security through the hard-fork?

--
--
Gavin Andresen

Peter Todd via bitcoin-dev

2016-02-06 21:11:58 UTC

Post by Adam Back via bitcoin-dev
It would probably be a good idea to have a security considerations
section

Containing what? I'm not aware of any security considerations that are any
different from any other consensus rules change.

I covered the security considerations unique to hard-forks on my blog:

https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks

Post by Adam Back via bitcoin-dev
, also, is there a list of which exchange, library, wallet,
pool, stats server, hardware etc you have tested this change against?

That testing is happening by the exchange, library, wallet, etc providers
https://bitcoinclassic.com/

How do we know any of this testing is actually being performed? I don't
currently know of any concrete testing actually done.

The only voting in this BIP is done by the miners, and that cannot be faked.

Are you unaware of Not Bitcoin XT?

https://bitcointalk.org/index.php?topic=1154520.0

Post by Gavin Andresen via bitcoin-dev
I can't imagine any even-remotely-likely sequence of events that would
require a rollback, can you be more specific about what you are imagining?
Miners suddenly getting cold feet?

See above.

Also, as the two coins are separate currencies and can easily trade
against each other in a 75%/25% split, it would be easy for the price to
diverge and hashing power to move.

In fact, I've been asked multiple times now by exchanges and other
players in this ecosystem for technical advice on how to split coins
across the chains effectively (easily done with nLockTime). Notably, the
exchanges who have asked me this - who hold customer funds on their
behalf - have informed me that their legal advice was that the
post-hard-fork coins are legally speaking separate currencies, and
customers must be given the opportunity to transact in them separately
if they choose too. Obviously, with a 75%/25% split, while block times
on the other chain will be slower, the chain is still quite useful and
nearly as secure as the main chain against 51% attack; why I personally
have suggested a 99% threshold:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012309.html

(remember that the threshold can always be soft-forked down)

It's also notable that millions of dollars of Bitcoin are voting agsast
the fork on the proof-of-stake voting site Bitcoinocracy.com While
obviously not comprehensive, the fact that a relatively obscure site
like it can achieve participation like that, even without an easy to use
user friendly interface.

Post by Adam Back via bitcoin-dev
How do you plan to monitor and manage security through the hard-fork?

Please provide details on exactly how that's going to happen.

--
https://petertodd.org 'peter'[:-1]@petertodd.org
000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698

Peter Todd via bitcoin-dev

2016-02-06 21:24:19 UTC

Post by Peter Todd via bitcoin-dev

Post by Adam Back via bitcoin-dev
It would probably be a good idea to have a security considerations
section

Containing what? I'm not aware of any security considerations that are any
different from any other consensus rules change.

https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks

Oh, and to be 100% clear, I should say those are only *some of* the
unique security considerations - for starters the article is mainly
talking about uncontroversial hard-forks, and doesn't even delve into
economic attacks among other omissions. It's just an introductory
article.

--
https://petertodd.org 'peter'[:-1]@petertodd.org
000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698

Samson Mow via bitcoin-dev

2016-02-09 05:11:56 UTC

Gavin, please don't quote that list on the Classic website. It's horribly
inaccurate and misleading to the general public.

Post by Gavin Andresen via bitcoin-dev
That testing is happening by the exchange, library, wallet, etc providers
https://bitcoinclassic.com/

I know for a fact that most companies you list there have no intention to
run Classic, much less test it. You should not mix support for 2MB with
support for Classic, or if people say they welcome a fork, to mean they
support Classic.

On Sun, Feb 7, 2016 at 5:11 AM, Peter Todd via bitcoin-dev <

Post by Adam Back via bitcoin-dev
It would probably be a good idea to have a security considerations
section

Containing what? I'm not aware of any security considerations that are

any

Post by Gavin Andresen via bitcoin-dev
different from any other consensus rules change.

https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks

Post by Adam Back via bitcoin-dev
, also, is there a list of which exchange, library, wallet,
pool, stats server, hardware etc you have tested this change against?

That testing is happening by the exchange, library, wallet, etc providers
https://bitcoinclassic.com/

How do we know any of this testing is actually being performed? I don't
currently know of any concrete testing actually done.

The only voting in this BIP is done by the miners, and that cannot be

faked.
Are you unaware of Not Bitcoin XT?
https://bitcointalk.org/index.php?topic=1154520.0

Post by Gavin Andresen via bitcoin-dev
I can't imagine any even-remotely-likely sequence of events that would
require a rollback, can you be more specific about what you are

imagining?

Post by Gavin Andresen via bitcoin-dev
Miners suddenly getting cold feet?

See above.
Also, as the two coins are separate currencies and can easily trade
against each other in a 75%/25% split, it would be easy for the price to
diverge and hashing power to move.
In fact, I've been asked multiple times now by exchanges and other
players in this ecosystem for technical advice on how to split coins
across the chains effectively (easily done with nLockTime). Notably, the
exchanges who have asked me this - who hold customer funds on their
behalf - have informed me that their legal advice was that the
post-hard-fork coins are legally speaking separate currencies, and
customers must be given the opportunity to transact in them separately
if they choose too. Obviously, with a 75%/25% split, while block times
on the other chain will be slower, the chain is still quite useful and
nearly as secure as the main chain against 51% attack; why I personally
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012309.html
(remember that the threshold can always be soft-forked down)
It's also notable that millions of dollars of Bitcoin are voting agsast
the fork on the proof-of-stake voting site Bitcoinocracy.com While
obviously not comprehensive, the fact that a relatively obscure site
like it can achieve participation like that, even without an easy to use
user friendly interface.

Post by Adam Back via bitcoin-dev
How do you plan to monitor and manage security through the hard-fork?

I don't plan to monitor or manage anything; the Bitcoin network is
self-monitoring and self-managing. Services like statoshi.info will do

the

Post by Gavin Andresen via bitcoin-dev
monitoring, and miners and people and businesses will manage the network,
as they do every day.

Please provide details on exactly how that's going to happen.
--
000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

David Thomson via bitcoin-dev

2016-02-06 21:28:22 UTC

Gavin,

I saw this in your blog post:

"Miners producing up-version blocks is a coordination mechanism. Other coordination mechanisms are possibleâ there could be a centrally determined âflag dayâ or âflag blockâ when everybody (or almost everybody) agrees that a change will happen."

Can you describe this a bit more? How would either a "flag day" or "flag block" work as an alternative and why did you decide against them?

More thoughts and questions inline, thanks!

Post by Adam Back via bitcoin-dev
It would probably be a good idea to have a security considerations
section

Containing what? I'm not aware of any security considerations that are any different from any other consensus rules change.

Can you explain and justify why that is the case? It would be nice to see that rationale laid out more fully as to why it's no different.

(I can write a blog post summarizing our slack discussion of SPV security immediately after the first greater-than-1mb-block if you like).

I'm not familiar with the context of your slack discussion, but why would you wait to summarize that only after the first-greater-than-1mb-block?

Post by Adam Back via bitcoin-dev
, also, is there a list of which exchange, library, wallet,
pool, stats server, hardware etc you have tested this change against?

https://bitcoinclassic.com/

Is there a way to provide more transparency and visibility into that process and level of readiness? Is there an expectation of certain levels of readiness here before certain other things happen? I was thinking it would be really useful to have a visual timeline of events associated with all of this. Maybe you could add that to one of your web pages?

The only voting in this BIP is done by the miners, and that cannot be faked.
Are you talking about people spinning up pseudo-full-nodes that fake the user-agent?
As I said, there are people who have said they will spin up thousands of full nodes to help prevent possible Sybil attacks which would become marginally easier to accomplish immediately after the first >1mb block was produced and full nodes that hadn't upgraded were left behind.
Would Blockstream be willing to help out by running a dozen or two extra full nodes?
I can't imagine any even-remotely-likely sequence of events that would require a rollback, can you be more specific about what you are imagining? Miners suddenly getting cold feet?

Well that, but also past performance isn't an indication of future performance, necessarily. They might have gone out of business, to give one example. There is surely assumed self-interest, but I have also seen rumors floating around of this being used as an arbitrage opportunity. Would suck to imagine that ever happening, but since this seems like it's being managed on more handshake type of deals (or conversations), are there any legal documents backing those commitments up? Or is that definitely overkill?

Maybe it's worth documenting the full range of possible series of events and then their presumed level of unlikelihood? "What can go wrong will go wrong", "Black Swan" events, type of considerations. :) Often when people discuss unlikely things like crypto being broken, it's like, "Assuming processing power of x, increasing at a rate of x, and a known age of the universe of x, it would take a billion times the known length of the universe for that to happen".

Certainly not everything fits so easily into that framing, but it would be really helpful to see the "what could possibly go wrong" things fully enumerated.

Thanks!!

Dave

Post by Adam Back via bitcoin-dev
How do you plan to monitor and manage security through the hard-fork?

I don't plan to monitor or manage anything; the Bitcoin network is self-monitoring and self-managing. Services like statoshi.infowill do the monitoring, and miners and people and businesses will manage the network, as they do every day.
--
--
Gavin Andresen
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Chris Priest via bitcoin-dev

2016-02-07 18:49:39 UTC

Segwit requires work from exchanges, wallets and services in order for
adoption to happen. This is because segwit changes the rules regarding
the Transaction data structure. A blocksize increase does not change
the Transaction rules at all. The blocksize increase is a change to
the Block structure. Most wallets these days are Block agnostic.

Essentially, if a client has been built using a library that abstracts
away the block, then that client's *code* does not need to be updated
to handle this blocksize limit change. An example is any service using
the Bitcore javascript library. Any wallet built using Bitcore does
not need any changes to handle a blocksize upgrade. I have one project
that is live that was built using Bitcore. Before, during, and after
the fork, I do not need to lift a finger *codewise* to keep my project
still working. Same goes for projects that are built using
pybitcointools, as well as probably a few other libraries.

A wallet using Bitcore also has to work in tandem with a blockchan
api. Bitcore itself does not provide any blockchain data, you have to
get that somewhere else, such as a Node API. That API has to be based
on a Node that is following the upgraded chain. My wallet for instance
is built on top of Bitpay Insight. If bitpay doesn't upgrade their
Node to follow the 2MB chain, then I must either...

1) Change my wallet to use my own Bitpay Insight. (Insight is open
source, so you can host you own using any Node client you want)
2) Switch to another API, such as Toshi or Bockr.io, or
Blokchain.Info, or ... (there are dozens to choose from)

A blockchain service such as a blockexplorer does need to be upgraded
to handle a blocksize hardfork. The only work required is updating
their node software so that the MAX_BLOCKSIZE parameter is set to 2MB.
This can be done by either changing the source code themselves, or by
installing an alternate client such as XT, Classic, or Unlimited.

On 2/6/16, Adam Back via bitcoin-dev

Post by Adam Back via bitcoin-dev
Hi Gavin
It would probably be a good idea to have a security considerations
section, also, is there a list of which exchange, library, wallet,
pool, stats server, hardware etc you have tested this change against?
Do you have a rollback plan in the event the hard-fork triggers via
false voting as seemed to be prevalent during XT? (Or rollback just
as contingency if something unforseen goes wrong).
How do you plan to monitor and manage security through the hard-fork?
Adam
On 6 February 2016 at 16:37, Gavin Andresen via bitcoin-dev

Post by Jorge TimÃ³n via bitcoin-dev
On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev

Post by Gavin Andresen via bitcoin-dev
http://gavinandresen.ninja/seventyfive-twentyeight

Can you put this in the BIP's Rationale section (which appears to be mis-named
"Discussion" in the current draft)?

I'll rename the section and expand it a little. I think standards documents
like BIPs should be concise, though (written for implementors), so I'm not
going to recreate the entire blog post there.

Post by Gavin Andresen via bitcoin-dev
Signature operations in un-executed branches of a Script are not counted
OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a
1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top
of the execution stack, it is counted as one signature operation. If it
is
satisfied by the public key nearest the bottom of the execution stack,
it
is counted as twenty signature operations. Signature operations involving
invalidly encoded signatures or public keys are not counted towards the
limit

These seem like they will break static analysis entirely. That was a noted
reason for creating BIP 16 to replace BIP 12. Is it no longer a concern?
Would
it make sense to require scripts to commit to the total accurate-sigop count
to fix this?

After implementing static counting and accurate counting... I was wrong.
Accurate/dynamic counting/limiting is quick and simple and can be completely
safe (the counting code can be told the limit and can "early-out"
validation).
I think making scripts commit to a total accurate sigop count is a bad
idea-- it would make multisignature signing more complicated for zero
benefit. E.g. if you're circulating a partially signed transaction to that
must be signed by 2 of 5 people, you can end up with a transaction that
requires 2, 3, 4, or 5 signature operations to validate (depending on which
public keys are used to do the signing). The first signer might have no
idea who else would sign and wouldn't know the accurate sigop count.

Post by Gavin Andresen via bitcoin-dev
The amount of data hashed to compute signature hashes is limited to
1,300,000,000 bytes per block.

The rationale for this wasn't in your blog post. I assume it's based on
the
current theoretical max at 1 MB blocks? Even a high-end PC would probably take
40-80 seconds just for the hashing, however - maybe a lower limit would
be
best?

Post by Gavin Andresen via bitcoin-dev
Miners express their support for this BIP by ...

But miners don't get to decide hardforks. How does the economy express their
support for it? What happens if miners trigger it without consent from the
economy?

"The economy" does support this.

Happy to add words about economic majority.
Classic will not implement a command-line option (the act of running Classic
is "I opt in"), but happy to add one for a pull request to Core, assuming
Core would not see such a pull request as having any hostile intent.

Post by Gavin Andresen via bitcoin-dev
SPV (simple payment validation) wallets are compatible with this change.

Would prefer if this is corrected to "Light clients" or something. Actual SPV
wallets do not exist at this time, and would not be compatible with a
hardfork.

Is there an explanation of SPV versus "Light Client" written somewhere more
permanent than a reddit comment or forum post that I can point to?

IMO this sentence is the most controversial part of your draft, and it
wouldn't suffer a loss to remove it (or at least make it subjective).

Happy to remove.

Post by Luke Dashjr via bitcoin-dev
1. Address at least the simple tasks on the hardfork wishlist (eg, enable some
disabled opcodes; fix P2SH for N-of->15 multisig; etc).

Those would be separate BIPs. (according to BIP 1, smaller is better)
After this 2MB bump, I agree we need to agree on a process for the next hard
fork to avoid all of the unnecessary drama.

Post by Luke Dashjr via bitcoin-dev
2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
insecure.

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

Jorge Timón via bitcoin-dev

2016-02-06 17:09:21 UTC

Any thoughts on the "95% better than 75%" and "grace period before miner
coordination instead of after" comments ?

Post by Gavin Andresen via bitcoin-dev
I suspect there ARE a significant percentage of un-maintained full

nodes-- probably 30 to 40%. Losing those nodes will not be a problem, for
three reasons:

None of the reasons you list say anything about the fact that "being lost"
(kicked out of the network) is a problem for those node's users.

Post by Gavin Andresen via bitcoin-dev
I strongly disagree with the statement that there is no cost to a longer

grace period.

I didn't say that.

Post by Gavin Andresen via bitcoin-dev
To bring it back to bitcoin-dev territory: are there any TECHNICAL

arguments why an upgrade would take a business or individual longer than 28
days?

Their own software stack may require more work to integrate the new rules
or their resources may not be immediately available to focus on this within
28 days they hadn't planned.

I believe it wold be less controversial to chose something that nobody can
deny is more than plenty of time for everyone to implement the changes
like, say, 1 year. I wouldn't personally oppose to something shorter like 6
months for really simple changes, but I don't see how 28 can ever be
considered uncontroversial and safe for everyone. Just trying to help in
removing controversy from the PR, but if you still think 28 can be safe and
uncontroversial, feel free to ignore these comments on the concrete length
and please let me know what you think about the other points I raised.

Tom Zander via bitcoin-dev

2016-02-06 17:25:21 UTC

Post by Jorge TimÃ³n via bitcoin-dev
None of the reasons you list say anything about the fact that "being lost"
(kicked out of the network) is a problem for those node's users.

--
Tom Zander

Luke Dashjr via bitcoin-dev

2016-02-06 20:46:39 UTC

Post by Jorge TimÃ³n via bitcoin-dev
None of the reasons you list say anything about the fact that "being
lost" (kicked out of the network) is a problem for those node's users.

Until someone decides to attack you. Then you'll get 6, 10, maybe more blocks
confirming a large 10000 BTC payment. If you're just a normal end user (or
perhaps an automated system), you'll figure that payment is good and
irreversibly hand over the title to the house.

Luke

Gavin Andresen via bitcoin-dev

2016-02-07 14:16:02 UTC

On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <

On Saturday, February 06, 2016 06:09:21 PM Jorge TimÃ³n via bitcoin-dev

Post by Jorge TimÃ³n via bitcoin-dev
None of the reasons you list say anything about the fact that "being
lost" (kicked out of the network) is a problem for those node's users.

That's because its not.
If you have a node that is "old" your node will stop getting new blocks.
The node will essentially just say "x-hours behind" with "x" getting

larger

every hour. Funds don't get confirmed. etc.

There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners (they
upgrade VERY quickly from 75% to over 95%).

So it will take a week to get 6 confirmations.

If you are a full node, you are warned that your software is obsolete and
you must upgrade.

If you are a lightweight node, it SHOULD tell you something is wrong, but
even if it doesn't, given that people running lightweight nodes run them so
they don't have to be connected to the network 24/7, it is very likely
during that week you disconnect and reconnect to the network several times.
And every time you do that you increase your chances that you will connect
to full nodes on the majority branch of the chain, where you will be told
about the double-spend.

All of that is assuming that there is no OTHER mitigation done. DNS seeds
should avoid reporting nodes that look like they are in the middle of
initial block download (that are at a block height significantly behind the
rest of the network), for example.

--
--
Gavin Andresen

Alex Morcos via bitcoin-dev

2016-02-07 15:06:06 UTC

I apologize if this discussion should be moved to -discuss, I'll let the
moderators decide, I've copied both.

And Gavin, I apologize for picking on you here, because certainly this
carelessness in how people represent "facts" applies to both sides, but
much of this discussion really infuriates me.
I believe it is completely irresponsible for you to state:
"There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners"
Sure, the rest of the technical community is capable of evaluating that for
themselves, but your statements are considered authoritative by much larger
audience. In truth, no one has any idea what would happen if the proposed
Classic hard fork activated with 75% right now. There is some chance you
are right, but there is a very legitimate possibility that a concerted
effort would arise to maintain a minority fork or perhaps if miners don't
see nearly a complete switch over, many of them might themselves reverse
the fork if they think it would be easier to achieve consensus that way.
We as a community have never been in such a situation before and it
behooves us to speak honestly and directly about the uncertainty of the
situation.

And the back and forth discussion over your BIP has been in large part a
charade. People asking why you aren't picking 95% know very well why you
aren't, but lets have an honest discussion of what the risks and in your
mind potential benefits of 75% are. Important debate about parameters of
your BIP get lost because we're sniping at each other about known
disagreements. For instance, I strongly believe 28 days is far too short.
I think its extremely unlikely that those who are opposed to a contentious
hard fork will do the development work to prepare for it as that may only
make it more likely to happen. Thus if you did achieve activation with
75%, its almost impossible to imagine that if Bitcoin Core decided to come
along (as opposed to pursuing a minority fork) that they'd have the time to
develop and test the patch and roll it out to wide adoption. If the goal
of your attempt is that any minority that disagreed will "choose" to follow
the majority branch, then you'd be much more likely to achieve that by
giving them time to decide that's what they wanted and roll out the
software to do so.

On Sun, Feb 7, 2016 at 9:16 AM, Gavin Andresen via bitcoin-dev <

Post by Gavin Andresen via bitcoin-dev
On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <

On Saturday, February 06, 2016 06:09:21 PM Jorge TimÃ³n via bitcoin-dev

Post by Jorge TimÃ³n via bitcoin-dev
None of the reasons you list say anything about the fact that "being
lost" (kicked out of the network) is a problem for those node's users.

That's because its not.
If you have a node that is "old" your node will stop getting new blocks.
The node will essentially just say "x-hours behind" with "x" getting

larger

every hour. Funds don't get confirmed. etc.

There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners (they
upgrade VERY quickly from 75% to over 95%).
So it will take a week to get 6 confirmations.
If you are a full node, you are warned that your software is obsolete and
you must upgrade.
If you are a lightweight node, it SHOULD tell you something is wrong, but
even if it doesn't, given that people running lightweight nodes run them so
they don't have to be connected to the network 24/7, it is very likely
during that week you disconnect and reconnect to the network several times.
And every time you do that you increase your chances that you will connect
to full nodes on the majority branch of the chain, where you will be told
about the double-spend.
All of that is assuming that there is no OTHER mitigation done. DNS seeds
should avoid reporting nodes that look like they are in the middle of
initial block download (that are at a block height significantly behind the
rest of the network), for example.
--
--
Gavin Andresen
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Peter Todd via bitcoin-dev

2016-02-07 16:54:23 UTC

Post by Alex Morcos via bitcoin-dev
And the back and forth discussion over your BIP has been in large part a
charade. People asking why you aren't picking 95% know very well why you
aren't, but lets have an honest discussion of what the risks and in your

Eh, lets not put words into people's mouths. I personally don't
understand why Gavin is using 75% in the manner that he is, given there
are many better alternatives, even if you don't think you can get ~100%
hashing power support.

Post by Alex Morcos via bitcoin-dev
mind potential benefits of 75% are. Important debate about parameters of
your BIP get lost because we're sniping at each other about known
disagreements. For instance, I strongly believe 28 days is far too short.

Note that the grace period adds a significant amount of complexity to
the implementation; a much simpler alternative is to just use a hashing
power activated change with a very high threshold - 99% or so - with a
minimum activation date some point reasonably far into the future.

Also the way the grace period is implemented means that if support
*drops* after 75% is reached, the hardfork still activates (I haven't
actually tested this, so I may be misunderstanding the code). Obviously,
this is a dangerous situation, and an easy way for miners to "poison the
well" and disruptively force the fork to be rescheduled without actually
attacking the coin (nothing wrong with changing your mind! and pool
distribution may change anyway).

Again, a simple high % miner consensus fork with a reasonable minimum
activation time avoids all these problems, with far less code
complexity.

--
https://petertodd.org 'peter'[:-1]@petertodd.org
00000000000000000711a9829e87ba8ea548f1793950893043a5dc56893dc1dc

Anthony Towns via bitcoin-dev

2016-02-07 15:19:27 UTC

Post by Gavin Andresen via bitcoin-dev
There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners (they
upgrade VERY quickly from 75% to over 95%).

The stated reasoning for 75% versus 95% is "because it gives "veto power"
to a single big solo miner or mining pool". But if a 20% miner wants to
"veto" the upgrade, with a 75% threshold, they could instead simply use
their hashpower to vote for an upgrade, but then not mine anything on
the new chain. At that point there'd be as little as 55% mining the new
2MB chain with 45% of hashpower remaining on the old chain. That'd be 18
minute blocks versus 22 minute blocks, which doesn't seem like much of
a difference in practice, and at that point hashpower could plausibly
end up switching almost entirely back to the original consensus rules
prior to the grace period ending.

With a non-consensus fork, I think you need to expect people involved to
potentially act in ways that aren't very gentlemanly, and guard against
it if you want the fork to be anything other than a huge mess.

Cheers,
aj

Jonathan Toomim via bitcoin-dev

2016-02-07 17:10:39 UTC

Post by Anthony Towns via bitcoin-dev
The stated reasoning for 75% versus 95% is "because it gives "veto power"
to a single big solo miner or mining pool". But if a 20% miner wants to
"veto" the upgrade, with a 75% threshold, they could instead simply use
their hashpower to vote for an upgrade, but then not mine anything on
the new chain. At that point there'd be as little as 55% mining the new
2MB chain with 45% of hashpower remaining on the old chain. That'd be 18
minute blocks versus 22 minute blocks, which doesn't seem like much of
a difference in practice, and at that point hashpower could plausibly
end up switching almost entirely back to the original consensus rules
prior to the grace period ending.

Keep in mind that within a single difficulty adjustment period, the difficulty of mining a block on either chain will be identical. Even if the value of a 1MB branch coin is $100 and the hashrate on the 1 MB branch is 100 PH/s, and the value of a 2 MB branch coin is $101 and the hashrate on the 2 MB branch is 1000 PH/s, the rational thing for a miner to do (for the first adjustment period) is to mine on the 2 MB branch, because the miner would earn 1% more on that branch.

So you're assuming that 25% of the hashrate chooses to remain on the minority version during the grace period, and that 20% chooses to switch back to the minority side. The fork happens. One branch has 1 MB blocks every 22 minutes, and the other branch has 2 MB blocks every 18 minutes. The first branch cannot handle the pre-fork transaction volume, as it only has 45% of the capacity that it had pre-fork. The second one can, as it has 111% of the pre-fork capacity. This makes the 1 MB branch much less usable than the 2 MB branch, which in turn causes the market value of newly minted coins on that branch to fall, which in turn causes miners to switch to the more profitable 2MB branch. This exacerbates the usability difference, which exacerbates the price difference, etc. Having two competing chains with equal hashrate using the same PoW function and nearly equal features is not a stable state. Positive feedback loops exist to make the vast majority of the users and the hashrate join one side.

Basically, any miners who stick to the minority branch are going to lose a lot of money.

jl2012--- via bitcoin-dev

2016-02-07 17:24:25 UTC

You are making a very naïve assumption that miners are just looking for
profit for the next second. Instead, they would try to optimize their short
term and long term ROI. It is also well known that some miners would mine at
a loss, even not for ideological reasons, if they believe that their action
is beneficial to the network and will provide long term ROI. It happened
after the last halving in 2012. Without any immediate price appreciation,
the hashing rate decreased by only less than 10%

Loading Image...

From: bitcoin-dev-***@lists.linuxfoundation.org
[mailto:bitcoin-dev-***@lists.linuxfoundation.org] On Behalf Of Jonathan
Toomim via bitcoin-dev
Sent: Monday, 8 February, 2016 01:11
To: Anthony Towns <***@erisian.com.au>
Cc: bitcoin-***@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
megabytes

On Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev
<bitcoin-***@lists.linuxfoundation.org
<mailto:bitcoin-***@lists.linuxfoundation.org> > wrote:

The stated reasoning for 75% versus 95% is "because it gives "veto power"
to a single big solo miner or mining pool". But if a 20% miner wants to
"veto" the upgrade, with a 75% threshold, they could instead simply use
their hashpower to vote for an upgrade, but then not mine anything on
the new chain. At that point there'd be as little as 55% mining the new
2MB chain with 45% of hashpower remaining on the old chain. That'd be 18
minute blocks versus 22 minute blocks, which doesn't seem like much of
a difference in practice, and at that point hashpower could plausibly
end up switching almost entirely back to the original consensus rules
prior to the grace period ending.

Keep in mind that within a single difficulty adjustment period, the
difficulty of mining a block on either chain will be identical. Even if the
value of a 1MB branch coin is $100 and the hashrate on the 1 MB branch is
100 PH/s, and the value of a 2 MB branch coin is $101 and the hashrate on
the 2 MB branch is 1000 PH/s, the rational thing for a miner to do (for the
first adjustment period) is to mine on the 2 MB branch, because the miner
would earn 1% more on that branch.

So you're assuming that 25% of the hashrate chooses to remain on the
minority version during the grace period, and that 20% chooses to switch
back to the minority side. The fork happens. One branch has 1 MB blocks
every 22 minutes, and the other branch has 2 MB blocks every 18 minutes. The
first branch cannot handle the pre-fork transaction volume, as it only has
45% of the capacity that it had pre-fork. The second one can, as it has 111%
of the pre-fork capacity. This makes the 1 MB branch much less usable than
the 2 MB branch, which in turn causes the market value of newly minted coins
on that branch to fall, which in turn causes miners to switch to the more
profitable 2MB branch. This exacerbates the usability difference, which
exacerbates the price difference, etc. Having two competing chains with
equal hashrate using the same PoW function and nearly equal features is not
a stable state. Positive feedback loops exist to make the vast majority of
the users and the hashrate join one side.

Basically, any miners who stick to the minority branch are going to lose a
lot of money.

Jonathan Toomim via bitcoin-dev

2016-02-07 17:56:48 UTC

You are making a very naïve assumption that miners are just looking for profit for the next second. Instead, they would try to optimize their short term and long term ROI. It is also well known that some miners would mine at a loss, even not for ideological reasons, if they believe that their action is beneficial to the network and will provide long term ROI. It happened after the last halving in 2012. Without any immediate price appreciation, the hashing rate decreased by only less than 10%

In 2012, revenue dropped by about 50% instantaneously. That does not mean that profitability became negative.

The difficulty at the time of the halving was about 3M. The exchange rate was about $12. A common miner at the time was the Radeon 6970, which performed about 350 Mh/s on 200 W for about 1.75 Mh/J. A computer with 4 6970s would use about 1 kW of power, once AC/DC losses and CPU overhead are taken into account. This 1 kW rig would have earned about $0.22/kWh before the halving, and $0.11/kWh after the halving. Since it's not hard to find electricity cheaper than $0.11/kWh, the hashrate didn't drop much.

It's a common misconception that the mining hashrate increases until an equilibrium is reached, and nobody is making a profit any longer. However, this is not true. The hashrate stops increasing when the expected operating profit over a reasonable time frame is no longer greater than the hardware cost, not when the operating profit approaches zero. For example, an S7 right now costs a little over $1000. If I don't expect to earn more than $1000 in operating profit over the next year or two with an S7, then I won't buy one.

Right now, an S7 earns about $190/month and costs about $60/month to operate, for a profit of $120/month. After the halving, revenue would drop to $95/month (or less, depending on difficulty and exchange rate), leaving profit at about $35/month. The $120/month profit is good enough motivation to buy hardware now, and the $35/month would be good enough motivation to keep running hardware after the halving.

I know in advance when the halvings are coming. There's going to be one in about 5 months, for example. I'm going to stop buying miners before the halving even if they're very profitable for a month because I don't want to be stuck with hardware that won't reach 100% return on investment (ROI).

Luke Dashjr via bitcoin-dev

2016-02-07 21:01:13 UTC

Post by Gavin Andresen via bitcoin-dev
On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <

Post by Tom Zander via bitcoin-dev
If you have a node that is "old" your node will stop getting new
blocks. The node will essentially just say "x-hours behind" with "x"
getting larger every hour. Funds don't get confirmed. etc.

Until someone decides to attack you. Then you'll get 6, 10, maybe more
blocks confirming a large 10000 BTC payment. If you're just a normal end
user (or perhaps an automated system), you'll figure that payment is good
and irreversibly hand over the title to the house.

There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners (they
upgrade VERY quickly from 75% to over 95%).

I'm assuming there are literally ZERO miners left on the weaker branch.
The attacker in this scenario simply rents hashing for a few days in advance
to build his fake chain, then broadcasts the blocks to the unsuspecting
merchant at ~10 block intervals so it looks like everything is working normal
again. There are lots of mining rental services out there, and miners quite
often do not care to avoid selling hashrate to the highest bidder regardless
of what they're mining. 10 blocks worth costs a little more than 250 BTC -
soon, that will be 125 BTC.

Luke

Steven Pine via bitcoin-dev

2016-02-07 21:33:13 UTC

Is it me or did Gavin ignore Yifu's direct questions? In case you missed it
Gavin --

~
"We can look at the adoption of the last major Bitcoin core release to
guess how long it might take people to upgrade. 0.11.0 was released on 12
July, 2015. Twenty eight days later, about 38% of full nodes were running
that release. Three months later, about 50% of the network was running that
release, and six months later about 66% of the network was running some
flavor of 0.11."

On what grounds do you think it is reasonable to assume that this update
will roll out 6x faster than previous data suggested, as oppose to your own
observation of 66% adoption in 6 month. or do you believe 38% node
upgrade-coverage (in 28 days ) on the network for a hard fork is good
enough?

There are no harm in choosing a longer grace period but picking one short
as 28 days you risk on alienating the nodes who do not upgrade with the
aggressive upgrade timeline you proposed.
~~

When Gavin writes "Responding to "28 days is not long enough" :

I keep seeing this claim made with no evidence to back it up. As I said, I
surveyed several of the biggest infrastructure providers and the btcd lead
developer and they all agree "28 days is plenty of time."

For individuals... why would it take somebody longer than 28 days to either
download and restart their bitcoind, or to patch and then re-run (the patch
can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?"

~~

Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
propositional a priori logic, but empirical evidence that. As for why
people take longer, who knows, we simply know from passed experience that
it in fact does take longer.

It's extremely frustrating to read Gavin's comments, it's hard to believe
he is engaging in earnest discussion.

On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <

Post by Gavin Andresen via bitcoin-dev
On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <

On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev

Until someone decides to attack you. Then you'll get 6, 10, maybe more
blocks confirming a large 10000 BTC payment. If you're just a normal

end

user (or perhaps an automated system), you'll figure that payment is

good

and irreversibly hand over the title to the house.

There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners

(they

Post by Gavin Andresen via bitcoin-dev
upgrade VERY quickly from 75% to over 95%).

--
Steven Pine
(510) 517-7075

Steven Pine via bitcoin-dev

2016-02-07 22:25:40 UTC

I agree that it seems like a safe assumption that adoption would be faster,
whether it is "very safe" and "significantly faster", whether it will be 6
times faster, all of those assumptions seems significantly less safe and
robust to me.

The nature of the bitcoin protocol, that it is a decentralized census based
protocol involving currency, suggests to me that roll out schedules ought
to be conservative with a minimum of assumptions. In light of the most
recent protocol upgrade, 6 months for this hard fork seems to me to be the
most conservative time frame with the fewest assumptions.

As for why it needs to be so fast, ie what are the dangers of it being as
slow as 6 months?

Gavin writes:

"I strongly disagree with the statement that there is no cost to a longer
grace period. There is broad agreement that a capacity increase is needed
NOW."

~~
"Broad agreement", that really seems to be another assumption, the fact
that the debate has been as long and acrimonious as it has been suggests
that there isn't broad agreement. Also, resorting to "SHOUTING" doesn't win
any favors when it comes to engaging in reasonable discussion om the
technical merits of a proposal.

We don't have any evidence of how fast nodes will upgrade when faced with
an impending hard fork, but it seems like a very safe assumption that the
"upgrade or be kicked off the network". In the previous cases it has been,
"here's the latest and greatest, give it a go!". Also, there will be
alerts sent out warning people of the situation, prompting them to take
action.
It is unclear if this will translate into more or less than 6x the
adoption speed of previous instances, but the idea that it would be faster
is solid. 28 days is aggressive, but again, it is only 28 days from when
the fork triggers. Compatible software is already available for anyone who
wants to prepare.
It is also of significance that this proposed fork, and this debate, has
been going on for many, many months. If someone proposed a forking concept
today, wrote the BIP tomorrow, deployed it next week, miners adopted it
instantly, and 28 days later it was the flag day, those 28 days would be in
a different context. There is no surprise here.
On Sun, Feb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev <

Post by Steven Pine via bitcoin-dev
Is it me or did Gavin ignore Yifu's direct questions? In case you missed
it Gavin --
~
"We can look at the adoption of the last major Bitcoin core release to
guess how long it might take people to upgrade. 0.11.0 was released on 12
July, 2015. Twenty eight days later, about 38% of full nodes were
running that release. Three months later, about 50% of the network was
running that release, and six months later about 66% of the network was
running some flavor of 0.11."
On what grounds do you think it is reasonable to assume that this update
will roll out 6x faster than previous data suggested, as oppose to your own
observation of 66% adoption in 6 month. or do you believe 38% node
upgrade-coverage (in 28 days ) on the network for a hard fork is good
enough?
There are no harm in choosing a longer grace period but picking one short
as 28 days you risk on alienating the nodes who do not upgrade with the
aggressive upgrade timeline you proposed.
~~
I keep seeing this claim made with no evidence to back it up. As I said,
I surveyed several of the biggest infrastructure providers and the btcd
lead developer and they all agree "28 days is plenty of time."
For individuals... why would it take somebody longer than 28 days to
either download and restart their bitcoind, or to patch and then re-run
(the patch can be a one-line change MAX_BLOCK_SIZE from 1000000 to
2000000)?"
~~
Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
propositional a priori logic, but empirical evidence that. As for why
people take longer, who knows, we simply know from passed experience that
it in fact does take longer.
It's extremely frustrating to read Gavin's comments, it's hard to believe
he is engaging in earnest discussion.
On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <

Post by Gavin Andresen via bitcoin-dev
On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <

On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev

Post by Tom Zander via bitcoin-dev
If you have a node that is "old" your node will stop getting new
blocks. The node will essentially just say "x-hours behind" with

"x"

Post by Tom Zander via bitcoin-dev
getting larger every hour. Funds don't get confirmed. etc.

Until someone decides to attack you. Then you'll get 6, 10, maybe

blocks confirming a large 10000 BTC payment. If you're just a normal

end

user (or perhaps an automated system), you'll figure that payment is

good

and irreversibly hand over the title to the house.

There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners

(they

Post by Gavin Andresen via bitcoin-dev
upgrade VERY quickly from 75% to over 95%).

--
Steven Pine
(510) 517-7075
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
Steven Pine
(510) 517-7075

Chris Priest via bitcoin-dev

2016-02-06 20:22:30 UTC

Its mostly a problem for exchanges and miners. Those entities need to
be on the network 100% of the time because they are using the network
100% of the time. A normal wallet user isn't taking payments every few
minutes like the exchanges are. "Getting booted off the network" is
not something to worry about for normal wallet users.

If miners aren't up to date, that is the biggest problem. A sudden
drop in hashpower will effect the network for all users, including
normal wallet users (by them having to wait longer for confirmations).
Miners must not be booted off the network ever. Hashpower voting is
the best way to make sure this never happens.

On 2/6/16, Tom Zander via bitcoin-dev

Post by Jorge TimÃ³n via bitcoin-dev
None of the reasons you list say anything about the fact that "being lost"
(kicked out of the network) is a problem for those node's users.

That's because its not.
If you have a node that is "old" your node will stop getting new blocks.
The node will essentially just say "x-hours behind" with "x" getting larger
every hour. Funds don't get confirmed. etc.
After upgrading the software they will see the new reality of the network.
Nobody said its a problem, because its not.
--
Tom Zander
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Luke Dashjr via bitcoin-dev

2016-02-06 20:36:23 UTC

Post by Gavin Andresen via bitcoin-dev
I suspect there ARE a significant percentage of un-maintained full nodes--

Do you have evidence these are intentionally unmaintained, and not users who
have simply not had time to review and decide on upgrading?

Post by Gavin Andresen via bitcoin-dev
There is broad agreement that a capacity increase is needed NOW.

If so, it is only based on misinformation. I am concerned you are implying
this conclusion is true. When I spoke with you maybe a year ago with my
concerns that block size might grow too fast, you suggested that the miners
could be trusted to not increase the block size until necessary (which is not
likely to be any time soon, despite the massive misinformation campaigns out
there).

Post by Gavin Andresen via bitcoin-dev
On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev

Post by Gavin Andresen via bitcoin-dev
Miners express their support for this BIP by ...

But miners don't get to decide hardforks. How does the economy
express their support for it? What happens if miners trigger it
without consent from the economy?

"The economy" does support this.

I have seen evidence which suggests the contrary. For example:
https://twitter.com/barrysilbert/status/694911989701861376

Where is yours?

Post by Luke Dashjr via bitcoin-dev
If you are intent on using the version bits to trigger the
hardfork, I suggest rephrasing this such that miners should
only enable the bit when they have independently confirmed
economic support (this means implementations need a config
option that defaults to off).

Happy to add words about economic majority.
Classic will not implement a command-line option (the act of running
Classic is "I opt in"), but happy to add one for a pull request to Core,
assuming Core would not see such a pull request as having any hostile
intent.

But this isn't about the miner opting in, it is about the miner *observing
economic support* for the change. I have successfully downloaded Bitcoin
Classic's beta binaries without ANY warning that by running it, I am
expressing that I believe the economy has approved of a hardfork.

Post by Luke Dashjr via bitcoin-dev
SPV (simple payment validation) wallets are compatible with this change.

Would prefer if this is corrected to "Light clients" or something.
Actual SPV wallets do not exist at this time, and would not be
compatible with a hardfork.

Is there an explanation of SPV versus "Light Client" written somewhere more
permanent than a reddit comment or forum post that I can point to?

Not that I am aware of. (But both reddit comments and forum posts have
outlived many other posts, such as blogs, so I'm not sure why to exclude them
specifically...)

In any case, since SPV nodes don't exist, there is probably no real need to
address them. Everyone will know what "light client" means.

Post by Luke Dashjr via bitcoin-dev
2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
insecure.

I haven't been paying attention to all of the
"soft-hardfork/hard-softfork/etc" terminology so have no idea what you
mean. Is THAT written up somewhere?

Working on a BIP draft for it, but it's not ready for publication yet. The
basic idea is to turn the merkle root in the block header into simply a hash
of a second block header, which is constructed to parse as a valid empty
generation transaction under the old rules. Thus, old nodes see the forked
blockchain as valid with continually growing work on it, but as if the blocks
were all empty. This protects them from attackers mining a short blockchain
they perceive as valid.

Luke

Jannes Faber via bitcoin-dev

2016-02-07 05:21:00 UTC

On 6 Feb 2016 4:41 p.m., "Gavin Andresen via bitcoin-dev" <

Post by Gavin Andresen via bitcoin-dev
I keep seeing this claim made with no evidence to back it up. As I said,

I surveyed several of the biggest infrastructure providers and the btcd
lead developer and they all agree "28 days is plenty of time."

28 days doesn't sound like enough for exchanges and others holding 3rd
party coins. They will have to start untangling the Bitcoins from
classiccoins immediately, while pausing all withdrawals. They *must* be
able to send their customers both coins as separate withdrawals. If not,
that amounts to theft of their customers funds.

(Note that the above describes the honest exchanges. Imagine the dishonest
ones that simply steal the classiccoins from their customers and sell them
for their own profit.)

The only other option is guaranteeing customers both coins in one
transaction, which they can't.

Surely you can't expect small entities to start putting in massive man
hours into this even before the hard fork has been triggered? Or even big
entities to have all that implemented and tested within *20* working days?

--
Jannes

Jonathan Toomim via bitcoin-dev

2016-02-07 18:55:52 UTC

They *must* be able to send their customers both coins as separate withdrawals.

Supporting the obsolete chain is unnecessary. Such support has not been offered in any cryptocurrency hard fork before, as far as I know. I do not see why it should start now.

If not, that amounts to theft of their customers funds.

If they announce their planned behavior before the fork, I do not see any ethical or legal issues.

Patrick Strateman via bitcoin-dev

2016-02-07 19:03:54 UTC

I would expect that custodians who fail to produce coins on both sides
of a fork in response to depositor requests will find themselves in
serious legal trouble.

Especially if the price moves against either fork.

On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev

They *must* be able to send their customers both coins as separate withdrawals.

Supporting the obsolete chain is unnecessary. Such support has not
been offered in any cryptocurrency hard fork before, as far as I know.
I do not see why it should start now.

If not, that amounts to theft of their customers funds.

If they announce their planned behavior before the fork, I do not see
any ethical or legal issues.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Trevin Hofmann via bitcoin-dev

2016-02-07 19:19:44 UTC

Patrick,

I would say that a company's terms of service should include their position
on this issue. It does not seem reasonable that they all are required to
provide access to coins on every single fork. Are custodial wallet users
also entitled to Clam, Zcash, and Decred, and others?

Regardless, I think this thread should be about the technical merits of the
BIP. Discussion of hard forks would be better held elsewhere.

On Sun, Feb 7, 2016 at 1:03 PM, Patrick Strateman via bitcoin-dev <

Post by Patrick Strateman via bitcoin-dev
I would expect that custodians who fail to produce coins on both sides
of a fork in response to depositor requests will find themselves in
serious legal trouble.
Especially if the price moves against either fork.

On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev

They *must* be able to send their customers both coins as separate withdrawals.

Supporting the obsolete chain is unnecessary. Such support has not
been offered in any cryptocurrency hard fork before, as far as I know.
I do not see why it should start now.

If not, that amounts to theft of their customers funds.

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

Tier Nolan via bitcoin-dev

2016-02-07 20:29:42 UTC

On Sun, Feb 7, 2016 at 7:03 PM, Patrick Strateman via bitcoin-dev <

If the exchange uses an UTXO from before the fork to pay their clients,
then they are guaranteed to count as paying on all forks. The exchange
doesn't need to specifically pay out for each fork.

As long as the exchange doesn't accidently double spend an output, even
change addresses are valid.

It is handling post-fork deposits where the problem can occur. If they
only receive coins on one fork, then that should cause the client to be
credited with funds on both forks.

The easiest thing would be to refuse to accept deposits for a while
before/after the fork happens.
<https://www.avast.com/sig-email> This email has been sent from a
virus-free computer protected by Avast.
www.avast.com <https://www.avast.com/sig-email>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Gavin Andresen via bitcoin-dev

2016-02-09 16:54:14 UTC

There are 406 nodes total that falls under the un-maintained category,
which is below 10% of the network.
Luke also have some data here that shows similar results.
http://luke.dashjr.org/programs/bitcoin/files/charts/versions.txt

I love seeing data! I was considering 0.10 nodes as 'unmaintained' because
it has been a long time since the 0.11 release.

Post by Gavin Andresen via bitcoin-dev
The network could shrink by 60% and it would still have plenty of open
connection slots

I'm afraid we have to agree to disagree if you think dropping support for
60% of the nodes on the network when rolling out an upgrade is the sane
default.

That is my estimate of the worst-case-- not 'sane default.'

My point is that even if the number of nodes shrank by 60%, we would not
see any issues (SPV nodes would still have no problem finding a full node
to connect to, full nodes would not have any problem connecting to each
other, and we would not be significantly more vulnerable to Sybil attacks
or "governments get together and try to ban running a full node" attacks).

Post by Gavin Andresen via bitcoin-dev
People are committing to spinning up thousands of supports-2mb-nodes

during the grace period.

thousands of nodes?! where did you get this figure? who are these people?
*Please* elaborate.

There are over a thousand people subscribed to the Classic slack channel,
many of whom have privately told me they are willing and able to run an
extra node or three (or a hundred-and-eleven) once there is a final release.

I'm not going to name names, because
a) these were private communications, and
b) risk of death threats, extortion, doxxing, DoS attacks, etc. Those
risks aren't theoretical, they are very real.

To be clear: I will discourage and publicly condemn anybody who runs
'pseudo nodes' or plans to spin up lots of nodes to try to influence the
debate. The only legitimate reason to run extra nodes is to fill in a
possible gap in total node count that might be caused by old, unmaintained
nodes that stop serving blocks because the rest of the network has upgraded.

We could wait a year and pick up maybe 10 or 20% more.
I don't understand this statement at all, please explicate.

The adoption curve for a new major release is exponential: lots of adoption
in the first 30 days or so, then it rapidly tapers off. Given that
people's nodes will be alerting them that they must upgrade, and given that
every source of Bitcoin news will probably be covering the miner adoption
vote like it was a presidential election, I expect the adoption curve for
the 2mb bump to be steeper than we've ever seen. So my best guess is
70-80% of nodes will upgrade within 30 days of the miner voting hitting 50%
of blocks and triggering the automatic 'version obsolete; upgrade required'
warning.

Wait a year, and my guess is you might reach another 10-20% (80 to
90-something percent).

David Vorick via bitcoin-dev

2016-02-10 06:14:13 UTC

Post by Gavin Andresen via bitcoin-dev
I love seeing data! I was considering 0.10 nodes as 'unmaintained'

because it has been a long time since the 0.11 release.

https://packages.gentoo.org/packages/net-p2p/bitcoin-qt

The Gentoo package manager still has 0.10.2 as the most recent stable
version. Getting a later version of the software on a gentoo setup requires
explicitly telling the package manger to grab a later version. I don't know
what percent of nodes are Gentoo 0.10.2, but I think it's evidence that
0.10 should not be considered 'unmaintained'. People who update their
software regularly will be running 0.10 on Gentoo.

Post by Gavin Andresen via bitcoin-dev
many of whom have privately told me they are willing and able to run an

extra node or three (or a hundred-and-eleven) once there is a final release.

I'm not clear on the utility of more nodes. Perhaps there is significant
concern about SPV nodes getting enough bandwidth or the network struggling
from the load? Generally though, I believe that when people talk about the
deteriorating full node count they are talking about a reduction in
decentralization. Full nodes are a weak indicator of how likely something
like a change in consensus rules is to get caught, or how many people you
would need to open communication with / extort in order to be able to force
rules upon the network. Having a person spin up multiple nodes doesn't
address either of those concerns, which in my understanding is what most
people care about. My personal concern is with the percentage of the
economy that is dependent on trusting the full nodes they are connected to,
and the overall integrity of that trust. (IE how likely is it that my SPV
node is going to lie to me about whether or not I've received a payment).

I will also point out that lots of people will promise things when they are
seeking political change. I don't know what percentage of promised nodes
would actually be spun up, but I'm guessing that it's going to be
significantly less than 100%. I have similar fears for companies that claim
they have tested their infrastructure for supporting 2MB blocks. Talk is
cheap.

Patrick Shirkey via bitcoin-dev

2016-02-10 06:36:05 UTC

Post by David Vorick via bitcoin-dev

Post by Gavin Andresen via bitcoin-dev
I love seeing data! I was considering 0.10 nodes as 'unmaintained'

because it has been a long time since the 0.11 release.
https://packages.gentoo.org/packages/net-p2p/bitcoin-qt
The Gentoo package manager still has 0.10.2 as the most recent stable
version. Getting a later version of the software on a gentoo setup requires
explicitly telling the package manger to grab a later version. I don't know
what percent of nodes are Gentoo 0.10.2, but I think it's evidence that
0.10 should not be considered 'unmaintained'. People who update their
software regularly will be running 0.10 on Gentoo.

Post by Gavin Andresen via bitcoin-dev
many of whom have privately told me they are willing and able to run an

extra node or three (or a hundred-and-eleven) once there is a final release.
I'm not clear on the utility of more nodes. Perhaps there is significant
concern about SPV nodes getting enough bandwidth or the network struggling
from the load? Generally though, I believe that when people talk about the
deteriorating full node count they are talking about a reduction in
decentralization. Full nodes are a weak indicator of how likely something
like a change in consensus rules is to get caught, or how many people you
would need to open communication with / extort in order to be able to force
rules upon the network. Having a person spin up multiple nodes doesn't
address either of those concerns, which in my understanding is what most
people care about. My personal concern is with the percentage of the
economy that is dependent on trusting the full nodes they are connected to,
and the overall integrity of that trust. (IE how likely is it that my SPV
node is going to lie to me about whether or not I've received a payment).
I will also point out that lots of people will promise things when they are
seeking political change. I don't know what percentage of promised nodes
would actually be spun up, but I'm guessing that it's going to be
significantly less than 100%. I have similar fears for companies that claim
they have tested their infrastructure for supporting 2MB blocks. Talk is
cheap.

This is a good point. The rollout procedure needs to be fully tested
*before* any changes are enforced.

Has anyone provided conclusive results on system load demands with an
increase to 2MB? Extrapolating further to higher blocksizes will also be
useful to get an idea of the scope of the problem. If the system does jump
to 2MB it is unlikely that will be the ultimate limit so 4, 8, 16 etc...
should also be quantified.

We already hear of the high system load (energy/cost) requirements* for
nodes under the current blocksize which appears to have created a barrier
to entry for a lot of miners. If increasing to 2MB makes it even more
expensive in terms of hardware and energy costs to run a node that will
consolidate the nodes into the control of a few wealthy parties who can
afford to run the most powerful hardware. Conversely if the increase helps
the system and individual nodes run more efficiently then that would be a
big incentive for miners to upgrade.

* (these reports might be false/wrong/propaganda)

--
Patrick Shirkey
Boost Hardware Ltd

Tier Nolan via bitcoin-dev

2016-02-10 12:58:01 UTC

On Wed, Feb 10, 2016 at 6:14 AM, David Vorick via bitcoin-dev <

Post by David Vorick via bitcoin-dev
I'm not clear on the utility of more nodes. Perhaps there is significant
concern about SPV nodes getting enough bandwidth or the network struggling
from the load?

It is unfortunate that when pruning is activated, the NODE_NETWORK bit is
cleared. This means that supporting SPV clients means running full nodes
without pruning. OTOH, a pruning node could support SPV clients that sync
more often than once every few days, especially if it stores a few GB of
block data.

Peter Todd via bitcoin-dev

2016-02-06 22:22:21 UTC

Post by Gavin Andresen via bitcoin-dev
2) People are committing to spinning up thousands of supports-2mb-nodes
during the grace period.

Why wouldn't an attacker be able to counter-sybil-attack that effort?

Who are these people?

Post by Gavin Andresen via bitcoin-dev
Would Blockstream be willing to help out by running a dozen or two extra
full nodes?

I'll remind everyone that Bitcoin Core does not condone participation in
network attacks to push controversial protcol changes through. I also
checked with Adam Back, who confirmed Blockstream as a company shares
those views.

For those readers unfamiliar with Sybil attacks, basically what the
above does is prevents nodes from being able to finding peers with
accurate information about what blockchains exist - the above can be
used to prevent nodes from learning about the longest chain for
instance, or the existance of substantial support for a minority chain.
This is why we've advocated giving users sufficient time to actively
opt-in to protocol changes.

--
https://petertodd.org 'peter'[:-1]@petertodd.org
000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698

Anthony Towns via bitcoin-dev

2016-02-07 11:37:57 UTC