Re: [bitcoin-dev] Barry Silbert segwit agreement
While I'm not 100% convinced there are strict technical reasons for needing to wait till after segwit is active before a hard fork can be started (you can, after all, activate segwit as a part of the HF), there are useful design and conservatism reasons (not causing massive discontinuity in fee market, handling major system changes one at a time, etc). Still, totally agree that attempting to design, code, and test a new hard fork in six months, let alone deploy it, let alone simultaneously with segwit, is a joke and fails to take seriously the investment many have made in the bitcoin system. Previous, rather simple, soft forks required similar if not more development time, not counting deployment and activation time. If the community is unable to form consensus around segwit alone for political reasons, further research into hard fork design may help, but even forks tied together would nearly certainly need to activate months apart. On May 26, 2017 5:30:37 PM EDT, James Hilliard wrote: >Mandatory signalling is the only way to lock in segwit with less than >95% hashpower without a full redeployment(which for a number of >technical reasons isn't feasible until after the existing segwit >deployment expires). There's no reason not to signal BIP141 bit 1 >while also signalling bit 4, but you would want to use bit 4 to >coordinate bit 1 mandatory signalling. > >It would not be feasible to schedule any HF until one can be >completely sure BIP141 is active(at least not without waiting for the >timeout and doing a redeployment) due to activation/p2p codepath >complexity. This is why the mandatory signalling period is needed. > >Since it is likely a HF will take months of development and testing I >see this or something similar as the fastest safe path forward: >1. Use BIP91 or similar to activate BIP141 via mandatory signalling >ASAP(likely using bit 4) >2. Develop HF code based on assumption that BIP141 is active so that >you only have to test the BIP141->HF upgrade/activation codepath. >3. Deploy HF after BIP141 lock in(bit 4 can be reused again here since >this will be after BIP91 expiration) > >When rolling out some features it often makes sense to combine them >into a single fork for example BIP's 68, 112, 113 were rolled out at >the same time as are BIP's 141, 143, 144, 145 for segwit, however a HF >has required features that would conflict with with features in the >segwit rollout which is why attempting to simultaneously deploy them >would cause major complexity/testing issues(you would have to deal >with feature conflict resolution for multiple potential activation >scenarios). By doing a staged rollout of segwit and then a HF you get >a single testable upgrade path. > >Based on past development experiences I wouldn't expect a 6 month >timeline to be realistic for a properly tested HF, but this proposed >upgrade path should be the fastest available for both SegWit and a HF >regardless. > >On Fri, May 26, 2017 at 4:10 PM, Jacob Eliosoff via bitcoin-dev > wrote: >> Just to clarify one thing, what I described differs from BIP91 in >that >> there's no orphaning. Just when Segwit2MB support reaches 80%, those >80% >> join everyone else in signaling for BIP141. BIP91 orphaning is an >optional >> addition but my guess is it wouldn't be needed. >> >> >> On May 26, 2017 4:02 PM, "Matt Corallo" >wrote: >>> >>> Your proposal seems to be simply BIP 91 tied to the >>> as-yet-entirely-undefined hard fork Barry et al proposed. >>> >>> Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, >as >>> you propose, would make the deployment on the incredibly short >timeline >>> Barry et al proposed slightly more realistic, though I would expect >to >>> see hard fork code readily available and well-tested at this point >in >>> order to meet that timeline. >>> >>> Ultimately, due to their aggressive timeline, the Barry et al >proposal >>> is incredibly unlikely to meet the requirements of a >>> multi-billion-dollar system, and continued research into meeting the >>> spirit, not the text, of their agreement seems warranted. >>> >>> Matt >>> >>> On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote: >>> > Forgive me if this is a dumb question. Suppose that rather than >>> > directly activating segwit, the Silbert/NYC Segwit2MB proposal's >lock-in >>> > just triggered BIP141 signaling (plus later HF). Would that avoid >>> > incompatibility with existing BIP141 nodes, and get segwit >activated >>> > sooner? Eg: >>> > >>> > - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals >support >>> > for "segwit now, HF (TBD) at scheduled date (Nov 23?)" >>> > - If bit 4 support reaches 80%, it locks in two things: the >scheduled HF >>> > (conditional on segwit), and *immediately* turning on bit 1 >(BIP141 >>> > support) >>> > >>> > I realize this would still leave problems like the aggressive HF >>> > schedule, possible chain split at the HF date between Segwit2MB >nodes >>> > and any remaining BIP
Re: [bitcoin-dev] Barry Silbert segwit agreement
On Friday, 26 May 2017 23:30:37 CEST James Hilliard via bitcoin-dev wrote: > It would not be feasible to schedule any HF until one can be > completely sure BIP141 is active why? > Since it is likely a HF will take months of development and testing I > see this or something similar as the fastest safe path forward This should not be an issue, it started 2 years ago. Its tested. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Barry Silbert segwit agreement
Mandatory signalling is the only way to lock in segwit with less than 95% hashpower without a full redeployment(which for a number of technical reasons isn't feasible until after the existing segwit deployment expires). There's no reason not to signal BIP141 bit 1 while also signalling bit 4, but you would want to use bit 4 to coordinate bit 1 mandatory signalling. It would not be feasible to schedule any HF until one can be completely sure BIP141 is active(at least not without waiting for the timeout and doing a redeployment) due to activation/p2p codepath complexity. This is why the mandatory signalling period is needed. Since it is likely a HF will take months of development and testing I see this or something similar as the fastest safe path forward: 1. Use BIP91 or similar to activate BIP141 via mandatory signalling ASAP(likely using bit 4) 2. Develop HF code based on assumption that BIP141 is active so that you only have to test the BIP141->HF upgrade/activation codepath. 3. Deploy HF after BIP141 lock in(bit 4 can be reused again here since this will be after BIP91 expiration) When rolling out some features it often makes sense to combine them into a single fork for example BIP's 68, 112, 113 were rolled out at the same time as are BIP's 141, 143, 144, 145 for segwit, however a HF has required features that would conflict with with features in the segwit rollout which is why attempting to simultaneously deploy them would cause major complexity/testing issues(you would have to deal with feature conflict resolution for multiple potential activation scenarios). By doing a staged rollout of segwit and then a HF you get a single testable upgrade path. Based on past development experiences I wouldn't expect a 6 month timeline to be realistic for a properly tested HF, but this proposed upgrade path should be the fastest available for both SegWit and a HF regardless. On Fri, May 26, 2017 at 4:10 PM, Jacob Eliosoff via bitcoin-dev wrote: > Just to clarify one thing, what I described differs from BIP91 in that > there's no orphaning. Just when Segwit2MB support reaches 80%, those 80% > join everyone else in signaling for BIP141. BIP91 orphaning is an optional > addition but my guess is it wouldn't be needed. > > > On May 26, 2017 4:02 PM, "Matt Corallo" wrote: >> >> Your proposal seems to be simply BIP 91 tied to the >> as-yet-entirely-undefined hard fork Barry et al proposed. >> >> Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, as >> you propose, would make the deployment on the incredibly short timeline >> Barry et al proposed slightly more realistic, though I would expect to >> see hard fork code readily available and well-tested at this point in >> order to meet that timeline. >> >> Ultimately, due to their aggressive timeline, the Barry et al proposal >> is incredibly unlikely to meet the requirements of a >> multi-billion-dollar system, and continued research into meeting the >> spirit, not the text, of their agreement seems warranted. >> >> Matt >> >> On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote: >> > Forgive me if this is a dumb question. Suppose that rather than >> > directly activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in >> > just triggered BIP141 signaling (plus later HF). Would that avoid >> > incompatibility with existing BIP141 nodes, and get segwit activated >> > sooner? Eg: >> > >> > - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support >> > for "segwit now, HF (TBD) at scheduled date (Nov 23?)" >> > - If bit 4 support reaches 80%, it locks in two things: the scheduled HF >> > (conditional on segwit), and *immediately* turning on bit 1 (BIP141 >> > support) >> > >> > I realize this would still leave problems like the aggressive HF >> > schedule, possible chain split at the HF date between Segwit2MB nodes >> > and any remaining BIP141 nodes, etc. My focus here is how >> > incompatibility with existing nodes could be minimized. >> > >> > (BIP91 could also be used if BIP141 support still fell short of 95%. >> > But if Segwit2MB support reaches 80%, it seems likely that an additional >> > 15% will support BIP141-without-HF.) >> > >> > >> > ___ >> > bitcoin-dev mailing list >> > bitcoin-dev@lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Barry Silbert segwit agreement
Just to clarify one thing, what I described differs from BIP91 in that there's no orphaning. Just when Segwit2MB support reaches 80%, those 80% join everyone else in signaling for BIP141. BIP91 orphaning is an optional addition but my guess is it wouldn't be needed. On May 26, 2017 4:02 PM, "Matt Corallo" wrote: > Your proposal seems to be simply BIP 91 tied to the > as-yet-entirely-undefined hard fork Barry et al proposed. > > Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, as > you propose, would make the deployment on the incredibly short timeline > Barry et al proposed slightly more realistic, though I would expect to > see hard fork code readily available and well-tested at this point in > order to meet that timeline. > > Ultimately, due to their aggressive timeline, the Barry et al proposal > is incredibly unlikely to meet the requirements of a > multi-billion-dollar system, and continued research into meeting the > spirit, not the text, of their agreement seems warranted. > > Matt > > On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote: > > Forgive me if this is a dumb question. Suppose that rather than > > directly activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in > > just triggered BIP141 signaling (plus later HF). Would that avoid > > incompatibility with existing BIP141 nodes, and get segwit activated > > sooner? Eg: > > > > - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support > > for "segwit now, HF (TBD) at scheduled date (Nov 23?)" > > - If bit 4 support reaches 80%, it locks in two things: the scheduled HF > > (conditional on segwit), and *immediately* turning on bit 1 (BIP141 > support) > > > > I realize this would still leave problems like the aggressive HF > > schedule, possible chain split at the HF date between Segwit2MB nodes > > and any remaining BIP141 nodes, etc. My focus here is how > > incompatibility with existing nodes could be minimized. > > > > (BIP91 could also be used if BIP141 support still fell short of 95%. > > But if Segwit2MB support reaches 80%, it seems likely that an additional > > 15% will support BIP141-without-HF.) > > > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP149 timeout-- why so far in the future?
A more important consideration than segwit's timeout is when code can be released, which will no doubt be several months after SegWit's current timeout. Greg's proposed 6 months seems much more reasonable to me, assuming its still many months after the formal release of code implementing it. Matt On 05/24/17 04:26, Rusty Russell via bitcoin-dev wrote: > Gregory Maxwell via bitcoin-dev > writes: >> Based on how fast we saw segwit adoption, why is the BIP149 timeout so >> far in the future? >> >> It seems to me that it could be six months after release and hit the >> kind of density required to make a stable transition. > > Agreed, I would suggest 16th December, 2017 (otherwise, it should be > 16th January 2018; during EOY holidays seems a bad idea). > > This means this whole debacle has delayed segwit exactly 1 (2) month(s) > beyond what we'd have if it used BIP8 in the first place. > > Cheers, > Rusty. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Barry Silbert segwit agreement
Your proposal seems to be simply BIP 91 tied to the as-yet-entirely-undefined hard fork Barry et al proposed. Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, as you propose, would make the deployment on the incredibly short timeline Barry et al proposed slightly more realistic, though I would expect to see hard fork code readily available and well-tested at this point in order to meet that timeline. Ultimately, due to their aggressive timeline, the Barry et al proposal is incredibly unlikely to meet the requirements of a multi-billion-dollar system, and continued research into meeting the spirit, not the text, of their agreement seems warranted. Matt On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote: > Forgive me if this is a dumb question. Suppose that rather than > directly activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in > just triggered BIP141 signaling (plus later HF). Would that avoid > incompatibility with existing BIP141 nodes, and get segwit activated > sooner? Eg: > > - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support > for "segwit now, HF (TBD) at scheduled date (Nov 23?)" > - If bit 4 support reaches 80%, it locks in two things: the scheduled HF > (conditional on segwit), and *immediately* turning on bit 1 (BIP141 support) > > I realize this would still leave problems like the aggressive HF > schedule, possible chain split at the HF date between Segwit2MB nodes > and any remaining BIP141 nodes, etc. My focus here is how > incompatibility with existing nodes could be minimized. > > (BIP91 could also be used if BIP141 support still fell short of 95%. > But if Segwit2MB support reaches 80%, it seems likely that an additional > 15% will support BIP141-without-HF.) > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
Hello Eric, Thank you for your question and your time off-list clarifying your position. I’m posting to the list so that a wider audience may benefit. Original Question: ‘Presumably the "very serious security vulnerability" posed is one of increased centralization of hash power. Would this danger exist without the patent risk?’ I would postulate that if ASICBOOST was originally released without the patent risk, then much of the risk would have been avoided; all of the mining manufactures would have implemented ASICBOOST and had a similar advantage. However, now time has passed and the damage of the patent monopoly exploiting CVE-2017-9230 has been already done. If the ASICBOOST patent was released to the public for free today, while a good thing, it wouldn’t soften the severity of the vulnerability we face today. The ASICBOOST PATENT provides a miner with a constant-factor advantage. This is a huge problem with zero-sum games, such as mining. In game-theory, a constant factor advantage gives an exponential advantage over the time period maintained. This explains why the Bitcoin Community initially took very little notice to ASICBOOST: The effects of ASICBOOST stated at virtually nothing, and it took a while for the advantage to been seen over the normal variance of mining. However, it’s influence has been exponentially growing since then: creating an emergency problem that we now face. The result of ASICBOOST going unchecked is that very quickly from now, surprisingly quickly, the only profitable miners will be the miners who make use of ASICBOOST. This is a grave concern. I will again reiterate that the virtue-signalling over perceived political motivations is ridiculous in the light what I consider a looming catastrophe, we should be judging by what is real not just perceived. The catastrophe that I fear is one company (or a single politically connected group) gaining a virtual complete monopoly of Bitcoin Mining. This is more important to me than avoiding chain-splits. Without a well-distributed set of miners Bitcoin isn’t Bitcoin. Cameron. PS. This attack is part of a larger set of licensing attacks, where patens are just one form of licensing attack. These attacks are particularly damaging in competitive markets such as mining. We should be vigilant for other attempts to create state-enforced licensing around mathematical algorithms. ASICBOOST is an illustrative example of what the Bitcoin Community needs to defend against. > On 26 May 2017, at 11:15 , Eric Voskuil wrote: > > Signed PGP part > Hi Cameron, > > Presumably the "very serious security vulnerability" posed is one of > increased centralization of hash power. Would this danger exist > without the patent risk? > > e > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Barry Silbert segwit agreement
On Friday, 26 May 2017 19:47:11 CEST Jacob Eliosoff via bitcoin-dev wrote: > Forgive me if this is a dumb question. Sorry for picking your email. I understand people want something different for the agreement, I know I do too. We have a specific agreement on the table, signed by a huge subsection of the industry. Maybe the time for changing things is not to be *after* the signatures are set. I know I’d change some detials. But do we really want to go through another conference where all the important people are present to agree on a compromise? Or can we use the one we have? The compromise is pretty simple; https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77 * Activate Segregated Witness at an 80% threshold, signaling at bit 4 * Activate a 2 MB hard fork within six months -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Barry Silbert segwit agreement
Forgive me if this is a dumb question. Suppose that rather than directly activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in just triggered BIP141 signaling (plus later HF). Would that avoid incompatibility with existing BIP141 nodes, and get segwit activated sooner? Eg: - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support for "segwit now, HF (TBD) at scheduled date (Nov 23?)" - If bit 4 support reaches 80%, it locks in two things: the scheduled HF (conditional on segwit), and *immediately* turning on bit 1 (BIP141 support) I realize this would still leave problems like the aggressive HF schedule, possible chain split at the HF date between Segwit2MB nodes and any remaining BIP141 nodes, etc. My focus here is how incompatibility with existing nodes could be minimized. (BIP91 could also be used if BIP141 support still fell short of 95%. But if Segwit2MB support reaches 80%, it seems likely that an additional 15% will support BIP141-without-HF.) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
On Friday, 26 May 2017 16:39:30 CEST Erik Aronesty wrote: > Linking a bit4 MASF with a bit4 "lock in of a hard fork in 6 months" is > something that will simply never happen for basic engineering reasons. The modifications to Bitcoin Core would take at most a day to do, plus a week to test. I’m not very happy with the full compromise myself, but can we please not stomp on actual progress with nebulous problems? I mean, you want SegWit, right? > Claiming that miners support segwit is disingenuous ... considering that > if they supported it, they would be signaling for it today... instead of > distracting the community with fake proposals that have no peer-reviewed > code. The nature of a compromise like the one that happened in New York is that both parties do something they are not the most happy with in exchange for the thing they want. Miners have agreed to the SegWit part of this compromise. Calling that disingenuous is not helpful... -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
Linking a bit4 MASF with a bit4 "lock in of a hard fork in 6 months" is something that will simply never happen for basic engineering reasons. Spoonet, an oft-quoted hard fork that actually has some strong support, is a much better candidate for the code base - but not of the supposed supporters of bit4 MASF seem to be ready to roll up their sleeves and do any work at all. I mean, if they really had "millions" for development, they could just hire dome developers and built it correctly, right? But they aren't ... instead they are pumping money into "bcoin", which doesn't yet have any of the protections needed to get consensus. Maybe it will some day. Claiming that miners support segwit is disingenuous ... considering that if they supported it, they would be signaling for it today... instead of distracting the community with fake proposals that have no peer-reviewed code. On Fri, May 26, 2017 at 5:21 AM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Friday, 26 May 2017 10:02:27 CEST Cameron Garnham via bitcoin-dev wrote: > > So, I started searching for the motivations of such a large amount of the > > mining hash-rate holding a position that isn’t at-all represented in the > > wider Bitcoin Community. My study of ASICBOOST lead to a ‘bingo’ moment: > > If one assumes that the 67% of the hash rate that refuse to signal for > > SegWit are using ASICBOOST. The entire picture of this political > > stalemate became much more understandable. > > I’m uncomfortable with your “bingo” moment, and your huge assumption to get > to make it fit. > The reality is that we have seen repeatedly that the miners are stating > they > are Ok with an ASICBOOST disabling change. > The larger mining industry has just this week come to consensus about a > better way to activate SegWit! Referring to the New York consensus > meeting!! > https://medium.com/@DCGco/bitcoin-scaling-agreement-at- > consensus-2017-133521fe9a77 > > I question your conclusions of miners not supporting SegWit because of > ASICBOOST, the evidence shows this accusation to be false. > > You openly admitting here that you use ASICBOOST as a tool to push SegWit > is > further making me uncomfortable. Your intention may be pure, but the > methods > are not. > And on that I agree with Andreas, that taints this proposal. > > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
On Friday, 26 May 2017 10:02:27 CEST Cameron Garnham via bitcoin-dev wrote: > So, I started searching for the motivations of such a large amount of the > mining hash-rate holding a position that isn’t at-all represented in the > wider Bitcoin Community. My study of ASICBOOST lead to a ‘bingo’ moment: > If one assumes that the 67% of the hash rate that refuse to signal for > SegWit are using ASICBOOST. The entire picture of this political > stalemate became much more understandable. I’m uncomfortable with your “bingo” moment, and your huge assumption to get to make it fit. The reality is that we have seen repeatedly that the miners are stating they are Ok with an ASICBOOST disabling change. The larger mining industry has just this week come to consensus about a better way to activate SegWit! Referring to the New York consensus meeting!! https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77 I question your conclusions of miners not supporting SegWit because of ASICBOOST, the evidence shows this accusation to be false. You openly admitting here that you use ASICBOOST as a tool to push SegWit is further making me uncomfortable. Your intention may be pure, but the methods are not. And on that I agree with Andreas, that taints this proposal. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Cameron, Presumably the "very serious security vulnerability" posed is one of increased centralization of hash power. Would this danger exist without the patent risk? e On 05/26/2017 01:02 AM, Cameron Garnham via bitcoin-dev wrote: > Thank you for your reply Andreas, > > I can assure you that I have many motivations for activating > SegWit. > > Before studding ASICBOOST I wanted to activate SegWit as it is a wonderful upgrade for Bitcoin. It seems to me that virtually the entire Bitcoin Ecosystem agrees with me. Except for around 67% of the mining hash-rate who very conspicuously refuse to signal for it’s activation. > > So, I started searching for the motivations of such a large amount of the mining hash-rate holding a position that isn’t at-all represented in the wider Bitcoin Community. My study of ASICBOOST lead to a ‘bingo’ moment: If one assumes that the 67% of the hash rate that refuse to signal for SegWit are using ASICBOOST. The entire picture of this political stalemate became much more understandable. > > This only strengthened my resolve to activate SegWit: not only is SegWit great, it partially mitigates a very serious security vulnerability. > > This is why I call into question why you would suggest: > > “This proposal is unnecessarily conflating two contentious issues and will attract criticism of self serving motivation.” > > 1. I am not conflating the issues. I would argue that very fact that SegWit has not been activated yet is directly because of CVE-2017-9230. > 2. I have no reason to believe that SegWit is contentious, except for the attackers who it would frustrate. > 3. I have no negative responses to my endeavours to get ASICBOOST > as regarded as a legitimate security vulnerability. This would suggest that it is not contentious in the wider technical community. > > If SegWit is NOT contentious within the technical community and it is NOT contentious to regard CVE-2017-9230 as a credible security vulnerability. Then using it as partial security fix for a security vulnerability SHOULD NOT be contentious. > > If you believe that SegWit is contentious within the technical community. Or you believe CVE-2017-9230 should not be regarded as a credible security vulnerability. Then I would logically agree with you that we should separate the issues so that we may gain consensus. However, I just don’t see this as the case. > > Cameron. > > >> On 26 May 2017, at 09:52 , Andreas M. Antonopoulos wrote: >> >> I rarely post here, out of respect to the mailing list. But >> since my name was mentioned... >> >> I much prefer Gregory Maxwell's proposal to defuse covert >> ASICBOOST (only) with a segwit-like commitment to the coinbase which does not obligate miners to signal Segwit or implement Segwit, thus disarming any suspicion that the issue is being exploited only to activate Segwit. >> >> This proposal is unnecessarily conflating two contentious issues and will attract criticism of self serving motivation. >> >> Politicising CVE is damaging to the long term bitcoin >> development and to its security. Not claiming that is the intent here, but the damage is done by the mere appearance of motive. >> >> >> >> On May 26, 2017 16:30, "Cameron Garnham via bitcoin-dev" wrote: >> Hello Bitcoin-Dev, >> >> CVE-2017-9230 (1) (2), or commonly known as ‘ASICBOOST’ is a >> severe (3) (4) and actively exploited (5) security vulnerability. >> >> To learn more about this vulnerability please read Jeremy >> Rubin’s detailed report: >> http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf >> >> Andreas Antonopoulos has an excellent presentation on why >> asicboost is dangerous: >> https://www.youtube.com/watch?v=t6jJDD2Aj8k >> >> In decisions on the #bitcoin-core-dev IRC channel; It was >> proposed, without negative feedback, that SegWit be used as a partial-mitigation of CVE-2017-9230. >> >> SegWit partially mitigates asicboost with the common reasonable assumption that any block that doesn’t include a witness commit in it's coinbase transaction was mined using covert asicboost. Making the use of covert asicboost far more conspicuous. >> >> It was also proposed that this partial mitigation should be >> quickly strengthened via another soft-fork that makes the inclusion of witness commits mandatory, without negative feedback. >> >> The security trade-offs of deploying a partial-mitigation to CVE-2017-9230 quickly vs more slowly but more conservatively is under intense debate. The author of this post has a strong preference to the swiftest viable option. >> >> Cameron. >> >> >> (1) CVE Entry: >> https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230 >> >> (2) Announcement of CVE to Mailing List: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014416. html >> >> (3) Discussion of the perverse incentives created by 'ASICBOOST' >> by Ryan Grant: >> https://lists.linuxfoundation.org/pipermail/bit
Re: [bitcoin-dev] BIP149 timeout-- why so far in the future?
I agree the date can be brought forward. FWIW, I originally set the date far out enough that people wouldn't immediately fixate on the date and rather look at the meat of the proposal instead. Given that we saw around 70% of nodes upgrade to BIP141 in around 5/6 months, I dont see any reason why we cant reduce the date to being 6 months or less from Nov. Given people are starving for segwit to the point of running BIP148, there is good evidence the community will upgrade in record time to BIP149. Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. Original Message Based on how fast we saw segwit adoption, why is the BIP149 timeout so far in the future? It seems to me that it could be six months after release and hit the kind of density required to make a stable transition. (If it were a different proposal and not segwit where we already have seen what network penetration looks like-- that would be another matter.) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
I rarely post here, out of respect to the mailing list. But since my name was mentioned... I much prefer Gregory Maxwell's proposal to defuse covert ASICBOOST (only) with a segwit-like commitment to the coinbase which does not obligate miners to signal Segwit or implement Segwit, thus disarming any suspicion that the issue is being exploited only to activate Segwit. This proposal is unnecessarily conflating two contentious issues and will attract criticism of self serving motivation. Politicising CVE is damaging to the long term bitcoin development and to its security. Not claiming that is the intent here, but the damage is done by the mere appearance of motive. On May 26, 2017 16:30, "Cameron Garnham via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello Bitcoin-Dev, > > CVE-2017-9230 (1) (2), or commonly known as ‘ASICBOOST’ is a severe (3) > (4) and actively exploited (5) security vulnerability. > > To learn more about this vulnerability please read Jeremy Rubin’s detailed > report: > http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf > > Andreas Antonopoulos has an excellent presentation on why asicboost is > dangerous: > https://www.youtube.com/watch?v=t6jJDD2Aj8k > > In decisions on the #bitcoin-core-dev IRC channel; It was proposed, > without negative feedback, that SegWit be used as a partial-mitigation of > CVE-2017-9230. > > SegWit partially mitigates asicboost with the common reasonable assumption > that any block that doesn’t include a witness commit in it's coinbase > transaction was mined using covert asicboost. Making the use of covert > asicboost far more conspicuous. > > It was also proposed that this partial mitigation should be quickly > strengthened via another soft-fork that makes the inclusion of witness > commits mandatory, without negative feedback. > > The security trade-offs of deploying a partial-mitigation to CVE-2017-9230 > quickly vs more slowly but more conservatively is under intense debate. > The author of this post has a strong preference to the swiftest viable > option. > > Cameron. > > > (1) CVE Entry: > https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230 > > (2) Announcement of CVE to Mailing List: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ > 2017-May/014416.html > > (3) Discussion of the perverse incentives created by 'ASICBOOST' by Ryan > Grant: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ > 2017-May/014352.html > > (4) Discussion of ASICBOOST's non-independent PoW calculation by Tier > Nolan: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ > 2017-May/014351.html > > (5) Evidence of Active Exploit by Gregory Maxwell: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ > 2017-April/013996.html > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
Thank you for your reply Andreas, I can assure you that I have many motivations for activating SegWit. Before studding ASICBOOST I wanted to activate SegWit as it is a wonderful upgrade for Bitcoin. It seems to me that virtually the entire Bitcoin Ecosystem agrees with me. Except for around 67% of the mining hash-rate who very conspicuously refuse to signal for it’s activation. So, I started searching for the motivations of such a large amount of the mining hash-rate holding a position that isn’t at-all represented in the wider Bitcoin Community. My study of ASICBOOST lead to a ‘bingo’ moment: If one assumes that the 67% of the hash rate that refuse to signal for SegWit are using ASICBOOST. The entire picture of this political stalemate became much more understandable. This only strengthened my resolve to activate SegWit: not only is SegWit great, it partially mitigates a very serious security vulnerability. This is why I call into question why you would suggest: “This proposal is unnecessarily conflating two contentious issues and will attract criticism of self serving motivation.” 1. I am not conflating the issues. I would argue that very fact that SegWit has not been activated yet is directly because of CVE-2017-9230. 2. I have no reason to believe that SegWit is contentious, except for the attackers who it would frustrate. 3. I have no negative responses to my endeavours to get ASICBOOST as regarded as a legitimate security vulnerability. This would suggest that it is not contentious in the wider technical community. If SegWit is NOT contentious within the technical community and it is NOT contentious to regard CVE-2017-9230 as a credible security vulnerability. Then using it as partial security fix for a security vulnerability SHOULD NOT be contentious. If you believe that SegWit is contentious within the technical community. Or you believe CVE-2017-9230 should not be regarded as a credible security vulnerability. Then I would logically agree with you that we should separate the issues so that we may gain consensus. However, I just don’t see this as the case. Cameron. > On 26 May 2017, at 09:52 , Andreas M. Antonopoulos > wrote: > > I rarely post here, out of respect to the mailing list. But since my name was > mentioned... > > I much prefer Gregory Maxwell's proposal to defuse covert ASICBOOST (only) > with a segwit-like commitment to the coinbase which does not obligate miners > to signal Segwit or implement Segwit, thus disarming any suspicion that the > issue is being exploited only to activate Segwit. > > This proposal is unnecessarily conflating two contentious issues and will > attract criticism of self serving motivation. > > Politicising CVE is damaging to the long term bitcoin development and to its > security. Not claiming that is the intent here, but the damage is done by the > mere appearance of motive. > > > > On May 26, 2017 16:30, "Cameron Garnham via bitcoin-dev" > wrote: > Hello Bitcoin-Dev, > > CVE-2017-9230 (1) (2), or commonly known as ‘ASICBOOST’ is a severe (3) (4) > and actively exploited (5) security vulnerability. > > To learn more about this vulnerability please read Jeremy Rubin’s detailed > report: > http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf > > Andreas Antonopoulos has an excellent presentation on why asicboost is > dangerous: > https://www.youtube.com/watch?v=t6jJDD2Aj8k > > In decisions on the #bitcoin-core-dev IRC channel; It was proposed, without > negative feedback, that SegWit be used as a partial-mitigation of > CVE-2017-9230. > > SegWit partially mitigates asicboost with the common reasonable assumption > that any block that doesn’t include a witness commit in it's coinbase > transaction was mined using covert asicboost. Making the use of covert > asicboost far more conspicuous. > > It was also proposed that this partial mitigation should be quickly > strengthened via another soft-fork that makes the inclusion of witness > commits mandatory, without negative feedback. > > The security trade-offs of deploying a partial-mitigation to CVE-2017-9230 > quickly vs more slowly but more conservatively is under intense debate. The > author of this post has a strong preference to the swiftest viable option. > > Cameron. > > > (1) CVE Entry: > https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230 > > (2) Announcement of CVE to Mailing List: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014416.html > > (3) Discussion of the perverse incentives created by 'ASICBOOST' by Ryan > Grant: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014352.html > > (4) Discussion of ASICBOOST's non-independent PoW calculation by Tier Nolan: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014351.html > > (5) Evidence of Active Exploit by Gregory Maxwell: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996
