BIP proposal: Increase block size limit to 2 megabytes

BIP proposal: Increase block size limit to 2 megabytes
2016-02-05 22:36 ` Yifu Guo
                   ` (3 more replies)
  
From: Gavin Andresen @ 2016-02-05 20:51 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

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.

Draft BIP:
  https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki

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

Blog post walking through the code:
  http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork

Blog post on a couple of the constants chosen:
  http://gavinandresen.ninja/seventyfive-twentyeight

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1466 bytes --]

 permalink raw reply	[|nested]
2016-02-05 22:36 ` 
                   ` 
  
From: Gavin Andresen @ 2016-02-05 20:51 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

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.

Draft BIP:
  https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki

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

Blog post walking through the code:
  http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork

Blog post on a couple of the constants chosen:
  http://gavinandresen.ninja/seventyfive-twentyeight

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1466 bytes --]

 permalink raw reply	[|nested]
* 
  2016-02-05 20:51 [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes Gavin Andresen

  2016-02-07 17:09   ` Gavin Andresen
  2016-02-05 23:04 ` 
                   ` 
  3 siblings, 1 reply; 42+ messages in thread
From: Yifu Guo @ 2016-02-05 22:36 UTC (permalink / raw)
  To: Gavin Andresen;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2152 bytes --]

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

> 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.
>
> Draft BIP:
>   https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki
>
> Summary:
>   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
>
> Blog post walking through the code:
>   http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
>
> Blog post on a couple of the constants chosen:
>   http://gavinandresen.ninja/seventyfive-twentyeight
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


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

[-- Attachment #2: Type: text/html, Size: 3721 bytes --]

^ permalink raw reply	[|nested] 42+ messages in thread
2016-02-05 20:51 [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes Gavin Andresen
  2016-02-05 22:36 ` Yifu Guo
  2016-02-05 23:04 ` Btc Drak

  2016-02-06  3:14   ` Jorge Timón
  2016-02-07 11:37 ` Anthony Towns
  
From: Luke Dashjr @ 2016-02-06  0:12 UTC (permalink / raw)
  To: bitcoin-dev, Gavin Andresen

On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev wrote:
> Blog post on a couple of the constants chosen:
>   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)?

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

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

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

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

> 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


 permalink raw reply	[|nested]
2016-02-06  0:12 ` Luke Dashjr

  2016-02-06 15:37     ` Gavin Andresen
  
From: Jorge Timón @ 2016-02-06  3:14 UTC (permalink / raw)
  To: Luke Dashjr;  Bitcoin Dev

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
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev wrote:
>> Blog post on a couple of the constants chosen:
>>   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)?
>
>> 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?
>
>> 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?
>
>> 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).
>
>> 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.
>
>> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


 permalink raw reply	[|nested]
2016-02-06  3:14   ` Jorge Timón

  2016-02-06 17:01       ` Adam Back
                         ` (5 more replies)
  
From: Gavin Andresen @ 2016-02-06 15:37 UTC (permalink / raw)
  To: Jorge Timón;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 6890 bytes --]

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
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev
> wrote:
> >> Blog post on a couple of the constants chosen:
> >>   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.


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


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

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.



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


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


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

Happy to remove.


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

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.

> 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

[-- Attachment #2: Type: text/html, Size: 10506 bytes --]

 permalink raw reply	[|nested]
2016-02-06  3:14   ` Jorge Timón

  2016-02-06 17:01       ` 
                         ` 
  
From: Gavin Andresen @ 2016-02-06 15:37 UTC (permalink / raw)
  To: Jorge Timón;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 6890 bytes --]

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
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev
> wrote:
> >> Blog post on a couple of the constants chosen:
> >>   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.


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


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

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.



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


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


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

Happy to remove.


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

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.

> 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

[-- Attachment #2: Type: text/html, Size: 10506 bytes --]

 permalink raw reply	[|nested]
* 
  2016-02-06 15:37     ` Gavin Andresen

  2016-02-06 17:45         ` Gavin Andresen
  2016-02-07 18:49         ` Chris Priest
  2016-02-06 17:09       ` 
                         ` 
  5 siblings, 2 replies; 42+ messages in thread
From: Adam Back @ 2016-02-06 17:01 UTC (permalink / raw)
  To: Gavin Andresen;  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
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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
>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> > On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev
>> > wrote:
>> >> Blog post on a couple of the constants chosen:
>> >>   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.
>
>>
>> >
>> >> 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.
>
>>
>> >
>> >> 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?
>
>
> 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.
>
>
>>
>> >
>> >> 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.
>
>
>> >
>> >> 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?
>
>>
>> >
>> >> 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).
>
>
> Happy to remove.
>
>>
>> > 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).
>
>
> 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.
>
>> > 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
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


^ permalink raw reply	[|nested] 42+ messages in thread
2016-02-06 17:09       ` Jorge Timón

  2016-02-06 20:22           ` Chris Priest
  2016-02-06 20:46           ` Luke Dashjr
  
From: Tom Zander @ 2016-02-06 17:25 UTC (permalink / raw)
  To: bitcoin-dev

On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev wrote:
> 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


 permalink raw reply	[|nested]
2016-02-06 17:01       ` Adam Back

  2016-02-06 21:11           ` Peter Todd
  2016-02-06 21:28           ` David Thomson
  2016-02-07 18:49         ` Chris Priest
  
From: Gavin Andresen @ 2016-02-06 17:45 UTC (permalink / raw)
  To: Adam Back;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]

On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam@cypherspace•org> wrote:

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



> , 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/


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


> 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
monitoring, and miners and people and businesses will manage the network,
as they do every day.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 3386 bytes --]

 permalink raw reply	[|nested]
2016-02-06 17:25         ` Tom Zander

  2016-02-06 20:46           ` Luke Dashjr
  
From: Chris Priest @ 2016-02-06 20:22 UTC (permalink / raw)
  To: Tom Zander;  bitcoin-dev

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
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev
> wrote:
>> 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
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


 permalink raw reply	[|nested]
* 
  2016-02-06 15:37     ` Gavin Andresen
  2016-02-06 17:01       ` Adam Back

  2016-02-06 17:25         ` Tom Zander
  2016-02-06 20:36       ` 
                         ` 
  5 siblings, 1 reply; 42+ messages in thread
From: Jorge Timón @ 2016-02-06 17:09 UTC (permalink / raw)
  To: Gavin Andresen;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]

On Feb 6, 2016 16:37, "Gavin Andresen" <gavinandresen@gmail•com> wrote:
>
> Responding to "28 days is not long enough" :

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

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

> I strongly disagree with the statement that there is no cost to a longer
grace period.

I didn't say that.

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

[-- Attachment #2: Type: text/html, Size: 1882 bytes --]

^ permalink raw reply	[|nested] 42+ messages in thread
2016-02-06 17:25         ` Tom Zander
  2016-02-06 20:22           ` Chris Priest

  2016-02-07 14:16             ` Gavin Andresen
  
From: Luke Dashjr @ 2016-02-06 20:46 UTC (permalink / raw)
  To: bitcoin-dev, Tom Zander

On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev wrote:
> On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev 
wrote:
> > 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.

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


 permalink raw reply	[|nested]
2016-02-06 17:45         ` Gavin Andresen

  2016-02-06 21:24             ` Peter Todd
  2016-02-09  5:11             ` Samson Mow
  2016-02-06 21:28           ` David Thomson
  
From: Peter Todd @ 2016-02-06 21:11 UTC (permalink / raw)
  To: Gavin Andresen;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]

On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev wrote:
> On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam@cypherspace•org> wrote:
> 
> >
> > 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

> > , 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/

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

> > 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 unaware of Not Bitcoin XT?

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

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

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

 permalink raw reply	[|nested]
2016-02-06 21:11           ` Peter Todd

  2016-02-09  5:11             ` Samson Mow
  
From: Peter Todd @ 2016-02-06 21:24 UTC (permalink / raw)
  To: Gavin Andresen, Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]

On Sat, Feb 06, 2016 at 04:11:58PM -0500, Peter Todd via bitcoin-dev wrote:
> On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev wrote:
> > On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam@cypherspace•org> wrote:
> > 
> > >
> > > 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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

 permalink raw reply	[|nested]
2016-02-06 17:45         ` Gavin Andresen
  2016-02-06 21:11           ` Peter Todd

  
From: David Thomson @ 2016-02-06 21:28 UTC (permalink / raw)
  To: Gavin Andresen;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 4684 bytes --]

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!

On Feb 6, 2016, at 12:45 PM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:

>> On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam@cypherspace•org> wrote:
>> 
>> 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?

> 
>  
>> , 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/

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?

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

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

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

[-- Attachment #2: Type: text/html, Size: 12129 bytes --]

 permalink raw reply	[|nested]
* 
  2016-02-06 15:37     ` Gavin Andresen
  2016-02-06 17:01       ` Adam Back
  2016-02-06 17:09       ` Jorge Timón

  2016-02-06 22:22       ` 
                         ` 
  5 siblings, 0 replies; 42+ messages in thread
From: Luke Dashjr @ 2016-02-06 20:36 UTC (permalink / raw)
  To: Gavin Andresen;  Bitcoin Dev

On Saturday, February 06, 2016 3:37:30 PM Gavin Andresen wrote:
> 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?

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

> On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr 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?

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

> > > 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.
 
> > I would also prefer to see any hardfork:
> > 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


^ permalink raw reply	[|nested] 42+ messages in thread
2016-02-06 15:37     ` Gavin Andresen
                         ` (3 preceding siblings ...)
  2016-02-06 22:22       ` Peter Todd

  2016-02-07 18:55         ` Jonathan Toomim
  2016-02-09 13:59       ` Yifu Guo
  
From: Jannes Faber @ 2016-02-07  5:21 UTC (permalink / raw)
  To: Gavin Andresen;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

On 6 Feb 2016 4:41 p.m., "Gavin Andresen via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> 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."

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

[-- Attachment #2: Type: text/html, Size: 1456 bytes --]

 permalink raw reply	[|nested]
2016-02-05 20:51 [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes Gavin Andresen
                   ` (2 preceding siblings ...)
  2016-02-06  0:12 ` Luke Dashjr

  
From: Anthony Towns @ 2016-02-07 11:37 UTC ( / )
  To: bitcoin-dev

On Fri, Feb 05, 2016 at 03:51:08PM -0500, Gavin Andresen via bitcoin-dev wrote:
> Constructive feedback welcome; [...]
> Summary:
>   Increase block size limit to 2,000,000 bytes.
>   With accurate sigop counting, but existing sigop limit (20,000)
>   And a new, high limit on signature hashing

To me, it seems absurd to have a hardfork but not take the opportunity
to combine these limits into a single weighted sum.

I'd suggest:

   0.5*blocksize + 50*accurate_sigops + 0.001*sighash < 2,000,000

That provides worst case blocksize of 4MB, worst case sigops of 40,000
and worst case sighash bytes of 2GB. Given the separate limit on sighash
bytes and the improvements from libsecp256k1 I think 40k sigops should
be fine, but I'm happy to be corrected.

For a regular transaction, of say 380 bytes with 2 sigops and hashing
about 800 bytes, that uses up about 291 units of the limit, meaning
that if a block was full of transactions of that form, the limit would
be 6872 tx or 2.6MB per block (along with 13.7k sigops and ~5.5MB hashed
for signatures).  Those weightings could probably be improved by doing
some detailed analysis and measurements, but I think they're pretty
reasonable for round figures.

The main advantage is that it would prevent blocks being cheaply filled
up due to hitting one of the secondary limits but only paying for the
contribution to the primary limit (presumably block size), which avoids
denial of service spam attacks.

I think having the limit take UTXO increase (or decrease) into effect
would be helpful too; but I don't have a specific suggestion. If it's
just a matter of making the limit stronger (eg adding "0.25*max(0,change
in UTXO bytes)" to the formula on the left, but not changing the limit on
the right), that would be a soft-forking change that could be introduced
later, and maybe that's fine.

If there was time to actually iterate on this proposal, rather than an
apparent aim to get it out the door in the next month or two, I think it
would be good to also design it so that the parameters of the weighted
sum could be adjusted by a soft-fork in future rather than requiring a
hard fork every time a limit's reached, or a weighting can be relaxed.
But I don't think that's feasible to design within a few weeks, so I
think it's off the table given the activation goal.

Cheers,
aj
2016-02-06 20:46           ` Luke Dashjr

  2016-02-07 15:06               ` Alex Morcos
                                 ` (2 more replies)
  
From: Gavin Andresen @ 2016-02-07 14:16 UTC (permalink / raw)
  To: Luke Dashjr;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]

On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev wrote:
> > On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev
> wrote:
> > > 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.
>
> 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%).

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

[-- Attachment #2: Type: text/html, Size: 2764 bytes --]

 permalink raw reply	[|nested]
2016-02-06 20:46           ` Luke Dashjr

  2016-02-07 15:06               ` 
                                 ` 
  
From: Gavin Andresen @ 2016-02-07 14:16 UTC (permalink / raw)
  To: Luke Dashjr;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]

On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev wrote:
> > On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev
> wrote:
> > > 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.
>
> 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%).

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

[-- Attachment #2: Type: text/html, Size: 2764 bytes --]

 permalink raw reply	[|nested]
2016-02-07 14:16             ` Gavin Andresen
  2016-02-07 15:06               ` Alex Morcos

  2016-02-07 17:10                 ` Jonathan Toomim
  2016-02-07 21:01               ` Luke Dashjr
  
From: Anthony Towns @ 2016-02-07 15:19 UTC (permalink / raw)
  To: bitcoin-dev

On Sun, Feb 07, 2016 at 09:16:02AM -0500, Gavin Andresen via bitcoin-dev wrote:
> 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



 permalink raw reply	[|nested]
2016-02-07 15:06               ` Alex Morcos

  
From: Peter Todd @ 2016-02-07 16:54 UTC (permalink / raw)
  To: Alex Morcos;  bitcoin-discuss, Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

On Sun, Feb 07, 2016 at 10:06:06AM -0500, Alex Morcos via bitcoin-dev wrote:
> 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.

> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

 permalink raw reply	[|nested]
2016-02-05 22:36 ` Yifu Guo

  
From: Gavin Andresen @ 2016-02-07 17:09 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2721 bytes --]

 permalink raw reply	[|nested]
2016-02-07 15:19               ` Anthony Towns

  2016-02-07 17:24                   ` jl2012
  
From: Jonathan Toomim @ 2016-02-07 17:10 UTC (permalink / raw)
  To: Anthony Towns;  bitcoin-dev


[-- Attachment #1.1: Type: text/plain, Size: 2401 bytes --]


On Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev <bitcoin-dev@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.

[-- Attachment #1.2: Type: text/html, Size: 9388 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

 permalink raw reply	[|nested]
2016-02-07 17:10                 ` Jonathan Toomim

  2016-02-07 17:56                     ` Jonathan Toomim
  
From: jl2012 @ 2016-02-07 17:24 UTC (permalink / raw)
  To: 'Jonathan Toomim', 'Anthony Towns';  bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 3415 bytes --]

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%

 

http://bitcoin.sipa.be/speed-ever.png

 

 

From: bitcoin-dev-bounces@lists•linuxfoundation.org
[mailto:bitcoin-dev-bounces@lists•linuxfoundation.org] On Behalf Of Jonathan
Toomim via bitcoin-dev
Sent: Monday, 8 February, 2016 01:11
To: Anthony Towns <aj@erisian•com.au>
Cc: bitcoin-dev@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-dev@lists•linuxfoundation.org
<mailto:bitcoin-dev@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.

 

 


[-- Attachment #2: Type: text/html, Size: 7278 bytes --]

 permalink raw reply	[|nested]
2016-02-07 17:24                   ` jl2012

  
From: Jonathan Toomim @ 2016-02-07 17:56 UTC (permalink / raw)
  To: jl2012;  Bitcoin Dev, Anthony Towns


[-- Attachment #1.1: Type: text/plain, Size: 2429 bytes --]

On Feb 7, 2016, at 9:24 AM, jl2012@xbt•hk wrote:

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



[-- Attachment #1.2: Type: text/html, Size: 3231 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

 permalink raw reply	[|nested]
2016-02-06 17:01       ` Adam Back
  2016-02-06 17:45         ` Gavin Andresen

  
From: Chris Priest @ 2016-02-07 18:49 UTC (permalink / raw)
  To: Adam Back;  Bitcoin Dev

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
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> 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
>>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>> > On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev
>>> > wrote:
>>> >> Blog post on a couple of the constants chosen:
>>> >>   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.
>>
>>>
>>> >
>>> >> 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.
>>
>>>
>>> >
>>> >> 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?
>>
>>
>> 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.
>>
>>
>>>
>>> >
>>> >> 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.
>>
>>
>>> >
>>> >> 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?
>>
>>>
>>> >
>>> >> 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).
>>
>>
>> Happy to remove.
>>
>>>
>>> > 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).
>>
>>
>> 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.
>>
>>> > 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
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


 permalink raw reply	[|nested]
2016-02-07  5:21       ` Jannes Faber

  2016-02-07 19:03           ` Patrick Strateman
  
From: Jonathan Toomim @ 2016-02-07 18:55 UTC (permalink / raw)
  To: Jannes Faber;  Bitcoin Dev


[-- Attachment #1.1: Type: text/plain, Size: 536 bytes --]


On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:

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

[-- Attachment #1.2: Type: text/html, Size: 961 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

 permalink raw reply	[|nested]
2016-02-07 18:55         ` Jonathan Toomim

  2016-02-07 19:19             ` Trevin Hofmann
  2016-02-07 20:29             ` Tier Nolan
  
From: Patrick Strateman @ 2016-02-07 19:03 UTC (permalink / raw)
  To: 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 02/07/2016 10:55 AM, Jonathan Toomim via bitcoin-dev wrote:
>
> On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
>> 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
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



 permalink raw reply	[|nested]
2016-02-07 19:03           ` Patrick Strateman

  2016-02-07 20:29             ` Tier Nolan
  
From: Trevin Hofmann @ 2016-02-07 19:19 UTC (permalink / raw)
  To: Patrick Strateman;  bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

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

> 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 02/07/2016 10:55 AM, Jonathan Toomim via bitcoin-dev wrote:
> >
> > On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev
> > <bitcoin-dev@lists•linuxfoundation.org
> > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
> >
> >> 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
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2865 bytes --]

 permalink raw reply	[|nested]
2016-02-07 19:03           ` Patrick Strateman
  2016-02-07 19:19             ` Trevin Hofmann

  
From: Tier Nolan @ 2016-02-07 20:29 UTC (permalink / raw)
  Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

On Sun, Feb 7, 2016 at 7:03 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

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

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>

[-- Attachment #2: Type: text/html, Size: 2013 bytes --]

 permalink raw reply	[|nested]
2016-02-07 14:16             ` Gavin Andresen
  2016-02-07 15:06               ` Alex Morcos
  2016-02-07 15:19               ` Anthony Towns

  2016-02-07 21:33                 ` Steven Pine
  
From: Luke Dashjr @ 2016-02-07 21:01 UTC (permalink / raw)
  To: Gavin Andresen;  Bitcoin Dev

On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
> On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
> > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev 
wrote:
> > > 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


 permalink raw reply	[|nested]
2016-02-07 21:01               ` Luke Dashjr

  2016-02-07 22:04                   ` Corey Haddad
  
From: Steven Pine @ 2016-02-07 21:33 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 3726 bytes --]

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

> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
> > bitcoin-dev@lists•linuxfoundation.org> wrote:
> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
> wrote:
> > > > 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
Steven Pine
(510) 517-7075

[-- Attachment #2: Type: text/html, Size: 5902 bytes --]

 permalink raw reply	[|nested]
2016-02-07 21:33                 ` Steven Pine

  2016-02-07 22:25                     ` Steven Pine
  
From: Corey Haddad @ 2016-02-07 22:04 UTC (permalink / raw)
  To: Steven Pine;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 5257 bytes --]

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 pace will be significantly faster.  The hard fork case it is:
"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 <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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 <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
>> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
>> > bitcoin-dev@lists•linuxfoundation.org> wrote:
>> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
>> wrote:
>> > > > 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
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> Steven Pine
> (510) 517-7075
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 7944 bytes --]

 permalink raw reply	[|nested]
2016-02-07 22:04                   ` Corey Haddad

  
From: Steven Pine @ 2016-02-07 22:25 UTC (permalink / raw)
  To: Corey Haddad;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 6702 bytes --]

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.



On Sun, Feb 7, 2016 at 5:04 PM, Corey Haddad <corey3@gmail•com> wrote:

> 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 pace will be significantly faster.  The hard fork case it is:
> "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 <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> 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 <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
>>> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
>>> > bitcoin-dev@lists•linuxfoundation.org> wrote:
>>> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
>>> wrote:
>>> > > > 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
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>>
>> --
>> Steven Pine
>> (510) 517-7075
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>


-- 
Steven Pine
(510) 517-7075

[-- Attachment #2: Type: text/html, Size: 10042 bytes --]

 permalink raw reply	[|nested]
2016-02-06 21:11           ` Peter Todd
  2016-02-06 21:24             ` Peter Todd

  
From: Samson Mow @ 2016-02-09  5:11 UTC (permalink / raw)
  To: Peter Todd;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 4366 bytes --]

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

> That testing is happening by the exchange, library, wallet, etc providers
> themselves. There is a list on the Classic home page:
>
> 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 <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev
> wrote:
> > On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam@cypherspace•org> wrote:
> >
> > >
> > > 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
>
> > > , 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/
>
> How do we know any of this testing is actually being performed? I don't
> currently know of any concrete testing actually done.
>
> > > 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 unaware of Not Bitcoin XT?
>
> https://bitcointalk.org/index.php?topic=1154520.0
>
> > 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.
>
> > > 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
> > 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.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> 000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 6671 bytes --]

 permalink raw reply	[|nested]
2016-02-06 15:37     ` Gavin Andresen
                         ` (4 preceding siblings ...)
  2016-02-07  5:21       ` Jannes Faber

  2016-02-09 16:54         ` Gavin Andresen
  
From: Yifu Guo @ 2016-02-09 13:59 UTC (permalink / raw)
  To: Gavin Andresen;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 9245 bytes --]

Happy Lunar New Year Everyone!

Gavin,

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


The notion of large set ( 30% to 40% ) of un-maintained full nodes are not
evident on the network. below is data based on a personal snap shot taken
around Dec, 2015. with the following assumptions.
1) nodes running non standard version strings are considered a preference
by the node operator and are not included.
2) nodes below 0.10 are counted as so called "un-maintained" even though
they also can be a choice of the node operator.

Satoshi:0.9.3, 105
Satoshi:0.8.6, 74
Satoshi:0.9.1, 49
Satoshi:0.9.2.1, 42
Satoshi:0.8.5, 39
Satoshi:0.8.1, 35
Satoshi:0.9.5, 14
Satoshi:0.8.3, 12
Satoshi:0.9.4, 10
Satoshi:0.9.99, 10
Satoshi:0.9.0, 5
Satoshi:0.9.2, 5
Satoshi:0.8.0, 4
Satoshi:0.8.99, 1
Satoshi:0.8.4, 1

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

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

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

> We could wait a year and pick up maybe 10 or 20% more.


I don't understand this statement at all, please explicate.

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

On Sat, Feb 6, 2016 at 10:37 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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
>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> > On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev
>> wrote:
>> >> Blog post on a couple of the constants chosen:
>> >>   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.
>
>
>> >
>> >> 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.
>
>
>> >
>> >> 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?
>>
>
> 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.
>
>
>
>> >
>> >> 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.
>
>
> >
>> >> 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?
>
>
>> >
>> >> 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).
>>
>
> Happy to remove.
>
>
>> > 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).
>>
>
> 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.
>
> > 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
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 14725 bytes --]

 permalink raw reply	[|nested]
2016-02-09 13:59       ` Yifu Guo

  2016-02-10  6:14           ` David Vorick
  
From: Gavin Andresen @ 2016-02-09 16:54 UTC (permalink / raw)
  To: Yifu Guo;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2949 bytes --]

On Tue, Feb 9, 2016 at 8:59 AM, Yifu Guo <yifu@coinapex•com> wrote:

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


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



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

[-- Attachment #2: Type: text/html, Size: 4899 bytes --]

 permalink raw reply	[|nested]
2016-02-09 16:54         ` Gavin Andresen

  2016-02-10  6:36             ` Patrick Shirkey
  2016-02-10 12:58             ` Tier Nolan
  
From: David Vorick @ 2016-02-10  6:14 UTC (permalink / raw)
  To: Gavin Andresen;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]

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

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

[-- Attachment #2: Type: text/html, Size: 2355 bytes --]

 permalink raw reply	[|nested]
2016-02-10  6:14           ` David Vorick

  2016-02-10 12:58             ` Tier Nolan
  
From: Patrick Shirkey @ 2016-02-10  6:36 UTC (permalink / raw)
  To: Bitcoin Dev


On Wed, February 10, 2016 5:14 pm, David Vorick via bitcoin-dev wrote:
>>  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.
>
>> 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


 permalink raw reply	[|nested]
2016-02-10  6:14           ` David Vorick
  2016-02-10  6:36             ` Patrick Shirkey

  
From: Tier Nolan @ 2016-02-10 12:58 UTC (permalink / raw)
  Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

On Wed, Feb 10, 2016 at 6:14 AM, David Vorick via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

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

[-- Attachment #2: Type: text/html, Size: 998 bytes --]

 permalink raw reply	[|nested]