BIP proposal: Increase block size limit to 2 megabytes
42 messages, 5 to 10 Feb 2016. Started by Gavin Andresen.
Gavin Andresen (6), Luke Dashjr (4), Peter Todd (4), Jonathan Toomim (3), Yifu Guo (2), Jorge Timón (2), Chris Priest (2), Anthony Towns (2), +15 more
This has been reviewed by merchants, miners and exchanges for a couple of weeks, and has been implemented and tested as part of the Bitcoin Classic and Bitcoin XT implementations.
Constructive feedback welcome; argument about whether or not it is a good idea to roll out a hard fork now will be unproductive, so I vote we don't go there.
Draft BIP: https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki
Summary: Increase block size limit to 2,000,000 bytes. After 75% hashpower support then 28-day grace period. With accurate sigop counting, but existing sigop limit (20,000) And a new, high limit on signature hashing
Blog post walking through the code: http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
Blog post on a couple of the constants chosen: http://gavinandresen.ninja/seventyfive-twentyeight
"We can look at the adoption of the last major Bitcoin core release to guess how long it might take people to upgrade. 0.11.0 was released on 12 July, 2015. Twenty eight days later, about 38% of full nodes were running that release. Three months later, about 50% of the network was running that release, and six months later about 66% of the network was running some flavor of 0.11."
On what grounds do you think it is reasonable to assume that this update will roll out 6x faster than previous data suggested, as oppose to your own observation of 66% adoption in 6 month. or do you believe 38% node upgrade-coverage ( in 28 days ) on the network for a hard fork is good enough?
There are no harm in choosing a longer grace period but picking one short as 28 days you risk on alienating the nodes who do not upgrade with the aggressive upgrade timeline you proposed.
On Fri, Feb 5, 2016 at 3:51 PM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (34 lines)
> This has been reviewed by merchants, miners and exchanges for a couple of > weeks, and has been implemented and tested as part of the Bitcoin Classic > and Bitcoin XT implementations. > > Constructive feedback welcome; argument about whether or not it is a good > idea to roll out a hard fork now will be unproductive, so I vote we don't > go there. > > Draft BIP: > https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki > > Summary: > Increase block size limit to 2,000,000 bytes. > After 75% hashpower support then 28-day grace period. > With accurate sigop counting, but existing sigop limit (20,000) > And a new, high limit on signature hashing > > Blog post walking through the code: > http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork > > Blog post on a couple of the constants chosen: > http://gavinandresen.ninja/seventyfive-twentyeight > > -- > -- > Gavin Andresen > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
On Fri, Feb 5, 2016 at 8:51 PM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (23 lines)
> This has been reviewed by merchants, miners and exchanges for a couple of > weeks, and has been implemented and tested as part of the Bitcoin Classic > and Bitcoin XT implementations. > > Constructive feedback welcome; argument about whether or not it is a good > idea to roll out a hard fork now will be unproductive, so I vote we don't > go there. > > Draft BIP: > https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki > > Summary: > Increase block size limit to 2,000,000 bytes. > After 75% hashpower support then 28-day grace period. > With accurate sigop counting, but existing sigop limit (20,000) > And a new, high limit on signature hashing > > Blog post walking through the code: > http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork > > Blog post on a couple of the constants chosen: > http://gavinandresen.ninja/seventyfive-twentyeight >
It's great to finally see a BIP, although seems strange to ask for feedback after releasing binaries.
In any case, the issue isn't about "whether or not it is a good idea to roll out a hard fork", the question has always been about how to do safe hard fork deployment and what the technological requirements are for doing so. Your BIP/blogs do not actually address any of this. 75% miner signalling with a 28 day flag day thereafter gives virtually no time for the entire ecosystem to migrate and is widely considered unsafe. It's plainly obvious that an entire ecosystem of 5000 full nodes cannot be prepared in a month.
On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev wrote:
Quoted text (2 lines)
> 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)?
Quoted text (8 lines)
> 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?
Quoted text (2 lines)
> 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?
Quoted text (1 line)
> Miners express their support for this BIP by ...
But miners don't get to decide hardforks. How does the economy express their support for it? What happens if miners trigger it without consent from the economy?
If you are intent on using the version bits to trigger the hardfork, I suggest rephrasing this such that miners should only enable the bit when they have independently confirmed economic support (this means implementations need a config option that defaults to off).
Quoted text (1 line)
> 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.
Quoted text (3 lines)
> In the short term, an increase is needed to continue the current economic > policies with regards to fees and block space, matching market expectations > and preventing market disruption.
IMO this sentence is the most controversial part of your draft, and it wouldn't suffer a loss to remove it (or at least make it subjective).
I would also prefer to see any hardfork:
1. Address at least the simple tasks on the hardfork wishlist (eg, enable some disabled opcodes; fix P2SH for N-of->15 multisig; etc). 2. Be deployed as a soft-hardfork so as not to leave old nodes entirely insecure.
Luke
If it is to be uncontroversial and everybody will upgrade, there's no fear of a "veto power" and there's no good reason not to wait for 95% block version signaling for deployment coordination, ideally using bip9. But that's for chosing the exact block where to start. The grace period to give time to all users to upgrade should be before and not after miner's final confirmation: that simplifies and accelerates things. Assuming we chose a grace period that is really adequate, nearly 100% of miners will have likely upgraded long before everyone (since miners are a subset of "everyone"). If that is not the case and miners happen to be the latest to upgrade, using bip9 after the grace period (aka starting median-time/height) will make sure the hardfork doesn't get activated without 95% of the miners having upgraded.
28 days seems extremely short (specially if the grace period comes first), some people have suggested one year for simple hardforks like this one.
On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (65 lines)
> On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev wrote: >> Blog post on a couple of the constants chosen: >> http://gavinandresen.ninja/seventyfive-twentyeight > > Can you put this in the BIP's Rationale section (which appears to be mis-named > "Discussion" in the current draft)? > >> Signature operations in un-executed branches of a Script are not counted >> OP_CHECKMULTISIG evaluations are counted accurately; if the signature for a >> 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the top >> of the execution stack, it is counted as one signature operation. If it is >> satisfied by the public key nearest the bottom of the execution stack, it >> is counted as twenty signature operations. Signature operations involving >> invalidly encoded signatures or public keys are not counted towards the >> limit > > These seem like they will break static analysis entirely. That was a noted > reason for creating BIP 16 to replace BIP 12. Is it no longer a concern? Would > it make sense to require scripts to commit to the total accurate-sigop count > to fix this? > >> The amount of data hashed to compute signature hashes is limited to >> 1,300,000,000 bytes per block. > > The rationale for this wasn't in your blog post. I assume it's based on the > current theoretical max at 1 MB blocks? Even a high-end PC would probably take > 40-80 seconds just for the hashing, however - maybe a lower limit would be > best? > >> Miners express their support for this BIP by ... > > But miners don't get to decide hardforks. How does the economy express their > support for it? What happens if miners trigger it without consent from the > economy? > > If you are intent on using the version bits to trigger the hardfork, I suggest > rephrasing this such that miners should only enable the bit when they have > independently confirmed economic support (this means implementations need a > config option that defaults to off). > >> SPV (simple payment validation) wallets are compatible with this change. > > Would prefer if this is corrected to "Light clients" or something. Actual SPV > wallets do not exist at this time, and would not be compatible with a > hardfork. > >> In the short term, an increase is needed to continue the current economic >> policies with regards to fees and block space, matching market expectations >> and preventing market disruption. > > IMO this sentence is the most controversial part of your draft, and it > wouldn't suffer a loss to remove it (or at least make it subjective). > > I would also prefer to see any hardfork: > > 1. Address at least the simple tasks on the hardfork wishlist (eg, enable some > disabled opcodes; fix P2SH for N-of->15 multisig; etc). > 2. Be deployed as a soft-hardfork so as not to leave old nodes entirely > insecure. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
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
Quoted text (10 lines)
> <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.
Quoted text (22 lines)
> > > >> 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.
Quoted text (12 lines)
> > > >> 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.
Quoted text (9 lines)
> > > >> 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.
Quoted text (9 lines)
> > > > 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.
Quoted text (8 lines)
> > >> 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?
Quoted text (10 lines)
> > > >> 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.
Quoted text (6 lines)
> > 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.
Quoted text (3 lines)
> 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?
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:
Quoted text (210 lines)
> 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 >
On Feb 6, 2016 16:37, "Gavin Andresen" <gavinandresen@gmail•com> wrote:
Quoted text (2 lines)
> > 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 ?
Quoted text (1 line)
> 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.
Quoted text (1 line)
> I strongly disagree with the statement that there is no cost to a longer
grace period.
I didn't say that.
Quoted text (1 line)
> 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.
On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev wrote:
Quoted text (2 lines)
> 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.
On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam@cypherspace•org> wrote:
Quoted text (3 lines)
> > 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).
Quoted text (3 lines)
> , 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:
Quoted text (5 lines)
> > 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?
Quoted text (2 lines)
> 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.
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:
Quoted text (24 lines)
> 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 >
On Saturday, February 06, 2016 3:37:30 PM Gavin Andresen wrote:
Quoted text (1 line)
> 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?
Quoted text (1 line)
> 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).
Quoted text (8 lines)
> 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?
Quoted text (12 lines)
> > 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.
Quoted text (9 lines)
> > > 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.
Quoted text (7 lines)
> > 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
On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev wrote:
Quoted text (1 line)
> On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev
wrote:
Quoted text (8 lines)
> > 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
On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev wrote:
Quoted text (9 lines)
> 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
Quoted text (8 lines)
> > , 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.
Quoted text (6 lines)
> > 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
Quoted text (3 lines)
> 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.
Quoted text (7 lines)
> > 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.
On Sat, Feb 06, 2016 at 04:11:58PM -0500, Peter Todd via bitcoin-dev wrote:
Quoted text (14 lines)
> 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.
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:
Quoted text (6 lines)
>> 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.
Quoted text (2 lines)
> > (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?
Quoted text (8 lines)
> > >> , 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?
Quoted text (15 lines)
> >> >> 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
Quoted text (13 lines)
> >> 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
On Sat, Feb 06, 2016 at 10:37:30AM -0500, Gavin Andresen via bitcoin-dev wrote:
Quoted text (2 lines)
> 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:
Quoted text (2 lines)
> 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.
On 6 Feb 2016 4:41 p.m., "Gavin Andresen via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (4 lines)
> > 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?
On Fri, Feb 05, 2016 at 03:51:08PM -0500, Gavin Andresen via bitcoin-dev wrote:
Quoted text (5 lines)
> Constructive feedback welcome; [...] > Summary: > Increase block size limit to 2,000,000 bytes. > With accurate sigop counting, but existing sigop limit (20,000) > And a new, high limit on signature hashing
To me, it seems absurd to have a hardfork but not take the opportunity to combine these limits into a single weighted sum.
I'd suggest:
0.5*blocksize + 50*accurate_sigops + 0.001*sighash < 2,000,000
That provides worst case blocksize of 4MB, worst case sigops of 40,000 and worst case sighash bytes of 2GB. Given the separate limit on sighash bytes and the improvements from libsecp256k1 I think 40k sigops should be fine, but I'm happy to be corrected.
For a regular transaction, of say 380 bytes with 2 sigops and hashing about 800 bytes, that uses up about 291 units of the limit, meaning that if a block was full of transactions of that form, the limit would be 6872 tx or 2.6MB per block (along with 13.7k sigops and ~5.5MB hashed for signatures). Those weightings could probably be improved by doing some detailed analysis and measurements, but I think they're pretty reasonable for round figures.
The main advantage is that it would prevent blocks being cheaply filled up due to hitting one of the secondary limits but only paying for the contribution to the primary limit (presumably block size), which avoids denial of service spam attacks.
I think having the limit take UTXO increase (or decrease) into effect would be helpful too; but I don't have a specific suggestion. If it's just a matter of making the limit stronger (eg adding "0.25*max(0,change in UTXO bytes)" to the formula on the left, but not changing the limit on the right), that would be a soft-forking change that could be introduced later, and maybe that's fine.
If there was time to actually iterate on this proposal, rather than an apparent aim to get it out the door in the next month or two, I think it would be good to also design it so that the parameters of the weighted sum could be adjusted by a soft-fork in future rather than requiring a hard fork every time a limit's reached, or a weighting can be relaxed. But I don't think that's feasible to design within a few weeks, so I think it's off the table given the activation goal.
Cheers, aj
On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (19 lines)
> 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.
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:
Quoted text (57 lines)
> 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 > >
On Sun, Feb 07, 2016 at 09:16:02AM -0500, Gavin Andresen via bitcoin-dev wrote:
Quoted text (3 lines)
> 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
On Sun, Feb 07, 2016 at 10:06:06AM -0500, Alex Morcos via bitcoin-dev wrote:
Quoted text (3 lines)
> 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.
Quoted text (3 lines)
> 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.
As I feared, request on feedback for this specific BIP has devolved into a general debate about the merits of soft-forks versus hard-forks (versus semi-hard Kosher Free Range forks...).
I've replied to several people privately off-list to not waste people's time rehashing arguments that have been argued to death in the past.
I do want to briefly address all of the concerns that stem from "what if a significant fraction of hashpower (e.g. 25%) stick with the 1mb branch of the chain."
Proof of work cannot be spoofed. If there is very little (a few percent) of hashpower mining a minority chain, confirmations on that chain take orders of magnitude longer. I wrote about why the incentives are extremely strong for only the stronger branch to survive here: http://gavinandresen.ninja/minority-branches
... the debate about whether or not that is correct doesn't belong here in bitcoin-dev, in my humble opinion.
All of the security concerns I have seen flow from an assumption that significant hashpower continues on the weaker branch. The BIP that is under discussion assumes that analysis is correct. I have not seen any evidence that it is not correct; all experience with previous forks (of both Bitcoin and altcoins) is that the stronger branch survives and the weaker branch very quickly dies.
As for the argument that creating and testing a patch for Core would take longer than 28 days:
The glib answer is "people should just run Classic, then."
A less glib answer is it would be trivial to create a patch for Core that accepted a more proof-of-work chain with larger blocks, but refused to mine larger blocks.
That would be a trivial patch that would require very little testing (extensive testing of 8 and 20mb blocks has already been done), and perhaps would be the best compromise until we can agree on a permanent solution that eliminates the arbitrary, contentious limits.
On Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (10 lines)
> 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.
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.
On Feb 7, 2016, at 9:24 AM, jl2012@xbt•hk wrote:
Quoted text (2 lines)
> 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).
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:
Quoted text (256 lines)
> 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 >
On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (2 lines)
> 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.
Quoted text (2 lines)
> 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.
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:
Quoted text (22 lines)
> > 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
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:
Quoted text (35 lines)
> 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 >
On Sun, Feb 7, 2016 at 7:03 PM, Patrick Strateman via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (4 lines)
> 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>
On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
Quoted text (3 lines)
> 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:
Quoted text (12 lines)
> > > 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
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:
Quoted text (39 lines)
> 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 >
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:
Quoted text (99 lines)
> 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 > >
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:
Quoted text (126 lines)
> 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 >> >> >
Gavin, please don't quote that list on the Classic website. It's horribly inaccurate and misleading to the general public.
Quoted text (4 lines)
> 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:
Quoted text (96 lines)
> 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 > >
Happy Lunar New Year Everyone!
Gavin,
Quoted text (3 lines)
> 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
Quoted text (2 lines)
> 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.
Quoted text (3 lines)
> > > 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.
Quoted text (1 line)
> We could wait a year and pick up maybe 10 or 20% more.
I don't understand this statement at all, please explicate.
On Tue, Feb 9, 2016 at 8:59 AM, Yifu Guo <yifu@coinapex•com> wrote:
Quoted text (6 lines)
> > 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.
Quoted text (9 lines)
> > > 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).
Quoted text (8 lines)
> >> > 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.
Quoted text (5 lines)
> 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).
Quoted text (1 line)
> 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.
Quoted text (1 line)
> 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.
On Wed, February 10, 2016 5:14 pm, David Vorick via bitcoin-dev wrote:
Quoted text (43 lines)
>> 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)
On Wed, Feb 10, 2016 at 6:14 AM, David Vorick via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (4 lines)
> 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.