* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 15:37 ` Gavin Andresen
@ 2016-02-06 17:01 ` Adam Back
2016-02-06 17:45 ` Gavin Andresen
2016-02-07 18:49 ` Chris Priest
2016-02-06 17:09 ` Jorge Timón
` (4 subsequent siblings)
5 siblings, 2 replies; 42+ messages in thread
From: Adam Back @ 2016-02-06 17:01 UTC (permalink / raw)
To: Gavin Andresen; +Cc: 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 [flat|nested] 42+ messages in thread* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 17:01 ` Adam Back
@ 2016-02-06 17:45 ` Gavin Andresen
2016-02-06 21:11 ` Peter Todd
2016-02-06 21:28 ` David Thomson
2016-02-07 18:49 ` Chris Priest
1 sibling, 2 replies; 42+ messages in thread
From: Gavin Andresen @ 2016-02-06 17:45 UTC (permalink / raw)
To: Adam Back; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 17:45 ` Gavin Andresen
@ 2016-02-06 21:11 ` Peter Todd
2016-02-06 21:24 ` Peter Todd
2016-02-09 5:11 ` Samson Mow
2016-02-06 21:28 ` David Thomson
1 sibling, 2 replies; 42+ messages in thread
From: Peter Todd @ 2016-02-06 21:11 UTC (permalink / raw)
To: Gavin Andresen; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 21:11 ` Peter Todd
@ 2016-02-06 21:24 ` Peter Todd
2016-02-09 5:11 ` Samson Mow
1 sibling, 0 replies; 42+ messages in thread
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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 21:11 ` Peter Todd
2016-02-06 21:24 ` Peter Todd
@ 2016-02-09 5:11 ` Samson Mow
1 sibling, 0 replies; 42+ messages in thread
From: Samson Mow @ 2016-02-09 5:11 UTC (permalink / raw)
To: Peter Todd; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 17:45 ` Gavin Andresen
2016-02-06 21:11 ` Peter Todd
@ 2016-02-06 21:28 ` David Thomson
1 sibling, 0 replies; 42+ messages in thread
From: David Thomson @ 2016-02-06 21:28 UTC (permalink / raw)
To: Gavin Andresen; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 17:01 ` Adam Back
2016-02-06 17:45 ` Gavin Andresen
@ 2016-02-07 18:49 ` Chris Priest
1 sibling, 0 replies; 42+ messages in thread
From: Chris Priest @ 2016-02-07 18:49 UTC (permalink / raw)
To: Adam Back; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
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 17:25 ` Tom Zander
2016-02-06 20:36 ` Luke Dashjr
` (3 subsequent siblings)
5 siblings, 1 reply; 42+ messages in thread
From: Jorge Timón @ 2016-02-06 17:09 UTC (permalink / raw)
To: Gavin Andresen; +Cc: 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 [flat|nested] 42+ messages in thread* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 17:09 ` Jorge Timón
@ 2016-02-06 17:25 ` Tom Zander
2016-02-06 20:22 ` Chris Priest
2016-02-06 20:46 ` Luke Dashjr
0 siblings, 2 replies; 42+ messages in thread
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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 17:25 ` Tom Zander
@ 2016-02-06 20:22 ` Chris Priest
2016-02-06 20:46 ` Luke Dashjr
1 sibling, 0 replies; 42+ messages in thread
From: Chris Priest @ 2016-02-06 20:22 UTC (permalink / raw)
To: Tom Zander; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 17:25 ` Tom Zander
2016-02-06 20:22 ` Chris Priest
@ 2016-02-06 20:46 ` Luke Dashjr
2016-02-07 14:16 ` Gavin Andresen
1 sibling, 1 reply; 42+ messages in thread
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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 20:46 ` Luke Dashjr
@ 2016-02-07 14:16 ` Gavin Andresen
2016-02-07 15:06 ` Alex Morcos
` (2 more replies)
0 siblings, 3 replies; 42+ messages in thread
From: Gavin Andresen @ 2016-02-07 14:16 UTC (permalink / raw)
To: Luke Dashjr; +Cc: 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 [flat|nested] 42+ messages in thread* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-07 14:16 ` Gavin Andresen
@ 2016-02-07 15:06 ` Alex Morcos
2016-02-07 16:54 ` Peter Todd
2016-02-07 15:19 ` Anthony Towns
2016-02-07 21:01 ` Luke Dashjr
2 siblings, 1 reply; 42+ messages in thread
From: Alex Morcos @ 2016-02-07 15:06 UTC (permalink / raw)
To: Gavin Andresen, bitcoin-discuss; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4873 bytes --]
I apologize if this discussion should be moved to -discuss, I'll let the
moderators decide, I've copied both.
And Gavin, I apologize for picking on you here, because certainly this
carelessness in how people represent "facts" applies to both sides, but
much of this discussion really infuriates me.
I believe it is completely irresponsible for you to state:
"There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners"
Sure, the rest of the technical community is capable of evaluating that for
themselves, but your statements are considered authoritative by much larger
audience. In truth, no one has any idea what would happen if the proposed
Classic hard fork activated with 75% right now. There is some chance you
are right, but there is a very legitimate possibility that a concerted
effort would arise to maintain a minority fork or perhaps if miners don't
see nearly a complete switch over, many of them might themselves reverse
the fork if they think it would be easier to achieve consensus that way.
We as a community have never been in such a situation before and it
behooves us to speak honestly and directly about the uncertainty of the
situation.
And the back and forth discussion over your BIP has been in large part a
charade. People asking why you aren't picking 95% know very well why you
aren't, but lets have an honest discussion of what the risks and in your
mind potential benefits of 75% are. Important debate about parameters of
your BIP get lost because we're sniping at each other about known
disagreements. For instance, I strongly believe 28 days is far too short.
I think its extremely unlikely that those who are opposed to a contentious
hard fork will do the development work to prepare for it as that may only
make it more likely to happen. Thus if you did achieve activation with
75%, its almost impossible to imagine that if Bitcoin Core decided to come
along (as opposed to pursuing a minority fork) that they'd have the time to
develop and test the patch and roll it out to wide adoption. If the goal
of your attempt is that any minority that disagreed will "choose" to follow
the majority branch, then you'd be much more likely to achieve that by
giving them time to decide that's what they wanted and roll out the
software to do so.
On Sun, Feb 7, 2016 at 9:16 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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:
>> > 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 6433 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-07 15:06 ` Alex Morcos
@ 2016-02-07 16:54 ` Peter Todd
0 siblings, 0 replies; 42+ messages in thread
From: Peter Todd @ 2016-02-07 16:54 UTC (permalink / raw)
To: Alex Morcos; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-07 14:16 ` Gavin Andresen
2016-02-07 15:06 ` Alex Morcos
@ 2016-02-07 15:19 ` Anthony Towns
2016-02-07 17:10 ` Jonathan Toomim
2016-02-07 21:01 ` Luke Dashjr
2 siblings, 1 reply; 42+ messages in thread
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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-07 15:19 ` Anthony Towns
@ 2016-02-07 17:10 ` Jonathan Toomim
2016-02-07 17:24 ` jl2012
0 siblings, 1 reply; 42+ messages in thread
From: Jonathan Toomim @ 2016-02-07 17:10 UTC (permalink / raw)
To: Anthony Towns; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-07 17:10 ` Jonathan Toomim
@ 2016-02-07 17:24 ` jl2012
2016-02-07 17:56 ` Jonathan Toomim
0 siblings, 1 reply; 42+ messages in thread
From: jl2012 @ 2016-02-07 17:24 UTC (permalink / raw)
To: 'Jonathan Toomim', 'Anthony Towns'; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-07 17:24 ` jl2012
@ 2016-02-07 17:56 ` Jonathan Toomim
0 siblings, 0 replies; 42+ messages in thread
From: Jonathan Toomim @ 2016-02-07 17:56 UTC (permalink / raw)
To: jl2012; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
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:01 ` Luke Dashjr
2016-02-07 21:33 ` Steven Pine
2 siblings, 1 reply; 42+ messages in thread
From: Luke Dashjr @ 2016-02-07 21:01 UTC (permalink / raw)
To: Gavin Andresen; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-07 21:01 ` Luke Dashjr
@ 2016-02-07 21:33 ` Steven Pine
2016-02-07 22:04 ` Corey Haddad
0 siblings, 1 reply; 42+ messages in thread
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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-07 21:33 ` Steven Pine
@ 2016-02-07 22:04 ` Corey Haddad
2016-02-07 22:25 ` Steven Pine
0 siblings, 1 reply; 42+ messages in thread
From: Corey Haddad @ 2016-02-07 22:04 UTC (permalink / raw)
To: Steven Pine; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-07 22:04 ` Corey Haddad
@ 2016-02-07 22:25 ` Steven Pine
0 siblings, 0 replies; 42+ messages in thread
From: Steven Pine @ 2016-02-07 22:25 UTC (permalink / raw)
To: Corey Haddad; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
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 20:36 ` Luke Dashjr
2016-02-06 22:22 ` Peter Todd
` (2 subsequent siblings)
5 siblings, 0 replies; 42+ messages in thread
From: Luke Dashjr @ 2016-02-06 20:36 UTC (permalink / raw)
To: Gavin Andresen; +Cc: 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 [flat|nested] 42+ messages in thread* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 15:37 ` Gavin Andresen
` (2 preceding siblings ...)
2016-02-06 20:36 ` Luke Dashjr
@ 2016-02-06 22:22 ` Peter Todd
2016-02-07 5:21 ` Jannes Faber
2016-02-09 13:59 ` Yifu Guo
5 siblings, 0 replies; 42+ messages in thread
From: Peter Todd @ 2016-02-06 22:22 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]
On Sat, Feb 06, 2016 at 10:37:30AM -0500, Gavin Andresen via bitcoin-dev wrote:
> 2) People are committing to spinning up thousands of supports-2mb-nodes
> during the grace period.
Why wouldn't an attacker be able to counter-sybil-attack that effort?
Who are these people?
On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev wrote:
> Would Blockstream be willing to help out by running a dozen or two extra
> full nodes?
I'll remind everyone that Bitcoin Core does not condone participation in
network attacks to push controversial protcol changes through. I also
checked with Adam Back, who confirmed Blockstream as a company shares
those views.
For those readers unfamiliar with Sybil attacks, basically what the
above does is prevents nodes from being able to finding peers with
accurate information about what blockchains exist - the above can be
used to prevent nodes from learning about the longest chain for
instance, or the existance of substantial support for a minority chain.
This is why we've advocated giving users sufficient time to actively
opt-in to protocol changes.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 15:37 ` Gavin Andresen
` (3 preceding siblings ...)
2016-02-06 22:22 ` Peter Todd
@ 2016-02-07 5:21 ` Jannes Faber
2016-02-07 18:55 ` Jonathan Toomim
2016-02-09 13:59 ` Yifu Guo
5 siblings, 1 reply; 42+ messages in thread
From: Jannes Faber @ 2016-02-07 5:21 UTC (permalink / raw)
To: Gavin Andresen; +Cc: 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 [flat|nested] 42+ messages in thread* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-07 5:21 ` Jannes Faber
@ 2016-02-07 18:55 ` Jonathan Toomim
2016-02-07 19:03 ` Patrick Strateman
0 siblings, 1 reply; 42+ messages in thread
From: Jonathan Toomim @ 2016-02-07 18:55 UTC (permalink / raw)
To: Jannes Faber; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-07 18:55 ` Jonathan Toomim
@ 2016-02-07 19:03 ` Patrick Strateman
2016-02-07 19:19 ` Trevin Hofmann
2016-02-07 20:29 ` Tier Nolan
0 siblings, 2 replies; 42+ messages in thread
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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-07 19:03 ` Patrick Strateman
@ 2016-02-07 19:19 ` Trevin Hofmann
2016-02-07 20:29 ` Tier Nolan
1 sibling, 0 replies; 42+ messages in thread
From: Trevin Hofmann @ 2016-02-07 19:19 UTC (permalink / raw)
To: Patrick Strateman; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-07 19:03 ` Patrick Strateman
2016-02-07 19:19 ` Trevin Hofmann
@ 2016-02-07 20:29 ` Tier Nolan
1 sibling, 0 replies; 42+ messages in thread
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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-06 15:37 ` Gavin Andresen
` (4 preceding siblings ...)
2016-02-07 5:21 ` Jannes Faber
@ 2016-02-09 13:59 ` Yifu Guo
2016-02-09 16:54 ` Gavin Andresen
5 siblings, 1 reply; 42+ messages in thread
From: Yifu Guo @ 2016-02-09 13:59 UTC (permalink / raw)
To: Gavin Andresen; +Cc: 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 [flat|nested] 42+ messages in thread* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-09 13:59 ` Yifu Guo
@ 2016-02-09 16:54 ` Gavin Andresen
2016-02-10 6:14 ` David Vorick
0 siblings, 1 reply; 42+ messages in thread
From: Gavin Andresen @ 2016-02-09 16:54 UTC (permalink / raw)
To: Yifu Guo; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-09 16:54 ` Gavin Andresen
@ 2016-02-10 6:14 ` David Vorick
2016-02-10 6:36 ` Patrick Shirkey
2016-02-10 12:58 ` Tier Nolan
0 siblings, 2 replies; 42+ messages in thread
From: David Vorick @ 2016-02-10 6:14 UTC (permalink / raw)
To: Gavin Andresen; +Cc: 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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-10 6:14 ` David Vorick
@ 2016-02-10 6:36 ` Patrick Shirkey
2016-02-10 12:58 ` Tier Nolan
1 sibling, 0 replies; 42+ messages in thread
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 [flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
2016-02-10 6:14 ` David Vorick
2016-02-10 6:36 ` Patrick Shirkey
@ 2016-02-10 12:58 ` Tier Nolan
1 sibling, 0 replies; 42+ messages in thread
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 [flat|nested] 42+ messages in thread
