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

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

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

[Tier Nolan via bitcoin-dev]

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

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

[Yifu Guo via bitcoin-dev]

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 100 to 200)?
>
> 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
>>  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 

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

[Gavin Andresen via bitcoin-dev]

On Tue, Feb 9, 2016 at 8:59 AM, Yifu Guo  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).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

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

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

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

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

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

[Gavin Andresen via bitcoin-dev]

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

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

[Tier Nolan via bitcoin-dev]

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.
 This email has been sent from a
virus-free computer protected by Avast.
www.avast.com 
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jonathan Toomim via bitcoin-dev]

On Feb 7, 2016, at 9:24 AM, jl2...@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).




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

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

[Trevin Hofmann via bitcoin-dev]

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

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

[Steven Pine via bitcoin-dev]

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

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

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

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

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 100 to 200)?"

~~

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

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

[Luke Dashjr via 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 1 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

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

[jl2012--- via bitcoin-dev]

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-boun...@lists.linuxfoundation.org
[mailto:bitcoin-dev-boun...@lists.linuxfoundation.org] On Behalf Of Jonathan
Toomim via bitcoin-dev
Sent: Monday, 8 February, 2016 01:11
To: Anthony Towns <a...@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.

 

 

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

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

[Jonathan Toomim via bitcoin-dev]

On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev 
 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.


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

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

[Peter Todd via bitcoin-dev]

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
0711a9829e87ba8ea548f1793950893043a5dc56893dc1dc


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

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

[Jonathan Toomim via bitcoin-dev]

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


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

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

[Patrick Strateman via bitcoin-dev]

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

Especially if the price moves against either fork.

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

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

[Chris Priest via 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
 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
>  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 100 to 200)?
>>
>> 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
>>>  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 

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

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

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

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

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

[Peter Todd via bitcoin-dev]

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  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
08320874843f282f554aa2436290642fcfa81e5a01d78698


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

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

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

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

[Gavin Andresen via bitcoin-dev]

On Sat, Feb 6, 2016 at 12:01 PM, Adam Back  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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jorge Timón via bitcoin-dev]

On Feb 6, 2016 16:37, "Gavin Andresen"  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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Adam Back via bitcoin-dev]

Hi Gavin

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

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

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

Adam

On 6 February 2016 at 16:37, Gavin Andresen via bitcoin-dev
 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 100 to 200)?
>
> 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
>>  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) 

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

[Luke Dashjr via bitcoin-dev]

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