From jerry.d.chan at bittoku.co.jp Sun Oct 1 12:53:49 2017 From: jerry.d.chan at bittoku.co.jp (digitsu) Date: Sun, 1 Oct 2017 21:53:49 +0900 Subject: [Bitcoin-segwit2x] August Status Report for SegWit2x In-Reply-To: References: <20170823153651.GA3232@savin.petertodd.org> <20170823183511.GA3479@savin.petertodd.org> <20170823190053.GA5037@savin.petertodd.org> <20170823192137.GA5288@savin.petertodd.org> Message-ID: <509739D8-C9F8-4505-9A99-23FDF95690B5@gmail.com> Exactly this. Why is the fact that NYA signalling miners switching to mine BCH for a time even a point of discussion here? NYA signalling means that miners are telling you they will support btc1 fork when the fork event occurs. It says NOTHING about what they can or cannot do BEFORE that event. For some reason, folks like PeterT think that signalling what you intend to do 3 months later is somehow violated by profit seeking behaviour done today. Perhaps this whole ?roundtable? and ?knights honor? theme has really gotten into people?s heads. > On Aug 24, 2017, at 04:34, Guy Corem via Bitcoin-segwit2x wrote: > > It seems you believe that the miners are fish, with short-term memory only. Bitcoin Cash gives exactly zero indication of what will happen with s2x. The pools that signed the agreement will not allow legacy chain mining. Sure, some of the core supporting miners will mine Slush pool, but I don't believe the hash rate on the legacy chain will be above 10%. > Without HF to adjust retargeting algorithm, the legacy chain will be unusable. > > On Aug 23, 2017 10:21 PM, "Peter Todd via Bitcoin-segwit2x" > wrote: > On Wed, Aug 23, 2017 at 08:12:13PM +0100, Alex Morcos wrote: > > Forget about the name. > > > > Peter's point is all the miners agreed to run Segwit2x-defined-Bitcoin > > (call this Bitcoin for short), yet they all defected from Bitcoin to run > > Bitcoin-Cash when it was in their economic interest. They will obviously > > defect from Bitcoin to run > > Old-Crappy-No2x-BlockstreamCore-Obstructionist-Not-Bitcoin in just the same > > way if it is also in their economic interest. > > Exactly. > > The questions about "What it Bitcoin?" are unrelated to my main point, which is > independent of what people decide to call things. I think you just did a better > job arguing it than me. :) > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From bitpico at icloud.com Mon Oct 2 07:00:24 2017 From: bitpico at icloud.com (bitPico) Date: Mon, 02 Oct 2017 03:00:24 -0400 Subject: [Bitcoin-segwit2x] August Status Report for SegWit2x In-Reply-To: <509739D8-C9F8-4505-9A99-23FDF95690B5@gmail.com> References: <20170823153651.GA3232@savin.petertodd.org> <20170823183511.GA3479@savin.petertodd.org> <20170823190053.GA5037@savin.petertodd.org> <20170823192137.GA5288@savin.petertodd.org> <509739D8-C9F8-4505-9A99-23FDF95690B5@gmail.com> Message-ID: This is a development list. Not for economic and speculative discussion. > On Oct 1, 2017, at 8:53 AM, digitsu via Bitcoin-segwit2x wrote: > > Exactly this. > > Why is the fact that NYA signalling miners switching to mine BCH for a time even a point of discussion here? NYA signalling means that miners are telling you they will support btc1 fork when the fork event occurs. It says NOTHING about what they can or cannot do BEFORE that event. For some reason, folks like PeterT think that signalling what you intend to do 3 months later is somehow violated by profit seeking behaviour done today. Perhaps this whole ?roundtable? and ?knights honor? theme has really gotten into people?s heads. > > > >> On Aug 24, 2017, at 04:34, Guy Corem via Bitcoin-segwit2x wrote: >> >> It seems you believe that the miners are fish, with short-term memory only. Bitcoin Cash gives exactly zero indication of what will happen with s2x. The pools that signed the agreement will not allow legacy chain mining. Sure, some of the core supporting miners will mine Slush pool, but I don't believe the hash rate on the legacy chain will be above 10%. >> Without HF to adjust retargeting algorithm, the legacy chain will be unusable. >> >>> On Aug 23, 2017 10:21 PM, "Peter Todd via Bitcoin-segwit2x" wrote: >>> On Wed, Aug 23, 2017 at 08:12:13PM +0100, Alex Morcos wrote: >>> > Forget about the name. >>> > >>> > Peter's point is all the miners agreed to run Segwit2x-defined-Bitcoin >>> > (call this Bitcoin for short), yet they all defected from Bitcoin to run >>> > Bitcoin-Cash when it was in their economic interest. They will obviously >>> > defect from Bitcoin to run >>> > Old-Crappy-No2x-BlockstreamCore-Obstructionist-Not-Bitcoin in just the same >>> > way if it is also in their economic interest. >>> >>> Exactly. >>> >>> The questions about "What it Bitcoin?" are unrelated to my main point, which is >>> independent of what people decide to call things. I think you just did a better >>> job arguing it than me. :) >>> >>> -- >>> https://petertodd.org 'peter'[:-1]@petertodd.org >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry.d.chan at bittoku.co.jp Tue Oct 3 12:58:34 2017 From: jerry.d.chan at bittoku.co.jp (Jerry D Chan) Date: Tue, 3 Oct 2017 21:58:34 +0900 Subject: [Bitcoin-segwit2x] August Status Report for SegWit2x In-Reply-To: References: <20170823153651.GA3232@savin.petertodd.org> <20170823183511.GA3479@savin.petertodd.org> <20170823190053.GA5037@savin.petertodd.org> <20170823192137.GA5288@savin.petertodd.org> <509739D8-C9F8-4505-9A99-23FDF95690B5@gmail.com> Message-ID: I thought it was along the same lines as Guy?s comment(s). If you want to make it clear that you are drawing a line here, maybe you'd want to make it publicly consistent. Jerry D Chan President and Founder Bittoku G.K. jerry.d.chan at bittoku.co.jp www.bittoku.co.jp > On Oct 2, 2017, at 16:00, bitPico via Bitcoin-segwit2x wrote: > > This is a development list. Not for economic and speculative discussion. > > On Oct 1, 2017, at 8:53 AM, digitsu via Bitcoin-segwit2x > wrote: > >> Exactly this. >> >> Why is the fact that NYA signalling miners switching to mine BCH for a time even a point of discussion here? NYA signalling means that miners are telling you they will support btc1 fork when the fork event occurs. It says NOTHING about what they can or cannot do BEFORE that event. For some reason, folks like PeterT think that signalling what you intend to do 3 months later is somehow violated by profit seeking behaviour done today. Perhaps this whole ?roundtable? and ?knights honor? theme has really gotten into people?s heads. >> >> >> >>> On Aug 24, 2017, at 04:34, Guy Corem via Bitcoin-segwit2x > wrote: >>> >>> It seems you believe that the miners are fish, with short-term memory only. Bitcoin Cash gives exactly zero indication of what will happen with s2x. The pools that signed the agreement will not allow legacy chain mining. Sure, some of the core supporting miners will mine Slush pool, but I don't believe the hash rate on the legacy chain will be above 10%. >>> Without HF to adjust retargeting algorithm, the legacy chain will be unusable. >>> >>> On Aug 23, 2017 10:21 PM, "Peter Todd via Bitcoin-segwit2x" > wrote: >>> On Wed, Aug 23, 2017 at 08:12:13PM +0100, Alex Morcos wrote: >>> > Forget about the name. >>> > >>> > Peter's point is all the miners agreed to run Segwit2x-defined-Bitcoin >>> > (call this Bitcoin for short), yet they all defected from Bitcoin to run >>> > Bitcoin-Cash when it was in their economic interest. They will obviously >>> > defect from Bitcoin to run >>> > Old-Crappy-No2x-BlockstreamCore-Obstructionist-Not-Bitcoin in just the same >>> > way if it is also in their economic interest. >>> >>> Exactly. >>> >>> The questions about "What it Bitcoin?" are unrelated to my main point, which is >>> independent of what people decide to call things. I think you just did a better >>> job arguing it than me. :) >>> >>> -- >>> https://petertodd.org 'peter'[:-1]@petertodd.org >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-08-10 at 2.19.56.png Type: image/png Size: 8427 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From opetruzel at gmail.com Wed Oct 4 17:17:02 2017 From: opetruzel at gmail.com (Oliver Petruzel) Date: Wed, 4 Oct 2017 13:17:02 -0400 Subject: [Bitcoin-segwit2x] Updated list of NYA signatories? In-Reply-To: References: Message-ID: All, Many throughout the community are under the mistaken impression that the original list of 58 NYA signatories is the complete list of those who have signed the agreement. However, the agreement itself has been available online for additional signatures since day one, and I know that others have signed it since. Where can we find and reference the updated/current list that includes all NYA signatories, and not just those who signed it during the initial conference? Thank you ahead of time! Respectfully, Oliver Petruzel Owner, Procryptic Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.bosworth at gmail.com Sun Oct 8 20:00:19 2017 From: alex.bosworth at gmail.com (Alex Bosworth) Date: Sun, 8 Oct 2017 13:00:19 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection Message-ID: In June of this year I asked about the provisions for strong 2-way replay protection. Strong 2-way replay protection means transactions valid on one chain should be invalid on the other, and vice-versa. I also asked about wipe-out protection, and that has since been implemented, which is great. I talked about the possibility of a contentious hard fork, where significant value persists across multiple chains. Support for the NYA hard fork is still lacking from Bitfinex, Local Bitcoins (the largest volume peer to peer exchange), Slush Pool, Trezor, Ledger, Electrum, and many others in the industry and individuals in the development and broader community. I know there has been some fervent hope that the contentious possibility of this hard fork would abate or become minimal in the remaining time, and that indeed was a laudable goal. But since June, contention has only risen. Instead of adding significant support to the agreement, important and longstanding Bitcoin companies such as BitWala, F2Pool, and others have pulled out of the New York Agreement that prompted this project. A number of signers have since decided to devote their energies to other currency projects, partially or in full. Early results from futures trading shows significant market demand for both sides of the fork. I can now say that preparations have begun in earnest to support both chains. The possibility of a contentious hard fork now looks like the probable future reality. Thus, this hard fork should provide strong 2-way replay protection. This means that transactions valid on one chain should be invalid on the other, and vice-versa. Without this protection, users would only be able to safely transact on the chains separately by using explicit splitting techniques, which puts excessive burden on the end user. I can restate suggestions from this list from Sergio Lerner and WuJihan who have pointed to encouraging multiple visions to coexist, potentially using a simple sighash modification that will fix the very simple technical problem that a valid signature authorizing a transaction of one currency should not be also used as a valid signature authorizing the transaction of another currency. Strong 2-way replay protection will help all businesses regardless of their position, and help regular users as well. I can quote from an industry statement regarding the previous contentious hard fork proposal BTU, which also proposed a hard fork coordinated around 3/4 hash power signaling: "However, none of the undersigned can list BTU unless we can run both chains independently without incident. Consequently, we insist that the Bitcoin Unlimited community (or any other consensus breaking implementation) build in strong two-way replay protection. Failure to do so will impede our ability to preserve BTU for customers and will either delay or outright preclude the listing of BTU." https://fs.bitcoinmagazine.com/assets/exchange_handling_of_contentious_hard_fork_event.pdf This quote specifically calls out "or any other consensus breaking implementation". The statement was signed by companies such as Bitstamp, Bitfinex, bitso, bitsquare, bittrex, btcc, btcchina, coinfloor, itbit, Kraken, QuadrigaCX, and ShapeShift. -- Sent from my iPhone From mike at bitgo.com Sun Oct 8 20:16:02 2017 From: mike at bitgo.com (Mike Belshe) Date: Sun, 8 Oct 2017 13:16:02 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: Alex - "Replay protection", as you call it, splits the chain. It simply doesn't make sense- you'd suddenly be breaking 10+million SPV clients that otherwise work just fine. It is a goal of segwit2x to help avoid this. Today, we're on course to deploy segwit2x with a vast majority of miners still signaling for it. On top of that, 99.94% of nodes & SPV clients will automatically follow that longest chain (segwit2x). I know some don't want Bitcoin to work this way, but this is the way that Bitcoin upgrades are implemented. Mike On Sun, Oct 8, 2017 at 1:00 PM, Alex Bosworth via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > In June of this year I asked about the provisions for strong 2-way > replay protection. Strong 2-way replay protection means transactions > valid on one chain should be invalid on the other, and vice-versa. I > also asked about wipe-out protection, and that has since been > implemented, which is great. > > I talked about the possibility of a contentious hard fork, where > significant value persists across multiple chains. Support for the NYA > hard fork is still lacking from Bitfinex, Local Bitcoins (the largest > volume peer to peer exchange), Slush Pool, Trezor, Ledger, Electrum, > and many others in the industry and individuals in the development and > broader community. > > I know there has been some fervent hope that the contentious > possibility of this hard fork would abate or become minimal in the > remaining time, and that indeed was a laudable goal. But since June, > contention has only risen. Instead of adding significant support to > the agreement, important and longstanding Bitcoin companies such as > BitWala, F2Pool, and others have pulled out of the New York Agreement > that prompted this project. A number of signers have since decided to > devote their energies to other currency projects, partially or in > full. > > Early results from futures trading shows significant market demand for > both sides of the fork. > > I can now say that preparations have begun in earnest to support both > chains. The possibility of a contentious hard fork now looks like the > probable future reality. Thus, this hard fork should provide strong > 2-way replay protection. This means that transactions valid on one > chain should be invalid on the other, and vice-versa. Without this > protection, users would only be able to safely transact on the chains > separately by using explicit splitting techniques, which puts > excessive burden on the end user. > > I can restate suggestions from this list from Sergio Lerner and > WuJihan who have pointed to encouraging multiple visions to coexist, > potentially using a simple sighash modification that will fix the very > simple technical problem that a valid signature authorizing a > transaction of one currency should not be also used as a valid > signature authorizing the transaction of another currency. > > Strong 2-way replay protection will help all businesses regardless of > their position, and help regular users as well. I can quote from an > industry statement regarding the previous contentious hard fork > proposal BTU, which also proposed a hard fork coordinated around 3/4 > hash power signaling: > > "However, none of the undersigned can list BTU unless we can run both > chains independently without incident. Consequently, we insist that > the Bitcoin Unlimited community (or any other consensus breaking > implementation) build in strong two-way replay protection. Failure to > do so will impede our ability to preserve BTU for customers and will > either delay or outright preclude the listing of BTU." > > https://fs.bitcoinmagazine.com/assets/exchange_handling_ > of_contentious_hard_fork_event.pdf > > This quote specifically calls out "or any other consensus breaking > implementation". The statement was signed by companies such as > Bitstamp, Bitfinex, bitso, bitsquare, bittrex, btcc, btcchina, > coinfloor, itbit, Kraken, QuadrigaCX, and ShapeShift. > > > > -- > Sent from my iPhone > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- *Mike Belshe* *CEO, BitGo, Inc*408-718-6885 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.eliosoff at gmail.com Sun Oct 8 20:31:48 2017 From: jacob.eliosoff at gmail.com (Jacob Eliosoff) Date: Sun, 8 Oct 2017 16:31:48 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: Alex, this has of course been much discussed. My 2c: 1. A lot of the replay debate comes down to, will the 2x chain accept txs sent post-split, by non-upgraded wallet software? As Mike said, there's strong consensus among Segwit2x folks that proposals which reject these txs (eg, the Bitcoin Cash approach) are a no-go, and a waste of time. 2. That said - I and others would love to see good 2-way replay protection if it meets that backwards-compatibility constraint, and there are approaches that do: see eg https://github.com/btc1/bitcoin/issues/34#issuecomment-329251611. Yes, the two chains are competing for users, but there are still ways we could protect *all* users from unintended sends (which no one wants to happen) if we're civilized about it. Unfortunately these approaches are unlikely to happen without buy-in from Core (eg, to make the 1x chain reject txs explicitly specifying 2x, in exchange for vice versa). On Sun, Oct 8, 2017 at 4:16 PM, Mike Belshe via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Alex - > > "Replay protection", as you call it, splits the chain. It simply doesn't > make sense- you'd suddenly be breaking 10+million SPV clients that > otherwise work just fine. It is a goal of segwit2x to help avoid this. > > Today, we're on course to deploy segwit2x with a vast majority of miners > still signaling for it. On top of that, 99.94% of nodes & SPV clients will > automatically follow that longest chain (segwit2x). > > I know some don't want Bitcoin to work this way, but this is the way that > Bitcoin upgrades are implemented. > > Mike > > > On Sun, Oct 8, 2017 at 1:00 PM, Alex Bosworth via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> In June of this year I asked about the provisions for strong 2-way >> replay protection. Strong 2-way replay protection means transactions >> valid on one chain should be invalid on the other, and vice-versa. I >> also asked about wipe-out protection, and that has since been >> implemented, which is great. >> >> I talked about the possibility of a contentious hard fork, where >> significant value persists across multiple chains. Support for the NYA >> hard fork is still lacking from Bitfinex, Local Bitcoins (the largest >> volume peer to peer exchange), Slush Pool, Trezor, Ledger, Electrum, >> and many others in the industry and individuals in the development and >> broader community. >> >> I know there has been some fervent hope that the contentious >> possibility of this hard fork would abate or become minimal in the >> remaining time, and that indeed was a laudable goal. But since June, >> contention has only risen. Instead of adding significant support to >> the agreement, important and longstanding Bitcoin companies such as >> BitWala, F2Pool, and others have pulled out of the New York Agreement >> that prompted this project. A number of signers have since decided to >> devote their energies to other currency projects, partially or in >> full. >> >> Early results from futures trading shows significant market demand for >> both sides of the fork. >> >> I can now say that preparations have begun in earnest to support both >> chains. The possibility of a contentious hard fork now looks like the >> probable future reality. Thus, this hard fork should provide strong >> 2-way replay protection. This means that transactions valid on one >> chain should be invalid on the other, and vice-versa. Without this >> protection, users would only be able to safely transact on the chains >> separately by using explicit splitting techniques, which puts >> excessive burden on the end user. >> >> I can restate suggestions from this list from Sergio Lerner and >> WuJihan who have pointed to encouraging multiple visions to coexist, >> potentially using a simple sighash modification that will fix the very >> simple technical problem that a valid signature authorizing a >> transaction of one currency should not be also used as a valid >> signature authorizing the transaction of another currency. >> >> Strong 2-way replay protection will help all businesses regardless of >> their position, and help regular users as well. I can quote from an >> industry statement regarding the previous contentious hard fork >> proposal BTU, which also proposed a hard fork coordinated around 3/4 >> hash power signaling: >> >> "However, none of the undersigned can list BTU unless we can run both >> chains independently without incident. Consequently, we insist that >> the Bitcoin Unlimited community (or any other consensus breaking >> implementation) build in strong two-way replay protection. Failure to >> do so will impede our ability to preserve BTU for customers and will >> either delay or outright preclude the listing of BTU." >> >> https://fs.bitcoinmagazine.com/assets/exchange_handling_of_ >> contentious_hard_fork_event.pdf >> >> This quote specifically calls out "or any other consensus breaking >> implementation". The statement was signed by companies such as >> Bitstamp, Bitfinex, bitso, bitsquare, bittrex, btcc, btcchina, >> coinfloor, itbit, Kraken, QuadrigaCX, and ShapeShift. >> >> >> >> -- >> Sent from my iPhone >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > > > -- > > > *Mike Belshe* > *CEO, BitGo, Inc*408-718-6885 <(408)%20718-6885> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameson.lopp at gmail.com Sun Oct 8 20:40:37 2017 From: jameson.lopp at gmail.com (Jameson Lopp) Date: Sun, 8 Oct 2017 16:40:37 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: It seems clear to me that there is going to be a chain split, so the question comes down to who is going to put in the effort to protect users from accidentally sending crypto assets that they had no intention of sending. Without strong native two way replay protection at the protocol level, the responsibility will fall upon every wallet and service provider. As a result I'd expect to see a longer period of disruption / inaccessibility than we saw with the BCH fork, and probably several orders of magnitude greater instances of nontechnical users making mistakes to their own detriment. I suspect that such a situation is destined to happen sooner or later given the permissionless nature of forks. The grand experiment must go on! On Sun, Oct 8, 2017 at 4:31 PM, Jacob Eliosoff via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Alex, this has of course been much discussed. My 2c: > > 1. A lot of the replay debate comes down to, will the 2x chain accept > txs sent post-split, by non-upgraded wallet software? As Mike said, > there's strong consensus among Segwit2x folks that proposals which reject > these txs (eg, the Bitcoin Cash approach) are a no-go, and a waste of time. > > 2. That said - I and others would love to see good 2-way replay > protection if it meets that backwards-compatibility constraint, and there > are approaches that do: see eg https://github.com/btc1/ > bitcoin/issues/34#issuecomment-329251611 > . > Yes, the two chains are competing for users, but there are still ways we > could protect *all* users from unintended sends (which no one wants to > happen) if we're civilized about it. Unfortunately these approaches are > unlikely to happen without buy-in from Core (eg, to make the 1x chain > reject txs explicitly specifying 2x, in exchange for vice versa). > > > > On Sun, Oct 8, 2017 at 4:16 PM, Mike Belshe via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Alex - >> >> "Replay protection", as you call it, splits the chain. It simply doesn't >> make sense- you'd suddenly be breaking 10+million SPV clients that >> otherwise work just fine. It is a goal of segwit2x to help avoid this. >> >> Today, we're on course to deploy segwit2x with a vast majority of miners >> still signaling for it. On top of that, 99.94% of nodes & SPV clients will >> automatically follow that longest chain (segwit2x). >> >> I know some don't want Bitcoin to work this way, but this is the way that >> Bitcoin upgrades are implemented. >> >> Mike >> >> >> On Sun, Oct 8, 2017 at 1:00 PM, Alex Bosworth via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> In June of this year I asked about the provisions for strong 2-way >>> replay protection. Strong 2-way replay protection means transactions >>> valid on one chain should be invalid on the other, and vice-versa. I >>> also asked about wipe-out protection, and that has since been >>> implemented, which is great. >>> >>> I talked about the possibility of a contentious hard fork, where >>> significant value persists across multiple chains. Support for the NYA >>> hard fork is still lacking from Bitfinex, Local Bitcoins (the largest >>> volume peer to peer exchange), Slush Pool, Trezor, Ledger, Electrum, >>> and many others in the industry and individuals in the development and >>> broader community. >>> >>> I know there has been some fervent hope that the contentious >>> possibility of this hard fork would abate or become minimal in the >>> remaining time, and that indeed was a laudable goal. But since June, >>> contention has only risen. Instead of adding significant support to >>> the agreement, important and longstanding Bitcoin companies such as >>> BitWala, F2Pool, and others have pulled out of the New York Agreement >>> that prompted this project. A number of signers have since decided to >>> devote their energies to other currency projects, partially or in >>> full. >>> >>> Early results from futures trading shows significant market demand for >>> both sides of the fork. >>> >>> I can now say that preparations have begun in earnest to support both >>> chains. The possibility of a contentious hard fork now looks like the >>> probable future reality. Thus, this hard fork should provide strong >>> 2-way replay protection. This means that transactions valid on one >>> chain should be invalid on the other, and vice-versa. Without this >>> protection, users would only be able to safely transact on the chains >>> separately by using explicit splitting techniques, which puts >>> excessive burden on the end user. >>> >>> I can restate suggestions from this list from Sergio Lerner and >>> WuJihan who have pointed to encouraging multiple visions to coexist, >>> potentially using a simple sighash modification that will fix the very >>> simple technical problem that a valid signature authorizing a >>> transaction of one currency should not be also used as a valid >>> signature authorizing the transaction of another currency. >>> >>> Strong 2-way replay protection will help all businesses regardless of >>> their position, and help regular users as well. I can quote from an >>> industry statement regarding the previous contentious hard fork >>> proposal BTU, which also proposed a hard fork coordinated around 3/4 >>> hash power signaling: >>> >>> "However, none of the undersigned can list BTU unless we can run both >>> chains independently without incident. Consequently, we insist that >>> the Bitcoin Unlimited community (or any other consensus breaking >>> implementation) build in strong two-way replay protection. Failure to >>> do so will impede our ability to preserve BTU for customers and will >>> either delay or outright preclude the listing of BTU." >>> >>> https://fs.bitcoinmagazine.com/assets/exchange_handling_of_c >>> ontentious_hard_fork_event.pdf >>> >>> This quote specifically calls out "or any other consensus breaking >>> implementation". The statement was signed by companies such as >>> Bitstamp, Bitfinex, bitso, bitsquare, bittrex, btcc, btcchina, >>> coinfloor, itbit, Kraken, QuadrigaCX, and ShapeShift. >>> >>> >>> >>> -- >>> Sent from my iPhone >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >> >> >> >> -- >> >> >> *Mike Belshe* >> *CEO, BitGo, Inc*408-718-6885 <(408)%20718-6885> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Sun Oct 8 20:43:04 2017 From: bitpico at icloud.com (bitPico) Date: Sun, 08 Oct 2017 16:43:04 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: NACK We will not be altering our non-Satoshi codebase to implement something that is: 1. Not needed (1x is legacy code) 2. Splits the chain (for no good reason) 3. Breaks all existing SPV nodes including ours (see 2.) There are at least four other non-Satoshi code full nodes and it?s unlikely they will modify their code either for the same reasons above. > On Oct 8, 2017, at 4:16 PM, Mike Belshe via Bitcoin-segwit2x wrote: > > Alex - > > "Replay protection", as you call it, splits the chain. It simply doesn't make sense- you'd suddenly be breaking 10+million SPV clients that otherwise work just fine. It is a goal of segwit2x to help avoid this. > > Today, we're on course to deploy segwit2x with a vast majority of miners still signaling for it. On top of that, 99.94% of nodes & SPV clients will automatically follow that longest chain (segwit2x). > > I know some don't want Bitcoin to work this way, but this is the way that Bitcoin upgrades are implemented. > > Mike > > >> On Sun, Oct 8, 2017 at 1:00 PM, Alex Bosworth via Bitcoin-segwit2x wrote: >> In June of this year I asked about the provisions for strong 2-way >> replay protection. Strong 2-way replay protection means transactions >> valid on one chain should be invalid on the other, and vice-versa. I >> also asked about wipe-out protection, and that has since been >> implemented, which is great. >> >> I talked about the possibility of a contentious hard fork, where >> significant value persists across multiple chains. Support for the NYA >> hard fork is still lacking from Bitfinex, Local Bitcoins (the largest >> volume peer to peer exchange), Slush Pool, Trezor, Ledger, Electrum, >> and many others in the industry and individuals in the development and >> broader community. >> >> I know there has been some fervent hope that the contentious >> possibility of this hard fork would abate or become minimal in the >> remaining time, and that indeed was a laudable goal. But since June, >> contention has only risen. Instead of adding significant support to >> the agreement, important and longstanding Bitcoin companies such as >> BitWala, F2Pool, and others have pulled out of the New York Agreement >> that prompted this project. A number of signers have since decided to >> devote their energies to other currency projects, partially or in >> full. >> >> Early results from futures trading shows significant market demand for >> both sides of the fork. >> >> I can now say that preparations have begun in earnest to support both >> chains. The possibility of a contentious hard fork now looks like the >> probable future reality. Thus, this hard fork should provide strong >> 2-way replay protection. This means that transactions valid on one >> chain should be invalid on the other, and vice-versa. Without this >> protection, users would only be able to safely transact on the chains >> separately by using explicit splitting techniques, which puts >> excessive burden on the end user. >> >> I can restate suggestions from this list from Sergio Lerner and >> WuJihan who have pointed to encouraging multiple visions to coexist, >> potentially using a simple sighash modification that will fix the very >> simple technical problem that a valid signature authorizing a >> transaction of one currency should not be also used as a valid >> signature authorizing the transaction of another currency. >> >> Strong 2-way replay protection will help all businesses regardless of >> their position, and help regular users as well. I can quote from an >> industry statement regarding the previous contentious hard fork >> proposal BTU, which also proposed a hard fork coordinated around 3/4 >> hash power signaling: >> >> "However, none of the undersigned can list BTU unless we can run both >> chains independently without incident. Consequently, we insist that >> the Bitcoin Unlimited community (or any other consensus breaking >> implementation) build in strong two-way replay protection. Failure to >> do so will impede our ability to preserve BTU for customers and will >> either delay or outright preclude the listing of BTU." >> >> https://fs.bitcoinmagazine.com/assets/exchange_handling_of_contentious_hard_fork_event.pdf >> >> This quote specifically calls out "or any other consensus breaking >> implementation". The statement was signed by companies such as >> Bitstamp, Bitfinex, bitso, bitsquare, bittrex, btcc, btcchina, >> coinfloor, itbit, Kraken, QuadrigaCX, and ShapeShift. >> >> >> >> -- >> Sent from my iPhone >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > -- > Mike Belshe > CEO, BitGo, Inc > 408-718-6885 > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Sun Oct 8 20:51:46 2017 From: bitpico at icloud.com (bitPico) Date: Sun, 08 Oct 2017 16:51:46 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: <634AB444-FB53-4DE5-804F-EB80F56B7D6D@icloud.com> This is a technical working group not one for speculation. If two chains emerge the weaker one MUST protect itself. We will know the weaker chain almost instantly when block 494,784 is passed. Until block 494,784 this is a non-issue. > On Oct 8, 2017, at 4:40 PM, Jameson Lopp via Bitcoin-segwit2x wrote: > > It seems clear to me that there is going to be a chain split, so the question comes down to who is going to put in the effort to protect users from accidentally sending crypto assets that they had no intention of sending. Without strong native two way replay protection at the protocol level, the responsibility will fall upon every wallet and service provider. As a result I'd expect to see a longer period of disruption / inaccessibility than we saw with the BCH fork, and probably several orders of magnitude greater instances of nontechnical users making mistakes to their own detriment. > > I suspect that such a situation is destined to happen sooner or later given the permissionless nature of forks. The grand experiment must go on! > From marcel at jamin.net Sun Oct 8 21:03:09 2017 From: marcel at jamin.net (Marcel Jamin) Date: Sun, 8 Oct 2017 23:03:09 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: <634AB444-FB53-4DE5-804F-EB80F56B7D6D@icloud.com> References: <634AB444-FB53-4DE5-804F-EB80F56B7D6D@icloud.com> Message-ID: You can't really compare chains with differing rulesets. Am 08.10.2017 22:52 schrieb "bitPico via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org>: > This is a technical working group not one for speculation. If two chains > emerge the weaker one MUST protect itself. We will know the weaker chain > almost instantly when block 494,784 is passed. Until block 494,784 this is > a non-issue. > > > On Oct 8, 2017, at 4:40 PM, Jameson Lopp via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > > > It seems clear to me that there is going to be a chain split, so the > question comes down to who is going to put in the effort to protect users > from accidentally sending crypto assets that they had no intention of > sending. Without strong native two way replay protection at the protocol > level, the responsibility will fall upon every wallet and service provider. > As a result I'd expect to see a longer period of disruption / > inaccessibility than we saw with the BCH fork, and probably several orders > of magnitude greater instances of nontechnical users making mistakes to > their own detriment. > > > > I suspect that such a situation is destined to happen sooner or later > given the permissionless nature of forks. The grand experiment must go on! > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameson.lopp at gmail.com Sun Oct 8 21:18:55 2017 From: jameson.lopp at gmail.com (Jameson Lopp) Date: Sun, 8 Oct 2017 17:18:55 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: <634AB444-FB53-4DE5-804F-EB80F56B7D6D@icloud.com> References: <634AB444-FB53-4DE5-804F-EB80F56B7D6D@icloud.com> Message-ID: Whatever measure you may use for "strength" or "weakness" is irrelevant - replay issues can affect any chain fork when there's inadequate protection at the protocol layer. Given the inability to force software updates in a permissionless system, the optimal thing for groups that have already committed to deploy updated software is for them to protect users of both forks, but you could argue that this more an issue of morality. From a technical standpoint, as I mentioned before, lack of native protection results in the responsibility then falling upon the wallet and service layer. On Sun, Oct 8, 2017 at 4:51 PM, bitPico wrote: > This is a technical working group not one for speculation. If two chains > emerge the weaker one MUST protect itself. We will know the weaker chain > almost instantly when block 494,784 is passed. Until block 494,784 this is > a non-issue. > > > On Oct 8, 2017, at 4:40 PM, Jameson Lopp via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > > > It seems clear to me that there is going to be a chain split, so the > question comes down to who is going to put in the effort to protect users > from accidentally sending crypto assets that they had no intention of > sending. Without strong native two way replay protection at the protocol > level, the responsibility will fall upon every wallet and service provider. > As a result I'd expect to see a longer period of disruption / > inaccessibility than we saw with the BCH fork, and probably several orders > of magnitude greater instances of nontechnical users making mistakes to > their own detriment. > > > > I suspect that such a situation is destined to happen sooner or later > given the permissionless nature of forks. The grand experiment must go on! > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaredr26 at gmail.com Sun Oct 8 21:20:37 2017 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Sun, 8 Oct 2017 14:20:37 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: > As a result I'd expect to see a longer period of disruption / inaccessibility than we saw with the BCH fork, and probably several orders of magnitude greater instances of nontechnical users making mistakes to their own detriment. Great, so either Core can compromise after 2 years of refusing, or Core should be adding strong two-way replay protection the fork that is rejecting overwhelming consensus. The window is probably passing for both sides to symmetrically fork as I proposed months ago. Either way, this project is taking the correct actions with the best chance of keeping the community together - Optional replay protection for those who care about the drama. Jared On Sun, Oct 8, 2017 at 1:40 PM, Jameson Lopp via Bitcoin-segwit2x wrote: > It seems clear to me that there is going to be a chain split, so the > question comes down to who is going to put in the effort to protect users > from accidentally sending crypto assets that they had no intention of > sending. Without strong native two way replay protection at the protocol > level, the responsibility will fall upon every wallet and service provider. > As a result I'd expect to see a longer period of disruption / > inaccessibility than we saw with the BCH fork, and probably several orders > of magnitude greater instances of nontechnical users making mistakes to > their own detriment. > > I suspect that such a situation is destined to happen sooner or later given > the permissionless nature of forks. The grand experiment must go on! > > On Sun, Oct 8, 2017 at 4:31 PM, Jacob Eliosoff via Bitcoin-segwit2x > wrote: >> >> Alex, this has of course been much discussed. My 2c: >> >> A lot of the replay debate comes down to, will the 2x chain accept txs >> sent post-split, by non-upgraded wallet software? As Mike said, there's >> strong consensus among Segwit2x folks that proposals which reject these txs >> (eg, the Bitcoin Cash approach) are a no-go, and a waste of time. >> >> That said - I and others would love to see good 2-way replay protection if >> it meets that backwards-compatibility constraint, and there are approaches >> that do: see eg >> https://github.com/btc1/bitcoin/issues/34#issuecomment-329251611. Yes, the >> two chains are competing for users, but there are still ways we could >> protect all users from unintended sends (which no one wants to happen) if >> we're civilized about it. Unfortunately these approaches are unlikely to >> happen without buy-in from Core (eg, to make the 1x chain reject txs >> explicitly specifying 2x, in exchange for vice versa). >> >> >> >> On Sun, Oct 8, 2017 at 4:16 PM, Mike Belshe via Bitcoin-segwit2x >> wrote: >>> >>> Alex - >>> >>> "Replay protection", as you call it, splits the chain. It simply doesn't >>> make sense- you'd suddenly be breaking 10+million SPV clients that otherwise >>> work just fine. It is a goal of segwit2x to help avoid this. >>> >>> Today, we're on course to deploy segwit2x with a vast majority of miners >>> still signaling for it. On top of that, 99.94% of nodes & SPV clients will >>> automatically follow that longest chain (segwit2x). >>> >>> I know some don't want Bitcoin to work this way, but this is the way that >>> Bitcoin upgrades are implemented. >>> >>> Mike >>> >>> >>> On Sun, Oct 8, 2017 at 1:00 PM, Alex Bosworth via Bitcoin-segwit2x >>> wrote: >>>> >>>> In June of this year I asked about the provisions for strong 2-way >>>> replay protection. Strong 2-way replay protection means transactions >>>> valid on one chain should be invalid on the other, and vice-versa. I >>>> also asked about wipe-out protection, and that has since been >>>> implemented, which is great. >>>> >>>> I talked about the possibility of a contentious hard fork, where >>>> significant value persists across multiple chains. Support for the NYA >>>> hard fork is still lacking from Bitfinex, Local Bitcoins (the largest >>>> volume peer to peer exchange), Slush Pool, Trezor, Ledger, Electrum, >>>> and many others in the industry and individuals in the development and >>>> broader community. >>>> >>>> I know there has been some fervent hope that the contentious >>>> possibility of this hard fork would abate or become minimal in the >>>> remaining time, and that indeed was a laudable goal. But since June, >>>> contention has only risen. Instead of adding significant support to >>>> the agreement, important and longstanding Bitcoin companies such as >>>> BitWala, F2Pool, and others have pulled out of the New York Agreement >>>> that prompted this project. A number of signers have since decided to >>>> devote their energies to other currency projects, partially or in >>>> full. >>>> >>>> Early results from futures trading shows significant market demand for >>>> both sides of the fork. >>>> >>>> I can now say that preparations have begun in earnest to support both >>>> chains. The possibility of a contentious hard fork now looks like the >>>> probable future reality. Thus, this hard fork should provide strong >>>> 2-way replay protection. This means that transactions valid on one >>>> chain should be invalid on the other, and vice-versa. Without this >>>> protection, users would only be able to safely transact on the chains >>>> separately by using explicit splitting techniques, which puts >>>> excessive burden on the end user. >>>> >>>> I can restate suggestions from this list from Sergio Lerner and >>>> WuJihan who have pointed to encouraging multiple visions to coexist, >>>> potentially using a simple sighash modification that will fix the very >>>> simple technical problem that a valid signature authorizing a >>>> transaction of one currency should not be also used as a valid >>>> signature authorizing the transaction of another currency. >>>> >>>> Strong 2-way replay protection will help all businesses regardless of >>>> their position, and help regular users as well. I can quote from an >>>> industry statement regarding the previous contentious hard fork >>>> proposal BTU, which also proposed a hard fork coordinated around 3/4 >>>> hash power signaling: >>>> >>>> "However, none of the undersigned can list BTU unless we can run both >>>> chains independently without incident. Consequently, we insist that >>>> the Bitcoin Unlimited community (or any other consensus breaking >>>> implementation) build in strong two-way replay protection. Failure to >>>> do so will impede our ability to preserve BTU for customers and will >>>> either delay or outright preclude the listing of BTU." >>>> >>>> >>>> https://fs.bitcoinmagazine.com/assets/exchange_handling_of_contentious_hard_fork_event.pdf >>>> >>>> This quote specifically calls out "or any other consensus breaking >>>> implementation". The statement was signed by companies such as >>>> Bitstamp, Bitfinex, bitso, bitsquare, bittrex, btcc, btcchina, >>>> coinfloor, itbit, Kraken, QuadrigaCX, and ShapeShift. >>>> >>>> >>>> >>>> -- >>>> Sent from my iPhone >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> >>> >>> -- >>> >>> Mike Belshe >>> CEO, BitGo, Inc >>> 408-718-6885 >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From alex.bosworth at gmail.com Sun Oct 8 21:38:50 2017 From: alex.bosworth at gmail.com (Alex Bosworth) Date: Sun, 08 Oct 2017 21:38:50 +0000 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: The Bitcoin Core process is quite unrelated to this question. Regardless of which code they do or do not merge into their repositories, it is the existing set of nodes with the existing set of software that is the question. Bitcoin Core may be a convenient landmark to point to as far as social sympathies go, but the technical reality is that the decentralized nature of the network means that existing full nodes and all existing wallet software without auto-update cannot be changed by any technical means. So the only sure way to prevent inadvertent opposite side spending from the existing user base who do not update is through the implementation of strong 2 way replay protection. Companies are already preparing for the reality of splitting. This is a purely technical issue, an equal problem for both sides of the fork. If we knew with great certainty that the market for the one side of the fork was so minimal that the issue was not worth considering, that would be a fine practical argument against worrying about replay protection. As things stand, businesses, users and futures markets do not reflect such a certainty. On Sun, Oct 8, 2017 at 2:20 PM Jared Lee Richardson via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > As a result I'd expect to see a longer period of disruption / > inaccessibility than we saw with the BCH fork, and probably several orders > of magnitude greater instances of nontechnical users making mistakes to > their own detriment. > > Great, so either Core can compromise after 2 years of refusing, or > Core should be adding strong two-way replay protection the fork that > is rejecting overwhelming consensus. The window is probably passing > for both sides to symmetrically fork as I proposed months ago. > > Either way, this project is taking the correct actions with the best > chance of keeping the community together - Optional replay protection > for those who care about the drama. > > Jared > > On Sun, Oct 8, 2017 at 1:40 PM, Jameson Lopp via Bitcoin-segwit2x > wrote: > > It seems clear to me that there is going to be a chain split, so the > > question comes down to who is going to put in the effort to protect users > > from accidentally sending crypto assets that they had no intention of > > sending. Without strong native two way replay protection at the protocol > > level, the responsibility will fall upon every wallet and service > provider. > > As a result I'd expect to see a longer period of disruption / > > inaccessibility than we saw with the BCH fork, and probably several > orders > > of magnitude greater instances of nontechnical users making mistakes to > > their own detriment. > > > > I suspect that such a situation is destined to happen sooner or later > given > > the permissionless nature of forks. The grand experiment must go on! > > > > On Sun, Oct 8, 2017 at 4:31 PM, Jacob Eliosoff via Bitcoin-segwit2x > > wrote: > >> > >> Alex, this has of course been much discussed. My 2c: > >> > >> A lot of the replay debate comes down to, will the 2x chain accept txs > >> sent post-split, by non-upgraded wallet software? As Mike said, there's > >> strong consensus among Segwit2x folks that proposals which reject these > txs > >> (eg, the Bitcoin Cash approach) are a no-go, and a waste of time. > >> > >> That said - I and others would love to see good 2-way replay protection > if > >> it meets that backwards-compatibility constraint, and there are > approaches > >> that do: see eg > >> https://github.com/btc1/bitcoin/issues/34#issuecomment-329251611. > Yes, the > >> two chains are competing for users, but there are still ways we could > >> protect all users from unintended sends (which no one wants to happen) > if > >> we're civilized about it. Unfortunately these approaches are unlikely > to > >> happen without buy-in from Core (eg, to make the 1x chain reject txs > >> explicitly specifying 2x, in exchange for vice versa). > >> > >> > >> > >> On Sun, Oct 8, 2017 at 4:16 PM, Mike Belshe via Bitcoin-segwit2x > >> wrote: > >>> > >>> Alex - > >>> > >>> "Replay protection", as you call it, splits the chain. It simply > doesn't > >>> make sense- you'd suddenly be breaking 10+million SPV clients that > otherwise > >>> work just fine. It is a goal of segwit2x to help avoid this. > >>> > >>> Today, we're on course to deploy segwit2x with a vast majority of > miners > >>> still signaling for it. On top of that, 99.94% of nodes & SPV clients > will > >>> automatically follow that longest chain (segwit2x). > >>> > >>> I know some don't want Bitcoin to work this way, but this is the way > that > >>> Bitcoin upgrades are implemented. > >>> > >>> Mike > >>> > >>> > >>> On Sun, Oct 8, 2017 at 1:00 PM, Alex Bosworth via Bitcoin-segwit2x > >>> wrote: > >>>> > >>>> In June of this year I asked about the provisions for strong 2-way > >>>> replay protection. Strong 2-way replay protection means transactions > >>>> valid on one chain should be invalid on the other, and vice-versa. I > >>>> also asked about wipe-out protection, and that has since been > >>>> implemented, which is great. > >>>> > >>>> I talked about the possibility of a contentious hard fork, where > >>>> significant value persists across multiple chains. Support for the NYA > >>>> hard fork is still lacking from Bitfinex, Local Bitcoins (the largest > >>>> volume peer to peer exchange), Slush Pool, Trezor, Ledger, Electrum, > >>>> and many others in the industry and individuals in the development and > >>>> broader community. > >>>> > >>>> I know there has been some fervent hope that the contentious > >>>> possibility of this hard fork would abate or become minimal in the > >>>> remaining time, and that indeed was a laudable goal. But since June, > >>>> contention has only risen. Instead of adding significant support to > >>>> the agreement, important and longstanding Bitcoin companies such as > >>>> BitWala, F2Pool, and others have pulled out of the New York Agreement > >>>> that prompted this project. A number of signers have since decided to > >>>> devote their energies to other currency projects, partially or in > >>>> full. > >>>> > >>>> Early results from futures trading shows significant market demand for > >>>> both sides of the fork. > >>>> > >>>> I can now say that preparations have begun in earnest to support both > >>>> chains. The possibility of a contentious hard fork now looks like the > >>>> probable future reality. Thus, this hard fork should provide strong > >>>> 2-way replay protection. This means that transactions valid on one > >>>> chain should be invalid on the other, and vice-versa. Without this > >>>> protection, users would only be able to safely transact on the chains > >>>> separately by using explicit splitting techniques, which puts > >>>> excessive burden on the end user. > >>>> > >>>> I can restate suggestions from this list from Sergio Lerner and > >>>> WuJihan who have pointed to encouraging multiple visions to coexist, > >>>> potentially using a simple sighash modification that will fix the very > >>>> simple technical problem that a valid signature authorizing a > >>>> transaction of one currency should not be also used as a valid > >>>> signature authorizing the transaction of another currency. > >>>> > >>>> Strong 2-way replay protection will help all businesses regardless of > >>>> their position, and help regular users as well. I can quote from an > >>>> industry statement regarding the previous contentious hard fork > >>>> proposal BTU, which also proposed a hard fork coordinated around 3/4 > >>>> hash power signaling: > >>>> > >>>> "However, none of the undersigned can list BTU unless we can run both > >>>> chains independently without incident. Consequently, we insist that > >>>> the Bitcoin Unlimited community (or any other consensus breaking > >>>> implementation) build in strong two-way replay protection. Failure to > >>>> do so will impede our ability to preserve BTU for customers and will > >>>> either delay or outright preclude the listing of BTU." > >>>> > >>>> > >>>> > https://fs.bitcoinmagazine.com/assets/exchange_handling_of_contentious_hard_fork_event.pdf > >>>> > >>>> This quote specifically calls out "or any other consensus breaking > >>>> implementation". The statement was signed by companies such as > >>>> Bitstamp, Bitfinex, bitso, bitsquare, bittrex, btcc, btcchina, > >>>> coinfloor, itbit, Kraken, QuadrigaCX, and ShapeShift. > >>>> > >>>> > >>>> > >>>> -- > >>>> Sent from my iPhone > >>>> _______________________________________________ > >>>> Bitcoin-segwit2x mailing list > >>>> Bitcoin-segwit2x at lists.linuxfoundation.org > >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>> > >>> > >>> > >>> > >>> -- > >>> > >>> Mike Belshe > >>> CEO, BitGo, Inc > >>> 408-718-6885 > >>> > >>> > >>> _______________________________________________ > >>> Bitcoin-segwit2x mailing list > >>> Bitcoin-segwit2x at lists.linuxfoundation.org > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>> > >> > >> > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- Sent from my iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Sun Oct 8 21:49:36 2017 From: bitpico at icloud.com (bitPico) Date: Sun, 08 Oct 2017 17:49:36 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <634AB444-FB53-4DE5-804F-EB80F56B7D6D@icloud.com> Message-ID: Forcing upgrades is accomplished through miners both historically and documented by the inventor of Bitcoin (read the white paper about the chain with the most proof of work) as they own the blockchain; full nodes only enforce miners rules and cannot produce any blocks (that is proof of stake). The 1 megabyte base blocks size is deprecated. We are upgrading from old software to new software (2 Megabyte base block size). The users that upgrade to the ?non-deprecated? Bitcoin implementations have no problems. The ones who fail to upgrade are irrelevant to this working group and to Bitcoin as a whole. > On Oct 8, 2017, at 5:18 PM, Jameson Lopp via Bitcoin-segwit2x wrote: > > Whatever measure you may use for "strength" or "weakness" is irrelevant - replay issues can affect any chain fork when there's inadequate protection at the protocol layer. > > Given the inability to force software updates in a permissionless system, the optimal thing for groups that have already committed to deploy updated software is for them to protect users of both forks, but you could argue that this more an issue of morality. From a technical standpoint, as I mentioned before, lack of native protection results in the responsibility then falling upon the wallet and service layer. > From jaredr26 at gmail.com Sun Oct 8 21:50:21 2017 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Sun, 8 Oct 2017 14:50:21 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: > So the only sure way to prevent inadvertent opposite side spending from the existing user base who do not update is through the implementation of strong 2 way replay protection. Or, you know, realize that human beings are not mysterious black boxes, and they do update when they have a reason to do so. > This is a purely technical issue, an equal problem for both sides of the fork. Nothing about the blocksize debate is a technical issue at this point. Complete ignorance of economics, game theory, and psychology is what got us to this point. Continuing to ignore it is not going to get us anywhere better. On Sun, Oct 8, 2017 at 2:38 PM, Alex Bosworth wrote: > The Bitcoin Core process is quite unrelated to this question. Regardless of > which code they do or do not merge into their repositories, it is the > existing set of nodes with the existing set of software that is the > question. > > Bitcoin Core may be a convenient landmark to point to as far as social > sympathies go, but the technical reality is that the decentralized nature of > the network means that existing full nodes and all existing wallet software > without auto-update cannot be changed by any technical means. So the only > sure way to prevent inadvertent opposite side spending from the existing > user base who do not update is through the implementation of strong 2 way > replay protection. > > Companies are already preparing for the reality of splitting. This is a > purely technical issue, an equal problem for both sides of the fork. > > If we knew with great certainty that the market for the one side of the fork > was so minimal that the issue was not worth considering, that would be a > fine practical argument against worrying about replay protection. As things > stand, businesses, users and futures markets do not reflect such a > certainty. > > On Sun, Oct 8, 2017 at 2:20 PM Jared Lee Richardson via Bitcoin-segwit2x > wrote: >> >> > As a result I'd expect to see a longer period of disruption / >> > inaccessibility than we saw with the BCH fork, and probably several orders >> > of magnitude greater instances of nontechnical users making mistakes to >> > their own detriment. >> >> Great, so either Core can compromise after 2 years of refusing, or >> Core should be adding strong two-way replay protection the fork that >> is rejecting overwhelming consensus. The window is probably passing >> for both sides to symmetrically fork as I proposed months ago. >> >> Either way, this project is taking the correct actions with the best >> chance of keeping the community together - Optional replay protection >> for those who care about the drama. >> >> Jared >> >> On Sun, Oct 8, 2017 at 1:40 PM, Jameson Lopp via Bitcoin-segwit2x >> wrote: >> > It seems clear to me that there is going to be a chain split, so the >> > question comes down to who is going to put in the effort to protect >> > users >> > from accidentally sending crypto assets that they had no intention of >> > sending. Without strong native two way replay protection at the protocol >> > level, the responsibility will fall upon every wallet and service >> > provider. >> > As a result I'd expect to see a longer period of disruption / >> > inaccessibility than we saw with the BCH fork, and probably several >> > orders >> > of magnitude greater instances of nontechnical users making mistakes to >> > their own detriment. >> > >> > I suspect that such a situation is destined to happen sooner or later >> > given >> > the permissionless nature of forks. The grand experiment must go on! >> > >> > On Sun, Oct 8, 2017 at 4:31 PM, Jacob Eliosoff via Bitcoin-segwit2x >> > wrote: >> >> >> >> Alex, this has of course been much discussed. My 2c: >> >> >> >> A lot of the replay debate comes down to, will the 2x chain accept txs >> >> sent post-split, by non-upgraded wallet software? As Mike said, >> >> there's >> >> strong consensus among Segwit2x folks that proposals which reject these >> >> txs >> >> (eg, the Bitcoin Cash approach) are a no-go, and a waste of time. >> >> >> >> That said - I and others would love to see good 2-way replay protection >> >> if >> >> it meets that backwards-compatibility constraint, and there are >> >> approaches >> >> that do: see eg >> >> https://github.com/btc1/bitcoin/issues/34#issuecomment-329251611. Yes, >> >> the >> >> two chains are competing for users, but there are still ways we could >> >> protect all users from unintended sends (which no one wants to happen) >> >> if >> >> we're civilized about it. Unfortunately these approaches are unlikely >> >> to >> >> happen without buy-in from Core (eg, to make the 1x chain reject txs >> >> explicitly specifying 2x, in exchange for vice versa). >> >> >> >> >> >> >> >> On Sun, Oct 8, 2017 at 4:16 PM, Mike Belshe via Bitcoin-segwit2x >> >> wrote: >> >>> >> >>> Alex - >> >>> >> >>> "Replay protection", as you call it, splits the chain. It simply >> >>> doesn't >> >>> make sense- you'd suddenly be breaking 10+million SPV clients that >> >>> otherwise >> >>> work just fine. It is a goal of segwit2x to help avoid this. >> >>> >> >>> Today, we're on course to deploy segwit2x with a vast majority of >> >>> miners >> >>> still signaling for it. On top of that, 99.94% of nodes & SPV clients >> >>> will >> >>> automatically follow that longest chain (segwit2x). >> >>> >> >>> I know some don't want Bitcoin to work this way, but this is the way >> >>> that >> >>> Bitcoin upgrades are implemented. >> >>> >> >>> Mike >> >>> >> >>> >> >>> On Sun, Oct 8, 2017 at 1:00 PM, Alex Bosworth via Bitcoin-segwit2x >> >>> wrote: >> >>>> >> >>>> In June of this year I asked about the provisions for strong 2-way >> >>>> replay protection. Strong 2-way replay protection means transactions >> >>>> valid on one chain should be invalid on the other, and vice-versa. I >> >>>> also asked about wipe-out protection, and that has since been >> >>>> implemented, which is great. >> >>>> >> >>>> I talked about the possibility of a contentious hard fork, where >> >>>> significant value persists across multiple chains. Support for the >> >>>> NYA >> >>>> hard fork is still lacking from Bitfinex, Local Bitcoins (the largest >> >>>> volume peer to peer exchange), Slush Pool, Trezor, Ledger, Electrum, >> >>>> and many others in the industry and individuals in the development >> >>>> and >> >>>> broader community. >> >>>> >> >>>> I know there has been some fervent hope that the contentious >> >>>> possibility of this hard fork would abate or become minimal in the >> >>>> remaining time, and that indeed was a laudable goal. But since June, >> >>>> contention has only risen. Instead of adding significant support to >> >>>> the agreement, important and longstanding Bitcoin companies such as >> >>>> BitWala, F2Pool, and others have pulled out of the New York Agreement >> >>>> that prompted this project. A number of signers have since decided to >> >>>> devote their energies to other currency projects, partially or in >> >>>> full. >> >>>> >> >>>> Early results from futures trading shows significant market demand >> >>>> for >> >>>> both sides of the fork. >> >>>> >> >>>> I can now say that preparations have begun in earnest to support both >> >>>> chains. The possibility of a contentious hard fork now looks like the >> >>>> probable future reality. Thus, this hard fork should provide strong >> >>>> 2-way replay protection. This means that transactions valid on one >> >>>> chain should be invalid on the other, and vice-versa. Without this >> >>>> protection, users would only be able to safely transact on the chains >> >>>> separately by using explicit splitting techniques, which puts >> >>>> excessive burden on the end user. >> >>>> >> >>>> I can restate suggestions from this list from Sergio Lerner and >> >>>> WuJihan who have pointed to encouraging multiple visions to coexist, >> >>>> potentially using a simple sighash modification that will fix the >> >>>> very >> >>>> simple technical problem that a valid signature authorizing a >> >>>> transaction of one currency should not be also used as a valid >> >>>> signature authorizing the transaction of another currency. >> >>>> >> >>>> Strong 2-way replay protection will help all businesses regardless of >> >>>> their position, and help regular users as well. I can quote from an >> >>>> industry statement regarding the previous contentious hard fork >> >>>> proposal BTU, which also proposed a hard fork coordinated around 3/4 >> >>>> hash power signaling: >> >>>> >> >>>> "However, none of the undersigned can list BTU unless we can run both >> >>>> chains independently without incident. Consequently, we insist that >> >>>> the Bitcoin Unlimited community (or any other consensus breaking >> >>>> implementation) build in strong two-way replay protection. Failure to >> >>>> do so will impede our ability to preserve BTU for customers and will >> >>>> either delay or outright preclude the listing of BTU." >> >>>> >> >>>> >> >>>> >> >>>> https://fs.bitcoinmagazine.com/assets/exchange_handling_of_contentious_hard_fork_event.pdf >> >>>> >> >>>> This quote specifically calls out "or any other consensus breaking >> >>>> implementation". The statement was signed by companies such as >> >>>> Bitstamp, Bitfinex, bitso, bitsquare, bittrex, btcc, btcchina, >> >>>> coinfloor, itbit, Kraken, QuadrigaCX, and ShapeShift. >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Sent from my iPhone >> >>>> _______________________________________________ >> >>>> Bitcoin-segwit2x mailing list >> >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> >> >>> Mike Belshe >> >>> CEO, BitGo, Inc >> >>> 408-718-6885 >> >>> >> >>> >> >>> _______________________________________________ >> >>> Bitcoin-segwit2x mailing list >> >>> Bitcoin-segwit2x at lists.linuxfoundation.org >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >>> >> >> >> >> >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> > >> > >> > _______________________________________________ >> > Bitcoin-segwit2x mailing list >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- > Sent from my iPhone From bitpico at icloud.com Sun Oct 8 21:54:01 2017 From: bitpico at icloud.com (bitPico) Date: Sun, 08 Oct 2017 17:54:01 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: <4639BFB5-B3CE-462A-AEA2-A667A8FF7760@icloud.com> What companies are not upgrading to 2x? We find no evidence that this is true and we work with most major Bitcoin companies and miners. Please share a list with references to each of their arguments. > > Companies are already preparing for the reality of splitting. > From segwit2x_mailinglist at bitcoinreminder.com Sun Oct 8 21:56:35 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Sun, 8 Oct 2017 23:56:35 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: <4639BFB5-B3CE-462A-AEA2-A667A8FF7760@icloud.com> References: <4639BFB5-B3CE-462A-AEA2-A667A8FF7760@icloud.com> Message-ID: <799786C2-65AF-40C0-B1AB-C1E0EAE585CE@bitcoinreminder.com> We at BitcoinReminder.com are preparing for the split and won?t accept B2X coins after the fork. This whole process here is a farce and we are for sure staying with the community - not with insane companies and individuals. > Am 08.10.2017 um 23:54 schrieb bitPico via Bitcoin-segwit2x : > > What companies are not upgrading to 2x? We find no evidence that this is true and we work with most major Bitcoin companies and miners. Please share a list with references to each of their arguments. > >> >> Companies are already preparing for the reality of splitting. >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Sun Oct 8 21:58:41 2017 From: bitpico at icloud.com (bitPico) Date: Sun, 08 Oct 2017 17:58:41 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: <799786C2-65AF-40C0-B1AB-C1E0EAE585CE@bitcoinreminder.com> References: <4639BFB5-B3CE-462A-AEA2-A667A8FF7760@icloud.com> <799786C2-65AF-40C0-B1AB-C1E0EAE585CE@bitcoinreminder.com> Message-ID: Since you are not upgrading you CAN unsubscribe from this list. > On Oct 8, 2017, at 5:56 PM, Peter BitcoinReminder.com wrote: > > This whole process here is a farce and we are for sure staying with the community - not with insane companies and individuals. From segwit2x_mailinglist at bitcoinreminder.com Sun Oct 8 22:01:32 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Mon, 9 Oct 2017 00:01:32 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <4639BFB5-B3CE-462A-AEA2-A667A8FF7760@icloud.com> <799786C2-65AF-40C0-B1AB-C1E0EAE585CE@bitcoinreminder.com> Message-ID: <17A06492-7C85-4D89-9514-53A8865EDE39@bitcoinreminder.com> My subscription to this list is based on our intent to keep our end customers safe and to ensure that their payments are working fine, so I try at least to mention here that there are many things going completely wrong with this project. > Am 08.10.2017 um 23:58 schrieb bitPico : > > Since you are not upgrading you CAN unsubscribe from this list. > >> On Oct 8, 2017, at 5:56 PM, Peter BitcoinReminder.com wrote: >> >> This whole process here is a farce and we are for sure staying with the community - not with insane companies and individuals. From pekatete at hotmail.com Sun Oct 8 22:12:48 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Sun, 8 Oct 2017 22:12:48 +0000 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection Message-ID: > As things stand, businesses, users and futures markets do not reflect such a certainty. It is important to include the entire ecosystem in determining certainty, but you fail to include the only relevant party when upgrading consensus rules, the miners. From verifiable data, there is statistical certainty that the legacy chain will not exist post HF or at best has a remote probability of being usable post upgrade. In-fact, implementing strong 2-way replay protection in the btc1 client would improve the statistical probability of the legacy chain surviving post upgrade and in contravention of the stated aims of the BTC1 WG. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Sun Oct 8 22:15:30 2017 From: bitpico at icloud.com (bitPico) Date: Sun, 08 Oct 2017 18:15:30 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: <17A06492-7C85-4D89-9514-53A8865EDE39@bitcoinreminder.com> References: <4639BFB5-B3CE-462A-AEA2-A667A8FF7760@icloud.com> <799786C2-65AF-40C0-B1AB-C1E0EAE585CE@bitcoinreminder.com> <17A06492-7C85-4D89-9514-53A8865EDE39@bitcoinreminder.com> Message-ID: If you want to ensure your customers are safe simply upgrade to the non-deprecated codebase; anything less is putting them at harm as ~95% miners are not going to keep using old outdated code. Staying on a minority or non-functional chain is the riskiest move to take on behalf of your customers from a blockchain security perspective. That said; if you do not upgrade to the non-outdated rules you will need to increase you confirmation wait times to at least 20 fold. > On Oct 8, 2017, at 6:01 PM, Peter BitcoinReminder.com via Bitcoin-segwit2x wrote: > > My subscription to this list is based on our intent to keep our end customers safe and to ensure that their payments are working fine From bitpico at icloud.com Sun Oct 8 22:23:44 2017 From: bitpico at icloud.com (bitPico) Date: Sun, 08 Oct 2017 18:23:44 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: <012BD06B-90E8-409F-86E7-3CA68D2BF635@icloud.com> Our mining data shows there will be no chance that the legacy 1x code continues to function whatsoever without specific changes (hacks) to the it. We estimate it will take the 1x chain several days to solve single block; 3 to be exact. You don?t need replay protection for a dead blockchain nor will this impact the upgraded nodes. > On Oct 8, 2017, at 6:12 PM, Phillip Katete via Bitcoin-segwit2x wrote: > > > > As things stand, businesses, users and futures markets do not reflect such a certainty. > > It is important to include the entire ecosystem in determining certainty, but you fail to include the only relevant party when upgrading consensus rules, the miners. From verifiable data, there is statistical certainty that the legacy chain will not exist post HF or at best has a remote probability of being usable post upgrade. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Sun Oct 8 22:46:30 2017 From: chris at suredbits.com (Chris Stewart) Date: Sun, 8 Oct 2017 17:46:30 -0500 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: So just to be clear, segwit2x no longer believes there will not be a chain split come November? -Chris On Sun, Oct 8, 2017 at 4:20 PM, Jared Lee Richardson via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > As a result I'd expect to see a longer period of disruption / > inaccessibility than we saw with the BCH fork, and probably several orders > of magnitude greater instances of nontechnical users making mistakes to > their own detriment. > > Great, so either Core can compromise after 2 years of refusing, or > Core should be adding strong two-way replay protection the fork that > is rejecting overwhelming consensus. The window is probably passing > for both sides to symmetrically fork as I proposed months ago. > > Either way, this project is taking the correct actions with the best > chance of keeping the community together - Optional replay protection > for those who care about the drama. > > Jared > > On Sun, Oct 8, 2017 at 1:40 PM, Jameson Lopp via Bitcoin-segwit2x > wrote: > > It seems clear to me that there is going to be a chain split, so the > > question comes down to who is going to put in the effort to protect users > > from accidentally sending crypto assets that they had no intention of > > sending. Without strong native two way replay protection at the protocol > > level, the responsibility will fall upon every wallet and service > provider. > > As a result I'd expect to see a longer period of disruption / > > inaccessibility than we saw with the BCH fork, and probably several > orders > > of magnitude greater instances of nontechnical users making mistakes to > > their own detriment. > > > > I suspect that such a situation is destined to happen sooner or later > given > > the permissionless nature of forks. The grand experiment must go on! > > > > On Sun, Oct 8, 2017 at 4:31 PM, Jacob Eliosoff via Bitcoin-segwit2x > > wrote: > >> > >> Alex, this has of course been much discussed. My 2c: > >> > >> A lot of the replay debate comes down to, will the 2x chain accept txs > >> sent post-split, by non-upgraded wallet software? As Mike said, there's > >> strong consensus among Segwit2x folks that proposals which reject these > txs > >> (eg, the Bitcoin Cash approach) are a no-go, and a waste of time. > >> > >> That said - I and others would love to see good 2-way replay protection > if > >> it meets that backwards-compatibility constraint, and there are > approaches > >> that do: see eg > >> https://github.com/btc1/bitcoin/issues/34#issuecomment-329251611. > Yes, the > >> two chains are competing for users, but there are still ways we could > >> protect all users from unintended sends (which no one wants to happen) > if > >> we're civilized about it. Unfortunately these approaches are unlikely > to > >> happen without buy-in from Core (eg, to make the 1x chain reject txs > >> explicitly specifying 2x, in exchange for vice versa). > >> > >> > >> > >> On Sun, Oct 8, 2017 at 4:16 PM, Mike Belshe via Bitcoin-segwit2x > >> wrote: > >>> > >>> Alex - > >>> > >>> "Replay protection", as you call it, splits the chain. It simply > doesn't > >>> make sense- you'd suddenly be breaking 10+million SPV clients that > otherwise > >>> work just fine. It is a goal of segwit2x to help avoid this. > >>> > >>> Today, we're on course to deploy segwit2x with a vast majority of > miners > >>> still signaling for it. On top of that, 99.94% of nodes & SPV clients > will > >>> automatically follow that longest chain (segwit2x). > >>> > >>> I know some don't want Bitcoin to work this way, but this is the way > that > >>> Bitcoin upgrades are implemented. > >>> > >>> Mike > >>> > >>> > >>> On Sun, Oct 8, 2017 at 1:00 PM, Alex Bosworth via Bitcoin-segwit2x > >>> wrote: > >>>> > >>>> In June of this year I asked about the provisions for strong 2-way > >>>> replay protection. Strong 2-way replay protection means transactions > >>>> valid on one chain should be invalid on the other, and vice-versa. I > >>>> also asked about wipe-out protection, and that has since been > >>>> implemented, which is great. > >>>> > >>>> I talked about the possibility of a contentious hard fork, where > >>>> significant value persists across multiple chains. Support for the NYA > >>>> hard fork is still lacking from Bitfinex, Local Bitcoins (the largest > >>>> volume peer to peer exchange), Slush Pool, Trezor, Ledger, Electrum, > >>>> and many others in the industry and individuals in the development and > >>>> broader community. > >>>> > >>>> I know there has been some fervent hope that the contentious > >>>> possibility of this hard fork would abate or become minimal in the > >>>> remaining time, and that indeed was a laudable goal. But since June, > >>>> contention has only risen. Instead of adding significant support to > >>>> the agreement, important and longstanding Bitcoin companies such as > >>>> BitWala, F2Pool, and others have pulled out of the New York Agreement > >>>> that prompted this project. A number of signers have since decided to > >>>> devote their energies to other currency projects, partially or in > >>>> full. > >>>> > >>>> Early results from futures trading shows significant market demand for > >>>> both sides of the fork. > >>>> > >>>> I can now say that preparations have begun in earnest to support both > >>>> chains. The possibility of a contentious hard fork now looks like the > >>>> probable future reality. Thus, this hard fork should provide strong > >>>> 2-way replay protection. This means that transactions valid on one > >>>> chain should be invalid on the other, and vice-versa. Without this > >>>> protection, users would only be able to safely transact on the chains > >>>> separately by using explicit splitting techniques, which puts > >>>> excessive burden on the end user. > >>>> > >>>> I can restate suggestions from this list from Sergio Lerner and > >>>> WuJihan who have pointed to encouraging multiple visions to coexist, > >>>> potentially using a simple sighash modification that will fix the very > >>>> simple technical problem that a valid signature authorizing a > >>>> transaction of one currency should not be also used as a valid > >>>> signature authorizing the transaction of another currency. > >>>> > >>>> Strong 2-way replay protection will help all businesses regardless of > >>>> their position, and help regular users as well. I can quote from an > >>>> industry statement regarding the previous contentious hard fork > >>>> proposal BTU, which also proposed a hard fork coordinated around 3/4 > >>>> hash power signaling: > >>>> > >>>> "However, none of the undersigned can list BTU unless we can run both > >>>> chains independently without incident. Consequently, we insist that > >>>> the Bitcoin Unlimited community (or any other consensus breaking > >>>> implementation) build in strong two-way replay protection. Failure to > >>>> do so will impede our ability to preserve BTU for customers and will > >>>> either delay or outright preclude the listing of BTU." > >>>> > >>>> > >>>> https://fs.bitcoinmagazine.com/assets/exchange_handling_ > of_contentious_hard_fork_event.pdf > >>>> > >>>> This quote specifically calls out "or any other consensus breaking > >>>> implementation". The statement was signed by companies such as > >>>> Bitstamp, Bitfinex, bitso, bitsquare, bittrex, btcc, btcchina, > >>>> coinfloor, itbit, Kraken, QuadrigaCX, and ShapeShift. > >>>> > >>>> > >>>> > >>>> -- > >>>> Sent from my iPhone > >>>> _______________________________________________ > >>>> Bitcoin-segwit2x mailing list > >>>> Bitcoin-segwit2x at lists.linuxfoundation.org > >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>> > >>> > >>> > >>> > >>> -- > >>> > >>> Mike Belshe > >>> CEO, BitGo, Inc > >>> 408-718-6885 > >>> > >>> > >>> _______________________________________________ > >>> Bitcoin-segwit2x mailing list > >>> Bitcoin-segwit2x at lists.linuxfoundation.org > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>> > >> > >> > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Sun Oct 8 22:57:00 2017 From: bitpico at icloud.com (bitPico) Date: Sun, 08 Oct 2017 18:57:00 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> https://blockchain.info/charts/nya-support ~95-96% Do the math on how long it would take to solve a 1x (deprecated) block with only 4-5% network hash power. There is no HACK in place to drop the difficulty either so it?s a dead blockchain. :-) > On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x wrote: > > So just to be clear, segwit2x no longer believes there will not be a chain split come November? > > -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameson.lopp at gmail.com Sun Oct 8 23:03:39 2017 From: jameson.lopp at gmail.com (Jameson Lopp) Date: Sun, 8 Oct 2017 19:03:39 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: It appears that some of you have managed to convince yourselves that you will be able to "force an upgrade" or "kill the existing chain." I don't expect to be able to convince you otherwise; history shall be the ultimate judge. On Sun, Oct 8, 2017 at 6:57 PM, bitPico via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > https://blockchain.info/charts/nya-support > > ~95-96% > > Do the math on how long it would take to solve a 1x (deprecated) block > with only 4-5% network hash power. > > There is no HACK in place to drop the difficulty either so it?s a dead > blockchain. :-) > > On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > So just to be clear, segwit2x no longer believes there will not be a chain > split come November? > > -Chris > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Mon Oct 9 00:56:31 2017 From: chris at suredbits.com (Chris Stewart) Date: Sun, 8 Oct 2017 19:56:31 -0500 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: So just so this is clear to the rest of the world, Segwit2x believes there will be no chain split? -Chris On Sun, Oct 8, 2017 at 5:57 PM, bitPico wrote: > https://blockchain.info/charts/nya-support > > ~95-96% > > Do the math on how long it would take to solve a 1x (deprecated) block > with only 4-5% network hash power. > > There is no HACK in place to drop the difficulty either so it?s a dead > blockchain. :-) > > On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > So just to be clear, segwit2x no longer believes there will not be a chain > split come November? > > -Chris > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emil at bitcoin.com Mon Oct 9 01:39:25 2017 From: emil at bitcoin.com (Emil Oldenburg) Date: Mon, 9 Oct 2017 10:39:25 +0900 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: Chain splits happens once in a while, we had a chain split three days ago, even though it didn't last as no miner built a block on top of the AntPool block since the cost of burying it deep enough to reach more than 100 confirmations so it can be sold, simply was too high. https://www.blocktrail.com/BTC/blocks/orphans/1 Post HF, we will get a chain split, and blocks will be mined on both chains. But the economic reality is that the non-upgraded legacy chain face a significant risk of getting orphaned/abandoned. What is a good definition of chain split? 1, 100, or 1000 blocks? Emil Oldenburg, CTO Emil at bitcoin.com Visit the all new https://bitcoin.com Wechat: emilold Telegram: emilold On 2017?10?09? 09:56, Chris Stewart via Bitcoin-segwit2x wrote: > So just so this is clear to the rest of the world, Segwit2x believes > there will be no chain split? > > -Chris > > On Sun, Oct 8, 2017 at 5:57 PM, bitPico > wrote: > > https://blockchain.info/charts/nya-support > > > ~95-96%? > > Do the math on how long it would take to solve a 1x (deprecated) > block with only 4-5% network hash power. > > There is no HACK in place to drop the difficulty either so it?s a > dead blockchain. :-) > >> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x >> > > wrote: >> >> So just to be clear, segwit2x no longer believes there will not >> be a chain split come November? >> >> -Chris > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Mon Oct 9 01:59:11 2017 From: chris at suredbits.com (Chris Stewart) Date: Sun, 8 Oct 2017 20:59:11 -0500 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: This is really alarming that you think this is how consensus protocols work. The legacy chain will never reorg to the new currency. The two consensus rule sets are incompatible. -Chris On Sun, Oct 8, 2017 at 8:39 PM, Emil Oldenburg via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Chain splits happens once in a while, we had a chain split three days ago, > even though it didn't last as no miner built a block on top of the AntPool > block since the cost of burying it deep enough to reach more than 100 > confirmations so it can be sold, simply was too high. > > https://www.blocktrail.com/BTC/blocks/orphans/1 > > Post HF, we will get a chain split, and blocks will be mined on both > chains. But the economic reality is that the non-upgraded legacy chain face > a significant risk of getting orphaned/abandoned. What is a good definition > of chain split? 1, 100, or 1000 blocks? > > > Emil Oldenburg, CTOEmil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > > On 2017?10?09? 09:56, Chris Stewart via Bitcoin-segwit2x wrote: > > So just so this is clear to the rest of the world, Segwit2x believes there > will be no chain split? > > -Chris > > On Sun, Oct 8, 2017 at 5:57 PM, bitPico wrote: > >> https://blockchain.info/charts/nya-support >> >> ~95-96% >> >> Do the math on how long it would take to solve a 1x (deprecated) block >> with only 4-5% network hash power. >> >> There is no HACK in place to drop the difficulty either so it?s a dead >> blockchain. :-) >> >> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> So just to be clear, segwit2x no longer believes there will not be a >> chain split come November? >> >> -Chris >> >> >> > > > _______________________________________________ > Bitcoin-segwit2x mailing listBitcoin-segwit2x at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emil at bitcoin.com Mon Oct 9 02:04:59 2017 From: emil at bitcoin.com (Emil Oldenburg) Date: Mon, 9 Oct 2017 11:04:59 +0900 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: I never said it will. Simply that the users will move to the upgraded chain and the legacy one will have neither blocks nor users after a short while. Emil Oldenburg, CTO Emil at bitcoin.com Visit the all new https://bitcoin.com Wechat: emilold Telegram: emilold On 2017?10?09? 10:59, Chris Stewart wrote: > This is really alarming that you think this is how consensus protocols > work. The legacy chain will never reorg to the new currency. The two > consensus rule sets are incompatible.? > > -Chris > > On Sun, Oct 8, 2017 at 8:39 PM, Emil Oldenburg via Bitcoin-segwit2x > > wrote: > > Chain splits happens once in a while, we had a chain split three > days ago, even though it didn't last as no miner built a block on > top of the AntPool block since the cost of burying it deep enough > to reach more than 100 confirmations so it can be sold, simply was > too high. > > https://www.blocktrail.com/BTC/blocks/orphans/1 > > > Post HF, we will get a chain split, and blocks will be mined on > both chains. But the economic reality is that the non-upgraded > legacy chain face a significant risk of getting > orphaned/abandoned. What is a good definition of chain split? 1, > 100, or 1000 blocks? > > > Emil Oldenburg, CTO > Emil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > > On 2017?10?09? 09:56, Chris Stewart via Bitcoin-segwit2x wrote: >> So just so this is clear to the rest of the world, Segwit2x >> believes there will be no chain split? >> >> -Chris >> >> On Sun, Oct 8, 2017 at 5:57 PM, bitPico > > wrote: >> >> https://blockchain.info/charts/nya-support >> >> >> ~95-96%? >> >> Do the math on how long it would take to solve a 1x >> (deprecated) block with only 4-5% network hash power. >> >> There is no HACK in place to drop the difficulty either so >> it?s a dead blockchain. :-) >> >>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via >>> Bitcoin-segwit2x >> > wrote: >>> >>> So just to be clear, segwit2x no longer believes there will >>> not be a chain split come November? >>> >>> -Chris >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Mon Oct 9 02:43:02 2017 From: chris at suredbits.com (Chris Stewart) Date: Sun, 8 Oct 2017 21:43:02 -0500 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: You cannot make assumptions about what users will do (unless you are assuming that the business they are using coerced them onto a specific chain). Also the word 'upgraded' is very subjective. I consider upgrades to be the Peter Thiel flavor of "0 to 1" (legitimate new technology) not the "1 to N" that hard forking a block size increase does. -Chris On Oct 8, 2017 9:05 PM, "Emil Oldenburg" wrote: I never said it will. Simply that the users will move to the upgraded chain and the legacy one will have neither blocks nor users after a short while. Emil Oldenburg, CTOEmil at bitcoin.com Visit the all new https://bitcoin.com Wechat: emilold Telegram: emilold On 2017?10?09? 10:59, Chris Stewart wrote: This is really alarming that you think this is how consensus protocols work. The legacy chain will never reorg to the new currency. The two consensus rule sets are incompatible. -Chris On Sun, Oct 8, 2017 at 8:39 PM, Emil Oldenburg via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Chain splits happens once in a while, we had a chain split three days ago, > even though it didn't last as no miner built a block on top of the AntPool > block since the cost of burying it deep enough to reach more than 100 > confirmations so it can be sold, simply was too high. > > https://www.blocktrail.com/BTC/blocks/orphans/1 > > Post HF, we will get a chain split, and blocks will be mined on both > chains. But the economic reality is that the non-upgraded legacy chain face > a significant risk of getting orphaned/abandoned. What is a good definition > of chain split? 1, 100, or 1000 blocks? > > > Emil Oldenburg, CTOEmil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > > On 2017?10?09? 09:56, Chris Stewart via Bitcoin-segwit2x wrote: > > So just so this is clear to the rest of the world, Segwit2x believes there > will be no chain split? > > -Chris > > On Sun, Oct 8, 2017 at 5:57 PM, bitPico wrote: > >> https://blockchain.info/charts/nya-support >> >> ~95-96% >> >> Do the math on how long it would take to solve a 1x (deprecated) block >> with only 4-5% network hash power. >> >> There is no HACK in place to drop the difficulty either so it?s a dead >> blockchain. :-) >> >> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> So just to be clear, segwit2x no longer believes there will not be a >> chain split come November? >> >> -Chris >> >> >> > > > _______________________________________________ > Bitcoin-segwit2x mailing listBitcoin-segwit2x at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Mon Oct 9 03:02:01 2017 From: chris at suredbits.com (Chris Stewart) Date: Sun, 8 Oct 2017 22:02:01 -0500 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: <1529390F-BE49-40B8-AD7E-6769AEC7B4FF@gmail.com> References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> <1529390F-BE49-40B8-AD7E-6769AEC7B4FF@gmail.com> Message-ID: So again -- just to be crystal clear -- consumer facing companies that signed the segwit2x agreement should offer their customers this choice between the two chains? -Chris On Oct 8, 2017 9:55 PM, "digitsu" wrote: > It doesn?t require any assumptions. Users (who tend to care about the > transaction validity and reliability of their chain) will move. Those that > don?t move will stay because they value their principles or idealogy more > than functionality or security of their chain. Everyone will get what they > want (to pay for). > > There is no coercion required. > > > On Oct 9, 2017, at 11:43, Chris Stewart via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > You cannot make assumptions about what users will do (unless you are > assuming that the business they are using coerced them onto a specific > chain). > > Also the word 'upgraded' is very subjective. I consider upgrades to be the > Peter Thiel flavor of "0 to 1" (legitimate new technology) not the "1 to > N" that hard forking a block size increase does. > > -Chris > On Oct 8, 2017 9:05 PM, "Emil Oldenburg" wrote: > > I never said it will. Simply that the users will move to the upgraded > chain and the legacy one will have neither blocks nor users after a short > while. > > > Emil Oldenburg, CTOEmil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > > On 2017?10?09? 10:59, Chris Stewart wrote: > > This is really alarming that you think this is how consensus protocols > work. The legacy chain will never reorg to the new currency. The two > consensus rule sets are incompatible. > > -Chris > > On Sun, Oct 8, 2017 at 8:39 PM, Emil Oldenburg via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Chain splits happens once in a while, we had a chain split three days >> ago, even though it didn't last as no miner built a block on top of the >> AntPool block since the cost of burying it deep enough to reach more than >> 100 confirmations so it can be sold, simply was too high. >> >> https://www.blocktrail.com/BTC/blocks/orphans/1 >> >> Post HF, we will get a chain split, and blocks will be mined on both >> chains. But the economic reality is that the non-upgraded legacy chain face >> a significant risk of getting orphaned/abandoned. What is a good definition >> of chain split? 1, 100, or 1000 blocks? >> >> >> Emil Oldenburg, CTOEmil at bitcoin.com >> Visit the all new https://bitcoin.com >> Wechat: emilold >> Telegram: emilold >> >> On 2017?10?09? 09:56, Chris Stewart via Bitcoin-segwit2x wrote: >> >> So just so this is clear to the rest of the world, Segwit2x believes >> there will be no chain split? >> >> -Chris >> >> On Sun, Oct 8, 2017 at 5:57 PM, bitPico wrote: >> >>> https://blockchain.info/charts/nya-support >>> >>> ~95-96% >>> >>> Do the math on how long it would take to solve a 1x (deprecated) block >>> with only 4-5% network hash power. >>> >>> There is no HACK in place to drop the difficulty either so it?s a dead >>> blockchain. :-) >>> >>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>> So just to be clear, segwit2x no longer believes there will not be a >>> chain split come November? >>> >>> -Chris >>> >>> >>> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing listBitcoin-segwit2x at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Mon Oct 9 03:26:18 2017 From: chris at suredbits.com (Chris Stewart) Date: Sun, 8 Oct 2017 22:26:18 -0500 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> <1529390F-BE49-40B8-AD7E-6769AEC7B4FF@gmail.com> Message-ID: It seems to me if bitcoin forks the consumer facing companies would be responsible for crediting users with balances on both chains. The word 'framing' makes me think of subjective marketing terms -- this is the interesting thing about bitcoin -- we are dealing with a bearer asset that *technically* can be forked by *anybody*. >they can simply tell their customers that this is the upgrade path that they will be taking, and if they don?t agree with it, then they should remove their funds or cease to use their service Again, I disagree about the word 'upgrade' in this context -- see my Peter Thiel comment -- but otherwise this seems prudent if you are diverging from consensus, but do you think there is enough time left until the hard fork to actually do this in a responsible manner? A lot of people don't follow bitcoin news on a daily basis like both of us do. -Chris On Sun, Oct 8, 2017 at 10:05 PM, Jerry D Chan wrote: > They *could*, if they were framing the fork as an optional new > transactional network option. But if they are framing it as an *upgrade* > to the existing one, they can simply tell their customers that this is the > upgrade path that they will be taking, and if they don?t agree with it, > then they should remove their funds or cease to use their service. There > is no way to ?ask? your customers that can?t be simply sybil attacked by > those who will pay for social media noise. > > > Jerry D Chan > President and Founder > Bittoku G.K. > jerry.d.chan at bittoku.co.jp > www.bittoku.co.jp > > > > On Oct 9, 2017, at 12:02, Chris Stewart via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > So again -- just to be crystal clear -- consumer facing companies that > signed the segwit2x agreement should offer their customers this choice > between the two chains? > > -Chris > > On Oct 8, 2017 9:55 PM, "digitsu" wrote: > >> It doesn?t require any assumptions. Users (who tend to care about the >> transaction validity and reliability of their chain) will move. Those that >> don?t move will stay because they value their principles or idealogy more >> than functionality or security of their chain. Everyone will get what they >> want (to pay for). >> >> There is no coercion required. >> >> >> On Oct 9, 2017, at 11:43, Chris Stewart via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> You cannot make assumptions about what users will do (unless you are >> assuming that the business they are using coerced them onto a specific >> chain). >> >> Also the word 'upgraded' is very subjective. I consider upgrades to be >> the Peter Thiel flavor of "0 to 1" (legitimate new technology) not the "1 >> to N" that hard forking a block size increase does. >> >> -Chris >> On Oct 8, 2017 9:05 PM, "Emil Oldenburg" wrote: >> >> I never said it will. Simply that the users will move to the upgraded >> chain and the legacy one will have neither blocks nor users after a short >> while. >> >> >> Emil Oldenburg, CTOEmil at bitcoin.com >> Visit the all new https://bitcoin.com >> Wechat: emilold >> Telegram: emilold >> >> On 2017?10?09? 10:59, Chris Stewart wrote: >> >> This is really alarming that you think this is how consensus protocols >> work. The legacy chain will never reorg to the new currency. The two >> consensus rule sets are incompatible. >> >> -Chris >> >> On Sun, Oct 8, 2017 at 8:39 PM, Emil Oldenburg via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> Chain splits happens once in a while, we had a chain split three days >>> ago, even though it didn't last as no miner built a block on top of the >>> AntPool block since the cost of burying it deep enough to reach more than >>> 100 confirmations so it can be sold, simply was too high. >>> >>> https://www.blocktrail.com/BTC/blocks/orphans/1 >>> >>> Post HF, we will get a chain split, and blocks will be mined on both >>> chains. But the economic reality is that the non-upgraded legacy chain face >>> a significant risk of getting orphaned/abandoned. What is a good definition >>> of chain split? 1, 100, or 1000 blocks? >>> >>> >>> Emil Oldenburg, CTOEmil at bitcoin.com >>> Visit the all new https://bitcoin.com >>> Wechat: emilold >>> Telegram: emilold >>> >>> On 2017?10?09? 09:56, Chris Stewart via Bitcoin-segwit2x wrote: >>> >>> So just so this is clear to the rest of the world, Segwit2x believes >>> there will be no chain split? >>> >>> -Chris >>> >>> On Sun, Oct 8, 2017 at 5:57 PM, bitPico wrote: >>> >>>> https://blockchain.info/charts/nya-support >>>> >>>> ~95-96% >>>> >>>> Do the math on how long it would take to solve a 1x (deprecated) block >>>> with only 4-5% network hash power. >>>> >>>> There is no HACK in place to drop the difficulty either so it?s a dead >>>> blockchain. :-) >>>> >>>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>> So just to be clear, segwit2x no longer believes there will not be a >>>> chain split come November? >>>> >>>> -Chris >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing listBitcoin-segwit2x at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-08-10 at 2.19.56.png Type: image/png Size: 8427 bytes Desc: not available URL: From mike at bitgo.com Mon Oct 9 03:38:56 2017 From: mike at bitgo.com (Mike Belshe) Date: Sun, 8 Oct 2017 20:38:56 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: On Sun, Oct 8, 2017 at 5:56 PM, Chris Stewart via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > So just so this is clear to the rest of the world, Segwit2x believes there > will be no chain split? > No. Although the design goal was to not create a split, that doesn't mean that there won't be one. Since you can never get 100.000% agreement, I suppose you could say that means there must be a split - the question is just how big. >From the beginning, the segwit2x crew tried to garner as much support as possible and make the code as simple and unobtrusive as possible. They certainly accomplished a lot - getting more miner support than ever in history, and getting segwit itself activated. With regard to the 2MB upgrade, it does seem that many are against it. But if you look at the node counts of SPV and full nodes, its easy to see that this group is incredibly small - likely 0.5% or less of all deployed wallets. On the other hand, adding "replay protection" and orphaning the SPV wallets would clearly create a massive chain split. Mike > > -Chris > > On Sun, Oct 8, 2017 at 5:57 PM, bitPico wrote: > >> https://blockchain.info/charts/nya-support >> >> ~95-96% >> >> Do the math on how long it would take to solve a 1x (deprecated) block >> with only 4-5% network hash power. >> >> There is no HACK in place to drop the difficulty either so it?s a dead >> blockchain. :-) >> >> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> So just to be clear, segwit2x no longer believes there will not be a >> chain split come November? >> >> -Chris >> >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- *Mike Belshe* *CEO, BitGo, Inc*408-718-6885 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Mon Oct 9 03:43:06 2017 From: chris at suredbits.com (Chris Stewart) Date: Sun, 8 Oct 2017 22:43:06 -0500 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: >No. Ok. Thanks for the candid answer Mike. I look forward to an official update from bitgo of how they will handle this chain split wrt to bitcoin and segwit2x. -Chris On Sun, Oct 8, 2017 at 10:38 PM, Mike Belshe wrote: > > > On Sun, Oct 8, 2017 at 5:56 PM, Chris Stewart via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> So just so this is clear to the rest of the world, Segwit2x believes >> there will be no chain split? >> > > No. > > Although the design goal was to not create a split, that doesn't mean that > there won't be one. Since you can never get 100.000% agreement, I suppose > you could say that means there must be a split - the question is just how > big. > > From the beginning, the segwit2x crew tried to garner as much support as > possible and make the code as simple and unobtrusive as possible. They > certainly accomplished a lot - getting more miner support than ever in > history, and getting segwit itself activated. With regard to the 2MB > upgrade, it does seem that many are against it. But if you look at the > node counts of SPV and full nodes, its easy to see that this group is > incredibly small - likely 0.5% or less of all deployed wallets. > > On the other hand, adding "replay protection" and orphaning the SPV > wallets would clearly create a massive chain split. > > Mike > > > > > >> >> -Chris >> >> On Sun, Oct 8, 2017 at 5:57 PM, bitPico wrote: >> >>> https://blockchain.info/charts/nya-support >>> >>> ~95-96% >>> >>> Do the math on how long it would take to solve a 1x (deprecated) block >>> with only 4-5% network hash power. >>> >>> There is no HACK in place to drop the difficulty either so it?s a dead >>> blockchain. :-) >>> >>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>> So just to be clear, segwit2x no longer believes there will not be a >>> chain split come November? >>> >>> -Chris >>> >>> >>> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > > -- > > > *Mike Belshe* > *CEO, BitGo, Inc*408-718-6885 <(408)%20718-6885> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry.d.chan at bittoku.co.jp Mon Oct 9 02:55:42 2017 From: jerry.d.chan at bittoku.co.jp (digitsu) Date: Mon, 9 Oct 2017 11:55:42 +0900 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: <1529390F-BE49-40B8-AD7E-6769AEC7B4FF@gmail.com> It doesn?t require any assumptions. Users (who tend to care about the transaction validity and reliability of their chain) will move. Those that don?t move will stay because they value their principles or idealogy more than functionality or security of their chain. Everyone will get what they want (to pay for). There is no coercion required. > On Oct 9, 2017, at 11:43, Chris Stewart via Bitcoin-segwit2x wrote: > > You cannot make assumptions about what users will do (unless you are assuming that the business they are using coerced them onto a specific chain). > > Also the word 'upgraded' is very subjective. I consider upgrades to be the Peter Thiel flavor of "0 to 1" (legitimate new technology) not the "1 to N" that hard forking a block size increase does. > > -Chris > On Oct 8, 2017 9:05 PM, "Emil Oldenburg" > wrote: > I never said it will. Simply that the users will move to the upgraded chain and the legacy one will have neither blocks nor users after a short while. > > Emil Oldenburg, CTO > Emil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > On 2017?10?09? 10:59, Chris Stewart wrote: >> This is really alarming that you think this is how consensus protocols work. The legacy chain will never reorg to the new currency. The two consensus rule sets are incompatible. >> >> -Chris >> >> On Sun, Oct 8, 2017 at 8:39 PM, Emil Oldenburg via Bitcoin-segwit2x > wrote: >> Chain splits happens once in a while, we had a chain split three days ago, even though it didn't last as no miner built a block on top of the AntPool block since the cost of burying it deep enough to reach more than 100 confirmations so it can be sold, simply was too high. >> >> https://www.blocktrail.com/BTC/blocks/orphans/1 >> Post HF, we will get a chain split, and blocks will be mined on both chains. But the economic reality is that the non-upgraded legacy chain face a significant risk of getting orphaned/abandoned. What is a good definition of chain split? 1, 100, or 1000 blocks? >> >> Emil Oldenburg, CTO >> Emil at bitcoin.com >> Visit the all new https://bitcoin.com >> Wechat: emilold >> Telegram: emilold >> On 2017?10?09? 09:56, Chris Stewart via Bitcoin-segwit2x wrote: >>> So just so this is clear to the rest of the world, Segwit2x believes there will be no chain split? >>> >>> -Chris >>> >>> On Sun, Oct 8, 2017 at 5:57 PM, bitPico > wrote: >>> https://blockchain.info/charts/nya-support >>> >>> ~95-96% >>> >>> Do the math on how long it would take to solve a 1x (deprecated) block with only 4-5% network hash power. >>> >>> There is no HACK in place to drop the difficulty either so it?s a dead blockchain. :-) >>> >>>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x > wrote: >>>> >>>> So just to be clear, segwit2x no longer believes there will not be a chain split come November? >>>> >>>> -Chris >>> >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From jerry.d.chan at bittoku.co.jp Mon Oct 9 03:05:49 2017 From: jerry.d.chan at bittoku.co.jp (Jerry D Chan) Date: Mon, 9 Oct 2017 12:05:49 +0900 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> <1529390F-BE49-40B8-AD7E-6769AEC7B4FF@gmail.com> Message-ID: They *could*, if they were framing the fork as an optional new transactional network option. But if they are framing it as an *upgrade* to the existing one, they can simply tell their customers that this is the upgrade path that they will be taking, and if they don?t agree with it, then they should remove their funds or cease to use their service. There is no way to ?ask? your customers that can?t be simply sybil attacked by those who will pay for social media noise. Jerry D Chan President and Founder Bittoku G.K. jerry.d.chan at bittoku.co.jp www.bittoku.co.jp > On Oct 9, 2017, at 12:02, Chris Stewart via Bitcoin-segwit2x wrote: > > So again -- just to be crystal clear -- consumer facing companies that signed the segwit2x agreement should offer their customers this choice between the two chains? > > -Chris > > On Oct 8, 2017 9:55 PM, "digitsu" > wrote: > It doesn?t require any assumptions. Users (who tend to care about the transaction validity and reliability of their chain) will move. Those that don?t move will stay because they value their principles or idealogy more than functionality or security of their chain. Everyone will get what they want (to pay for). > > There is no coercion required. > > >> On Oct 9, 2017, at 11:43, Chris Stewart via Bitcoin-segwit2x > wrote: >> >> You cannot make assumptions about what users will do (unless you are assuming that the business they are using coerced them onto a specific chain). >> >> Also the word 'upgraded' is very subjective. I consider upgrades to be the Peter Thiel flavor of "0 to 1" (legitimate new technology) not the "1 to N" that hard forking a block size increase does. >> >> -Chris >> On Oct 8, 2017 9:05 PM, "Emil Oldenburg" > wrote: >> I never said it will. Simply that the users will move to the upgraded chain and the legacy one will have neither blocks nor users after a short while. >> >> Emil Oldenburg, CTO >> Emil at bitcoin.com >> Visit the all new https://bitcoin.com >> Wechat: emilold >> Telegram: emilold >> On 2017?10?09? 10:59, Chris Stewart wrote: >>> This is really alarming that you think this is how consensus protocols work. The legacy chain will never reorg to the new currency. The two consensus rule sets are incompatible. >>> >>> -Chris >>> >>> On Sun, Oct 8, 2017 at 8:39 PM, Emil Oldenburg via Bitcoin-segwit2x > wrote: >>> Chain splits happens once in a while, we had a chain split three days ago, even though it didn't last as no miner built a block on top of the AntPool block since the cost of burying it deep enough to reach more than 100 confirmations so it can be sold, simply was too high. >>> >>> https://www.blocktrail.com/BTC/blocks/orphans/1 >>> Post HF, we will get a chain split, and blocks will be mined on both chains. But the economic reality is that the non-upgraded legacy chain face a significant risk of getting orphaned/abandoned. What is a good definition of chain split? 1, 100, or 1000 blocks? >>> >>> Emil Oldenburg, CTO >>> Emil at bitcoin.com >>> Visit the all new https://bitcoin.com >>> Wechat: emilold >>> Telegram: emilold >>> On 2017?10?09? 09:56, Chris Stewart via Bitcoin-segwit2x wrote: >>>> So just so this is clear to the rest of the world, Segwit2x believes there will be no chain split? >>>> >>>> -Chris >>>> >>>> On Sun, Oct 8, 2017 at 5:57 PM, bitPico > wrote: >>>> https://blockchain.info/charts/nya-support >>>> >>>> ~95-96% >>>> >>>> Do the math on how long it would take to solve a 1x (deprecated) block with only 4-5% network hash power. >>>> >>>> There is no HACK in place to drop the difficulty either so it?s a dead blockchain. :-) >>>> >>>>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x > wrote: >>>>> >>>>> So just to be clear, segwit2x no longer believes there will not be a chain split come November? >>>>> >>>>> -Chris >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-08-10 at 2.19.56.png Type: image/png Size: 8427 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From jerry.d.chan at bittoku.co.jp Mon Oct 9 03:41:45 2017 From: jerry.d.chan at bittoku.co.jp (Jerry D Chan) Date: Mon, 9 Oct 2017 12:41:45 +0900 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> <1529390F-BE49-40B8-AD7E-6769AEC7B4FF@gmail.com> Message-ID: <75497358-A9DF-4987-850A-E3EA7E711E8D@bittoku.co.jp> There is no marketing involved. Let?s keep the discussion technical, there is no reason to start debating phrasing or semantics here, I should think you know very well what I mean when I said ?framing?. Its a business, they can choose what kind of service they can provide their customers. If they were a business that was run properly, then they would have stated in their T&C that they would only offer access to the bitcoin ledger of which they have the sole right to determine which one it is. Most of the time this will be what everyone else agrees it is, but in times of a fork, the only thing that the business can guarantee that they will have control over their version of the ledger. Unless a company has explicitly stated that they will support any and all ledger forks that persist past a certain time, this should not be assumed to be the default behaviour, ?ethical?, ?moral obligation? or otherwise. Bitcoin is a new paradigm. Users who put their money into it thinking that it is just ?digital gold? and services just ?banks? should be dissuaded from believing this oversimplification, for exactly the situations such as the one we find ourselves in now. Jerry D Chan President and Founder Bittoku G.K. jerry.d.chan at bittoku.co.jp www.bittoku.co.jp > On Oct 9, 2017, at 12:26, Chris Stewart wrote: > > It seems to me if bitcoin forks the consumer facing companies would be responsible for crediting users with balances on both chains. The word 'framing' makes me think of subjective marketing terms -- this is the interesting thing about bitcoin -- we are dealing with a bearer asset that *technically* can be forked by *anybody*. > > >they can simply tell their customers that this is the upgrade path that they will be taking, and if they don?t agree with it, then they should remove their funds or cease to use their service > > Again, I disagree about the word 'upgrade' in this context -- see my Peter Thiel comment -- but otherwise this seems prudent if you are diverging from consensus, but do you think there is enough time left until the hard fork to actually do this in a responsible manner? A lot of people don't follow bitcoin news on a daily basis like both of us do. > > -Chris > > On Sun, Oct 8, 2017 at 10:05 PM, Jerry D Chan > wrote: > They *could*, if they were framing the fork as an optional new transactional network option. But if they are framing it as an *upgrade* to the existing one, they can simply tell their customers that this is the upgrade path that they will be taking, and if they don?t agree with it, then they should remove their funds or cease to use their service. There is no way to ?ask? your customers that can?t be simply sybil attacked by those who will pay for social media noise. > > > Jerry D Chan > President and Founder > Bittoku G.K. > jerry.d.chan at bittoku.co.jp > www.bittoku.co.jp > > > > >> On Oct 9, 2017, at 12:02, Chris Stewart via Bitcoin-segwit2x > wrote: >> >> So again -- just to be crystal clear -- consumer facing companies that signed the segwit2x agreement should offer their customers this choice between the two chains? >> >> -Chris >> >> On Oct 8, 2017 9:55 PM, "digitsu" > wrote: >> It doesn?t require any assumptions. Users (who tend to care about the transaction validity and reliability of their chain) will move. Those that don?t move will stay because they value their principles or idealogy more than functionality or security of their chain. Everyone will get what they want (to pay for). >> >> There is no coercion required. >> >> >>> On Oct 9, 2017, at 11:43, Chris Stewart via Bitcoin-segwit2x > wrote: >>> >>> You cannot make assumptions about what users will do (unless you are assuming that the business they are using coerced them onto a specific chain). >>> >>> Also the word 'upgraded' is very subjective. I consider upgrades to be the Peter Thiel flavor of "0 to 1" (legitimate new technology) not the "1 to N" that hard forking a block size increase does. >>> >>> -Chris >>> On Oct 8, 2017 9:05 PM, "Emil Oldenburg" > wrote: >>> I never said it will. Simply that the users will move to the upgraded chain and the legacy one will have neither blocks nor users after a short while. >>> >>> >>> >>> Emil Oldenburg, CTO >>> Emil at bitcoin.com >>> Visit the all new https://bitcoin.com >>> Wechat: emilold >>> Telegram: emilold >>> On 2017?10?09? 10:59, Chris Stewart wrote: >>>> This is really alarming that you think this is how consensus protocols work. The legacy chain will never reorg to the new currency. The two consensus rule sets are incompatible. >>>> >>>> -Chris >>>> >>>> On Sun, Oct 8, 2017 at 8:39 PM, Emil Oldenburg via Bitcoin-segwit2x > wrote: >>>> Chain splits happens once in a while, we had a chain split three days ago, even though it didn't last as no miner built a block on top of the AntPool block since the cost of burying it deep enough to reach more than 100 confirmations so it can be sold, simply was too high. >>>> >>>> https://www.blocktrail.com/BTC/blocks/orphans/1 >>>> Post HF, we will get a chain split, and blocks will be mined on both chains. But the economic reality is that the non-upgraded legacy chain face a significant risk of getting orphaned/abandoned. What is a good definition of chain split? 1, 100, or 1000 blocks? >>>> >>>> >>>> >>>> Emil Oldenburg, CTO >>>> Emil at bitcoin.com >>>> Visit the all new https://bitcoin.com >>>> Wechat: emilold >>>> Telegram: emilold >>>> On 2017?10?09? 09:56, Chris Stewart via Bitcoin-segwit2x wrote: >>>>> So just so this is clear to the rest of the world, Segwit2x believes there will be no chain split? >>>>> >>>>> -Chris >>>>> >>>>> On Sun, Oct 8, 2017 at 5:57 PM, bitPico > wrote: >>>>> https://blockchain.info/charts/nya-support >>>>> >>>>> ~95-96% >>>>> >>>>> Do the math on how long it would take to solve a 1x (deprecated) block with only 4-5% network hash power. >>>>> >>>>> There is no HACK in place to drop the difficulty either so it?s a dead blockchain. :-) >>>>> >>>>>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x > wrote: >>>>>> >>>>>> So just to be clear, segwit2x no longer believes there will not be a chain split come November? >>>>>> >>>>>> -Chris >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-08-10 at 2.19.56.png Type: image/png Size: 8427 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From mike at bitgo.com Mon Oct 9 03:46:03 2017 From: mike at bitgo.com (Mike Belshe) Date: Sun, 8 Oct 2017 20:46:03 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: BitGo serves its customers; we'll handle both chains. I still hope everyone decides to vote for bigger blocks - its taken a long time to get here, and we have a great opportunity! No reason to support two chains except pride. Mike On Sun, Oct 8, 2017 at 8:43 PM, Chris Stewart wrote: > >No. > > Ok. Thanks for the candid answer Mike. I look forward to an official > update from bitgo of how they will handle this chain split wrt to bitcoin > and segwit2x. > > -Chris > > On Sun, Oct 8, 2017 at 10:38 PM, Mike Belshe wrote: > >> >> >> On Sun, Oct 8, 2017 at 5:56 PM, Chris Stewart via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> So just so this is clear to the rest of the world, Segwit2x believes >>> there will be no chain split? >>> >> >> No. >> >> Although the design goal was to not create a split, that doesn't mean >> that there won't be one. Since you can never get 100.000% agreement, I >> suppose you could say that means there must be a split - the question is >> just how big. >> >> From the beginning, the segwit2x crew tried to garner as much support as >> possible and make the code as simple and unobtrusive as possible. They >> certainly accomplished a lot - getting more miner support than ever in >> history, and getting segwit itself activated. With regard to the 2MB >> upgrade, it does seem that many are against it. But if you look at the >> node counts of SPV and full nodes, its easy to see that this group is >> incredibly small - likely 0.5% or less of all deployed wallets. >> >> On the other hand, adding "replay protection" and orphaning the SPV >> wallets would clearly create a massive chain split. >> >> Mike >> >> >> >> >> >>> >>> -Chris >>> >>> On Sun, Oct 8, 2017 at 5:57 PM, bitPico wrote: >>> >>>> https://blockchain.info/charts/nya-support >>>> >>>> ~95-96% >>>> >>>> Do the math on how long it would take to solve a 1x (deprecated) block >>>> with only 4-5% network hash power. >>>> >>>> There is no HACK in place to drop the difficulty either so it?s a dead >>>> blockchain. :-) >>>> >>>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>> So just to be clear, segwit2x no longer believes there will not be a >>>> chain split come November? >>>> >>>> -Chris >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> >> >> -- >> >> >> *Mike Belshe* >> *CEO, BitGo, Inc*408-718-6885 <(408)%20718-6885> >> > > -- *Mike Belshe* *CEO, BitGo, Inc*408-718-6885 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel at jamin.net Mon Oct 9 08:46:33 2017 From: marcel at jamin.net (Marcel Jamin) Date: Mon, 9 Oct 2017 10:46:33 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: On 9 October 2017 at 05:46, Mike Belshe via Bitcoin-segwit2x wrote: > BitGo serves its customers; we'll handle both chains. > I still hope everyone decides to vote for bigger blocks - its taken a long > time to get here, and we have a great opportunity! The block limit effectively doubled recently. You say that's because of the NYA, others say it's because of the UASF ultimatum. Personally I believe the pro-hardfork side saw a chance to get their pound of flesh with the NYA and BIP91 caught them by surprise. But the UASF deadline provided the pressure. In any case, it already doubled and you want to double it *again*. > No reason to support two chains except pride. The new chain will be run by a forked off client maintained by a new and much smaller set of developers willing to give in to business (and presumably government) pressure. The original chain will keep the most if not all of the developer talent that helped bitcoin flourish over the past years and follow a more rational and less political approach to decision making. I see plenty of reason to support the original chain and can't fathom how anyone (except some CEOs perhaps) would value the former higher than the latter. Early results on Bitfinex tend to agree with me here. This valuation will be an issue for you and the mining support you currently think you have. Understand that hashpower is a value add, not the core value proposition. Even with 1000x the hashpower, there's nothing secure about a corporately run version of bitcoin. - Marcel > > Mike > > > On Sun, Oct 8, 2017 at 8:43 PM, Chris Stewart wrote: >> >> >No. >> >> Ok. Thanks for the candid answer Mike. I look forward to an official >> update from bitgo of how they will handle this chain split wrt to bitcoin >> and segwit2x. >> >> -Chris >> >> On Sun, Oct 8, 2017 at 10:38 PM, Mike Belshe wrote: >>> >>> >>> >>> On Sun, Oct 8, 2017 at 5:56 PM, Chris Stewart via Bitcoin-segwit2x >>> wrote: >>>> >>>> So just so this is clear to the rest of the world, Segwit2x believes >>>> there will be no chain split? >>> >>> >>> No. >>> >>> Although the design goal was to not create a split, that doesn't mean >>> that there won't be one. Since you can never get 100.000% agreement, I >>> suppose you could say that means there must be a split - the question is >>> just how big. >>> >>> From the beginning, the segwit2x crew tried to garner as much support as >>> possible and make the code as simple and unobtrusive as possible. They >>> certainly accomplished a lot - getting more miner support than ever in >>> history, and getting segwit itself activated. With regard to the 2MB >>> upgrade, it does seem that many are against it. But if you look at the node >>> counts of SPV and full nodes, its easy to see that this group is incredibly >>> small - likely 0.5% or less of all deployed wallets. >>> >>> On the other hand, adding "replay protection" and orphaning the SPV >>> wallets would clearly create a massive chain split. >>> >>> Mike >>> >>> >>> >>> >>>> >>>> >>>> -Chris >>>> >>>> On Sun, Oct 8, 2017 at 5:57 PM, bitPico wrote: >>>>> >>>>> https://blockchain.info/charts/nya-support >>>>> >>>>> ~95-96% >>>>> >>>>> Do the math on how long it would take to solve a 1x (deprecated) block >>>>> with only 4-5% network hash power. >>>>> >>>>> There is no HACK in place to drop the difficulty either so it?s a dead >>>>> blockchain. :-) >>>>> >>>>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x >>>>> wrote: >>>>> >>>>> So just to be clear, segwit2x no longer believes there will not be a >>>>> chain split come November? >>>>> >>>>> -Chris >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>> >>> >>> >>> -- >>> >>> Mike Belshe >>> CEO, BitGo, Inc >>> 408-718-6885 >> >> > > > > -- > > Mike Belshe > CEO, BitGo, Inc > 408-718-6885 > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From bitpico at icloud.com Mon Oct 9 09:25:48 2017 From: bitpico at icloud.com (bitPico) Date: Mon, 09 Oct 2017 05:25:48 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: This is a Bitcoin 2x Base Block Size technical discussion list not for speculative or other discussions. Thank You > On Oct 9, 2017, at 4:46 AM, Marcel Jamin via Bitcoin-segwit2x wrote: > > On 9 October 2017 at 05:46, Mike Belshe via Bitcoin-segwit2x > wrote: > >> BitGo serves its customers; we'll handle both chains. >> I still hope everyone decides to vote for bigger blocks - its taken a long >> time to get here, and we have a great opportunity! > > The block limit effectively doubled recently. You say that's because > of the NYA, others say it's because of the UASF ultimatum. Personally > I believe the pro-hardfork side saw a chance to get their pound of > flesh with the NYA and BIP91 caught them by surprise. But the UASF > deadline provided the pressure. > > In any case, it already doubled and you want to double it *again*. > >> No reason to support two chains except pride. > > The new chain will be run by a forked off client maintained by a new > and much smaller set of developers willing to give in to business (and > presumably government) pressure. > > The original chain will keep the most if not all of the developer > talent that helped bitcoin flourish over the past years and follow a > more rational and less political approach to decision making. > > I see plenty of reason to support the original chain and can't fathom > how anyone (except some CEOs perhaps) would value the former higher > than the latter. Early results on Bitfinex tend to agree with me here. > This valuation will be an issue for you and the mining support you > currently think you have. Understand that hashpower is a value add, > not the core value proposition. Even with 1000x the hashpower, there's > nothing secure about a corporately run version of bitcoin. > > > - Marcel > > >> >> Mike >> >> >>> On Sun, Oct 8, 2017 at 8:43 PM, Chris Stewart wrote: >>> >>>> No. >>> >>> Ok. Thanks for the candid answer Mike. I look forward to an official >>> update from bitgo of how they will handle this chain split wrt to bitcoin >>> and segwit2x. >>> >>> -Chris >>> >>>> On Sun, Oct 8, 2017 at 10:38 PM, Mike Belshe wrote: >>>> >>>> >>>> >>>> On Sun, Oct 8, 2017 at 5:56 PM, Chris Stewart via Bitcoin-segwit2x >>>> wrote: >>>>> >>>>> So just so this is clear to the rest of the world, Segwit2x believes >>>>> there will be no chain split? >>>> >>>> >>>> No. >>>> >>>> Although the design goal was to not create a split, that doesn't mean >>>> that there won't be one. Since you can never get 100.000% agreement, I >>>> suppose you could say that means there must be a split - the question is >>>> just how big. >>>> >>>> From the beginning, the segwit2x crew tried to garner as much support as >>>> possible and make the code as simple and unobtrusive as possible. They >>>> certainly accomplished a lot - getting more miner support than ever in >>>> history, and getting segwit itself activated. With regard to the 2MB >>>> upgrade, it does seem that many are against it. But if you look at the node >>>> counts of SPV and full nodes, its easy to see that this group is incredibly >>>> small - likely 0.5% or less of all deployed wallets. >>>> >>>> On the other hand, adding "replay protection" and orphaning the SPV >>>> wallets would clearly create a massive chain split. >>>> >>>> Mike >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> -Chris >>>>> >>>>>> On Sun, Oct 8, 2017 at 5:57 PM, bitPico wrote: >>>>>> >>>>>> https://blockchain.info/charts/nya-support >>>>>> >>>>>> ~95-96% >>>>>> >>>>>> Do the math on how long it would take to solve a 1x (deprecated) block >>>>>> with only 4-5% network hash power. >>>>>> >>>>>> There is no HACK in place to drop the difficulty either so it?s a dead >>>>>> blockchain. :-) >>>>>> >>>>>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x >>>>>> wrote: >>>>>> >>>>>> So just to be clear, segwit2x no longer believes there will not be a >>>>>> chain split come November? >>>>>> >>>>>> -Chris >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Mike Belshe >>>> CEO, BitGo, Inc >>>> 408-718-6885 >>> >>> >> >> >> >> -- >> >> Mike Belshe >> CEO, BitGo, Inc >> 408-718-6885 >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x From marcel at jamin.net Mon Oct 9 10:00:06 2017 From: marcel at jamin.net (Marcel Jamin) Date: Mon, 9 Oct 2017 12:00:06 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: On 9 October 2017 at 11:25, bitPico wrote: > This is a Bitcoin 2x Base Block Size technical discussion list not for speculative or other discussions. The post I replied to wasn't technical to begin with. It feels like the off-topic card is played rather selectively. Also, to be technical, there is no base block size. This list discusses raising the MAX_BLOCK_WEIGHT from 4M to 8M. > > Thank You > >> On Oct 9, 2017, at 4:46 AM, Marcel Jamin via Bitcoin-segwit2x wrote: >> >> On 9 October 2017 at 05:46, Mike Belshe via Bitcoin-segwit2x >> wrote: >> >>> BitGo serves its customers; we'll handle both chains. >>> I still hope everyone decides to vote for bigger blocks - its taken a long >>> time to get here, and we have a great opportunity! >> >> The block limit effectively doubled recently. You say that's because >> of the NYA, others say it's because of the UASF ultimatum. Personally >> I believe the pro-hardfork side saw a chance to get their pound of >> flesh with the NYA and BIP91 caught them by surprise. But the UASF >> deadline provided the pressure. >> >> In any case, it already doubled and you want to double it *again*. >> >>> No reason to support two chains except pride. >> >> The new chain will be run by a forked off client maintained by a new >> and much smaller set of developers willing to give in to business (and >> presumably government) pressure. >> >> The original chain will keep the most if not all of the developer >> talent that helped bitcoin flourish over the past years and follow a >> more rational and less political approach to decision making. >> >> I see plenty of reason to support the original chain and can't fathom >> how anyone (except some CEOs perhaps) would value the former higher >> than the latter. Early results on Bitfinex tend to agree with me here. >> This valuation will be an issue for you and the mining support you >> currently think you have. Understand that hashpower is a value add, >> not the core value proposition. Even with 1000x the hashpower, there's >> nothing secure about a corporately run version of bitcoin. >> >> >> - Marcel >> >> >>> >>> Mike >>> >>> >>>> On Sun, Oct 8, 2017 at 8:43 PM, Chris Stewart wrote: >>>> >>>>> No. >>>> >>>> Ok. Thanks for the candid answer Mike. I look forward to an official >>>> update from bitgo of how they will handle this chain split wrt to bitcoin >>>> and segwit2x. >>>> >>>> -Chris >>>> >>>>> On Sun, Oct 8, 2017 at 10:38 PM, Mike Belshe wrote: >>>>> >>>>> >>>>> >>>>> On Sun, Oct 8, 2017 at 5:56 PM, Chris Stewart via Bitcoin-segwit2x >>>>> wrote: >>>>>> >>>>>> So just so this is clear to the rest of the world, Segwit2x believes >>>>>> there will be no chain split? >>>>> >>>>> >>>>> No. >>>>> >>>>> Although the design goal was to not create a split, that doesn't mean >>>>> that there won't be one. Since you can never get 100.000% agreement, I >>>>> suppose you could say that means there must be a split - the question is >>>>> just how big. >>>>> >>>>> From the beginning, the segwit2x crew tried to garner as much support as >>>>> possible and make the code as simple and unobtrusive as possible. They >>>>> certainly accomplished a lot - getting more miner support than ever in >>>>> history, and getting segwit itself activated. With regard to the 2MB >>>>> upgrade, it does seem that many are against it. But if you look at the node >>>>> counts of SPV and full nodes, its easy to see that this group is incredibly >>>>> small - likely 0.5% or less of all deployed wallets. >>>>> >>>>> On the other hand, adding "replay protection" and orphaning the SPV >>>>> wallets would clearly create a massive chain split. >>>>> >>>>> Mike >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> -Chris >>>>>> >>>>>>> On Sun, Oct 8, 2017 at 5:57 PM, bitPico wrote: >>>>>>> >>>>>>> https://blockchain.info/charts/nya-support >>>>>>> >>>>>>> ~95-96% >>>>>>> >>>>>>> Do the math on how long it would take to solve a 1x (deprecated) block >>>>>>> with only 4-5% network hash power. >>>>>>> >>>>>>> There is no HACK in place to drop the difficulty either so it?s a dead >>>>>>> blockchain. :-) >>>>>>> >>>>>>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x >>>>>>> wrote: >>>>>>> >>>>>>> So just to be clear, segwit2x no longer believes there will not be a >>>>>>> chain split come November? >>>>>>> >>>>>>> -Chris >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Bitcoin-segwit2x mailing list >>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Mike Belshe >>>>> CEO, BitGo, Inc >>>>> 408-718-6885 >>>> >>>> >>> >>> >>> >>> -- >>> >>> Mike Belshe >>> CEO, BitGo, Inc >>> 408-718-6885 >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x From mike at bitgo.com Mon Oct 9 14:43:13 2017 From: mike at bitgo.com (Mike Belshe) Date: Mon, 9 Oct 2017 07:43:13 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: I don't expect to convince you, but segwit didn't double the block size as you claim. You can witness the results yourself - more like a 3% increase so far. I expect it may get to a 50% increase in 8-10 months, but your mileage may vary. Even at theoretical max, its not a doubling. Regardless, we should always be thinking about growing capacity. I'm interested in helping a much larger portion of the world have access to Bitcoin, and we know we need to move forward. This is a simple and easy step. I've never heard customers say "no thanks" to better scalability except in Bitcoin. Today, Bitcoin is small potatoes. Want to make it really soar? Make it available to everyone. Best, Mike On Mon, Oct 9, 2017 at 1:46 AM, Marcel Jamin wrote: > On 9 October 2017 at 05:46, Mike Belshe via Bitcoin-segwit2x > wrote: > > > BitGo serves its customers; we'll handle both chains. > > I still hope everyone decides to vote for bigger blocks - its taken a > long > > time to get here, and we have a great opportunity! > > The block limit effectively doubled recently. You say that's because > of the NYA, others say it's because of the UASF ultimatum. Personally > I believe the pro-hardfork side saw a chance to get their pound of > flesh with the NYA and BIP91 caught them by surprise. But the UASF > deadline provided the pressure. > > In any case, it already doubled and you want to double it *again*. > > > No reason to support two chains except pride. > > The new chain will be run by a forked off client maintained by a new > and much smaller set of developers willing to give in to business (and > presumably government) pressure. > > The original chain will keep the most if not all of the developer > talent that helped bitcoin flourish over the past years and follow a > more rational and less political approach to decision making. > > I see plenty of reason to support the original chain and can't fathom > how anyone (except some CEOs perhaps) would value the former higher > than the latter. Early results on Bitfinex tend to agree with me here. > This valuation will be an issue for you and the mining support you > currently think you have. Understand that hashpower is a value add, > not the core value proposition. Even with 1000x the hashpower, there's > nothing secure about a corporately run version of bitcoin. > > > - Marcel > > > > > > Mike > > > > > > On Sun, Oct 8, 2017 at 8:43 PM, Chris Stewart > wrote: > >> > >> >No. > >> > >> Ok. Thanks for the candid answer Mike. I look forward to an official > >> update from bitgo of how they will handle this chain split wrt to > bitcoin > >> and segwit2x. > >> > >> -Chris > >> > >> On Sun, Oct 8, 2017 at 10:38 PM, Mike Belshe wrote: > >>> > >>> > >>> > >>> On Sun, Oct 8, 2017 at 5:56 PM, Chris Stewart via Bitcoin-segwit2x > >>> wrote: > >>>> > >>>> So just so this is clear to the rest of the world, Segwit2x believes > >>>> there will be no chain split? > >>> > >>> > >>> No. > >>> > >>> Although the design goal was to not create a split, that doesn't mean > >>> that there won't be one. Since you can never get 100.000% agreement, I > >>> suppose you could say that means there must be a split - the question > is > >>> just how big. > >>> > >>> From the beginning, the segwit2x crew tried to garner as much support > as > >>> possible and make the code as simple and unobtrusive as possible. They > >>> certainly accomplished a lot - getting more miner support than ever in > >>> history, and getting segwit itself activated. With regard to the 2MB > >>> upgrade, it does seem that many are against it. But if you look at > the node > >>> counts of SPV and full nodes, its easy to see that this group is > incredibly > >>> small - likely 0.5% or less of all deployed wallets. > >>> > >>> On the other hand, adding "replay protection" and orphaning the SPV > >>> wallets would clearly create a massive chain split. > >>> > >>> Mike > >>> > >>> > >>> > >>> > >>>> > >>>> > >>>> -Chris > >>>> > >>>> On Sun, Oct 8, 2017 at 5:57 PM, bitPico wrote: > >>>>> > >>>>> https://blockchain.info/charts/nya-support > >>>>> > >>>>> ~95-96% > >>>>> > >>>>> Do the math on how long it would take to solve a 1x (deprecated) > block > >>>>> with only 4-5% network hash power. > >>>>> > >>>>> There is no HACK in place to drop the difficulty either so it?s a > dead > >>>>> blockchain. :-) > >>>>> > >>>>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x > >>>>> wrote: > >>>>> > >>>>> So just to be clear, segwit2x no longer believes there will not be a > >>>>> chain split come November? > >>>>> > >>>>> -Chris > >>>>> > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Bitcoin-segwit2x mailing list > >>>> Bitcoin-segwit2x at lists.linuxfoundation.org > >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>>> > >>> > >>> > >>> > >>> -- > >>> > >>> Mike Belshe > >>> CEO, BitGo, Inc > >>> 408-718-6885 > >> > >> > > > > > > > > -- > > > > Mike Belshe > > CEO, BitGo, Inc > > 408-718-6885 > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > -- *Mike Belshe* *CEO, BitGo, Inc*408-718-6885 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel at jamin.net Mon Oct 9 15:48:20 2017 From: marcel at jamin.net (Marcel Jamin) Date: Mon, 9 Oct 2017 17:48:20 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: On 9 October 2017 at 16:43, Mike Belshe wrote: > I don't expect to convince you, but segwit didn't double the block size as > you claim. You can witness the results yourself - more like a 3% increase > so far. I expect it may get to a 50% increase in 8-10 months, but your > mileage may vary. I didn't claim that the block size doubled, I pointed to the fact that the block *limit* effectively doubled. And the fact that the available capacity is not fully utilized right now does say something about the urgency of further increasing MAX_BLOCK_WEIGHT. > Even at theoretical max, its not a doubling. The theoretical max is slightly less than 4M bytes. Four times the previous limit. The recent estimates I've seen put the effective/practical capacity increase at 2.1x - 2.3x if SegWit is fully utilized. > Regardless, we should always be thinking about growing capacity. And we are, of course. SegWit provides a doubling of capacity. Schnorr signatures will build upon that and provide another 20-30%. The lightning network then completely knocks it out of the park and effectively increases the capacity for certain types of transactions / use cases by several orders of magnitude. > I'm interested in helping a much larger portion of the world have access to > Bitcoin, and we know we need to move forward. This is a simple and easy > step. That's very honorable and most bitcoiners share that goal, but the approach you take is utterly wrong and will utlimately fail. The question just is how much damage you want to do to bitcoin and/or the bitcoin brand in order to eventually realize that. The sheer audacity of non-tech people to promote their technical solution despite overwhelming expert opposition is mind-boggling (https://en.bitcoin.it/wiki/Segwit_support). I'm sorry to be blunt, but you're way out of your circle of competence and you need to recognize that. > I've never heard customers say "no thanks" to better scalability except in Bitcoin. Bitcoin is not a business and does not have customers. It has users, many of which don't primarily value it because of super low transactions fees, but because of it's censorship resistance. Because of the fact that no single entity or group has full control over it. This includes DCG & friends. Changes to bitcoin must be argued for. All concerns need to be addressed. If we start making backroom deals to get stuff in and let certain groups hold things like SegWit hostage to successfully get what they want but can't properly argue for, I'd consider this experiment failed. > Today, Bitcoin is small potatoes. Want to make it really soar? Make it > available to everyone. We owe it to ourselves to do it properly. > > Best, > Mike > > > On Mon, Oct 9, 2017 at 1:46 AM, Marcel Jamin wrote: >> >> On 9 October 2017 at 05:46, Mike Belshe via Bitcoin-segwit2x >> wrote: >> >> > BitGo serves its customers; we'll handle both chains. >> > I still hope everyone decides to vote for bigger blocks - its taken a >> > long >> > time to get here, and we have a great opportunity! >> >> The block limit effectively doubled recently. You say that's because >> of the NYA, others say it's because of the UASF ultimatum. Personally >> I believe the pro-hardfork side saw a chance to get their pound of >> flesh with the NYA and BIP91 caught them by surprise. But the UASF >> deadline provided the pressure. >> >> In any case, it already doubled and you want to double it *again*. >> >> > No reason to support two chains except pride. >> >> The new chain will be run by a forked off client maintained by a new >> and much smaller set of developers willing to give in to business (and >> presumably government) pressure. >> >> The original chain will keep the most if not all of the developer >> talent that helped bitcoin flourish over the past years and follow a >> more rational and less political approach to decision making. >> >> I see plenty of reason to support the original chain and can't fathom >> how anyone (except some CEOs perhaps) would value the former higher >> than the latter. Early results on Bitfinex tend to agree with me here. >> This valuation will be an issue for you and the mining support you >> currently think you have. Understand that hashpower is a value add, >> not the core value proposition. Even with 1000x the hashpower, there's >> nothing secure about a corporately run version of bitcoin. >> >> >> - Marcel >> >> >> > >> > Mike >> > >> > >> > On Sun, Oct 8, 2017 at 8:43 PM, Chris Stewart >> > wrote: >> >> >> >> >No. >> >> >> >> Ok. Thanks for the candid answer Mike. I look forward to an official >> >> update from bitgo of how they will handle this chain split wrt to >> >> bitcoin >> >> and segwit2x. >> >> >> >> -Chris >> >> >> >> On Sun, Oct 8, 2017 at 10:38 PM, Mike Belshe wrote: >> >>> >> >>> >> >>> >> >>> On Sun, Oct 8, 2017 at 5:56 PM, Chris Stewart via Bitcoin-segwit2x >> >>> wrote: >> >>>> >> >>>> So just so this is clear to the rest of the world, Segwit2x believes >> >>>> there will be no chain split? >> >>> >> >>> >> >>> No. >> >>> >> >>> Although the design goal was to not create a split, that doesn't mean >> >>> that there won't be one. Since you can never get 100.000% agreement, I >> >>> suppose you could say that means there must be a split - the question >> >>> is >> >>> just how big. >> >>> >> >>> From the beginning, the segwit2x crew tried to garner as much support >> >>> as >> >>> possible and make the code as simple and unobtrusive as possible. They >> >>> certainly accomplished a lot - getting more miner support than ever in >> >>> history, and getting segwit itself activated. With regard to the 2MB >> >>> upgrade, it does seem that many are against it. But if you look at >> >>> the node >> >>> counts of SPV and full nodes, its easy to see that this group is >> >>> incredibly >> >>> small - likely 0.5% or less of all deployed wallets. >> >>> >> >>> On the other hand, adding "replay protection" and orphaning the SPV >> >>> wallets would clearly create a massive chain split. >> >>> >> >>> Mike >> >>> >> >>> >> >>> >> >>> >> >>>> >> >>>> >> >>>> -Chris >> >>>> >> >>>> On Sun, Oct 8, 2017 at 5:57 PM, bitPico wrote: >> >>>>> >> >>>>> https://blockchain.info/charts/nya-support >> >>>>> >> >>>>> ~95-96% >> >>>>> >> >>>>> Do the math on how long it would take to solve a 1x (deprecated) >> >>>>> block >> >>>>> with only 4-5% network hash power. >> >>>>> >> >>>>> There is no HACK in place to drop the difficulty either so it?s a >> >>>>> dead >> >>>>> blockchain. :-) >> >>>>> >> >>>>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x >> >>>>> wrote: >> >>>>> >> >>>>> So just to be clear, segwit2x no longer believes there will not be a >> >>>>> chain split come November? >> >>>>> >> >>>>> -Chris >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Bitcoin-segwit2x mailing list >> >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> >> >>> Mike Belshe >> >>> CEO, BitGo, Inc >> >>> 408-718-6885 >> >> >> >> >> > >> > >> > >> > -- >> > >> > Mike Belshe >> > CEO, BitGo, Inc >> > 408-718-6885 >> > >> > >> > _______________________________________________ >> > Bitcoin-segwit2x mailing list >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > > > > > -- > > Mike Belshe > CEO, BitGo, Inc > 408-718-6885 From jerry.d.chan at bittoku.co.jp Mon Oct 9 05:16:25 2017 From: jerry.d.chan at bittoku.co.jp (Jerry D Chan) Date: Mon, 9 Oct 2017 14:16:25 +0900 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> <1529390F-BE49-40B8-AD7E-6769AEC7B4FF@gmail.com> <75497358-A9DF-4987-850A-E3EA7E711E8D@bittoku.co.jp> Message-ID: <9A0F644A-E2AB-47DC-A3F2-BB1AEF75D484@bittoku.co.jp> You hit upon the important point here: 1) Services are charged with keeping safe the clients assets, NOT its value. The assets in this case are private keys. These are not affected in a fork. 2) For services that are not holding keys as assets but ?balances? then they should already be licensed as a deposit holding business aka, a banking institution, (are they really? I doubt BitFinex is) if they aren?t then they have no obligation whatsoever, and if you are their client you should have known this when you willingly gave them your bitcoins. If they aren?t, then you traded your bitcoins for what effectively are air mileage points when you sent them to the business. They can do whatever they want with them, including cancelling them at will. 3) For ones that ?are? banks, then basically what you are saying is that the law should be enforcing them to stay in consensus with each other. ? I don?t believe this is the responsibility of the businesses. They should have clearly stated in their T&C that they would support the ledger of the most proof of work chain. That is about all they can guarantee they can do. Else you are effectively trying to put a meta-layer of consensus over bitcoin PoW. Jerry D Chan President and Founder Bittoku G.K. jerry.d.chan at bittoku.co.jp www.bittoku.co.jp > On Oct 9, 2017, at 12:49, Chris Stewart wrote: > > >Let?s keep the discussion technical, there is no reason to start debating phrasing or semantics here, I should think you know very well what I mean when I said ?framing?. Its a business, they can choose what kind of service they can provide their customers. If they were a business that was run properly, then they would have stated in their T&C that they would only offer access to the bitcoin ledger of which they have the sole right to determine which one it is. > > I agree, *technically* most consumer facing companies are acting as custodians of bitcoin*. In the case of a hard fork they will inherit custody of a new crypto asset. In most jurisdictions these companies cannot outright confiscate assets (in this case either bitcoin or the hard fork asset) from their customers. > > * - there are a few exceptions to this. I'm talking about about your traditional exchange/broker (coinbase,gemini,bitstamp,bitfinex etc) > > -Chris > > On Sun, Oct 8, 2017 at 10:41 PM, Jerry D Chan > wrote: > There is no marketing involved. Let?s keep the discussion technical, there is no reason to start debating phrasing or semantics here, I should think you know very well what I mean when I said ?framing?. Its a business, they can choose what kind of service they can provide their customers. If they were a business that was run properly, then they would have stated in their T&C that they would only offer access to the bitcoin ledger of which they have the sole right to determine which one it is. Most of the time this will be what everyone else agrees it is, but in times of a fork, the only thing that the business can guarantee that they will have control over their version of the ledger. > > Unless a company has explicitly stated that they will support any and all ledger forks that persist past a certain time, this should not be assumed to be the default behaviour, ?ethical?, ?moral obligation? or otherwise. > > Bitcoin is a new paradigm. Users who put their money into it thinking that it is just ?digital gold? and services just ?banks? should be dissuaded from believing this oversimplification, for exactly the situations such as the one we find ourselves in now. > > > Jerry D Chan > President and Founder > Bittoku G.K. > jerry.d.chan at bittoku.co.jp > www.bittoku.co.jp > > > > >> On Oct 9, 2017, at 12:26, Chris Stewart > wrote: >> >> It seems to me if bitcoin forks the consumer facing companies would be responsible for crediting users with balances on both chains. The word 'framing' makes me think of subjective marketing terms -- this is the interesting thing about bitcoin -- we are dealing with a bearer asset that *technically* can be forked by *anybody*. >> >> >they can simply tell their customers that this is the upgrade path that they will be taking, and if they don?t agree with it, then they should remove their funds or cease to use their service >> >> Again, I disagree about the word 'upgrade' in this context -- see my Peter Thiel comment -- but otherwise this seems prudent if you are diverging from consensus, but do you think there is enough time left until the hard fork to actually do this in a responsible manner? A lot of people don't follow bitcoin news on a daily basis like both of us do. >> >> -Chris >> >> On Sun, Oct 8, 2017 at 10:05 PM, Jerry D Chan > wrote: >> They *could*, if they were framing the fork as an optional new transactional network option. But if they are framing it as an *upgrade* to the existing one, they can simply tell their customers that this is the upgrade path that they will be taking, and if they don?t agree with it, then they should remove their funds or cease to use their service. There is no way to ?ask? your customers that can?t be simply sybil attacked by those who will pay for social media noise. >> >> >> Jerry D Chan >> President and Founder >> Bittoku G.K. >> jerry.d.chan at bittoku.co.jp >> www.bittoku.co.jp >> >> >> >> >>> On Oct 9, 2017, at 12:02, Chris Stewart via Bitcoin-segwit2x > wrote: >>> >>> So again -- just to be crystal clear -- consumer facing companies that signed the segwit2x agreement should offer their customers this choice between the two chains? >>> >>> -Chris >>> >>> On Oct 8, 2017 9:55 PM, "digitsu" > wrote: >>> It doesn?t require any assumptions. Users (who tend to care about the transaction validity and reliability of their chain) will move. Those that don?t move will stay because they value their principles or idealogy more than functionality or security of their chain. Everyone will get what they want (to pay for). >>> >>> There is no coercion required. >>> >>> >>>> On Oct 9, 2017, at 11:43, Chris Stewart via Bitcoin-segwit2x > wrote: >>>> >>>> You cannot make assumptions about what users will do (unless you are assuming that the business they are using coerced them onto a specific chain). >>>> >>>> Also the word 'upgraded' is very subjective. I consider upgrades to be the Peter Thiel flavor of "0 to 1" (legitimate new technology) not the "1 to N" that hard forking a block size increase does. >>>> >>>> -Chris >>>> On Oct 8, 2017 9:05 PM, "Emil Oldenburg" > wrote: >>>> I never said it will. Simply that the users will move to the upgraded chain and the legacy one will have neither blocks nor users after a short while. >>>> >>>> >>>> >>>> Emil Oldenburg, CTO >>>> Emil at bitcoin.com >>>> Visit the all new https://bitcoin.com >>>> Wechat: emilold >>>> Telegram: emilold >>>> On 2017?10?09? 10:59, Chris Stewart wrote: >>>>> This is really alarming that you think this is how consensus protocols work. The legacy chain will never reorg to the new currency. The two consensus rule sets are incompatible. >>>>> >>>>> -Chris >>>>> >>>>> On Sun, Oct 8, 2017 at 8:39 PM, Emil Oldenburg via Bitcoin-segwit2x > wrote: >>>>> Chain splits happens once in a while, we had a chain split three days ago, even though it didn't last as no miner built a block on top of the AntPool block since the cost of burying it deep enough to reach more than 100 confirmations so it can be sold, simply was too high. >>>>> >>>>> https://www.blocktrail.com/BTC/blocks/orphans/1 >>>>> Post HF, we will get a chain split, and blocks will be mined on both chains. But the economic reality is that the non-upgraded legacy chain face a significant risk of getting orphaned/abandoned. What is a good definition of chain split? 1, 100, or 1000 blocks? >>>>> >>>>> >>>>> >>>>> Emil Oldenburg, CTO >>>>> Emil at bitcoin.com >>>>> Visit the all new https://bitcoin.com >>>>> Wechat: emilold >>>>> Telegram: emilold >>>>> On 2017?10?09? 09:56, Chris Stewart via Bitcoin-segwit2x wrote: >>>>>> So just so this is clear to the rest of the world, Segwit2x believes there will be no chain split? >>>>>> >>>>>> -Chris >>>>>> >>>>>> On Sun, Oct 8, 2017 at 5:57 PM, bitPico > wrote: >>>>>> https://blockchain.info/charts/nya-support >>>>>> >>>>>> ~95-96% >>>>>> >>>>>> Do the math on how long it would take to solve a 1x (deprecated) block with only 4-5% network hash power. >>>>>> >>>>>> There is no HACK in place to drop the difficulty either so it?s a dead blockchain. :-) >>>>>> >>>>>>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x > wrote: >>>>>>> >>>>>>> So just to be clear, segwit2x no longer believes there will not be a chain split come November? >>>>>>> >>>>>>> -Chris >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Bitcoin-segwit2x mailing list >>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-08-10 at 2.19.56.png Type: image/png Size: 8427 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From hubert.maslin at gmail.com Mon Oct 9 16:58:19 2017 From: hubert.maslin at gmail.com (hubert maslin) Date: Mon, 9 Oct 2017 18:58:19 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection Message-ID: Hello Mike, I understand that you're meaning well and want, as we all do, bitcoin to succeed over long term, and by reading your messages on this thread I've once again noticed that the current rift within the Bitcoin community actually springs from a few disagreements that have more to do with culture and process rather than with long term goals. I'm going to talk about those disagreements and hopefully state the "pro decentralisation" position in a way that's conducive to intelligent debate and perhaps, ultimate agreement. We want to bring Bitcoin to more users because it has unique features and qualities (namely permissionless-ness, resistance to tx censorship, resistance to inflation, pseudonymity) that the existing financial system doesn't offer. The presence of these features is contrary to the interests of many powerful entities (the legacy banking system, governments and their surveillance agencies) and only survive thanks to Bitcoin's decentralisation and absence of centralised points of failure. Being willing to sacrifice or endanger Bitcoin's decentralisation to achieve scaling isn't wise or forward thinking, and is completely self-defeating. What's the point of on-boarding an ever greater number of users if you run the risk of weakening those features and give those users the same experience than current centralised paiement systems offer, e.g. tx censorship, vulnerability to inflation, and government surveillance? This would be a nonsensical and unproductive thing to do. Doing this would be all the more absurd that we now know (as we have since 2015) that, before increasing base block size, we can greatly increase throughput through more efficient of block space (with Segwit and, in the near future, with MAST, Schnorr signatures and signatures aggregation) and more importantly, with second layer technologies such as the Lightning Network or sidechains. These technologies are under rapid development, and will soon alleviate scaling. Presenting the scaling debate as a dichotomy between "onboard users fast and break things" and "let's for ever stay a store of value for rich people" is a mistake, because we know we can already greatly improve scaling, within the next few months and years. Was scaling slower than anticipated, we should err on the side of caution, and not give our potential adversaries any lever that they might pull to weaken those features. And this is why this scheduled hard fork worries me. Regardless of the blockchain bloating issue, changing consensus rules without wide community consensus - and in particular without the consensus of the community members that value decentralisation and privacy the most - is precisely such a lever for governments or other antagonists to pull. It would set an extremely bad precedent. The particulars of this fork - the fact that it doesn't have replay protection, that it lays a claim on the Bitcoin brand, that it relies on the imperfect security models of SPV wallets to make them follow new consensus rules - make things worse. if this fork is successful and the entire community shifts to the S2X chain (which, barring a prolonged 51% attack on the original chain, seems extremely unlikely to me), this would signals to external actors that consensus rules can be changed by exercising the right pressure on the right companies - and we're literally talking of a dozen mining pools and a dozen major paiement processors and exchanges, spread in only a few jurisdictions. This would cast doubt on the entire ability of cryptocurrencies to remain decentralised and act as censorship-resistant medium of exchange and inflation-resistant store of value. Bitcoin's sole comparative advantage over centralised systems would vanish. Even if this fork wasn't a base block size doubling but a simple, symbolic increase of one byte to base block size, it would still be a bad thing, because it would show that consensus rules - and therefore the very nature of the currency people use - can be changed by external actors. To me and to many other people, this debate isn't about block size anymore: it's about the survivability of Bitcoin as a decentralised system. The Bitcoin community should be as amorphous and resistant to change as possible - even to more technically sound changes like Segwit, and even when these changes come from competent devs with a solid track record of defending decentralisation and privacy. Just because only a few thousands or dozens of thousands of early users and cypherpunks out of a dozen million of users disagree with this fork doesn't mean we can be ignored: Bitcoin rose to its current popularity (and value) because we invested our time, our hopes and our money in it, and millions of politically unresponsive BitPay or Coinbase customers will not make up for our absence on a centralised chain. Claiming that Segwit2X has consensus with the now standard line "those who oppose it are only a few thousands, while NYA signatories have millions of customers" is akin to the NSA claiming that a majority of citizens endorses surveillance, "because only a few thousands nerds care about it". Claiming the silence of a majority of stakeholders as a tacit endorsement of some policy is a dangerous (and I would add immoral) thing to do, and is what has led to the creation of the centralised institutions that Bitcoin aims at replacing. Bitcoin is a formidable opportunity to bring greater monetary, economic and political freedom to all humans, and the single best hope of freedom-loving persons in this otherwise authoritarian and freedom-hating century. Regardless of whatever understanding or sympathy we may have for you and other NYA signatories, we who care about those things can not accept cooptation by companies who effectively are centralised points of failure at the mercy of governments. If I could sum up my position (and the position of many users preoccupied with decentralisation), it would be: "let us scale wisely, without making short-term compromises that would weaken Bitcoin's unique features". Merely increasing base block size as soon as we lack space would be akin to kicking the can down the road to serfdom. And changing consensus rules at a whim - or worse, engaging in a 51% attack to coerce the community into following the new rules - would get us there in no time. And to respond to one of your points, Mike, wishing for both chains to survive is certainly not about "pride": it's about giving a durable, decentralised consensus system to the world, a system that can't be coopted, coerced or censored. Mike, if you have any question or wish to continue this chat privately feel free to respond directly to this email. I feel that the differences between our respective camps are born out of cultural differences and absurd misunderstandings, and magnified by our good ol' tribal instincts; there is no reason why we should go through a messy divorce when we all agree on making Bitcoin the world's sole currency, used for both small purchases and storing large amount of values. This is Bitcoin's destiny, and our squabbles are petty in comparison. Cheers. Hubert -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at bitgo.com Mon Oct 9 17:00:03 2017 From: mike at bitgo.com (Mike Belshe) Date: Mon, 9 Oct 2017 10:00:03 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: On Mon, Oct 9, 2017 at 8:48 AM, Marcel Jamin wrote: > On 9 October 2017 at 16:43, Mike Belshe wrote: > > I don't expect to convince you, but segwit didn't double the block size > as > > you claim. You can witness the results yourself - more like a 3% > increase > > so far. I expect it may get to a 50% increase in 8-10 months, but your > > mileage may vary. > > I didn't claim that the block size doubled, I pointed to the fact that > the block *limit* effectively doubled. And the fact that the available > capacity is not fully utilized right now does say something about the > urgency of further increasing MAX_BLOCK_WEIGHT. > > > > Even at theoretical max, its not a doubling. > > The theoretical max is slightly less than 4M bytes. Four times the > previous limit. The recent estimates I've seen put the > effective/practical capacity increase at 2.1x - 2.3x if SegWit is > fully utilized. > I was using Bitcoin Core's expectation of 60% maximum increase as described here: https://bitcoincore.org/en/2016/01/26/segwit-benefits/#block-capacitysize-increase > > > Regardless, we should always be thinking about growing capacity. > > And we are, of course. SegWit provides a doubling of capacity. Schnorr > signatures will build upon that and provide another 20-30%. The > lightning network then completely knocks it out of the park and > effectively increases the capacity for certain types of transactions / > use cases by several orders of magnitude. > Nobody is debating Schnorr signatures here. I think that is a great idea for the future too. > > > I'm interested in helping a much larger portion of the world have access > to > > Bitcoin, and we know we need to move forward. This is a simple and easy > > step. > > That's very honorable and most bitcoiners share that goal, but the > approach you take is utterly wrong and will utlimately fail. The > question just is how much damage you want to do to bitcoin and/or the > bitcoin brand in order to eventually realize that. > You failed to articulate any technical arguments here. > > The sheer audacity of non-tech people to promote their technical > solution despite overwhelming expert opposition is mind-boggling > (https://en.bitcoin.it/wiki/Segwit_support). I'm sorry to be blunt, > but you're way out of your circle of competence and you need to > recognize that. > Okay, thanks for the insults. I suggest you do some research. > > > I've never heard customers say "no thanks" to better scalability except > in Bitcoin. > > Bitcoin is not a business and does not have customers. It has users, > many of which don't primarily value it because of super low > transactions fees, but because of it's censorship resistance. Because > of the fact that no single entity or group has full control over it. > This includes DCG & friends. > I've never heard users say "no thanks" to better scalability except in Bitcoin. > > Changes to bitcoin must be argued for. All concerns need to be > addressed. If we start making backroom deals to get stuff in and let > certain groups hold things like SegWit hostage to successfully get > what they want but can't properly argue for, I'd consider this > experiment failed. > You have failed to make any technical arguments here. This has all been done, and after fervent debate, the decisions have been made. At this point, the onus is on you to provide technical arguments against segwit2x. While you have provided a full course dinner of insults to me and everyone else here, you've failed to state even one single technical argument against segwit2x. > > Today, Bitcoin is small potatoes. Want to make it really soar? Make it > > available to everyone. > > We owe it to ourselves to do it properly. > Again, give me a technical argument. Mike > > > > > Best, > > Mike > > > > > > On Mon, Oct 9, 2017 at 1:46 AM, Marcel Jamin wrote: > >> > >> On 9 October 2017 at 05:46, Mike Belshe via Bitcoin-segwit2x > >> wrote: > >> > >> > BitGo serves its customers; we'll handle both chains. > >> > I still hope everyone decides to vote for bigger blocks - its taken a > >> > long > >> > time to get here, and we have a great opportunity! > >> > >> The block limit effectively doubled recently. You say that's because > >> of the NYA, others say it's because of the UASF ultimatum. Personally > >> I believe the pro-hardfork side saw a chance to get their pound of > >> flesh with the NYA and BIP91 caught them by surprise. But the UASF > >> deadline provided the pressure. > >> > >> In any case, it already doubled and you want to double it *again*. > >> > >> > No reason to support two chains except pride. > >> > >> The new chain will be run by a forked off client maintained by a new > >> and much smaller set of developers willing to give in to business (and > >> presumably government) pressure. > >> > >> The original chain will keep the most if not all of the developer > >> talent that helped bitcoin flourish over the past years and follow a > >> more rational and less political approach to decision making. > >> > >> I see plenty of reason to support the original chain and can't fathom > >> how anyone (except some CEOs perhaps) would value the former higher > >> than the latter. Early results on Bitfinex tend to agree with me here. > >> This valuation will be an issue for you and the mining support you > >> currently think you have. Understand that hashpower is a value add, > >> not the core value proposition. Even with 1000x the hashpower, there's > >> nothing secure about a corporately run version of bitcoin. > >> > >> > >> - Marcel > >> > >> > >> > > >> > Mike > >> > > >> > > >> > On Sun, Oct 8, 2017 at 8:43 PM, Chris Stewart > >> > wrote: > >> >> > >> >> >No. > >> >> > >> >> Ok. Thanks for the candid answer Mike. I look forward to an official > >> >> update from bitgo of how they will handle this chain split wrt to > >> >> bitcoin > >> >> and segwit2x. > >> >> > >> >> -Chris > >> >> > >> >> On Sun, Oct 8, 2017 at 10:38 PM, Mike Belshe wrote: > >> >>> > >> >>> > >> >>> > >> >>> On Sun, Oct 8, 2017 at 5:56 PM, Chris Stewart via Bitcoin-segwit2x > >> >>> wrote: > >> >>>> > >> >>>> So just so this is clear to the rest of the world, Segwit2x > believes > >> >>>> there will be no chain split? > >> >>> > >> >>> > >> >>> No. > >> >>> > >> >>> Although the design goal was to not create a split, that doesn't > mean > >> >>> that there won't be one. Since you can never get 100.000% > agreement, I > >> >>> suppose you could say that means there must be a split - the > question > >> >>> is > >> >>> just how big. > >> >>> > >> >>> From the beginning, the segwit2x crew tried to garner as much > support > >> >>> as > >> >>> possible and make the code as simple and unobtrusive as possible. > They > >> >>> certainly accomplished a lot - getting more miner support than ever > in > >> >>> history, and getting segwit itself activated. With regard to the > 2MB > >> >>> upgrade, it does seem that many are against it. But if you look at > >> >>> the node > >> >>> counts of SPV and full nodes, its easy to see that this group is > >> >>> incredibly > >> >>> small - likely 0.5% or less of all deployed wallets. > >> >>> > >> >>> On the other hand, adding "replay protection" and orphaning the SPV > >> >>> wallets would clearly create a massive chain split. > >> >>> > >> >>> Mike > >> >>> > >> >>> > >> >>> > >> >>> > >> >>>> > >> >>>> > >> >>>> -Chris > >> >>>> > >> >>>> On Sun, Oct 8, 2017 at 5:57 PM, bitPico > wrote: > >> >>>>> > >> >>>>> https://blockchain.info/charts/nya-support > >> >>>>> > >> >>>>> ~95-96% > >> >>>>> > >> >>>>> Do the math on how long it would take to solve a 1x (deprecated) > >> >>>>> block > >> >>>>> with only 4-5% network hash power. > >> >>>>> > >> >>>>> There is no HACK in place to drop the difficulty either so it?s a > >> >>>>> dead > >> >>>>> blockchain. :-) > >> >>>>> > >> >>>>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x > >> >>>>> wrote: > >> >>>>> > >> >>>>> So just to be clear, segwit2x no longer believes there will not > be a > >> >>>>> chain split come November? > >> >>>>> > >> >>>>> -Chris > >> >>>>> > >> >>>>> > >> >>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> Bitcoin-segwit2x mailing list > >> >>>> Bitcoin-segwit2x at lists.linuxfoundation.org > >> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin- > segwit2x > >> >>>> > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> > >> >>> Mike Belshe > >> >>> CEO, BitGo, Inc > >> >>> 408-718-6885 > >> >> > >> >> > >> > > >> > > >> > > >> > -- > >> > > >> > Mike Belshe > >> > CEO, BitGo, Inc > >> > 408-718-6885 > >> > > >> > > >> > _______________________________________________ > >> > Bitcoin-segwit2x mailing list > >> > Bitcoin-segwit2x at lists.linuxfoundation.org > >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > > > > > > > > > > > -- > > > > Mike Belshe > > CEO, BitGo, Inc > > 408-718-6885 > -- *Mike Belshe* *CEO, BitGo, Inc*408-718-6885 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at bloq.com Mon Oct 9 17:19:44 2017 From: jeff at bloq.com (Jeff Garzik) Date: Mon, 9 Oct 2017 13:19:44 -0400 Subject: [Bitcoin-segwit2x] Bitcoin Protocol Change Specifications Message-ID: Introduction ---------------------- A familiar claim is that specifications for segwit2x do not exist, or segwit2x is "unspecified." This was false (link , link ) -- but it is a fair criticism that you have to google for them, and that shouldn't be the case. Specifications are also an issue in our wider community. To make it easier for both segwit2x and post-segwit2x development, there is a repository and simple process for Protocol Change Specifications (PCS) at https://github.com/btc1/specifications The process ------------------------- 1) Create a specification, stored as *drafts/PCS-$username-$featurename* format. 2) When code exists, is production ready and *may potentially activate*, move the specification to *PCS/PCS-$year-$number-$featurename* Engineers will be familiar with an IETF-like process. It is important for non-engineers to understand *creating a specification does not mean a change is accepted on the network - that's outside anybody's control*. The goal is to document what changes are live, or may go live. Current contents ------------------------------- The first few documents are the tx-size PCS and a clone of Sergio's segwit2x BIP into the PCS repo. 1) tx-size: tl;dr Goal is to state "tx limits don't change, even as block size increases" - tx limits are frozen for wallet compatibility. 2) segwit2x: Document SegWit + 2M multi-phase upgrade. This will also be where the replay protection proposal would be documented. Who is welcome? ---------------------------------- The wider community needs to open the innovative process to more developers. We would welcome and encourage Bitcoin and *Bitcoin-compatible* developers to contribute specifications: Bitcoin, Bitcoin Cash, Litecoin, Zcash, Bitcoin-compatible Drivechain, etc. The current BIP process and the overall toxic environment do not create welcoming, pro-developer outcomes where we all work together to create the best technology possible. Let's change that. What are the goals? --------------------------------------- 1. Shared innovation: It is way too early in the crypto game for infighting, or innovation gatekeeping by a small clique. We need to be sharing innovations across teams and chains, working together, beta testing *with real money* on litecoin or bitcoin cash or a sidechain, then adding that feature to bitcoin more conservatively (or not at all, if RM testing shows flaws). This was the flight path of SegWit (litecoin RM testing first) and now block size increase (Bitcoin Cash RM testing first). The best way to share innovation is working together on common specifications and best practices across chains. "Way back" in 2010, many of us simply assumed that bitcoin governance and upgradability would allow bitcoin to rapidly digest the latest innovations such as zero-knowledge proofs. This has not happened. 2. Increase focus on specification - push back on "the code is the spec" mentality. Work towards a multi-implementation network. 3. Solution sharing. Sharing of bug fixes (vs. features, #1, above). Real world example - A performance problem in bitcoin-derived zcash, found & fixed by zcash team, can be backported to bitcoin and other bitcoin clones. Most of these codebases are derived from Bitcoin, and benefit from sharing fixes. -- Jeff Garzik CEO and Co Founder Bloq, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Mon Oct 9 17:54:00 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Mon, 9 Oct 2017 17:54:00 +0000 Subject: [Bitcoin-segwit2x] Bitcoin Protocol Change Specifications In-Reply-To: References: , Message-ID: ACK everything here! * The current BIP process and the overall toxic environment do not create welcoming, pro-developer outcomes where we all work together to create the best technology possible. Let's change that. It is about time that btc1 is officially declared the reference client and this update, following on from the August 2017 update, confirms it in all but words. Congratulations to all on reaching this milestone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel at jamin.net Mon Oct 9 19:51:38 2017 From: marcel at jamin.net (Marcel Jamin) Date: Mon, 9 Oct 2017 21:51:38 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: On 9 October 2017 at 19:00, Mike Belshe wrote: > I was using Bitcoin Core's expectation of 60% maximum increase as described > here: > https://bitcoincore.org/en/2016/01/26/segwit-benefits/#block-capacitysize-increase > (The lower bound of it.) > Nobody is debating Schnorr signatures here. I think that is a great idea > for the future too. I brought up Schnorr signatures and LN up as examples of thinking about growing capacity. > You failed to articulate any technical arguments here. I didn't try to. Those have already been made by people far more capable than me again and again. And subsequently handwaved away. Talk about being insulting. >> The sheer audacity of non-tech people to promote their technical >> solution despite overwhelming expert opposition is mind-boggling >> (https://en.bitcoin.it/wiki/Segwit_support). I'm sorry to be blunt, >> but you're way out of your circle of competence and you need to >> recognize that. > > > Okay, thanks for the insults. I suggest you do some research. Your behaviour is insulting as well. Almost as if you didn't do research on the numerous people whose assessments you are continually dismissing. Swap "non-tech" for "bitcoin non-experts", if you like. It's admittedly more accurate. My point remains the same. >> > I've never heard customers say "no thanks" to better scalability except >> > in Bitcoin. >> >> Bitcoin is not a business and does not have customers. It has users, >> many of which don't primarily value it because of super low >> transactions fees, but because of it's censorship resistance. Because >> of the fact that no single entity or group has full control over it. >> This includes DCG & friends. > > > I've never heard users say "no thanks" to better scalability except in > Bitcoin. >> >> >> Changes to bitcoin must be argued for. All concerns need to be >> addressed. If we start making backroom deals to get stuff in and let >> certain groups hold things like SegWit hostage to successfully get >> what they want but can't properly argue for, I'd consider this >> experiment failed. > > > You have failed to make any technical arguments here. This has all been > done, and after fervent debate, the decisions have been made. Looks like I didn't get the memo. > At this point, the onus is on you to provide technical arguments against > segwit2x. While you have provided a full course dinner of insults to me and > everyone else here, you've failed to state even one single technical > argument against segwit2x. If telling it how it is insults you, you may want to reevaluate your position. But I'll stop here. I acknowledge that the "Why?" is considered off-topic here. I also agree that my hostile stance towards what I perceive as an attack isn't really helping here. My apologies. This will sort itself out in the coming weeks anyway. >> > Today, Bitcoin is small potatoes. Want to make it really soar? Make it >> > available to everyone. >> >> We owe it to ourselves to do it properly. > > > Again, give me a technical argument. > > > Mike > > > > > >> >> >> > >> > Best, >> > Mike >> > >> > >> > On Mon, Oct 9, 2017 at 1:46 AM, Marcel Jamin wrote: >> >> >> >> On 9 October 2017 at 05:46, Mike Belshe via Bitcoin-segwit2x >> >> wrote: >> >> >> >> > BitGo serves its customers; we'll handle both chains. >> >> > I still hope everyone decides to vote for bigger blocks - its taken a >> >> > long >> >> > time to get here, and we have a great opportunity! >> >> >> >> The block limit effectively doubled recently. You say that's because >> >> of the NYA, others say it's because of the UASF ultimatum. Personally >> >> I believe the pro-hardfork side saw a chance to get their pound of >> >> flesh with the NYA and BIP91 caught them by surprise. But the UASF >> >> deadline provided the pressure. >> >> >> >> In any case, it already doubled and you want to double it *again*. >> >> >> >> > No reason to support two chains except pride. >> >> >> >> The new chain will be run by a forked off client maintained by a new >> >> and much smaller set of developers willing to give in to business (and >> >> presumably government) pressure. >> >> >> >> The original chain will keep the most if not all of the developer >> >> talent that helped bitcoin flourish over the past years and follow a >> >> more rational and less political approach to decision making. >> >> >> >> I see plenty of reason to support the original chain and can't fathom >> >> how anyone (except some CEOs perhaps) would value the former higher >> >> than the latter. Early results on Bitfinex tend to agree with me here. >> >> This valuation will be an issue for you and the mining support you >> >> currently think you have. Understand that hashpower is a value add, >> >> not the core value proposition. Even with 1000x the hashpower, there's >> >> nothing secure about a corporately run version of bitcoin. >> >> >> >> >> >> - Marcel >> >> >> >> >> >> > >> >> > Mike >> >> > >> >> > >> >> > On Sun, Oct 8, 2017 at 8:43 PM, Chris Stewart >> >> > wrote: >> >> >> >> >> >> >No. >> >> >> >> >> >> Ok. Thanks for the candid answer Mike. I look forward to an official >> >> >> update from bitgo of how they will handle this chain split wrt to >> >> >> bitcoin >> >> >> and segwit2x. >> >> >> >> >> >> -Chris >> >> >> >> >> >> On Sun, Oct 8, 2017 at 10:38 PM, Mike Belshe wrote: >> >> >>> >> >> >>> >> >> >>> >> >> >>> On Sun, Oct 8, 2017 at 5:56 PM, Chris Stewart via Bitcoin-segwit2x >> >> >>> wrote: >> >> >>>> >> >> >>>> So just so this is clear to the rest of the world, Segwit2x >> >> >>>> believes >> >> >>>> there will be no chain split? >> >> >>> >> >> >>> >> >> >>> No. >> >> >>> >> >> >>> Although the design goal was to not create a split, that doesn't >> >> >>> mean >> >> >>> that there won't be one. Since you can never get 100.000% >> >> >>> agreement, I >> >> >>> suppose you could say that means there must be a split - the >> >> >>> question >> >> >>> is >> >> >>> just how big. >> >> >>> >> >> >>> From the beginning, the segwit2x crew tried to garner as much >> >> >>> support >> >> >>> as >> >> >>> possible and make the code as simple and unobtrusive as possible. >> >> >>> They >> >> >>> certainly accomplished a lot - getting more miner support than ever >> >> >>> in >> >> >>> history, and getting segwit itself activated. With regard to the >> >> >>> 2MB >> >> >>> upgrade, it does seem that many are against it. But if you look at >> >> >>> the node >> >> >>> counts of SPV and full nodes, its easy to see that this group is >> >> >>> incredibly >> >> >>> small - likely 0.5% or less of all deployed wallets. >> >> >>> >> >> >>> On the other hand, adding "replay protection" and orphaning the SPV >> >> >>> wallets would clearly create a massive chain split. >> >> >>> >> >> >>> Mike >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>>> >> >> >>>> >> >> >>>> -Chris >> >> >>>> >> >> >>>> On Sun, Oct 8, 2017 at 5:57 PM, bitPico >> >> >>>> wrote: >> >> >>>>> >> >> >>>>> https://blockchain.info/charts/nya-support >> >> >>>>> >> >> >>>>> ~95-96% >> >> >>>>> >> >> >>>>> Do the math on how long it would take to solve a 1x (deprecated) >> >> >>>>> block >> >> >>>>> with only 4-5% network hash power. >> >> >>>>> >> >> >>>>> There is no HACK in place to drop the difficulty either so it?s a >> >> >>>>> dead >> >> >>>>> blockchain. :-) >> >> >>>>> >> >> >>>>> On Oct 8, 2017, at 6:46 PM, Chris Stewart via Bitcoin-segwit2x >> >> >>>>> wrote: >> >> >>>>> >> >> >>>>> So just to be clear, segwit2x no longer believes there will not >> >> >>>>> be a >> >> >>>>> chain split come November? >> >> >>>>> >> >> >>>>> -Chris >> >> >>>>> >> >> >>>>> >> >> >>>> >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> Bitcoin-segwit2x mailing list >> >> >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> >>>> >> >> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >>>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> >> >> >>> Mike Belshe >> >> >>> CEO, BitGo, Inc >> >> >>> 408-718-6885 >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > >> >> > Mike Belshe >> >> > CEO, BitGo, Inc >> >> > 408-718-6885 >> >> > >> >> > >> >> > _______________________________________________ >> >> > Bitcoin-segwit2x mailing list >> >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > >> > >> > >> > >> > >> > -- >> > >> > Mike Belshe >> > CEO, BitGo, Inc >> > 408-718-6885 > > > > > -- > > Mike Belshe > CEO, BitGo, Inc > 408-718-6885 From bitpico at icloud.com Mon Oct 9 20:09:02 2017 From: bitpico at icloud.com (bitPico) Date: Mon, 09 Oct 2017 16:09:02 -0400 Subject: [Bitcoin-segwit2x] Bitcoin Protocol Change Specifications In-Reply-To: References: Message-ID: <4135E113-4CE3-4638-821F-722590400484@icloud.com> Thanks Jeff! Good to see other Bitcoin developers understand the IETF process and how non-chaotic it is. Bitcoin has been plagued since its inception with a basically nonexistent development process. Good to see something that other implementors can follow and participate in. > On Oct 9, 2017, at 1:19 PM, Jeff Garzik via Bitcoin-segwit2x wrote: > > Introduction > ---------------------- > A familiar claim is that specifications for segwit2x do not exist, or segwit2x is "unspecified." This was false (link , link ) -- but it is a fair criticism that you have to google for them, and that shouldn't be the case. > > Specifications are also an issue in our wider community. To make it easier for both segwit2x and post-segwit2x development, there is a repository and simple process for Protocol Change Specifications (PCS) at https://github.com/btc1/specifications > > The process > ------------------------- > 1) Create a specification, stored as drafts/PCS-$username-$featurename format. > > 2) When code exists, is production ready and may potentially activate, move the specification to PCS/PCS-$year-$number-$featurename > > Engineers will be familiar with an IETF-like process. > > It is important for non-engineers to understand creating a specification does not mean a change is accepted on the network - that's outside anybody's control. The goal is to document what changes are live, or may go live. > > Current contents > ------------------------------- > The first few documents are the tx-size PCS and a clone of Sergio's segwit2x BIP into the PCS repo. > > 1) tx-size: tl;dr Goal is to state "tx limits don't change, even as block size increases" - tx limits are frozen for wallet compatibility. > > 2) segwit2x: Document SegWit + 2M multi-phase upgrade. > > This will also be where the replay protection proposal would be documented. > > > Who is welcome? > ---------------------------------- > > The wider community needs to open the innovative process to more developers. We would welcome and encourage Bitcoin and Bitcoin-compatible developers to contribute specifications: Bitcoin, Bitcoin Cash, Litecoin, Zcash, Bitcoin-compatible Drivechain, etc. > > The current BIP process and the overall toxic environment do not create welcoming, pro-developer outcomes where we all work together to create the best technology possible. Let's change that. > > > What are the goals? > --------------------------------------- > > 1. Shared innovation: It is way too early in the crypto game for infighting, or innovation gatekeeping by a small clique. We need to be sharing innovations across teams and chains, working together, beta testing with real money on litecoin or bitcoin cash or a sidechain, then adding that feature to bitcoin more conservatively (or not at all, if RM testing shows flaws). This was the flight path of SegWit (litecoin RM testing first) and now block size increase (Bitcoin Cash RM testing first). > > The best way to share innovation is working together on common specifications and best practices across chains. > > "Way back" in 2010, many of us simply assumed that bitcoin governance and upgradability would allow bitcoin to rapidly digest the latest innovations such as zero-knowledge proofs. This has not happened. > > > 2. Increase focus on specification - push back on "the code is the spec" mentality. Work towards a multi-implementation network. > > > 3. Solution sharing. Sharing of bug fixes (vs. features, #1, above). > > Real world example - A performance problem in bitcoin-derived zcash, found & fixed by zcash team, can be backported to bitcoin and other bitcoin clones. > > Most of these codebases are derived from Bitcoin, and benefit from sharing fixes. > > -- > Jeff Garzik > CEO and Co Founder > Bloq, Inc. > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at bitgo.com Mon Oct 9 20:27:05 2017 From: mike at bitgo.com (Mike Belshe) Date: Mon, 9 Oct 2017 13:27:05 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: Thanks for the lengthy reply. Your argument can go both ways; why not support this 2mb block size increase? The risk has already been mitigated - miners will adopt it, businesses will support it, and its compatible with 99.5% of existing wallets. Now, if the core team would start trying to help it work, instead of fighting it for pride and emotional reasons, we'd even have all the developer support behind it.... There are no technical arguments remaining against it - just lengthy prose about misunderstandings and what not. You imply that planning for growth/scalability has a correlated risk of destabilization that accompanies it. If we took that as our guiding principle, we wouldn't implement segwit either. Sure, segwit is opt-in at the user level, but its not opt-in at the chain level - we all are dependent on it working properly or the chain which we share breaks for all of us. The 2x part of Segwit2x is, by any measure, a simpler technical change. I would never say that changes carry no risk, but as far as risk goes, this one is really small. It's a good opportunity now to just move to 2mb blocks, and there are literally no technical objections left. Mike On Mon, Oct 9, 2017 at 9:58 AM, hubert maslin via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Hello Mike, I understand that you're meaning well and want, as we all do, > bitcoin to succeed over long term, and by reading your messages on this > thread I've once again noticed that the current rift within the Bitcoin > community actually springs from a few disagreements that have more to do > with culture and process rather than with long term goals. I'm going to > talk about those disagreements and hopefully state the "pro > decentralisation" position in a way that's conducive to intelligent debate > and perhaps, ultimate agreement. > > We want to bring Bitcoin to more users because it has unique features and > qualities (namely permissionless-ness, resistance to tx censorship, > resistance to inflation, pseudonymity) that the existing financial system > doesn't offer. The presence of these features is contrary to the interests > of many powerful entities (the legacy banking system, governments and their > surveillance agencies) and only survive thanks to Bitcoin's > decentralisation and absence of centralised points of failure. Being > willing to sacrifice or endanger Bitcoin's decentralisation to achieve > scaling isn't wise or forward thinking, and is completely self-defeating. > What's the point of on-boarding an ever greater number of users if you run > the risk of weakening those features and give those users the same > experience than current centralised paiement systems offer, e.g. tx > censorship, vulnerability to inflation, and government surveillance? This > would be a nonsensical and unproductive thing to do. > > Doing this would be all the more absurd that we now know (as we have since > 2015) that, before increasing base block size, we can greatly increase > throughput through more efficient of block space (with Segwit and, in the > near future, with MAST, Schnorr signatures and signatures aggregation) and > more importantly, with second layer technologies such as the Lightning > Network or sidechains. These technologies are under rapid development, and > will soon alleviate scaling. > > Presenting the scaling debate as a dichotomy between "onboard users fast > and break things" and "let's for ever stay a store of value for rich > people" is a mistake, because we know we can already greatly improve > scaling, within the next few months and years. Was scaling slower than > anticipated, we should err on the side of caution, and not give our > potential adversaries any lever that they might pull to weaken those > features. > > And this is why this scheduled hard fork worries me. Regardless of the > blockchain bloating issue, changing consensus rules without wide community > consensus - and in particular without the consensus of the community > members that value decentralisation and privacy the most - is precisely > such a lever for governments or other antagonists to pull. > It would set an extremely bad precedent. The particulars of this fork - > the fact that it doesn't have replay protection, that it lays a claim on > the Bitcoin brand, that it relies on the imperfect security models of SPV > wallets to make them follow new consensus rules - make things worse. > > if this fork is successful and the entire community shifts to the S2X > chain (which, barring a prolonged 51% attack on the original chain, seems > extremely unlikely to me), this would signals to external actors that > consensus rules can be changed by exercising the right pressure on the > right companies - and we're literally talking of a dozen mining pools and a > dozen major paiement processors and exchanges, spread in only a few > jurisdictions. This would cast doubt on the entire ability of > cryptocurrencies to remain decentralised and act as censorship-resistant > medium of exchange and inflation-resistant store of value. Bitcoin's sole > comparative advantage over centralised systems would vanish. > > Even if this fork wasn't a base block size doubling but a simple, symbolic > increase of one byte to base block size, it would still be a bad thing, > because it would show that consensus rules - and therefore the very nature > of the currency people use - can be changed by external actors. To me and > to many other people, this debate isn't about block size anymore: it's > about the survivability of Bitcoin as a decentralised system. The Bitcoin > community should be as amorphous and resistant to change as possible - even > to more technically sound changes like Segwit, and even when these changes > come from competent devs with a solid track record of defending > decentralisation and privacy. > > Just because only a few thousands or dozens of thousands of early users > and cypherpunks out of a dozen million of users disagree with this fork > doesn't mean we can be ignored: Bitcoin rose to its current popularity (and > value) because we invested our time, our hopes and our money in it, and > millions of politically unresponsive BitPay or Coinbase customers will not > make up for our absence on a centralised chain. > > Claiming that Segwit2X has consensus with the now standard line "those who > oppose it are only a few thousands, while NYA signatories have millions of > customers" is akin to the NSA claiming that a majority of citizens endorses > surveillance, "because only a few thousands nerds care about it". Claiming > the silence of a majority of stakeholders as a tacit endorsement of some > policy is a dangerous (and I would add immoral) thing to do, and is what > has led to the creation of the centralised institutions that Bitcoin aims > at replacing. > > Bitcoin is a formidable opportunity to bring greater monetary, economic > and political freedom to all humans, and the single best hope of > freedom-loving persons in this otherwise authoritarian and freedom-hating > century. Regardless of whatever understanding or sympathy we may have for > you and other NYA signatories, we who care about those things can not > accept cooptation by companies who effectively are centralised points of > failure at the mercy of governments. > > If I could sum up my position (and the position of many users preoccupied > with decentralisation), it would be: "let us scale wisely, without making > short-term compromises that would weaken Bitcoin's unique features". Merely > increasing base block size as soon as we lack space would be akin to > kicking the can down the road to serfdom. And changing consensus rules at a > whim - or worse, engaging in a 51% attack to coerce the community into > following the new rules - would get us there in no time. > > And to respond to one of your points, Mike, wishing for both chains to > survive is certainly not about "pride": it's about giving a durable, > decentralised consensus system to the world, a system that can't be > coopted, coerced or censored. > > Mike, if you have any question or wish to continue this chat privately > feel free to respond directly to this email. I feel that the differences > between our respective camps are born out of cultural differences and > absurd misunderstandings, and magnified by our good ol' tribal instincts; > there is no reason why we should go through a messy divorce when we all > agree on making Bitcoin the world's sole currency, used for both small > purchases and storing large amount of values. This is Bitcoin's destiny, > and our squabbles are petty in comparison. > > Cheers. > Hubert > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- *Mike Belshe* *CEO, BitGo, Inc*408-718-6885 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Tue Oct 10 01:52:46 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Tue, 10 Oct 2017 03:52:46 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: On 9 October 2017 at 22:27, Mike Belshe via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Thanks for the lengthy reply. Your argument can go both ways; why not > support this 2mb block size increase? The risk has already been mitigated > - miners will adopt it, businesses will support it, and its compatible with > 99.5% of existing wallets. Now, if the core team would start trying to help > it work, instead of fighting it for pride and emotional reasons, we'd even > have all the developer support behind it.... There are no technical > arguments remaining against it - just lengthy prose about misunderstandings > and what not. > > You imply that planning for growth/scalability has a correlated risk of > destabilization that accompanies it. If we took that as our guiding > principle, we wouldn't implement segwit either. Sure, segwit is opt-in at > the user level, but its not opt-in at the chain level - we all are > dependent on it working properly or the chain which we share breaks for all > of us. The 2x part of Segwit2x is, by any measure, a simpler technical > change. I would never say that changes carry no risk, but as far as risk > goes, this one is really small. > > It's a good opportunity now to just move to 2mb blocks, and there are > literally no technical objections left. > Thanks for the insight There are technical arguments surrounding the argument of increasing the block size from "1MB" to "2MB", as such. These, imho, were well articulated by adam back at in his talk this weekend at the hcpp hackers congress [1]. I did raise a question on this topic at th end, We can scale highly if we used a central mint to solve double spend. Somewhere between 2 nodes and billions of nodes lies a sweet spot that offers the utility of trade, in combination with the defense of corruptibility. I think the consensus in core is to increase block size in a practical way with storage (ie moore's law). This whole problem is a timing question (assuming we stick with proof of work) and it also involves social issues. Why dont we just agree the expert consensus is to increase capacity, but that the timeline for that is not yet agreed. Heavy handed techniques are likely to be counter productive, when essentially most parties are in agreement. [1] https://www.youtube.com/watch?v=mmSuxqaKR2U > > Mike > > > > > On Mon, Oct 9, 2017 at 9:58 AM, hubert maslin via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Hello Mike, I understand that you're meaning well and want, as we all do, >> bitcoin to succeed over long term, and by reading your messages on this >> thread I've once again noticed that the current rift within the Bitcoin >> community actually springs from a few disagreements that have more to do >> with culture and process rather than with long term goals. I'm going to >> talk about those disagreements and hopefully state the "pro >> decentralisation" position in a way that's conducive to intelligent debate >> and perhaps, ultimate agreement. >> >> We want to bring Bitcoin to more users because it has unique features and >> qualities (namely permissionless-ness, resistance to tx censorship, >> resistance to inflation, pseudonymity) that the existing financial system >> doesn't offer. The presence of these features is contrary to the interests >> of many powerful entities (the legacy banking system, governments and their >> surveillance agencies) and only survive thanks to Bitcoin's >> decentralisation and absence of centralised points of failure. Being >> willing to sacrifice or endanger Bitcoin's decentralisation to achieve >> scaling isn't wise or forward thinking, and is completely self-defeating. >> What's the point of on-boarding an ever greater number of users if you run >> the risk of weakening those features and give those users the same >> experience than current centralised paiement systems offer, e.g. tx >> censorship, vulnerability to inflation, and government surveillance? This >> would be a nonsensical and unproductive thing to do. >> >> Doing this would be all the more absurd that we now know (as we have >> since 2015) that, before increasing base block size, we can greatly >> increase throughput through more efficient of block space (with Segwit and, >> in the near future, with MAST, Schnorr signatures and signatures >> aggregation) and more importantly, with second layer technologies such as >> the Lightning Network or sidechains. These technologies are under rapid >> development, and will soon alleviate scaling. >> >> Presenting the scaling debate as a dichotomy between "onboard users fast >> and break things" and "let's for ever stay a store of value for rich >> people" is a mistake, because we know we can already greatly improve >> scaling, within the next few months and years. Was scaling slower than >> anticipated, we should err on the side of caution, and not give our >> potential adversaries any lever that they might pull to weaken those >> features. >> >> And this is why this scheduled hard fork worries me. Regardless of the >> blockchain bloating issue, changing consensus rules without wide community >> consensus - and in particular without the consensus of the community >> members that value decentralisation and privacy the most - is precisely >> such a lever for governments or other antagonists to pull. >> It would set an extremely bad precedent. The particulars of this fork - >> the fact that it doesn't have replay protection, that it lays a claim on >> the Bitcoin brand, that it relies on the imperfect security models of SPV >> wallets to make them follow new consensus rules - make things worse. >> >> if this fork is successful and the entire community shifts to the S2X >> chain (which, barring a prolonged 51% attack on the original chain, seems >> extremely unlikely to me), this would signals to external actors that >> consensus rules can be changed by exercising the right pressure on the >> right companies - and we're literally talking of a dozen mining pools and a >> dozen major paiement processors and exchanges, spread in only a few >> jurisdictions. This would cast doubt on the entire ability of >> cryptocurrencies to remain decentralised and act as censorship-resistant >> medium of exchange and inflation-resistant store of value. Bitcoin's sole >> comparative advantage over centralised systems would vanish. >> >> Even if this fork wasn't a base block size doubling but a simple, >> symbolic increase of one byte to base block size, it would still be a bad >> thing, because it would show that consensus rules - and therefore the very >> nature of the currency people use - can be changed by external actors. To >> me and to many other people, this debate isn't about block size anymore: >> it's about the survivability of Bitcoin as a decentralised system. The >> Bitcoin community should be as amorphous and resistant to change as >> possible - even to more technically sound changes like Segwit, and even >> when these changes come from competent devs with a solid track record of >> defending decentralisation and privacy. >> >> Just because only a few thousands or dozens of thousands of early users >> and cypherpunks out of a dozen million of users disagree with this fork >> doesn't mean we can be ignored: Bitcoin rose to its current popularity (and >> value) because we invested our time, our hopes and our money in it, and >> millions of politically unresponsive BitPay or Coinbase customers will not >> make up for our absence on a centralised chain. >> >> Claiming that Segwit2X has consensus with the now standard line "those >> who oppose it are only a few thousands, while NYA signatories have millions >> of customers" is akin to the NSA claiming that a majority of citizens >> endorses surveillance, "because only a few thousands nerds care about it". >> Claiming the silence of a majority of stakeholders as a tacit endorsement >> of some policy is a dangerous (and I would add immoral) thing to do, and is >> what has led to the creation of the centralised institutions that Bitcoin >> aims at replacing. >> >> Bitcoin is a formidable opportunity to bring greater monetary, economic >> and political freedom to all humans, and the single best hope of >> freedom-loving persons in this otherwise authoritarian and freedom-hating >> century. Regardless of whatever understanding or sympathy we may have for >> you and other NYA signatories, we who care about those things can not >> accept cooptation by companies who effectively are centralised points of >> failure at the mercy of governments. >> >> If I could sum up my position (and the position of many users preoccupied >> with decentralisation), it would be: "let us scale wisely, without making >> short-term compromises that would weaken Bitcoin's unique features". Merely >> increasing base block size as soon as we lack space would be akin to >> kicking the can down the road to serfdom. And changing consensus rules at a >> whim - or worse, engaging in a 51% attack to coerce the community into >> following the new rules - would get us there in no time. >> >> And to respond to one of your points, Mike, wishing for both chains to >> survive is certainly not about "pride": it's about giving a durable, >> decentralised consensus system to the world, a system that can't be >> coopted, coerced or censored. >> >> Mike, if you have any question or wish to continue this chat privately >> feel free to respond directly to this email. I feel that the differences >> between our respective camps are born out of cultural differences and >> absurd misunderstandings, and magnified by our good ol' tribal instincts; >> there is no reason why we should go through a messy divorce when we all >> agree on making Bitcoin the world's sole currency, used for both small >> purchases and storing large amount of values. This is Bitcoin's destiny, >> and our squabbles are petty in comparison. >> >> Cheers. >> Hubert >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > > -- > > > *Mike Belshe* > *CEO, BitGo, Inc*408-718-6885 <%28408%29%20718-6885> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaredr26 at gmail.com Tue Oct 10 02:36:22 2017 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Mon, 9 Oct 2017 19:36:22 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: > We can scale highly if we used a central mint to solve double spend. The implication of this is fundamentally not true. Bitcoin can scale hundreds of times past where we are today without any major risks or impacts whatsoever. > Somewhere between 2 nodes and billions of nodes lies a sweet spot that offers the utility of trade, in combination with the defense of corruptibility. The number of fullnodes goes up as transaction volume goes up: http://snap.stanford.edu/class/cs224w-2014/projects2014/cs224w-27-final.pdf > Somewhere between 2 nodes and billions of nodes lies a sweet spot that offers the utility of trade, in combination with the defense of corruptibility. Do you know what it is you are arguing in favor of? Running a fullnode can be done for less than $4.17 a month: https://www.reddit.com/r/Bitcoin/comments/6yopwt/run_a_bitcoin_full_node_for_50_a_year/ It actually can be done for even less than THAT. You're literally arguing the difference between $4.17 a month and $8 a month. Meanwhile, the average transaction fee paid 2 days ago was $2.15, PER TRANSACTION. If someone sends literally 2 transactions a month, they are now paying more just to use Bitcoin than it costs to run a fullnode. That's pointless. Fullnode costs actually scale remarkably well. We would have to scale hundreds of times above where we are today before we begin to have problems regarding fullnodes -and probably not even then due to the expanded ecosystem and adoption. > Why dont we just agree the expert consensus is to increase capacity, but that the timeline for that is not yet agreed. These "experts" have not provided any math to back up their claims, and refuse to debate the issue when challenged. Why does it matter if 5% of the fullnodes we have in operation shut down because of rising costs? How many fullnodes do we need? How do we know when we have too few nodes and the network is in danger? These are the questions that should be asked and answered to justify blocking the growth of the entire system. Instead of answering, we get down to fearmongering. "If you don't run a fullnode, the government can control Bitcoin!" and "If you run a fullnode in a datacenter, that's not using Bitcoin!" That line of thinking is ridiculous. If we're going to hold back the entire crypto ecosystem, there needs to be a really good reason for it, and it needs to be discussed **thoroughly** with numbers and risk evaluations of the different options. Answer me this, or get the answer from your experts. If we were willing to have pruned fullnode costs be $50 per month, how far could Bitcoin scale? The answer is pretty amazing. Jared On Mon, Oct 9, 2017 at 6:52 PM, Melvin Carvalho via Bitcoin-segwit2x wrote: > > > On 9 October 2017 at 22:27, Mike Belshe via Bitcoin-segwit2x > wrote: >> >> Thanks for the lengthy reply. Your argument can go both ways; why not >> support this 2mb block size increase? The risk has already been mitigated - >> miners will adopt it, businesses will support it, and its compatible with >> 99.5% of existing wallets. Now, if the core team would start trying to help >> it work, instead of fighting it for pride and emotional reasons, we'd even >> have all the developer support behind it.... There are no technical >> arguments remaining against it - just lengthy prose about misunderstandings >> and what not. >> >> You imply that planning for growth/scalability has a correlated risk of >> destabilization that accompanies it. If we took that as our guiding >> principle, we wouldn't implement segwit either. Sure, segwit is opt-in at >> the user level, but its not opt-in at the chain level - we all are dependent >> on it working properly or the chain which we share breaks for all of us. The >> 2x part of Segwit2x is, by any measure, a simpler technical change. I >> would never say that changes carry no risk, but as far as risk goes, this >> one is really small. >> >> It's a good opportunity now to just move to 2mb blocks, and there are >> literally no technical objections left. > > > Thanks for the insight > > There are technical arguments surrounding the argument of increasing the > block size from "1MB" to "2MB", as such. > > These, imho, were well articulated by adam back at in his talk this weekend > at the hcpp hackers congress [1]. I did raise a question on this topic at > th end, > > We can scale highly if we used a central mint to solve double spend. > > Somewhere between 2 nodes and billions of nodes lies a sweet spot that > offers the utility of trade, in combination with the defense of > corruptibility. > > I think the consensus in core is to increase block size in a practical way > with storage (ie moore's law). > > This whole problem is a timing question (assuming we stick with proof of > work) and it also involves social issues. > > Why dont we just agree the expert consensus is to increase capacity, but > that the timeline for that is not yet agreed. > > Heavy handed techniques are likely to be counter productive, when > essentially most parties are in agreement. > > [1] https://www.youtube.com/watch?v=mmSuxqaKR2U > >> >> >> Mike >> >> >> >> >> On Mon, Oct 9, 2017 at 9:58 AM, hubert maslin via Bitcoin-segwit2x >> wrote: >>> >>> Hello Mike, I understand that you're meaning well and want, as we all do, >>> bitcoin to succeed over long term, and by reading your messages on this >>> thread I've once again noticed that the current rift within the Bitcoin >>> community actually springs from a few disagreements that have more to do >>> with culture and process rather than with long term goals. I'm going to talk >>> about those disagreements and hopefully state the "pro decentralisation" >>> position in a way that's conducive to intelligent debate and perhaps, >>> ultimate agreement. >>> >>> We want to bring Bitcoin to more users because it has unique features and >>> qualities (namely permissionless-ness, resistance to tx censorship, >>> resistance to inflation, pseudonymity) that the existing financial system >>> doesn't offer. The presence of these features is contrary to the interests >>> of many powerful entities (the legacy banking system, governments and their >>> surveillance agencies) and only survive thanks to Bitcoin's decentralisation >>> and absence of centralised points of failure. Being willing to sacrifice or >>> endanger Bitcoin's decentralisation to achieve scaling isn't wise or forward >>> thinking, and is completely self-defeating. What's the point of on-boarding >>> an ever greater number of users if you run the risk of weakening those >>> features and give those users the same experience than current centralised >>> paiement systems offer, e.g. tx censorship, vulnerability to inflation, and >>> government surveillance? This would be a nonsensical and unproductive thing >>> to do. >>> >>> Doing this would be all the more absurd that we now know (as we have >>> since 2015) that, before increasing base block size, we can greatly increase >>> throughput through more efficient of block space (with Segwit and, in the >>> near future, with MAST, Schnorr signatures and signatures aggregation) and >>> more importantly, with second layer technologies such as the Lightning >>> Network or sidechains. These technologies are under rapid development, and >>> will soon alleviate scaling. >>> >>> Presenting the scaling debate as a dichotomy between "onboard users fast >>> and break things" and "let's for ever stay a store of value for rich people" >>> is a mistake, because we know we can already greatly improve scaling, within >>> the next few months and years. Was scaling slower than anticipated, we >>> should err on the side of caution, and not give our potential adversaries >>> any lever that they might pull to weaken those features. >>> >>> And this is why this scheduled hard fork worries me. Regardless of the >>> blockchain bloating issue, changing consensus rules without wide community >>> consensus - and in particular without the consensus of the community members >>> that value decentralisation and privacy the most - is precisely such a lever >>> for governments or other antagonists to pull. >>> It would set an extremely bad precedent. The particulars of this fork - >>> the fact that it doesn't have replay protection, that it lays a claim on the >>> Bitcoin brand, that it relies on the imperfect security models of SPV >>> wallets to make them follow new consensus rules - make things worse. >>> >>> if this fork is successful and the entire community shifts to the S2X >>> chain (which, barring a prolonged 51% attack on the original chain, seems >>> extremely unlikely to me), this would signals to external actors that >>> consensus rules can be changed by exercising the right pressure on the right >>> companies - and we're literally talking of a dozen mining pools and a dozen >>> major paiement processors and exchanges, spread in only a few jurisdictions. >>> This would cast doubt on the entire ability of cryptocurrencies to remain >>> decentralised and act as censorship-resistant medium of exchange and >>> inflation-resistant store of value. Bitcoin's sole comparative advantage >>> over centralised systems would vanish. >>> >>> Even if this fork wasn't a base block size doubling but a simple, >>> symbolic increase of one byte to base block size, it would still be a bad >>> thing, because it would show that consensus rules - and therefore the very >>> nature of the currency people use - can be changed by external actors. To me >>> and to many other people, this debate isn't about block size anymore: it's >>> about the survivability of Bitcoin as a decentralised system. The Bitcoin >>> community should be as amorphous and resistant to change as possible - even >>> to more technically sound changes like Segwit, and even when these changes >>> come from competent devs with a solid track record of defending >>> decentralisation and privacy. >>> >>> Just because only a few thousands or dozens of thousands of early users >>> and cypherpunks out of a dozen million of users disagree with this fork >>> doesn't mean we can be ignored: Bitcoin rose to its current popularity (and >>> value) because we invested our time, our hopes and our money in it, and >>> millions of politically unresponsive BitPay or Coinbase customers will not >>> make up for our absence on a centralised chain. >>> >>> Claiming that Segwit2X has consensus with the now standard line "those >>> who oppose it are only a few thousands, while NYA signatories have millions >>> of customers" is akin to the NSA claiming that a majority of citizens >>> endorses surveillance, "because only a few thousands nerds care about it". >>> Claiming the silence of a majority of stakeholders as a tacit endorsement of >>> some policy is a dangerous (and I would add immoral) thing to do, and is >>> what has led to the creation of the centralised institutions that Bitcoin >>> aims at replacing. >>> >>> Bitcoin is a formidable opportunity to bring greater monetary, economic >>> and political freedom to all humans, and the single best hope of >>> freedom-loving persons in this otherwise authoritarian and freedom-hating >>> century. Regardless of whatever understanding or sympathy we may have for >>> you and other NYA signatories, we who care about those things can not accept >>> cooptation by companies who effectively are centralised points of failure at >>> the mercy of governments. >>> >>> If I could sum up my position (and the position of many users preoccupied >>> with decentralisation), it would be: "let us scale wisely, without making >>> short-term compromises that would weaken Bitcoin's unique features". Merely >>> increasing base block size as soon as we lack space would be akin to kicking >>> the can down the road to serfdom. And changing consensus rules at a whim - >>> or worse, engaging in a 51% attack to coerce the community into following >>> the new rules - would get us there in no time. >>> >>> And to respond to one of your points, Mike, wishing for both chains to >>> survive is certainly not about "pride": it's about giving a durable, >>> decentralised consensus system to the world, a system that can't be coopted, >>> coerced or censored. >>> >>> Mike, if you have any question or wish to continue this chat privately >>> feel free to respond directly to this email. I feel that the differences >>> between our respective camps are born out of cultural differences and absurd >>> misunderstandings, and magnified by our good ol' tribal instincts; there is >>> no reason why we should go through a messy divorce when we all agree on >>> making Bitcoin the world's sole currency, used for both small purchases and >>> storing large amount of values. This is Bitcoin's destiny, and our squabbles >>> are petty in comparison. >>> >>> Cheers. >>> Hubert >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >> >> >> >> -- >> >> Mike Belshe >> CEO, BitGo, Inc >> 408-718-6885 >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From hubert.maslin at gmail.com Tue Oct 10 09:32:20 2017 From: hubert.maslin at gmail.com (hubert maslin) Date: Tue, 10 Oct 2017 11:32:20 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: I get your frustration that the ecosystem resists a lot to something that's a no-brainer upgrade for you, but this resistance is a feature, not a bug, and in my opinion Segwit2X was the wrong vehicle to achieve an upgrade of this kind from the beginning. Bitcoin is not an enterprise database that your supplier can upgrade in a week, it's a *shared* global decentralised ledger, it's an infrastructure used by millions (and hopefully billions in the future) of people who all have their own reasons to use it and their own preferences. It's to be expected by upgrading such a thing will be a long and contentious process. If you want the support of developers, investors and power users, you have to make this 2X base block size (now block weight) increase palatable to them, by asking them whether they might to see some other changes bundled with it, and also by having enough time to develop, test and deploy the fork (for example 6 months for development/testing and a year for deployment). Replay protection is also a must, so that those whose wishes haven't been fulfilled by the fork can easily stay on their chain, without feeling like they're marginalised, or held hostages. I know this isn't a psychology or anthropology mailing list, but I'd like to make a point about human nature, that explains why debates get so heated so easily. People don't like to back down to so much as the smallest slights or disrespect, because of the implicit assumption that such a retreat would only lead to greater agression or disrespect in the future - this is why violent conflicts often arise from seemingly benign squabbles. This assumption is literally built in us; it's a by-product of our evolution, because those humans who reacted to threats of agression instead of waiting for an actual agression to take place might have had better odds of survival. Suppose that we do as you wish and agree on this fork: what tells us that a year from now some other group of CEOs will not come up with a perfectly valid reason to implement address blacklisting at the protocol level, or change Bitcoin's inflation schedule? Having backed down to the November 2017 2X hard fork would make it harder for us to resist the ones to come. The fact that we mistrust people whose objectives and group membership differ from ours is a truth as fundamental as the fact that we breathe, eat or drink. To disarm this natural mistrust, the process that leads to the definition and implementation of the fork has to be as inclusive, egalitarian and open as possible, so that all voices can be heard. The process might actually matters even more than its own product - the fork design - because the process itself is an expression of the balance of economic power among the different stakeholders; and it would be dangerous to artificially sway this balance through manipulation, disinformation or outrage. You refer to the risk of the hard fork being small. But focusing on pure technical risks misses the point: the main risk of this fork (and the main reason why so many of us are opposed to it) is the fact that it opens the door to further contentious changes in the future. There's an element of recursion here - the fork is contentious because it sets a bad precedent of a contentious change having been made - and that's because the design process it stems from wasn't open and collaborative. You can't get together at a private meeting (from what I've understood, developers other than those closely affiliated to you weren't invited), agree among yourselves to redesign Bitcoin and expect other stakeholders to follow you. It's sad that Segwit2X chose that path, because many early adopters and investors are realistic and understand that a block weight increase will very likely be needed in the future, because even if we could get a large part of the bitcoin economy to use paiement channels, we would still have to have enough room to settle them. I'm afraid it's too late to call off the fork, as you've all already invested so much time and energy in it. I think (and hope) that the fork will fail, and that the B2X chain will never gain any significant economic value - precisely because it would be so vulnerable to arbitrary changes in consensus rules from external actors. In any case I hope that the next iterations of the scaling debate will be more open and collaborative, and see cool heads prevail. Cheers. Hubert 2017-10-09 22:27 GMT+02:00 Mike Belshe : > Thanks for the lengthy reply. Your argument can go both ways; why not > support this 2mb block size increase? The risk has already been mitigated > - miners will adopt it, businesses will support it, and its compatible with > 99.5% of existing wallets. Now, if the core team would start trying to help > it work, instead of fighting it for pride and emotional reasons, we'd even > have all the developer support behind it.... There are no technical > arguments remaining against it - just lengthy prose about misunderstandings > and what not. > > You imply that planning for growth/scalability has a correlated risk of > destabilization that accompanies it. If we took that as our guiding > principle, we wouldn't implement segwit either. Sure, segwit is opt-in at > the user level, but its not opt-in at the chain level - we all are > dependent on it working properly or the chain which we share breaks for all > of us. The 2x part of Segwit2x is, by any measure, a simpler technical > change. I would never say that changes carry no risk, but as far as risk > goes, this one is really small. > > It's a good opportunity now to just move to 2mb blocks, and there are > literally no technical objections left. > > Mike > > > > > On Mon, Oct 9, 2017 at 9:58 AM, hubert maslin via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Hello Mike, I understand that you're meaning well and want, as we all do, >> bitcoin to succeed over long term, and by reading your messages on this >> thread I've once again noticed that the current rift within the Bitcoin >> community actually springs from a few disagreements that have more to do >> with culture and process rather than with long term goals. I'm going to >> talk about those disagreements and hopefully state the "pro >> decentralisation" position in a way that's conducive to intelligent debate >> and perhaps, ultimate agreement. >> >> We want to bring Bitcoin to more users because it has unique features and >> qualities (namely permissionless-ness, resistance to tx censorship, >> resistance to inflation, pseudonymity) that the existing financial system >> doesn't offer. The presence of these features is contrary to the interests >> of many powerful entities (the legacy banking system, governments and their >> surveillance agencies) and only survive thanks to Bitcoin's >> decentralisation and absence of centralised points of failure. Being >> willing to sacrifice or endanger Bitcoin's decentralisation to achieve >> scaling isn't wise or forward thinking, and is completely self-defeating. >> What's the point of on-boarding an ever greater number of users if you run >> the risk of weakening those features and give those users the same >> experience than current centralised paiement systems offer, e.g. tx >> censorship, vulnerability to inflation, and government surveillance? This >> would be a nonsensical and unproductive thing to do. >> >> Doing this would be all the more absurd that we now know (as we have >> since 2015) that, before increasing base block size, we can greatly >> increase throughput through more efficient of block space (with Segwit and, >> in the near future, with MAST, Schnorr signatures and signatures >> aggregation) and more importantly, with second layer technologies such as >> the Lightning Network or sidechains. These technologies are under rapid >> development, and will soon alleviate scaling. >> >> Presenting the scaling debate as a dichotomy between "onboard users fast >> and break things" and "let's for ever stay a store of value for rich >> people" is a mistake, because we know we can already greatly improve >> scaling, within the next few months and years. Was scaling slower than >> anticipated, we should err on the side of caution, and not give our >> potential adversaries any lever that they might pull to weaken those >> features. >> >> And this is why this scheduled hard fork worries me. Regardless of the >> blockchain bloating issue, changing consensus rules without wide community >> consensus - and in particular without the consensus of the community >> members that value decentralisation and privacy the most - is precisely >> such a lever for governments or other antagonists to pull. >> It would set an extremely bad precedent. The particulars of this fork - >> the fact that it doesn't have replay protection, that it lays a claim on >> the Bitcoin brand, that it relies on the imperfect security models of SPV >> wallets to make them follow new consensus rules - make things worse. >> >> if this fork is successful and the entire community shifts to the S2X >> chain (which, barring a prolonged 51% attack on the original chain, seems >> extremely unlikely to me), this would signals to external actors that >> consensus rules can be changed by exercising the right pressure on the >> right companies - and we're literally talking of a dozen mining pools and a >> dozen major paiement processors and exchanges, spread in only a few >> jurisdictions. This would cast doubt on the entire ability of >> cryptocurrencies to remain decentralised and act as censorship-resistant >> medium of exchange and inflation-resistant store of value. Bitcoin's sole >> comparative advantage over centralised systems would vanish. >> >> Even if this fork wasn't a base block size doubling but a simple, >> symbolic increase of one byte to base block size, it would still be a bad >> thing, because it would show that consensus rules - and therefore the very >> nature of the currency people use - can be changed by external actors. To >> me and to many other people, this debate isn't about block size anymore: >> it's about the survivability of Bitcoin as a decentralised system. The >> Bitcoin community should be as amorphous and resistant to change as >> possible - even to more technically sound changes like Segwit, and even >> when these changes come from competent devs with a solid track record of >> defending decentralisation and privacy. >> >> Just because only a few thousands or dozens of thousands of early users >> and cypherpunks out of a dozen million of users disagree with this fork >> doesn't mean we can be ignored: Bitcoin rose to its current popularity (and >> value) because we invested our time, our hopes and our money in it, and >> millions of politically unresponsive BitPay or Coinbase customers will not >> make up for our absence on a centralised chain. >> >> Claiming that Segwit2X has consensus with the now standard line "those >> who oppose it are only a few thousands, while NYA signatories have millions >> of customers" is akin to the NSA claiming that a majority of citizens >> endorses surveillance, "because only a few thousands nerds care about it". >> Claiming the silence of a majority of stakeholders as a tacit endorsement >> of some policy is a dangerous (and I would add immoral) thing to do, and is >> what has led to the creation of the centralised institutions that Bitcoin >> aims at replacing. >> >> Bitcoin is a formidable opportunity to bring greater monetary, economic >> and political freedom to all humans, and the single best hope of >> freedom-loving persons in this otherwise authoritarian and freedom-hating >> century. Regardless of whatever understanding or sympathy we may have for >> you and other NYA signatories, we who care about those things can not >> accept cooptation by companies who effectively are centralised points of >> failure at the mercy of governments. >> >> If I could sum up my position (and the position of many users preoccupied >> with decentralisation), it would be: "let us scale wisely, without making >> short-term compromises that would weaken Bitcoin's unique features". Merely >> increasing base block size as soon as we lack space would be akin to >> kicking the can down the road to serfdom. And changing consensus rules at a >> whim - or worse, engaging in a 51% attack to coerce the community into >> following the new rules - would get us there in no time. >> >> And to respond to one of your points, Mike, wishing for both chains to >> survive is certainly not about "pride": it's about giving a durable, >> decentralised consensus system to the world, a system that can't be >> coopted, coerced or censored. >> >> Mike, if you have any question or wish to continue this chat privately >> feel free to respond directly to this email. I feel that the differences >> between our respective camps are born out of cultural differences and >> absurd misunderstandings, and magnified by our good ol' tribal instincts; >> there is no reason why we should go through a messy divorce when we all >> agree on making Bitcoin the world's sole currency, used for both small >> purchases and storing large amount of values. This is Bitcoin's destiny, >> and our squabbles are petty in comparison. >> >> Cheers. >> Hubert >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > > -- > > > *Mike Belshe* > *CEO, BitGo, Inc*408-718-6885 <(408)%20718-6885> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomz at freedommail.ch Tue Oct 10 09:50:54 2017 From: tomz at freedommail.ch (Tom Zander) Date: Tue, 10 Oct 2017 11:50:54 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: <1557932.jUTfu5DZ3s@strawberry> On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via Bitcoin-segwit2x wrote: > The Bitcoin Core process is quite unrelated to this question. Regardless > of which code they do or do not merge into their repositories, it is the > existing set of nodes with the existing set of software that is the > question. The vast majority of people use either SPV wallets or online wallets. They will just follow the longest chain. I?d like to point out that the only people that will have to upgrade are the people that run a Bitcoin Core node while they are not miners etc. Those individuals are doing it wrong anyway. Instead of badgering the SegWit-workgroup, I think a much higher rate of benefit can be reached by educating the people that run full nodes and explaining how they are not in actual fact helping the network. The simple fact is that if they didn?t run those nodes, this whole discussion would not exist. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel From barry at dcg.co Tue Oct 10 12:17:51 2017 From: barry at dcg.co (Barry Silbert) Date: Tue, 10 Oct 2017 12:17:51 +0000 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: Hi Hubert, To clarify, Core was invited. Alex Morcos was kind enough to confirm via Reddit: https://www.reddit.com/r/Bitcoin/comments/6d1r96/is_it_not_telling_that_the_core_devs_were_not/dhzc46v/?sh=f688cb33&st=J7CBGTHU https://www.reddit.com/r/Bitcoin/comments/6cwg98/barry_silbert_bitcoin_scaling_agreement/dhy4oeo/?sh=76d1d2d1&st=J7CBG00Q Barry Silbert Founder & CEO, Digital Currency Group www.DCG.co e: barry at DCG.co t: (212) 473-2408 | @BarrySilbert 636 Avenue of the Americas (Entrance on 19th St.) New York, NY 10011 From: bitcoin-segwit2x-bounces at lists.linuxfoundation.org [mailto:bitcoin-segwit2x-bounces at lists.linuxfoundation.org] On Behalf Of hubert maslin via Bitcoin-segwit2x Sent: Tuesday, October 10, 2017 5:32 AM To: BitGo - Mike Belshe Cc: bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] Strong 2-Way Replay Protection I get your frustration that the ecosystem resists a lot to something that's a no-brainer upgrade for you, but this resistance is a feature, not a bug, and in my opinion Segwit2X was the wrong vehicle to achieve an upgrade of this kind from the beginning. Bitcoin is not an enterprise database that your supplier can upgrade in a week, it's a *shared* global decentralised ledger, it's an infrastructure used by millions (and hopefully billions in the future) of people who all have their own reasons to use it and their own preferences. It's to be expected by upgrading such a thing will be a long and contentious process. If you want the support of developers, investors and power users, you have to make this 2X base block size (now block weight) increase palatable to them, by asking them whether they might to see some other changes bundled with it, and also by having enough time to develop, test and deploy the fork (for example 6 months for development/testing and a year for deployment). Replay protection is also a must, so that those whose wishes haven't been fulfilled by the fork can easily stay on their chain, without feeling like they're marginalised, or held hostages. I know this isn't a psychology or anthropology mailing list, but I'd like to make a point about human nature, that explains why debates get so heated so easily. People don't like to back down to so much as the smallest slights or disrespect, because of the implicit assumption that such a retreat would only lead to greater agression or disrespect in the future - this is why violent conflicts often arise from seemingly benign squabbles. This assumption is literally built in us; it's a by-product of our evolution, because those humans who reacted to threats of agression instead of waiting for an actual agression to take place might have had better odds of survival. Suppose that we do as you wish and agree on this fork: what tells us that a year from now some other group of CEOs will not come up with a perfectly valid reason to implement address blacklisting at the protocol level, or change Bitcoin's inflation schedule? Having backed down to the November 2017 2X hard fork would make it harder for us to resist the ones to come. The fact that we mistrust people whose objectives and group membership differ from ours is a truth as fundamental as the fact that we breathe, eat or drink. To disarm this natural mistrust, the process that leads to the definition and implementation of the fork has to be as inclusive, egalitarian and open as possible, so that all voices can be heard. The process might actually matters even more than its own product - the fork design - because the process itself is an expression of the balance of economic power among the different stakeholders; and it would be dangerous to artificially sway this balance through manipulation, disinformation or outrage. You refer to the risk of the hard fork being small. But focusing on pure technical risks misses the point: the main risk of this fork (and the main reason why so many of us are opposed to it) is the fact that it opens the door to further contentious changes in the future. There's an element of recursion here - the fork is contentious because it sets a bad precedent of a contentious change having been made - and that's because the design process it stems from wasn't open and collaborative. You can't get together at a private meeting (from what I've understood, developers other than those closely affiliated to you weren't invited), agree among yourselves to redesign Bitcoin and expect other stakeholders to follow you. It's sad that Segwit2X chose that path, because many early adopters and investors are realistic and understand that a block weight increase will very likely be needed in the future, because even if we could get a large part of the bitcoin economy to use paiement channels, we would still have to have enough room to settle them. I'm afraid it's too late to call off the fork, as you've all already invested so much time and energy in it. I think (and hope) that the fork will fail, and that the B2X chain will never gain any significant economic value - precisely because it would be so vulnerable to arbitrary changes in consensus rules from external actors. In any case I hope that the next iterations of the scaling debate will be more open and collaborative, and see cool heads prevail. Cheers. Hubert 2017-10-09 22:27 GMT+02:00 Mike Belshe >: Thanks for the lengthy reply. Your argument can go both ways; why not support this 2mb block size increase? The risk has already been mitigated - miners will adopt it, businesses will support it, and its compatible with 99.5% of existing wallets. Now, if the core team would start trying to help it work, instead of fighting it for pride and emotional reasons, we'd even have all the developer support behind it.... There are no technical arguments remaining against it - just lengthy prose about misunderstandings and what not. You imply that planning for growth/scalability has a correlated risk of destabilization that accompanies it. If we took that as our guiding principle, we wouldn't implement segwit either. Sure, segwit is opt-in at the user level, but its not opt-in at the chain level - we all are dependent on it working properly or the chain which we share breaks for all of us. The 2x part of Segwit2x is, by any measure, a simpler technical change. I would never say that changes carry no risk, but as far as risk goes, this one is really small. It's a good opportunity now to just move to 2mb blocks, and there are literally no technical objections left. Mike On Mon, Oct 9, 2017 at 9:58 AM, hubert maslin via Bitcoin-segwit2x > wrote: Hello Mike, I understand that you're meaning well and want, as we all do, bitcoin to succeed over long term, and by reading your messages on this thread I've once again noticed that the current rift within the Bitcoin community actually springs from a few disagreements that have more to do with culture and process rather than with long term goals. I'm going to talk about those disagreements and hopefully state the "pro decentralisation" position in a way that's conducive to intelligent debate and perhaps, ultimate agreement. We want to bring Bitcoin to more users because it has unique features and qualities (namely permissionless-ness, resistance to tx censorship, resistance to inflation, pseudonymity) that the existing financial system doesn't offer. The presence of these features is contrary to the interests of many powerful entities (the legacy banking system, governments and their surveillance agencies) and only survive thanks to Bitcoin's decentralisation and absence of centralised points of failure. Being willing to sacrifice or endanger Bitcoin's decentralisation to achieve scaling isn't wise or forward thinking, and is completely self-defeating. What's the point of on-boarding an ever greater number of users if you run the risk of weakening those features and give those users the same experience than current centralised paiement systems offer, e.g. tx censorship, vulnerability to inflation, and government surveillance? This would be a nonsensical and unproductive thing to do. Doing this would be all the more absurd that we now know (as we have since 2015) that, before increasing base block size, we can greatly increase throughput through more efficient of block space (with Segwit and, in the near future, with MAST, Schnorr signatures and signatures aggregation) and more importantly, with second layer technologies such as the Lightning Network or sidechains. These technologies are under rapid development, and will soon alleviate scaling. Presenting the scaling debate as a dichotomy between "onboard users fast and break things" and "let's for ever stay a store of value for rich people" is a mistake, because we know we can already greatly improve scaling, within the next few months and years. Was scaling slower than anticipated, we should err on the side of caution, and not give our potential adversaries any lever that they might pull to weaken those features. And this is why this scheduled hard fork worries me. Regardless of the blockchain bloating issue, changing consensus rules without wide community consensus - and in particular without the consensus of the community members that value decentralisation and privacy the most - is precisely such a lever for governments or other antagonists to pull. It would set an extremely bad precedent. The particulars of this fork - the fact that it doesn't have replay protection, that it lays a claim on the Bitcoin brand, that it relies on the imperfect security models of SPV wallets to make them follow new consensus rules - make things worse. if this fork is successful and the entire community shifts to the S2X chain (which, barring a prolonged 51% attack on the original chain, seems extremely unlikely to me), this would signals to external actors that consensus rules can be changed by exercising the right pressure on the right companies - and we're literally talking of a dozen mining pools and a dozen major paiement processors and exchanges, spread in only a few jurisdictions. This would cast doubt on the entire ability of cryptocurrencies to remain decentralised and act as censorship-resistant medium of exchange and inflation-resistant store of value. Bitcoin's sole comparative advantage over centralised systems would vanish. Even if this fork wasn't a base block size doubling but a simple, symbolic increase of one byte to base block size, it would still be a bad thing, because it would show that consensus rules - and therefore the very nature of the currency people use - can be changed by external actors. To me and to many other people, this debate isn't about block size anymore: it's about the survivability of Bitcoin as a decentralised system. The Bitcoin community should be as amorphous and resistant to change as possible - even to more technically sound changes like Segwit, and even when these changes come from competent devs with a solid track record of defending decentralisation and privacy. Just because only a few thousands or dozens of thousands of early users and cypherpunks out of a dozen million of users disagree with this fork doesn't mean we can be ignored: Bitcoin rose to its current popularity (and value) because we invested our time, our hopes and our money in it, and millions of politically unresponsive BitPay or Coinbase customers will not make up for our absence on a centralised chain. Claiming that Segwit2X has consensus with the now standard line "those who oppose it are only a few thousands, while NYA signatories have millions of customers" is akin to the NSA claiming that a majority of citizens endorses surveillance, "because only a few thousands nerds care about it". Claiming the silence of a majority of stakeholders as a tacit endorsement of some policy is a dangerous (and I would add immoral) thing to do, and is what has led to the creation of the centralised institutions that Bitcoin aims at replacing. Bitcoin is a formidable opportunity to bring greater monetary, economic and political freedom to all humans, and the single best hope of freedom-loving persons in this otherwise authoritarian and freedom-hating century. Regardless of whatever understanding or sympathy we may have for you and other NYA signatories, we who care about those things can not accept cooptation by companies who effectively are centralised points of failure at the mercy of governments. If I could sum up my position (and the position of many users preoccupied with decentralisation), it would be: "let us scale wisely, without making short-term compromises that would weaken Bitcoin's unique features". Merely increasing base block size as soon as we lack space would be akin to kicking the can down the road to serfdom. And changing consensus rules at a whim - or worse, engaging in a 51% attack to coerce the community into following the new rules - would get us there in no time. And to respond to one of your points, Mike, wishing for both chains to survive is certainly not about "pride": it's about giving a durable, decentralised consensus system to the world, a system that can't be coopted, coerced or censored. Mike, if you have any question or wish to continue this chat privately feel free to respond directly to this email. I feel that the differences between our respective camps are born out of cultural differences and absurd misunderstandings, and magnified by our good ol' tribal instincts; there is no reason why we should go through a messy divorce when we all agree on making Bitcoin the world's sole currency, used for both small purchases and storing large amount of values. This is Bitcoin's destiny, and our squabbles are petty in comparison. Cheers. Hubert _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -- Mike Belshe CEO, BitGo, Inc 408-718-6885 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel at jamin.net Tue Oct 10 13:33:00 2017 From: marcel at jamin.net (Marcel Jamin) Date: Tue, 10 Oct 2017 15:33:00 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: For visibility -- Gregory Maxwell's reply to Alex Morcos: > The message you relayed was > https://0bin.net/paste/T0xP9qKeBmLiOybE#bw8g7mxCLgO1d2Yp29nayYij3lUxv7AgYjBuxz1ynPB > which requested we endorse a specific prefabricated statement, "I/we > agree to immediately support the activation of Segregated Witness and > commit to effectuate a block size increase to 2MB within 12 months" > which had a long list of signers. This was on May 16th, after they'd > been circulating this stuff for weeks. > As you noted, the whole thing was wildly inappropriate and people would have > rejected attending if they were invited under its stated goals. But I don't > agree that we were meaningfully invited to collaborate either-- you don't send > a finished agreement with a long list of signers to someone whos opinion you > value--, and certainly not under a framework we wouldn't have seen as wildly > inappropriate. > Though sure, we at least had a theoretical short notice opportunity to > attend-- not to actually influence the result, but to add legitimacy to it, > "gee thanks". :) On 10 October 2017 at 14:17, Barry Silbert via Bitcoin-segwit2x wrote: > Hi Hubert, > > > > To clarify, Core was invited. Alex Morcos was kind enough to confirm via > Reddit: > > > > https://www.reddit.com/r/Bitcoin/comments/6d1r96/is_it_not_telling_that_the_core_devs_were_not/dhzc46v/?sh=f688cb33&st=J7CBGTHU > > https://www.reddit.com/r/Bitcoin/comments/6cwg98/barry_silbert_bitcoin_scaling_agreement/dhy4oeo/?sh=76d1d2d1&st=J7CBG00Q > > > > > > Barry Silbert > > Founder & CEO, Digital Currency Group > > www.DCG.co > > e: barry at DCG.co > > t: (212) 473-2408 | @BarrySilbert > > 636 Avenue of the Americas (Entrance on 19th St.) > New York, NY 10011 > > > > > > From: bitcoin-segwit2x-bounces at lists.linuxfoundation.org > [mailto:bitcoin-segwit2x-bounces at lists.linuxfoundation.org] On Behalf Of > hubert maslin via Bitcoin-segwit2x > Sent: Tuesday, October 10, 2017 5:32 AM > To: BitGo - Mike Belshe > Cc: bitcoin-segwit2x at lists.linuxfoundation.org > Subject: Re: [Bitcoin-segwit2x] Strong 2-Way Replay Protection > > > > I get your frustration that the ecosystem resists a lot to something that's > a no-brainer upgrade for you, but this resistance is a feature, not a bug, > and in my opinion Segwit2X was the wrong vehicle to achieve an upgrade of > this kind from the beginning. > > > > Bitcoin is not an enterprise database that your supplier can upgrade in a > week, it's a *shared* global decentralised ledger, it's an infrastructure > used by millions (and hopefully billions in the future) of people who all > have their own reasons to use it and their own preferences. It's to be > expected by upgrading such a thing will be a long and contentious process. > > > > If you want the support of developers, investors and power users, you have > to make this 2X base block size (now block weight) increase palatable to > them, by asking them whether they might to see some other changes bundled > with it, and also by having enough time to develop, test and deploy the fork > (for example 6 months for development/testing and a year for deployment). > Replay protection is also a must, so that those whose wishes haven't been > fulfilled by the fork can easily stay on their chain, without feeling like > they're marginalised, or held hostages. > > > > I know this isn't a psychology or anthropology mailing list, but I'd like to > make a point about human nature, that explains why debates get so heated so > easily. > > People don't like to back down to so much as the smallest slights or > disrespect, because of the implicit assumption that such a retreat would > only lead to greater agression or disrespect in the future - this is why > violent conflicts often arise from seemingly benign squabbles. This > assumption is literally built in us; it's a by-product of our evolution, > because those humans who reacted to threats of agression instead of waiting > for an actual agression to take place might have had better odds of > survival. Suppose that we do as you wish and agree on this fork: what tells > us that a year from now some other group of CEOs will not come up with a > perfectly valid reason to implement address blacklisting at the protocol > level, or change Bitcoin's inflation schedule? Having backed down to the > November 2017 2X hard fork would make it harder for us to resist the ones to > come. > > The fact that we mistrust people whose objectives and group membership > differ from ours is a truth as fundamental as the fact that we breathe, eat > or drink. To disarm this natural mistrust, the process that leads to the > definition and implementation of the fork has to be as inclusive, > egalitarian and open as possible, so that all voices can be heard. The > process might actually matters even more than its own product - the fork > design - because the process itself is an expression of the balance of > economic power among the different stakeholders; and it would be dangerous > to artificially sway this balance through manipulation, disinformation or > outrage. > > > > You refer to the risk of the hard fork being small. But focusing on pure > technical risks misses the point: the main risk of this fork (and the main > reason why so many of us are opposed to it) is the fact that it opens the > door to further contentious changes in the future. There's an element of > recursion here - the fork is contentious because it sets a bad precedent of > a contentious change having been made - and that's because the design > process it stems from wasn't open and collaborative. > > > > You can't get together at a private meeting (from what I've understood, > developers other than those closely affiliated to you weren't invited), > agree among yourselves to redesign Bitcoin and expect other stakeholders to > follow you. It's sad that Segwit2X chose that path, because many early > adopters and investors are realistic and understand that a block weight > increase will very likely be needed in the future, because even if we could > get a large part of the bitcoin economy to use paiement channels, we would > still have to have enough room to settle them. > > > > I'm afraid it's too late to call off the fork, as you've all already > invested so much time and energy in it. I think (and hope) that the fork > will fail, and that the B2X chain will never gain any significant economic > value - precisely because it would be so vulnerable to arbitrary changes in > consensus rules from external actors. > > > > In any case I hope that the next iterations of the scaling debate will be > more open and collaborative, and see cool heads prevail. > > > > Cheers. > > Hubert > > > > 2017-10-09 22:27 GMT+02:00 Mike Belshe : > > Thanks for the lengthy reply. Your argument can go both ways; why not > support this 2mb block size increase? The risk has already been mitigated - > miners will adopt it, businesses will support it, and its compatible with > 99.5% of existing wallets. Now, if the core team would start trying to help > it work, instead of fighting it for pride and emotional reasons, we'd even > have all the developer support behind it.... There are no technical > arguments remaining against it - just lengthy prose about misunderstandings > and what not. > > > > You imply that planning for growth/scalability has a correlated risk of > destabilization that accompanies it. If we took that as our guiding > principle, we wouldn't implement segwit either. Sure, segwit is opt-in at > the user level, but its not opt-in at the chain level - we all are dependent > on it working properly or the chain which we share breaks for all of us. The > 2x part of Segwit2x is, by any measure, a simpler technical change. I > would never say that changes carry no risk, but as far as risk goes, this > one is really small. > > > > It's a good opportunity now to just move to 2mb blocks, and there are > literally no technical objections left. > > > Mike > > > > > > > > > > On Mon, Oct 9, 2017 at 9:58 AM, hubert maslin via Bitcoin-segwit2x > wrote: > > Hello Mike, I understand that you're meaning well and want, as we all do, > bitcoin to succeed over long term, and by reading your messages on this > thread I've once again noticed that the current rift within the Bitcoin > community actually springs from a few disagreements that have more to do > with culture and process rather than with long term goals. I'm going to talk > about those disagreements and hopefully state the "pro decentralisation" > position in a way that's conducive to intelligent debate and perhaps, > ultimate agreement. > > > > We want to bring Bitcoin to more users because it has unique features and > qualities (namely permissionless-ness, resistance to tx censorship, > resistance to inflation, pseudonymity) that the existing financial system > doesn't offer. The presence of these features is contrary to the interests > of many powerful entities (the legacy banking system, governments and their > surveillance agencies) and only survive thanks to Bitcoin's decentralisation > and absence of centralised points of failure. Being willing to sacrifice or > endanger Bitcoin's decentralisation to achieve scaling isn't wise or forward > thinking, and is completely self-defeating. What's the point of on-boarding > an ever greater number of users if you run the risk of weakening those > features and give those users the same experience than current centralised > paiement systems offer, e.g. tx censorship, vulnerability to inflation, and > government surveillance? This would be a nonsensical and unproductive thing > to do. > > > > Doing this would be all the more absurd that we now know (as we have since > 2015) that, before increasing base block size, we can greatly increase > throughput through more efficient of block space (with Segwit and, in the > near future, with MAST, Schnorr signatures and signatures aggregation) and > more importantly, with second layer technologies such as the Lightning > Network or sidechains. These technologies are under rapid development, and > will soon alleviate scaling. > > > > Presenting the scaling debate as a dichotomy between "onboard users fast and > break things" and "let's for ever stay a store of value for rich people" is > a mistake, because we know we can already greatly improve scaling, within > the next few months and years. Was scaling slower than anticipated, we > should err on the side of caution, and not give our potential adversaries > any lever that they might pull to weaken those features. > > > > And this is why this scheduled hard fork worries me. Regardless of the > blockchain bloating issue, changing consensus rules without wide community > consensus - and in particular without the consensus of the community members > that value decentralisation and privacy the most - is precisely such a lever > for governments or other antagonists to pull. > > It would set an extremely bad precedent. The particulars of this fork - the > fact that it doesn't have replay protection, that it lays a claim on the > Bitcoin brand, that it relies on the imperfect security models of SPV > wallets to make them follow new consensus rules - make things worse. > > > > if this fork is successful and the entire community shifts to the S2X chain > (which, barring a prolonged 51% attack on the original chain, seems > extremely unlikely to me), this would signals to external actors that > consensus rules can be changed by exercising the right pressure on the right > companies - and we're literally talking of a dozen mining pools and a dozen > major paiement processors and exchanges, spread in only a few jurisdictions. > This would cast doubt on the entire ability of cryptocurrencies to remain > decentralised and act as censorship-resistant medium of exchange and > inflation-resistant store of value. Bitcoin's sole comparative advantage > over centralised systems would vanish. > > > > Even if this fork wasn't a base block size doubling but a simple, symbolic > increase of one byte to base block size, it would still be a bad thing, > because it would show that consensus rules - and therefore the very nature > of the currency people use - can be changed by external actors. To me and to > many other people, this debate isn't about block size anymore: it's about > the survivability of Bitcoin as a decentralised system. The Bitcoin > community should be as amorphous and resistant to change as possible - even > to more technically sound changes like Segwit, and even when these changes > come from competent devs with a solid track record of defending > decentralisation and privacy. > > > > Just because only a few thousands or dozens of thousands of early users and > cypherpunks out of a dozen million of users disagree with this fork doesn't > mean we can be ignored: Bitcoin rose to its current popularity (and value) > because we invested our time, our hopes and our money in it, and millions of > politically unresponsive BitPay or Coinbase customers will not make up for > our absence on a centralised chain. > > > > Claiming that Segwit2X has consensus with the now standard line "those who > oppose it are only a few thousands, while NYA signatories have millions of > customers" is akin to the NSA claiming that a majority of citizens endorses > surveillance, "because only a few thousands nerds care about it". Claiming > the silence of a majority of stakeholders as a tacit endorsement of some > policy is a dangerous (and I would add immoral) thing to do, and is what has > led to the creation of the centralised institutions that Bitcoin aims at > replacing. > > > > Bitcoin is a formidable opportunity to bring greater monetary, economic and > political freedom to all humans, and the single best hope of freedom-loving > persons in this otherwise authoritarian and freedom-hating century. > Regardless of whatever understanding or sympathy we may have for you and > other NYA signatories, we who care about those things can not accept > cooptation by companies who effectively are centralised points of failure at > the mercy of governments. > > > > If I could sum up my position (and the position of many users preoccupied > with decentralisation), it would be: "let us scale wisely, without making > short-term compromises that would weaken Bitcoin's unique features". Merely > increasing base block size as soon as we lack space would be akin to kicking > the can down the road to serfdom. And changing consensus rules at a whim - > or worse, engaging in a 51% attack to coerce the community into following > the new rules - would get us there in no time. > > > > And to respond to one of your points, Mike, wishing for both chains to > survive is certainly not about "pride": it's about giving a durable, > decentralised consensus system to the world, a system that can't be coopted, > coerced or censored. > > > > Mike, if you have any question or wish to continue this chat privately feel > free to respond directly to this email. I feel that the differences between > our respective camps are born out of cultural differences and absurd > misunderstandings, and magnified by our good ol' tribal instincts; there is > no reason why we should go through a messy divorce when we all agree on > making Bitcoin the world's sole currency, used for both small purchases and > storing large amount of values. This is Bitcoin's destiny, and our squabbles > are petty in comparison. > > > > Cheers. > > Hubert > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > -- > > Mike Belshe > CEO, BitGo, Inc > 408-718-6885 > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From morcos at gmail.com Tue Oct 10 13:38:50 2017 From: morcos at gmail.com (Alex Morcos) Date: Tue, 10 Oct 2017 09:38:50 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: To set the record straight. It was clear to me that Barry would have liked us to attend the meeting regardless of any intention to sign the agreement. It is possible I did not convey that clearly to a half dozen other Core developers in passing on the invitation although I tried to. But I was biased against any Core developers attending because: a) I did not feel the other participants in the meeting would have appreciated us being there if our intention was not to "compromise" b) I did not feel it was Core's place to represent the opposition to the intended agreement or negotiate on behalf of the opposition. (i.e. ever attend a meeting like this) On Tue, Oct 10, 2017 at 9:33 AM, Marcel Jamin via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > For visibility -- Gregory Maxwell's reply to Alex Morcos: > > > The message you relayed was > > https://0bin.net/paste/T0xP9qKeBmLiOybE#bw8g7mxCLgO1d2Yp29nayYij3lUxv7 > AgYjBuxz1ynPB > > which requested we endorse a specific prefabricated statement, "I/we > > agree to immediately support the activation of Segregated Witness and > > commit to effectuate a block size increase to 2MB within 12 months" > > which had a long list of signers. This was on May 16th, after they'd > > been circulating this stuff for weeks. > > > As you noted, the whole thing was wildly inappropriate and people would > have > > rejected attending if they were invited under its stated goals. But I > don't > > agree that we were meaningfully invited to collaborate either-- you > don't send > > a finished agreement with a long list of signers to someone whos opinion > you > > value--, and certainly not under a framework we wouldn't have seen as > wildly > > inappropriate. > > > Though sure, we at least had a theoretical short notice opportunity to > > attend-- not to actually influence the result, but to add legitimacy to > it, > > "gee thanks". :) > > > On 10 October 2017 at 14:17, Barry Silbert via Bitcoin-segwit2x > wrote: > > Hi Hubert, > > > > > > > > To clarify, Core was invited. Alex Morcos was kind enough to confirm via > > Reddit: > > > > > > > > https://www.reddit.com/r/Bitcoin/comments/6d1r96/is_it_ > not_telling_that_the_core_devs_were_not/dhzc46v/?sh=f688cb33&st=J7CBGTHU > > > > https://www.reddit.com/r/Bitcoin/comments/6cwg98/barry_ > silbert_bitcoin_scaling_agreement/dhy4oeo/?sh=76d1d2d1&st=J7CBG00Q > > > > > > > > > > > > Barry Silbert > > > > Founder & CEO, Digital Currency Group > > > > www.DCG.co > > > > e: barry at DCG.co > > > > t: (212) 473-2408 | @BarrySilbert > > > > 636 Avenue of the Americas (Entrance on 19th St.) > > New York, NY 10011 > > > > > > > > > > > > From: bitcoin-segwit2x-bounces at lists.linuxfoundation.org > > [mailto:bitcoin-segwit2x-bounces at lists.linuxfoundation.org] On Behalf Of > > hubert maslin via Bitcoin-segwit2x > > Sent: Tuesday, October 10, 2017 5:32 AM > > To: BitGo - Mike Belshe > > Cc: bitcoin-segwit2x at lists.linuxfoundation.org > > Subject: Re: [Bitcoin-segwit2x] Strong 2-Way Replay Protection > > > > > > > > I get your frustration that the ecosystem resists a lot to something > that's > > a no-brainer upgrade for you, but this resistance is a feature, not a > bug, > > and in my opinion Segwit2X was the wrong vehicle to achieve an upgrade of > > this kind from the beginning. > > > > > > > > Bitcoin is not an enterprise database that your supplier can upgrade in a > > week, it's a *shared* global decentralised ledger, it's an infrastructure > > used by millions (and hopefully billions in the future) of people who all > > have their own reasons to use it and their own preferences. It's to be > > expected by upgrading such a thing will be a long and contentious > process. > > > > > > > > If you want the support of developers, investors and power users, you > have > > to make this 2X base block size (now block weight) increase palatable to > > them, by asking them whether they might to see some other changes bundled > > with it, and also by having enough time to develop, test and deploy the > fork > > (for example 6 months for development/testing and a year for deployment). > > Replay protection is also a must, so that those whose wishes haven't been > > fulfilled by the fork can easily stay on their chain, without feeling > like > > they're marginalised, or held hostages. > > > > > > > > I know this isn't a psychology or anthropology mailing list, but I'd > like to > > make a point about human nature, that explains why debates get so heated > so > > easily. > > > > People don't like to back down to so much as the smallest slights or > > disrespect, because of the implicit assumption that such a retreat would > > only lead to greater agression or disrespect in the future - this is why > > violent conflicts often arise from seemingly benign squabbles. This > > assumption is literally built in us; it's a by-product of our evolution, > > because those humans who reacted to threats of agression instead of > waiting > > for an actual agression to take place might have had better odds of > > survival. Suppose that we do as you wish and agree on this fork: what > tells > > us that a year from now some other group of CEOs will not come up with a > > perfectly valid reason to implement address blacklisting at the protocol > > level, or change Bitcoin's inflation schedule? Having backed down to the > > November 2017 2X hard fork would make it harder for us to resist the > ones to > > come. > > > > The fact that we mistrust people whose objectives and group membership > > differ from ours is a truth as fundamental as the fact that we breathe, > eat > > or drink. To disarm this natural mistrust, the process that leads to the > > definition and implementation of the fork has to be as inclusive, > > egalitarian and open as possible, so that all voices can be heard. The > > process might actually matters even more than its own product - the fork > > design - because the process itself is an expression of the balance of > > economic power among the different stakeholders; and it would be > dangerous > > to artificially sway this balance through manipulation, disinformation or > > outrage. > > > > > > > > You refer to the risk of the hard fork being small. But focusing on pure > > technical risks misses the point: the main risk of this fork (and the > main > > reason why so many of us are opposed to it) is the fact that it opens the > > door to further contentious changes in the future. There's an element of > > recursion here - the fork is contentious because it sets a bad precedent > of > > a contentious change having been made - and that's because the design > > process it stems from wasn't open and collaborative. > > > > > > > > You can't get together at a private meeting (from what I've understood, > > developers other than those closely affiliated to you weren't invited), > > agree among yourselves to redesign Bitcoin and expect other stakeholders > to > > follow you. It's sad that Segwit2X chose that path, because many early > > adopters and investors are realistic and understand that a block weight > > increase will very likely be needed in the future, because even if we > could > > get a large part of the bitcoin economy to use paiement channels, we > would > > still have to have enough room to settle them. > > > > > > > > I'm afraid it's too late to call off the fork, as you've all already > > invested so much time and energy in it. I think (and hope) that the fork > > will fail, and that the B2X chain will never gain any significant > economic > > value - precisely because it would be so vulnerable to arbitrary changes > in > > consensus rules from external actors. > > > > > > > > In any case I hope that the next iterations of the scaling debate will be > > more open and collaborative, and see cool heads prevail. > > > > > > > > Cheers. > > > > Hubert > > > > > > > > 2017-10-09 22:27 GMT+02:00 Mike Belshe : > > > > Thanks for the lengthy reply. Your argument can go both ways; why not > > support this 2mb block size increase? The risk has already been > mitigated - > > miners will adopt it, businesses will support it, and its compatible with > > 99.5% of existing wallets. Now, if the core team would start trying to > help > > it work, instead of fighting it for pride and emotional reasons, we'd > even > > have all the developer support behind it.... There are no technical > > arguments remaining against it - just lengthy prose about > misunderstandings > > and what not. > > > > > > > > You imply that planning for growth/scalability has a correlated risk of > > destabilization that accompanies it. If we took that as our guiding > > principle, we wouldn't implement segwit either. Sure, segwit is opt-in > at > > the user level, but its not opt-in at the chain level - we all are > dependent > > on it working properly or the chain which we share breaks for all of us. > The > > 2x part of Segwit2x is, by any measure, a simpler technical change. I > > would never say that changes carry no risk, but as far as risk goes, this > > one is really small. > > > > > > > > It's a good opportunity now to just move to 2mb blocks, and there are > > literally no technical objections left. > > > > > > Mike > > > > > > > > > > > > > > > > > > > > On Mon, Oct 9, 2017 at 9:58 AM, hubert maslin via Bitcoin-segwit2x > > wrote: > > > > Hello Mike, I understand that you're meaning well and want, as we all do, > > bitcoin to succeed over long term, and by reading your messages on this > > thread I've once again noticed that the current rift within the Bitcoin > > community actually springs from a few disagreements that have more to do > > with culture and process rather than with long term goals. I'm going to > talk > > about those disagreements and hopefully state the "pro decentralisation" > > position in a way that's conducive to intelligent debate and perhaps, > > ultimate agreement. > > > > > > > > We want to bring Bitcoin to more users because it has unique features and > > qualities (namely permissionless-ness, resistance to tx censorship, > > resistance to inflation, pseudonymity) that the existing financial system > > doesn't offer. The presence of these features is contrary to the > interests > > of many powerful entities (the legacy banking system, governments and > their > > surveillance agencies) and only survive thanks to Bitcoin's > decentralisation > > and absence of centralised points of failure. Being willing to sacrifice > or > > endanger Bitcoin's decentralisation to achieve scaling isn't wise or > forward > > thinking, and is completely self-defeating. What's the point of > on-boarding > > an ever greater number of users if you run the risk of weakening those > > features and give those users the same experience than current > centralised > > paiement systems offer, e.g. tx censorship, vulnerability to inflation, > and > > government surveillance? This would be a nonsensical and unproductive > thing > > to do. > > > > > > > > Doing this would be all the more absurd that we now know (as we have > since > > 2015) that, before increasing base block size, we can greatly increase > > throughput through more efficient of block space (with Segwit and, in the > > near future, with MAST, Schnorr signatures and signatures aggregation) > and > > more importantly, with second layer technologies such as the Lightning > > Network or sidechains. These technologies are under rapid development, > and > > will soon alleviate scaling. > > > > > > > > Presenting the scaling debate as a dichotomy between "onboard users fast > and > > break things" and "let's for ever stay a store of value for rich people" > is > > a mistake, because we know we can already greatly improve scaling, within > > the next few months and years. Was scaling slower than anticipated, we > > should err on the side of caution, and not give our potential adversaries > > any lever that they might pull to weaken those features. > > > > > > > > And this is why this scheduled hard fork worries me. Regardless of the > > blockchain bloating issue, changing consensus rules without wide > community > > consensus - and in particular without the consensus of the community > members > > that value decentralisation and privacy the most - is precisely such a > lever > > for governments or other antagonists to pull. > > > > It would set an extremely bad precedent. The particulars of this fork - > the > > fact that it doesn't have replay protection, that it lays a claim on the > > Bitcoin brand, that it relies on the imperfect security models of SPV > > wallets to make them follow new consensus rules - make things worse. > > > > > > > > if this fork is successful and the entire community shifts to the S2X > chain > > (which, barring a prolonged 51% attack on the original chain, seems > > extremely unlikely to me), this would signals to external actors that > > consensus rules can be changed by exercising the right pressure on the > right > > companies - and we're literally talking of a dozen mining pools and a > dozen > > major paiement processors and exchanges, spread in only a few > jurisdictions. > > This would cast doubt on the entire ability of cryptocurrencies to remain > > decentralised and act as censorship-resistant medium of exchange and > > inflation-resistant store of value. Bitcoin's sole comparative advantage > > over centralised systems would vanish. > > > > > > > > Even if this fork wasn't a base block size doubling but a simple, > symbolic > > increase of one byte to base block size, it would still be a bad thing, > > because it would show that consensus rules - and therefore the very > nature > > of the currency people use - can be changed by external actors. To me > and to > > many other people, this debate isn't about block size anymore: it's about > > the survivability of Bitcoin as a decentralised system. The Bitcoin > > community should be as amorphous and resistant to change as possible - > even > > to more technically sound changes like Segwit, and even when these > changes > > come from competent devs with a solid track record of defending > > decentralisation and privacy. > > > > > > > > Just because only a few thousands or dozens of thousands of early users > and > > cypherpunks out of a dozen million of users disagree with this fork > doesn't > > mean we can be ignored: Bitcoin rose to its current popularity (and > value) > > because we invested our time, our hopes and our money in it, and > millions of > > politically unresponsive BitPay or Coinbase customers will not make up > for > > our absence on a centralised chain. > > > > > > > > Claiming that Segwit2X has consensus with the now standard line "those > who > > oppose it are only a few thousands, while NYA signatories have millions > of > > customers" is akin to the NSA claiming that a majority of citizens > endorses > > surveillance, "because only a few thousands nerds care about it". > Claiming > > the silence of a majority of stakeholders as a tacit endorsement of some > > policy is a dangerous (and I would add immoral) thing to do, and is what > has > > led to the creation of the centralised institutions that Bitcoin aims at > > replacing. > > > > > > > > Bitcoin is a formidable opportunity to bring greater monetary, economic > and > > political freedom to all humans, and the single best hope of > freedom-loving > > persons in this otherwise authoritarian and freedom-hating century. > > Regardless of whatever understanding or sympathy we may have for you and > > other NYA signatories, we who care about those things can not accept > > cooptation by companies who effectively are centralised points of > failure at > > the mercy of governments. > > > > > > > > If I could sum up my position (and the position of many users preoccupied > > with decentralisation), it would be: "let us scale wisely, without making > > short-term compromises that would weaken Bitcoin's unique features". > Merely > > increasing base block size as soon as we lack space would be akin to > kicking > > the can down the road to serfdom. And changing consensus rules at a whim > - > > or worse, engaging in a 51% attack to coerce the community into following > > the new rules - would get us there in no time. > > > > > > > > And to respond to one of your points, Mike, wishing for both chains to > > survive is certainly not about "pride": it's about giving a durable, > > decentralised consensus system to the world, a system that can't be > coopted, > > coerced or censored. > > > > > > > > Mike, if you have any question or wish to continue this chat privately > feel > > free to respond directly to this email. I feel that the differences > between > > our respective camps are born out of cultural differences and absurd > > misunderstandings, and magnified by our good ol' tribal instincts; there > is > > no reason why we should go through a messy divorce when we all agree on > > making Bitcoin the world's sole currency, used for both small purchases > and > > storing large amount of values. This is Bitcoin's destiny, and our > squabbles > > are petty in comparison. > > > > > > > > Cheers. > > > > Hubert > > > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > > > > > > > -- > > > > Mike Belshe > > CEO, BitGo, Inc > > 408-718-6885 > > > > > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameson.lopp at gmail.com Tue Oct 10 14:03:12 2017 From: jameson.lopp at gmail.com (Jameson Lopp) Date: Tue, 10 Oct 2017 10:03:12 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: <1557932.jUTfu5DZ3s@strawberry> References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: On Tue, Oct 10, 2017 at 5:50 AM, Tom Zander via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via Bitcoin-segwit2x > wrote: > > The Bitcoin Core process is quite unrelated to this question. Regardless > > of which code they do or do not merge into their repositories, it is the > > existing set of nodes with the existing set of software that is the > > question. > > The vast majority of people use either SPV wallets or online wallets. > They will just follow the longest chain. > > I?d like to point out that the only people that will have to upgrade are > the > people that run a Bitcoin Core node while they are not miners etc. > Those individuals are doing it wrong anyway. > > Instead of badgering the SegWit-workgroup, I think a much higher rate of > benefit can be reached by educating the people that run full nodes and > explaining how they are not in actual fact helping the network. > The simple fact is that if they didn?t run those nodes, this whole > discussion would not exist. > > If you want to redesign the system to force everyone into a weaker security model, you could do a LOT better to make it simpler and more efficient while you're at it. Yes, user sovereignty is a huge inconvenience to those who wish to push a contentious proposal. That's the whole point. You're free to create a new system without it, but I suspect you won't have much success convincing users who value financial sovereignty to voluntarily give it up. > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at bloq.com Tue Oct 10 14:11:49 2017 From: jeff at bloq.com (Jeff Garzik) Date: Tue, 10 Oct 2017 10:11:49 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: All, This is not an extension of social media. This is a technical mailing list for discussions related to segwit2x. It is self-evident that (1) _not_ upgrading past 1M base block size has been contentious and does not have consensus, and (2) the segwit-only path did not have consensus. segwit2x solves these problems. If there are technical suggestions, please send a technically-specific email or file a PR at github. Thanks. On Tue, Oct 10, 2017 at 10:03 AM, Jameson Lopp via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > > On Tue, Oct 10, 2017 at 5:50 AM, Tom Zander via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via Bitcoin-segwit2x >> wrote: >> > The Bitcoin Core process is quite unrelated to this question. Regardless >> > of which code they do or do not merge into their repositories, it is the >> > existing set of nodes with the existing set of software that is the >> > question. >> >> The vast majority of people use either SPV wallets or online wallets. >> They will just follow the longest chain. >> >> I?d like to point out that the only people that will have to upgrade are >> the >> people that run a Bitcoin Core node while they are not miners etc. >> Those individuals are doing it wrong anyway. >> >> Instead of badgering the SegWit-workgroup, I think a much higher rate of >> benefit can be reached by educating the people that run full nodes and >> explaining how they are not in actual fact helping the network. >> The simple fact is that if they didn?t run those nodes, this whole >> discussion would not exist. >> >> If you want to redesign the system to force everyone into a weaker > security model, you could do a LOT better to make it simpler and more > efficient while you're at it. > > Yes, user sovereignty is a huge inconvenience to those who wish to push a > contentious proposal. That's the whole point. You're free to create a new > system without it, but I suspect you won't have much success convincing > users who value financial sovereignty to voluntarily give it up. > >> -- >> Tom Zander >> Blog: https://zander.github.io >> Vlog: https://vimeo.com/channels/tomscryptochannel >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- Jeff Garzik CEO and Co Founder Bloq, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaredr26 at gmail.com Tue Oct 10 14:16:29 2017 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Tue, 10 Oct 2017 07:16:29 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: > If you want to redesign the system to force everyone into a weaker security model, you could do a LOT better to make it simpler and more efficient while you're at it. Can you please show an attack whereby bigger blocks decreases Bitcoin's "security model"? What's the game theory of that attack scenario? What's the metrics / measurement when Bitcoin should know it is in danger? On Tue, Oct 10, 2017 at 7:03 AM, Jameson Lopp via Bitcoin-segwit2x wrote: > > > On Tue, Oct 10, 2017 at 5:50 AM, Tom Zander via Bitcoin-segwit2x > wrote: >> >> On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via Bitcoin-segwit2x >> wrote: >> > The Bitcoin Core process is quite unrelated to this question. Regardless >> > of which code they do or do not merge into their repositories, it is the >> > existing set of nodes with the existing set of software that is the >> > question. >> >> The vast majority of people use either SPV wallets or online wallets. >> They will just follow the longest chain. >> >> I?d like to point out that the only people that will have to upgrade are >> the >> people that run a Bitcoin Core node while they are not miners etc. >> Those individuals are doing it wrong anyway. >> >> Instead of badgering the SegWit-workgroup, I think a much higher rate of >> benefit can be reached by educating the people that run full nodes and >> explaining how they are not in actual fact helping the network. >> The simple fact is that if they didn?t run those nodes, this whole >> discussion would not exist. >> > If you want to redesign the system to force everyone into a weaker security > model, you could do a LOT better to make it simpler and more efficient while > you're at it. > > Yes, user sovereignty is a huge inconvenience to those who wish to push a > contentious proposal. That's the whole point. You're free to create a new > system without it, but I suspect you won't have much success convincing > users who value financial sovereignty to voluntarily give it up. >> >> -- >> Tom Zander >> Blog: https://zander.github.io >> Vlog: https://vimeo.com/channels/tomscryptochannel >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From segwit2x_mailinglist at bitcoinreminder.com Tue Oct 10 14:19:04 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Tue, 10 Oct 2017 16:19:04 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: > segwit2x solves these problems. It?s really a shame that you talk about consensus, while so many contributions to this list and other forums show clearly that there is NO consensus throughout the community. You guys are so far away from reality, it?s really astonishing. Since you are completely ignoring technical reasons against this fork, you can expect that other ignore your rules the same way. > Am 10.10.2017 um 16:11 schrieb Jeff Garzik via Bitcoin-segwit2x : > > All, > > This is not an extension of social media. This is a technical mailing list for discussions related to segwit2x. > > It is self-evident that (1) _not_ upgrading past 1M base block size has been contentious and does not have consensus, and (2) the segwit-only path did not have consensus. segwit2x solves these problems. > > If there are technical suggestions, please send a technically-specific email or file a PR at github. > > Thanks. > > > > > > On Tue, Oct 10, 2017 at 10:03 AM, Jameson Lopp via Bitcoin-segwit2x > wrote: > > > On Tue, Oct 10, 2017 at 5:50 AM, Tom Zander via Bitcoin-segwit2x > wrote: > On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via Bitcoin-segwit2x > wrote: > > The Bitcoin Core process is quite unrelated to this question. Regardless > > of which code they do or do not merge into their repositories, it is the > > existing set of nodes with the existing set of software that is the > > question. > > The vast majority of people use either SPV wallets or online wallets. > They will just follow the longest chain. > > I?d like to point out that the only people that will have to upgrade are the > people that run a Bitcoin Core node while they are not miners etc. > Those individuals are doing it wrong anyway. > > Instead of badgering the SegWit-workgroup, I think a much higher rate of > benefit can be reached by educating the people that run full nodes and > explaining how they are not in actual fact helping the network. > The simple fact is that if they didn?t run those nodes, this whole > discussion would not exist. > > If you want to redesign the system to force everyone into a weaker security model, you could do a LOT better to make it simpler and more efficient while you're at it. > > Yes, user sovereignty is a huge inconvenience to those who wish to push a contentious proposal. That's the whole point. You're free to create a new system without it, but I suspect you won't have much success convincing users who value financial sovereignty to voluntarily give it up. > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > -- > Jeff Garzik > CEO and Co Founder > Bloq, Inc. > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Tue Oct 10 14:29:56 2017 From: chris at suredbits.com (Chris Stewart) Date: Tue, 10 Oct 2017 09:29:56 -0500 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: >Can you please show an attack whereby bigger blocks decreases Bitcoin's "security model"? What's the game theory of that attack scenario? What's the metrics / measurement when Bitcoin should know it is in danger? I don't have a specific vulnerability on hand -- and it would be extremely irresponsible of me to disclose it via a mailing list (!) -- but an example of a vulnerability found less than a year ago is Sergio Demian Lerner's FindAndDelete exploit. https://bitslog.wordpress.com/2017/01/08/a-bitcoin-transaction-that-takes-5-hours-to-verify/ This was a serious vulnerability before it was patched. It is made worse by a throughput increase to our system as you can fit more of these txs in a block. Another example of Christopher Jeffrey's exploit at breaking bitcoin. He emphasizes that the setup for this attack takes a long time -- which makes it unlikely -- however if there is a throughput increase to the system this can be setup faster (and cheaper). https://www.youtube.com/watch?v=0WCaoGiAOHE&feature=youtu.be&t=8944 The moral of the story here is we should be conservative/humble with the security assumptions of bitcoin. We *still* have a lot to learn about bitcoin and consensus based protocols. If you can DoS the network in a way that causes the p2p network to fail there will be a severe disruption to bitcoin. As it stands the bitcoin protocol has an astounding track record in terms of up time -- I'd like it to keep it that way. -Chris On Tue, Oct 10, 2017 at 9:16 AM, Jared Lee Richardson via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > If you want to redesign the system to force everyone into a weaker > security model, you could do a LOT better to make it simpler and more > efficient while you're at it. > > Can you please show an attack whereby bigger blocks decreases > Bitcoin's "security model"? What's the game theory of that attack > scenario? What's the metrics / measurement when Bitcoin should know > it is in danger? > > > On Tue, Oct 10, 2017 at 7:03 AM, Jameson Lopp via Bitcoin-segwit2x > wrote: > > > > > > On Tue, Oct 10, 2017 at 5:50 AM, Tom Zander via Bitcoin-segwit2x > > wrote: > >> > >> On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via > Bitcoin-segwit2x > >> wrote: > >> > The Bitcoin Core process is quite unrelated to this question. > Regardless > >> > of which code they do or do not merge into their repositories, it is > the > >> > existing set of nodes with the existing set of software that is the > >> > question. > >> > >> The vast majority of people use either SPV wallets or online wallets. > >> They will just follow the longest chain. > >> > >> I?d like to point out that the only people that will have to upgrade are > >> the > >> people that run a Bitcoin Core node while they are not miners etc. > >> Those individuals are doing it wrong anyway. > >> > >> Instead of badgering the SegWit-workgroup, I think a much higher rate of > >> benefit can be reached by educating the people that run full nodes and > >> explaining how they are not in actual fact helping the network. > >> The simple fact is that if they didn?t run those nodes, this whole > >> discussion would not exist. > >> > > If you want to redesign the system to force everyone into a weaker > security > > model, you could do a LOT better to make it simpler and more efficient > while > > you're at it. > > > > Yes, user sovereignty is a huge inconvenience to those who wish to push a > > contentious proposal. That's the whole point. You're free to create a new > > system without it, but I suspect you won't have much success convincing > > users who value financial sovereignty to voluntarily give it up. > >> > >> -- > >> Tom Zander > >> Blog: https://zander.github.io > >> Vlog: https://vimeo.com/channels/tomscryptochannel > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameson.lopp at gmail.com Tue Oct 10 14:33:03 2017 From: jameson.lopp at gmail.com (Jameson Lopp) Date: Tue, 10 Oct 2017 10:33:03 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: I was referring to SPV vs full node security models. Deep dive into them available here: https://www.coindesk.com/bitcoins-security-model-deep-dive/ SPV is a weaker security model. It also has pretty bad scaling properties that need to be addressed if the intention is for all users to run SPV clients. Deep dive available here: https://www.coindesk.com/spv-support-billion-bitcoin-users-sizing-scaling-claim/ - Jameson On Tue, Oct 10, 2017 at 10:29 AM, Chris Stewart wrote: > >Can you please show an attack whereby bigger blocks decreases > Bitcoin's "security model"? What's the game theory of that attack > scenario? What's the metrics / measurement when Bitcoin should know > it is in danger? > > I don't have a specific vulnerability on hand -- and it would be extremely > irresponsible of me to disclose it via a mailing list (!) -- but an example > of a vulnerability found less than a year ago is Sergio Demian Lerner's > FindAndDelete exploit. > > https://bitslog.wordpress.com/2017/01/08/a-bitcoin- > transaction-that-takes-5-hours-to-verify/ > > This was a serious vulnerability before it was patched. It is made worse > by a throughput increase to our system as you can fit more of these txs in > a block. > > Another example of Christopher Jeffrey's exploit at breaking bitcoin. He > emphasizes that the setup for this attack takes a long time -- which makes > it unlikely -- however if there is a throughput increase to the system this > can be setup faster (and cheaper). > > https://www.youtube.com/watch?v=0WCaoGiAOHE&feature=youtu.be&t=8944 > > The moral of the story here is we should be conservative/humble with the > security assumptions of bitcoin. We *still* have a lot to learn about > bitcoin and consensus based protocols. If you can DoS the network in a way > that causes the p2p network to fail there will be a severe disruption to > bitcoin. As it stands the bitcoin protocol has an astounding track record > in terms of up time -- I'd like it to keep it that way. > > -Chris > > > On Tue, Oct 10, 2017 at 9:16 AM, Jared Lee Richardson via Bitcoin-segwit2x > wrote: > >> > If you want to redesign the system to force everyone into a weaker >> security model, you could do a LOT better to make it simpler and more >> efficient while you're at it. >> >> Can you please show an attack whereby bigger blocks decreases >> Bitcoin's "security model"? What's the game theory of that attack >> scenario? What's the metrics / measurement when Bitcoin should know >> it is in danger? >> >> >> On Tue, Oct 10, 2017 at 7:03 AM, Jameson Lopp via Bitcoin-segwit2x >> wrote: >> > >> > >> > On Tue, Oct 10, 2017 at 5:50 AM, Tom Zander via Bitcoin-segwit2x >> > wrote: >> >> >> >> On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via >> Bitcoin-segwit2x >> >> wrote: >> >> > The Bitcoin Core process is quite unrelated to this question. >> Regardless >> >> > of which code they do or do not merge into their repositories, it is >> the >> >> > existing set of nodes with the existing set of software that is the >> >> > question. >> >> >> >> The vast majority of people use either SPV wallets or online wallets. >> >> They will just follow the longest chain. >> >> >> >> I?d like to point out that the only people that will have to upgrade >> are >> >> the >> >> people that run a Bitcoin Core node while they are not miners etc. >> >> Those individuals are doing it wrong anyway. >> >> >> >> Instead of badgering the SegWit-workgroup, I think a much higher rate >> of >> >> benefit can be reached by educating the people that run full nodes and >> >> explaining how they are not in actual fact helping the network. >> >> The simple fact is that if they didn?t run those nodes, this whole >> >> discussion would not exist. >> >> >> > If you want to redesign the system to force everyone into a weaker >> security >> > model, you could do a LOT better to make it simpler and more efficient >> while >> > you're at it. >> > >> > Yes, user sovereignty is a huge inconvenience to those who wish to push >> a >> > contentious proposal. That's the whole point. You're free to create a >> new >> > system without it, but I suspect you won't have much success convincing >> > users who value financial sovereignty to voluntarily give it up. >> >> >> >> -- >> >> Tom Zander >> >> Blog: https://zander.github.io >> >> Vlog: https://vimeo.com/channels/tomscryptochannel >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > >> > >> > >> > _______________________________________________ >> > Bitcoin-segwit2x mailing list >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaredr26 at gmail.com Tue Oct 10 14:41:38 2017 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Tue, 10 Oct 2017 07:41:38 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: > The moral of the story here is we should be conservative/humble with the security assumptions of bitcoin. No, the moral of the story is that you are literally choking the growth of the ecosystem based on assumptions. > but an example of a vulnerability found less than a year ago is Sergio Demian Lerner's FindAndDelete exploit. Those aren't unsolvable issues related to blocksize. When those are found, we fix them. End of story. > however if there is a throughput increase to the system this can be setup faster (and cheaper). ... Which was fixed. So now we can increase the blocksize. Refusing to increase the blocksize is doing REAL measurable damage to Bitcoin. If you don't have a real measurable attack that we absolutely must protect ourselves against, increasing the blocksize is a no brainer. On Tue, Oct 10, 2017 at 7:29 AM, Chris Stewart wrote: >>Can you please show an attack whereby bigger blocks decreases > Bitcoin's "security model"? What's the game theory of that attack > scenario? What's the metrics / measurement when Bitcoin should know > it is in danger? > > I don't have a specific vulnerability on hand -- and it would be extremely > irresponsible of me to disclose it via a mailing list (!) -- but an example > of a vulnerability found less than a year ago is Sergio Demian Lerner's > FindAndDelete exploit. > > https://bitslog.wordpress.com/2017/01/08/a-bitcoin-transaction-that-takes-5-hours-to-verify/ > > This was a serious vulnerability before it was patched. It is made worse by > a throughput increase to our system as you can fit more of these txs in a > block. > > Another example of Christopher Jeffrey's exploit at breaking bitcoin. He > emphasizes that the setup for this attack takes a long time -- which makes > it unlikely -- however if there is a throughput increase to the system this > can be setup faster (and cheaper). > > https://www.youtube.com/watch?v=0WCaoGiAOHE&feature=youtu.be&t=8944 > > The moral of the story here is we should be conservative/humble with the > security assumptions of bitcoin. We *still* have a lot to learn about > bitcoin and consensus based protocols. If you can DoS the network in a way > that causes the p2p network to fail there will be a severe disruption to > bitcoin. As it stands the bitcoin protocol has an astounding track record in > terms of up time -- I'd like it to keep it that way. > > -Chris > > > On Tue, Oct 10, 2017 at 9:16 AM, Jared Lee Richardson via Bitcoin-segwit2x > wrote: >> >> > If you want to redesign the system to force everyone into a weaker >> > security model, you could do a LOT better to make it simpler and more >> > efficient while you're at it. >> >> Can you please show an attack whereby bigger blocks decreases >> Bitcoin's "security model"? What's the game theory of that attack >> scenario? What's the metrics / measurement when Bitcoin should know >> it is in danger? >> >> >> On Tue, Oct 10, 2017 at 7:03 AM, Jameson Lopp via Bitcoin-segwit2x >> wrote: >> > >> > >> > On Tue, Oct 10, 2017 at 5:50 AM, Tom Zander via Bitcoin-segwit2x >> > wrote: >> >> >> >> On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via >> >> Bitcoin-segwit2x >> >> wrote: >> >> > The Bitcoin Core process is quite unrelated to this question. >> >> > Regardless >> >> > of which code they do or do not merge into their repositories, it is >> >> > the >> >> > existing set of nodes with the existing set of software that is the >> >> > question. >> >> >> >> The vast majority of people use either SPV wallets or online wallets. >> >> They will just follow the longest chain. >> >> >> >> I?d like to point out that the only people that will have to upgrade >> >> are >> >> the >> >> people that run a Bitcoin Core node while they are not miners etc. >> >> Those individuals are doing it wrong anyway. >> >> >> >> Instead of badgering the SegWit-workgroup, I think a much higher rate >> >> of >> >> benefit can be reached by educating the people that run full nodes and >> >> explaining how they are not in actual fact helping the network. >> >> The simple fact is that if they didn?t run those nodes, this whole >> >> discussion would not exist. >> >> >> > If you want to redesign the system to force everyone into a weaker >> > security >> > model, you could do a LOT better to make it simpler and more efficient >> > while >> > you're at it. >> > >> > Yes, user sovereignty is a huge inconvenience to those who wish to push >> > a >> > contentious proposal. That's the whole point. You're free to create a >> > new >> > system without it, but I suspect you won't have much success convincing >> > users who value financial sovereignty to voluntarily give it up. >> >> >> >> -- >> >> Tom Zander >> >> Blog: https://zander.github.io >> >> Vlog: https://vimeo.com/channels/tomscryptochannel >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > >> > >> > >> > _______________________________________________ >> > Bitcoin-segwit2x mailing list >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > From jaredr26 at gmail.com Tue Oct 10 14:49:21 2017 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Tue, 10 Oct 2017 07:49:21 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: > SPV is a weaker security model. Yes, for those USERS. Guess what... Most users do not need Fort Knox levels of security. Properly done SPV wallets can become trustless up to millions of dollars of economic value transferred because of the economic penalty properties of mining. Since there is no such vulnerability inherent in the ecosystem; Blocksizes can be increased now. > It also has pretty bad scaling properties that need to be addressed if the intention is for all users to run SPV clients. Oh, isn't that the thing you wrote and multiple core developers reviewed and approved but you literally forgot that computers can do caching and can batch requests, which ruins pretty much all of the math you did? And it isn't even a very good argument after ignoring that. Those are completely fixable problems. Are things being prioritized to work on that? I can say that 2x is prioritizing it. But I guess if no one prioritizes the things that "must happen" so Bitcoin can scale... we can't ever scale! Yay! On Tue, Oct 10, 2017 at 7:41 AM, Jared Lee Richardson wrote: >> The moral of the story here is we should be conservative/humble with the security assumptions of bitcoin. > > No, the moral of the story is that you are literally choking the > growth of the ecosystem based on assumptions. > >> but an example of a vulnerability found less than a year ago is Sergio Demian Lerner's FindAndDelete exploit. > > Those aren't unsolvable issues related to blocksize. When those are > found, we fix them. End of story. > >> however if there is a throughput increase to the system this can be setup faster (and cheaper). > > ... Which was fixed. So now we can increase the blocksize. > > > Refusing to increase the blocksize is doing REAL measurable damage to > Bitcoin. If you don't have a real measurable attack that we > absolutely must protect ourselves against, increasing the blocksize is > a no brainer. > > > On Tue, Oct 10, 2017 at 7:29 AM, Chris Stewart wrote: >>>Can you please show an attack whereby bigger blocks decreases >> Bitcoin's "security model"? What's the game theory of that attack >> scenario? What's the metrics / measurement when Bitcoin should know >> it is in danger? >> >> I don't have a specific vulnerability on hand -- and it would be extremely >> irresponsible of me to disclose it via a mailing list (!) -- but an example >> of a vulnerability found less than a year ago is Sergio Demian Lerner's >> FindAndDelete exploit. >> >> https://bitslog.wordpress.com/2017/01/08/a-bitcoin-transaction-that-takes-5-hours-to-verify/ >> >> This was a serious vulnerability before it was patched. It is made worse by >> a throughput increase to our system as you can fit more of these txs in a >> block. >> >> Another example of Christopher Jeffrey's exploit at breaking bitcoin. He >> emphasizes that the setup for this attack takes a long time -- which makes >> it unlikely -- however if there is a throughput increase to the system this >> can be setup faster (and cheaper). >> >> https://www.youtube.com/watch?v=0WCaoGiAOHE&feature=youtu.be&t=8944 >> >> The moral of the story here is we should be conservative/humble with the >> security assumptions of bitcoin. We *still* have a lot to learn about >> bitcoin and consensus based protocols. If you can DoS the network in a way >> that causes the p2p network to fail there will be a severe disruption to >> bitcoin. As it stands the bitcoin protocol has an astounding track record in >> terms of up time -- I'd like it to keep it that way. >> >> -Chris >> >> >> On Tue, Oct 10, 2017 at 9:16 AM, Jared Lee Richardson via Bitcoin-segwit2x >> wrote: >>> >>> > If you want to redesign the system to force everyone into a weaker >>> > security model, you could do a LOT better to make it simpler and more >>> > efficient while you're at it. >>> >>> Can you please show an attack whereby bigger blocks decreases >>> Bitcoin's "security model"? What's the game theory of that attack >>> scenario? What's the metrics / measurement when Bitcoin should know >>> it is in danger? >>> >>> >>> On Tue, Oct 10, 2017 at 7:03 AM, Jameson Lopp via Bitcoin-segwit2x >>> wrote: >>> > >>> > >>> > On Tue, Oct 10, 2017 at 5:50 AM, Tom Zander via Bitcoin-segwit2x >>> > wrote: >>> >> >>> >> On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via >>> >> Bitcoin-segwit2x >>> >> wrote: >>> >> > The Bitcoin Core process is quite unrelated to this question. >>> >> > Regardless >>> >> > of which code they do or do not merge into their repositories, it is >>> >> > the >>> >> > existing set of nodes with the existing set of software that is the >>> >> > question. >>> >> >>> >> The vast majority of people use either SPV wallets or online wallets. >>> >> They will just follow the longest chain. >>> >> >>> >> I?d like to point out that the only people that will have to upgrade >>> >> are >>> >> the >>> >> people that run a Bitcoin Core node while they are not miners etc. >>> >> Those individuals are doing it wrong anyway. >>> >> >>> >> Instead of badgering the SegWit-workgroup, I think a much higher rate >>> >> of >>> >> benefit can be reached by educating the people that run full nodes and >>> >> explaining how they are not in actual fact helping the network. >>> >> The simple fact is that if they didn?t run those nodes, this whole >>> >> discussion would not exist. >>> >> >>> > If you want to redesign the system to force everyone into a weaker >>> > security >>> > model, you could do a LOT better to make it simpler and more efficient >>> > while >>> > you're at it. >>> > >>> > Yes, user sovereignty is a huge inconvenience to those who wish to push >>> > a >>> > contentious proposal. That's the whole point. You're free to create a >>> > new >>> > system without it, but I suspect you won't have much success convincing >>> > users who value financial sovereignty to voluntarily give it up. >>> >> >>> >> -- >>> >> Tom Zander >>> >> Blog: https://zander.github.io >>> >> Vlog: https://vimeo.com/channels/tomscryptochannel >>> >> _______________________________________________ >>> >> Bitcoin-segwit2x mailing list >>> >> Bitcoin-segwit2x at lists.linuxfoundation.org >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> > >>> > >>> > >>> > _______________________________________________ >>> > Bitcoin-segwit2x mailing list >>> > Bitcoin-segwit2x at lists.linuxfoundation.org >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> > >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> From mike at bitgo.com Tue Oct 10 14:52:59 2017 From: mike at bitgo.com (Mike Belshe) Date: Tue, 10 Oct 2017 07:52:59 -0700 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: Hey - this thread is degrading into unproductive, off-topic noise. If no more points are to be made about technical discussion of split-chain/replay protection, then lets just stop. Mike On Tue, Oct 10, 2017 at 7:49 AM, Jared Lee Richardson via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > SPV is a weaker security model. > > Yes, for those USERS. Guess what... Most users do not need Fort Knox > levels of security. > > Properly done SPV wallets can become trustless up to millions of > dollars of economic value transferred because of the economic penalty > properties of mining. > > Since there is no such vulnerability inherent in the ecosystem; > Blocksizes can be increased now. > > > It also has pretty bad scaling properties that need to be addressed if > the intention is for all users to run SPV clients. > > Oh, isn't that the thing you wrote and multiple core developers > reviewed and approved but you literally forgot that computers can do > caching and can batch requests, which ruins pretty much all of the > math you did? > > And it isn't even a very good argument after ignoring that. Those are > completely fixable problems. Are things being prioritized to work on > that? I can say that 2x is prioritizing it. But I guess if no one > prioritizes the things that "must happen" so Bitcoin can scale... we > can't ever scale! Yay! > > > On Tue, Oct 10, 2017 at 7:41 AM, Jared Lee Richardson > wrote: > >> The moral of the story here is we should be conservative/humble with > the security assumptions of bitcoin. > > > > No, the moral of the story is that you are literally choking the > > growth of the ecosystem based on assumptions. > > > >> but an example of a vulnerability found less than a year ago is Sergio > Demian Lerner's FindAndDelete exploit. > > > > Those aren't unsolvable issues related to blocksize. When those are > > found, we fix them. End of story. > > > >> however if there is a throughput increase to the system this can be > setup faster (and cheaper). > > > > ... Which was fixed. So now we can increase the blocksize. > > > > > > Refusing to increase the blocksize is doing REAL measurable damage to > > Bitcoin. If you don't have a real measurable attack that we > > absolutely must protect ourselves against, increasing the blocksize is > > a no brainer. > > > > > > On Tue, Oct 10, 2017 at 7:29 AM, Chris Stewart > wrote: > >>>Can you please show an attack whereby bigger blocks decreases > >> Bitcoin's "security model"? What's the game theory of that attack > >> scenario? What's the metrics / measurement when Bitcoin should know > >> it is in danger? > >> > >> I don't have a specific vulnerability on hand -- and it would be > extremely > >> irresponsible of me to disclose it via a mailing list (!) -- but an > example > >> of a vulnerability found less than a year ago is Sergio Demian Lerner's > >> FindAndDelete exploit. > >> > >> https://bitslog.wordpress.com/2017/01/08/a-bitcoin- > transaction-that-takes-5-hours-to-verify/ > >> > >> This was a serious vulnerability before it was patched. It is made > worse by > >> a throughput increase to our system as you can fit more of these txs in > a > >> block. > >> > >> Another example of Christopher Jeffrey's exploit at breaking bitcoin. He > >> emphasizes that the setup for this attack takes a long time -- which > makes > >> it unlikely -- however if there is a throughput increase to the system > this > >> can be setup faster (and cheaper). > >> > >> https://www.youtube.com/watch?v=0WCaoGiAOHE&feature=youtu.be&t=8944 > >> > >> The moral of the story here is we should be conservative/humble with the > >> security assumptions of bitcoin. We *still* have a lot to learn about > >> bitcoin and consensus based protocols. If you can DoS the network in a > way > >> that causes the p2p network to fail there will be a severe disruption to > >> bitcoin. As it stands the bitcoin protocol has an astounding track > record in > >> terms of up time -- I'd like it to keep it that way. > >> > >> -Chris > >> > >> > >> On Tue, Oct 10, 2017 at 9:16 AM, Jared Lee Richardson via > Bitcoin-segwit2x > >> wrote: > >>> > >>> > If you want to redesign the system to force everyone into a weaker > >>> > security model, you could do a LOT better to make it simpler and more > >>> > efficient while you're at it. > >>> > >>> Can you please show an attack whereby bigger blocks decreases > >>> Bitcoin's "security model"? What's the game theory of that attack > >>> scenario? What's the metrics / measurement when Bitcoin should know > >>> it is in danger? > >>> > >>> > >>> On Tue, Oct 10, 2017 at 7:03 AM, Jameson Lopp via Bitcoin-segwit2x > >>> wrote: > >>> > > >>> > > >>> > On Tue, Oct 10, 2017 at 5:50 AM, Tom Zander via Bitcoin-segwit2x > >>> > wrote: > >>> >> > >>> >> On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via > >>> >> Bitcoin-segwit2x > >>> >> wrote: > >>> >> > The Bitcoin Core process is quite unrelated to this question. > >>> >> > Regardless > >>> >> > of which code they do or do not merge into their repositories, it > is > >>> >> > the > >>> >> > existing set of nodes with the existing set of software that is > the > >>> >> > question. > >>> >> > >>> >> The vast majority of people use either SPV wallets or online > wallets. > >>> >> They will just follow the longest chain. > >>> >> > >>> >> I?d like to point out that the only people that will have to upgrade > >>> >> are > >>> >> the > >>> >> people that run a Bitcoin Core node while they are not miners etc. > >>> >> Those individuals are doing it wrong anyway. > >>> >> > >>> >> Instead of badgering the SegWit-workgroup, I think a much higher > rate > >>> >> of > >>> >> benefit can be reached by educating the people that run full nodes > and > >>> >> explaining how they are not in actual fact helping the network. > >>> >> The simple fact is that if they didn?t run those nodes, this whole > >>> >> discussion would not exist. > >>> >> > >>> > If you want to redesign the system to force everyone into a weaker > >>> > security > >>> > model, you could do a LOT better to make it simpler and more > efficient > >>> > while > >>> > you're at it. > >>> > > >>> > Yes, user sovereignty is a huge inconvenience to those who wish to > push > >>> > a > >>> > contentious proposal. That's the whole point. You're free to create a > >>> > new > >>> > system without it, but I suspect you won't have much success > convincing > >>> > users who value financial sovereignty to voluntarily give it up. > >>> >> > >>> >> -- > >>> >> Tom Zander > >>> >> Blog: https://zander.github.io > >>> >> Vlog: https://vimeo.com/channels/tomscryptochannel > >>> >> _______________________________________________ > >>> >> Bitcoin-segwit2x mailing list > >>> >> Bitcoin-segwit2x at lists.linuxfoundation.org > >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Bitcoin-segwit2x mailing list > >>> > Bitcoin-segwit2x at lists.linuxfoundation.org > >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>> > > >>> _______________________________________________ > >>> Bitcoin-segwit2x mailing list > >>> Bitcoin-segwit2x at lists.linuxfoundation.org > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- *Mike Belshe* *CEO, BitGo, Inc*408-718-6885 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Tue Oct 10 14:51:15 2017 From: chris at suredbits.com (Chris Stewart) Date: Tue, 10 Oct 2017 09:51:15 -0500 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: >... Which was fixed. So now we can increase the blocksize. Yes they were fixed. Which is awesome! But how do you know there aren't more lurking in the bitcoin codebase -- that is the nature of a vulnerability -- no one knows it exists until it does! We have found two vulnerabilities of this nature in the last 1.5 years! That is alarming to me. I don't think we should change rules to the protocol that can exacerbate this flavor of vulnerabilities when we are still regularly finding them. Maybe this is where we differ in visions for bitcoin. It seems to me you that are willing to accept much more technical risk than bitcoin currently has. If the p2p network goes down or consensus fails we can get a group of people together (probably the people that started segwit2x) to dictate what the state of the ledger is. Is that a fair representation of your views? I envision bitcoin to be an autonomous system that does not need humans directly interacting with the protocol to determine what the state of the ledger is. -Chris On Tue, Oct 10, 2017 at 9:41 AM, Jared Lee Richardson wrote: > > The moral of the story here is we should be conservative/humble with the > security assumptions of bitcoin. > > No, the moral of the story is that you are literally choking the > growth of the ecosystem based on assumptions. > > > but an example of a vulnerability found less than a year ago is Sergio > Demian Lerner's FindAndDelete exploit. > > Those aren't unsolvable issues related to blocksize. When those are > found, we fix them. End of story. > > > however if there is a throughput increase to the system this can be > setup faster (and cheaper). > > ... Which was fixed. So now we can increase the blocksize. > > > Refusing to increase the blocksize is doing REAL measurable damage to > Bitcoin. If you don't have a real measurable attack that we > absolutely must protect ourselves against, increasing the blocksize is > a no brainer. > > > On Tue, Oct 10, 2017 at 7:29 AM, Chris Stewart > wrote: > >>Can you please show an attack whereby bigger blocks decreases > > Bitcoin's "security model"? What's the game theory of that attack > > scenario? What's the metrics / measurement when Bitcoin should know > > it is in danger? > > > > I don't have a specific vulnerability on hand -- and it would be > extremely > > irresponsible of me to disclose it via a mailing list (!) -- but an > example > > of a vulnerability found less than a year ago is Sergio Demian Lerner's > > FindAndDelete exploit. > > > > https://bitslog.wordpress.com/2017/01/08/a-bitcoin- > transaction-that-takes-5-hours-to-verify/ > > > > This was a serious vulnerability before it was patched. It is made worse > by > > a throughput increase to our system as you can fit more of these txs in a > > block. > > > > Another example of Christopher Jeffrey's exploit at breaking bitcoin. He > > emphasizes that the setup for this attack takes a long time -- which > makes > > it unlikely -- however if there is a throughput increase to the system > this > > can be setup faster (and cheaper). > > > > https://www.youtube.com/watch?v=0WCaoGiAOHE&feature=youtu.be&t=8944 > > > > The moral of the story here is we should be conservative/humble with the > > security assumptions of bitcoin. We *still* have a lot to learn about > > bitcoin and consensus based protocols. If you can DoS the network in a > way > > that causes the p2p network to fail there will be a severe disruption to > > bitcoin. As it stands the bitcoin protocol has an astounding track > record in > > terms of up time -- I'd like it to keep it that way. > > > > -Chris > > > > > > On Tue, Oct 10, 2017 at 9:16 AM, Jared Lee Richardson via > Bitcoin-segwit2x > > wrote: > >> > >> > If you want to redesign the system to force everyone into a weaker > >> > security model, you could do a LOT better to make it simpler and more > >> > efficient while you're at it. > >> > >> Can you please show an attack whereby bigger blocks decreases > >> Bitcoin's "security model"? What's the game theory of that attack > >> scenario? What's the metrics / measurement when Bitcoin should know > >> it is in danger? > >> > >> > >> On Tue, Oct 10, 2017 at 7:03 AM, Jameson Lopp via Bitcoin-segwit2x > >> wrote: > >> > > >> > > >> > On Tue, Oct 10, 2017 at 5:50 AM, Tom Zander via Bitcoin-segwit2x > >> > wrote: > >> >> > >> >> On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via > >> >> Bitcoin-segwit2x > >> >> wrote: > >> >> > The Bitcoin Core process is quite unrelated to this question. > >> >> > Regardless > >> >> > of which code they do or do not merge into their repositories, it > is > >> >> > the > >> >> > existing set of nodes with the existing set of software that is the > >> >> > question. > >> >> > >> >> The vast majority of people use either SPV wallets or online wallets. > >> >> They will just follow the longest chain. > >> >> > >> >> I?d like to point out that the only people that will have to upgrade > >> >> are > >> >> the > >> >> people that run a Bitcoin Core node while they are not miners etc. > >> >> Those individuals are doing it wrong anyway. > >> >> > >> >> Instead of badgering the SegWit-workgroup, I think a much higher rate > >> >> of > >> >> benefit can be reached by educating the people that run full nodes > and > >> >> explaining how they are not in actual fact helping the network. > >> >> The simple fact is that if they didn?t run those nodes, this whole > >> >> discussion would not exist. > >> >> > >> > If you want to redesign the system to force everyone into a weaker > >> > security > >> > model, you could do a LOT better to make it simpler and more efficient > >> > while > >> > you're at it. > >> > > >> > Yes, user sovereignty is a huge inconvenience to those who wish to > push > >> > a > >> > contentious proposal. That's the whole point. You're free to create a > >> > new > >> > system without it, but I suspect you won't have much success > convincing > >> > users who value financial sovereignty to voluntarily give it up. > >> >> > >> >> -- > >> >> Tom Zander > >> >> Blog: https://zander.github.io > >> >> Vlog: https://vimeo.com/channels/tomscryptochannel > >> >> _______________________________________________ > >> >> Bitcoin-segwit2x mailing list > >> >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > > >> > > >> > > >> > _______________________________________________ > >> > Bitcoin-segwit2x mailing list > >> > Bitcoin-segwit2x at lists.linuxfoundation.org > >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moe at bitaccess.co Tue Oct 10 15:06:28 2017 From: moe at bitaccess.co (Moe Adham) Date: Tue, 10 Oct 2017 11:06:28 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: Agreed, Thanks Mike. Many of us are on this mailing list to stay informed about the technical requirements in supporting S2X. We may not all agree if it is going to happen, or why; for those of us with businesses to run, we need to keep our customers happy regardless the outcome (we all have customers in both camps). For that reason, it would be really beneficial if we could have one mailing list on this subject that is strictly related *strictly to technical details of this software version*, versus continuous political chatter. -- *Moe Adham, MSc, BEng **|* Co-Founder *bitaccess.co * Cell: *+1 858 877 3420* On Tue, Oct 10, 2017 at 10:52 AM, Mike Belshe via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Hey - this thread is degrading into unproductive, off-topic noise. If no > more points are to be made about technical discussion of split-chain/replay > protection, then lets just stop. > > Mike > > > On Tue, Oct 10, 2017 at 7:49 AM, Jared Lee Richardson via Bitcoin-segwit2x > wrote: > >> > SPV is a weaker security model. >> >> Yes, for those USERS. Guess what... Most users do not need Fort Knox >> levels of security. >> >> Properly done SPV wallets can become trustless up to millions of >> dollars of economic value transferred because of the economic penalty >> properties of mining. >> >> Since there is no such vulnerability inherent in the ecosystem; >> Blocksizes can be increased now. >> >> > It also has pretty bad scaling properties that need to be addressed if >> the intention is for all users to run SPV clients. >> >> Oh, isn't that the thing you wrote and multiple core developers >> reviewed and approved but you literally forgot that computers can do >> caching and can batch requests, which ruins pretty much all of the >> math you did? >> >> And it isn't even a very good argument after ignoring that. Those are >> completely fixable problems. Are things being prioritized to work on >> that? I can say that 2x is prioritizing it. But I guess if no one >> prioritizes the things that "must happen" so Bitcoin can scale... we >> can't ever scale! Yay! >> >> >> On Tue, Oct 10, 2017 at 7:41 AM, Jared Lee Richardson >> wrote: >> >> The moral of the story here is we should be conservative/humble with >> the security assumptions of bitcoin. >> > >> > No, the moral of the story is that you are literally choking the >> > growth of the ecosystem based on assumptions. >> > >> >> but an example of a vulnerability found less than a year ago is Sergio >> Demian Lerner's FindAndDelete exploit. >> > >> > Those aren't unsolvable issues related to blocksize. When those are >> > found, we fix them. End of story. >> > >> >> however if there is a throughput increase to the system this can be >> setup faster (and cheaper). >> > >> > ... Which was fixed. So now we can increase the blocksize. >> > >> > >> > Refusing to increase the blocksize is doing REAL measurable damage to >> > Bitcoin. If you don't have a real measurable attack that we >> > absolutely must protect ourselves against, increasing the blocksize is >> > a no brainer. >> > >> > >> > On Tue, Oct 10, 2017 at 7:29 AM, Chris Stewart >> wrote: >> >>>Can you please show an attack whereby bigger blocks decreases >> >> Bitcoin's "security model"? What's the game theory of that attack >> >> scenario? What's the metrics / measurement when Bitcoin should know >> >> it is in danger? >> >> >> >> I don't have a specific vulnerability on hand -- and it would be >> extremely >> >> irresponsible of me to disclose it via a mailing list (!) -- but an >> example >> >> of a vulnerability found less than a year ago is Sergio Demian Lerner's >> >> FindAndDelete exploit. >> >> >> >> https://bitslog.wordpress.com/2017/01/08/a-bitcoin-transacti >> on-that-takes-5-hours-to-verify/ >> >> >> >> This was a serious vulnerability before it was patched. It is made >> worse by >> >> a throughput increase to our system as you can fit more of these txs >> in a >> >> block. >> >> >> >> Another example of Christopher Jeffrey's exploit at breaking bitcoin. >> He >> >> emphasizes that the setup for this attack takes a long time -- which >> makes >> >> it unlikely -- however if there is a throughput increase to the system >> this >> >> can be setup faster (and cheaper). >> >> >> >> https://www.youtube.com/watch?v=0WCaoGiAOHE&feature=youtu.be&t=8944 >> >> >> >> The moral of the story here is we should be conservative/humble with >> the >> >> security assumptions of bitcoin. We *still* have a lot to learn about >> >> bitcoin and consensus based protocols. If you can DoS the network in a >> way >> >> that causes the p2p network to fail there will be a severe disruption >> to >> >> bitcoin. As it stands the bitcoin protocol has an astounding track >> record in >> >> terms of up time -- I'd like it to keep it that way. >> >> >> >> -Chris >> >> >> >> >> >> On Tue, Oct 10, 2017 at 9:16 AM, Jared Lee Richardson via >> Bitcoin-segwit2x >> >> wrote: >> >>> >> >>> > If you want to redesign the system to force everyone into a weaker >> >>> > security model, you could do a LOT better to make it simpler and >> more >> >>> > efficient while you're at it. >> >>> >> >>> Can you please show an attack whereby bigger blocks decreases >> >>> Bitcoin's "security model"? What's the game theory of that attack >> >>> scenario? What's the metrics / measurement when Bitcoin should know >> >>> it is in danger? >> >>> >> >>> >> >>> On Tue, Oct 10, 2017 at 7:03 AM, Jameson Lopp via Bitcoin-segwit2x >> >>> wrote: >> >>> > >> >>> > >> >>> > On Tue, Oct 10, 2017 at 5:50 AM, Tom Zander via Bitcoin-segwit2x >> >>> > wrote: >> >>> >> >> >>> >> On Sunday, 8 October 2017 23:38:50 CEST Alex Bosworth via >> >>> >> Bitcoin-segwit2x >> >>> >> wrote: >> >>> >> > The Bitcoin Core process is quite unrelated to this question. >> >>> >> > Regardless >> >>> >> > of which code they do or do not merge into their repositories, >> it is >> >>> >> > the >> >>> >> > existing set of nodes with the existing set of software that is >> the >> >>> >> > question. >> >>> >> >> >>> >> The vast majority of people use either SPV wallets or online >> wallets. >> >>> >> They will just follow the longest chain. >> >>> >> >> >>> >> I?d like to point out that the only people that will have to >> upgrade >> >>> >> are >> >>> >> the >> >>> >> people that run a Bitcoin Core node while they are not miners etc. >> >>> >> Those individuals are doing it wrong anyway. >> >>> >> >> >>> >> Instead of badgering the SegWit-workgroup, I think a much higher >> rate >> >>> >> of >> >>> >> benefit can be reached by educating the people that run full nodes >> and >> >>> >> explaining how they are not in actual fact helping the network. >> >>> >> The simple fact is that if they didn?t run those nodes, this whole >> >>> >> discussion would not exist. >> >>> >> >> >>> > If you want to redesign the system to force everyone into a weaker >> >>> > security >> >>> > model, you could do a LOT better to make it simpler and more >> efficient >> >>> > while >> >>> > you're at it. >> >>> > >> >>> > Yes, user sovereignty is a huge inconvenience to those who wish to >> push >> >>> > a >> >>> > contentious proposal. That's the whole point. You're free to create >> a >> >>> > new >> >>> > system without it, but I suspect you won't have much success >> convincing >> >>> > users who value financial sovereignty to voluntarily give it up. >> >>> >> >> >>> >> -- >> >>> >> Tom Zander >> >>> >> Blog: https://zander.github.io >> >>> >> Vlog: https://vimeo.com/channels/tomscryptochannel >> >>> >> _______________________________________________ >> >>> >> Bitcoin-segwit2x mailing list >> >>> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-s >> egwit2x >> >>> > >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > Bitcoin-segwit2x mailing list >> >>> > Bitcoin-segwit2x at lists.linuxfoundation.org >> >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >>> > >> >>> _______________________________________________ >> >>> Bitcoin-segwit2x mailing list >> >>> Bitcoin-segwit2x at lists.linuxfoundation.org >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > > > -- > > > *Mike Belshe* > *CEO, BitGo, Inc*408-718-6885 <(408)%20718-6885> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Tue Oct 10 15:26:40 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Tue, 10 Oct 2017 17:26:40 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: Message-ID: On 8 October 2017 at 22:00, Alex Bosworth via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > In June of this year I asked about the provisions for strong 2-way > replay protection. Strong 2-way replay protection means transactions > valid on one chain should be invalid on the other, and vice-versa. I > also asked about wipe-out protection, and that has since been > implemented, which is great. > > I talked about the possibility of a contentious hard fork, where > significant value persists across multiple chains. Support for the NYA > hard fork is still lacking from Bitfinex, Local Bitcoins (the largest > volume peer to peer exchange), Slush Pool, Trezor, Ledger, Electrum, > and many others in the industry and individuals in the development and > broader community. > > I know there has been some fervent hope that the contentious > possibility of this hard fork would abate or become minimal in the > remaining time, and that indeed was a laudable goal. But since June, > contention has only risen. Instead of adding significant support to > the agreement, important and longstanding Bitcoin companies such as > BitWala, F2Pool, and others have pulled out of the New York Agreement > that prompted this project. A number of signers have since decided to > devote their energies to other currency projects, partially or in > full. > > Early results from futures trading shows significant market demand for > both sides of the fork. > > I can now say that preparations have begun in earnest to support both > chains. The possibility of a contentious hard fork now looks like the > probable future reality. Thus, this hard fork should provide strong > 2-way replay protection. This means that transactions valid on one > chain should be invalid on the other, and vice-versa. Without this > protection, users would only be able to safely transact on the chains > separately by using explicit splitting techniques, which puts > excessive burden on the end user. > > I can restate suggestions from this list from Sergio Lerner and > WuJihan who have pointed to encouraging multiple visions to coexist, > potentially using a simple sighash modification that will fix the very > simple technical problem that a valid signature authorizing a > transaction of one currency should not be also used as a valid > signature authorizing the transaction of another currency. > > Strong 2-way replay protection will help all businesses regardless of > their position, and help regular users as well. I can quote from an > industry statement regarding the previous contentious hard fork > proposal BTU, which also proposed a hard fork coordinated around 3/4 > hash power signaling: > > "However, none of the undersigned can list BTU unless we can run both > chains independently without incident. Consequently, we insist that > the Bitcoin Unlimited community (or any other consensus breaking > implementation) build in strong two-way replay protection. Failure to > do so will impede our ability to preserve BTU for customers and will > either delay or outright preclude the listing of BTU." > > https://fs.bitcoinmagazine.com/assets/exchange_handling_ > of_contentious_hard_fork_event.pdf > > This quote specifically calls out "or any other consensus breaking > implementation". The statement was signed by companies such as > Bitstamp, Bitfinex, bitso, bitsquare, bittrex, btcc, btcchina, > coinfloor, itbit, Kraken, QuadrigaCX, and ShapeShift. > Apologies in advanced if I've missed something here. I think the following is a technical argument that's worth pointing out explicitly. Without replay protection, doesnt publishing a transaction to a block or even the UXTO, amount to publishing sensitive customer / user information. For example, would it not be similar to publishing the credit card details of one of your customers. If so, I would suspect that this would violate the law in many, if not all, jurisdictions. If my above assumptions are correct (there may be a flaw in my logic that I've not seen), does that not mean almost all the companies supporting seg2x will have to implement replay protection individually. Therefore, would it not make sense to just do it at the protocol level, or holding off the timing of the release of the fork until the futures market indicates there will not be a chain split? > > > > > -- > Sent from my iPhone > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjors at sprovoost.nl Tue Oct 10 16:07:39 2017 From: sjors at sprovoost.nl (Sjors Provoost) Date: Tue, 10 Oct 2017 18:07:39 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: > Op 10 okt. 2017, om 16:11 heeft Jeff Garzik via Bitcoin-segwit2x het volgende geschreven: > > All, > > This is not an extension of social media. This is a technical mailing list for discussions related to segwit2x. > > It is self-evident that (1) _not_ upgrading past 1M base block size has been contentious and does not have consensus, and (2) the segwit-only path did not have consensus. segwit2x solves these problems. > > If there are technical suggestions, please send a technically-specific email or file a PR at github. I really like RFC 7282 as it suggests a more precise definition of technical rough consensus than what I see on this list. In particular it distinguishes between technical objections and non-technical objections. I assume you're referring to that when saying "consensus". If not, let me know, so we're on the same page with regards to the expected process. It is my understanding that only miners objected to the SegWit-only path (2) and that they did so without technical arguments. RFC 7282 explicitly addresses situations like that and states that such non-technical objections should be ignored. More precisely, it suggests insisting the miners communicate their technical objections (though perhaps not on this list, as it's too late for that). It also cautions against the use of polls to measure the level of (dis)agreement, which cuts both ways here. This RFC makes no guarantees that things move quickly and defaults to doing nothing. It has a bias towards a more complex solution, when this addresses all issues raised against the simpler solutions, e.g. initial size increase via SegWit soft-fork and various wallet upgrades, rather than just a consensus HF. It has a bias towards slower deployments and no hard deadlines, since fewer people believe those to be unsafe. Hence Spoonnet HF at some ill defined time in the future, vs. a specific time commitment that SegWit2x signatories would prefer. This can be quite frustrating. People might even see it as a fatal flaw, still others see it as a strength. My impression of the SegWit2x deal is that it (temporarily and selectively) abandons RFC 7282 in favor of making progress (in the eyes of its participants). More important than a size increase, at least to me [1], is that I see this pattern at a more detailed level. There are many unanswered questions about the precise workings of a contentious hard-fork. Specific technical objections against pull requests were raised, but not addressed. These PR's were merged despite that, again for the sake of expediency. The re-opening of the replay attack issue is a good example; it should not have been merged (yet), given that the objections cited for reopening it were raised before the merge. If these objections had been addressed before the merge, there would have been no need to reopen it. As much as I'm in favor of good replay protection (opt-in both ways at minimum), changing consensus rules five weeks before a hard-fork seems quite dangerous. There's a high likelihood of some critical security bug not getting detected in time. There's even some political and economic incentive to withhold such vulnerabilities until the last moment (e.g. to speculate on BT2 tokens). In addition future scaling work might be hindered, although sunset code could help with that. Another process issue to think about, is that although a code freeze was scheduled for some time ago, there wasn't a clear fallback plan for when issues were found after the freeze. For example, a good policy could be to postpone the fork to at least N months after any new issue is found. The current deal doesn't provide room for this, which I think people pointed this out from day one. It's probably unwise to set a date in stone before a proposal and working code are fully fleshed out and thoroughly reviewed and tested. It prevents conundrums like having to choose between (a) sticking to the code freeze and not adding replay protection, (b) rushing it in and risking a zero-day or (c) renegotiating a HF block that miners are already signaling for. Sjors [0] https://tools.ietf.org/html/rfc7282 (HT Rusty Russel) [1] this may be my own bias, as it's easier for me to understand these specific problems whereas the scaling debate is quite complex -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From jli225 at binghamton.edu Wed Oct 11 12:27:06 2017 From: jli225 at binghamton.edu (Junyi Li) Date: Wed, 11 Oct 2017 08:27:06 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: SPV is tiny weaker than full nodes in security model ONLY when you read codes carefully, understand it thoroughly, and compile it with trusted tools. So, it's very irresponsible to spread the FUD to frighten users away SPV. Sticking to full nodes results in unnecessary burden to Both users and Bitcoin network, while bringing in literally zero benefits. I agree with Both Jeff and Sjors on the protocol process. RFC 7282 successfully prevented the fake UASF although most of committee members were corrupted. However, it may have fatal disadvantages. A small portion, i.e. three members, can unite to prevent all commits others who they dislike make, thus the most talented devs will leave gradually, while the same kind of people will join them. Under RFC 7282, the formation of cliques for their selfish interests is inevitable. Fortunately, the success of Bitcoin (SegWit2X) will set a precedent that no group is irreplaceable, thus there will be less effort and money to be used to corrupt committee members. Corruption would be delayed. So RFC 7282 is at least insufficient. It only can prevent contentious Soft Fork and contentious Hard Fork. Instead, it encourages contentious No Fork. Certain 'No fork' is more dangerous than SF and HF. I oppose the replay protection part. As Satoshi stated, the only way for everyone to stay on the same page is to believe that the longest chain is always the valid one, no matter what [1]. With the support of majority hashrate, Bitcoin (SegWit2x) shall be seen as an update, without any doubt. According to the forks history of Bitcoin, no update added replay protection. If someone or certain group plan to issue an altcoin before or after the update, and if they believe they can gain majority hashrate in the future with the help of censorship, the burden of adding replay protection is on them. We have no reason to care about if they have anti-HF ego or if it's only an excuse. It's exciting to see Bitcoiners who defended Bitcoin in front of CIA and NYDFS come together to defend Bitcoin (SegWit2X) again. Some people might have negative impression on Jihan Wu due to smear campaign they read, yet the censor won't tell you the fact that it's Jihan who firstly translated Bitcoin White Paper into Chinese. Bitcoin (Segwit2X) is certainly not perfect and that's exactly why this mailing list exists. Some trolls were actually wasting their time in the hope of persuading us with the misinformation they 'learned' under censorship [2]. I agree with Mike Belshe. If everybody comes here to state what they believe just to be told it is incorrect, we aren't going to have a very high noise to signal ratio. If those trolls really care about Bitcoin as they claimed, please help this project become more perfect and more successful by being constructive. Cheers. Junyi [1] http://satoshi.nakamotoinstitute.org/quotes/nodes/ [2] https://www.youtube.com/watch?v=0Fe6HbNdbrA On Tue, Oct 10, 2017 at 12:07 PM, Sjors Provoost via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > Op 10 okt. 2017, om 16:11 heeft Jeff Garzik via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> het volgende geschreven: > > All, > > This is not an extension of social media. This is a technical mailing > list for discussions related to segwit2x. > > It is self-evident that (1) _not_ upgrading past 1M base block size has > been contentious and does not have consensus, and (2) the segwit-only path > did not have consensus. segwit2x solves these problems. > > If there are technical suggestions, please send a technically-specific > email or file a PR at github. > > > I really like RFC 7282 as it suggests a more precise definition of > technical rough consensus than what I see on this list. In particular it > distinguishes between technical objections and non-technical objections. I > assume you're referring to that when saying "consensus". If not, let me > know, so we're on the same page with regards to the expected process. > > It is my understanding that only miners objected to the SegWit-only path > (2) and that they did so without technical arguments. RFC 7282 explicitly > addresses situations like that and states that such non-technical > objections should be ignored. More precisely, it suggests insisting the > miners communicate their technical objections (though perhaps not on this > list, as it's too late for that). > > It also cautions against the use of polls to measure the level of > (dis)agreement, which cuts both ways here. > > This RFC makes no guarantees that things move quickly and defaults to > doing nothing. > > It has a bias towards a more complex solution, when this addresses all > issues raised against the simpler solutions, e.g. initial size increase via > SegWit soft-fork and various wallet upgrades, rather than just a consensus > HF. > > It has a bias towards slower deployments and no hard deadlines, since > fewer people believe those to be unsafe. Hence Spoonnet HF at some ill > defined time in the future, vs. a specific time commitment that SegWit2x > signatories would prefer. > > This can be quite frustrating. People might even see it as a fatal flaw, > still others see it as a strength. > > My impression of the SegWit2x deal is that it (temporarily and > selectively) abandons RFC 7282 in favor of making progress (in the eyes of > its participants). > > More important than a size increase, at least to me [1], is that I see > this pattern at a more detailed level. There are many unanswered questions > about the precise workings of a contentious hard-fork. Specific technical > objections against pull requests were raised, but not addressed. These PR's > were merged despite that, again for the sake of expediency. The re-opening > of the replay attack issue is a good example; it should not have been > merged (yet), given that the objections cited for reopening it were raised > before the merge. If these objections had been addressed before the merge, > there would have been no need to reopen it. > > As much as I'm in favor of good replay protection (opt-in both ways at > minimum), changing consensus rules five weeks before a hard-fork seems > quite dangerous. There's a high likelihood of some critical security bug > not getting detected in time. There's even some political and economic > incentive to withhold such vulnerabilities until the last moment (e.g. to > speculate on BT2 tokens). In addition future scaling work might be > hindered, although sunset code could help with that. > > Another process issue to think about, is that although a code freeze was > scheduled for some time ago, there wasn't a clear fallback plan for when > issues were found after the freeze. For example, a good policy could be to > postpone the fork to at least N months after any new issue is found. The > current deal doesn't provide room for this, which I think people pointed > this out from day one. It's probably unwise to set a date in stone before a > proposal and working code are fully fleshed out and thoroughly reviewed and > tested. It prevents conundrums like having to choose between (a) sticking > to the code freeze and not adding replay protection, (b) rushing it in and > risking a zero-day or (c) renegotiating a HF block that miners are already > signaling for. > > Sjors > > [0] https://tools.ietf.org/html/rfc7282 (HT Rusty Russel) > [1] this may be my own bias, as it's easier for me to understand these > specific problems whereas the scaling debate is quite complex > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Wed Oct 11 13:06:21 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Wed, 11 Oct 2017 15:06:21 +0200 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: On 11 October 2017 at 14:27, Junyi Li via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > SPV is tiny weaker than full nodes in security model ONLY when you read > codes carefully, understand it thoroughly, and compile it with trusted > tools. So, it's very irresponsible to spread the FUD to frighten users away > SPV. Sticking to full nodes results in unnecessary burden to Both users and > Bitcoin network, while bringing in literally zero benefits. > > I agree with Both Jeff and Sjors on the protocol process. RFC 7282 > successfully prevented the fake UASF although most of committee members > were corrupted. However, it may have fatal disadvantages. A small portion, > i.e. three members, can unite to prevent all commits others who they > dislike make, thus the most talented devs will leave gradually, while the > same kind of people will join them. Under RFC 7282, the formation of > cliques for their selfish interests is inevitable. > > Fortunately, the success of Bitcoin (SegWit2X) will set a precedent that > no group is irreplaceable, thus there will be less effort and money to be > used to corrupt committee members. Corruption would be delayed. > > So RFC 7282 is at least insufficient. It only can prevent contentious Soft > Fork and contentious Hard Fork. Instead, it encourages contentious No Fork. > Certain 'No fork' is more dangerous than SF and HF. > > > I oppose the replay protection part. As Satoshi stated, the only way for > everyone to stay on the same page is to believe that the longest chain is > always the valid one, no matter what [1]. With the support of majority > hashrate, Bitcoin (SegWit2x) shall be seen as an update, without any doubt. > According to the forks history of Bitcoin, no update added replay > protection. If someone or certain group plan to issue an altcoin before or > after the update, and if they believe they can gain majority hashrate in > the future with the help of censorship, the burden of adding replay > protection is on them. We have no reason to care about if they have anti-HF > ego or if it's only an excuse. > IMHO this is a misunderstanding of Satoshi's quote. The longest chain is specific to a given protocol, and a given genesis block. The purpose is simply to synchronize a given network and avoid race conditions associated with double spending. If protocols diverge, as is the case of a hard fork, the length of the chain become irrelevant. For example ethereum, or litecoin, or some sha256 alt coin, or even a copy of bitcoin with a different genesis block could have more provable length (ie implied hash power) and yet be a different entity. About all you can say is that for a given protocol, and a shared history, nodes will work on the longest one that it knows. It would be absurd to argue that if a sha256 fork of bitcion (eg peercoin) for some reason got more hashing, it would become bitcoin. History has shown that there have been over 1000 forks of bitcoin core, and yet it has always remained the dominant. This is true measurable consensus. > > It's exciting to see Bitcoiners who defended Bitcoin in front of CIA and > NYDFS come together to defend Bitcoin (SegWit2X) again. Some people might > have negative impression on Jihan Wu due to smear campaign they read, yet > the censor won't tell you the fact that it's Jihan who firstly translated > Bitcoin White Paper into Chinese. > > Bitcoin (Segwit2X) is certainly not perfect and that's exactly why this > mailing list exists. Some trolls were actually wasting their time in the > hope of persuading us with the misinformation they 'learned' under > censorship [2]. I agree with Mike Belshe. If everybody comes here to state > what they believe just to be told it is incorrect, we aren't going to have > a very high noise to signal ratio. If those trolls really care about > Bitcoin as they claimed, please help this project become more perfect and > more successful by being constructive. > > Cheers. > > Junyi > > > [1] http://satoshi.nakamotoinstitute.org/quotes/nodes/ > > [2] https://www.youtube.com/watch?v=0Fe6HbNdbrA > > On Tue, Oct 10, 2017 at 12:07 PM, Sjors Provoost via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> >> Op 10 okt. 2017, om 16:11 heeft Jeff Garzik via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> het volgende geschreven: >> >> All, >> >> This is not an extension of social media. This is a technical mailing >> list for discussions related to segwit2x. >> >> It is self-evident that (1) _not_ upgrading past 1M base block size has >> been contentious and does not have consensus, and (2) the segwit-only path >> did not have consensus. segwit2x solves these problems. >> >> If there are technical suggestions, please send a technically-specific >> email or file a PR at github. >> >> >> I really like RFC 7282 as it suggests a more precise definition of >> technical rough consensus than what I see on this list. In particular it >> distinguishes between technical objections and non-technical objections. I >> assume you're referring to that when saying "consensus". If not, let me >> know, so we're on the same page with regards to the expected process. >> >> It is my understanding that only miners objected to the SegWit-only path >> (2) and that they did so without technical arguments. RFC 7282 explicitly >> addresses situations like that and states that such non-technical >> objections should be ignored. More precisely, it suggests insisting the >> miners communicate their technical objections (though perhaps not on this >> list, as it's too late for that). >> >> It also cautions against the use of polls to measure the level of >> (dis)agreement, which cuts both ways here. >> >> This RFC makes no guarantees that things move quickly and defaults to >> doing nothing. >> >> It has a bias towards a more complex solution, when this addresses all >> issues raised against the simpler solutions, e.g. initial size increase via >> SegWit soft-fork and various wallet upgrades, rather than just a consensus >> HF. >> >> It has a bias towards slower deployments and no hard deadlines, since >> fewer people believe those to be unsafe. Hence Spoonnet HF at some ill >> defined time in the future, vs. a specific time commitment that SegWit2x >> signatories would prefer. >> >> This can be quite frustrating. People might even see it as a fatal flaw, >> still others see it as a strength. >> >> My impression of the SegWit2x deal is that it (temporarily and >> selectively) abandons RFC 7282 in favor of making progress (in the eyes of >> its participants). >> >> More important than a size increase, at least to me [1], is that I see >> this pattern at a more detailed level. There are many unanswered questions >> about the precise workings of a contentious hard-fork. Specific technical >> objections against pull requests were raised, but not addressed. These PR's >> were merged despite that, again for the sake of expediency. The re-opening >> of the replay attack issue is a good example; it should not have been >> merged (yet), given that the objections cited for reopening it were raised >> before the merge. If these objections had been addressed before the merge, >> there would have been no need to reopen it. >> >> As much as I'm in favor of good replay protection (opt-in both ways at >> minimum), changing consensus rules five weeks before a hard-fork seems >> quite dangerous. There's a high likelihood of some critical security bug >> not getting detected in time. There's even some political and economic >> incentive to withhold such vulnerabilities until the last moment (e.g. to >> speculate on BT2 tokens). In addition future scaling work might be >> hindered, although sunset code could help with that. >> >> Another process issue to think about, is that although a code freeze was >> scheduled for some time ago, there wasn't a clear fallback plan for when >> issues were found after the freeze. For example, a good policy could be to >> postpone the fork to at least N months after any new issue is found. The >> current deal doesn't provide room for this, which I think people pointed >> this out from day one. It's probably unwise to set a date in stone before a >> proposal and working code are fully fleshed out and thoroughly reviewed and >> tested. It prevents conundrums like having to choose between (a) sticking >> to the code freeze and not adding replay protection, (b) rushing it in and >> risking a zero-day or (c) renegotiating a HF block that miners are already >> signaling for. >> >> Sjors >> >> [0] https://tools.ietf.org/html/rfc7282 (HT Rusty Russel) >> [1] this may be my own bias, as it's easier for me to understand these >> specific problems whereas the scaling debate is quite complex >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Wed Oct 11 23:22:21 2017 From: bitpico at icloud.com (bitPico) Date: Wed, 11 Oct 2017 19:22:21 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: <1557932.jUTfu5DZ3s@strawberry> References: <1557932.jUTfu5DZ3s@strawberry> Message-ID: <1FB6BB39-69AF-44AE-9888-04B2103E39A3@icloud.com> If full nodes did not exist there would be nothing to enforce miner rules which means they could do as they please. You don?t seem to understand how Bitcoin works so we will give you the short version: 1. Miners produce blocks and maintain the blockchain via consensus rules. 2. Full nodes keep the miners ?in check? so they do not break consensus rules. If full nodes did not exist or were not plentiful the network would not be secure whatsoever... > On Oct 10, 2017, at 5:50 AM, Tom Zander via Bitcoin-segwit2x wrote: > think a much higher rate of benefit can be reached by educating the people that run full nodes and > explaining how they are not in actual fact helping the network. > The simple fact is that if they didn?t run those nodes, this whole > discussion would not exist. > > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x From bitpico at icloud.com Wed Oct 11 23:30:44 2017 From: bitpico at icloud.com (bitPico) Date: Wed, 11 Oct 2017 19:30:44 -0400 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: References: <2C87CC64-30CF-40AA-BFA5-686C2CC39EBD@icloud.com> Message-ID: This mailing list is for discussion of the SegWit2x Bitcoin upgrade; more specifically upgrading from deprecated code (1x) to upgraded code (2x) to increase the base block size. If you are not experienced participating in ?working groups? please read up on the IETF as we all share the one common goal of ?making the internet better?. https://www.ietf.org/newcomers.html > On Oct 9, 2017, at 3:51 PM, Marcel Jamin via Bitcoin-segwit2x wrote: > > On 9 October 2017 at 19:00, Mike Belshe > wrote: > >> I was using Bitcoin Core's expectation of 60% maximum increase as described >> here: >> https://bitcoincore.org/en/2016/01/26/segwit-benefits/#block-capacitysize-increase >> > > (The lower bound of it.) > >> Nobody is debating Schnorr signatures here. I think that is a great idea >> for the future too. > > I brought up Schnorr signatures and LN up as examples of thinking > about growing capacity. > >> You failed to articulate any technical arguments here. > > I didn't try to. Those have already been made by people far more > capable than me again and again. And subsequently handwaved away. Talk > about being insulting. > >>> The sheer audacity of non-tech people to promote their technical >>> solution despite overwhelming expert opposition is mind-boggling >>> (https://en.bitcoin.it/wiki/Segwit_support ). I'm sorry to be blunt, >>> but you're way out of your circle of competence and you need to >>> recognize that. >> >> >> Okay, thanks for the insults. I suggest you do some research. > > Your behaviour is insulting as well. Almost as if you didn't do > research on the numerous people whose assessments you are continually > dismissing. > > Swap "non-tech" for "bitcoin non-experts", if you like. It's > admittedly more accurate. My point remains the same. > >>>> I've never heard customers say "no thanks" to better scalability except >>>> in Bitcoin. >>> >>> Bitcoin is not a business and does not have customers. It has users, >>> many of which don't primarily value it because of super low >>> transactions fees, but because of it's censorship resistance. Because >>> of the fact that no single entity or group has full control over it. >>> This includes DCG & friends. >> >> >> I've never heard users say "no thanks" to better scalability except in >> Bitcoin. >>> >>> >>> Changes to bitcoin must be argued for. All concerns need to be >>> addressed. If we start making backroom deals to get stuff in and let >>> certain groups hold things like SegWit hostage to successfully get >>> what they want but can't properly argue for, I'd consider this >>> experiment failed. >> >> >> You have failed to make any technical arguments here. This has all been >> done, and after fervent debate, the decisions have been made. > > Looks like I didn't get the memo. > >> At this point, the onus is on you to provide technical arguments against >> segwit2x. While you have provided a full course dinner of insults to me and >> everyone else here, you've failed to state even one single technical >> argument against segwit2x. > > If telling it how it is insults you, you may want to reevaluate your position. > > But I'll stop here. I acknowledge that the "Why?" is considered > off-topic here. I also agree that my hostile stance towards what I > perceive as an attack isn't really helping here. My apologies. > > This will sort itself out in the coming weeks anyway. > >>>> Today, Bitcoin is small potatoes. Want to make it really soar? Make it >>>> available to everyone. >>> >>> We owe it to ourselves to do it properly. >> >> >> Again, give me a technical argument. >> >> >> Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Wed Oct 11 23:48:42 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Wed, 11 Oct 2017 23:48:42 +0000 Subject: [Bitcoin-segwit2x] Strong 2-Way Replay Protection In-Reply-To: <1FB6BB39-69AF-44AE-9888-04B2103E39A3@icloud.com> References: <1557932.jUTfu5DZ3s@strawberry>, <1FB6BB39-69AF-44AE-9888-04B2103E39A3@icloud.com> Message-ID: >2. Full nodes keep the miners ?in check? so they do not break consensus rules. This is a wrong interpretation, IMO. None mining nodes cannot (whether full or SPV) cannot keep miners in check, they simply won?t follow a chain that contains blocks that are incompatible with their (none mining nodes?) consensus rules, this fork from that chain (if there are miners with consensus rules compatible with theirs). It is ONLY miners that keep their fellow miners in check. If a single miners (or a group) have differing consensus rules from the rest, then they?ll fork their chain off -------------- next part -------------- An HTML attachment was scrubbed... URL: From segwit2x_mailinglist at bitcoinreminder.com Thu Oct 12 12:49:54 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Thu, 12 Oct 2017 14:49:54 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? Message-ID: Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly non-NYA blocks, are you still going to fork off in November - splitting the chain intentionally? ? [1] https://imgur.com/LgYdFKw -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Thu Oct 12 13:41:20 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Thu, 12 Oct 2017 15:41:20 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: On 12 October 2017 at 14:49, Peter BitcoinReminder.com via Bitcoin-segwit2x wrote: > Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly > non-NYA blocks, are you still going to fork off in November - splitting the > chain intentionally? > This is good new information, thanks! A sensible approach might be: 1. Allow the implementation of Schnorr signatures 2. In parallel, address the issues raised on the segwit2x codebase 3. Unfreeze the segwit2x code, and seek a dialogue with core on a timeline for a 2x block size increase The reason being that we've just had a capacity upgrade and segwit is starting to kick in. Blocks are less congested now. Schnorr will likely give another 30% capacity quite soon. This will allow general hardware increases to make moving to 2x blocks, without a contentious hard fork, more practical. Just my 2 cents. > > ? > [1] https://imgur.com/LgYdFKw > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.eliosoff at gmail.com Thu Oct 12 14:24:19 2017 From: jacob.eliosoff at gmail.com (Jacob Eliosoff) Date: Thu, 12 Oct 2017 10:24:19 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: Just as a factual matter, per Wang Chun, F2Pool's owner: "I didn't pull out of anything. I told Jihan long time ago that I would support segwit2x only until July. Now it is September." https://twitter.com/f2pool_wangchun/status/903419665703043072 If anyone comes across evidence of miners/pools actually pulling out, many of us would be sincerely interested to see it, though I'd suggest say Twitter rather than a technical mailing list. On Oct 12, 2017 9:41 AM, "Melvin Carvalho via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > > On 12 October 2017 at 14:49, Peter BitcoinReminder.com via > Bitcoin-segwit2x wrote: > >> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly >> non-NYA blocks, are you still going to fork off in November - splitting the >> chain intentionally? >> > > This is good new information, thanks! > > A sensible approach might be: > > 1. Allow the implementation of Schnorr signatures > 2. In parallel, address the issues raised on the segwit2x codebase > 3. Unfreeze the segwit2x code, and seek a dialogue with core on a timeline > for a 2x block size increase > > The reason being that we've just had a capacity upgrade and segwit is > starting to kick in. Blocks are less congested now. Schnorr will likely > give another 30% capacity quite soon. This will allow general hardware > increases to make moving to 2x blocks, without a contentious hard fork, > more practical. > > Just my 2 cents. > > >> >> ? >> [1] https://imgur.com/LgYdFKw >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at blockstream.com Thu Oct 12 14:38:24 2017 From: adam at blockstream.com (Dr Adam Back) Date: Thu, 12 Oct 2017 16:38:24 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: Probably viaBTC was bigger in a way because historically they have been a kind of proxy for Bitmain, they said they would mine both chains. https://twitter.com/yhaiyang/status/917423471507890176 I believe that's what all miners will do anyway, because you cant mine unprofitably, hashrate follows profitability. But it likely speaks to what Bitmain also intends to do - I would hazard a guess. Adam On Thu, Oct 12, 2017 at 4:24 PM, Jacob Eliosoff via Bitcoin-segwit2x wrote: > Just as a factual matter, per Wang Chun, F2Pool's owner: "I didn't pull out > of anything. I told Jihan long time ago that I would support segwit2x only > until July. Now it is September." > https://twitter.com/f2pool_wangchun/status/903419665703043072 > > If anyone comes across evidence of miners/pools actually pulling out, many > of us would be sincerely interested to see it, though I'd suggest say > Twitter rather than a technical mailing list. > > > On Oct 12, 2017 9:41 AM, "Melvin Carvalho via Bitcoin-segwit2x" > wrote: >> >> >> >> On 12 October 2017 at 14:49, Peter BitcoinReminder.com via >> Bitcoin-segwit2x wrote: >>> >>> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly >>> non-NYA blocks, are you still going to fork off in November - splitting the >>> chain intentionally? >> >> >> This is good new information, thanks! >> >> A sensible approach might be: >> >> 1. Allow the implementation of Schnorr signatures >> 2. In parallel, address the issues raised on the segwit2x codebase >> 3. Unfreeze the segwit2x code, and seek a dialogue with core on a timeline >> for a 2x block size increase >> >> The reason being that we've just had a capacity upgrade and segwit is >> starting to kick in. Blocks are less congested now. Schnorr will likely >> give another 30% capacity quite soon. This will allow general hardware >> increases to make moving to 2x blocks, without a contentious hard fork, more >> practical. >> >> Just my 2 cents. >> >>> >>> >>> ? >>> [1] https://imgur.com/LgYdFKw >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From pekatete at hotmail.com Thu Oct 12 14:47:04 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Thu, 12 Oct 2017 14:47:04 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: , Message-ID: It is patently wrong to suggest ViaBTC said they?ll mine both chains. What they actually said (and the linked tweet confirms) is that they?ll support both chains to give access to users (quite distinct from mine both chains). I?m inclined to think that if they do mine the legacy chain, it?ll be to produce coinbase tx only blocks to hasten it?s demise. >Probably viaBTC was bigger in a way because historically they have been a kind of proxy for Bitmain, they said they would mine both chains. https://twitter.com/yhaiyang/status/917423471507890176 >I believe that's what all miners will do anyway, because you cant mine unprofitably, hashrate follows profitability. But it likely speaks to what Bitmain also intends to do - I would hazard a guess. >Adam _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaredr26 at gmail.com Thu Oct 12 15:34:36 2017 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Thu, 12 Oct 2017 08:34:36 -0700 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: > 1. Allow the implementation of Schnorr signatures AFAIK this isn't being blocked on 2x in any way. > 2. In parallel, address the issues raised on the segwit2x codebase What issues? Mandatory replay protection is the big "issue" and that is largely a political fight, not a technical one to be "addressed." There are significant downsides to it for many parties, which is why it isn't being done. > 3. Unfreeze the segwit2x code, and seek a dialogue with core on a timeline for a 2x block size increase Unfortunately the Core development team has shown absolutely zero interest in compromising in any way except their own you'll-do-what-we-say compromises, which is a big part of what got us in this mess. Even if they did show interest in such a thing, there's basically zero trust from anyone not already aligned with them. That lack of trust in Core's reasonableness is a big part of why BCH happened in the first place; BCH might not have had enough momentum to get started if 2x had required a hardfork at the segwit activation moment instead of pre-activating based on future promises. This split in the community runs DEEP. > The reason being that we've just had a capacity upgrade and segwit is starting to kick in. Lol. The daily average blocksize has literally only been above 1mb two days since segwit activated[1]. The weekly average blocksize has literally not even recovered[2] from the pre-segwit mempool crisis began to seriously damage real uses of Bitcoin[3]. Meanwhile the mempools had more than 15k transactions pending for ~20 out of the last 48 hours[4], and the median transaction fee paid is not only higher than the mid-august pre-segwit median but it is actually rising for the last 14 days[5]. Segwit2x activated segwit. Backing out of the 2x part is not an option, even if Segwit had solved the problems it was supposed to solve, which it clearly has not. [1] - https://blockchain.info/charts/avg-block-size?timespan=30days [2] - https://blockchain.info/charts/avg-block-size?timespan=180days&daysAverageString=7 [3] - https://blog.bitspark.io/bitspark-switching-to-bitshares-for-remittances/ and https://cointelegraph.com/news/bitcoin-fees-chasing-businesses-away-dash-litecoin-benefit [4] - https://jochen-hoenicke.de/queue/#2d [5] - https://bitinfocharts.com/comparison/median_transaction_fee-btc-sma7.html#1y I have a feeling this email message will spawn more political conversation, so I will do my best to not respond further. Jared On Thu, Oct 12, 2017 at 6:41 AM, Melvin Carvalho via Bitcoin-segwit2x wrote: > > > On 12 October 2017 at 14:49, Peter BitcoinReminder.com via Bitcoin-segwit2x > wrote: >> >> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly >> non-NYA blocks, are you still going to fork off in November - splitting the >> chain intentionally? > > > This is good new information, thanks! > > A sensible approach might be: > > 1. Allow the implementation of Schnorr signatures > 2. In parallel, address the issues raised on the segwit2x codebase > 3. Unfreeze the segwit2x code, and seek a dialogue with core on a timeline > for a 2x block size increase > > The reason being that we've just had a capacity upgrade and segwit is > starting to kick in. Blocks are less congested now. Schnorr will likely > give another 30% capacity quite soon. This will allow general hardware > increases to make moving to 2x blocks, without a contentious hard fork, more > practical. > > Just my 2 cents. > >> >> >> ? >> [1] https://imgur.com/LgYdFKw >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From jeff at bloq.com Thu Oct 12 15:50:27 2017 From: jeff at bloq.com (Jeff Garzik) Date: Thu, 12 Oct 2017 08:50:27 -0700 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: Answers inline... On Oct 12, 2017 6:41 AM, "Melvin Carvalho via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: On 12 October 2017 at 14:49, Peter BitcoinReminder.com via Bitcoin-segwit2x wrote: > Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly > non-NYA blocks, are you still going to fork off in November - splitting the > chain intentionally? > This is good new information, thanks! It is information over a month old. See counter. A sensible approach might be: 1. Allow the implementation of Schnorr signatures Very risky- this impacts tx message integrity and authenticity. Changing transaction signing code impacts private keys and other security sensitive surfaces. In comparison, changing the size of the message container - a block - does not impact message integrity and authenticity. 2. In parallel, address the issues raised on the segwit2x codebase Link to the issues filed? 3. Unfreeze the segwit2x code, and seek a dialogue with core on a timeline for a 2x block size increase All field evidence points to continual delays, never a base block size increase as has been planned since 2010. Repeated attempts at dialogue just result in attacks, delays, The Familiar Stuff. The reason being that we've just had a capacity upgrade and segwit is starting to kick in. Blocks are less congested now. Schnorr will likely give another 30% capacity quite soon. This will allow general hardware increases to make moving to 2x blocks, without a contentious hard fork, more practical. It is extremely contentious to continue blocking a block size increase. Continued delay is part of what produced the gridlock that we saw over the past two years. Just my 2 cents. > > ? > [1] https://imgur.com/LgYdFKw > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From segwit2x_mailinglist at bitcoinreminder.com Thu Oct 12 15:53:37 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Thu, 12 Oct 2017 17:53:37 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> I was just pointing out that F2Pool just stopped NYA signaling some hours ago - which is a new information. And still nobody answered my question if you know acknowledge that there will be a chain split for sure and you are intentionally splitting off? > Am 12.10.2017 um 17:50 schrieb Jeff Garzik : > > It is information over a month old. See counter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at ob1.io Thu Oct 12 15:56:25 2017 From: brian at ob1.io (Brian Hoffman) Date: Thu, 12 Oct 2017 15:56:25 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> Message-ID: Where have you been? Wang Chun has said they never were agreed to NYA post segwit so what?s your point exactly? It?s obvious that there will be a chain split at this point. On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via Bitcoin-segwit2x wrote: > I was just pointing out that F2Pool just stopped NYA signaling some hours > ago - which is a new information. > > And still nobody answered my question if you know acknowledge that there > will be a chain split for sure and you are intentionally splitting off? > > > Am 12.10.2017 um 17:50 schrieb Jeff Garzik : > > It is information over a month old. See counter. > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- Brian Hoffman President OB1 (571) 205-4967 -------------- next part -------------- An HTML attachment was scrubbed... URL: From segwit2x_mailinglist at bitcoinreminder.com Thu Oct 12 16:02:12 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Thu, 12 Oct 2017 18:02:12 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> Message-ID: I was just surprised, since the general wording here was that ?95 % of the hashpower is supporting the NYA? - which isn?t the case obviously. Is there any percentage (75%, 65%, 40%?) where you would stop this fork and reconsider the timeframe? > Am 12.10.2017 um 17:56 schrieb Brian Hoffman : > > Where have you been? Wang Chun has said they never were agreed to NYA post segwit so what?s your point exactly? > > It?s obvious that there will be a chain split at this point. > > > > On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via Bitcoin-segwit2x > wrote: > I was just pointing out that F2Pool just stopped NYA signaling some hours ago - which is a new information. > > And still nobody answered my question if you know acknowledge that there will be a chain split for sure and you are intentionally splitting off? > > >> Am 12.10.2017 um 17:50 schrieb Jeff Garzik >: >> >> It is information over a month old. See counter. > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- > Brian Hoffman > President > OB1 > (571) 205-4967 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at shapeshift.io Thu Oct 12 16:37:33 2017 From: erik at shapeshift.io (Erik Voorhees) Date: Thu, 12 Oct 2017 12:37:33 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> Message-ID: The F2Pool news is not news, it was known since at least Aug 31: https://www.coindesk.com/f2pool-reneges-mining-pool-pulls-segwit2x-support-hard-fork/ Kind regards, -Erik Voorhees CEO ShapeShift AG On October 12, 2017 at 10:03:01 AM, Peter BitcoinReminder.com via Bitcoin-segwit2x (bitcoin-segwit2x at lists.linuxfoundation.org) wrote: I was just surprised, since the general wording here was that ?95 % of the hashpower is supporting the NYA? - which isn?t the case obviously. Is there any percentage (75%, 65%, 40%?) where you would stop this fork and reconsider the timeframe? Am 12.10.2017 um 17:56 schrieb Brian Hoffman : Where have you been? Wang Chun has said they never were agreed to NYA post segwit so what?s your point exactly? It?s obvious that there will be a chain split at this point. On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via Bitcoin-segwit2x wrote: > I was just pointing out that F2Pool just stopped NYA signaling some hours > ago - which is a new information. > > And still nobody answered my question if you know acknowledge that there > will be a chain split for sure and you are intentionally splitting off? > > > Am 12.10.2017 um 17:50 schrieb Jeff Garzik : > > It is information over a month old. See counter. > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- Brian Hoffman President OB1 (571) 205-4967 _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at blockstream.com Thu Oct 12 16:53:00 2017 From: adam at blockstream.com (Dr Adam Back) Date: Thu, 12 Oct 2017 18:53:00 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> Message-ID: Well no offence guys, but you cant have it both ways "95% support" and then "no we always knew that 10% wasnt supporting" the math doesn't add up. Not that it really matters, but for accuracy. Adam On Thu, Oct 12, 2017 at 6:37 PM, Erik Voorhees via Bitcoin-segwit2x wrote: > The F2Pool news is not news, it was known since at least Aug 31: > https://www.coindesk.com/f2pool-reneges-mining-pool-pulls-segwit2x-support-hard-fork/ > > > > Kind regards, > -Erik Voorhees > CEO ShapeShift AG > > On October 12, 2017 at 10:03:01 AM, Peter BitcoinReminder.com via > Bitcoin-segwit2x (bitcoin-segwit2x at lists.linuxfoundation.org) wrote: > > I was just surprised, since the general wording here was that ?95 % of the > hashpower is supporting the NYA? - which isn?t the case obviously. > > Is there any percentage (75%, 65%, 40%?) where you would stop this fork and > reconsider the timeframe? > > Am 12.10.2017 um 17:56 schrieb Brian Hoffman : > > Where have you been? Wang Chun has said they never were agreed to NYA post > segwit so what?s your point exactly? > > It?s obvious that there will be a chain split at this point. > > > > On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via > Bitcoin-segwit2x wrote: >> >> I was just pointing out that F2Pool just stopped NYA signaling some hours >> ago - which is a new information. >> >> And still nobody answered my question if you know acknowledge that there >> will be a chain split for sure and you are intentionally splitting off? >> >> >> Am 12.10.2017 um 17:50 schrieb Jeff Garzik : >> >> It is information over a month old. See counter. >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- > Brian Hoffman > President > OB1 > (571) 205-4967 > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From mike at bitgo.com Thu Oct 12 16:57:21 2017 From: mike at bitgo.com (Mike Belshe) Date: Thu, 12 Oct 2017 09:57:21 -0700 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> Message-ID: Only f2pool should speak for f2pool What we know is that want Chun tweeted in sept that he doesn't support segwit2x. We also know that as of this moment f2pool is still signalling support for segwit2x on a daily basis in spite of those tweets These two things contradict each other and I think only f2pool can clarify Mike On Oct 12, 2017 9:53 AM, "Dr Adam Back via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Well no offence guys, but you cant have it both ways "95% support" and > then "no we always knew that 10% wasnt supporting" the math doesn't > add up. > > Not that it really matters, but for accuracy. > > Adam > > > On Thu, Oct 12, 2017 at 6:37 PM, Erik Voorhees via Bitcoin-segwit2x > wrote: > > The F2Pool news is not news, it was known since at least Aug 31: > > https://www.coindesk.com/f2pool-reneges-mining-pool- > pulls-segwit2x-support-hard-fork/ > > > > > > > > Kind regards, > > -Erik Voorhees > > CEO ShapeShift AG > > > > On October 12, 2017 at 10:03:01 AM, Peter BitcoinReminder.com via > > Bitcoin-segwit2x (bitcoin-segwit2x at lists.linuxfoundation.org) wrote: > > > > I was just surprised, since the general wording here was that ?95 % of > the > > hashpower is supporting the NYA? - which isn?t the case obviously. > > > > Is there any percentage (75%, 65%, 40%?) where you would stop this fork > and > > reconsider the timeframe? > > > > Am 12.10.2017 um 17:56 schrieb Brian Hoffman : > > > > Where have you been? Wang Chun has said they never were agreed to NYA > post > > segwit so what?s your point exactly? > > > > It?s obvious that there will be a chain split at this point. > > > > > > > > On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via > > Bitcoin-segwit2x wrote: > >> > >> I was just pointing out that F2Pool just stopped NYA signaling some > hours > >> ago - which is a new information. > >> > >> And still nobody answered my question if you know acknowledge that there > >> will be a chain split for sure and you are intentionally splitting off? > >> > >> > >> Am 12.10.2017 um 17:50 schrieb Jeff Garzik : > >> > >> It is information over a month old. See counter. > >> > >> > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > -- > > Brian Hoffman > > President > > OB1 > > (571) 205-4967 > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Thu Oct 12 17:00:06 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Thu, 12 Oct 2017 17:00:06 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com>, , Message-ID: Whatever he may say he agreed to, the facts are that he voted to activate and lock-in SegWit2x on bit 4 (before voting on bit 1 to get the legacy clients activated and locked-in too). Despite the sabre rattling, f2pool will end up on the majority chain as they are not in the space to prop up core. From: Brian Hoffman via Bitcoin-segwit2x Sent: 12 October 2017 16:56 To: Peter BitcoinReminder.com; Peter Todd via Bitcoin-segwit2x Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? Where have you been? Wang Chun has said they never were agreed to NYA post segwit so what?s your point exactly? It?s obvious that there will be a chain split at this point. On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via Bitcoin-segwit2x > wrote: I was just pointing out that F2Pool just stopped NYA signaling some hours ago - which is a new information. And still nobody answered my question if you know acknowledge that there will be a chain split for sure and you are intentionally splitting off? Am 12.10.2017 um 17:50 schrieb Jeff Garzik >: It is information over a month old. See counter. _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -- Brian Hoffman President OB1 (571) 205-4967 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Thu Oct 12 17:04:57 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Thu, 12 Oct 2017 17:04:57 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> , Message-ID: Actually, the math does add up, if you apply some common sense, as f2pool stopping signalling for NYA does not mean they are going to point all their hash to the legacy chain post Nov HF. A good guide of how much they?ll point at legacy is the same proportion of the remaining network hash distribution thus at best 2% for legacy. From: Dr Adam Back via Bitcoin-segwit2x Sent: 12 October 2017 17:53 To: Erik Voorhees Cc: Peter Todd via Bitcoin-segwit2x Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? Well no offence guys, but you cant have it both ways "95% support" and then "no we always knew that 10% wasnt supporting" the math doesn't add up. Not that it really matters, but for accuracy. Adam On Thu, Oct 12, 2017 at 6:37 PM, Erik Voorhees via Bitcoin-segwit2x wrote: > The F2Pool news is not news, it was known since at least Aug 31: > https://www.coindesk.com/f2pool-reneges-mining-pool-pulls-segwit2x-support-hard-fork/ > > > > Kind regards, > -Erik Voorhees > CEO ShapeShift AG > > On October 12, 2017 at 10:03:01 AM, Peter BitcoinReminder.com via > Bitcoin-segwit2x (bitcoin-segwit2x at lists.linuxfoundation.org) wrote: > > I was just surprised, since the general wording here was that ?95 % of the > hashpower is supporting the NYA? - which isn?t the case obviously. > > Is there any percentage (75%, 65%, 40%?) where you would stop this fork and > reconsider the timeframe? > > Am 12.10.2017 um 17:56 schrieb Brian Hoffman : > > Where have you been? Wang Chun has said they never were agreed to NYA post > segwit so what?s your point exactly? > > It?s obvious that there will be a chain split at this point. > > > > On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via > Bitcoin-segwit2x wrote: >> >> I was just pointing out that F2Pool just stopped NYA signaling some hours >> ago - which is a new information. >> >> And still nobody answered my question if you know acknowledge that there >> will be a chain split for sure and you are intentionally splitting off? >> >> >> Am 12.10.2017 um 17:50 schrieb Jeff Garzik : >> >> It is information over a month old. See counter. >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- > Brian Hoffman > President > OB1 > (571) 205-4967 > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.hilliard1 at gmail.com Thu Oct 12 17:13:43 2017 From: james.hilliard1 at gmail.com (James Hilliard) Date: Thu, 12 Oct 2017 11:13:43 -0600 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> Message-ID: That's incorrect, f2pool was signalling on bit 1 well before bit 4. The 2X hard fork activation logic in btc1 is also not triggered by bit 4, it is triggered by the bit 1 activation of segwit regardless of whether or not there was a bit 4 activation, bit 4 activation only triggered BIP91 mandatory signalling. On Thu, Oct 12, 2017 at 11:00 AM, Phillip Katete via Bitcoin-segwit2x wrote: > Whatever he may say he agreed to, the facts are that he voted to activate > and lock-in SegWit2x on bit 4 (before voting on bit 1 to get the legacy > clients activated and locked-in too). > > Despite the sabre rattling, f2pool will end up on the majority chain as they > are not in the space to prop up core. > > > > From: Brian Hoffman via Bitcoin-segwit2x > Sent: 12 October 2017 16:56 > To: Peter BitcoinReminder.com; Peter Todd via Bitcoin-segwit2x > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > happening? > > > > Where have you been? Wang Chun has said they never were agreed to NYA post > segwit so what?s your point exactly? > > > > It?s obvious that there will be a chain split at this point. > > > > > > > > On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via > Bitcoin-segwit2x wrote: > > I was just pointing out that F2Pool just stopped NYA signaling some hours > ago - which is a new information. > > > > And still nobody answered my question if you know acknowledge that there > will be a chain split for sure and you are intentionally splitting off? > > > > > > Am 12.10.2017 um 17:50 schrieb Jeff Garzik : > > > > It is information over a month old. See counter. > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- > > Brian Hoffman > > President > > OB1 > > (571) 205-4967 > > > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From pekatete at hotmail.com Thu Oct 12 17:18:09 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Thu, 12 Oct 2017 17:18:09 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> , Message-ID: Thanks for clearing that up, at least we are now clear that without SegWit2x, segwit would never have been activated seeing the pre bit 4 signalling on bit 1 never sustained anything near 35% (thus segwit had no chance of being activated). From: James Hilliard Sent: 12 October 2017 18:13 To: Phillip Katete Cc: brian at ob1.io; bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? That's incorrect, f2pool was signalling on bit 1 well before bit 4. The 2X hard fork activation logic in btc1 is also not triggered by bit 4, it is triggered by the bit 1 activation of segwit regardless of whether or not there was a bit 4 activation, bit 4 activation only triggered BIP91 mandatory signalling. On Thu, Oct 12, 2017 at 11:00 AM, Phillip Katete via Bitcoin-segwit2x wrote: > Whatever he may say he agreed to, the facts are that he voted to activate > and lock-in SegWit2x on bit 4 (before voting on bit 1 to get the legacy > clients activated and locked-in too). > > Despite the sabre rattling, f2pool will end up on the majority chain as they > are not in the space to prop up core. > > > > From: Brian Hoffman via Bitcoin-segwit2x > Sent: 12 October 2017 16:56 > To: Peter BitcoinReminder.com; Peter Todd via Bitcoin-segwit2x > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > happening? > > > > Where have you been? Wang Chun has said they never were agreed to NYA post > segwit so what?s your point exactly? > > > > It?s obvious that there will be a chain split at this point. > > > > > > > > On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via > Bitcoin-segwit2x wrote: > > I was just pointing out that F2Pool just stopped NYA signaling some hours > ago - which is a new information. > > > > And still nobody answered my question if you know acknowledge that there > will be a chain split for sure and you are intentionally splitting off? > > > > > > Am 12.10.2017 um 17:50 schrieb Jeff Garzik : > > > > It is information over a month old. See counter. > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- > > Brian Hoffman > > President > > OB1 > > (571) 205-4967 > > > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.hilliard1 at gmail.com Thu Oct 12 17:31:15 2017 From: james.hilliard1 at gmail.com (James Hilliard) Date: Thu, 12 Oct 2017 11:31:15 -0600 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> Message-ID: SegWit2x consists of BIP91 and a 2X HF, however bit 4 is not required to activate the 2X HF, it's only used to activate BIP91. Bit 4 signalling is not an accurate indication of 2X HF support, it's only an indicator for BIP91 support. On Thu, Oct 12, 2017 at 11:18 AM, Phillip Katete wrote: > Thanks for clearing that up, at least we are now clear that without > SegWit2x, segwit would never have been activated seeing the pre bit 4 > signalling on bit 1 never sustained anything near 35% (thus segwit had no > chance of being activated). > > > > From: James Hilliard > Sent: 12 October 2017 18:13 > To: Phillip Katete > Cc: brian at ob1.io; bitcoin-segwit2x at lists.linuxfoundation.org > > > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > happening? > > > > That's incorrect, f2pool was signalling on bit 1 well before bit 4. > The 2X hard fork activation logic in btc1 is also not triggered by bit > 4, it is triggered by the bit 1 activation of segwit regardless of > whether or not there was a bit 4 activation, bit 4 activation only > triggered BIP91 mandatory signalling. > > On Thu, Oct 12, 2017 at 11:00 AM, Phillip Katete via Bitcoin-segwit2x > wrote: >> Whatever he may say he agreed to, the facts are that he voted to activate >> and lock-in SegWit2x on bit 4 (before voting on bit 1 to get the legacy >> clients activated and locked-in too). >> >> Despite the sabre rattling, f2pool will end up on the majority chain as >> they >> are not in the space to prop up core. >> >> >> >> From: Brian Hoffman via Bitcoin-segwit2x >> Sent: 12 October 2017 16:56 >> To: Peter BitcoinReminder.com; Peter Todd via Bitcoin-segwit2x >> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still >> happening? >> >> >> >> Where have you been? Wang Chun has said they never were agreed to NYA post >> segwit so what?s your point exactly? >> >> >> >> It?s obvious that there will be a chain split at this point. >> >> >> >> >> >> >> >> On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via >> Bitcoin-segwit2x wrote: >> >> I was just pointing out that F2Pool just stopped NYA signaling some hours >> ago - which is a new information. >> >> >> >> And still nobody answered my question if you know acknowledge that there >> will be a chain split for sure and you are intentionally splitting off? >> >> >> >> >> >> Am 12.10.2017 um 17:50 schrieb Jeff Garzik : >> >> >> >> It is information over a month old. See counter. >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> -- >> >> Brian Hoffman >> >> President >> >> OB1 >> >> (571) 205-4967 >> >> >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > From pekatete at hotmail.com Thu Oct 12 17:40:33 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Thu, 12 Oct 2017 17:40:33 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> , Message-ID: We can safely and accurately deduce overwhelming support for 2x from bit 4/BIP91 support because segwit only voting/signalling, despite being open for an extended period of time, never even achieved / sustained even half the required threshold until the NYA. From: James Hilliard Sent: 12 October 2017 18:31 To: Phillip Katete Cc: brian at ob1.io; bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? SegWit2x consists of BIP91 and a 2X HF, however bit 4 is not required to activate the 2X HF, it's only used to activate BIP91. Bit 4 signalling is not an accurate indication of 2X HF support, it's only an indicator for BIP91 support. On Thu, Oct 12, 2017 at 11:18 AM, Phillip Katete wrote: > Thanks for clearing that up, at least we are now clear that without > SegWit2x, segwit would never have been activated seeing the pre bit 4 > signalling on bit 1 never sustained anything near 35% (thus segwit had no > chance of being activated). > > > > From: James Hilliard > Sent: 12 October 2017 18:13 > To: Phillip Katete > Cc: brian at ob1.io; bitcoin-segwit2x at lists.linuxfoundation.org > > > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > happening? > > > > That's incorrect, f2pool was signalling on bit 1 well before bit 4. > The 2X hard fork activation logic in btc1 is also not triggered by bit > 4, it is triggered by the bit 1 activation of segwit regardless of > whether or not there was a bit 4 activation, bit 4 activation only > triggered BIP91 mandatory signalling. > > On Thu, Oct 12, 2017 at 11:00 AM, Phillip Katete via Bitcoin-segwit2x > wrote: >> Whatever he may say he agreed to, the facts are that he voted to activate >> and lock-in SegWit2x on bit 4 (before voting on bit 1 to get the legacy >> clients activated and locked-in too). >> >> Despite the sabre rattling, f2pool will end up on the majority chain as >> they >> are not in the space to prop up core. >> >> >> >> From: Brian Hoffman via Bitcoin-segwit2x >> Sent: 12 October 2017 16:56 >> To: Peter BitcoinReminder.com; Peter Todd via Bitcoin-segwit2x >> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still >> happening? >> >> >> >> Where have you been? Wang Chun has said they never were agreed to NYA post >> segwit so what?s your point exactly? >> >> >> >> It?s obvious that there will be a chain split at this point. >> >> >> >> >> >> >> >> On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via >> Bitcoin-segwit2x wrote: >> >> I was just pointing out that F2Pool just stopped NYA signaling some hours >> ago - which is a new information. >> >> >> >> And still nobody answered my question if you know acknowledge that there >> will be a chain split for sure and you are intentionally splitting off? >> >> >> >> >> >> Am 12.10.2017 um 17:50 schrieb Jeff Garzik : >> >> >> >> It is information over a month old. See counter. >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> -- >> >> Brian Hoffman >> >> President >> >> OB1 >> >> (571) 205-4967 >> >> >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Thu Oct 12 18:05:56 2017 From: bitpico at icloud.com (bitPico) Date: Thu, 12 Oct 2017 14:05:56 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> Message-ID: This list is for development purposes not hearsay or speculation. If F2Pool would like to say something this is the place otherwise it?s hearsay. Have an excellent day! > On Oct 12, 2017, at 1:40 PM, Phillip Katete via Bitcoin-segwit2x wrote: > > We can safely and accurately deduce overwhelming support for 2x from bit 4/BIP91 support because segwit only voting/signalling, despite being open for an extended period of time, never even achieved / sustained even half the required threshold until the NYA. > > From: James Hilliard > Sent: 12 October 2017 18:31 > To: Phillip Katete > Cc: brian at ob1.io; bitcoin-segwit2x at lists.linuxfoundation.org > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > > SegWit2x consists of BIP91 and a 2X HF, however bit 4 is not required > to activate the 2X HF, it's only used to activate BIP91. Bit 4 > signalling is not an accurate indication of 2X HF support, it's only > an indicator for BIP91 support. > > On Thu, Oct 12, 2017 at 11:18 AM, Phillip Katete wrote: > > Thanks for clearing that up, at least we are now clear that without > > SegWit2x, segwit would never have been activated seeing the pre bit 4 > > signalling on bit 1 never sustained anything near 35% (thus segwit had no > > chance of being activated). > > > > > > > > From: James Hilliard > > Sent: 12 October 2017 18:13 > > To: Phillip Katete > > Cc: brian at ob1.io; bitcoin-segwit2x at lists.linuxfoundation.org > > > > > > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > > happening? > > > > > > > > That's incorrect, f2pool was signalling on bit 1 well before bit 4. > > The 2X hard fork activation logic in btc1 is also not triggered by bit > > 4, it is triggered by the bit 1 activation of segwit regardless of > > whether or not there was a bit 4 activation, bit 4 activation only > > triggered BIP91 mandatory signalling. > > > > On Thu, Oct 12, 2017 at 11:00 AM, Phillip Katete via Bitcoin-segwit2x > > wrote: > >> Whatever he may say he agreed to, the facts are that he voted to activate > >> and lock-in SegWit2x on bit 4 (before voting on bit 1 to get the legacy > >> clients activated and locked-in too). > >> > >> Despite the sabre rattling, f2pool will end up on the majority chain as > >> they > >> are not in the space to prop up core. > >> > >> > >> > >> From: Brian Hoffman via Bitcoin-segwit2x > >> Sent: 12 October 2017 16:56 > >> To: Peter BitcoinReminder.com; Peter Todd via Bitcoin-segwit2x > >> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > >> happening? > >> > >> > >> > >> Where have you been? Wang Chun has said they never were agreed to NYA post > >> segwit so what?s your point exactly? > >> > >> > >> > >> It?s obvious that there will be a chain split at this point. > >> > >> > >> > >> > >> > >> > >> > >> On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via > >> Bitcoin-segwit2x wrote: > >> > >> I was just pointing out that F2Pool just stopped NYA signaling some hours > >> ago - which is a new information. > >> > >> > >> > >> And still nobody answered my question if you know acknowledge that there > >> will be a chain split for sure and you are intentionally splitting off? > >> > >> > >> > >> > >> > >> Am 12.10.2017 um 17:50 schrieb Jeff Garzik : > >> > >> > >> > >> It is information over a month old. See counter. > >> > >> > >> > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > >> -- > >> > >> Brian Hoffman > >> > >> President > >> > >> OB1 > >> > >> (571) 205-4967 > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From nperrymond at hotmail.com Thu Oct 12 18:36:55 2017 From: nperrymond at hotmail.com (Nigel Perrymond) Date: Thu, 12 Oct 2017 18:36:55 +0000 Subject: [Bitcoin-segwit2x] Segwit2x a go Message-ID: Subscribe me for mailing list Sent from my Windows 10 phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Thu Oct 12 18:57:28 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Thu, 12 Oct 2017 18:57:28 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> , Message-ID: That link contains the word ?safelinks? and it triggers alarms for me but having read a few of your postings elsewhere, I trust the link even less. But I suppose we better limit posts to tech discussion (as the handbags have already started flying). From: Dr Adam Back Sent: 12 October 2017 19:06 To: Phillip Katete Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? To understand more about mining economics and the creation vs verification mechanism between miners and nodes, I recommend this article by Prof Emin Sirer which explains it quite clearly. https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhackingdistributed.com%2F2016%2F01%2F03%2Ftime-for-bitcoin-user-voice%2F&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=vmHa78wd%2BIZzrO6hH6ap5654%2BSDlXu3FGTNScKRWDQg%3D&reserved=0 Adam On Thu, Oct 12, 2017 at 7:00 PM, Phillip Katete via Bitcoin-segwit2x wrote: > Whatever he may say he agreed to, the facts are that he voted to activate > and lock-in SegWit2x on bit 4 (before voting on bit 1 to get the legacy > clients activated and locked-in too). > > Despite the sabre rattling, f2pool will end up on the majority chain as they > are not in the space to prop up core. > > > > From: Brian Hoffman via Bitcoin-segwit2x > Sent: 12 October 2017 16:56 > To: Peter BitcoinReminder.com; Peter Todd via Bitcoin-segwit2x > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > happening? > > > > Where have you been? Wang Chun has said they never were agreed to NYA post > segwit so what?s your point exactly? > > > > It?s obvious that there will be a chain split at this point. > > > > > > > > On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via > Bitcoin-segwit2x wrote: > > I was just pointing out that F2Pool just stopped NYA signaling some hours > ago - which is a new information. > > > > And still nobody answered my question if you know acknowledge that there > will be a chain split for sure and you are intentionally splitting off? > > > > > > Am 12.10.2017 um 17:50 schrieb Jeff Garzik : > > > > It is information over a month old. See counter. > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=qUYCDGIAGw7y1%2Fsskts%2F0SBdhzqyWDsldjkufCQMsXA%3D&reserved=0 > > -- > > Brian Hoffman > > President > > OB1 > > (571) 205-4967 > > > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=qUYCDGIAGw7y1%2Fsskts%2F0SBdhzqyWDsldjkufCQMsXA%3D&reserved=0 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Thu Oct 12 19:53:31 2017 From: bitpico at icloud.com (bitPico) Date: Thu, 12 Oct 2017 15:53:31 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> Without you knowing why they stopped signaling this is FUD and off-topic for this list. Please instead let F2Pool state their own opinion here since yours doesn?t count. If you think your opinion does count then show us your blocks that your pool has produced; until then you are simply an end-user and still you are off-topic for this list. If you need ELI5 for how this list works please let us know and we can help you Peter Todd. Have a groovy day! > On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via Bitcoin-segwit2x wrote: > > Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly non-NYA blocks, are you still going to fork off in November - splitting the chain intentionally? > > ? > [1] https://imgur.com/LgYdFKw > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From segwit2x_mailinglist at bitcoinreminder.com Thu Oct 12 19:57:10 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Thu, 12 Oct 2017 21:57:10 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> Message-ID: I?m not Peter Todd, we just share the same (nice) firstname. I still didn?t get an answer what the minimum amount of hashpower is required, before the fork is getting delayed? We have to plan time for the whole security measures etc, so I think it?s reasonable to get more information about this? > Am 12.10.2017 um 21:53 schrieb bitPico : > > Without you knowing why they stopped signaling this is FUD and off-topic for this list. Please instead let F2Pool state their own opinion here since yours doesn?t count. If you think your opinion does count then show us your blocks that your pool has produced; until then you are simply an end-user and still you are off-topic for this list. If you need ELI5 for how this list works please let us know and we can help you Peter Todd. > > Have a groovy day! > >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via Bitcoin-segwit2x > wrote: >> >> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly non-NYA blocks, are you still going to fork off in November - splitting the chain intentionally? >> >> ? >> [1] https://imgur.com/LgYdFKw >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Thu Oct 12 20:04:47 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Thu, 12 Oct 2017 20:04:47 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> References: , <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> Message-ID: @bitPico - Stop tossing your handbags as you are only adding to the noise (off-topic for this list). From: bitPico via Bitcoin-segwit2x Sent: 12 October 2017 20:53 To: Peter BitcoinReminder.com Cc: Peter Todd via Bitcoin-segwit2x Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? Without you knowing why they stopped signaling this is FUD and off-topic for this list. Please instead let F2Pool state their own opinion here since yours doesn?t count. If you think your opinion does count then show us your blocks that your pool has produced; until then you are simply an end-user and still you are off-topic for this list. If you need ELI5 for how this list works please let us know and we can help you Peter Todd. Have a groovy day! On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via Bitcoin-segwit2x > wrote: Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly non-NYA blocks, are you still going to fork off in November - splitting the chain intentionally? ? [1] https://imgur.com/LgYdFKw _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Thu Oct 12 20:07:51 2017 From: bitpico at icloud.com (bitPico) Date: Thu, 12 Oct 2017 16:07:51 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> Message-ID: <1190648C-811C-498C-83F3-5ACCF69A11A1@icloud.com> Our pool is currently running at 1.72% of the entire global network hash rate. We are in the process of deploying approximately an additional 3-4% in the next 14 days. Even if the false rumor that F2Pool was backing out of mining 2x we already have the ASIC?s and infrastructure to make them irrelevant. Regardless this is a working group and F2Pool or any other pools are welcome to come voice their opinions here however hearsay is simply hearsay. To answer your question there will be no 1x chain as we have proven mathematically in this list; if you want read it if you require further information. Have a groovy day sir Peter! > On Oct 12, 2017, at 3:57 PM, Peter BitcoinReminder.com wrote: > > I still didn?t get an answer what the minimum amount of hashpower is required, before the fork is getting delayed? > From bitpico at icloud.com Thu Oct 12 20:09:37 2017 From: bitpico at icloud.com (bitPico) Date: Thu, 12 Oct 2017 16:09:37 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> Message-ID: This is a working group mailing list not to be used for anything else. No insults on this list please and stay on topic. Have a groovy day sir!. > On Oct 12, 2017, at 4:04 PM, Phillip Katete wrote: > > @bitPico - Stop tossing your handbags as you are only adding to the noise (off-topic for this list). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From selkisr at gmail.com Thu Oct 12 20:30:58 2017 From: selkisr at gmail.com (Ryan Selkis) Date: Thu, 12 Oct 2017 16:30:58 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> Message-ID: This seems to be a relevant technical question: "If there are other miner defections in the coming weeks, what is the minimum amount of hashpower required before the fork gets delayed?" I am not convinced one of this group's primary assumptions - that it represents the true economic majority of bitcoin - is correct, and it seems more evidence is accumulating that further contradicts this (e.g. rising volumes and growing spread between BT1 and BT2 on Bitfinex). We could see additional tangible evidence of that lack of support if NYA supporting orgs see an upcoming surge in withdrawals (like Coinbase with the BCH fork). 2x proponents have held up hashing power and their representation of the economic majority as the mandate to push this HF. If the true economic majority appears to reject 2x, it is possible other miners may back out of the NYA as well. I, too, would like to know the answer to Peter's question. Thanks, Ryan On Thu, Oct 12, 2017 at 3:57 PM, Peter BitcoinReminder.com via Bitcoin-segwit2x wrote: > I?m not Peter Todd, we just share the same (nice) firstname. > > I still didn?t get an answer what the minimum amount of hashpower is > required, before the fork is getting delayed? > We have to plan time for the whole security measures etc, so I think it?s > reasonable to get more information about this? > > > Am 12.10.2017 um 21:53 schrieb bitPico : > > Without you knowing why they stopped signaling this is FUD and off-topic > for this list. Please instead let F2Pool state their own opinion here > since yours doesn?t count. If you think your opinion does count then show > us your blocks that your pool has produced; until then you are simply an > end-user and still you are off-topic for this list. If you need ELI5 for > how this list works please let us know and we can help you Peter Todd. > > Have a groovy day! > > On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com > via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly > non-NYA blocks, are you still going to fork off in November - splitting the > chain intentionally? > > ? > [1] https://imgur.com/LgYdFKw > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- Ryan Selkis Hoboken, NJ 07030 C: 518-542-1077 Sign up for my Weekly Bit -------------- next part -------------- An HTML attachment was scrubbed... URL: From jheathco at gmail.com Thu Oct 12 20:31:31 2017 From: jheathco at gmail.com (John Heathco) Date: Thu, 12 Oct 2017 20:31:31 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> Message-ID: I don't believe there is an explicitly stated hashpower in which the fork would be "called off", but I would assume it is much lower than what is currently signaling, even if we make the (unwise) assumption that F2Pool would not contribute to mining 2x whatsoever. On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via Bitcoin-segwit2x wrote: > I?m not Peter Todd, we just share the same (nice) firstname. > > I still didn?t get an answer what the minimum amount of hashpower is > required, before the fork is getting delayed? > We have to plan time for the whole security measures etc, so I think it?s > reasonable to get more information about this? > > > Am 12.10.2017 um 21:53 schrieb bitPico : > > Without you knowing why they stopped signaling this is FUD and off-topic > for this list. Please instead let F2Pool state their own opinion here > since yours doesn?t count. If you think your opinion does count then show > us your blocks that your pool has produced; until then you are simply an > end-user and still you are off-topic for this list. If you need ELI5 for > how this list works please let us know and we can help you Peter Todd. > > Have a groovy day! > > On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com > via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly > non-NYA blocks, are you still going to fork off in November - splitting the > chain intentionally? > > ? > [1] https://imgur.com/LgYdFKw > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jheathco at gmail.com Thu Oct 12 20:34:36 2017 From: jheathco at gmail.com (John Heathco) Date: Thu, 12 Oct 2017 20:34:36 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> Message-ID: While we are on the topic of hypotheticals, we should also consider what 1x plans to do if >51% hashing power on that chain begins mining empty blocks. I do not condone the practice, but it is a major (and realistic) threat. On Thu, Oct 12, 2017 at 1:31 PM John Heathco wrote: > I don't believe there is an explicitly stated hashpower in which the fork > would be "called off", but I would assume it is much lower than what is > currently signaling, even if we make the (unwise) assumption that F2Pool > would not contribute to mining 2x whatsoever. > > > > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via > Bitcoin-segwit2x wrote: > >> I?m not Peter Todd, we just share the same (nice) firstname. >> >> I still didn?t get an answer what the minimum amount of hashpower is >> required, before the fork is getting delayed? >> We have to plan time for the whole security measures etc, so I think it?s >> reasonable to get more information about this? >> >> >> Am 12.10.2017 um 21:53 schrieb bitPico : >> >> Without you knowing why they stopped signaling this is FUD and off-topic >> for this list. Please instead let F2Pool state their own opinion here >> since yours doesn?t count. If you think your opinion does count then show >> us your blocks that your pool has produced; until then you are simply an >> end-user and still you are off-topic for this list. If you need ELI5 for >> how this list works please let us know and we can help you Peter Todd. >> >> Have a groovy day! >> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com >> via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly >> non-NYA blocks, are you still going to fork off in November - splitting the >> chain intentionally? >> >> ? >> [1] https://imgur.com/LgYdFKw >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kekcoin at protonmail.com Fri Oct 13 00:08:41 2017 From: kekcoin at protonmail.com (Kekcoin) Date: Thu, 12 Oct 2017 20:08:41 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> Message-ID: From the .outlook.com part of the domain it seems to me it's your hotmail injecting referral links in incoming emails. Perhaps reconsider your email provider and not publicly shame someone for trying to provide you with informational material. Hackingdistributed.com (as I can see is being linked in the referral) is Emin Sirer's real domain. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 12, 2017 6:57 PM > UTC Time: October 12, 2017 6:57 PM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: Dr Adam Back > bitcoin-segwit2x at lists.linuxfoundation.org > > That link contains the word ?safelinks? and it triggers alarms for me but having read a few of your postings elsewhere, I trust the link even less. > > But I suppose we better limit posts to tech discussion (as the handbags have already started flying). > > From: [Dr Adam Back](mailto:adam at blockstream.com) > Sent: 12 October 2017 19:06 > To: [Phillip Katete](mailto:pekatete at hotmail.com) > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > > To understand more about mining economics and the creation vs > verification mechanism between miners and nodes, I recommend this > article by Prof Emin Sirer which explains it quite clearly. > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhackingdistributed.com%2F2016%2F01%2F03%2Ftime-for-bitcoin-user-voice%2F&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=vmHa78wd%2BIZzrO6hH6ap5654%2BSDlXu3FGTNScKRWDQg%3D&reserved=0 > > Adam > > On Thu, Oct 12, 2017 at 7:00 PM, Phillip Katete via Bitcoin-segwit2x > wrote: >> Whatever he may say he agreed to, the facts are that he voted to activate >> and lock-in SegWit2x on bit 4 (before voting on bit 1 to get the legacy >> clients activated and locked-in too). >> >> Despite the sabre rattling, f2pool will end up on the majority chain as they >> are not in the space to prop up core. >> >> >> >> From: Brian Hoffman via Bitcoin-segwit2x >> Sent: 12 October 2017 16:56 >> To: Peter BitcoinReminder.com; Peter Todd via Bitcoin-segwit2x >> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still >> happening? >> >> >> >> Where have you been? Wang Chun has said they never were agreed to NYA post >> segwit so what?s your point exactly? >> >> >> >> It?s obvious that there will be a chain split at this point. >> >> >> >> >> >> >> >> On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via >> Bitcoin-segwit2x wrote: >> >> I was just pointing out that F2Pool just stopped NYA signaling some hours >> ago - which is a new information. >> >> >> >> And still nobody answered my question if you know acknowledge that there >> will be a chain split for sure and you are intentionally splitting off? >> >> >> >> >> >> Am 12.10.2017 um 17:50 schrieb Jeff Garzik : >> >> >> >> It is information over a month old. See counter. >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=qUYCDGIAGw7y1%2Fsskts%2F0SBdhzqyWDsldjkufCQMsXA%3D&reserved=0 >> >> -- >> >> Brian Hoffman >> >> President >> >> OB1 >> >> (571) 205-4967 >> >> >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=qUYCDGIAGw7y1%2Fsskts%2F0SBdhzqyWDsldjkufCQMsXA%3D&reserved=0 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Fri Oct 13 00:29:39 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Fri, 13 Oct 2017 00:29:39 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> , Message-ID: Honestly, I am neither trying to shame him nor have any intention of changing my email provider (probably had my Hotmail for as long as you are old!). The age old advice is not to click on links that you do not trust (and I have simply been transparent on this). But also the ?information? was not solicited (big red flag) and more pertinently I do not trust blockstream (or their employees), what with all the DDoS attacks, character assassinations, attempts to usurp the bitcoin consensus mechanism et al. You?d be the first to blame me if I picked up a nasty virus from the link. Better safe than sorry. From: Kekcoin Sent: 13 October 2017 01:08 To: Phillip Katete Cc: bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >From the .outlook.com part of the domain it seems to me it's your hotmail injecting referral links in incoming emails. Perhaps reconsider your email provider and not publicly shame someone for trying to provide you with informational material. Hackingdistributed.com (as I can see is being linked in the referral) is Emin Sirer's real domain. Sent with ProtonMail Secure Email. -------- Original Message -------- Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? Local Time: October 12, 2017 6:57 PM UTC Time: October 12, 2017 6:57 PM From: bitcoin-segwit2x at lists.linuxfoundation.org To: Dr Adam Back bitcoin-segwit2x at lists.linuxfoundation.org That link contains the word ?safelinks? and it triggers alarms for me but having read a few of your postings elsewhere, I trust the link even less. But I suppose we better limit posts to tech discussion (as the handbags have already started flying). From: Dr Adam Back Sent: 12 October 2017 19:06 To: Phillip Katete Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? To understand more about mining economics and the creation vs verification mechanism between miners and nodes, I recommend this article by Prof Emin Sirer which explains it quite clearly. https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhackingdistributed.com%2F2016%2F01%2F03%2Ftime-for-bitcoin-user-voice%2F&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=vmHa78wd%2BIZzrO6hH6ap5654%2BSDlXu3FGTNScKRWDQg%3D&reserved=0 Adam On Thu, Oct 12, 2017 at 7:00 PM, Phillip Katete via Bitcoin-segwit2x wrote: > Whatever he may say he agreed to, the facts are that he voted to activate > and lock-in SegWit2x on bit 4 (before voting on bit 1 to get the legacy > clients activated and locked-in too). > > Despite the sabre rattling, f2pool will end up on the majority chain as they > are not in the space to prop up core. > > > > From: Brian Hoffman via Bitcoin-segwit2x > Sent: 12 October 2017 16:56 > To: Peter BitcoinReminder.com; Peter Todd via Bitcoin-segwit2x > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > happening? > > > > Where have you been? Wang Chun has said they never were agreed to NYA post > segwit so what?s your point exactly? > > > > It?s obvious that there will be a chain split at this point. > > > > > > > > On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via > Bitcoin-segwit2x wrote: > > I was just pointing out that F2Pool just stopped NYA signaling some hours > ago - which is a new information. > > > > And still nobody answered my question if you know acknowledge that there > will be a chain split for sure and you are intentionally splitting off? > > > > > > Am 12.10.2017 um 17:50 schrieb Jeff Garzik : > > > > It is information over a month old. See counter. > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=qUYCDGIAGw7y1%2Fsskts%2F0SBdhzqyWDsldjkufCQMsXA%3D&reserved=0 > > -- > > Brian Hoffman > > President > > OB1 > > (571) 205-4967 > > > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=qUYCDGIAGw7y1%2Fsskts%2F0SBdhzqyWDsldjkufCQMsXA%3D&reserved=0 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kekcoin at protonmail.com Fri Oct 13 00:36:55 2017 From: kekcoin at protonmail.com (Kekcoin) Date: Thu, 12 Oct 2017 20:36:55 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> , Message-ID: Between your wild assumptions about my age, your fallacious implication that a younger age would imply lesser knowledge while simultaneously showcasing a severe lack of insight, and your random strawmen about what I would have said if this or that happened, I think I'll consider you a lost cause and cut this discussion short. Apologies to the list for the offtopic. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: RE: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 13, 2017 12:29 AM > UTC Time: October 13, 2017 12:29 AM > From: pekatete at hotmail.com > To: Kekcoin > bitcoin-segwit2x at lists.linuxfoundation.org > > Honestly, I am neither trying to shame him nor have any intention of changing my email provider (probably had my Hotmail for as long as you are old!). The age old advice is not to click on links that you do not trust (and I have simply been transparent on this). But also the ?information? was not solicited (big red flag) and more pertinently I do not trust blockstream (or their employees), what with all the DDoS attacks, character assassinations, attempts to usurp the bitcoin consensus mechanism et al. You?d be the first to blame me if I picked up a nasty virus from the link. Better safe than sorry. > > From: [Kekcoin](mailto:kekcoin at protonmail.com) > Sent: 13 October 2017 01:08 > To: [Phillip Katete](mailto:pekatete at hotmail.com) > Cc: bitcoin-segwit2x at lists.linuxfoundation.org > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > > From the .outlook.com part of the domain it seems to me it's your hotmail injecting referral links in incoming emails. Perhaps reconsider your email provider and not publicly shame someone for trying to provide you with informational material. Hackingdistributed.com (as I can see is being linked in the referral) is Emin Sirer's real domain. > > Sent with [ProtonMail](https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotonmail.com&data=02%7C01%7Cpekatete%40hotmail.com%7C9a5adc9865eb46ef262108d511ce9781%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434501360011295&sdata=Jf2RVO8xAtxetJYELseIhG8hvKFFAAgQkeIO1idiHqE%3D&reserved=0) Secure Email. > >> -------- Original Message -------- >> >> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >> >> Local Time: October 12, 2017 6:57 PM >> >> UTC Time: October 12, 2017 6:57 PM >> >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> >> To: Dr Adam Back >> >> bitcoin-segwit2x at lists.linuxfoundation.org >> >> That link contains the word ?safelinks? and it triggers alarms for me but having read a few of your postings elsewhere, I trust the link even less. >> >> But I suppose we better limit posts to tech discussion (as the handbags have already started flying). >> >> From: [Dr Adam Back](mailto:adam at blockstream.com) >> >> Sent: 12 October 2017 19:06 >> >> To: [Phillip Katete](mailto:pekatete at hotmail.com) >> >> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >> >> To understand more about mining economics and the creation vs >> verification mechanism between miners and nodes, I recommend this >> article by Prof Emin Sirer which explains it quite clearly. >> >> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhackingdistributed.com%2F2016%2F01%2F03%2Ftime-for-bitcoin-user-voice%2F&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=vmHa78wd%2BIZzrO6hH6ap5654%2BSDlXu3FGTNScKRWDQg%3D&reserved=0 >> >> Adam >> >> On Thu, Oct 12, 2017 at 7:00 PM, Phillip Katete via Bitcoin-segwit2x >> wrote: >>> Whatever he may say he agreed to, the facts are that he voted to activate >>> and lock-in SegWit2x on bit 4 (before voting on bit 1 to get the legacy >>> clients activated and locked-in too). >>> >>> Despite the sabre rattling, f2pool will end up on the majority chain as they >>> are not in the space to prop up core. >>> >>> >>> >>> From: Brian Hoffman via Bitcoin-segwit2x >>> Sent: 12 October 2017 16:56 >>> To: Peter BitcoinReminder.com; Peter Todd via Bitcoin-segwit2x >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still >>> happening? >>> >>> >>> >>> Where have you been? Wang Chun has said they never were agreed to NYA post >>> segwit so what?s your point exactly? >>> >>> >>> >>> It?s obvious that there will be a chain split at this point. >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via >>> Bitcoin-segwit2x wrote: >>> >>> I was just pointing out that F2Pool just stopped NYA signaling some hours >>> ago - which is a new information. >>> >>> >>> >>> And still nobody answered my question if you know acknowledge that there >>> will be a chain split for sure and you are intentionally splitting off? >>> >>> >>> >>> >>> >>> Am 12.10.2017 um 17:50 schrieb Jeff Garzik : >>> >>> >>> >>> It is information over a month old. See counter. >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=qUYCDGIAGw7y1%2Fsskts%2F0SBdhzqyWDsldjkufCQMsXA%3D&reserved=0 >>> >>> -- >>> >>> Brian Hoffman >>> >>> President >>> >>> OB1 >>> >>> (571) 205-4967 >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=qUYCDGIAGw7y1%2Fsskts%2F0SBdhzqyWDsldjkufCQMsXA%3D&reserved=0 >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Fri Oct 13 00:58:48 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Fri, 13 Oct 2017 00:58:48 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <8AABDFAA-D0BE-4329-91C6-99CAB376F555@bitcoinreminder.com> , , Message-ID: As for the initial query for which the link was provided: Bit 1 signalling barely achieved sustained backing of 35% (requiring 95%) in any voting window pre NYA (bip91/bit 4) signalling. That is verifiable from the blockchain and I do not have to click on any links. On the separate issue of where f2pool?s hash will end up, everyone is entitled to their opining and it is in my estimation that f2pool (having been weary of loosing money by un-necessarily restarting their servers to top signalling for NYA since Sep 1st) are not going to risk all their hash simply to ?support? core. @Kekcoin ? if you got offended, good. And yes, you are a kid going by your last. And stop adding to the off-topic noise by apologising for being off-topic. From: Kekcoin Sent: 13 October 2017 01:37 To: Phillip Katete Cc: bitcoin-segwit2x at lists.linuxfoundation.org Subject: RE: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? Between your wild assumptions about my age, your fallacious implication that a younger age would imply lesser knowledge while simultaneously showcasing a severe lack of insight, and your random strawmen about what I would have said if this or that happened, I think I'll consider you a lost cause and cut this discussion short. Apologies to the list for the offtopic. Sent with ProtonMail Secure Email. -------- Original Message -------- Subject: RE: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? Local Time: October 13, 2017 12:29 AM UTC Time: October 13, 2017 12:29 AM From: pekatete at hotmail.com To: Kekcoin bitcoin-segwit2x at lists.linuxfoundation.org Honestly, I am neither trying to shame him nor have any intention of changing my email provider (probably had my Hotmail for as long as you are old!). The age old advice is not to click on links that you do not trust (and I have simply been transparent on this). But also the ?information? was not solicited (big red flag) and more pertinently I do not trust blockstream (or their employees), what with all the DDoS attacks, character assassinations, attempts to usurp the bitcoin consensus mechanism et al. You?d be the first to blame me if I picked up a nasty virus from the link. Better safe than sorry. From: Kekcoin Sent: 13 October 2017 01:08 To: Phillip Katete Cc: bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >From the .outlook.com part of the domain it seems to me it's your hotmail injecting referral links in incoming emails. Perhaps reconsider your email provider and not publicly shame someone for trying to provide you with informational material. Hackingdistributed.com (as I can see is being linked in the referral) is Emin Sirer's real domain. Sent with ProtonMail Secure Email. -------- Original Message -------- Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? Local Time: October 12, 2017 6:57 PM UTC Time: October 12, 2017 6:57 PM From: bitcoin-segwit2x at lists.linuxfoundation.org To: Dr Adam Back bitcoin-segwit2x at lists.linuxfoundation.org That link contains the word ?safelinks? and it triggers alarms for me but having read a few of your postings elsewhere, I trust the link even less. But I suppose we better limit posts to tech discussion (as the handbags have already started flying). From: Dr Adam Back Sent: 12 October 2017 19:06 To: Phillip Katete Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? To understand more about mining economics and the creation vs verification mechanism between miners and nodes, I recommend this article by Prof Emin Sirer which explains it quite clearly. https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhackingdistributed.com%2F2016%2F01%2F03%2Ftime-for-bitcoin-user-voice%2F&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=vmHa78wd%2BIZzrO6hH6ap5654%2BSDlXu3FGTNScKRWDQg%3D&reserved=0 Adam On Thu, Oct 12, 2017 at 7:00 PM, Phillip Katete via Bitcoin-segwit2x wrote: > Whatever he may say he agreed to, the facts are that he voted to activate > and lock-in SegWit2x on bit 4 (before voting on bit 1 to get the legacy > clients activated and locked-in too). > > Despite the sabre rattling, f2pool will end up on the majority chain as they > are not in the space to prop up core. > > > > From: Brian Hoffman via Bitcoin-segwit2x > Sent: 12 October 2017 16:56 > To: Peter BitcoinReminder.com; Peter Todd via Bitcoin-segwit2x > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > happening? > > > > Where have you been? Wang Chun has said they never were agreed to NYA post > segwit so what?s your point exactly? > > > > It?s obvious that there will be a chain split at this point. > > > > > > > > On Thu, Oct 12, 2017 at 8:53 AM Peter BitcoinReminder.com via > Bitcoin-segwit2x wrote: > > I was just pointing out that F2Pool just stopped NYA signaling some hours > ago - which is a new information. > > > > And still nobody answered my question if you know acknowledge that there > will be a chain split for sure and you are intentionally splitting off? > > > > > > Am 12.10.2017 um 17:50 schrieb Jeff Garzik : > > > > It is information over a month old. See counter. > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=qUYCDGIAGw7y1%2Fsskts%2F0SBdhzqyWDsldjkufCQMsXA%3D&reserved=0 > > -- > > Brian Hoffman > > President > > OB1 > > (571) 205-4967 > > > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7Ce59f79fd56bf4c5b6b2108d5119bff26%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636434284047243812&sdata=qUYCDGIAGw7y1%2Fsskts%2F0SBdhzqyWDsldjkufCQMsXA%3D&reserved=0 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emil at bitcoin.com Fri Oct 13 01:42:14 2017 From: emil at bitcoin.com (Emil Oldenburg) Date: Fri, 13 Oct 2017 10:42:14 +0900 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> Message-ID: <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> If we try to be technical here. The HF is already activated, is estimated to trigger in 36 days, and can't be "called off". Nor is there any logic to delay it if hashrate deflects. That's the rules of the btc1 client. Emil Oldenburg, CTO Emil at bitcoin.com Visit the all new https://bitcoin.com Wechat: emilold Telegram: emilold On 2017?10?13? 05:31, John Heathco via Bitcoin-segwit2x wrote: > I don't believe there is an explicitly stated hashpower in which the > fork would be "called off", but I would assume it is much lower than > what is currently signaling, even if we make the (unwise) assumption > that F2Pool would not contribute to mining 2x whatsoever. > > > > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via > Bitcoin-segwit2x > wrote: > > I?m not Peter Todd, we just share the same (nice) firstname. > > I still didn?t get an answer what the minimum amount of hashpower > is required, before the fork is getting delayed? > We have to plan time for the whole security measures etc, so I > think it?s reasonable to get more information about this? > > >> Am 12.10.2017 um 21:53 schrieb bitPico > >: >> >> Without you knowing why they stopped signaling this is FUD and >> off-topic for this list. Please instead let F2Pool ?state their >> own opinion here since yours doesn?t count. If you think your >> opinion does count then show us your blocks that your pool has >> produced; until then you are simply an end-user and still you are >> off-topic for this list. If you need ELI5 for how this list works >> please let us know and we can help you Peter Todd. >> >> Have a groovy day! >> >>> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com >>> via Bitcoin-segwit2x >>> >> > wrote: >>> >>> Since F2Pool stopped signaling for the NYA[1] and slush also >>> mines mostly non-NYA blocks, are you still going to fork off in >>> November - splitting the chain intentionally?? >>> >>> ? >>> [1]?https://imgur.com/LgYdFKw >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From segwit2x_mailinglist at bitcoinreminder.com Fri Oct 13 08:31:43 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Fri, 13 Oct 2017 10:31:43 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> Message-ID: <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Thats not a reason, the BTC1 sourcecode is still in development (f.e. replay protection was reverted just 1-2 days ago?) - so the argument ?it can?t be called off? is just wrong. So wouldn?t it make sense to add a minimum required hashrate for the HF to lock in? You are really going to fork off with f.e. 40 % hashpower? > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x : > > If we try to be technical here. The HF is already activated, is estimated to trigger in 36 days, and can't be "called off". Nor is there any logic to delay it if hashrate deflects. That's the rules of the btc1 client. > > Emil Oldenburg, CTO > Emil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > On 2017?10?13? 05:31, John Heathco via Bitcoin-segwit2x wrote: >> I don't believe there is an explicitly stated hashpower in which the fork would be "called off", but I would assume it is much lower than what is currently signaling, even if we make the (unwise) assumption that F2Pool would not contribute to mining 2x whatsoever. >> >> >> >> On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via Bitcoin-segwit2x > wrote: >> I?m not Peter Todd, we just share the same (nice) firstname. >> >> I still didn?t get an answer what the minimum amount of hashpower is required, before the fork is getting delayed? >> We have to plan time for the whole security measures etc, so I think it?s reasonable to get more information about this? >> >> >>> Am 12.10.2017 um 21:53 schrieb bitPico >: >>> >>> Without you knowing why they stopped signaling this is FUD and off-topic for this list. Please instead let F2Pool state their own opinion here since yours doesn?t count. If you think your opinion does count then show us your blocks that your pool has produced; until then you are simply an end-user and still you are off-topic for this list. If you need ELI5 for how this list works please let us know and we can help you Peter Todd. >>> >>> Have a groovy day! >>> >>>> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via Bitcoin-segwit2x > wrote: >>>> >>>> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly non-NYA blocks, are you still going to fork off in November - splitting the chain intentionally? >>>> >>>> ? >>>> [1] https://imgur.com/LgYdFKw >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From emil at bitcoin.com Fri Oct 13 09:01:33 2017 From: emil at bitcoin.com (Emil Oldenburg) Date: Fri, 13 Oct 2017 18:01:33 +0900 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: The hardfork part is already locked in and is not subject to change. Many btc1 nodes are already deployed and they should not and don't need to update. The only thing left is a potential extra softfork for opt-in replay protection. Only the miners need this softfork. What makes you think the hardfork will have less than 40% hashpower? Emil Oldenburg, CTO Emil at bitcoin.com Visit the all new https://bitcoin.com Wechat: emilold Telegram: emilold On 2017?10?13? 17:31, Peter BitcoinReminder.com wrote: > Thats not a reason, the BTC1 sourcecode is still in development (f.e. > replay protection was reverted just 1-2 days ago?) - so the argument > ?it can?t be called off? is just wrong. > > So wouldn?t it make sense to add a minimum required hashrate for the > HF to lock in? You are really going to fork off with f.e. 40 % hashpower? > > >> Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x >> > >: >> >> If we try to be technical here. The HF is already activated, is >> estimated to trigger in 36 days, and can't be "called off". Nor is >> there any logic to delay it if hashrate deflects. That's the rules of >> the btc1 client. >> >> >> Emil Oldenburg, CTO >> Emil at bitcoin.com >> Visit the all new https://bitcoin.com >> Wechat: emilold >> Telegram: emilold >> On 2017?10?13? 05:31, John Heathco via Bitcoin-segwit2x wrote: >>> I don't believe there is an explicitly stated hashpower in which the >>> fork would be "called off", but I would assume it is much lower than >>> what is currently signaling, even if we make the (unwise) assumption >>> that F2Pool would not contribute to mining 2x whatsoever. >>> >>> >>> >>> On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com >>> via Bitcoin-segwit2x >>> >> > wrote: >>> >>> I?m not Peter Todd, we just share the same (nice) firstname. >>> >>> I still didn?t get an answer what the minimum amount of >>> hashpower is required, before the fork is getting delayed? >>> We have to plan time for the whole security measures etc, so I >>> think it?s reasonable to get more information about this? >>> >>> >>>> Am 12.10.2017 um 21:53 schrieb bitPico >>> >: >>>> >>>> Without you knowing why they stopped signaling this is FUD and >>>> off-topic for this list. Please instead let F2Pool ?state their >>>> own opinion here since yours doesn?t count. If you think your >>>> opinion does count then show us your blocks that your pool has >>>> produced; until then you are simply an end-user and still you >>>> are off-topic for this list. If you need ELI5 for how this list >>>> works please let us know and we can help you Peter Todd. >>>> >>>> Have a groovy day! >>>> >>>>> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com >>>>> via Bitcoin-segwit2x >>>>> >>>> > wrote: >>>>> >>>>> Since F2Pool stopped signaling for the NYA[1] and slush also >>>>> mines mostly non-NYA blocks, are you still going to fork off >>>>> in November - splitting the chain intentionally?? >>>>> >>>>> ? >>>>> [1]?https://imgur.com/LgYdFKw >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at blockstream.com Fri Oct 13 09:11:07 2017 From: adam at blockstream.com (Dr Adam Back) Date: Fri, 13 Oct 2017 11:11:07 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: The futures price is 1/3 of 40% so yes actually < 40% hashrate is quite likely. https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https%3a%2f%2fwww.google.com%2f Nodes should upgrade because code changes are being made and it's not a good idea to run pre-production code on the live network. Do you recall when the company you work for lost bitcoin by running pre-release fork code before on the pool? Is anyone running BTC1 head in production? Protecting how much value. Reminder this is a public list. Adam On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x wrote: > The hardfork part is already locked in and is not subject to change. Many > btc1 nodes are already deployed and they should not and don't need to > update. The only thing left is a potential extra softfork for opt-in replay > protection. Only the miners need this softfork. > > What makes you think the hardfork will have less than 40% hashpower? > > > Emil Oldenburg, CTO > Emil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > > On 2017?10?13? 17:31, Peter BitcoinReminder.com wrote: > > Thats not a reason, the BTC1 sourcecode is still in development (f.e. replay > protection was reverted just 1-2 days ago?) - so the argument ?it can?t be > called off? is just wrong. > > So wouldn?t it make sense to add a minimum required hashrate for the HF to > lock in? You are really going to fork off with f.e. 40 % hashpower? > > > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x > : > > If we try to be technical here. The HF is already activated, is estimated to > trigger in 36 days, and can't be "called off". Nor is there any logic to > delay it if hashrate deflects. That's the rules of the btc1 client. > > > Emil Oldenburg, CTO > Emil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > > On 2017?10?13? 05:31, John Heathco via Bitcoin-segwit2x wrote: > > I don't believe there is an explicitly stated hashpower in which the fork > would be "called off", but I would assume it is much lower than what is > currently signaling, even if we make the (unwise) assumption that F2Pool > would not contribute to mining 2x whatsoever. > > > > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via > Bitcoin-segwit2x wrote: >> >> I?m not Peter Todd, we just share the same (nice) firstname. >> >> I still didn?t get an answer what the minimum amount of hashpower is >> required, before the fork is getting delayed? >> We have to plan time for the whole security measures etc, so I think it?s >> reasonable to get more information about this? >> >> >> Am 12.10.2017 um 21:53 schrieb bitPico : >> >> Without you knowing why they stopped signaling this is FUD and off-topic >> for this list. Please instead let F2Pool state their own opinion here since >> yours doesn?t count. If you think your opinion does count then show us your >> blocks that your pool has produced; until then you are simply an end-user >> and still you are off-topic for this list. If you need ELI5 for how this >> list works please let us know and we can help you Peter Todd. >> >> Have a groovy day! >> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via >> Bitcoin-segwit2x wrote: >> >> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly >> non-NYA blocks, are you still going to fork off in November - splitting the >> chain intentionally? >> >> ? >> [1] https://imgur.com/LgYdFKw >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From bitcoinerrorlog at gmail.com Fri Oct 13 09:15:13 2017 From: bitcoinerrorlog at gmail.com (Bitcoin Error Log) Date: Fri, 13 Oct 2017 09:15:13 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: The futures market is showing economic consensus support for S2X fork at about 12% right now. Miners can't afford to mine at 12% of value. It is not impossible that this fork you are making will have minority hashpower very quickly, or even from the start. Forking the miners does not fork the users automatically, and it does not create demand for their new blocks. You need to get serious about protecting your own fork from this situation, or call off the whole thing entirely. You only have a majority consensus of miners and no other players in this incentive structure. Even with the miners, most of your signaling is just that, and only by pools. Individual miners will mine what is most profitable, and if that is the original Bitcoin, that IS what they will mine. On Fri, Oct 13, 2017 at 5:01 AM Emil Oldenburg via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > The hardfork part is already locked in and is not subject to change. Many > btc1 nodes are already deployed and they should not and don't need to > update. The only thing left is a potential extra softfork for opt-in replay > protection. Only the miners need this softfork. > > What makes you think the hardfork will have less than 40% hashpower? > > > Emil Oldenburg, CTOEmil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > > On 2017?10?13? 17:31, Peter BitcoinReminder.com wrote: > > Thats not a reason, the BTC1 sourcecode is still in development (f.e. > replay protection was reverted just 1-2 days ago?) - so the argument ?it > can?t be called off? is just wrong. > > So wouldn?t it make sense to add a minimum required hashrate for the HF to > lock in? You are really going to fork off with f.e. 40 % hashpower? > > > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org>: > > If we try to be technical here. The HF is already activated, is estimated > to trigger in 36 days, and can't be "called off". Nor is there any logic to > delay it if hashrate deflects. That's the rules of the btc1 client. > > > Emil Oldenburg, CTOEmil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > > On 2017?10?13? 05:31, John Heathco via Bitcoin-segwit2x wrote: > > I don't believe there is an explicitly stated hashpower in which the fork > would be "called off", but I would assume it is much lower than what is > currently signaling, even if we make the (unwise) assumption that F2Pool > would not contribute to mining 2x whatsoever. > > > > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via > Bitcoin-segwit2x wrote: > >> I?m not Peter Todd, we just share the same (nice) firstname. >> >> I still didn?t get an answer what the minimum amount of hashpower is >> required, before the fork is getting delayed? >> We have to plan time for the whole security measures etc, so I think it?s >> reasonable to get more information about this? >> >> >> Am 12.10.2017 um 21:53 schrieb bitPico : >> >> Without you knowing why they stopped signaling this is FUD and off-topic >> for this list. Please instead let F2Pool state their own opinion here >> since yours doesn?t count. If you think your opinion does count then show >> us your blocks that your pool has produced; until then you are simply an >> end-user and still you are off-topic for this list. If you need ELI5 for >> how this list works please let us know and we can help you Peter Todd. >> >> Have a groovy day! >> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com >> via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly >> non-NYA blocks, are you still going to fork off in November - splitting the >> chain intentionally? >> >> ? >> [1] https://imgur.com/LgYdFKw >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > > _______________________________________________ > Bitcoin-segwit2x mailing listBitcoin-segwit2x at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- John C Bitcoin Error Log www.bitcoinerrorlog.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Fri Oct 13 09:47:03 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Fri, 13 Oct 2017 09:47:03 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> , Message-ID: You are barking up the wrong tree by using a ?rigged? futures? price to estimate the hash supporting the upgrade at fork time. They NYA was presented as being backed by at least 80% of the network hash then and was activated / locked-in by over 90%. Since then, it has continued to receive and sustain intent signalling above the introduction threshold. It is only rational to expect the hash on fork to reflect the latter as opposed to futures? prices. Obiter dicta: the futures? price is more reflective of the wavering non mining, none economic users. It goes without saying, a lot of people are going to loose a lot of money on this otherwise rigged futures? market. From: Dr Adam Back via Bitcoin-segwit2x Sent: 13 October 2017 10:11 To: Emil Oldenburg Cc: Peter Todd via Bitcoin-segwit2x Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? The futures price is 1/3 of 40% so yes actually < 40% hashrate is quite likely. https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https%3a%2f%2fwww.google.com%2f Nodes should upgrade because code changes are being made and it's not a good idea to run pre-production code on the live network. Do you recall when the company you work for lost bitcoin by running pre-release fork code before on the pool? Is anyone running BTC1 head in production? Protecting how much value. Reminder this is a public list. Adam On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x wrote: > The hardfork part is already locked in and is not subject to change. Many > btc1 nodes are already deployed and they should not and don't need to > update. The only thing left is a potential extra softfork for opt-in replay > protection. Only the miners need this softfork. > > What makes you think the hardfork will have less than 40% hashpower? > > > Emil Oldenburg, CTO > Emil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > > On 2017?10?13? 17:31, Peter BitcoinReminder.com wrote: > > Thats not a reason, the BTC1 sourcecode is still in development (f.e. replay > protection was reverted just 1-2 days ago?) - so the argument ?it can?t be > called off? is just wrong. > > So wouldn?t it make sense to add a minimum required hashrate for the HF to > lock in? You are really going to fork off with f.e. 40 % hashpower? > > > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x > : > > If we try to be technical here. The HF is already activated, is estimated to > trigger in 36 days, and can't be "called off". Nor is there any logic to > delay it if hashrate deflects. That's the rules of the btc1 client. > > > Emil Oldenburg, CTO > Emil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > > On 2017?10?13? 05:31, John Heathco via Bitcoin-segwit2x wrote: > > I don't believe there is an explicitly stated hashpower in which the fork > would be "called off", but I would assume it is much lower than what is > currently signaling, even if we make the (unwise) assumption that F2Pool > would not contribute to mining 2x whatsoever. > > > > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via > Bitcoin-segwit2x wrote: >> >> I?m not Peter Todd, we just share the same (nice) firstname. >> >> I still didn?t get an answer what the minimum amount of hashpower is >> required, before the fork is getting delayed? >> We have to plan time for the whole security measures etc, so I think it?s >> reasonable to get more information about this? >> >> >> Am 12.10.2017 um 21:53 schrieb bitPico : >> >> Without you knowing why they stopped signaling this is FUD and off-topic >> for this list. Please instead let F2Pool state their own opinion here since >> yours doesn?t count. If you think your opinion does count then show us your >> blocks that your pool has produced; until then you are simply an end-user >> and still you are off-topic for this list. If you need ELI5 for how this >> list works please let us know and we can help you Peter Todd. >> >> Have a groovy day! >> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via >> Bitcoin-segwit2x wrote: >> >> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly >> non-NYA blocks, are you still going to fork off in November - splitting the >> chain intentionally? >> >> ? >> [1] https://imgur.com/LgYdFKw >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Fri Oct 13 10:11:25 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Fri, 13 Oct 2017 12:11:25 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > You are barking up the wrong tree by using a ?rigged? futures? price to > estimate the hash supporting the upgrade at fork time. They NYA was > presented as being backed by at least 80% of the network hash then and was > activated / locked-in by over 90%. Since then, it has continued to receive > and sustain intent signalling above the introduction threshold. It is only > rational to expect the hash on fork to reflect the latter as opposed to > futures? prices. > > > > Obiter dicta: the futures? price is more reflective of the wavering non > mining, none economic users. It goes without saying, a lot of people are > going to loose a lot of money on this otherwise rigged futures? market. > Markets are not always accurate, but simply a form of price discovery, I think "rigged" is perhaps a loaded term in this case and stretching things. A 12% futures market does not bode well for success, but, you never know. Since F2Pool stopped signaling NYA yesterday the signaling ratio is now about 81%, though this might have something to do with the feast and famine EDA in bitcoin cash which has just been activated. Around 83% might be a better guess. However signaling is cheap, and many miners act in economic self interest. Having helped run a coin for many years, I have witnessed this being the case. There's nothing developers would like more than steady miners that stick with a coin, but sites such as coinwarz [1] all too often create spikes in hash power related to profitability. Wishing to stay on topic, I'd like to ask the following question. If signaling falls below the described 80% threshold stated above (ie one more miner stops signaling), will this this be grounds to rethink the timing of the release schedule? [1] https://www.coinwarz.com/cryptocurrency > > > *From: *Dr Adam Back via Bitcoin-segwit2x > > *Sent: *13 October 2017 10:11 > *To: *Emil Oldenburg > *Cc: *Peter Todd via Bitcoin-segwit2x > > *Subject: *Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > happening? > > > > The futures price is 1/3 of 40% so yes actually < 40% hashrate is quite > likely. > > > https://www.cryptonator.com/rates/BT2-BTC?utm_referrer= > https%3a%2f%2fwww.google.com%2f > > Nodes should upgrade because code changes are being made and it's not > a good idea to run pre-production code on the live network. Do you > recall when the company you work for lost bitcoin by running > pre-release fork code before on the pool? > > Is anyone running BTC1 head in production? Protecting how much value. > Reminder this is a public list. > > Adam > > On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x > wrote: > > The hardfork part is already locked in and is not subject to change. Many > > btc1 nodes are already deployed and they should not and don't need to > > update. The only thing left is a potential extra softfork for opt-in > replay > > protection. Only the miners need this softfork. > > > > What makes you think the hardfork will have less than 40% hashpower? > > > > > > Emil Oldenburg, CTO > > Emil at bitcoin.com > > Visit the all new https://bitcoin.com > > Wechat: emilold > > Telegram: emilold > > > > On 2017 > ?10?13? 17:31, Peter BitcoinReminder.com wrote: > > > > > Thats not a reason, the BTC1 sourcecode is still in development (f.e. > replay > > protection was reverted just 1-2 days ago?) - so the argument ?it can?t > be > > called off? is just wrong. > > > > So wouldn?t it make sense to add a minimum required hashrate for the HF > to > > lock in? You are really going to fork off with f.e. 40 % hashpower? > > > > > > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x > > : > > > > If we try to be technical here. The HF is already activated, is > estimated to > > trigger in 36 days, and can't be "called off". Nor is there any logic to > > delay it if hashrate deflects. That's the rules of the btc1 client. > > > > > > Emil Oldenburg, CTO > > Emil at bitcoin.com > > Visit the all new https://bitcoin.com > > Wechat: emilold > > Telegram: emilold > > > > On 2017 > ?10?13? 05:31, John Heathco via Bitcoin-segwit2x wrote: > > > > > I don't believe there is an explicitly stated hashpower in which the fork > > would be "called off", but I would assume it is much lower than what is > > currently signaling, even if we make the (unwise) assumption that F2Pool > > would not contribute to mining 2x whatsoever. > > > > > > > > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via > > Bitcoin-segwit2x wrote: > >> > >> I?m not Peter Todd, we just share the same (nice) firstname. > >> > >> I still didn?t get an answer what the minimum amount of hashpower is > >> required, before the fork is getting delayed? > >> We have to plan time for the whole security measures etc, so I think > it?s > >> reasonable to get more information about this? > >> > >> > >> Am 12.10.2017 um 21:53 schrieb bitPico : > >> > >> Without you knowing why they stopped signaling this is FUD and off-topic > >> for this list. Please instead let F2Pool state their own opinion here > since > >> yours doesn?t count. If you think your opinion does count then show us > your > >> blocks that your pool has produced; until then you are simply an > end-user > >> and still you are off-topic for this list. If you need ELI5 for how this > >> list works please let us know and we can help you Peter Todd. > >> > >> Have a groovy day! > >> > >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via > >> Bitcoin-segwit2x wrote: > >> > >> Since F2Pool stopped signaling for the NYA[1] and slush also mines > mostly > >> non-NYA blocks, are you still going to fork off in November - splitting > the > >> chain intentionally? > >> > >> ? > >> [1] https://imgur.com/LgYdFKw > >> > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > >> > >> > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Fri Oct 13 10:30:24 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Fri, 13 Oct 2017 10:30:24 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> , Message-ID: The disingenuity here is ?painful to watch?. First you make hay of f2pool switching off NYA signaling intent THEN you rubbish signaling intent as cheap and not worthy of consideration as a metric. More worryingly, you then want to predicate the HF on miner signaling at the 80% threshold. So which is it then? Even with the EDA induced hash oscillations, I am confident hash at and post fork will mirror signaling intent. From: Melvin Carvalho Sent: 13 October 2017 11:11 To: Phillip Katete Cc: Dr Adam Back; Emil Oldenburg; Peter Todd via Bitcoin-segwit2x Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x > wrote: You are barking up the wrong tree by using a ?rigged? futures? price to estimate the hash supporting the upgrade at fork time. They NYA was presented as being backed by at least 80% of the network hash then and was activated / locked-in by over 90%. Since then, it has continued to receive and sustain intent signalling above the introduction threshold. It is only rational to expect the hash on fork to reflect the latter as opposed to futures? prices. Obiter dicta: the futures? price is more reflective of the wavering non mining, none economic users. It goes without saying, a lot of people are going to loose a lot of money on this otherwise rigged futures? market. Markets are not always accurate, but simply a form of price discovery, I think "rigged" is perhaps a loaded term in this case and stretching things. A 12% futures market does not bode well for success, but, you never know. Since F2Pool stopped signaling NYA yesterday the signaling ratio is now about 81%, though this might have something to do with the feast and famine EDA in bitcoin cash which has just been activated. Around 83% might be a better guess. However signaling is cheap, and many miners act in economic self interest. Having helped run a coin for many years, I have witnessed this being the case. There's nothing developers would like more than steady miners that stick with a coin, but sites such as coinwarz [1] all too often create spikes in hash power related to profitability. Wishing to stay on topic, I'd like to ask the following question. If signaling falls below the described 80% threshold stated above (ie one more miner stops signaling), will this this be grounds to rethink the timing of the release schedule? [1] https://www.coinwarz.com/cryptocurrency From: Dr Adam Back via Bitcoin-segwit2x Sent: 13 October 2017 10:11 To: Emil Oldenburg Cc: Peter Todd via Bitcoin-segwit2x Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? The futures price is 1/3 of 40% so yes actually < 40% hashrate is quite likely. https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https%3a%2f%2fwww.google.com%2f Nodes should upgrade because code changes are being made and it's not a good idea to run pre-production code on the live network. Do you recall when the company you work for lost bitcoin by running pre-release fork code before on the pool? Is anyone running BTC1 head in production? Protecting how much value. Reminder this is a public list. Adam On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x > wrote: > The hardfork part is already locked in and is not subject to change. Many > btc1 nodes are already deployed and they should not and don't need to > update. The only thing left is a potential extra softfork for opt-in replay > protection. Only the miners need this softfork. > > What makes you think the hardfork will have less than 40% hashpower? > > > Emil Oldenburg, CTO > Emil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > > On 2017 ?10?13? 17:31, Peter BitcoinReminder.com wrote: > > Thats not a reason, the BTC1 sourcecode is still in development (f.e. replay > protection was reverted just 1-2 days ago?) - so the argument ?it can?t be > called off? is just wrong. > > So wouldn?t it make sense to add a minimum required hashrate for the HF to > lock in? You are really going to fork off with f.e. 40 % hashpower? > > > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x > >: > > If we try to be technical here. The HF is already activated, is estimated to > trigger in 36 days, and can't be "called off". Nor is there any logic to > delay it if hashrate deflects. That's the rules of the btc1 client. > > > Emil Oldenburg, CTO > Emil at bitcoin.com > Visit the all new https://bitcoin.com > Wechat: emilold > Telegram: emilold > > On 2017 ?10?13? 05:31, John Heathco via Bitcoin-segwit2x wrote: > > I don't believe there is an explicitly stated hashpower in which the fork > would be "called off", but I would assume it is much lower than what is > currently signaling, even if we make the (unwise) assumption that F2Pool > would not contribute to mining 2x whatsoever. > > > > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via > Bitcoin-segwit2x > wrote: >> >> I?m not Peter Todd, we just share the same (nice) firstname. >> >> I still didn?t get an answer what the minimum amount of hashpower is >> required, before the fork is getting delayed? >> We have to plan time for the whole security measures etc, so I think it?s >> reasonable to get more information about this? >> >> >> Am 12.10.2017 um 21:53 schrieb bitPico >: >> >> Without you knowing why they stopped signaling this is FUD and off-topic >> for this list. Please instead let F2Pool state their own opinion here since >> yours doesn?t count. If you think your opinion does count then show us your >> blocks that your pool has produced; until then you are simply an end-user >> and still you are off-topic for this list. If you need ELI5 for how this >> list works please let us know and we can help you Peter Todd. >> >> Have a groovy day! >> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via >> Bitcoin-segwit2x > wrote: >> >> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly >> non-NYA blocks, are you still going to fork off in November - splitting the >> chain intentionally? >> >> ? >> [1] https://imgur.com/LgYdFKw >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Fri Oct 13 10:45:14 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Fri, 13 Oct 2017 12:45:14 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: On 13 October 2017 at 12:30, Phillip Katete wrote: > The disingenuity here is ?painful to watch?. First you make hay of f2pool > switching off NYA signaling intent THEN you rubbish signaling intent as > cheap and not worthy of consideration as a metric. More worryingly, you > then want to predicate the HF on miner signaling at the 80% threshold. So > which is it then? > > > > Even with the EDA induced hash oscillations, I am confident hash at and > post fork will mirror signaling intent. > 24h signaling fell to 79.86% [1] [1] https://coin.dance/blocks#thisweek > > > *From: *Melvin Carvalho > *Sent: *13 October 2017 11:11 > *To: *Phillip Katete > *Cc: *Dr Adam Back ; Emil Oldenburg > ; Peter Todd via Bitcoin-segwit2x > > > *Subject: *Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > happening? > > > > > > > > On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > You are barking up the wrong tree by using a ?rigged? futures? price to > estimate the hash supporting the upgrade at fork time. They NYA was > presented as being backed by at least 80% of the network hash then and was > activated / locked-in by over 90%. Since then, it has continued to receive > and sustain intent signalling above the introduction threshold. It is only > rational to expect the hash on fork to reflect the latter as opposed to > futures? prices. > > > > Obiter dicta: the futures? price is more reflective of the wavering non > mining, none economic users. It goes without saying, a lot of people are > going to loose a lot of money on this otherwise rigged futures? market. > > > > Markets are not always accurate, but simply a form of price discovery, I > think "rigged" is perhaps a loaded term in this case and stretching > things. A 12% futures market does not bode well for success, but, you > never know. > > Since F2Pool stopped signaling NYA yesterday the signaling ratio is now > about 81%, though this might have something to do with the feast and famine > EDA in bitcoin cash which has just been activated. Around 83% might be a > better guess. > > However signaling is cheap, and many miners act in economic self > interest. Having helped run a coin for many years, I have witnessed this > being the case. There's nothing developers would like more than steady > miners that stick with a coin, but sites such as coinwarz [1] all too often > create spikes in hash power related to profitability. > > Wishing to stay on topic, I'd like to ask the following question. If > signaling falls below the described 80% threshold stated above (ie one more > miner stops signaling), will this this be grounds to rethink the timing of > the release schedule? > > > [1] https://www.coinwarz.com/cryptocurrency > > > > > > *From: *Dr Adam Back via Bitcoin-segwit2x > > *Sent: *13 October 2017 10:11 > *To: *Emil Oldenburg > *Cc: *Peter Todd via Bitcoin-segwit2x > > *Subject: *Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > happening? > > > > The futures price is 1/3 of 40% so yes actually < 40% hashrate is quite > likely. > > > > https://www.cryptonator.com/rates/BT2-BTC?utm_referrer= > https%3a%2f%2fwww.google.com%2f > > Nodes should upgrade because code changes are being made and it's not > a good idea to run pre-production code on the live network. Do you > recall when the company you work for lost bitcoin by running > pre-release fork code before on the pool? > > Is anyone running BTC1 head in production? Protecting how much value. > Reminder this is a public list. > > Adam > > On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x > wrote: > > The hardfork part is already locked in and is not subject to change. Many > > btc1 nodes are already deployed and they should not and don't need to > > update. The only thing left is a potential extra softfork for opt-in > replay > > protection. Only the miners need this softfork. > > > > What makes you think the hardfork will have less than 40% hashpower? > > > > > > Emil Oldenburg, CTO > > Emil at bitcoin.com > > Visit the all new https://bitcoin.com > > Wechat: emilold > > Telegram: emilold > > > > On 2017 > > ?10?13? 17:31, Peter BitcoinReminder.com wrote: > > > > > > Thats not a reason, the BTC1 sourcecode is still in development (f.e. > replay > > protection was reverted just 1-2 days ago?) - so the argument ?it can?t > be > > called off? is just wrong. > > > > So wouldn?t it make sense to add a minimum required hashrate for the HF > to > > lock in? You are really going to fork off with f.e. 40 % hashpower? > > > > > > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x > > : > > > > If we try to be technical here. The HF is already activated, is > estimated to > > trigger in 36 days, and can't be "called off". Nor is there any logic to > > delay it if hashrate deflects. That's the rules of the btc1 client. > > > > > > Emil Oldenburg, CTO > > Emil at bitcoin.com > > Visit the all new https://bitcoin.com > > Wechat: emilold > > Telegram: emilold > > > > On 2017 > > ?10?13? 05:31, John Heathco via Bitcoin-segwit2x wrote: > > > > > > I don't believe there is an explicitly stated hashpower in which the fork > > would be "called off", but I would assume it is much lower than what is > > currently signaling, even if we make the (unwise) assumption that F2Pool > > would not contribute to mining 2x whatsoever. > > > > > > > > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via > > Bitcoin-segwit2x wrote: > >> > >> I?m not Peter Todd, we just share the same (nice) firstname. > >> > >> I still didn?t get an answer what the minimum amount of hashpower is > >> required, before the fork is getting delayed? > >> We have to plan time for the whole security measures etc, so I think > it?s > >> reasonable to get more information about this? > >> > >> > >> Am 12.10.2017 um 21:53 schrieb bitPico : > >> > >> Without you knowing why they stopped signaling this is FUD and off-topic > >> for this list. Please instead let F2Pool state their own opinion here > since > >> yours doesn?t count. If you think your opinion does count then show us > your > >> blocks that your pool has produced; until then you are simply an > end-user > >> and still you are off-topic for this list. If you need ELI5 for how this > >> list works please let us know and we can help you Peter Todd. > >> > >> Have a groovy day! > >> > >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via > >> Bitcoin-segwit2x wrote: > >> > >> Since F2Pool stopped signaling for the NYA[1] and slush also mines > mostly > >> non-NYA blocks, are you still going to fork off in November - splitting > the > >> chain intentionally? > >> > >> ? > >> [1] https://imgur.com/LgYdFKw > >> > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > >> > >> > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Fri Oct 13 15:55:04 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Fri, 13 Oct 2017 17:55:04 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: On 13 October 2017 at 12:45, Melvin Carvalho wrote: > > > On 13 October 2017 at 12:30, Phillip Katete wrote: > >> The disingenuity here is ?painful to watch?. First you make hay of >> f2pool switching off NYA signaling intent THEN you rubbish signaling intent >> as cheap and not worthy of consideration as a metric. More worryingly, you >> then want to predicate the HF on miner signaling at the 80% threshold. So >> which is it then? >> >> >> >> Even with the EDA induced hash oscillations, I am confident hash at and >> post fork will mirror signaling intent. >> > > 24h signaling fell to 79.86% [1] > NYA signaling is now down to 77.70% in the last 24h (down from over 90% a day ago) https://coin.dance/blocks This does not take into account ViaBTC which may support either chain, but are currently signaling 100% NYA. However, much hash is mining bitcoin cash right now, and probably favourable to seg2x Additionally, you can monitor the futures market in realtime https://cryptowat.ch/bitfinex/bt2btc Currently trading at 10.6% of bitcoin (down from over 20% a day ago) You may wish to consider these metrics a source of new information for this project. And / or watch them as they develop. > > [1] https://coin.dance/blocks#thisweek > > >> >> >> *From: *Melvin Carvalho >> *Sent: *13 October 2017 11:11 >> *To: *Phillip Katete >> *Cc: *Dr Adam Back ; Emil Oldenburg >> ; Peter Todd via Bitcoin-segwit2x >> >> >> *Subject: *Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still >> happening? >> >> >> >> >> >> >> >> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> You are barking up the wrong tree by using a ?rigged? futures? price to >> estimate the hash supporting the upgrade at fork time. They NYA was >> presented as being backed by at least 80% of the network hash then and was >> activated / locked-in by over 90%. Since then, it has continued to receive >> and sustain intent signalling above the introduction threshold. It is only >> rational to expect the hash on fork to reflect the latter as opposed to >> futures? prices. >> >> >> >> Obiter dicta: the futures? price is more reflective of the wavering non >> mining, none economic users. It goes without saying, a lot of people are >> going to loose a lot of money on this otherwise rigged futures? market. >> >> >> >> Markets are not always accurate, but simply a form of price discovery, I >> think "rigged" is perhaps a loaded term in this case and stretching >> things. A 12% futures market does not bode well for success, but, you >> never know. >> >> Since F2Pool stopped signaling NYA yesterday the signaling ratio is now >> about 81%, though this might have something to do with the feast and famine >> EDA in bitcoin cash which has just been activated. Around 83% might be a >> better guess. >> >> However signaling is cheap, and many miners act in economic self >> interest. Having helped run a coin for many years, I have witnessed this >> being the case. There's nothing developers would like more than steady >> miners that stick with a coin, but sites such as coinwarz [1] all too often >> create spikes in hash power related to profitability. >> >> Wishing to stay on topic, I'd like to ask the following question. If >> signaling falls below the described 80% threshold stated above (ie one more >> miner stops signaling), will this this be grounds to rethink the timing of >> the release schedule? >> >> >> [1] https://www.coinwarz.com/cryptocurrency >> >> >> >> >> >> *From: *Dr Adam Back via Bitcoin-segwit2x >> >> *Sent: *13 October 2017 10:11 >> *To: *Emil Oldenburg >> *Cc: *Peter Todd via Bitcoin-segwit2x >> >> *Subject: *Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still >> happening? >> >> >> >> The futures price is 1/3 of 40% so yes actually < 40% hashrate is quite >> likely. >> >> >> >> https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https >> %3a%2f%2fwww.google.com%2f >> >> Nodes should upgrade because code changes are being made and it's not >> a good idea to run pre-production code on the live network. Do you >> recall when the company you work for lost bitcoin by running >> pre-release fork code before on the pool? >> >> Is anyone running BTC1 head in production? Protecting how much value. >> Reminder this is a public list. >> >> Adam >> >> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x >> wrote: >> > The hardfork part is already locked in and is not subject to change. >> Many >> > btc1 nodes are already deployed and they should not and don't need to >> > update. The only thing left is a potential extra softfork for opt-in >> replay >> > protection. Only the miners need this softfork. >> > >> > What makes you think the hardfork will have less than 40% hashpower? >> > >> > >> > Emil Oldenburg, CTO >> > Emil at bitcoin.com >> > Visit the all new https://bitcoin.com >> > Wechat: emilold >> > Telegram: emilold >> > >> > On 2017 >> >> ?10?13? 17:31, Peter BitcoinReminder.com wrote: >> >> >> > >> > Thats not a reason, the BTC1 sourcecode is still in development (f.e. >> replay >> > protection was reverted just 1-2 days ago?) - so the argument ?it can?t >> be >> > called off? is just wrong. >> > >> > So wouldn?t it make sense to add a minimum required hashrate for the HF >> to >> > lock in? You are really going to fork off with f.e. 40 % hashpower? >> > >> > >> > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x >> > : >> > >> > If we try to be technical here. The HF is already activated, is >> estimated to >> > trigger in 36 days, and can't be "called off". Nor is there any logic to >> > delay it if hashrate deflects. That's the rules of the btc1 client. >> > >> > >> > Emil Oldenburg, CTO >> > Emil at bitcoin.com >> > Visit the all new https://bitcoin.com >> > Wechat: emilold >> > Telegram: emilold >> > >> > On 2017 >> >> ?10?13? 05:31, John Heathco via Bitcoin-segwit2x wrote: >> >> >> > >> > I don't believe there is an explicitly stated hashpower in which the >> fork >> > would be "called off", but I would assume it is much lower than what is >> > currently signaling, even if we make the (unwise) assumption that F2Pool >> > would not contribute to mining 2x whatsoever. >> > >> > >> > >> > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via >> > Bitcoin-segwit2x wrote: >> >> >> >> I?m not Peter Todd, we just share the same (nice) firstname. >> >> >> >> I still didn?t get an answer what the minimum amount of hashpower is >> >> required, before the fork is getting delayed? >> >> We have to plan time for the whole security measures etc, so I think >> it?s >> >> reasonable to get more information about this? >> >> >> >> >> >> Am 12.10.2017 um 21:53 schrieb bitPico : >> >> >> >> Without you knowing why they stopped signaling this is FUD and >> off-topic >> >> for this list. Please instead let F2Pool state their own opinion here >> since >> >> yours doesn?t count. If you think your opinion does count then show us >> your >> >> blocks that your pool has produced; until then you are simply an >> end-user >> >> and still you are off-topic for this list. If you need ELI5 for how >> this >> >> list works please let us know and we can help you Peter Todd. >> >> >> >> Have a groovy day! >> >> >> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via >> >> Bitcoin-segwit2x wrote: >> >> >> >> Since F2Pool stopped signaling for the NYA[1] and slush also mines >> mostly >> >> non-NYA blocks, are you still going to fork off in November - >> splitting the >> >> chain intentionally? >> >> >> >> ? >> >> [1] https://imgur.com/LgYdFKw >> >> >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> >> >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > >> > >> > >> > _______________________________________________ >> > Bitcoin-segwit2x mailing list >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > >> > >> > _______________________________________________ >> > Bitcoin-segwit2x mailing list >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > >> > >> > >> > >> > _______________________________________________ >> > Bitcoin-segwit2x mailing list >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at bitso.com Sat Oct 14 00:20:56 2017 From: ben at bitso.com (Ben Peters) Date: Fri, 13 Oct 2017 17:20:56 -0700 (PDT) Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: I think there is a fundamental misunderstanding about the nature of the NYA/Segwit2x endeavour. What is happening here is that an alternative, minimally modified, version of the Bitcoin code is being developed that will implement a change that has long been sought by the mining community and many in industry and beyond (a change that they presumably feel is important for the future success of Bitcoin and thus their respective investments). That candidate code will be offered to the miners and mining pools, who may or may not opt to apply hashing power to it. If they apply more than the threshold amount of hashing power, then that new code will effectively takeover from the previous consensus rule, and take most SPV wallets and economic activity along with it. Rather than lobbying this technical working group to ?call off? their efforts, your time might be better spent lobbying the miners. The function of this group is to produce candidate code, thus fulfilling the obligations as set out under the NYA. > On Oct 13, 2017, at 8:55 AM, Melvin Carvalho via Bitcoin-segwit2x wrote: > > > > > On 13 October 2017 at 12:45, Melvin Carvalho?>wrote: >> >> >> On 13 October 2017 at 12:30, Phillip Katete?>>wrote: >>> The?disingenuity here is ?painful to watch?. First you make hay of f2pool switching off NYA signaling intent THEN you rubbish signaling intent as cheap and not worthy of consideration as a metric. More worryingly, you then want to predicate the HF on miner signaling at the 80% threshold. So which is it then? >>> >>> >>> >>> ? >>> >>> Even with the EDA induced hash oscillations, I am confident hash at and post fork will mirror signaling intent. >>> >>> >>> >> >> 24h signaling fell to 79.86% [1] >> >> >> >> >> > > NYA signaling is now down to 77.70% in the last 24h (down from over 90% a day ago) > > https://coin.dance/blocks > > > > This does not take into account ViaBTC which may support either chain, but are currently signaling 100% NYA. > > > However, much hash is mining bitcoin cash right now, and probably favourable to seg2x > > > > Additionally, you can monitor the futures market in realtime > > https://cryptowat.ch/bitfinex/bt2btc > > > > Currently trading at 10.6% of bitcoin (down from over 20% a day ago) > > > > You may wish to consider these metrics a source of new information for this project.? And / or watch them as they develop. > > ? >> >> [1]?https://coin.dance/blocks#thisweek >> >> >> >> ? >>> >>> >>> >>> >>> ? >>> >>> From:?Melvin Carvalho >>> >>> Sent:?13 October 2017 11:11 >>> To:?Phillip Katete >>> >>> Cc:?Dr Adam Back >>> ;?Emil Oldenburg >>> ;?Peter Todd via Bitcoin-segwit2x >>> >>> >>> Subject:?Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >>> >>> >>> >>> >>> >>> ? >>> >>> >>> ? >>> >>> >>> ? >>> >>> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x >> >>>> wrote: >>> >>> >>>> You are barking up the wrong tree by using a ?rigged? futures? price to estimate the hash supporting the upgrade at fork time. They NYA was presented as being backed by at least 80% of the network hash then and was activated / locked-in by over 90%. Since then, it has continued to receive and sustain intent signalling above the introduction threshold. It is only rational to expect the hash on fork to reflect the latter as opposed to futures? prices. >>>> ? >>>> Obiter dicta: the futures? price is more reflective of the wavering non mining, none? economic users. It goes without saying, a lot of people are going to loose a lot of money on this otherwise rigged futures? market. >>>> >>>> >>>> >>> ? >>> >>> >>> Markets are not always accurate, but simply a form of price discovery, I think "rigged" is perhaps a loaded term in this case and stretching things.? A 12% futures market does not bode well for success, but, you never know. >>> >>> >>> >>> Since F2Pool stopped signaling NYA yesterday the signaling ratio is now about 81%, though this might have something to do with the feast and famine EDA in bitcoin cash which has just been activated.? Around 83% might be a better guess. >>> >>> >>> >>> However signaling is cheap, and many miners act in economic self interest.? Having helped run a coin for many years, I have witnessed this being the case.? There's nothing developers would like more than steady miners that stick with a coin, but sites such as coinwarz [1] all too often create spikes in hash power related to profitability. >>> >>> >>> >>> Wishing to stay on topic, I'd like to ask the following question.? If signaling falls below the described 80% threshold stated above (ie one more miner stops signaling), will this this be grounds to rethink the timing of the release schedule? >>> >>> >>> >>> >>> [1]?https://www.coinwarz.com/cryptocurrency >>> >>> >>> >>> >>> >>> ? >>> >>> >>> >>>> ? >>>> >>>> >>>> From:Dr Adam Back via Bitcoin-segwit2x >>>> >>>> Sent:?13 October 2017 10:11 >>>> To:?Emil Oldenburg >>>> >>>> Cc:?Peter Todd via Bitcoin-segwit2x >>>> >>>> Subject:?Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >>>> >>>> ? >>>> The futures price is 1/3 of 40% so yes actually < 40% hashrate is quite likely. >>>> >>>> >>>> https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https%3a%2f%2fwww.google.com%2f >>>> >>>> >>>> >>>> >>>> Nodes should upgrade because code changes are being made and it's not >>>> a good idea to run pre-production code on the live network.? Do you >>>> recall when the company you work for lost bitcoin by running >>>> pre-release fork code before on the pool? >>>> >>>> Is anyone running BTC1 head in production?? Protecting how much value. >>>> Reminder this is a public list. >>>> >>>> Adam >>>> >>>> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x >>>> >>> >>>>> wrote: >>>>> The hardfork part is already locked in and is not subject to change. Many >>>>> btc1 nodes are already deployed and they should not and don't need to >>>>> update. The only thing left is a potential extra softfork for opt-in replay >>>>> protection. Only the miners need this softfork. >>>>> >>>>> What makes you think the hardfork will have less than 40% hashpower? >>>>> >>>>> >>>>> Emil Oldenburg, CTO >>>>>?Emil at bitcoin.com >>>> >>>>> Visit the all new?https://bitcoin.com >>>> >>>>> Wechat: emilold >>>>> Telegram: emilold >>>>> >>>>> On 2017 >>>> >>>> >>>> >>>> >>>> ?10?13?17:31, Peter BitcoinReminder.com wrote:? >>>> >>>> >>>> >>>>> >>>>> Thats not a reason, the BTC1 sourcecode is still in development (f.e. replay >>>>> protection was reverted just 1-2 days ago?) - so the argument ?it can?t be >>>>> called off? is just wrong. >>>>> >>>>> So wouldn?t it make sense to add a minimum required hashrate for the HF to >>>>> lock in? You are really going to fork off with f.e. 40 % hashpower? >>>>> >>>>> >>>>> Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x >>>>> >>> >>>>>: >>>>> >>>>> If we try to be technical here. The HF is already activated, is estimated to >>>>> trigger in 36 days, and can't be "called off". Nor is there any logic to >>>>> delay it if hashrate deflects. That's the rules of the btc1 client. >>>>> >>>>> >>>>> Emil Oldenburg, CTO >>>>>?Emil at bitcoin.com >>>> >>>>> Visit the all new?https://bitcoin.com >>>> >>>>> Wechat: emilold >>>>> Telegram: emilold >>>>> >>>>> On 2017 >>>> >>>> >>>> >>>> >>>> ?10?13?05:31, John Heathco via Bitcoin-segwit2x wrote:? >>>> >>>> >>>> >>>>> >>>>> I don't believe there is an explicitly stated hashpower in which the fork >>>>> would be "called off", but I would assume it is much lower than what is >>>>> currently signaling, even if we make the (unwise) assumption that F2Pool >>>>> would not contribute to mining 2x whatsoever. >>>>> >>>>> >>>>> >>>>> On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via >>>>> Bitcoin-segwit2x >>> >>>>> wrote: >>>>>> >>>>>> I?m not Peter Todd, we just share the same (nice) firstname. >>>>>> >>>>>> I still didn?t get an answer what the minimum amount of hashpower is >>>>>> required, before the fork is getting delayed? >>>>>> We have to plan time for the whole security measures etc, so I think it?s >>>>>> reasonable to get more information about this? >>>>>> >>>>>> >>>>>> Am 12.10.2017 um 21:53 schrieb bitPico >>>>: >>>>>> >>>>>> Without you knowing why they stopped signaling this is FUD and off-topic >>>>>> for this list. Please instead let F2Pool? state their own opinion here since >>>>>> yours doesn?t count. If you think your opinion does count then show us your >>>>>> blocks that your pool has produced; until then you are simply an end-user >>>>>> and still you are off-topic for this list. If you need ELI5 for how this >>>>>> list works please let us know and we can help you Peter Todd. >>>>>> >>>>>> Have a groovy day! >>>>>> >>>>>> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via >>>>>> Bitcoin-segwit2x >>> >>>>> wrote: >>>>>> >>>>>> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly >>>>>> non-NYA blocks, are you still going to fork off in November - splitting the >>>>>> chain intentionally? >>>>>> >>>>>> ? >>>>>> [1]?https://imgur.com/LgYdFKw >>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Bitcoin-segwit2x mailing list >>>>>>?Bitcoin-segwit2x at lists.linuxfoundation.org >>>> >>>> >>>>>>?https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Bitcoin-segwit2x mailing list >>>>>>?Bitcoin-segwit2x at lists.linuxfoundation.org >>>> >>>> >>>>>>?https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>>?Bitcoin-segwit2x at lists.linuxfoundation.org >>>> >>>> >>>>>?https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>>?Bitcoin-segwit2x at lists.linuxfoundation.org >>>> >>>> >>>>>?https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>>?Bitcoin-segwit2x at lists.linuxfoundation.org >>>> >>>> >>>>>?https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>>> >>>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> >>>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ? >>>> >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> >>>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> ? >>> >>> >>> ? >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Sat Oct 14 02:11:30 2017 From: bitpico at icloud.com (bitPico) Date: Fri, 13 Oct 2017 22:11:30 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: <8F50BA06-7CB6-46FE-99E3-955D6658820A@icloud.com> We are miners and Bitcoin developers with our own non-Satoshi C++ full nodes. We have been SegWit2x compatible for months. We will not be running ?candidate code? as we have our own original code. The goal here is to have many compatible implementations including Bitcoin Unlimited, btc1, XT, Classic, bcoin, bitPico and other full node implementations we may have missed. Miners alike will run whichever code they prefer. Most will keep running the same code they have been running but just re-compile with 2x compatible changes. Bitcoin is a protocol; there is no candidate or reference code only consensus rules that developers and miners either follow or deviate (fork) from. > On Oct 13, 2017, at 8:20 PM, Ben Peters via Bitcoin-segwit2x wrote: > > I think there is a fundamental misunderstanding about the nature of the NYA/Segwit2x endeavour. What is happening here is that an alternative, minimally modified, version of the Bitcoin code is being developed that will implement a change that has long been sought by the mining community and many in industry and beyond (a change that they presumably feel is important for the future success of Bitcoin and thus their respective investments). > > That candidate code will be offered to the miners and mining pools, who may or may not opt to apply hashing power to it. If they apply more than the threshold amount of hashing power, then that new code will effectively takeover from the previous consensus rule, and take most SPV wallets and economic activity along with it. > > Rather than lobbying this technical working group to ?call off? their efforts, your time might be better spent lobbying the miners. The function of this group is to produce candidate code, thus fulfilling the obligations as set out under the NYA. > > > >> On Oct 13, 2017, at 8:55 AM, Melvin Carvalho via Bitcoin-segwit2x wrote: >> >> >> >> On 13 October 2017 at 12:45, Melvin Carvalho wrote: >>> >>> >>> On 13 October 2017 at 12:30, Phillip Katete wrote: >>>> The disingenuity here is ?painful to watch?. First you make hay of f2pool switching off NYA signaling intent THEN you rubbish signaling intent as cheap and not worthy of consideration as a metric. More worryingly, you then want to predicate the HF on miner signaling at the 80% threshold. So which is it then? >>>> >>>> Even with the EDA induced hash oscillations, I am confident hash at and post fork will mirror signaling intent. >>> >>> 24h signaling fell to 79.86% [1] >> >> NYA signaling is now down to 77.70% in the last 24h (down from over 90% a day ago) >> >> https://coin.dance/blocks >> >> This does not take into account ViaBTC which may support either chain, but are currently signaling 100% NYA. >> >> However, much hash is mining bitcoin cash right now, and probably favourable to seg2x >> >> Additionally, you can monitor the futures market in realtime >> >> https://cryptowat.ch/bitfinex/bt2btc >> >> Currently trading at 10.6% of bitcoin (down from over 20% a day ago) >> >> You may wish to consider these metrics a source of new information for this project. And / or watch them as they develop. >> >>> >>> [1] https://coin.dance/blocks#thisweek >>> >>>> >>>> From: Melvin Carvalho >>>> Sent: 13 October 2017 11:11 >>>> To: Phillip Katete >>>> Cc: Dr Adam Back; Emil Oldenburg; Peter Todd via Bitcoin-segwit2x >>>> >>>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >>>> >>>> >>>> >>>> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x wrote: >>>> You are barking up the wrong tree by using a ?rigged? futures? price to estimate the hash supporting the upgrade at fork time. They NYA was presented as being backed by at least 80% of the network hash then and was activated / locked-in by over 90%. Since then, it has continued to receive and sustain intent signalling above the introduction threshold. It is only rational to expect the hash on fork to reflect the latter as opposed to futures? prices. >>>> >>>> Obiter dicta: the futures? price is more reflective of the wavering non mining, none economic users. It goes without saying, a lot of people are going to loose a lot of money on this otherwise rigged futures? market. >>>> >>>> Markets are not always accurate, but simply a form of price discovery, I think "rigged" is perhaps a loaded term in this case and stretching things. A 12% futures market does not bode well for success, but, you never know. >>>> Since F2Pool stopped signaling NYA yesterday the signaling ratio is now about 81%, though this might have something to do with the feast and famine EDA in bitcoin cash which has just been activated. Around 83% might be a better guess. >>>> However signaling is cheap, and many miners act in economic self interest. Having helped run a coin for many years, I have witnessed this being the case. There's nothing developers would like more than steady miners that stick with a coin, but sites such as coinwarz [1] all too often create spikes in hash power related to profitability. >>>> Wishing to stay on topic, I'd like to ask the following question. If signaling falls below the described 80% threshold stated above (ie one more miner stops signaling), will this this be grounds to rethink the timing of the release schedule? >>>> >>>> [1] https://www.coinwarz.com/cryptocurrency >>>> >>>> >>>> From:Dr Adam Back via Bitcoin-segwit2x >>>> Sent: 13 October 2017 10:11 >>>> To: Emil Oldenburg >>>> Cc: Peter Todd via Bitcoin-segwit2x >>>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >>>> >>>> The futures price is 1/3 of 40% so yes actually < 40% hashrate is quite likely. >>>> >>>> >>>> https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https%3a%2f%2fwww.google.com%2f >>>> >>>> Nodes should upgrade because code changes are being made and it's not >>>> a good idea to run pre-production code on the live network. Do you >>>> recall when the company you work for lost bitcoin by running >>>> pre-release fork code before on the pool? >>>> >>>> Is anyone running BTC1 head in production? Protecting how much value. >>>> Reminder this is a public list. >>>> >>>> Adam >>>> >>>> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x >>>> wrote: >>>> > The hardfork part is already locked in and is not subject to change. Many >>>> > btc1 nodes are already deployed and they should not and don't need to >>>> > update. The only thing left is a potential extra softfork for opt-in replay >>>> > protection. Only the miners need this softfork. >>>> > >>>> > What makes you think the hardfork will have less than 40% hashpower? >>>> > >>>> > >>>> > Emil Oldenburg, CTO >>>> > Emil at bitcoin.com >>>> > Visit the all new https://bitcoin.com >>>> > Wechat: emilold >>>> > Telegram: emilold >>>> > >>>> > On 2017 >>>> ?10?13?17:31, Peter BitcoinReminder.com wrote: >>>> >>>> > >>>> > Thats not a reason, the BTC1 sourcecode is still in development (f.e. replay >>>> > protection was reverted just 1-2 days ago?) - so the argument ?it can?t be >>>> > called off? is just wrong. >>>> > >>>> > So wouldn?t it make sense to add a minimum required hashrate for the HF to >>>> > lock in? You are really going to fork off with f.e. 40 % hashpower? >>>> > >>>> > >>>> > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x >>>> > : >>>> > >>>> > If we try to be technical here. The HF is already activated, is estimated to >>>> > trigger in 36 days, and can't be "called off". Nor is there any logic to >>>> > delay it if hashrate deflects. That's the rules of the btc1 client. >>>> > >>>> > >>>> > Emil Oldenburg, CTO >>>> > Emil at bitcoin.com >>>> > Visit the all new https://bitcoin.com >>>> > Wechat: emilold >>>> > Telegram: emilold >>>> > >>>> > On 2017 >>>> ?10?13?05:31, John Heathco via Bitcoin-segwit2x wrote: >>>> >>>> > >>>> > I don't believe there is an explicitly stated hashpower in which the fork >>>> > would be "called off", but I would assume it is much lower than what is >>>> > currently signaling, even if we make the (unwise) assumption that F2Pool >>>> > would not contribute to mining 2x whatsoever. >>>> > >>>> > >>>> > >>>> > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via >>>> > Bitcoin-segwit2x wrote: >>>> >> >>>> >> I?m not Peter Todd, we just share the same (nice) firstname. >>>> >> >>>> >> I still didn?t get an answer what the minimum amount of hashpower is >>>> >> required, before the fork is getting delayed? >>>> >> We have to plan time for the whole security measures etc, so I think it?s >>>> >> reasonable to get more information about this? >>>> >> >>>> >> >>>> >> Am 12.10.2017 um 21:53 schrieb bitPico : >>>> >> >>>> >> Without you knowing why they stopped signaling this is FUD and off-topic >>>> >> for this list. Please instead let F2Pool state their own opinion here since >>>> >> yours doesn?t count. If you think your opinion does count then show us your >>>> >> blocks that your pool has produced; until then you are simply an end-user >>>> >> and still you are off-topic for this list. If you need ELI5 for how this >>>> >> list works please let us know and we can help you Peter Todd. >>>> >> >>>> >> Have a groovy day! >>>> >> >>>> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via >>>> >> Bitcoin-segwit2x wrote: >>>> >> >>>> >> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly >>>> >> non-NYA blocks, are you still going to fork off in November - splitting the >>>> >> chain intentionally? >>>> >> >>>> >> ? >>>> >> [1] https://imgur.com/LgYdFKw >>>> >> >>>> >> _______________________________________________ >>>> >> Bitcoin-segwit2x mailing list >>>> >> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> Bitcoin-segwit2x mailing list >>>> >> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Bitcoin-segwit2x mailing list >>>> > Bitcoin-segwit2x at lists.linuxfoundation.org >>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> > >>>> > >>>> > _______________________________________________ >>>> > Bitcoin-segwit2x mailing list >>>> > Bitcoin-segwit2x at lists.linuxfoundation.org >>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> > >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Bitcoin-segwit2x mailing list >>>> > Bitcoin-segwit2x at lists.linuxfoundation.org >>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> > >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel at jamin.net Sat Oct 14 05:31:27 2017 From: marcel at jamin.net (Marcel Jamin) Date: Sat, 14 Oct 2017 07:31:27 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: On 14 October 2017 at 02:20, Ben Peters via Bitcoin-segwit2x wrote: > I think there is a fundamental misunderstanding about the nature of the > NYA/Segwit2x endeavour. What is happening here is that an alternative, > minimally modified, version of the Bitcoin code is being developed that will > implement a change that has long been sought by the mining community and > many in industry and beyond (a change that they presumably feel is important > for the future success of Bitcoin and thus their respective investments). > > That candidate code will be offered to the miners and mining pools, who may > or may not opt to apply hashing power to it. If they apply more than the > threshold amount of hashing power, then that new code will effectively > takeover from the previous consensus rule, and take most SPV wallets and > economic activity along with it. > > Rather than lobbying this technical working group to ?call off? their > efforts, your time might be better spent lobbying the miners. The function > of this group is to produce candidate code, thus fulfilling the obligations > as set out under the NYA. Fair enough, but this working group is making technical decisions that can create a lof of confusion and cause many problems for bitcoin users. Much of the lobbying is targeted towards implementing strong two-way replay protection. The reason for not implementing this protection, is that it would reveal this project as an alternative fork of bitcoin and is based on the assumption, that most miners will in fact employ the client put forward by this WG and apply their hashpower to it. Many indicators however point towards a virtually guaranteed network split. The NYA committed signers to "deployment of safe solutions that increase bitcoin capacity". This implementation doesn't fulfill that goal. Without strong replay protection, this will be a mess for both sides. > > > On Oct 13, 2017, at 8:55 AM, Melvin Carvalho via Bitcoin-segwit2x > wrote: > > > > On 13 October 2017 at 12:45, Melvin Carvalho > wrote: >> >> >> >> On 13 October 2017 at 12:30, Phillip Katete wrote: >>> >>> The disingenuity here is ?painful to watch?. First you make hay of f2pool >>> switching off NYA signaling intent THEN you rubbish signaling intent as >>> cheap and not worthy of consideration as a metric. More worryingly, you then >>> want to predicate the HF on miner signaling at the 80% threshold. So which >>> is it then? >>> >>> Even with the EDA induced hash oscillations, I am confident hash at and >>> post fork will mirror signaling intent. >> >> >> 24h signaling fell to 79.86% [1] > > > NYA signaling is now down to 77.70% in the last 24h (down from over 90% a > day ago) > > https://coin.dance/blocks > > This does not take into account ViaBTC which may support either chain, but > are currently signaling 100% NYA. > > However, much hash is mining bitcoin cash right now, and probably favourable > to seg2x > > Additionally, you can monitor the futures market in realtime > > https://cryptowat.ch/bitfinex/bt2btc > > Currently trading at 10.6% of bitcoin (down from over 20% a day ago) > > You may wish to consider these metrics a source of new information for this > project. And / or watch them as they develop. > >> >> >> [1] https://coin.dance/blocks#thisweek >> >>> >>> >>> From: Melvin Carvalho >>> Sent: 13 October 2017 11:11 >>> To: Phillip Katete >>> Cc: Dr Adam Back; Emil Oldenburg; Peter Todd via Bitcoin-segwit2x >>> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still >>> happening? >>> >>> >>> >>> >>> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x >>> wrote: >>> >>> You are barking up the wrong tree by using a ?rigged? futures? price to >>> estimate the hash supporting the upgrade at fork time. They NYA was >>> presented as being backed by at least 80% of the network hash then and was >>> activated / locked-in by over 90%. Since then, it has continued to receive >>> and sustain intent signalling above the introduction threshold. It is only >>> rational to expect the hash on fork to reflect the latter as opposed to >>> futures? prices. >>> >>> Obiter dicta: the futures? price is more reflective of the wavering non >>> mining, none economic users. It goes without saying, a lot of people are >>> going to loose a lot of money on this otherwise rigged futures? market. >>> >>> >>> Markets are not always accurate, but simply a form of price discovery, I >>> think "rigged" is perhaps a loaded term in this case and stretching things. >>> A 12% futures market does not bode well for success, but, you never know. >>> Since F2Pool stopped signaling NYA yesterday the signaling ratio is now >>> about 81%, though this might have something to do with the feast and famine >>> EDA in bitcoin cash which has just been activated. Around 83% might be a >>> better guess. >>> However signaling is cheap, and many miners act in economic self >>> interest. Having helped run a coin for many years, I have witnessed this >>> being the case. There's nothing developers would like more than steady >>> miners that stick with a coin, but sites such as coinwarz [1] all too often >>> create spikes in hash power related to profitability. >>> Wishing to stay on topic, I'd like to ask the following question. If >>> signaling falls below the described 80% threshold stated above (ie one more >>> miner stops signaling), will this this be grounds to rethink the timing of >>> the release schedule? >>> >>> [1] https://www.coinwarz.com/cryptocurrency >>> >>> >>> >>> From:Dr Adam Back via Bitcoin-segwit2x >>> Sent: 13 October 2017 10:11 >>> To: Emil Oldenburg >>> Cc: Peter Todd via Bitcoin-segwit2x >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still >>> happening? >>> >>> The futures price is 1/3 of 40% so yes actually < 40% hashrate is quite >>> likely. >>> >>> >>> >>> https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https%3a%2f%2fwww.google.com%2f >>> >>> Nodes should upgrade because code changes are being made and it's not >>> a good idea to run pre-production code on the live network. Do you >>> recall when the company you work for lost bitcoin by running >>> pre-release fork code before on the pool? >>> >>> Is anyone running BTC1 head in production? Protecting how much value. >>> Reminder this is a public list. >>> >>> Adam >>> >>> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x >>> wrote: >>> > The hardfork part is already locked in and is not subject to change. >>> > Many >>> > btc1 nodes are already deployed and they should not and don't need to >>> > update. The only thing left is a potential extra softfork for opt-in >>> > replay >>> > protection. Only the miners need this softfork. >>> > >>> > What makes you think the hardfork will have less than 40% hashpower? >>> > >>> > >>> > Emil Oldenburg, CTO >>> > Emil at bitcoin.com >>> > Visit the all new https://bitcoin.com >>> > Wechat: emilold >>> > Telegram: emilold >>> > >>> > On 2017 >>> ?10?13?17:31, Peter BitcoinReminder.com wrote: >>> >>> > >>> > Thats not a reason, the BTC1 sourcecode is still in development (f.e. >>> > replay >>> > protection was reverted just 1-2 days ago?) - so the argument ?it can?t >>> > be >>> > called off? is just wrong. >>> > >>> > So wouldn?t it make sense to add a minimum required hashrate for the HF >>> > to >>> > lock in? You are really going to fork off with f.e. 40 % hashpower? >>> > >>> > >>> > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x >>> > : >>> > >>> > If we try to be technical here. The HF is already activated, is >>> > estimated to >>> > trigger in 36 days, and can't be "called off". Nor is there any logic >>> > to >>> > delay it if hashrate deflects. That's the rules of the btc1 client. >>> > >>> > >>> > Emil Oldenburg, CTO >>> > Emil at bitcoin.com >>> > Visit the all new https://bitcoin.com >>> > Wechat: emilold >>> > Telegram: emilold >>> > >>> > On 2017 >>> ?10?13?05:31, John Heathco via Bitcoin-segwit2x wrote: >>> >>> > >>> > I don't believe there is an explicitly stated hashpower in which the >>> > fork >>> > would be "called off", but I would assume it is much lower than what is >>> > currently signaling, even if we make the (unwise) assumption that >>> > F2Pool >>> > would not contribute to mining 2x whatsoever. >>> > >>> > >>> > >>> > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via >>> > Bitcoin-segwit2x wrote: >>> >> >>> >> I?m not Peter Todd, we just share the same (nice) firstname. >>> >> >>> >> I still didn?t get an answer what the minimum amount of hashpower is >>> >> required, before the fork is getting delayed? >>> >> We have to plan time for the whole security measures etc, so I think >>> >> it?s >>> >> reasonable to get more information about this? >>> >> >>> >> >>> >> Am 12.10.2017 um 21:53 schrieb bitPico : >>> >> >>> >> Without you knowing why they stopped signaling this is FUD and >>> >> off-topic >>> >> for this list. Please instead let F2Pool state their own opinion here >>> >> since >>> >> yours doesn?t count. If you think your opinion does count then show us >>> >> your >>> >> blocks that your pool has produced; until then you are simply an >>> >> end-user >>> >> and still you are off-topic for this list. If you need ELI5 for how >>> >> this >>> >> list works please let us know and we can help you Peter Todd. >>> >> >>> >> Have a groovy day! >>> >> >>> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via >>> >> Bitcoin-segwit2x wrote: >>> >> >>> >> Since F2Pool stopped signaling for the NYA[1] and slush also mines >>> >> mostly >>> >> non-NYA blocks, are you still going to fork off in November - >>> >> splitting the >>> >> chain intentionally? >>> >> >>> >> ? >>> >> [1] https://imgur.com/LgYdFKw >>> >> >>> >> _______________________________________________ >>> >> Bitcoin-segwit2x mailing list >>> >> Bitcoin-segwit2x at lists.linuxfoundation.org >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> Bitcoin-segwit2x mailing list >>> >> Bitcoin-segwit2x at lists.linuxfoundation.org >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> > >>> > >>> > >>> > _______________________________________________ >>> > Bitcoin-segwit2x mailing list >>> > Bitcoin-segwit2x at lists.linuxfoundation.org >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> > >>> > >>> > _______________________________________________ >>> > Bitcoin-segwit2x mailing list >>> > Bitcoin-segwit2x at lists.linuxfoundation.org >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Bitcoin-segwit2x mailing list >>> > Bitcoin-segwit2x at lists.linuxfoundation.org >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> > >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From jacob.eliosoff at gmail.com Sat Oct 14 05:53:58 2017 From: jacob.eliosoff at gmail.com (Jacob Eliosoff) Date: Sat, 14 Oct 2017 01:53:58 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: Can I ask that anyone advocating 2-way replay protection (which I also support) be specific about how they propose it be done? No disrespect meant, but BCH-style RP, that would require old wallets to upgrade, has been proposed and emphatically NACKed here umpteen times: it is just unrealistic to think this project would adopt it at this stage. There are other 2-way RP approaches that I still believe are worth pursuing , but at this point any discussion of 2-way RP as if it's a simple binary decision is a complete waste of everyone's time. On Sat, Oct 14, 2017 at 1:31 AM, Marcel Jamin via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > On 14 October 2017 at 02:20, Ben Peters via Bitcoin-segwit2x > wrote: > > I think there is a fundamental misunderstanding about the nature of the > > NYA/Segwit2x endeavour. What is happening here is that an alternative, > > minimally modified, version of the Bitcoin code is being developed that > will > > implement a change that has long been sought by the mining community and > > many in industry and beyond (a change that they presumably feel is > important > > for the future success of Bitcoin and thus their respective investments). > > > > That candidate code will be offered to the miners and mining pools, who > may > > or may not opt to apply hashing power to it. If they apply more than the > > threshold amount of hashing power, then that new code will effectively > > takeover from the previous consensus rule, and take most SPV wallets and > > economic activity along with it. > > > > Rather than lobbying this technical working group to ?call off? their > > efforts, your time might be better spent lobbying the miners. The > function > > of this group is to produce candidate code, thus fulfilling the > obligations > > as set out under the NYA. > > Fair enough, but this working group is making technical decisions that > can create a lof of confusion and cause many problems for bitcoin > users. > > Much of the lobbying is targeted towards implementing strong two-way > replay protection. The reason for not implementing this protection, is > that it would reveal this project as an alternative fork of bitcoin > and is based on the assumption, that most miners will in fact employ > the client put forward by this WG and apply their hashpower to it. > > Many indicators however point towards a virtually guaranteed network split. > > The NYA committed signers to "deployment of safe solutions that > increase bitcoin capacity". This implementation doesn't fulfill that > goal. Without strong replay protection, this will be a mess for both > sides. > > > > > > > On Oct 13, 2017, at 8:55 AM, Melvin Carvalho via Bitcoin-segwit2x > > wrote: > > > > > > > > On 13 October 2017 at 12:45, Melvin Carvalho > > wrote: > >> > >> > >> > >> On 13 October 2017 at 12:30, Phillip Katete >wrote: > >>> > >>> The disingenuity here is ?painful to watch?. First you make hay of > f2pool > >>> switching off NYA signaling intent THEN you rubbish signaling intent as > >>> cheap and not worthy of consideration as a metric. More worryingly, > you then > >>> want to predicate the HF on miner signaling at the 80% threshold. So > which > >>> is it then? > >>> > >>> Even with the EDA induced hash oscillations, I am confident hash at and > >>> post fork will mirror signaling intent. > >> > >> > >> 24h signaling fell to 79.86% [1] > > > > > > NYA signaling is now down to 77.70% in the last 24h (down from over 90% a > > day ago) > > > > https://coin.dance/blocks > > > > This does not take into account ViaBTC which may support either chain, > but > > are currently signaling 100% NYA. > > > > However, much hash is mining bitcoin cash right now, and probably > favourable > > to seg2x > > > > Additionally, you can monitor the futures market in realtime > > > > https://cryptowat.ch/bitfinex/bt2btc > > > > Currently trading at 10.6% of bitcoin (down from over 20% a day ago) > > > > You may wish to consider these metrics a source of new information for > this > > project. And / or watch them as they develop. > > > >> > >> > >> [1] https://coin.dance/blocks#thisweek > >> > >>> > >>> > >>> From: Melvin Carvalho > >>> Sent: 13 October 2017 11:11 > >>> To: Phillip Katete > >>> Cc: Dr Adam Back; Emil Oldenburg; Peter Todd via Bitcoin-segwit2x > >>> > >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > >>> happening? > >>> > >>> > >>> > >>> > >>> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x > >>> wrote: > >>> > >>> You are barking up the wrong tree by using a ?rigged? futures? price to > >>> estimate the hash supporting the upgrade at fork time. They NYA was > >>> presented as being backed by at least 80% of the network hash then and > was > >>> activated / locked-in by over 90%. Since then, it has continued to > receive > >>> and sustain intent signalling above the introduction threshold. It is > only > >>> rational to expect the hash on fork to reflect the latter as opposed to > >>> futures? prices. > >>> > >>> Obiter dicta: the futures? price is more reflective of the wavering non > >>> mining, none economic users. It goes without saying, a lot of people > are > >>> going to loose a lot of money on this otherwise rigged futures? market. > >>> > >>> > >>> Markets are not always accurate, but simply a form of price discovery, > I > >>> think "rigged" is perhaps a loaded term in this case and stretching > things. > >>> A 12% futures market does not bode well for success, but, you never > know. > >>> Since F2Pool stopped signaling NYA yesterday the signaling ratio is now > >>> about 81%, though this might have something to do with the feast and > famine > >>> EDA in bitcoin cash which has just been activated. Around 83% might > be a > >>> better guess. > >>> However signaling is cheap, and many miners act in economic self > >>> interest. Having helped run a coin for many years, I have witnessed > this > >>> being the case. There's nothing developers would like more than steady > >>> miners that stick with a coin, but sites such as coinwarz [1] all too > often > >>> create spikes in hash power related to profitability. > >>> Wishing to stay on topic, I'd like to ask the following question. If > >>> signaling falls below the described 80% threshold stated above (ie one > more > >>> miner stops signaling), will this this be grounds to rethink the > timing of > >>> the release schedule? > >>> > >>> [1] https://www.coinwarz.com/cryptocurrency > >>> > >>> > >>> > >>> From:Dr Adam Back via Bitcoin-segwit2x > >>> Sent: 13 October 2017 10:11 > >>> To: Emil Oldenburg > >>> Cc: Peter Todd via Bitcoin-segwit2x > >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > >>> happening? > >>> > >>> The futures price is 1/3 of 40% so yes actually < 40% hashrate is quite > >>> likely. > >>> > >>> > >>> > >>> https://www.cryptonator.com/rates/BT2-BTC?utm_referrer= > https%3a%2f%2fwww.google.com%2f > >>> > >>> Nodes should upgrade because code changes are being made and it's not > >>> a good idea to run pre-production code on the live network. Do you > >>> recall when the company you work for lost bitcoin by running > >>> pre-release fork code before on the pool? > >>> > >>> Is anyone running BTC1 head in production? Protecting how much value. > >>> Reminder this is a public list. > >>> > >>> Adam > >>> > >>> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x > >>> wrote: > >>> > The hardfork part is already locked in and is not subject to change. > >>> > Many > >>> > btc1 nodes are already deployed and they should not and don't need to > >>> > update. The only thing left is a potential extra softfork for opt-in > >>> > replay > >>> > protection. Only the miners need this softfork. > >>> > > >>> > What makes you think the hardfork will have less than 40% hashpower? > >>> > > >>> > > >>> > Emil Oldenburg, CTO > >>> > Emil at bitcoin.com > >>> > Visit the all new https://bitcoin.com > >>> > Wechat: emilold > >>> > Telegram: emilold > >>> > > >>> > On 2017 > >>> ?10?13?17:31, Peter BitcoinReminder.com wrote: > >>> > >>> > > >>> > Thats not a reason, the BTC1 sourcecode is still in development (f.e. > >>> > replay > >>> > protection was reverted just 1-2 days ago?) - so the argument ?it > can?t > >>> > be > >>> > called off? is just wrong. > >>> > > >>> > So wouldn?t it make sense to add a minimum required hashrate for the > HF > >>> > to > >>> > lock in? You are really going to fork off with f.e. 40 % hashpower? > >>> > > >>> > > >>> > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x > >>> > : > >>> > > >>> > If we try to be technical here. The HF is already activated, is > >>> > estimated to > >>> > trigger in 36 days, and can't be "called off". Nor is there any logic > >>> > to > >>> > delay it if hashrate deflects. That's the rules of the btc1 client. > >>> > > >>> > > >>> > Emil Oldenburg, CTO > >>> > Emil at bitcoin.com > >>> > Visit the all new https://bitcoin.com > >>> > Wechat: emilold > >>> > Telegram: emilold > >>> > > >>> > On 2017 > >>> ?10?13?05:31, John Heathco via Bitcoin-segwit2x wrote: > >>> > >>> > > >>> > I don't believe there is an explicitly stated hashpower in which the > >>> > fork > >>> > would be "called off", but I would assume it is much lower than what > is > >>> > currently signaling, even if we make the (unwise) assumption that > >>> > F2Pool > >>> > would not contribute to mining 2x whatsoever. > >>> > > >>> > > >>> > > >>> > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via > >>> > Bitcoin-segwit2x wrote: > >>> >> > >>> >> I?m not Peter Todd, we just share the same (nice) firstname. > >>> >> > >>> >> I still didn?t get an answer what the minimum amount of hashpower is > >>> >> required, before the fork is getting delayed? > >>> >> We have to plan time for the whole security measures etc, so I think > >>> >> it?s > >>> >> reasonable to get more information about this? > >>> >> > >>> >> > >>> >> Am 12.10.2017 um 21:53 schrieb bitPico : > >>> >> > >>> >> Without you knowing why they stopped signaling this is FUD and > >>> >> off-topic > >>> >> for this list. Please instead let F2Pool state their own opinion > here > >>> >> since > >>> >> yours doesn?t count. If you think your opinion does count then show > us > >>> >> your > >>> >> blocks that your pool has produced; until then you are simply an > >>> >> end-user > >>> >> and still you are off-topic for this list. If you need ELI5 for how > >>> >> this > >>> >> list works please let us know and we can help you Peter Todd. > >>> >> > >>> >> Have a groovy day! > >>> >> > >>> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via > >>> >> Bitcoin-segwit2x > wrote: > >>> >> > >>> >> Since F2Pool stopped signaling for the NYA[1] and slush also mines > >>> >> mostly > >>> >> non-NYA blocks, are you still going to fork off in November - > >>> >> splitting the > >>> >> chain intentionally? > >>> >> > >>> >> ? > >>> >> [1] https://imgur.com/LgYdFKw > >>> >> > >>> >> _______________________________________________ > >>> >> Bitcoin-segwit2x mailing list > >>> >> Bitcoin-segwit2x at lists.linuxfoundation.org > >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>> >> > >>> >> > >>> >> > >>> >> _______________________________________________ > >>> >> Bitcoin-segwit2x mailing list > >>> >> Bitcoin-segwit2x at lists.linuxfoundation.org > >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Bitcoin-segwit2x mailing list > >>> > Bitcoin-segwit2x at lists.linuxfoundation.org > >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>> > > >>> > > >>> > _______________________________________________ > >>> > Bitcoin-segwit2x mailing list > >>> > Bitcoin-segwit2x at lists.linuxfoundation.org > >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Bitcoin-segwit2x mailing list > >>> > Bitcoin-segwit2x at lists.linuxfoundation.org > >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>> > > >>> _______________________________________________ > >>> Bitcoin-segwit2x mailing list > >>> Bitcoin-segwit2x at lists.linuxfoundation.org > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>> > >>> > >>> _______________________________________________ > >>> Bitcoin-segwit2x mailing list > >>> Bitcoin-segwit2x at lists.linuxfoundation.org > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>> > >>> > >>> > >> > >> > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel at jamin.net Sat Oct 14 06:24:42 2017 From: marcel at jamin.net (Marcel Jamin) Date: Sat, 14 Oct 2017 08:24:42 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: I wouldn't consider any opt-in approach as "strong" replay protection. If this WG as NACKed strong two way replay protection, then it's not a safe upgrade path und thus not an implementation honoring the NYA. On 14 October 2017 at 07:53, Jacob Eliosoff wrote: > Can I ask that anyone advocating 2-way replay protection (which I also > support) be specific about how they propose it be done? No disrespect > meant, but BCH-style RP, that would require old wallets to upgrade, has been > proposed and emphatically NACKed here umpteen times: it is just unrealistic > to think this project would adopt it at this stage. There are other 2-way > RP approaches that I still believe are worth pursuing, but at this point any > discussion of 2-way RP as if it's a simple binary decision is a complete > waste of everyone's time. > > > On Sat, Oct 14, 2017 at 1:31 AM, Marcel Jamin via Bitcoin-segwit2x > wrote: >> >> On 14 October 2017 at 02:20, Ben Peters via Bitcoin-segwit2x >> wrote: >> > I think there is a fundamental misunderstanding about the nature of the >> > NYA/Segwit2x endeavour. What is happening here is that an alternative, >> > minimally modified, version of the Bitcoin code is being developed that >> > will >> > implement a change that has long been sought by the mining community and >> > many in industry and beyond (a change that they presumably feel is >> > important >> > for the future success of Bitcoin and thus their respective >> > investments). >> > >> > That candidate code will be offered to the miners and mining pools, who >> > may >> > or may not opt to apply hashing power to it. If they apply more than the >> > threshold amount of hashing power, then that new code will effectively >> > takeover from the previous consensus rule, and take most SPV wallets and >> > economic activity along with it. >> > >> > Rather than lobbying this technical working group to ?call off? their >> > efforts, your time might be better spent lobbying the miners. The >> > function >> > of this group is to produce candidate code, thus fulfilling the >> > obligations >> > as set out under the NYA. >> >> Fair enough, but this working group is making technical decisions that >> can create a lof of confusion and cause many problems for bitcoin >> users. >> >> Much of the lobbying is targeted towards implementing strong two-way >> replay protection. The reason for not implementing this protection, is >> that it would reveal this project as an alternative fork of bitcoin >> and is based on the assumption, that most miners will in fact employ >> the client put forward by this WG and apply their hashpower to it. >> >> Many indicators however point towards a virtually guaranteed network >> split. >> >> The NYA committed signers to "deployment of safe solutions that >> increase bitcoin capacity". This implementation doesn't fulfill that >> goal. Without strong replay protection, this will be a mess for both >> sides. >> >> > >> > >> > On Oct 13, 2017, at 8:55 AM, Melvin Carvalho via Bitcoin-segwit2x >> > wrote: >> > >> > >> > >> > On 13 October 2017 at 12:45, Melvin Carvalho >> > wrote: >> >> >> >> >> >> >> >> On 13 October 2017 at 12:30, Phillip Katete >> >> wrote: >> >>> >> >>> The disingenuity here is ?painful to watch?. First you make hay of >> >>> f2pool >> >>> switching off NYA signaling intent THEN you rubbish signaling intent >> >>> as >> >>> cheap and not worthy of consideration as a metric. More worryingly, >> >>> you then >> >>> want to predicate the HF on miner signaling at the 80% threshold. So >> >>> which >> >>> is it then? >> >>> >> >>> Even with the EDA induced hash oscillations, I am confident hash at >> >>> and >> >>> post fork will mirror signaling intent. >> >> >> >> >> >> 24h signaling fell to 79.86% [1] >> > >> > >> > NYA signaling is now down to 77.70% in the last 24h (down from over 90% >> > a >> > day ago) >> > >> > https://coin.dance/blocks >> > >> > This does not take into account ViaBTC which may support either chain, >> > but >> > are currently signaling 100% NYA. >> > >> > However, much hash is mining bitcoin cash right now, and probably >> > favourable >> > to seg2x >> > >> > Additionally, you can monitor the futures market in realtime >> > >> > https://cryptowat.ch/bitfinex/bt2btc >> > >> > Currently trading at 10.6% of bitcoin (down from over 20% a day ago) >> > >> > You may wish to consider these metrics a source of new information for >> > this >> > project. And / or watch them as they develop. >> > >> >> >> >> >> >> [1] https://coin.dance/blocks#thisweek >> >> >> >>> >> >>> >> >>> From: Melvin Carvalho >> >>> Sent: 13 October 2017 11:11 >> >>> To: Phillip Katete >> >>> Cc: Dr Adam Back; Emil Oldenburg; Peter Todd via Bitcoin-segwit2x >> >>> >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still >> >>> happening? >> >>> >> >>> >> >>> >> >>> >> >>> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x >> >>> wrote: >> >>> >> >>> You are barking up the wrong tree by using a ?rigged? futures? price >> >>> to >> >>> estimate the hash supporting the upgrade at fork time. They NYA was >> >>> presented as being backed by at least 80% of the network hash then and >> >>> was >> >>> activated / locked-in by over 90%. Since then, it has continued to >> >>> receive >> >>> and sustain intent signalling above the introduction threshold. It is >> >>> only >> >>> rational to expect the hash on fork to reflect the latter as opposed >> >>> to >> >>> futures? prices. >> >>> >> >>> Obiter dicta: the futures? price is more reflective of the wavering >> >>> non >> >>> mining, none economic users. It goes without saying, a lot of people >> >>> are >> >>> going to loose a lot of money on this otherwise rigged futures? >> >>> market. >> >>> >> >>> >> >>> Markets are not always accurate, but simply a form of price discovery, >> >>> I >> >>> think "rigged" is perhaps a loaded term in this case and stretching >> >>> things. >> >>> A 12% futures market does not bode well for success, but, you never >> >>> know. >> >>> Since F2Pool stopped signaling NYA yesterday the signaling ratio is >> >>> now >> >>> about 81%, though this might have something to do with the feast and >> >>> famine >> >>> EDA in bitcoin cash which has just been activated. Around 83% might >> >>> be a >> >>> better guess. >> >>> However signaling is cheap, and many miners act in economic self >> >>> interest. Having helped run a coin for many years, I have witnessed >> >>> this >> >>> being the case. There's nothing developers would like more than >> >>> steady >> >>> miners that stick with a coin, but sites such as coinwarz [1] all too >> >>> often >> >>> create spikes in hash power related to profitability. >> >>> Wishing to stay on topic, I'd like to ask the following question. If >> >>> signaling falls below the described 80% threshold stated above (ie one >> >>> more >> >>> miner stops signaling), will this this be grounds to rethink the >> >>> timing of >> >>> the release schedule? >> >>> >> >>> [1] https://www.coinwarz.com/cryptocurrency >> >>> >> >>> >> >>> >> >>> From:Dr Adam Back via Bitcoin-segwit2x >> >>> Sent: 13 October 2017 10:11 >> >>> To: Emil Oldenburg >> >>> Cc: Peter Todd via Bitcoin-segwit2x >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still >> >>> happening? >> >>> >> >>> The futures price is 1/3 of 40% so yes actually < 40% hashrate is >> >>> quite >> >>> likely. >> >>> >> >>> >> >>> >> >>> >> >>> https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https%3a%2f%2fwww.google.com%2f >> >>> >> >>> Nodes should upgrade because code changes are being made and it's not >> >>> a good idea to run pre-production code on the live network. Do you >> >>> recall when the company you work for lost bitcoin by running >> >>> pre-release fork code before on the pool? >> >>> >> >>> Is anyone running BTC1 head in production? Protecting how much value. >> >>> Reminder this is a public list. >> >>> >> >>> Adam >> >>> >> >>> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x >> >>> wrote: >> >>> > The hardfork part is already locked in and is not subject to change. >> >>> > Many >> >>> > btc1 nodes are already deployed and they should not and don't need >> >>> > to >> >>> > update. The only thing left is a potential extra softfork for opt-in >> >>> > replay >> >>> > protection. Only the miners need this softfork. >> >>> > >> >>> > What makes you think the hardfork will have less than 40% hashpower? >> >>> > >> >>> > >> >>> > Emil Oldenburg, CTO >> >>> > Emil at bitcoin.com >> >>> > Visit the all new https://bitcoin.com >> >>> > Wechat: emilold >> >>> > Telegram: emilold >> >>> > >> >>> > On 2017 >> >>> ?10?13?17:31, Peter BitcoinReminder.com wrote: >> >>> >> >>> > >> >>> > Thats not a reason, the BTC1 sourcecode is still in development >> >>> > (f.e. >> >>> > replay >> >>> > protection was reverted just 1-2 days ago?) - so the argument ?it >> >>> > can?t >> >>> > be >> >>> > called off? is just wrong. >> >>> > >> >>> > So wouldn?t it make sense to add a minimum required hashrate for the >> >>> > HF >> >>> > to >> >>> > lock in? You are really going to fork off with f.e. 40 % hashpower? >> >>> > >> >>> > >> >>> > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x >> >>> > : >> >>> > >> >>> > If we try to be technical here. The HF is already activated, is >> >>> > estimated to >> >>> > trigger in 36 days, and can't be "called off". Nor is there any >> >>> > logic >> >>> > to >> >>> > delay it if hashrate deflects. That's the rules of the btc1 client. >> >>> > >> >>> > >> >>> > Emil Oldenburg, CTO >> >>> > Emil at bitcoin.com >> >>> > Visit the all new https://bitcoin.com >> >>> > Wechat: emilold >> >>> > Telegram: emilold >> >>> > >> >>> > On 2017 >> >>> ?10?13?05:31, John Heathco via Bitcoin-segwit2x wrote: >> >>> >> >>> > >> >>> > I don't believe there is an explicitly stated hashpower in which the >> >>> > fork >> >>> > would be "called off", but I would assume it is much lower than what >> >>> > is >> >>> > currently signaling, even if we make the (unwise) assumption that >> >>> > F2Pool >> >>> > would not contribute to mining 2x whatsoever. >> >>> > >> >>> > >> >>> > >> >>> > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via >> >>> > Bitcoin-segwit2x wrote: >> >>> >> >> >>> >> I?m not Peter Todd, we just share the same (nice) firstname. >> >>> >> >> >>> >> I still didn?t get an answer what the minimum amount of hashpower >> >>> >> is >> >>> >> required, before the fork is getting delayed? >> >>> >> We have to plan time for the whole security measures etc, so I >> >>> >> think >> >>> >> it?s >> >>> >> reasonable to get more information about this? >> >>> >> >> >>> >> >> >>> >> Am 12.10.2017 um 21:53 schrieb bitPico : >> >>> >> >> >>> >> Without you knowing why they stopped signaling this is FUD and >> >>> >> off-topic >> >>> >> for this list. Please instead let F2Pool state their own opinion >> >>> >> here >> >>> >> since >> >>> >> yours doesn?t count. If you think your opinion does count then show >> >>> >> us >> >>> >> your >> >>> >> blocks that your pool has produced; until then you are simply an >> >>> >> end-user >> >>> >> and still you are off-topic for this list. If you need ELI5 for how >> >>> >> this >> >>> >> list works please let us know and we can help you Peter Todd. >> >>> >> >> >>> >> Have a groovy day! >> >>> >> >> >>> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via >> >>> >> Bitcoin-segwit2x >> >>> >> wrote: >> >>> >> >> >>> >> Since F2Pool stopped signaling for the NYA[1] and slush also mines >> >>> >> mostly >> >>> >> non-NYA blocks, are you still going to fork off in November - >> >>> >> splitting the >> >>> >> chain intentionally? >> >>> >> >> >>> >> ? >> >>> >> [1] https://imgur.com/LgYdFKw >> >>> >> >> >>> >> _______________________________________________ >> >>> >> Bitcoin-segwit2x mailing list >> >>> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >>> >> >> >>> >> >> >>> >> >> >>> >> _______________________________________________ >> >>> >> Bitcoin-segwit2x mailing list >> >>> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >>> > >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > Bitcoin-segwit2x mailing list >> >>> > Bitcoin-segwit2x at lists.linuxfoundation.org >> >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > Bitcoin-segwit2x mailing list >> >>> > Bitcoin-segwit2x at lists.linuxfoundation.org >> >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > Bitcoin-segwit2x mailing list >> >>> > Bitcoin-segwit2x at lists.linuxfoundation.org >> >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >>> > >> >>> _______________________________________________ >> >>> Bitcoin-segwit2x mailing list >> >>> Bitcoin-segwit2x at lists.linuxfoundation.org >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >>> >> >>> >> >>> _______________________________________________ >> >>> Bitcoin-segwit2x mailing list >> >>> Bitcoin-segwit2x at lists.linuxfoundation.org >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >>> >> >>> >> >>> >> >> >> >> >> > >> > _______________________________________________ >> > Bitcoin-segwit2x mailing list >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > >> > >> > _______________________________________________ >> > Bitcoin-segwit2x mailing list >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > From jacob.eliosoff at gmail.com Sat Oct 14 06:38:12 2017 From: jacob.eliosoff at gmail.com (Jacob Eliosoff) Date: Sat, 14 Oct 2017 02:38:12 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: My link included approaches that at least make it easy for users to send 1x-only txs - approaches that could conceivably get deployed by 2x, and thus protect 1x users. Just repeatedly banging your head against the wall with a proposal everyone can see has 0 chance at deployment (want to bet?) doesn't protect users at all. It accomplishes exactly as much for your cause as sending 100 mails to this list saying "DON'T HF!" Anyway that's my 2c. If you want to discuss further let's talk offline or on Twitter - somewhere other than a list for plausible technical proposals. On Sat, Oct 14, 2017 at 2:24 AM, Marcel Jamin wrote: > I wouldn't consider any opt-in approach as "strong" replay protection. > If this WG as NACKed strong two way replay protection, then it's not a > safe upgrade path und thus not an implementation honoring the NYA. > > On 14 October 2017 at 07:53, Jacob Eliosoff > wrote: > > Can I ask that anyone advocating 2-way replay protection (which I also > > support) be specific about how they propose it be done? No disrespect > > meant, but BCH-style RP, that would require old wallets to upgrade, has > been > > proposed and emphatically NACKed here umpteen times: it is just > unrealistic > > to think this project would adopt it at this stage. There are other > 2-way > > RP approaches that I still believe are worth pursuing, but at this point > any > > discussion of 2-way RP as if it's a simple binary decision is a complete > > waste of everyone's time. > > > > > > On Sat, Oct 14, 2017 at 1:31 AM, Marcel Jamin via Bitcoin-segwit2x > > wrote: > >> > >> On 14 October 2017 at 02:20, Ben Peters via Bitcoin-segwit2x > >> wrote: > >> > I think there is a fundamental misunderstanding about the nature of > the > >> > NYA/Segwit2x endeavour. What is happening here is that an alternative, > >> > minimally modified, version of the Bitcoin code is being developed > that > >> > will > >> > implement a change that has long been sought by the mining community > and > >> > many in industry and beyond (a change that they presumably feel is > >> > important > >> > for the future success of Bitcoin and thus their respective > >> > investments). > >> > > >> > That candidate code will be offered to the miners and mining pools, > who > >> > may > >> > or may not opt to apply hashing power to it. If they apply more than > the > >> > threshold amount of hashing power, then that new code will effectively > >> > takeover from the previous consensus rule, and take most SPV wallets > and > >> > economic activity along with it. > >> > > >> > Rather than lobbying this technical working group to ?call off? their > >> > efforts, your time might be better spent lobbying the miners. The > >> > function > >> > of this group is to produce candidate code, thus fulfilling the > >> > obligations > >> > as set out under the NYA. > >> > >> Fair enough, but this working group is making technical decisions that > >> can create a lof of confusion and cause many problems for bitcoin > >> users. > >> > >> Much of the lobbying is targeted towards implementing strong two-way > >> replay protection. The reason for not implementing this protection, is > >> that it would reveal this project as an alternative fork of bitcoin > >> and is based on the assumption, that most miners will in fact employ > >> the client put forward by this WG and apply their hashpower to it. > >> > >> Many indicators however point towards a virtually guaranteed network > >> split. > >> > >> The NYA committed signers to "deployment of safe solutions that > >> increase bitcoin capacity". This implementation doesn't fulfill that > >> goal. Without strong replay protection, this will be a mess for both > >> sides. > >> > >> > > >> > > >> > On Oct 13, 2017, at 8:55 AM, Melvin Carvalho via Bitcoin-segwit2x > >> > wrote: > >> > > >> > > >> > > >> > On 13 October 2017 at 12:45, Melvin Carvalho > >> > wrote: > >> >> > >> >> > >> >> > >> >> On 13 October 2017 at 12:30, Phillip Katete > >> >> wrote: > >> >>> > >> >>> The disingenuity here is ?painful to watch?. First you make hay of > >> >>> f2pool > >> >>> switching off NYA signaling intent THEN you rubbish signaling intent > >> >>> as > >> >>> cheap and not worthy of consideration as a metric. More worryingly, > >> >>> you then > >> >>> want to predicate the HF on miner signaling at the 80% threshold. So > >> >>> which > >> >>> is it then? > >> >>> > >> >>> Even with the EDA induced hash oscillations, I am confident hash at > >> >>> and > >> >>> post fork will mirror signaling intent. > >> >> > >> >> > >> >> 24h signaling fell to 79.86% [1] > >> > > >> > > >> > NYA signaling is now down to 77.70% in the last 24h (down from over > 90% > >> > a > >> > day ago) > >> > > >> > https://coin.dance/blocks > >> > > >> > This does not take into account ViaBTC which may support either chain, > >> > but > >> > are currently signaling 100% NYA. > >> > > >> > However, much hash is mining bitcoin cash right now, and probably > >> > favourable > >> > to seg2x > >> > > >> > Additionally, you can monitor the futures market in realtime > >> > > >> > https://cryptowat.ch/bitfinex/bt2btc > >> > > >> > Currently trading at 10.6% of bitcoin (down from over 20% a day ago) > >> > > >> > You may wish to consider these metrics a source of new information for > >> > this > >> > project. And / or watch them as they develop. > >> > > >> >> > >> >> > >> >> [1] https://coin.dance/blocks#thisweek > >> >> > >> >>> > >> >>> > >> >>> From: Melvin Carvalho > >> >>> Sent: 13 October 2017 11:11 > >> >>> To: Phillip Katete > >> >>> Cc: Dr Adam Back; Emil Oldenburg; Peter Todd via Bitcoin-segwit2x > >> >>> > >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork > still > >> >>> happening? > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x > >> >>> wrote: > >> >>> > >> >>> You are barking up the wrong tree by using a ?rigged? futures? price > >> >>> to > >> >>> estimate the hash supporting the upgrade at fork time. They NYA was > >> >>> presented as being backed by at least 80% of the network hash then > and > >> >>> was > >> >>> activated / locked-in by over 90%. Since then, it has continued to > >> >>> receive > >> >>> and sustain intent signalling above the introduction threshold. It > is > >> >>> only > >> >>> rational to expect the hash on fork to reflect the latter as opposed > >> >>> to > >> >>> futures? prices. > >> >>> > >> >>> Obiter dicta: the futures? price is more reflective of the wavering > >> >>> non > >> >>> mining, none economic users. It goes without saying, a lot of > people > >> >>> are > >> >>> going to loose a lot of money on this otherwise rigged futures? > >> >>> market. > >> >>> > >> >>> > >> >>> Markets are not always accurate, but simply a form of price > discovery, > >> >>> I > >> >>> think "rigged" is perhaps a loaded term in this case and stretching > >> >>> things. > >> >>> A 12% futures market does not bode well for success, but, you never > >> >>> know. > >> >>> Since F2Pool stopped signaling NYA yesterday the signaling ratio is > >> >>> now > >> >>> about 81%, though this might have something to do with the feast and > >> >>> famine > >> >>> EDA in bitcoin cash which has just been activated. Around 83% might > >> >>> be a > >> >>> better guess. > >> >>> However signaling is cheap, and many miners act in economic self > >> >>> interest. Having helped run a coin for many years, I have witnessed > >> >>> this > >> >>> being the case. There's nothing developers would like more than > >> >>> steady > >> >>> miners that stick with a coin, but sites such as coinwarz [1] all > too > >> >>> often > >> >>> create spikes in hash power related to profitability. > >> >>> Wishing to stay on topic, I'd like to ask the following question. > If > >> >>> signaling falls below the described 80% threshold stated above (ie > one > >> >>> more > >> >>> miner stops signaling), will this this be grounds to rethink the > >> >>> timing of > >> >>> the release schedule? > >> >>> > >> >>> [1] https://www.coinwarz.com/cryptocurrency > >> >>> > >> >>> > >> >>> > >> >>> From:Dr Adam Back via Bitcoin-segwit2x > >> >>> Sent: 13 October 2017 10:11 > >> >>> To: Emil Oldenburg > >> >>> Cc: Peter Todd via Bitcoin-segwit2x > >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork > still > >> >>> happening? > >> >>> > >> >>> The futures price is 1/3 of 40% so yes actually < 40% hashrate is > >> >>> quite > >> >>> likely. > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> https://www.cryptonator.com/rates/BT2-BTC?utm_referrer= > https%3a%2f%2fwww.google.com%2f > >> >>> > >> >>> Nodes should upgrade because code changes are being made and it's > not > >> >>> a good idea to run pre-production code on the live network. Do you > >> >>> recall when the company you work for lost bitcoin by running > >> >>> pre-release fork code before on the pool? > >> >>> > >> >>> Is anyone running BTC1 head in production? Protecting how much > value. > >> >>> Reminder this is a public list. > >> >>> > >> >>> Adam > >> >>> > >> >>> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via > Bitcoin-segwit2x > >> >>> wrote: > >> >>> > The hardfork part is already locked in and is not subject to > change. > >> >>> > Many > >> >>> > btc1 nodes are already deployed and they should not and don't need > >> >>> > to > >> >>> > update. The only thing left is a potential extra softfork for > opt-in > >> >>> > replay > >> >>> > protection. Only the miners need this softfork. > >> >>> > > >> >>> > What makes you think the hardfork will have less than 40% > hashpower? > >> >>> > > >> >>> > > >> >>> > Emil Oldenburg, CTO > >> >>> > Emil at bitcoin.com > >> >>> > Visit the all new https://bitcoin.com > >> >>> > Wechat: emilold > >> >>> > Telegram: emilold > >> >>> > > >> >>> > On 2017 > >> >>> ?10?13?17:31, Peter BitcoinReminder.com wrote: > >> >>> > >> >>> > > >> >>> > Thats not a reason, the BTC1 sourcecode is still in development > >> >>> > (f.e. > >> >>> > replay > >> >>> > protection was reverted just 1-2 days ago?) - so the argument ?it > >> >>> > can?t > >> >>> > be > >> >>> > called off? is just wrong. > >> >>> > > >> >>> > So wouldn?t it make sense to add a minimum required hashrate for > the > >> >>> > HF > >> >>> > to > >> >>> > lock in? You are really going to fork off with f.e. 40 % > hashpower? > >> >>> > > >> >>> > > >> >>> > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x > >> >>> > : > >> >>> > > >> >>> > If we try to be technical here. The HF is already activated, is > >> >>> > estimated to > >> >>> > trigger in 36 days, and can't be "called off". Nor is there any > >> >>> > logic > >> >>> > to > >> >>> > delay it if hashrate deflects. That's the rules of the btc1 > client. > >> >>> > > >> >>> > > >> >>> > Emil Oldenburg, CTO > >> >>> > Emil at bitcoin.com > >> >>> > Visit the all new https://bitcoin.com > >> >>> > Wechat: emilold > >> >>> > Telegram: emilold > >> >>> > > >> >>> > On 2017 > >> >>> ?10?13?05:31, John Heathco via Bitcoin-segwit2x wrote: > >> >>> > >> >>> > > >> >>> > I don't believe there is an explicitly stated hashpower in which > the > >> >>> > fork > >> >>> > would be "called off", but I would assume it is much lower than > what > >> >>> > is > >> >>> > currently signaling, even if we make the (unwise) assumption that > >> >>> > F2Pool > >> >>> > would not contribute to mining 2x whatsoever. > >> >>> > > >> >>> > > >> >>> > > >> >>> > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via > >> >>> > Bitcoin-segwit2x > wrote: > >> >>> >> > >> >>> >> I?m not Peter Todd, we just share the same (nice) firstname. > >> >>> >> > >> >>> >> I still didn?t get an answer what the minimum amount of hashpower > >> >>> >> is > >> >>> >> required, before the fork is getting delayed? > >> >>> >> We have to plan time for the whole security measures etc, so I > >> >>> >> think > >> >>> >> it?s > >> >>> >> reasonable to get more information about this? > >> >>> >> > >> >>> >> > >> >>> >> Am 12.10.2017 um 21:53 schrieb bitPico : > >> >>> >> > >> >>> >> Without you knowing why they stopped signaling this is FUD and > >> >>> >> off-topic > >> >>> >> for this list. Please instead let F2Pool state their own opinion > >> >>> >> here > >> >>> >> since > >> >>> >> yours doesn?t count. If you think your opinion does count then > show > >> >>> >> us > >> >>> >> your > >> >>> >> blocks that your pool has produced; until then you are simply an > >> >>> >> end-user > >> >>> >> and still you are off-topic for this list. If you need ELI5 for > how > >> >>> >> this > >> >>> >> list works please let us know and we can help you Peter Todd. > >> >>> >> > >> >>> >> Have a groovy day! > >> >>> >> > >> >>> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via > >> >>> >> Bitcoin-segwit2x > >> >>> >> wrote: > >> >>> >> > >> >>> >> Since F2Pool stopped signaling for the NYA[1] and slush also > mines > >> >>> >> mostly > >> >>> >> non-NYA blocks, are you still going to fork off in November - > >> >>> >> splitting the > >> >>> >> chain intentionally? > >> >>> >> > >> >>> >> ? > >> >>> >> [1] https://imgur.com/LgYdFKw > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bitpay.com Sat Oct 14 06:58:34 2017 From: tony at bitpay.com (Tony Gallippi) Date: Sat, 14 Oct 2017 02:58:34 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: If users are that particular that they want their transaction *only* included in a 1MB container block, and *never* in any 2MB container block, that is their choice. But, even with just a 50% decrease in hashing power those users will start to pay very high fees for that 1MB preference and likely wait a very long time between blocks. The companies that signed the NYA represent probably 60%, maybe 80%, of all transactions on the bitcoin network today. Blockchain and Coinbase together have 30 million users. Those users are all the silent majority that don't comment on social media. They just want their transaction to work, without preference for container size, but with a preference for a lower fee and less congestion. These users have likely never run a full node and have no reason to. I expect at the moment of the fork, bitcoin core will still have a majority of nodes. But BTC1, bcoin, and many other implementations allowing a larger container block will have more than enough nodes to make a viable mesh network. We could use more implementations of bitcoin, and a defensive consensus amongst them. With that, bitcoin can evolve and will be impossible to stop. On Sat, Oct 14, 2017 at 2:38 AM, Jacob Eliosoff via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > My link included approaches that at least make it easy for users to send > 1x-only txs - approaches that could conceivably get deployed by 2x, and > thus protect 1x users. Just repeatedly banging your head against the wall > with a proposal everyone can see has 0 chance at deployment (want to bet?) > doesn't protect users at all. It accomplishes exactly as much for your > cause as sending 100 mails to this list saying "DON'T HF!" > > Anyway that's my 2c. If you want to discuss further let's talk offline or > on Twitter - somewhere other than a list for plausible technical proposals. > > > On Sat, Oct 14, 2017 at 2:24 AM, Marcel Jamin wrote: > >> I wouldn't consider any opt-in approach as "strong" replay protection. >> If this WG as NACKed strong two way replay protection, then it's not a >> safe upgrade path und thus not an implementation honoring the NYA. >> >> On 14 October 2017 at 07:53, Jacob Eliosoff >> wrote: >> > Can I ask that anyone advocating 2-way replay protection (which I also >> > support) be specific about how they propose it be done? No disrespect >> > meant, but BCH-style RP, that would require old wallets to upgrade, has >> been >> > proposed and emphatically NACKed here umpteen times: it is just >> unrealistic >> > to think this project would adopt it at this stage. There are other >> 2-way >> > RP approaches that I still believe are worth pursuing, but at this >> point any >> > discussion of 2-way RP as if it's a simple binary decision is a complete >> > waste of everyone's time. >> > >> > >> > On Sat, Oct 14, 2017 at 1:31 AM, Marcel Jamin via Bitcoin-segwit2x >> > wrote: >> >> >> >> On 14 October 2017 at 02:20, Ben Peters via Bitcoin-segwit2x >> >> wrote: >> >> > I think there is a fundamental misunderstanding about the nature of >> the >> >> > NYA/Segwit2x endeavour. What is happening here is that an >> alternative, >> >> > minimally modified, version of the Bitcoin code is being developed >> that >> >> > will >> >> > implement a change that has long been sought by the mining community >> and >> >> > many in industry and beyond (a change that they presumably feel is >> >> > important >> >> > for the future success of Bitcoin and thus their respective >> >> > investments). >> >> > >> >> > That candidate code will be offered to the miners and mining pools, >> who >> >> > may >> >> > or may not opt to apply hashing power to it. If they apply more than >> the >> >> > threshold amount of hashing power, then that new code will >> effectively >> >> > takeover from the previous consensus rule, and take most SPV wallets >> and >> >> > economic activity along with it. >> >> > >> >> > Rather than lobbying this technical working group to ?call off? their >> >> > efforts, your time might be better spent lobbying the miners. The >> >> > function >> >> > of this group is to produce candidate code, thus fulfilling the >> >> > obligations >> >> > as set out under the NYA. >> >> >> >> Fair enough, but this working group is making technical decisions that >> >> can create a lof of confusion and cause many problems for bitcoin >> >> users. >> >> >> >> Much of the lobbying is targeted towards implementing strong two-way >> >> replay protection. The reason for not implementing this protection, is >> >> that it would reveal this project as an alternative fork of bitcoin >> >> and is based on the assumption, that most miners will in fact employ >> >> the client put forward by this WG and apply their hashpower to it. >> >> >> >> Many indicators however point towards a virtually guaranteed network >> >> split. >> >> >> >> The NYA committed signers to "deployment of safe solutions that >> >> increase bitcoin capacity". This implementation doesn't fulfill that >> >> goal. Without strong replay protection, this will be a mess for both >> >> sides. >> >> >> >> > >> >> > >> >> > On Oct 13, 2017, at 8:55 AM, Melvin Carvalho via Bitcoin-segwit2x >> >> > wrote: >> >> > >> >> > >> >> > >> >> > On 13 October 2017 at 12:45, Melvin Carvalho >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> On 13 October 2017 at 12:30, Phillip Katete >> >> >> wrote: >> >> >>> >> >> >>> The disingenuity here is ?painful to watch?. First you make hay of >> >> >>> f2pool >> >> >>> switching off NYA signaling intent THEN you rubbish signaling >> intent >> >> >>> as >> >> >>> cheap and not worthy of consideration as a metric. More worryingly, >> >> >>> you then >> >> >>> want to predicate the HF on miner signaling at the 80% threshold. >> So >> >> >>> which >> >> >>> is it then? >> >> >>> >> >> >>> Even with the EDA induced hash oscillations, I am confident hash at >> >> >>> and >> >> >>> post fork will mirror signaling intent. >> >> >> >> >> >> >> >> >> 24h signaling fell to 79.86% [1] >> >> > >> >> > >> >> > NYA signaling is now down to 77.70% in the last 24h (down from over >> 90% >> >> > a >> >> > day ago) >> >> > >> >> > https://coin.dance/blocks >> >> > >> >> > This does not take into account ViaBTC which may support either >> chain, >> >> > but >> >> > are currently signaling 100% NYA. >> >> > >> >> > However, much hash is mining bitcoin cash right now, and probably >> >> > favourable >> >> > to seg2x >> >> > >> >> > Additionally, you can monitor the futures market in realtime >> >> > >> >> > https://cryptowat.ch/bitfinex/bt2btc >> >> > >> >> > Currently trading at 10.6% of bitcoin (down from over 20% a day ago) >> >> > >> >> > You may wish to consider these metrics a source of new information >> for >> >> > this >> >> > project. And / or watch them as they develop. >> >> > >> >> >> >> >> >> >> >> >> [1] https://coin.dance/blocks#thisweek >> >> >> >> >> >>> >> >> >>> >> >> >>> From: Melvin Carvalho >> >> >>> Sent: 13 October 2017 11:11 >> >> >>> To: Phillip Katete >> >> >>> Cc: Dr Adam Back; Emil Oldenburg; Peter Todd via Bitcoin-segwit2x >> >> >>> >> >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork >> still >> >> >>> happening? >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x >> >> >>> wrote: >> >> >>> >> >> >>> You are barking up the wrong tree by using a ?rigged? futures? >> price >> >> >>> to >> >> >>> estimate the hash supporting the upgrade at fork time. They NYA was >> >> >>> presented as being backed by at least 80% of the network hash then >> and >> >> >>> was >> >> >>> activated / locked-in by over 90%. Since then, it has continued to >> >> >>> receive >> >> >>> and sustain intent signalling above the introduction threshold. It >> is >> >> >>> only >> >> >>> rational to expect the hash on fork to reflect the latter as >> opposed >> >> >>> to >> >> >>> futures? prices. >> >> >>> >> >> >>> Obiter dicta: the futures? price is more reflective of the wavering >> >> >>> non >> >> >>> mining, none economic users. It goes without saying, a lot of >> people >> >> >>> are >> >> >>> going to loose a lot of money on this otherwise rigged futures? >> >> >>> market. >> >> >>> >> >> >>> >> >> >>> Markets are not always accurate, but simply a form of price >> discovery, >> >> >>> I >> >> >>> think "rigged" is perhaps a loaded term in this case and stretching >> >> >>> things. >> >> >>> A 12% futures market does not bode well for success, but, you never >> >> >>> know. >> >> >>> Since F2Pool stopped signaling NYA yesterday the signaling ratio is >> >> >>> now >> >> >>> about 81%, though this might have something to do with the feast >> and >> >> >>> famine >> >> >>> EDA in bitcoin cash which has just been activated. Around 83% >> might >> >> >>> be a >> >> >>> better guess. >> >> >>> However signaling is cheap, and many miners act in economic self >> >> >>> interest. Having helped run a coin for many years, I have >> witnessed >> >> >>> this >> >> >>> being the case. There's nothing developers would like more than >> >> >>> steady >> >> >>> miners that stick with a coin, but sites such as coinwarz [1] all >> too >> >> >>> often >> >> >>> create spikes in hash power related to profitability. >> >> >>> Wishing to stay on topic, I'd like to ask the following question. >> If >> >> >>> signaling falls below the described 80% threshold stated above (ie >> one >> >> >>> more >> >> >>> miner stops signaling), will this this be grounds to rethink the >> >> >>> timing of >> >> >>> the release schedule? >> >> >>> >> >> >>> [1] https://www.coinwarz.com/cryptocurrency >> >> >>> >> >> >>> >> >> >>> >> >> >>> From:Dr Adam Back via Bitcoin-segwit2x >> >> >>> Sent: 13 October 2017 10:11 >> >> >>> To: Emil Oldenburg >> >> >>> Cc: Peter Todd via Bitcoin-segwit2x >> >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork >> still >> >> >>> happening? >> >> >>> >> >> >>> The futures price is 1/3 of 40% so yes actually < 40% hashrate is >> >> >>> quite >> >> >>> likely. >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https >> %3a%2f%2fwww.google.com%2f >> >> >>> >> >> >>> Nodes should upgrade because code changes are being made and it's >> not >> >> >>> a good idea to run pre-production code on the live network. Do you >> >> >>> recall when the company you work for lost bitcoin by running >> >> >>> pre-release fork code before on the pool? >> >> >>> >> >> >>> Is anyone running BTC1 head in production? Protecting how much >> value. >> >> >>> Reminder this is a public list. >> >> >>> >> >> >>> Adam >> >> >>> >> >> >>> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via >> Bitcoin-segwit2x >> >> >>> wrote: >> >> >>> > The hardfork part is already locked in and is not subject to >> change. >> >> >>> > Many >> >> >>> > btc1 nodes are already deployed and they should not and don't >> need >> >> >>> > to >> >> >>> > update. The only thing left is a potential extra softfork for >> opt-in >> >> >>> > replay >> >> >>> > protection. Only the miners need this softfork. >> >> >>> > >> >> >>> > What makes you think the hardfork will have less than 40% >> hashpower? >> >> >>> > >> >> >>> > >> >> >>> > Emil Oldenburg, CTO >> >> >>> > Emil at bitcoin.com >> >> >>> > Visit the all new https://bitcoin.com >> >> >>> > Wechat: emilold >> >> >>> > Telegram: emilold >> >> >>> > >> >> >>> > On 2017 >> >> >>> ?10?13?17:31, Peter BitcoinReminder.com wrote: >> >> >>> >> >> >>> > >> >> >>> > Thats not a reason, the BTC1 sourcecode is still in development >> >> >>> > (f.e. >> >> >>> > replay >> >> >>> > protection was reverted just 1-2 days ago?) - so the argument ?it >> >> >>> > can?t >> >> >>> > be >> >> >>> > called off? is just wrong. >> >> >>> > >> >> >>> > So wouldn?t it make sense to add a minimum required hashrate for >> the >> >> >>> > HF >> >> >>> > to >> >> >>> > lock in? You are really going to fork off with f.e. 40 % >> hashpower? >> >> >>> > >> >> >>> > >> >> >>> > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via >> Bitcoin-segwit2x >> >> >>> > : >> >> >>> > >> >> >>> > If we try to be technical here. The HF is already activated, is >> >> >>> > estimated to >> >> >>> > trigger in 36 days, and can't be "called off". Nor is there any >> >> >>> > logic >> >> >>> > to >> >> >>> > delay it if hashrate deflects. That's the rules of the btc1 >> client. >> >> >>> > >> >> >>> > >> >> >>> > Emil Oldenburg, CTO >> >> >>> > Emil at bitcoin.com >> >> >>> > Visit the all new https://bitcoin.com >> >> >>> > Wechat: emilold >> >> >>> > Telegram: emilold >> >> >>> > >> >> >>> > On 2017 >> >> >>> ?10?13?05:31, John Heathco via Bitcoin-segwit2x wrote: >> >> >>> >> >> >>> > >> >> >>> > I don't believe there is an explicitly stated hashpower in which >> the >> >> >>> > fork >> >> >>> > would be "called off", but I would assume it is much lower than >> what >> >> >>> > is >> >> >>> > currently signaling, even if we make the (unwise) assumption that >> >> >>> > F2Pool >> >> >>> > would not contribute to mining 2x whatsoever. >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via >> >> >>> > Bitcoin-segwit2x >> wrote: >> >> >>> >> >> >> >>> >> I?m not Peter Todd, we just share the same (nice) firstname. >> >> >>> >> >> >> >>> >> I still didn?t get an answer what the minimum amount of >> hashpower >> >> >>> >> is >> >> >>> >> required, before the fork is getting delayed? >> >> >>> >> We have to plan time for the whole security measures etc, so I >> >> >>> >> think >> >> >>> >> it?s >> >> >>> >> reasonable to get more information about this? >> >> >>> >> >> >> >>> >> >> >> >>> >> Am 12.10.2017 um 21:53 schrieb bitPico : >> >> >>> >> >> >> >>> >> Without you knowing why they stopped signaling this is FUD and >> >> >>> >> off-topic >> >> >>> >> for this list. Please instead let F2Pool state their own >> opinion >> >> >>> >> here >> >> >>> >> since >> >> >>> >> yours doesn?t count. If you think your opinion does count then >> show >> >> >>> >> us >> >> >>> >> your >> >> >>> >> blocks that your pool has produced; until then you are simply an >> >> >>> >> end-user >> >> >>> >> and still you are off-topic for this list. If you need ELI5 for >> how >> >> >>> >> this >> >> >>> >> list works please let us know and we can help you Peter Todd. >> >> >>> >> >> >> >>> >> Have a groovy day! >> >> >>> >> >> >> >>> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via >> >> >>> >> Bitcoin-segwit2x >> >> >>> >> wrote: >> >> >>> >> >> >> >>> >> Since F2Pool stopped signaling for the NYA[1] and slush also >> mines >> >> >>> >> mostly >> >> >>> >> non-NYA blocks, are you still going to fork off in November - >> >> >>> >> splitting the >> >> >>> >> chain intentionally? >> >> >>> >> >> >> >>> >> ? >> >> >>> >> [1] https://imgur.com/LgYdFKw >> > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- *Tony Gallippi* Co-founder and Executive Chairman BitPay, Inc. https://bitpay.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at bloq.com Sat Oct 14 07:02:06 2017 From: jeff at bloq.com (Jeff Garzik) Date: Sat, 14 Oct 2017 00:02:06 -0700 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: "Strong, two-way replay protection" is poorly defined. Segwit2x is an upgrade to bitcoin, not an altcoin. It is an explicit design goal that SPV wallets continue working through the fork, following the strongest, most secure chain as they were programmed to do. Therefore, any method of replay protection that breaks over 10 million wallets - greatly exacerbating chain splits - is rejected (and this has been communicated repeatedly for months). Put simply, we want most wallets to Just Keep Working. Certain types of replay protection break that. On Oct 14, 2017 2:24 AM, "Marcel Jamin via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > I wouldn't consider any opt-in approach as "strong" replay protection. > If this WG as NACKed strong two way replay protection, then it's not a > safe upgrade path und thus not an implementation honoring the NYA. > > On 14 October 2017 at 07:53, Jacob Eliosoff > wrote: > > Can I ask that anyone advocating 2-way replay protection (which I also > > support) be specific about how they propose it be done? No disrespect > > meant, but BCH-style RP, that would require old wallets to upgrade, has > been > > proposed and emphatically NACKed here umpteen times: it is just > unrealistic > > to think this project would adopt it at this stage. There are other > 2-way > > RP approaches that I still believe are worth pursuing, but at this point > any > > discussion of 2-way RP as if it's a simple binary decision is a complete > > waste of everyone's time. > > > > > > On Sat, Oct 14, 2017 at 1:31 AM, Marcel Jamin via Bitcoin-segwit2x > > wrote: > >> > >> On 14 October 2017 at 02:20, Ben Peters via Bitcoin-segwit2x > >> wrote: > >> > I think there is a fundamental misunderstanding about the nature of > the > >> > NYA/Segwit2x endeavour. What is happening here is that an alternative, > >> > minimally modified, version of the Bitcoin code is being developed > that > >> > will > >> > implement a change that has long been sought by the mining community > and > >> > many in industry and beyond (a change that they presumably feel is > >> > important > >> > for the future success of Bitcoin and thus their respective > >> > investments). > >> > > >> > That candidate code will be offered to the miners and mining pools, > who > >> > may > >> > or may not opt to apply hashing power to it. If they apply more than > the > >> > threshold amount of hashing power, then that new code will effectively > >> > takeover from the previous consensus rule, and take most SPV wallets > and > >> > economic activity along with it. > >> > > >> > Rather than lobbying this technical working group to ?call off? their > >> > efforts, your time might be better spent lobbying the miners. The > >> > function > >> > of this group is to produce candidate code, thus fulfilling the > >> > obligations > >> > as set out under the NYA. > >> > >> Fair enough, but this working group is making technical decisions that > >> can create a lof of confusion and cause many problems for bitcoin > >> users. > >> > >> Much of the lobbying is targeted towards implementing strong two-way > >> replay protection. The reason for not implementing this protection, is > >> that it would reveal this project as an alternative fork of bitcoin > >> and is based on the assumption, that most miners will in fact employ > >> the client put forward by this WG and apply their hashpower to it. > >> > >> Many indicators however point towards a virtually guaranteed network > >> split. > >> > >> The NYA committed signers to "deployment of safe solutions that > >> increase bitcoin capacity". This implementation doesn't fulfill that > >> goal. Without strong replay protection, this will be a mess for both > >> sides. > >> > >> > > >> > > >> > On Oct 13, 2017, at 8:55 AM, Melvin Carvalho via Bitcoin-segwit2x > >> > wrote: > >> > > >> > > >> > > >> > On 13 October 2017 at 12:45, Melvin Carvalho > >> > wrote: > >> >> > >> >> > >> >> > >> >> On 13 October 2017 at 12:30, Phillip Katete > >> >> wrote: > >> >>> > >> >>> The disingenuity here is ?painful to watch?. First you make hay of > >> >>> f2pool > >> >>> switching off NYA signaling intent THEN you rubbish signaling intent > >> >>> as > >> >>> cheap and not worthy of consideration as a metric. More worryingly, > >> >>> you then > >> >>> want to predicate the HF on miner signaling at the 80% threshold. So > >> >>> which > >> >>> is it then? > >> >>> > >> >>> Even with the EDA induced hash oscillations, I am confident hash at > >> >>> and > >> >>> post fork will mirror signaling intent. > >> >> > >> >> > >> >> 24h signaling fell to 79.86% [1] > >> > > >> > > >> > NYA signaling is now down to 77.70% in the last 24h (down from over > 90% > >> > a > >> > day ago) > >> > > >> > https://coin.dance/blocks > >> > > >> > This does not take into account ViaBTC which may support either chain, > >> > but > >> > are currently signaling 100% NYA. > >> > > >> > However, much hash is mining bitcoin cash right now, and probably > >> > favourable > >> > to seg2x > >> > > >> > Additionally, you can monitor the futures market in realtime > >> > > >> > https://cryptowat.ch/bitfinex/bt2btc > >> > > >> > Currently trading at 10.6% of bitcoin (down from over 20% a day ago) > >> > > >> > You may wish to consider these metrics a source of new information for > >> > this > >> > project. And / or watch them as they develop. > >> > > >> >> > >> >> > >> >> [1] https://coin.dance/blocks#thisweek > >> >> > >> >>> > >> >>> > >> >>> From: Melvin Carvalho > >> >>> Sent: 13 October 2017 11:11 > >> >>> To: Phillip Katete > >> >>> Cc: Dr Adam Back; Emil Oldenburg; Peter Todd via Bitcoin-segwit2x > >> >>> > >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork > still > >> >>> happening? > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x > >> >>> wrote: > >> >>> > >> >>> You are barking up the wrong tree by using a ?rigged? futures? price > >> >>> to > >> >>> estimate the hash supporting the upgrade at fork time. They NYA was > >> >>> presented as being backed by at least 80% of the network hash then > and > >> >>> was > >> >>> activated / locked-in by over 90%. Since then, it has continued to > >> >>> receive > >> >>> and sustain intent signalling above the introduction threshold. It > is > >> >>> only > >> >>> rational to expect the hash on fork to reflect the latter as opposed > >> >>> to > >> >>> futures? prices. > >> >>> > >> >>> Obiter dicta: the futures? price is more reflective of the wavering > >> >>> non > >> >>> mining, none economic users. It goes without saying, a lot of > people > >> >>> are > >> >>> going to loose a lot of money on this otherwise rigged futures? > >> >>> market. > >> >>> > >> >>> > >> >>> Markets are not always accurate, but simply a form of price > discovery, > >> >>> I > >> >>> think "rigged" is perhaps a loaded term in this case and stretching > >> >>> things. > >> >>> A 12% futures market does not bode well for success, but, you never > >> >>> know. > >> >>> Since F2Pool stopped signaling NYA yesterday the signaling ratio is > >> >>> now > >> >>> about 81%, though this might have something to do with the feast and > >> >>> famine > >> >>> EDA in bitcoin cash which has just been activated. Around 83% might > >> >>> be a > >> >>> better guess. > >> >>> However signaling is cheap, and many miners act in economic self > >> >>> interest. Having helped run a coin for many years, I have witnessed > >> >>> this > >> >>> being the case. There's nothing developers would like more than > >> >>> steady > >> >>> miners that stick with a coin, but sites such as coinwarz [1] all > too > >> >>> often > >> >>> create spikes in hash power related to profitability. > >> >>> Wishing to stay on topic, I'd like to ask the following question. > If > >> >>> signaling falls below the described 80% threshold stated above (ie > one > >> >>> more > >> >>> miner stops signaling), will this this be grounds to rethink the > >> >>> timing of > >> >>> the release schedule? > >> >>> > >> >>> [1] https://www.coinwarz.com/cryptocurrency > >> >>> > >> >>> > >> >>> > >> >>> From:Dr Adam Back via Bitcoin-segwit2x > >> >>> Sent: 13 October 2017 10:11 > >> >>> To: Emil Oldenburg > >> >>> Cc: Peter Todd via Bitcoin-segwit2x > >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork > still > >> >>> happening? > >> >>> > >> >>> The futures price is 1/3 of 40% so yes actually < 40% hashrate is > >> >>> quite > >> >>> likely. > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> https://www.cryptonator.com/rates/BT2-BTC?utm_referrer= > https%3a%2f%2fwww.google.com%2f > >> >>> > >> >>> Nodes should upgrade because code changes are being made and it's > not > >> >>> a good idea to run pre-production code on the live network. Do you > >> >>> recall when the company you work for lost bitcoin by running > >> >>> pre-release fork code before on the pool? > >> >>> > >> >>> Is anyone running BTC1 head in production? Protecting how much > value. > >> >>> Reminder this is a public list. > >> >>> > >> >>> Adam > >> >>> > >> >>> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via > Bitcoin-segwit2x > >> >>> wrote: > >> >>> > The hardfork part is already locked in and is not subject to > change. > >> >>> > Many > >> >>> > btc1 nodes are already deployed and they should not and don't need > >> >>> > to > >> >>> > update. The only thing left is a potential extra softfork for > opt-in > >> >>> > replay > >> >>> > protection. Only the miners need this softfork. > >> >>> > > >> >>> > What makes you think the hardfork will have less than 40% > hashpower? > >> >>> > > >> >>> > > >> >>> > Emil Oldenburg, CTO > >> >>> > Emil at bitcoin.com > >> >>> > Visit the all new https://bitcoin.com > >> >>> > Wechat: emilold > >> >>> > Telegram: emilold > >> >>> > > >> >>> > On 2017 > >> >>> ?10?13?17:31, Peter BitcoinReminder.com wrote: > >> >>> > >> >>> > > >> >>> > Thats not a reason, the BTC1 sourcecode is still in development > >> >>> > (f.e. > >> >>> > replay > >> >>> > protection was reverted just 1-2 days ago?) - so the argument ?it > >> >>> > can?t > >> >>> > be > >> >>> > called off? is just wrong. > >> >>> > > >> >>> > So wouldn?t it make sense to add a minimum required hashrate for > the > >> >>> > HF > >> >>> > to > >> >>> > lock in? You are really going to fork off with f.e. 40 % > hashpower? > >> >>> > > >> >>> > > >> >>> > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x > >> >>> > : > >> >>> > > >> >>> > If we try to be technical here. The HF is already activated, is > >> >>> > estimated to > >> >>> > trigger in 36 days, and can't be "called off". Nor is there any > >> >>> > logic > >> >>> > to > >> >>> > delay it if hashrate deflects. That's the rules of the btc1 > client. > >> >>> > > >> >>> > > >> >>> > Emil Oldenburg, CTO > >> >>> > Emil at bitcoin.com > >> >>> > Visit the all new https://bitcoin.com > >> >>> > Wechat: emilold > >> >>> > Telegram: emilold > >> >>> > > >> >>> > On 2017 > >> >>> ?10?13?05:31, John Heathco via Bitcoin-segwit2x wrote: > >> >>> > >> >>> > > >> >>> > I don't believe there is an explicitly stated hashpower in which > the > >> >>> > fork > >> >>> > would be "called off", but I would assume it is much lower than > what > >> >>> > is > >> >>> > currently signaling, even if we make the (unwise) assumption that > >> >>> > F2Pool > >> >>> > would not contribute to mining 2x whatsoever. > >> >>> > > >> >>> > > >> >>> > > >> >>> > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via > >> >>> > Bitcoin-segwit2x > wrote: > >> >>> >> > >> >>> >> I?m not Peter Todd, we just share the same (nice) firstname. > >> >>> >> > >> >>> >> I still didn?t get an answer what the minimum amount of hashpower > >> >>> >> is > >> >>> >> required, before the fork is getting delayed? > >> >>> >> We have to plan time for the whole security measures etc, so I > >> >>> >> think > >> >>> >> it?s > >> >>> >> reasonable to get more information about this? > >> >>> >> > >> >>> >> > >> >>> >> Am 12.10.2017 um 21:53 schrieb bitPico : > >> >>> >> > >> >>> >> Without you knowing why they stopped signaling this is FUD and > >> >>> >> off-topic > >> >>> >> for this list. Please instead let F2Pool state their own opinion > >> >>> >> here > >> >>> >> since > >> >>> >> yours doesn?t count. If you think your opinion does count then > show > >> >>> >> us > >> >>> >> your > >> >>> >> blocks that your pool has produced; until then you are simply an > >> >>> >> end-user > >> >>> >> and still you are off-topic for this list. If you need ELI5 for > how > >> >>> >> this > >> >>> >> list works please let us know and we can help you Peter Todd. > >> >>> >> > >> >>> >> Have a groovy day! > >> >>> >> > >> >>> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via > >> >>> >> Bitcoin-segwit2x > >> >>> >> wrote: > >> >>> >> > >> >>> >> Since F2Pool stopped signaling for the NYA[1] and slush also > mines > >> >>> >> mostly > >> >>> >> non-NYA blocks, are you still going to fork off in November - > >> >>> >> splitting the > >> >>> >> chain intentionally? > >> >>> >> > >> >>> >> ? > >> >>> >> [1] https://imgur.com/LgYdFKw > >> >>> >> > >> >>> >> _______________________________________________ > >> >>> >> Bitcoin-segwit2x mailing list > >> >>> >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin- > segwit2x > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> _______________________________________________ > >> >>> >> Bitcoin-segwit2x mailing list > >> >>> >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin- > segwit2x > >> >>> > > >> >>> > > >> >>> > > >> >>> > _______________________________________________ > >> >>> > Bitcoin-segwit2x mailing list > >> >>> > Bitcoin-segwit2x at lists.linuxfoundation.org > >> >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin- > segwit2x > >> >>> > > >> >>> > > >> >>> > _______________________________________________ > >> >>> > Bitcoin-segwit2x mailing list > >> >>> > Bitcoin-segwit2x at lists.linuxfoundation.org > >> >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin- > segwit2x > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > _______________________________________________ > >> >>> > Bitcoin-segwit2x mailing list > >> >>> > Bitcoin-segwit2x at lists.linuxfoundation.org > >> >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin- > segwit2x > >> >>> > > >> >>> _______________________________________________ > >> >>> Bitcoin-segwit2x mailing list > >> >>> Bitcoin-segwit2x at lists.linuxfoundation.org > >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> Bitcoin-segwit2x mailing list > >> >>> Bitcoin-segwit2x at lists.linuxfoundation.org > >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> >>> > >> >>> > >> >>> > >> >> > >> >> > >> > > >> > _______________________________________________ > >> > Bitcoin-segwit2x mailing list > >> > Bitcoin-segwit2x at lists.linuxfoundation.org > >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > > >> > > >> > _______________________________________________ > >> > Bitcoin-segwit2x mailing list > >> > Bitcoin-segwit2x at lists.linuxfoundation.org > >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel at jamin.net Sat Oct 14 07:38:50 2017 From: marcel at jamin.net (Marcel Jamin) Date: Sat, 14 Oct 2017 09:38:50 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: On 14 October 2017 at 09:02, Jeff Garzik wrote: > "Strong, two-way replay protection" is poorly defined. > > Segwit2x is an upgrade to bitcoin, not an altcoin. I and many others heavily disagree. The simple reality is this: S2X is incompatible with Bitcoin AND contentious. Miners and business adopting this approach to "upgrading" will fork themselves off the bitcoin blockchain. You're trying to define Bitcoin's rules by strong-arming changes through hashpower. It doesn't bode well for bitcoin's future if this is actually successful. > It is an explicit design goal that SPV wallets continue working through the > fork, following the strongest, most secure chain as they were programmed to > do. ... tricking them to follow an invalid chain, as SPV can't fully validate bitcoin's rules. Validity is not solely defined by hashpower. > Therefore, any method of replay protection that breaks over 10 million > wallets - greatly exacerbating chain splits - is rejected (and this has been > communicated repeatedly for months). It doesn't break wallets at all, it merely fails to automatically (and unsolicitedly) onboard them onto this WG's fork of bitcoin (= incompatible consensus rules, new set of developers, new maintainer). > Put simply, we want most wallets to Just Keep Working. Certain types of > replay protection break that. Put simply, you want to take most wallets with you without explicit consent and certain types of replay protection don't allow you to do that. You're only offering an opt-out approach requiring user action + bloat on the incumbent chain. There are ways to increase bitcoin's capacity without causing a schism like this. After all, we did just double it. Work with (virtually all) bitcoin protocol developers, not against them. This merely means holding off on a hard fork for a while longer, acknowledging that a safe hard fork that doesn't split the community is a hard thing to do. As it should be. And before anyone is going to lecture me again that this is off-topic for this list (as a blanket defense when things get uncomfortable), rest assured that this will be my last mail to this list. One way or another, this will sort itself out. > On Oct 14, 2017 2:24 AM, "Marcel Jamin via Bitcoin-segwit2x" > wrote: >> >> I wouldn't consider any opt-in approach as "strong" replay protection. >> If this WG as NACKed strong two way replay protection, then it's not a >> safe upgrade path und thus not an implementation honoring the NYA. >> >> On 14 October 2017 at 07:53, Jacob Eliosoff >> wrote: >> > Can I ask that anyone advocating 2-way replay protection (which I also >> > support) be specific about how they propose it be done? No disrespect >> > meant, but BCH-style RP, that would require old wallets to upgrade, has >> > been >> > proposed and emphatically NACKed here umpteen times: it is just >> > unrealistic >> > to think this project would adopt it at this stage. There are other >> > 2-way >> > RP approaches that I still believe are worth pursuing, but at this point >> > any >> > discussion of 2-way RP as if it's a simple binary decision is a complete >> > waste of everyone's time. >> > >> > >> > On Sat, Oct 14, 2017 at 1:31 AM, Marcel Jamin via Bitcoin-segwit2x >> > wrote: >> >> >> >> On 14 October 2017 at 02:20, Ben Peters via Bitcoin-segwit2x >> >> wrote: >> >> > I think there is a fundamental misunderstanding about the nature of >> >> > the >> >> > NYA/Segwit2x endeavour. What is happening here is that an >> >> > alternative, >> >> > minimally modified, version of the Bitcoin code is being developed >> >> > that >> >> > will >> >> > implement a change that has long been sought by the mining community >> >> > and >> >> > many in industry and beyond (a change that they presumably feel is >> >> > important >> >> > for the future success of Bitcoin and thus their respective >> >> > investments). >> >> > >> >> > That candidate code will be offered to the miners and mining pools, >> >> > who >> >> > may >> >> > or may not opt to apply hashing power to it. If they apply more than >> >> > the >> >> > threshold amount of hashing power, then that new code will >> >> > effectively >> >> > takeover from the previous consensus rule, and take most SPV wallets >> >> > and >> >> > economic activity along with it. >> >> > >> >> > Rather than lobbying this technical working group to ?call off? their >> >> > efforts, your time might be better spent lobbying the miners. The >> >> > function >> >> > of this group is to produce candidate code, thus fulfilling the >> >> > obligations >> >> > as set out under the NYA. >> >> >> >> Fair enough, but this working group is making technical decisions that >> >> can create a lof of confusion and cause many problems for bitcoin >> >> users. >> >> >> >> Much of the lobbying is targeted towards implementing strong two-way >> >> replay protection. The reason for not implementing this protection, is >> >> that it would reveal this project as an alternative fork of bitcoin >> >> and is based on the assumption, that most miners will in fact employ >> >> the client put forward by this WG and apply their hashpower to it. >> >> >> >> Many indicators however point towards a virtually guaranteed network >> >> split. >> >> >> >> The NYA committed signers to "deployment of safe solutions that >> >> increase bitcoin capacity". This implementation doesn't fulfill that >> >> goal. Without strong replay protection, this will be a mess for both >> >> sides. >> >> >> >> > >> >> > >> >> > On Oct 13, 2017, at 8:55 AM, Melvin Carvalho via Bitcoin-segwit2x >> >> > wrote: >> >> > >> >> > >> >> > >> >> > On 13 October 2017 at 12:45, Melvin Carvalho >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> On 13 October 2017 at 12:30, Phillip Katete >> >> >> wrote: >> >> >>> >> >> >>> The disingenuity here is ?painful to watch?. First you make hay of >> >> >>> f2pool >> >> >>> switching off NYA signaling intent THEN you rubbish signaling >> >> >>> intent >> >> >>> as >> >> >>> cheap and not worthy of consideration as a metric. More worryingly, >> >> >>> you then >> >> >>> want to predicate the HF on miner signaling at the 80% threshold. >> >> >>> So >> >> >>> which >> >> >>> is it then? >> >> >>> >> >> >>> Even with the EDA induced hash oscillations, I am confident hash at >> >> >>> and >> >> >>> post fork will mirror signaling intent. >> >> >> >> >> >> >> >> >> 24h signaling fell to 79.86% [1] >> >> > >> >> > >> >> > NYA signaling is now down to 77.70% in the last 24h (down from over >> >> > 90% >> >> > a >> >> > day ago) >> >> > >> >> > https://coin.dance/blocks >> >> > >> >> > This does not take into account ViaBTC which may support either >> >> > chain, >> >> > but >> >> > are currently signaling 100% NYA. >> >> > >> >> > However, much hash is mining bitcoin cash right now, and probably >> >> > favourable >> >> > to seg2x >> >> > >> >> > Additionally, you can monitor the futures market in realtime >> >> > >> >> > https://cryptowat.ch/bitfinex/bt2btc >> >> > >> >> > Currently trading at 10.6% of bitcoin (down from over 20% a day ago) >> >> > >> >> > You may wish to consider these metrics a source of new information >> >> > for >> >> > this >> >> > project. And / or watch them as they develop. >> >> > >> >> >> >> >> >> >> >> >> [1] https://coin.dance/blocks#thisweek >> >> >> >> >> >>> >> >> >>> >> >> >>> From: Melvin Carvalho >> >> >>> Sent: 13 October 2017 11:11 >> >> >>> To: Phillip Katete >> >> >>> Cc: Dr Adam Back; Emil Oldenburg; Peter Todd via Bitcoin-segwit2x >> >> >>> >> >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork >> >> >>> still >> >> >>> happening? >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x >> >> >>> wrote: >> >> >>> >> >> >>> You are barking up the wrong tree by using a ?rigged? futures? >> >> >>> price >> >> >>> to >> >> >>> estimate the hash supporting the upgrade at fork time. They NYA was >> >> >>> presented as being backed by at least 80% of the network hash then >> >> >>> and >> >> >>> was >> >> >>> activated / locked-in by over 90%. Since then, it has continued to >> >> >>> receive >> >> >>> and sustain intent signalling above the introduction threshold. It >> >> >>> is >> >> >>> only >> >> >>> rational to expect the hash on fork to reflect the latter as >> >> >>> opposed >> >> >>> to >> >> >>> futures? prices. >> >> >>> >> >> >>> Obiter dicta: the futures? price is more reflective of the wavering >> >> >>> non >> >> >>> mining, none economic users. It goes without saying, a lot of >> >> >>> people >> >> >>> are >> >> >>> going to loose a lot of money on this otherwise rigged futures? >> >> >>> market. >> >> >>> >> >> >>> >> >> >>> Markets are not always accurate, but simply a form of price >> >> >>> discovery, >> >> >>> I >> >> >>> think "rigged" is perhaps a loaded term in this case and stretching >> >> >>> things. >> >> >>> A 12% futures market does not bode well for success, but, you never >> >> >>> know. >> >> >>> Since F2Pool stopped signaling NYA yesterday the signaling ratio is >> >> >>> now >> >> >>> about 81%, though this might have something to do with the feast >> >> >>> and >> >> >>> famine >> >> >>> EDA in bitcoin cash which has just been activated. Around 83% >> >> >>> might >> >> >>> be a >> >> >>> better guess. >> >> >>> However signaling is cheap, and many miners act in economic self >> >> >>> interest. Having helped run a coin for many years, I have >> >> >>> witnessed >> >> >>> this >> >> >>> being the case. There's nothing developers would like more than >> >> >>> steady >> >> >>> miners that stick with a coin, but sites such as coinwarz [1] all >> >> >>> too >> >> >>> often >> >> >>> create spikes in hash power related to profitability. >> >> >>> Wishing to stay on topic, I'd like to ask the following question. >> >> >>> If >> >> >>> signaling falls below the described 80% threshold stated above (ie >> >> >>> one >> >> >>> more >> >> >>> miner stops signaling), will this this be grounds to rethink the >> >> >>> timing of >> >> >>> the release schedule? >> >> >>> >> >> >>> [1] https://www.coinwarz.com/cryptocurrency >> >> >>> >> >> >>> >> >> >>> >> >> >>> From:Dr Adam Back via Bitcoin-segwit2x >> >> >>> Sent: 13 October 2017 10:11 >> >> >>> To: Emil Oldenburg >> >> >>> Cc: Peter Todd via Bitcoin-segwit2x >> >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork >> >> >>> still >> >> >>> happening? >> >> >>> >> >> >>> The futures price is 1/3 of 40% so yes actually < 40% hashrate is >> >> >>> quite >> >> >>> likely. >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https%3a%2f%2fwww.google.com%2f >> >> >>> >> >> >>> Nodes should upgrade because code changes are being made and it's >> >> >>> not >> >> >>> a good idea to run pre-production code on the live network. Do you >> >> >>> recall when the company you work for lost bitcoin by running >> >> >>> pre-release fork code before on the pool? >> >> >>> >> >> >>> Is anyone running BTC1 head in production? Protecting how much >> >> >>> value. >> >> >>> Reminder this is a public list. >> >> >>> >> >> >>> Adam >> >> >>> >> >> >>> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via >> >> >>> Bitcoin-segwit2x >> >> >>> wrote: >> >> >>> > The hardfork part is already locked in and is not subject to >> >> >>> > change. >> >> >>> > Many >> >> >>> > btc1 nodes are already deployed and they should not and don't >> >> >>> > need >> >> >>> > to >> >> >>> > update. The only thing left is a potential extra softfork for >> >> >>> > opt-in >> >> >>> > replay >> >> >>> > protection. Only the miners need this softfork. >> >> >>> > >> >> >>> > What makes you think the hardfork will have less than 40% >> >> >>> > hashpower? >> >> >>> > >> >> >>> > >> >> >>> > Emil Oldenburg, CTO >> >> >>> > Emil at bitcoin.com >> >> >>> > Visit the all new https://bitcoin.com >> >> >>> > Wechat: emilold >> >> >>> > Telegram: emilold >> >> >>> > >> >> >>> > On 2017 >> >> >>> ?10?13?17:31, Peter BitcoinReminder.com wrote: >> >> >>> >> >> >>> > >> >> >>> > Thats not a reason, the BTC1 sourcecode is still in development >> >> >>> > (f.e. >> >> >>> > replay >> >> >>> > protection was reverted just 1-2 days ago?) - so the argument ?it >> >> >>> > can?t >> >> >>> > be >> >> >>> > called off? is just wrong. >> >> >>> > >> >> >>> > So wouldn?t it make sense to add a minimum required hashrate for >> >> >>> > the >> >> >>> > HF >> >> >>> > to >> >> >>> > lock in? You are really going to fork off with f.e. 40 % >> >> >>> > hashpower? >> >> >>> > >> >> >>> > >> >> >>> > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via >> >> >>> > Bitcoin-segwit2x >> >> >>> > : >> >> >>> > >> >> >>> > If we try to be technical here. The HF is already activated, is >> >> >>> > estimated to >> >> >>> > trigger in 36 days, and can't be "called off". Nor is there any >> >> >>> > logic >> >> >>> > to >> >> >>> > delay it if hashrate deflects. That's the rules of the btc1 >> >> >>> > client. >> >> >>> > >> >> >>> > >> >> >>> > Emil Oldenburg, CTO >> >> >>> > Emil at bitcoin.com >> >> >>> > Visit the all new https://bitcoin.com >> >> >>> > Wechat: emilold >> >> >>> > Telegram: emilold >> >> >>> > >> >> >>> > On 2017 >> >> >>> ?10?13?05:31, John Heathco via Bitcoin-segwit2x wrote: >> >> >>> >> >> >>> > >> >> >>> > I don't believe there is an explicitly stated hashpower in which >> >> >>> > the >> >> >>> > fork >> >> >>> > would be "called off", but I would assume it is much lower than >> >> >>> > what >> >> >>> > is >> >> >>> > currently signaling, even if we make the (unwise) assumption that >> >> >>> > F2Pool >> >> >>> > would not contribute to mining 2x whatsoever. >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via >> >> >>> > Bitcoin-segwit2x >> >> >>> > wrote: >> >> >>> >> >> >> >>> >> I?m not Peter Todd, we just share the same (nice) firstname. >> >> >>> >> >> >> >>> >> I still didn?t get an answer what the minimum amount of >> >> >>> >> hashpower >> >> >>> >> is >> >> >>> >> required, before the fork is getting delayed? >> >> >>> >> We have to plan time for the whole security measures etc, so I >> >> >>> >> think >> >> >>> >> it?s >> >> >>> >> reasonable to get more information about this? >> >> >>> >> >> >> >>> >> >> >> >>> >> Am 12.10.2017 um 21:53 schrieb bitPico : >> >> >>> >> >> >> >>> >> Without you knowing why they stopped signaling this is FUD and >> >> >>> >> off-topic >> >> >>> >> for this list. Please instead let F2Pool state their own >> >> >>> >> opinion >> >> >>> >> here >> >> >>> >> since >> >> >>> >> yours doesn?t count. If you think your opinion does count then >> >> >>> >> show >> >> >>> >> us >> >> >>> >> your >> >> >>> >> blocks that your pool has produced; until then you are simply an >> >> >>> >> end-user >> >> >>> >> and still you are off-topic for this list. If you need ELI5 for >> >> >>> >> how >> >> >>> >> this >> >> >>> >> list works please let us know and we can help you Peter Todd. >> >> >>> >> >> >> >>> >> Have a groovy day! >> >> >>> >> >> >> >>> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via >> >> >>> >> Bitcoin-segwit2x >> >> >>> >> wrote: >> >> >>> >> >> >> >>> >> Since F2Pool stopped signaling for the NYA[1] and slush also >> >> >>> >> mines >> >> >>> >> mostly >> >> >>> >> non-NYA blocks, are you still going to fork off in November - >> >> >>> >> splitting the >> >> >>> >> chain intentionally? >> >> >>> >> >> >> >>> >> ? >> >> >>> >> [1] https://imgur.com/LgYdFKw >> >> >>> >> >> >> >>> >> _______________________________________________ >> >> >>> >> Bitcoin-segwit2x mailing list >> >> >>> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> >>> >> >> >> >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> _______________________________________________ >> >> >>> >> Bitcoin-segwit2x mailing list >> >> >>> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> >>> >> >> >> >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > _______________________________________________ >> >> >>> > Bitcoin-segwit2x mailing list >> >> >>> > Bitcoin-segwit2x at lists.linuxfoundation.org >> >> >>> > >> >> >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >>> > >> >> >>> > >> >> >>> > _______________________________________________ >> >> >>> > Bitcoin-segwit2x mailing list >> >> >>> > Bitcoin-segwit2x at lists.linuxfoundation.org >> >> >>> > >> >> >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > _______________________________________________ >> >> >>> > Bitcoin-segwit2x mailing list >> >> >>> > Bitcoin-segwit2x at lists.linuxfoundation.org >> >> >>> > >> >> >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >>> > >> >> >>> _______________________________________________ >> >> >>> Bitcoin-segwit2x mailing list >> >> >>> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >>> >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Bitcoin-segwit2x mailing list >> >> >>> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> > >> >> > _______________________________________________ >> >> > Bitcoin-segwit2x mailing list >> >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > >> >> > >> >> > _______________________________________________ >> >> > Bitcoin-segwit2x mailing list >> >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > >> > >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x From emil at bitcoin.com Sat Oct 14 08:07:08 2017 From: emil at bitcoin.com (Emil Oldenburg) Date: Sat, 14 Oct 2017 17:07:08 +0900 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: <24b02d99-aefb-9530-d50d-4ffa8a701a35@bitcoin.com> Anyone contributing to the contention disqualify themselves from complaining about contention. If you are campaigning and working against SegWit2x, then you can not use contention as an argument. If you are actively working on splitting the community and making the divide deeper, you simply can't use it as an argument. It's as a genuine concern as the mafia being concerned that your store will burn down unless you get their insurance. The Core developers failed to convince the community and the miners to activate Segwit alone. It was when it was bundled with a 2Mb base block as the deadlock was broken and Segwit got activated. The 1Mb baseblock limit is not a defining feature for bitcoin, and fighting tooth and nails about the container size is not only ridiculous, but just plain toxic and will in the long run ruin the community. If SegWit2x fails, it will set a terrible precedent; that the loudest, most intolerant and toxic will get the final say about Bitcoin changes. When we finally have the broadest community consensus in a long time, the best course of action would be for the minority group of small blockers to suspend their FUD and shaming campaigns and concede. SegWit2x is contentious because you made it contentious; suspend your trolling efforts and it won't be anymore. Emil Oldenburg, CTO Emil at bitcoin.com Visit the all new https://bitcoin.com Wechat: emilold Telegram: emilold On 2017?10?14? 16:38, Marcel Jamin via Bitcoin-segwit2x wrote: > On 14 October 2017 at 09:02, Jeff Garzik wrote: >> "Strong, two-way replay protection" is poorly defined. >> >> Segwit2x is an upgrade to bitcoin, not an altcoin. > I and many others heavily disagree. The simple reality is this: S2X is > incompatible with Bitcoin AND contentious. Miners and business > adopting this approach to "upgrading" will fork themselves off the > bitcoin blockchain. You're trying to define Bitcoin's rules by > strong-arming changes through hashpower. It doesn't bode well for > bitcoin's future if this is actually successful. > >> It is an explicit design goal that SPV wallets continue working through the >> fork, following the strongest, most secure chain as they were programmed to >> do. > ... tricking them to follow an invalid chain, as SPV can't fully > validate bitcoin's rules. Validity is not solely defined by hashpower. > >> Therefore, any method of replay protection that breaks over 10 million >> wallets - greatly exacerbating chain splits - is rejected (and this has been >> communicated repeatedly for months). > It doesn't break wallets at all, it merely fails to automatically (and > unsolicitedly) onboard them onto this WG's fork of bitcoin (= > incompatible consensus rules, new set of developers, new maintainer). > >> Put simply, we want most wallets to Just Keep Working. Certain types of >> replay protection break that. > Put simply, you want to take most wallets with you without explicit > consent and certain types of replay protection don't allow you to do > that. You're only offering an opt-out approach requiring user action + > bloat on the incumbent chain. > > There are ways to increase bitcoin's capacity without causing a schism > like this. After all, we did just double it. Work with (virtually all) > bitcoin protocol developers, not against them. This merely means > holding off on a hard fork for a while longer, acknowledging that a > safe hard fork that doesn't split the community is a hard thing to do. > As it should be. > > And before anyone is going to lecture me again that this is off-topic > for this list (as a blanket defense when things get uncomfortable), > rest assured that this will be my last mail to this list. One way or > another, this will sort itself out. > >> On Oct 14, 2017 2:24 AM, "Marcel Jamin via Bitcoin-segwit2x" >> wrote: >>> I wouldn't consider any opt-in approach as "strong" replay protection. >>> If this WG as NACKed strong two way replay protection, then it's not a >>> safe upgrade path und thus not an implementation honoring the NYA. >>> >>> On 14 October 2017 at 07:53, Jacob Eliosoff >>> wrote: >>>> Can I ask that anyone advocating 2-way replay protection (which I also >>>> support) be specific about how they propose it be done? No disrespect >>>> meant, but BCH-style RP, that would require old wallets to upgrade, has >>>> been >>>> proposed and emphatically NACKed here umpteen times: it is just >>>> unrealistic >>>> to think this project would adopt it at this stage. There are other >>>> 2-way >>>> RP approaches that I still believe are worth pursuing, but at this point >>>> any >>>> discussion of 2-way RP as if it's a simple binary decision is a complete >>>> waste of everyone's time. >>>> >>>> >>>> On Sat, Oct 14, 2017 at 1:31 AM, Marcel Jamin via Bitcoin-segwit2x >>>> wrote: >>>>> On 14 October 2017 at 02:20, Ben Peters via Bitcoin-segwit2x >>>>> wrote: >>>>>> I think there is a fundamental misunderstanding about the nature of >>>>>> the >>>>>> NYA/Segwit2x endeavour. What is happening here is that an >>>>>> alternative, >>>>>> minimally modified, version of the Bitcoin code is being developed >>>>>> that >>>>>> will >>>>>> implement a change that has long been sought by the mining community >>>>>> and >>>>>> many in industry and beyond (a change that they presumably feel is >>>>>> important >>>>>> for the future success of Bitcoin and thus their respective >>>>>> investments). >>>>>> >>>>>> That candidate code will be offered to the miners and mining pools, >>>>>> who >>>>>> may >>>>>> or may not opt to apply hashing power to it. If they apply more than >>>>>> the >>>>>> threshold amount of hashing power, then that new code will >>>>>> effectively >>>>>> takeover from the previous consensus rule, and take most SPV wallets >>>>>> and >>>>>> economic activity along with it. >>>>>> >>>>>> Rather than lobbying this technical working group to ?call off? their >>>>>> efforts, your time might be better spent lobbying the miners. The >>>>>> function >>>>>> of this group is to produce candidate code, thus fulfilling the >>>>>> obligations >>>>>> as set out under the NYA. >>>>> Fair enough, but this working group is making technical decisions that >>>>> can create a lof of confusion and cause many problems for bitcoin >>>>> users. >>>>> >>>>> Much of the lobbying is targeted towards implementing strong two-way >>>>> replay protection. The reason for not implementing this protection, is >>>>> that it would reveal this project as an alternative fork of bitcoin >>>>> and is based on the assumption, that most miners will in fact employ >>>>> the client put forward by this WG and apply their hashpower to it. >>>>> >>>>> Many indicators however point towards a virtually guaranteed network >>>>> split. >>>>> >>>>> The NYA committed signers to "deployment of safe solutions that >>>>> increase bitcoin capacity". This implementation doesn't fulfill that >>>>> goal. Without strong replay protection, this will be a mess for both >>>>> sides. >>>>> >>>>>> >>>>>> On Oct 13, 2017, at 8:55 AM, Melvin Carvalho via Bitcoin-segwit2x >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 13 October 2017 at 12:45, Melvin Carvalho >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> On 13 October 2017 at 12:30, Phillip Katete >>>>>>> wrote: >>>>>>>> The disingenuity here is ?painful to watch?. First you make hay of >>>>>>>> f2pool >>>>>>>> switching off NYA signaling intent THEN you rubbish signaling >>>>>>>> intent >>>>>>>> as >>>>>>>> cheap and not worthy of consideration as a metric. More worryingly, >>>>>>>> you then >>>>>>>> want to predicate the HF on miner signaling at the 80% threshold. >>>>>>>> So >>>>>>>> which >>>>>>>> is it then? >>>>>>>> >>>>>>>> Even with the EDA induced hash oscillations, I am confident hash at >>>>>>>> and >>>>>>>> post fork will mirror signaling intent. >>>>>>> >>>>>>> 24h signaling fell to 79.86% [1] >>>>>> >>>>>> NYA signaling is now down to 77.70% in the last 24h (down from over >>>>>> 90% >>>>>> a >>>>>> day ago) >>>>>> >>>>>> https://coin.dance/blocks >>>>>> >>>>>> This does not take into account ViaBTC which may support either >>>>>> chain, >>>>>> but >>>>>> are currently signaling 100% NYA. >>>>>> >>>>>> However, much hash is mining bitcoin cash right now, and probably >>>>>> favourable >>>>>> to seg2x >>>>>> >>>>>> Additionally, you can monitor the futures market in realtime >>>>>> >>>>>> https://cryptowat.ch/bitfinex/bt2btc >>>>>> >>>>>> Currently trading at 10.6% of bitcoin (down from over 20% a day ago) >>>>>> >>>>>> You may wish to consider these metrics a source of new information >>>>>> for >>>>>> this >>>>>> project. And / or watch them as they develop. >>>>>> >>>>>>> >>>>>>> [1] https://coin.dance/blocks#thisweek >>>>>>> >>>>>>>> >>>>>>>> From: Melvin Carvalho >>>>>>>> Sent: 13 October 2017 11:11 >>>>>>>> To: Phillip Katete >>>>>>>> Cc: Dr Adam Back; Emil Oldenburg; Peter Todd via Bitcoin-segwit2x >>>>>>>> >>>>>>>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork >>>>>>>> still >>>>>>>> happening? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x >>>>>>>> wrote: >>>>>>>> >>>>>>>> You are barking up the wrong tree by using a ?rigged? futures? >>>>>>>> price >>>>>>>> to >>>>>>>> estimate the hash supporting the upgrade at fork time. They NYA was >>>>>>>> presented as being backed by at least 80% of the network hash then >>>>>>>> and >>>>>>>> was >>>>>>>> activated / locked-in by over 90%. Since then, it has continued to >>>>>>>> receive >>>>>>>> and sustain intent signalling above the introduction threshold. It >>>>>>>> is >>>>>>>> only >>>>>>>> rational to expect the hash on fork to reflect the latter as >>>>>>>> opposed >>>>>>>> to >>>>>>>> futures? prices. >>>>>>>> >>>>>>>> Obiter dicta: the futures? price is more reflective of the wavering >>>>>>>> non >>>>>>>> mining, none economic users. It goes without saying, a lot of >>>>>>>> people >>>>>>>> are >>>>>>>> going to loose a lot of money on this otherwise rigged futures? >>>>>>>> market. >>>>>>>> >>>>>>>> >>>>>>>> Markets are not always accurate, but simply a form of price >>>>>>>> discovery, >>>>>>>> I >>>>>>>> think "rigged" is perhaps a loaded term in this case and stretching >>>>>>>> things. >>>>>>>> A 12% futures market does not bode well for success, but, you never >>>>>>>> know. >>>>>>>> Since F2Pool stopped signaling NYA yesterday the signaling ratio is >>>>>>>> now >>>>>>>> about 81%, though this might have something to do with the feast >>>>>>>> and >>>>>>>> famine >>>>>>>> EDA in bitcoin cash which has just been activated. Around 83% >>>>>>>> might >>>>>>>> be a >>>>>>>> better guess. >>>>>>>> However signaling is cheap, and many miners act in economic self >>>>>>>> interest. Having helped run a coin for many years, I have >>>>>>>> witnessed >>>>>>>> this >>>>>>>> being the case. There's nothing developers would like more than >>>>>>>> steady >>>>>>>> miners that stick with a coin, but sites such as coinwarz [1] all >>>>>>>> too >>>>>>>> often >>>>>>>> create spikes in hash power related to profitability. >>>>>>>> Wishing to stay on topic, I'd like to ask the following question. >>>>>>>> If >>>>>>>> signaling falls below the described 80% threshold stated above (ie >>>>>>>> one >>>>>>>> more >>>>>>>> miner stops signaling), will this this be grounds to rethink the >>>>>>>> timing of >>>>>>>> the release schedule? >>>>>>>> >>>>>>>> [1] https://www.coinwarz.com/cryptocurrency >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From:Dr Adam Back via Bitcoin-segwit2x >>>>>>>> Sent: 13 October 2017 10:11 >>>>>>>> To: Emil Oldenburg >>>>>>>> Cc: Peter Todd via Bitcoin-segwit2x >>>>>>>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork >>>>>>>> still >>>>>>>> happening? >>>>>>>> >>>>>>>> The futures price is 1/3 of 40% so yes actually < 40% hashrate is >>>>>>>> quite >>>>>>>> likely. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https%3a%2f%2fwww.google.com%2f >>>>>>>> >>>>>>>> Nodes should upgrade because code changes are being made and it's >>>>>>>> not >>>>>>>> a good idea to run pre-production code on the live network. Do you >>>>>>>> recall when the company you work for lost bitcoin by running >>>>>>>> pre-release fork code before on the pool? >>>>>>>> >>>>>>>> Is anyone running BTC1 head in production? Protecting how much >>>>>>>> value. >>>>>>>> Reminder this is a public list. >>>>>>>> >>>>>>>> Adam >>>>>>>> >>>>>>>> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via >>>>>>>> Bitcoin-segwit2x >>>>>>>> wrote: >>>>>>>>> The hardfork part is already locked in and is not subject to >>>>>>>>> change. >>>>>>>>> Many >>>>>>>>> btc1 nodes are already deployed and they should not and don't >>>>>>>>> need >>>>>>>>> to >>>>>>>>> update. The only thing left is a potential extra softfork for >>>>>>>>> opt-in >>>>>>>>> replay >>>>>>>>> protection. Only the miners need this softfork. >>>>>>>>> >>>>>>>>> What makes you think the hardfork will have less than 40% >>>>>>>>> hashpower? >>>>>>>>> >>>>>>>>> >>>>>>>>> Emil Oldenburg, CTO >>>>>>>>> Emil at bitcoin.com >>>>>>>>> Visit the all new https://bitcoin.com >>>>>>>>> Wechat: emilold >>>>>>>>> Telegram: emilold >>>>>>>>> >>>>>>>>> On 2017 >>>>>>>> ?10?13?17:31, Peter BitcoinReminder.com wrote: >>>>>>>> >>>>>>>>> Thats not a reason, the BTC1 sourcecode is still in development >>>>>>>>> (f.e. >>>>>>>>> replay >>>>>>>>> protection was reverted just 1-2 days ago?) - so the argument ?it >>>>>>>>> can?t >>>>>>>>> be >>>>>>>>> called off? is just wrong. >>>>>>>>> >>>>>>>>> So wouldn?t it make sense to add a minimum required hashrate for >>>>>>>>> the >>>>>>>>> HF >>>>>>>>> to >>>>>>>>> lock in? You are really going to fork off with f.e. 40 % >>>>>>>>> hashpower? >>>>>>>>> >>>>>>>>> >>>>>>>>> Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via >>>>>>>>> Bitcoin-segwit2x >>>>>>>>> : >>>>>>>>> >>>>>>>>> If we try to be technical here. The HF is already activated, is >>>>>>>>> estimated to >>>>>>>>> trigger in 36 days, and can't be "called off". Nor is there any >>>>>>>>> logic >>>>>>>>> to >>>>>>>>> delay it if hashrate deflects. That's the rules of the btc1 >>>>>>>>> client. >>>>>>>>> >>>>>>>>> >>>>>>>>> Emil Oldenburg, CTO >>>>>>>>> Emil at bitcoin.com >>>>>>>>> Visit the all new https://bitcoin.com >>>>>>>>> Wechat: emilold >>>>>>>>> Telegram: emilold >>>>>>>>> >>>>>>>>> On 2017 >>>>>>>> ?10?13?05:31, John Heathco via Bitcoin-segwit2x wrote: >>>>>>>> >>>>>>>>> I don't believe there is an explicitly stated hashpower in which >>>>>>>>> the >>>>>>>>> fork >>>>>>>>> would be "called off", but I would assume it is much lower than >>>>>>>>> what >>>>>>>>> is >>>>>>>>> currently signaling, even if we make the (unwise) assumption that >>>>>>>>> F2Pool >>>>>>>>> would not contribute to mining 2x whatsoever. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via >>>>>>>>> Bitcoin-segwit2x >>>>>>>>> wrote: >>>>>>>>>> I?m not Peter Todd, we just share the same (nice) firstname. >>>>>>>>>> >>>>>>>>>> I still didn?t get an answer what the minimum amount of >>>>>>>>>> hashpower >>>>>>>>>> is >>>>>>>>>> required, before the fork is getting delayed? >>>>>>>>>> We have to plan time for the whole security measures etc, so I >>>>>>>>>> think >>>>>>>>>> it?s >>>>>>>>>> reasonable to get more information about this? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Am 12.10.2017 um 21:53 schrieb bitPico : >>>>>>>>>> >>>>>>>>>> Without you knowing why they stopped signaling this is FUD and >>>>>>>>>> off-topic >>>>>>>>>> for this list. Please instead let F2Pool state their own >>>>>>>>>> opinion >>>>>>>>>> here >>>>>>>>>> since >>>>>>>>>> yours doesn?t count. If you think your opinion does count then >>>>>>>>>> show >>>>>>>>>> us >>>>>>>>>> your >>>>>>>>>> blocks that your pool has produced; until then you are simply an >>>>>>>>>> end-user >>>>>>>>>> and still you are off-topic for this list. If you need ELI5 for >>>>>>>>>> how >>>>>>>>>> this >>>>>>>>>> list works please let us know and we can help you Peter Todd. >>>>>>>>>> >>>>>>>>>> Have a groovy day! >>>>>>>>>> >>>>>>>>>> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via >>>>>>>>>> Bitcoin-segwit2x >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Since F2Pool stopped signaling for the NYA[1] and slush also >>>>>>>>>> mines >>>>>>>>>> mostly >>>>>>>>>> non-NYA blocks, are you still going to fork off in November - >>>>>>>>>> splitting the >>>>>>>>>> chain intentionally? >>>>>>>>>> >>>>>>>>>> ? >>>>>>>>>> [1] https://imgur.com/LgYdFKw >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Bitcoin-segwit2x mailing list >>>>>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>>>>> >>>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Bitcoin-segwit2x mailing list >>>>>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>>>>> >>>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Bitcoin-segwit2x mailing list >>>>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>>>> >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Bitcoin-segwit2x mailing list >>>>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>>>> >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Bitcoin-segwit2x mailing list >>>>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>>>> >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Bitcoin-segwit2x mailing list >>>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Bitcoin-segwit2x mailing list >>>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Bitcoin-segwit2x mailing list >>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Bitcoin-segwit2x mailing list >>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x From cedrickperrigo at protonmail.com Sat Oct 14 08:37:19 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 04:37:19 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: <24b02d99-aefb-9530-d50d-4ffa8a701a35@bitcoin.com> References: <24b02d99-aefb-9530-d50d-4ffa8a701a35@bitcoin.com> Message-ID: <2Zrk4ZW7SsI4r-rp33uzvV3Mk1hxzFJrCG2OQNHNpz1TTkJVxGb7IEnUXgK2XmKmY18BS9lqbpzAvfxTXZnGONQgccH9PPu02fzpKeVQpP8=@protonmail.com> Put it the other way around: Core/Blockstream trollers should consider its campaign failed if it does not get more than 50% hashrate support. I do not understand why currently Core thinks that F2Pool stopped signalling does something good to them. F2Pool has a history of switching sides and is an unstable factor. Given the characteristics of F2Pool founders, it is likely that they might switch sides again and again before the fork date. How does this feel victorious for Core? With less than 20 percent of the hash power, Core will be a centralized network after the fork date -- there will be more than 50 percent of blocks mined by F2Pool and 90 percent of blocks mined by F2Pool and Slush Pool. F2Pool can easily attack the whole Core network and make it unusable. Combined with slow block rates and high fees that will at least last three months, I don't think any sane people would use that network. Compared with Core, Segwit2x is much more decentralized with many more miners and business support. It is basically Blockstream/Core vs. everyone else. Besides, the continued trolling from Core has driven those who did not pick a side away. I've always seen Jeff, Emil, Erik and many others patiently answer questions regarding relay protection and else. In Core, you will be welcomed by personal attacks and "NACK"s without any reason. For a normal user like me, with most businesses I use like BitPay, Coinbase, ShapeShift and many others in segwit2x, plus the additional benefits of low fees, there is no reason for me to stay in Core. There is also a silent majority of users who won't publicly express their opinions because of all the Core trolls. Good luck to Core, and hope all Bitcoin people can stay together. Sent with [ProtonMail](https://protonmail.com) Secure Email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jli225 at binghamton.edu Sat Oct 14 09:18:56 2017 From: jli225 at binghamton.edu (Junyi Li) Date: Sat, 14 Oct 2017 09:18:56 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: Marcel, If you believe Bitcoin (SegWit2X) is not Bitcoin, this mailing list may be not the right place for you to complain, since you have recklessly violated the charter, for a long time. As many others clarified patiently, this mailing list is for technical talks only. To defend and improve Bitcoin project constructively technically is the only aim of us. I respect your freedom of speech, but you should realize that you have already infringed others' rights. Frankly speaking, you are harrassing others. The toxic environment in Bitcoin community has already scared those most talented and reputable devs away from Bitcoin in the past years. Instead of continuing cursing, trying to be constructive is the required attitude in any work group. Bitcoin (SegWit2X) is Bitcoin. Bitcoin is censorship-resistant. It's a shame to stand on the side of censorship. If you disagree on 'All human beings are born free and equal', you are actually humiliating yourself and harassing others by continuing talking about the constitution. We have confidence in defending our constitution and Bitcoin. The Berlin wall looks quite high, yet it's rotten since long ago. The censorship and propaganda were very effective in brainwashing useful idiots, yet its collapse is doomed. Because, we have belief in Bitcoin. We believe Bitcoin is destined to benefit the world very, very, very much. Welcome to Bitcoin, anyway. Sincerely, (Sorry for this off-topic email.) Junyi On Sat, Oct 14, 2017 at 00:38 Marcel Jamin via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > On 14 October 2017 at 09:02, Jeff Garzik wrote: > > "Strong, two-way replay protection" is poorly defined. > > > > Segwit2x is an upgrade to bitcoin, not an altcoin. > > I and many others heavily disagree. The simple reality is this: S2X is > incompatible with Bitcoin AND contentious. Miners and business > adopting this approach to "upgrading" will fork themselves off the > bitcoin blockchain. You're trying to define Bitcoin's rules by > strong-arming changes through hashpower. It doesn't bode well for > bitcoin's future if this is actually successful. > > > It is an explicit design goal that SPV wallets continue working through > the > > fork, following the strongest, most secure chain as they were programmed > to > > do. > > ... tricking them to follow an invalid chain, as SPV can't fully > validate bitcoin's rules. Validity is not solely defined by hashpower. > > > Therefore, any method of replay protection that breaks over 10 million > > wallets - greatly exacerbating chain splits - is rejected (and this has > been > > communicated repeatedly for months). > > It doesn't break wallets at all, it merely fails to automatically (and > unsolicitedly) onboard them onto this WG's fork of bitcoin (= > incompatible consensus rules, new set of developers, new maintainer). > > > Put simply, we want most wallets to Just Keep Working. Certain types of > > replay protection break that. > > Put simply, you want to take most wallets with you without explicit > consent and certain types of replay protection don't allow you to do > that. You're only offering an opt-out approach requiring user action + > bloat on the incumbent chain. > > There are ways to increase bitcoin's capacity without causing a schism > like this. After all, we did just double it. Work with (virtually all) > bitcoin protocol developers, not against them. This merely means > holding off on a hard fork for a while longer, acknowledging that a > safe hard fork that doesn't split the community is a hard thing to do. > As it should be. > > And before anyone is going to lecture me again that this is off-topic > for this list (as a blanket defense when things get uncomfortable), > rest assured that this will be my last mail to this list. One way or > another, this will sort itself out. > l -------------- next part -------------- An HTML attachment was scrubbed... URL: From segwit2x_mailinglist at bitcoinreminder.com Sat Oct 14 09:40:16 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Sat, 14 Oct 2017 11:40:16 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: About ?how a strong 2 way replay protection is to be defined? - maybe just listen to the community and exchanges? Bitmex declared yesterday that they won?t support or even list B2X, because you don?t offer the minimal level of security for the users: Strong two way transaction replay protection, enabled by default, such that transactions on each chain are invalid on the other chain. A clean break, such that the new chain cannot be ?wiped out? by the original chain. A modification to the block header, such that all wallets (including light clients) are required to upgrade to follow the hardforked chain. A change in address format, to prevent people inadvertently sending coins to an address on the wrong chain. New P2P network magic, to ensure a functioning and reliable node network for the both coins. https://blog.bitmex.com/policy-on-bitcoin-hard-forks-update/ And to tell ?oh it?s so hard to implement? is nonsense, even BCash did it in about the same timeframe. I think you shoot yourself in your own foot by missing these features and I think a lot other exchanges will follow or followed already Bitmex (BitKonan f.e.). This strategy is unprofessional and risky - for both sides. > Am 14.10.2017 um 11:18 schrieb Junyi Li via Bitcoin-segwit2x : > > Marcel, > If you believe Bitcoin (SegWit2X) is not Bitcoin, this mailing list may be not the right place for you to complain, since you have recklessly violated the charter, for a long time. > > As many others clarified patiently, this mailing list is for technical talks only. To defend and improve Bitcoin project constructively technically is the only aim of us. > > I respect your freedom of speech, but you should realize that you have already infringed others' rights. Frankly speaking, you are harrassing others. > > The toxic environment in Bitcoin community has already scared those most talented and reputable devs away from Bitcoin in the past years. Instead of continuing cursing, trying to be constructive is the required attitude in any work group. > > Bitcoin (SegWit2X) is Bitcoin. Bitcoin is censorship-resistant. It's a shame to stand on the side of censorship. > > If you disagree on 'All human beings are born free and equal', you are actually humiliating yourself and harassing others by continuing talking about the constitution. > > We have confidence in defending our constitution and Bitcoin. The Berlin wall looks quite high, yet it's rotten since long ago. The censorship and propaganda were very effective in brainwashing useful idiots, yet its collapse is doomed. > > Because, we have belief in Bitcoin. We believe Bitcoin is destined to benefit the world very, very, very much. > > Welcome to Bitcoin, anyway. > > > Sincerely, > > (Sorry for this off-topic email.) > > Junyi > > > On Sat, Oct 14, 2017 at 00:38 Marcel Jamin via Bitcoin-segwit2x > wrote: > On 14 October 2017 at 09:02, Jeff Garzik > wrote: > > "Strong, two-way replay protection" is poorly defined. > > > > Segwit2x is an upgrade to bitcoin, not an altcoin. > > I and many others heavily disagree. The simple reality is this: S2X is > incompatible with Bitcoin AND contentious. Miners and business > adopting this approach to "upgrading" will fork themselves off the > bitcoin blockchain. You're trying to define Bitcoin's rules by > strong-arming changes through hashpower. It doesn't bode well for > bitcoin's future if this is actually successful. > > > It is an explicit design goal that SPV wallets continue working through the > > fork, following the strongest, most secure chain as they were programmed to > > do. > > ... tricking them to follow an invalid chain, as SPV can't fully > validate bitcoin's rules. Validity is not solely defined by hashpower. > > > Therefore, any method of replay protection that breaks over 10 million > > wallets - greatly exacerbating chain splits - is rejected (and this has been > > communicated repeatedly for months). > > It doesn't break wallets at all, it merely fails to automatically (and > unsolicitedly) onboard them onto this WG's fork of bitcoin (= > incompatible consensus rules, new set of developers, new maintainer). > > > Put simply, we want most wallets to Just Keep Working. Certain types of > > replay protection break that. > > Put simply, you want to take most wallets with you without explicit > consent and certain types of replay protection don't allow you to do > that. You're only offering an opt-out approach requiring user action + > bloat on the incumbent chain. > > There are ways to increase bitcoin's capacity without causing a schism > like this. After all, we did just double it. Work with (virtually all) > bitcoin protocol developers, not against them. This merely means > holding off on a hard fork for a while longer, acknowledging that a > safe hard fork that doesn't split the community is a hard thing to do. > As it should be. > > And before anyone is going to lecture me again that this is off-topic > for this list (as a blanket defense when things get uncomfortable), > rest assured that this will be my last mail to this list. One way or > another, this will sort itself out. > l > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Sat Oct 14 09:59:58 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 05:59:58 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: Lmao. What's the usefulness to tell the opinions of some exchanges that has market share of 0.00% according to CoinMarketCap? We probably should take considerations of the majority first like Coinbase, ShapeShift and others, who needs to take care of millions of its own users. In the mean time, no offense to them, but as a really small business, you would have nothing to lose even when you pick the wrong side. The smaller you are, the easier you can be brought by Blockstream to follow its propaganda. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 14, 2017 5:40 PM > UTC Time: October 14, 2017 9:40 AM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: bitcoin-segwit2x at lists.linuxfoundation.org > > About ?how a strong 2 way replay protection is to be defined? - maybe just listen to the community and exchanges? > > Bitmex declared yesterday that they won?t support or even list B2X, because you don?t offer the minimal level of security for the users: > > - Strong two way transaction replay protection, enabled by default, such that transactions on each chain are invalid on the other chain. > - A clean break, such that the new chain cannot be ?wiped out? by the original chain. > - A modification to the block header, such that all wallets (including light clients) are required to upgrade to follow the hardforked chain. > - A change in address format, to prevent people inadvertently sending coins to an address on the wrong chain. > - New P2P network magic, to ensure a functioning and reliable node network for the both coins. > > https://blog.bitmex.com/policy-on-bitcoin-hard-forks-update/ > > And to tell ?oh it?s so hard to implement? is nonsense, even BCash did it in about the same timeframe. > > I think you shoot yourself in your own foot by missing these features and I think a lot other exchanges will follow or followed already Bitmex (BitKonan f.e.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From wordsgalore at gmail.com Sat Oct 14 10:18:01 2017 From: wordsgalore at gmail.com (Scott Roberts) Date: Sat, 14 Oct 2017 06:18:01 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? Message-ID: SegWit2x seems to have more miner and business support, not "community" support from devs, users, and hodlers. Higher hashrate is a chain consensus, not a bitcoin protocol consensus. Miners and businesses unilaterally making decisions is like banks and corporations lobbying government, something bitcoin is supposed to be against. Calling SegWit2x an "attack" is a declaration that there is a technological deficiency. Alts do not whine over hash attacks from larger coins. They simply fix their difficulty to have a much faster response. By not fixing it, SegWit and SegWit2x are demanding that there be only 1 "bitcoin". Competing forks that let the market decide would be better. An incredibly slow (aka "inefficient", "inaccurate", "bureaucratic", or "dumb") difficulty blocks the market from being able to make a decision. It prevents a smaller competitor from growing because it will be sent into oscillations with long delays until the price drops to reflect the slow (dumb) difficulty. Even alts with 5x faster block times than bitcoin have to abandon the cryptonote difficulty that is a 300 block window. Either SegWit or SegWit2x are going to desperately need a much shorter rolling window average for determining difficulty in the range of 30 to 60 blocks (as long as it is not "tempered" or otherwise slowed down with a low-pass filter). It's very simple and there is no better solution (if you disagree, email me and I'll show how your suggested alternative is no better or inferior): next_D = avg_D * 600 / avg_ST Devs of the bitcoin protocol need to solve the technical challenge of how to provide users (buyers and sellers of goods and services) with an alternative that protects them against hodlers (the 1%) and miners (the banks). Saying there should be only one bitcoin and that it should be "The" coin benefits hodlers to the detriment of future users (the 99%). Competing "bitcoins" would be more like Hayak's competing currencies. Limited quantity coin is a deflationary coin, something the 1% love. The ideal coin would be constant value so that society's contracts can remain valid when expressed in it (like price and wage commitments). This can only be done when coin quantity expands in proportion to its marketplace use (by users, not traders). So let forks thrive together. Don't let hodlers retain the same 90% of all coins when these forks occur. Figure out how to airdrop the new coins to each unique human DNA sequence, and how to let businesses equally accept them. From cedrickperrigo at protonmail.com Sat Oct 14 10:39:22 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 06:39:22 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: I only see existing devs using anti-segwit2x as a strategy to hold their places. Core is extremely hostile for new devs. This includes scientists and professional engineers who has much better understanding of the Bitcoin protocol. Businesses and miners are large hodlers of Bitcoin. Excluding them makes no sense. Besides, if you think there's more "users" supporting segwit1x altcoin. Show me the proof with their Bitcoin holding amounts. If that ever covers 10% of the total Bitcoins in circulation, I would start to consider segwit1x altcoin has some grounds. Otherwise, it's just sybil attack trolls paid by Blockstream. Besides, segwit2x businesses also have many engineers who would be glad to take up the job of Core if they quit. (But of course Core is always welcome to join the segwit2x camp.) Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 14, 2017 6:18 PM > UTC Time: October 14, 2017 10:18 AM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: bitcoin-segwit2x at lists.linuxfoundation.org > > SegWit2x seems to have more miner and business support, not > "community" support from devs, users, and hodlers. > > Higher hashrate is a chain consensus, not a bitcoin protocol consensus. > > Miners and businesses unilaterally making decisions is like banks and > corporations lobbying government, something bitcoin is supposed to be > against. > > Calling SegWit2x an "attack" is a declaration that there is a > technological deficiency. Alts do not whine over hash attacks from > larger coins. They simply fix their difficulty to have a much faster > response. By not fixing it, SegWit and SegWit2x are demanding that > there be only 1 "bitcoin". Competing forks that let the market decide > would be better. An incredibly slow (aka "inefficient", "inaccurate", > "bureaucratic", or "dumb") difficulty blocks the market from being > able to make a decision. It prevents a smaller competitor from > growing because it will be sent into oscillations with long delays > until the price drops to reflect the slow (dumb) difficulty. Even > alts with 5x faster block times than bitcoin have to abandon the > cryptonote difficulty that is a 300 block window. > > Either SegWit or SegWit2x are going to desperately need a much shorter > rolling window average for determining difficulty in the range of 30 > to 60 blocks (as long as it is not "tempered" or otherwise slowed down > with a low-pass filter). It"s very simple and there is no better > solution (if you disagree, email me and I"ll show how your suggested > alternative is no better or inferior): > > next_D = avg_D * 600 / avg_ST > > Devs of the bitcoin protocol need to solve the technical challenge of > how to provide users (buyers and sellers of goods and services) with > an alternative that protects them against hodlers (the 1%) and miners > (the banks). Saying there should be only one bitcoin and that it > should be "The" coin benefits hodlers to the detriment of future users > (the 99%). Competing "bitcoins" would be more like Hayak"s competing > currencies. Limited quantity coin is a deflationary coin, something > the 1% love. The ideal coin would be constant value so that society"s > contracts can remain valid when expressed in it (like price and wage > commitments). This can only be done when coin quantity expands in > proportion to its marketplace use (by users, not traders). So let > forks thrive together. Don"t let hodlers retain the same 90% of all > coins when these forks occur. Figure out how to airdrop the new coins > to each unique human DNA sequence, and how to let businesses equally > accept them. > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From segwit2x_mailinglist at bitcoinreminder.com Sat Oct 14 10:43:57 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Sat, 14 Oct 2017 12:43:57 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: > some exchanges that has market share of 0.00% according to CoinMarketCap? I don?t get where you get your numbers from, but when I look at coinmarketcap and sort by BTC trading volume, Bitmex is higher ranked than GDAX? https://coinmarketcap.com/exchanges/volume/24-hour/all/#BTC > Am 14.10.2017 um 11:59 schrieb Cedrick Perrigo : > > Lmao. What's the usefulness to tell the opinions of some exchanges that has market share of 0.00% according to CoinMarketCap? We probably should take considerations of the majority first like Coinbase, ShapeShift and others, who needs to take care of millions of its own users. > > In the mean time, no offense to them, but as a really small business, you would have nothing to lose even when you pick the wrong side. The smaller you are, the easier you can be brought by Blockstream to follow its propaganda. > > > Sent with ProtonMail Secure Email. > >> -------- Original Message -------- >> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >> Local Time: October 14, 2017 5:40 PM >> UTC Time: October 14, 2017 9:40 AM >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> To: bitcoin-segwit2x at lists.linuxfoundation.org >> >> About ?how a strong 2 way replay protection is to be defined? - maybe just listen to the community and exchanges? >> >> Bitmex declared yesterday that they won?t support or even list B2X, because you don?t offer the minimal level of security for the users: >> >> Strong two way transaction replay protection, enabled by default, such that transactions on each chain are invalid on the other chain. >> A clean break, such that the new chain cannot be ?wiped out? by the original chain. >> A modification to the block header, such that all wallets (including light clients) are required to upgrade to follow the hardforked chain. >> A change in address format, to prevent people inadvertently sending coins to an address on the wrong chain. >> New P2P network magic, to ensure a functioning and reliable node network for the both coins. >> https://blog.bitmex.com/policy-on-bitcoin-hard-forks-update/ >> >> And to tell ?oh it?s so hard to implement? is nonsense, even BCash did it in about the same timeframe. >> >> I think you shoot yourself in your own foot by missing these features and I think a lot other exchanges will follow or followed already Bitmex (BitKonan f.e.). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Sat Oct 14 10:47:10 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 06:47:10 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: Educate yourself. It's a market with no fees. So the volume should at least be discounted (and for CoinMarketCap it's considered meaningless). Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 14, 2017 6:43 PM > UTC Time: October 14, 2017 10:43 AM > From: segwit2x_mailinglist at bitcoinreminder.com > To: Cedrick Perrigo > bitcoin-segwit2x at lists.linuxfoundation.org > >> some exchanges that has market share of 0.00% according to CoinMarketCap? > > I don?t get where you get your numbers from, but when I look at coinmarketcap and sort by BTC trading volume, Bitmex is higher ranked than GDAX? > > https://coinmarketcap.com/exchanges/volume/24-hour/all/#BTC > >> Am 14.10.2017 um 11:59 schrieb Cedrick Perrigo : >> >> Lmao. What's the usefulness to tell the opinions of some exchanges that has market share of 0.00% according to CoinMarketCap? We probably should take considerations of the majority first like Coinbase, ShapeShift and others, who needs to take care of millions of its own users. >> >> In the mean time, no offense to them, but as a really small business, you would have nothing to lose even when you pick the wrong side. The smaller you are, the easier you can be brought by Blockstream to follow its propaganda. >> >> Sent with [ProtonMail](https://protonmail.com/) Secure Email. >> >>> -------- Original Message -------- >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >>> Local Time: October 14, 2017 5:40 PM >>> UTC Time: October 14, 2017 9:40 AM >>> From: bitcoin-segwit2x at lists.linuxfoundation.org >>> To: bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> About ?how a strong 2 way replay protection is to be defined? - maybe just listen to the community and exchanges? >>> >>> Bitmex declared yesterday that they won?t support or even list B2X, because you don?t offer the minimal level of security for the users: >>> >>> - Strong two way transaction replay protection, enabled by default, such that transactions on each chain are invalid on the other chain. >>> - A clean break, such that the new chain cannot be ?wiped out? by the original chain. >>> - A modification to the block header, such that all wallets (including light clients) are required to upgrade to follow the hardforked chain. >>> - A change in address format, to prevent people inadvertently sending coins to an address on the wrong chain. >>> - New P2P network magic, to ensure a functioning and reliable node network for the both coins. >>> >>> https://blog.bitmex.com/policy-on-bitcoin-hard-forks-update/ >>> >>> And to tell ?oh it?s so hard to implement? is nonsense, even BCash did it in about the same timeframe. >>> >>> I think you shoot yourself in your own foot by missing these features and I think a lot other exchanges will follow or followed already Bitmex (BitKonan f.e.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at blockstream.com Sat Oct 14 11:19:44 2017 From: adam at blockstream.com (Dr Adam Back) Date: Sat, 14 Oct 2017 13:19:44 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: A lot of what you described doesn't work the way you seem to expect. There's a few levels: Mining economics: I do some mining, and there are a number of data points from alt-coins that share mining algorithms: miners short / mid term mine what is profitable. That is driven by relative price. Difficulty adjusts to equilibrium. This is a feature, it is the incentive that secures blockchains. Bitcoin security works by economically incentivised creation of valid blocks as measured by the nodes on the network. Nodes and wallets mechanically todays software: Existing full nodes won't follow. Most smart phone wallets will not automatically switch but either ignore a new chain, stop functioning, go into some kind of warning state pending bugfix, some older wallets may get stuck on random chain. And because there is no proper replay protection randomly transactions will be made on one or both chains unless mixed with new coinbase over time. That will be pretty disruptive because people writing wallet software don't know what segwit2x code will be as they keep changing. Bitcoin cash changed up to 5days before release. Services: Also it's a big job to defend all existing all existing services and wallets. Never the less as both chains have value each service and wallet must over time offer some solution even if it is replay protected withdrawal. So nothing is achieved in practice vs proper replay protection other than disruption. Due Care & safety: Doing reckless and risky things to the network may not be a good advertisement for service or wallet. Users will research and make some decision about which wallets and services will preserve their coins and allow them to split and sell or hold whichever of the 3 or 4 spinoffs are created. People will likely not recommend software and services that promote dand advocated for creating the disruption and risk. Financial, support tickets: users will complain via support tickets and formal complaints about experience and asset loss as that happens. Would be interested in proponents views of how their companies (if they have users) will handle this, and also how they suppose different use cases from other services and wallets will interoperate. It sort of feels like there is an expected game-theory reaction here that no one is talking about, but maybe people have different views of what the logical game theory is? ps please trip replies list posts are bouncing as too large. Adam On Sat, Oct 14, 2017 at 2:20 AM, Ben Peters via Bitcoin-segwit2x wrote: > I think there is a fundamental misunderstanding about the nature of the > NYA/Segwit2x endeavour. What is happening here is that an alternative, > minimally modified, version of the Bitcoin code is being developed that will > implement a change that has long been sought by the mining community and > many in industry and beyond (a change that they presumably feel is important > for the future success of Bitcoin and thus their respective investments). > > That candidate code will be offered to the miners and mining pools, who may > or may not opt to apply hashing power to it. If they apply more than the > threshold amount of hashing power, then that new code will effectively > takeover from the previous consensus rule, and take most SPV wallets and > economic activity along with it. > > Rather than lobbying this technical working group to ?call off? their > efforts, your time might be better spent lobbying the miners. The function > of this group is to produce candidate code, thus fulfilling the obligations > as set out under the NYA. > From cedrickperrigo at protonmail.com Sat Oct 14 11:50:56 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 07:50:56 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: Arguing about strong two-way replay protection is a waste of time for Core. People had made clear that won't happen. You'd better spending time thinking about how you would make segwit1x altcoin survive. Talking about financial/support tickets. More would be complaining why the transaction on segwit1x altcoin is not confirmed and why the fee is too high. Exchanges will likely not want to handle this, and drop segwit1x altcoin support all together. That's the simple game theory. Adam, what you didn't get is that all the disruptive part you talked about happens only on the segwit1x altcoin. Segwit2x Bitcoin is not affected. So better spend you time on bitcoin-dev discussing with Blockstream devs on how to hard fork the difficulty algorithm and add replay protection on the segwit1x altcoin. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 14, 2017 7:19 PM > UTC Time: October 14, 2017 11:19 AM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: Ben Peters > Peter Todd via Bitcoin-segwit2x > > A lot of what you described doesn"t work the way you seem to expect. > > There"s a few levels: > > Mining economics: I do some mining, and there are a number of data > points from alt-coins that share mining algorithms: miners short / mid > term mine what is profitable. That is driven by relative price. > Difficulty adjusts to equilibrium. This is a feature, it is the > incentive that secures blockchains. Bitcoin security works by > economically incentivised creation of valid blocks as measured by the > nodes on the network. > > Nodes and wallets mechanically todays software: Existing full nodes > won"t follow. Most smart phone wallets will not automatically switch > but either ignore a new chain, stop functioning, go into some kind of > warning state pending bugfix, some older wallets may get stuck on > random chain. And because there is no proper replay protection > randomly transactions will be made on one or both chains unless mixed > with new coinbase over time. That will be pretty disruptive because > people writing wallet software don"t know what segwit2x code will be > as they keep changing. Bitcoin cash changed up to 5days before > release. > > Services: Also it"s a big job to defend all existing all existing > services and wallets. Never the less as both chains have value each > service and wallet must over time offer some solution even if it is > replay protected withdrawal. So nothing is achieved in practice vs > proper replay protection other than disruption. > > Due Care & safety: Doing reckless and risky things to the network may > not be a good advertisement for service or wallet. Users will > research and make some decision about which wallets and services will > preserve their coins and allow them to split and sell or hold > whichever of the 3 or 4 spinoffs are created. People will likely not > recommend software and services that promote dand advocated for > creating the disruption and risk. > > Financial, support tickets: users will complain via support tickets > and formal complaints about experience and asset loss as that happens. > > Would be interested in proponents views of how their companies (if > they have users) will handle this, and also how they suppose different > use cases from other services and wallets will interoperate. > > It sort of feels like there is an expected game-theory reaction here > that no one is talking about, but maybe people have different views of > what the logical game theory is? > > ps please trip replies list posts are bouncing as too large. > > Adam > > On Sat, Oct 14, 2017 at 2:20 AM, Ben Peters via Bitcoin-segwit2x > wrote: >> I think there is a fundamental misunderstanding about the nature of the >> NYA/Segwit2x endeavour. What is happening here is that an alternative, >> minimally modified, version of the Bitcoin code is being developed that will >> implement a change that has long been sought by the mining community and >> many in industry and beyond (a change that they presumably feel is important >> for the future success of Bitcoin and thus their respective investments). >> >> That candidate code will be offered to the miners and mining pools, who may >> or may not opt to apply hashing power to it. If they apply more than the >> threshold amount of hashing power, then that new code will effectively >> takeover from the previous consensus rule, and take most SPV wallets and >> economic activity along with it. >> >> Rather than lobbying this technical working group to ?call off? their >> efforts, your time might be better spent lobbying the miners. The function >> of this group is to produce candidate code, thus fulfilling the obligations >> as set out under the NYA. >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From wordsgalore at gmail.com Sat Oct 14 12:03:10 2017 From: wordsgalore at gmail.com (Scott Roberts) Date: Sat, 14 Oct 2017 08:03:10 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? Message-ID: > if you think there's more "users" supporting segwit1x altcoin. Show me the proof with their Bitcoin holding amounts. I defined users as "buyers and sellers of goods and services" and as the 99% (as opposed to the 1% hodlers). Probably 1% of the population will always hold 90% of bitcoin. They may start loaning it out at interest to gain an even higher percentage, decreasing the amount of coin in the marketplace even further, further increasing their percent ownership of society without effort. People (users) as workers contributing to society are notorious for not having enough savings, and democracy replaced other systems by protecting them against the 1%, be they lords, rentiers, monopolies, bankers, or hodlers trying to enforce a bitcoin monopoly. Tech is so advanced, the capital of hodling speculators that increased mining infrastructure was not needed except as a marketing tool to get capital the fastest to create the most hashpower. The shift to fees means the coin that pays the highest in total fees will be able to pay the most "protection money". So power will shift from hodlers to users. But meeting the demand of low fees per coin transferred for the users and high total fees for the miners leads to bigger blocks that lose security (if there is only one chain). So let chains flourish to the chagrin of hodlers in order to lower fees per coin transferred, increase security, eliminate the single-chain point of failure, and get closer to the ideal of a constant value currency. To what extent is hodler greed for a monopolistic coin the source of the bickering? (be they SegWit1x, SegWit2x, or both) Does anyone really have future users in mind since it means doing things hodlers will not like? From melvincarvalho at gmail.com Sat Oct 14 12:03:15 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Sat, 14 Oct 2017 14:03:15 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: On 12 October 2017 at 17:50, Jeff Garzik wrote: > Answers inline... > > > > On Oct 12, 2017 6:41 AM, "Melvin Carvalho via Bitcoin-segwit2x" < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > > > On 12 October 2017 at 14:49, Peter BitcoinReminder.com via > Bitcoin-segwit2x wrote: > >> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly >> non-NYA blocks, are you still going to fork off in November - splitting the >> chain intentionally? >> > > This is good new information, thanks! > > > It is information over a month old. See counter. > The information of intent may be over a month old, but the actual signaling is recent, hence why I consider it new information. However, if we were to assume that the information was indeed months old, perhaps the logical thing to do would be to backward adjust the signaling. And perhaps the conclusion to that would be that segwit2x might not have reached the thresholds for activation? > > > A sensible approach might be: > > 1. Allow the implementation of Schnorr signatures > > > Very risky- this impacts tx message integrity and authenticity. Changing > transaction signing code impacts private keys and other security sensitive > surfaces. > > In comparison, changing the size of the message container - a block - does > not impact message integrity and authenticity. > Hi Jeff, thanks for the response. Thanks for raising this. I'd like to reply to these points. So would you be in favour or against the schnorr sig capacity increase. Or be in favour of changing the sequencing. 2x first, then debate schnorr sig? > > 2. In parallel, address the issues raised on the segwit2x codebase > > > Link to the issues filed? > Good point again. Im mainly thinking about the replay protection. > > > 3. Unfreeze the segwit2x code, and seek a dialogue with core on a timeline > for a 2x block size increase > > > All field evidence points to continual delays, never a base block size > increase as has been planned since 2010. > > Repeated attempts at dialogue just result in attacks, delays, The Familiar > Stuff. > It sounds to me like there has been a loss of trust. Typically in working groups (IETF/W3C) there are a broad section of stake holders that meet once a week (telecon) and twice a year (face to face). Not a perfect system, but it does help build trust, or prevent loss. Jeff I think is well regarded by many or most. I remember the early days on irc, when everyone just got on :) As an observer, I do get the impression that people want the same things (increased capacity over time), or at a minimum, that's the rhetoric. We did just have an increase in capacity more are planned. > > > > > The reason being that we've just had a capacity upgrade and segwit is > starting to kick in. Blocks are less congested now. Schnorr will likely > give another 30% capacity quite soon. This will allow general hardware > increases to make moving to 2x blocks, without a contentious hard fork, > more practical. > > > It is extremely contentious to continue blocking a block size increase. > > Continued delay is part of what produced the gridlock that we saw over the > past two years. > I think there's a trade off here, well articulated by Adam Back in his hcpp17 talk last weekend [1]. At one time or other I think most bitcoiners have thought, 'larger blocks, that's a good idea. But it comes with at the cost I think in 3 areas. 1. bitcoin becomes more centralized in that it becomes harder to run a full node. While the incremental value of full nodes diminishes as they go up, it's a trade off to think about. As hardware improves this balance shifts. 2. security the block chain long-term, via proof of work, requires fees. Eventually the block reward will go away. So the idea of zero fees and large blocks has a shelf life, as rewards half. This is a hard problem. We really need to use all our brain power, to solve it together. OK, it might not be urgent for 20 years, but we need to start planning for this. I dont think a 1MB block with high fees is really a practical solution. Larger blocks will have to come, if we stay with proof of work (not a given). 3. it is not practical to put every tx on the block chain. For example, I am working on a fitness project that rewards you for steps taken in a given day. It would be impractical to put every step on the block chain. So it is necessary to build layer 2 technology that aggregates tx, and puts them on the block chain sparingly. That seems like a good way to scale bitcoin to a wider audience. Personally I am highly sympathetic to core, but actually think 2x is a reasonable proposal. There is a certain logic that says the timing is not ideal, when a capacity increase has just been rolled out, and there are more in the pipe. But face it, the way it is being rolled out is impractical, and causes high risk to users, businesses, the eco system and bitcoin itself. And if the market is an indicator, has a high chance of failure. Worse still, it exacerbates the already low level of trust. There has been a lot of acrimony flying around. And anything seen as an attack will obviously be defended against. But I think we should take the attitude of never responding to personal abuse (Ive received some already) and welcoming anyone that wants to make bitcoin better to do so, in spite of past record. Even Jamie Dimon :) tl;dr I think 2MB has to happen at some point if we stick to proof of work, the argument is strong. The argument that now is not the time is also a strong one. IMHO the best thing would be to fight less and talk more. Bitcoin is supposed to be a new way to do finance, we should be using our collective ability to take on the incumbent financial system, which is a huge task, and we have limited time to do that. The best chance is to work together. [1] https://www.youtube.com/watch?v=mmSuxqaKR2U > > > > Just my 2 cents. > > >> >> ? >> [1] https://imgur.com/LgYdFKw >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jli225 at binghamton.edu Sat Oct 14 12:10:50 2017 From: jli225 at binghamton.edu (Junyi Li) Date: Sat, 14 Oct 2017 12:10:50 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: Mr. Adam Back, I appreciate your interest in Bitcoin. However, I am afraid that this may be not the appropriate place to play politics. Double speaking or not, off-topic chat combined with destructive tone only add unnecessary noise. Emil has clearly pointed out some logical fallacies of anti-Bitcoin trolls. Moreover, it will be a bit more moral if the beneficiary of censorship keeps quiet, instead of bragging about the efficiency of censorship. Enjoy the sunshine. Junyi On Sat, Oct 14, 2017 at 04:19 Dr Adam Back via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > A lot of what you described doesn't work the way you seem to expect. > > There's a few levels: > > Mining economics: I do some mining, and there are a number of data > points from alt-coins that share mining algorithms: miners short / mid > term mine what is profitable. That is driven by relative price. > Difficulty adjusts to equilibrium. This is a feature, it is the > incentive that secures blockchains. Bitcoin security works by > economically incentivised creation of valid blocks as measured by the > nodes on the network. > > Nodes and wallets mechanically todays software: Existing full nodes > won't follow. Most smart phone wallets will not automatically switch > but either ignore a new chain, stop functioning, go into some kind of > warning state pending bugfix, some older wallets may get stuck on > random chain. And because there is no proper replay protection > randomly transactions will be made on one or both chains unless mixed > with new coinbase over time. That will be pretty disruptive because > people writing wallet software don't know what segwit2x code will be > as they keep changing. Bitcoin cash changed up to 5days before > release. > > Services: Also it's a big job to defend all existing all existing > services and wallets. Never the less as both chains have value each > service and wallet must over time offer some solution even if it is > replay protected withdrawal. So nothing is achieved in practice vs > proper replay protection other than disruption. > > Due Care & safety: Doing reckless and risky things to the network may > not be a good advertisement for service or wallet. Users will > research and make some decision about which wallets and services will > preserve their coins and allow them to split and sell or hold > whichever of the 3 or 4 spinoffs are created. People will likely not > recommend software and services that promote dand advocated for > creating the disruption and risk. > > Financial, support tickets: users will complain via support tickets > and formal complaints about experience and asset loss as that happens. > > Would be interested in proponents views of how their companies (if > they have users) will handle this, and also how they suppose different > use cases from other services and wallets will interoperate. > > It sort of feels like there is an expected game-theory reaction here > that no one is talking about, but maybe people have different views of > what the logical game theory is? > > ps please trip replies list posts are bouncing as too large. > > Adam > > On Sat, Oct 14, 2017 at 2:20 AM, Ben Peters via Bitcoin-segwit2x > wrote: > > I think there is a fundamental misunderstanding about the nature of the > > NYA/Segwit2x endeavour. What is happening here is that an alternative, > > minimally modified, version of the Bitcoin code is being developed that > will > > implement a change that has long been sought by the mining community and > > many in industry and beyond (a change that they presumably feel is > important > > for the future success of Bitcoin and thus their respective investments). > > > > That candidate code will be offered to the miners and mining pools, who > may > > or may not opt to apply hashing power to it. If they apply more than the > > threshold amount of hashing power, then that new code will effectively > > takeover from the previous consensus rule, and take most SPV wallets and > > economic activity along with it. > > > > Rather than lobbying this technical working group to ?call off? their > > efforts, your time might be better spent lobbying the miners. The > function > > of this group is to produce candidate code, thus fulfilling the > obligations > > as set out under the NYA. > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Sat Oct 14 12:13:36 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 08:13:36 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: <1OZUZjec_r1zNpTPaHkGg5sRMQaBP5wjXp2_-GkGVtHVF9LuyJBFSWgnc8LcEPrwq7kpSHDyBOh-WiGdiZbCQjnpK3YU2CGDfNn2Jkf6-Nw=@protonmail.com> Wow. So "buyers and sellers of goods and services" exclude more than 10,000 merchants in the BitPay network, not counting others? I can use Segwit2x Bitcoin to buy games on Steam, products from Microsoft, goods from OpenBazzar and pay for my VPS. I cannot use segwit1x altcoin to do anything. What kind of delusions do you live in. No matter how long you spend arguing in this mailing list. No proof or data means you are a troll. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 14, 2017 8:03 PM > UTC Time: October 14, 2017 12:03 PM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: bitcoin-segwit2x at lists.linuxfoundation.org > >> if you think there"s more "users" supporting segwit1x altcoin. Show me the proof with their Bitcoin holding amounts. > > I defined users as "buyers and sellers of goods and services" and as > the 99% (as opposed to the 1% hodlers). Probably 1% of the population > will always hold 90% of bitcoin. They may start loaning it out at > interest to gain an even higher percentage, decreasing the amount of > coin in the marketplace even further, further increasing their percent > ownership of society without effort. People (users) as workers > contributing to society are notorious for not having enough savings, > and democracy replaced other systems by protecting them against the > 1%, be they lords, rentiers, monopolies, bankers, or hodlers trying to > enforce a bitcoin monopoly. > > Tech is so advanced, the capital of hodling speculators that increased > mining infrastructure was not needed except as a marketing tool to get > capital the fastest to create the most hashpower. The shift to fees > means the coin that pays the highest in total fees will be able to pay > the most "protection money". So power will shift from hodlers to > users. But meeting the demand of low fees per coin transferred for > the users and high total fees for the miners leads to bigger blocks > that lose security (if there is only one chain). So let chains > flourish to the chagrin of hodlers in order to lower fees per coin > transferred, increase security, eliminate the single-chain point of > failure, and get closer to the ideal of a constant value currency. > > To what extent is hodler greed for a monopolistic coin the source of > the bickering? (be they SegWit1x, SegWit2x, or both) Does anyone > really have future users in mind since it means doing things hodlers > will not like? > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Sat Oct 14 12:19:05 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 08:19:05 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: <20262D13-7947-4F84-BAF5-29509BFE197A@lampesberger.net> References: <1OZUZjec_r1zNpTPaHkGg5sRMQaBP5wjXp2_-GkGVtHVF9LuyJBFSWgnc8LcEPrwq7kpSHDyBOh-WiGdiZbCQjnpK3YU2CGDfNn2Jkf6-Nw=@protonmail.com> <20262D13-7947-4F84-BAF5-29509BFE197A@lampesberger.net> Message-ID: <0WO3QxylX0Dyhk8Mo4WVC1j6xZPjeZCzb5p2wnhBL8lSJpYzIp8NEIkp076q3tkDAwSH5qz3NKtC-8DFt1lyC97n2hCrzww6UsE3Bwtdu1Q=@protonmail.com> What's the minimum hashrate for Core for it to consider segwit1x altcoin a failure? 50%? Has it already failed? Do not use double standards, especially because this is not Core/Blockstream's mailing list. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 14, 2017 8:15 PM > UTC Time: October 14, 2017 12:15 PM > From: office at lampesberger.net > To: Cedrick Perrigo > Scott Roberts , bitcoin-segwit2x at lists.linuxfoundation.org > > Can we please tone down again this discussion? > > I still would like to get an answer what the minimum hashrate do you want to have, before you consider the fork to be delayed? > >> Am 14.10.2017 um 14:13 schrieb Cedrick Perrigo via Bitcoin-segwit2x : >> >> Wow. So "buyers and sellers of goods and services" exclude more than 10,000 merchants in the BitPay network, not counting others? I can use Segwit2x Bitcoin to buy games on Steam, products from Microsoft, goods from OpenBazzar and pay for my VPS. I cannot use segwit1x altcoin to do anything. >> >> What kind of delusions do you live in. >> >> No matter how long you spend arguing in this mailing list. No proof or data means you are a troll. >> >> Sent with [ProtonMail](https://protonmail.com/) Secure Email. >> >>> -------- Original Message -------- >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >>> Local Time: October 14, 2017 8:03 PM >>> UTC Time: October 14, 2017 12:03 PM >>> From: bitcoin-segwit2x at lists.linuxfoundation.org >>> To: bitcoin-segwit2x at lists.linuxfoundation.org >>> >>>> if you think there"s more "users" supporting segwit1x altcoin. Show me the proof with their Bitcoin holding amounts. >>> >>> I defined users as "buyers and sellers of goods and services" and as >>> the 99% (as opposed to the 1% hodlers). Probably 1% of the population >>> will always hold 90% of bitcoin. They may start loaning it out at >>> interest to gain an even higher percentage, decreasing the amount of >>> coin in the marketplace even further, further increasing their percent >>> ownership of society without effort. People (users) as workers >>> contributing to society are notorious for not having enough savings, >>> and democracy replaced other systems by protecting them against the >>> 1%, be they lords, rentiers, monopolies, bankers, or hodlers trying to >>> enforce a bitcoin monopoly. >>> >>> Tech is so advanced, the capital of hodling speculators that increased >>> mining infrastructure was not needed except as a marketing tool to get >>> capital the fastest to create the most hashpower. The shift to fees >>> means the coin that pays the highest in total fees will be able to pay >>> the most "protection money". So power will shift from hodlers to >>> users. But meeting the demand of low fees per coin transferred for >>> the users and high total fees for the miners leads to bigger blocks >>> that lose security (if there is only one chain). So let chains >>> flourish to the chagrin of hodlers in order to lower fees per coin >>> transferred, increase security, eliminate the single-chain point of >>> failure, and get closer to the ideal of a constant value currency. >>> >>> To what extent is hodler greed for a monopolistic coin the source of >>> the bickering? (be they SegWit1x, SegWit2x, or both) Does anyone >>> really have future users in mind since it means doing things hodlers >>> will not like? >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From sysman at bitfury.org Sat Oct 14 12:18:55 2017 From: sysman at bitfury.org (Alex Petrov) Date: Sat, 14 Oct 2017 15:18:55 +0300 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: <17803036-148E-407E-BAA9-2EFE4CF489C8@bitfury.org> 1st hard suggestion keep this discussion technical & less political ! (Cedrick Perrigo - anon person ?) 2nd Jeff all simpler, my IMHO All upgrades should be done in safe way, protecting interests of most users on all version as much as possible. All negative impacts will harm for whole ecosystem & sure price, users trust & doesn't matter separate alt-coins or single-coin. 3rd upgrading existing system, will be always someone who will not upgrade, delay or would like to support their own version, - major role plays "economical" full-nodes who perform operations. - SPV wallets can be fulled/misled by huge amount of non-economical full-nodes with different full-nodes rule.set - miners majority impacting -> trx speed/hashrate & hashrate should be high enough to protect "avg.coin-marketcap-price" from 51% attack - users (coin owners) & biz.team - are free to choice and support any version of chains, if they not harm other chain. - harming other chain, directly, by mistake or by negligence is equal to attacking. same about SPV wallets, using their technical misconceptions for misleading against the will of the owners - is kinda of attacking. different versions is okey, they is team doesn't trust they may create they own community, taking onboard all users who would like to join. all current version improvements may happens only them huge amount of dev/users/biz agree & would like to see it. protocol _compatibility_ should be supported by most nodes, changes should be pre-planed in safe way & and pre-agreed. all network & ecosystem should function stabile as possible in all cases. all instabilities will harm trust of users, business & will 100% impact price. > On Oct 14, 2017, at 10:02, Jeff Garzik via Bitcoin-segwit2x wrote: > > "Strong, two-way replay protection" is poorly defined. > > Segwit2x is an upgrade to bitcoin, not an altcoin. > > It is an explicit design goal that SPV wallets continue working through the fork, following the strongest, most secure chain as they were programmed to do. > > Therefore, any method of replay protection that breaks over 10 million wallets - greatly exacerbating chain splits - is rejected (and this has been communicated repeatedly for months). > > Put simply, we want most wallets to Just Keep Working. Certain types of replay protection break that. > > _____________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -- THIS COMMUNICATION AND ANY ATTACHMENTS MAY CONTAIN CONFIDENTIAL INFORMATION OF THE SENDER. ALL UNAUTHORIZED USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE NOTIFY THE SENDER IMMEDIATELY AND DESTROY ALL COPIES OF THIS COMMUNICATION. THANK YOU. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Sat Oct 14 12:46:37 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 08:46:37 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: <17803036-148E-407E-BAA9-2EFE4CF489C8@bitfury.org> References: <17803036-148E-407E-BAA9-2EFE4CF489C8@bitfury.org> Message-ID: <-5NDMVoWCV--vFS_cwx46Geq2F6U70yh2wxPAfPPpdZ2VI5FialXJWI_kNIet4yj-isZPMIR5AGyhQQoCrXfP5SsO-dblDPoS3Q44VcpXPE=@protonmail.com> There's solid proof that Blockstream's segwit1x altcoin is harming and attacking segwit2x Bitcoin. What happening right now is the proof. Segwit2x Bitcoin is not in any way harming segwit1x altcoin. Miners quitting an altcoin is just normal dynamics. Plus segwit1x Blockstream people has stated that miners do not matter. If Blockstream trolls don't stop on this mailing list. You'll see more and more "anon person" like me. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 14, 2017 8:18 PM > UTC Time: October 14, 2017 12:18 PM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: Jeff Garzik > Peter Todd via Bitcoin-segwit2x > > 1st hard suggestion keep this discussion technical & less political ! (Cedrick Perrigo - anon person ?) > > 2nd Jeff all simpler, my IMHO > All upgrades should be done in safe way, protecting interests of most users on all version as much as possible. > All negative impacts will harm for whole ecosystem & sure price, users trust & doesn't matter separate alt-coins or single-coin. > > 3rd upgrading existing system, will be always someone who will not upgrade, delay or would like to support their own version, > - major role plays "economical" full-nodes who perform operations. > - SPV wallets can be fulled/misled by huge amount of non-economical full-nodes with different full-nodes rule.set > - miners majority impacting -> trx speed/hashrate > & hashrate should be high enough to protect "avg.coin-marketcap-price" from 51% attack > - users (coin owners) & biz.team - are free to choice and support any version of chains, if they not harm other chain. > > - harming other chain, directly, by mistake or by negligence is equal to attacking. > same about SPV wallets, using their technical misconceptions for misleading against the will of the owners - is kinda of attacking. > > different versions is okey, they is team doesn't trust they may create they own community, taking onboard all users who would like to join. > all current version improvements may happens only them huge amount of dev/users/biz agree & would like to see it. > protocol _compatibility_ should be supported by most nodes, changes should be pre-planed in safe way & and pre-agreed. > > all network & ecosystem should function stabile as possible in all cases. > all instabilities will harm trust of users, business & will 100% impact price. > >> On Oct 14, 2017, at 10:02, Jeff Garzik via Bitcoin-segwit2x wrote: >> >> "Strong, two-way replay protection" is poorly defined. >> >> Segwit2x is an upgrade to bitcoin, not an altcoin. >> >> It is an explicit design goal that SPV wallets continue working through the fork, following the strongest, most secure chain as they were programmed to do. >> >> Therefore, any method of replay protection that breaks over 10 million wallets - greatly exacerbating chain splits - is rejected (and this has been communicated repeatedly for months). >> >> Put simply, we want most wallets to Just Keep Working. Certain types of replay protection break that. >> >>> _____________________________________________ >> >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- THIS COMMUNICATION AND ANY ATTACHMENTS MAY CONTAIN CONFIDENTIAL INFORMATION OF THE SENDER. ALL UNAUTHORIZED USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE NOTIFY THE SENDER IMMEDIATELY AND DESTROY ALL COPIES OF THIS COMMUNICATION. THANK YOU. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wordsgalore at gmail.com Sat Oct 14 12:55:30 2017 From: wordsgalore at gmail.com (Scott Roberts) Date: Sat, 14 Oct 2017 08:55:30 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: <20262D13-7947-4F84-BAF5-29509BFE197A@lampesberger.net> References: <1OZUZjec_r1zNpTPaHkGg5sRMQaBP5wjXp2_-GkGVtHVF9LuyJBFSWgnc8LcEPrwq7kpSHDyBOh-WiGdiZbCQjnpK3YU2CGDfNn2Jkf6-Nw=@protonmail.com> <20262D13-7947-4F84-BAF5-29509BFE197A@lampesberger.net> Message-ID: > So "buyers and sellers of goods and services" exclude more than 10,000 merchants [...]? Not if the merchants are not hodlers. Hodler or not, they are aligned with users wanting low fees, which is good. I derided them because history indicates letting big companies decide what is best for their customers when influencing law is not exactly a good idea. It's setting a bad precedence. The medical, pharmaceutical, and medical-insurance lobbies dwarf the other lobbies which has had disastrous consequences in the U.S. I am not for or against 1x or 2x. I'm against ugly difficulty algorithms. From cedrickperrigo at protonmail.com Sat Oct 14 13:02:35 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 09:02:35 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <1OZUZjec_r1zNpTPaHkGg5sRMQaBP5wjXp2_-GkGVtHVF9LuyJBFSWgnc8LcEPrwq7kpSHDyBOh-WiGdiZbCQjnpK3YU2CGDfNn2Jkf6-Nw=@protonmail.com> <20262D13-7947-4F84-BAF5-29509BFE197A@lampesberger.net> Message-ID: Hodlers or not, let's put it aside. But they're as you defined, users -- "buyers and sellers of goods and services". Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 14, 2017 8:55 PM > UTC Time: October 14, 2017 12:55 PM > From: wordsgalore at gmail.com > To: Peter Lampesberger > Cedrick Perrigo , bitcoin-segwit2x at lists.linuxfoundation.org > >> So "buyers and sellers of goods and services" exclude more than 10,000 merchants [...]? > > Not if the merchants are not hodlers. Hodler or not, they are aligned > with users wanting low fees, which is good. I derided them because > history indicates letting big companies decide what is best for their > customers when influencing law is not exactly a good idea. It"s > setting a bad precedence. The medical, pharmaceutical, and > medical-insurance lobbies dwarf the other lobbies which has had > disastrous consequences in the U.S. > > I am not for or against 1x or 2x. I"m against ugly difficulty algorithms. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wordsgalore at gmail.com Sat Oct 14 13:23:57 2017 From: wordsgalore at gmail.com (Scott Roberts) Date: Sat, 14 Oct 2017 09:23:57 -0400 Subject: [Bitcoin-segwit2x] We are all bitcoin Message-ID: There's a debate about how to define bitcoin. Let SegWit and SegWit2x destroy each other. The alts will rise. It's an insult to both the alts and bitcoin to say they are not bitcoin. For what reason or theoretical foundation do people want one God to rule them all? To hell with the dollar. To hell with a single bitcoin. Only constant value is the ideal coin, and that seems possible only with competing currencies. From sysman at bitfury.org Sat Oct 14 13:24:09 2017 From: sysman at bitfury.org (Alex Petrov) Date: Sat, 14 Oct 2017 16:24:09 +0300 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: <-5NDMVoWCV--vFS_cwx46Geq2F6U70yh2wxPAfPPpdZ2VI5FialXJWI_kNIet4yj-isZPMIR5AGyhQQoCrXfP5SsO-dblDPoS3Q44VcpXPE=@protonmail.com> References: <17803036-148E-407E-BAA9-2EFE4CF489C8@bitfury.org> <-5NDMVoWCV--vFS_cwx46Geq2F6U70yh2wxPAfPPpdZ2VI5FialXJWI_kNIet4yj-isZPMIR5AGyhQQoCrXfP5SsO-dblDPoS3Q44VcpXPE=@protonmail.com> Message-ID: Cederick - huge network can not be upgraded fast, and definitely can not attack new version developed in short time. current network uses prev.version with all prior versions + huge amount of nodes/users/spv who react slowly, it thousands of businesses/customers who can not upgrade fast their applications, hardware, or deploy to millions of mobile clients even in week/3-4months... I think even is split if not planed, any S2X/BTC1/ABC1/GOLD/CORE - all should keep in mind all risks, and prevent all kind of risks. for huge networks reaction is longer, shorter network/team/community should implement protection to avoid harmful effects, otherwise it may be counted as huge/same-size network attack, and them attackers should realize & take full responsibility of all consequences for all networks, exploding the trust for technology by itself. > On Oct 14, 2017, at 15:46, Cedrick Perrigo wrote: > > There's solid proof that Blockstream's segwit1x altcoin is harming and attacking segwit2x Bitcoin. What happening right now is the proof. > > Segwit2x Bitcoin is not in any way harming segwit1x altcoin. Miners quitting an altcoin is just normal dynamics. Plus segwit1x Blockstream people has stated that miners do not matter. > > If Blockstream trolls don't stop on this mailing list. You'll see more and more "anon person" like me. > > > Sent with ProtonMail Secure Email. > >> -------- Original Message -------- >> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >> Local Time: October 14, 2017 8:18 PM >> UTC Time: October 14, 2017 12:18 PM >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> To: Jeff Garzik >> Peter Todd via Bitcoin-segwit2x >> >> 1st hard suggestion keep this discussion technical & less political ! (Cedrick Perrigo - anon person ?) >> >> 2nd Jeff all simpler, my IMHO >> All upgrades should be done in safe way, protecting interests of most users on all version as much as possible. >> All negative impacts will harm for whole ecosystem & sure price, users trust & doesn't matter separate alt-coins or single-coin. >> >> 3rd upgrading existing system, will be always someone who will not upgrade, delay or would like to support their own version, >> - major role plays "economical" full-nodes who perform operations. >> - SPV wallets can be fulled/misled by huge amount of non-economical full-nodes with different full-nodes rule.set >> - miners majority impacting -> trx speed/hashrate >> & hashrate should be high enough to protect "avg.coin-marketcap-price" from 51% attack >> - users (coin owners) & biz.team - are free to choice and support any version of chains, if they not harm other chain. >> >> - harming other chain, directly, by mistake or by negligence is equal to attacking. >> same about SPV wallets, using their technical misconceptions for misleading against the will of the owners - is kinda of attacking. >> >> different versions is okey, they is team doesn't trust they may create they own community, taking onboard all users who would like to join. >> all current version improvements may happens only them huge amount of dev/users/biz agree & would like to see it. >> protocol _compatibility_ should be supported by most nodes, changes should be pre-planed in safe way & and pre-agreed. >> >> all network & ecosystem should function stabile as possible in all cases. >> all instabilities will harm trust of users, business & will 100% impact price. >> >> >>> On Oct 14, 2017, at 10:02, Jeff Garzik via Bitcoin-segwit2x > wrote: >>> >>> "Strong, two-way replay protection" is poorly defined. >>> >>> Segwit2x is an upgrade to bitcoin, not an altcoin. >>> >>> It is an explicit design goal that SPV wallets continue working through the fork, following the strongest, most secure chain as they were programmed to do. >>> >>> Therefore, any method of replay protection that breaks over 10 million wallets - greatly exacerbating chain splits - is rejected (and this has been communicated repeatedly for months). >>> >>> Put simply, we want most wallets to Just Keep Working. Certain types of replay protection break that. >>> >>> _____________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> -- THIS COMMUNICATION AND ANY ATTACHMENTS MAY CONTAIN CONFIDENTIAL INFORMATION OF THE SENDER. ALL UNAUTHORIZED USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE NOTIFY THE SENDER IMMEDIATELY AND DESTROY ALL COPIES OF THIS COMMUNICATION. THANK YOU. > -- THIS COMMUNICATION AND ANY ATTACHMENTS MAY CONTAIN CONFIDENTIAL INFORMATION OF THE SENDER. ALL UNAUTHORIZED USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE NOTIFY THE SENDER IMMEDIATELY AND DESTROY ALL COPIES OF THIS COMMUNICATION. THANK YOU. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Sat Oct 14 13:39:04 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Sat, 14 Oct 2017 13:39:04 +0000 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <17803036-148E-407E-BAA9-2EFE4CF489C8@bitfury.org> <-5NDMVoWCV--vFS_cwx46Geq2F6U70yh2wxPAfPPpdZ2VI5FialXJWI_kNIet4yj-isZPMIR5AGyhQQoCrXfP5SsO-dblDPoS3Q44VcpXPE=@protonmail.com>, Message-ID: The definition of an upgrade as spouted by core clearly does not cut the mustard here, so please bear that in mind when making the fallacious claim that ?a huge network can not be upgraded fast?. Once you take that on-board, you?ll be the first to acknowledge that most of your other ?points? of contention / interpretation are baseless. Now unless you?d want to continue wasting your time (like those still ?demanding? strong 2 way RP that breaks SPV?s when it has been made patently clear that?ll not be sanctioned) knowing pretty well that there are irreconcilable conceptual differences in the interpretation of both technical and economic points, then do it somewhere else. From: Alex Petrov via Bitcoin-segwit2x Sent: 14 October 2017 14:24 To: Cedrick Perrigo Cc: Peter Todd via Bitcoin-segwit2x Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? Cederick - huge network can not be upgraded fast, and definitely can not attack new version developed in short time. current network uses prev.version with all prior versions + huge amount of nodes/users/spv who react slowly, it thousands of businesses/customers who can not upgrade fast their applications, hardware, or deploy to millions of mobile clients even in week/3-4months... I think even is split if not planed, any S2X/BTC1/ABC1/GOLD/CORE - all should keep in mind all risks, and prevent all kind of risks. for huge networks reaction is longer, shorter network/team/community should implement protection to avoid harmful effects, otherwise it may be counted as huge/same-size network attack, and them attackers should realize & take full responsibility of all consequences for all networks, exploding the trust for technology by itself. On Oct 14, 2017, at 15:46, Cedrick Perrigo > wrote: There's solid proof that Blockstream's segwit1x altcoin is harming and attacking segwit2x Bitcoin. What happening right now is the proof. Segwit2x Bitcoin is not in any way harming segwit1x altcoin. Miners quitting an altcoin is just normal dynamics. Plus segwit1x Blockstream people has stated that miners do not matter. If Blockstream trolls don't stop on this mailing list. You'll see more and more "anon person" like me. Sent with ProtonMail Secure Email. -------- Original Message -------- Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? Local Time: October 14, 2017 8:18 PM UTC Time: October 14, 2017 12:18 PM From: bitcoin-segwit2x at lists.linuxfoundation.org To: Jeff Garzik > Peter Todd via Bitcoin-segwit2x > 1st hard suggestion keep this discussion technical & less political ! (Cedrick Perrigo - anon person ?) 2nd Jeff all simpler, my IMHO All upgrades should be done in safe way, protecting interests of most users on all version as much as possible. All negative impacts will harm for whole ecosystem & sure price, users trust & doesn't matter separate alt-coins or single-coin. 3rd upgrading existing system, will be always someone who will not upgrade, delay or would like to support their own version, - major role plays "economical" full-nodes who perform operations. - SPV wallets can be fulled/misled by huge amount of non-economical full-nodes with different full-nodes rule.set - miners majority impacting -> trx speed/hashrate & hashrate should be high enough to protect "avg.coin-marketcap-price" from 51% attack - users (coin owners) & biz.team - are free to choice and support any version of chains, if they not harm other chain. - harming other chain, directly, by mistake or by negligence is equal to attacking. same about SPV wallets, using their technical misconceptions for misleading against the will of the owners - is kinda of attacking. different versions is okey, they is team doesn't trust they may create they own community, taking onboard all users who would like to join. all current version improvements may happens only them huge amount of dev/users/biz agree & would like to see it. protocol _compatibility_ should be supported by most nodes, changes should be pre-planed in safe way & and pre-agreed. all network & ecosystem should function stabile as possible in all cases. all instabilities will harm trust of users, business & will 100% impact price. On Oct 14, 2017, at 10:02, Jeff Garzik via Bitcoin-segwit2x > wrote: "Strong, two-way replay protection" is poorly defined. Segwit2x is an upgrade to bitcoin, not an altcoin. It is an explicit design goal that SPV wallets continue working through the fork, following the strongest, most secure chain as they were programmed to do. Therefore, any method of replay protection that breaks over 10 million wallets - greatly exacerbating chain splits - is rejected (and this has been communicated repeatedly for months). Put simply, we want most wallets to Just Keep Working. Certain types of replay protection break that. _____________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -- THIS COMMUNICATION AND ANY ATTACHMENTS MAY CONTAIN CONFIDENTIAL INFORMATION OF THE SENDER. ALL UNAUTHORIZED USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE NOTIFY THE SENDER IMMEDIATELY AND DESTROY ALL COPIES OF THIS COMMUNICATION. THANK YOU. -- THIS COMMUNICATION AND ANY ATTACHMENTS MAY CONTAIN CONFIDENTIAL INFORMATION OF THE SENDER. ALL UNAUTHORIZED USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE NOTIFY THE SENDER IMMEDIATELY AND DESTROY ALL COPIES OF THIS COMMUNICATION. THANK YOU. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Sat Oct 14 14:08:48 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 10:08:48 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <17803036-148E-407E-BAA9-2EFE4CF489C8@bitfury.org> <-5NDMVoWCV--vFS_cwx46Geq2F6U70yh2wxPAfPPpdZ2VI5FialXJWI_kNIet4yj-isZPMIR5AGyhQQoCrXfP5SsO-dblDPoS3Q44VcpXPE=@protonmail.com> Message-ID: <3WzCzIWwpA5w4kPb9jhZzUYmcqZjrOKeYPVjtvWEd-ZyCzCRQ1S3jY6h3H5DnfH_0K8eg75S85JUwcz20dWlPui8daUbayo9QOJVbm_lVZc=@protonmail.com> There is no way you can justify it's be "upgraded fast". 2X has been at least on the discussion for 2 years. NYA is a continuation of HKA, which Core also joined, but failed to deliver its plan. I would say that around July before segwit2x is enforced, Blockstream has done a masterpiece of trolling that makes miners, businesses and users feel that they also agreed on the 2X part. Only starting from October Blockstream started this massive campaign of trolling of RP. This is such a short notice and thus Blockstream/Core is qualified as the "attacker", and should take full responsibility of all its consequences. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 14, 2017 9:24 PM > UTC Time: October 14, 2017 1:24 PM > From: sysman at bitfury.org > To: Cedrick Perrigo > Jeff Garzik , Peter Todd via Bitcoin-segwit2x > > Cederick > > - huge network can not be upgraded fast, and definitely can not attack new version developed in short time. > current network uses prev.version with all prior versions + huge amount of nodes/users/spv who react slowly, > it thousands of businesses/customers who can not upgrade fast their applications, hardware, or deploy to millions of mobile clients even in week/3-4months... > > I think even is split if not planed, any S2X/BTC1/ABC1/GOLD/CORE - all should keep in mind all risks, and prevent all kind of risks. > for huge networks reaction is longer, shorter network/team/community should implement protection to avoid harmful effects, > otherwise it may be counted as huge/same-size network attack, and them attackers should realize & take full responsibility of all consequences for all networks, > exploding the trust for technology by itself. > >> On Oct 14, 2017, at 15:46, Cedrick Perrigo wrote: >> >> There's solid proof that Blockstream's segwit1x altcoin is harming and attacking segwit2x Bitcoin. What happening right now is the proof. >> >> Segwit2x Bitcoin is not in any way harming segwit1x altcoin. Miners quitting an altcoin is just normal dynamics. Plus segwit1x Blockstream people has stated that miners do not matter. >> >> If Blockstream trolls don't stop on this mailing list. You'll see more and more "anon person" like me. >> >> Sent with [ProtonMail](https://protonmail.com/) Secure Email. >> >>> -------- Original Message -------- >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >>> Local Time: October 14, 2017 8:18 PM >>> UTC Time: October 14, 2017 12:18 PM >>> From: bitcoin-segwit2x at lists.linuxfoundation.org >>> To: Jeff Garzik >>> Peter Todd via Bitcoin-segwit2x >>> >>> 1st hard suggestion keep this discussion technical & less political ! (Cedrick Perrigo - anon person ?) >>> >>> 2nd Jeff all simpler, my IMHO >>> All upgrades should be done in safe way, protecting interests of most users on all version as much as possible. >>> All negative impacts will harm for whole ecosystem & sure price, users trust & doesn't matter separate alt-coins or single-coin. >>> >>> 3rd upgrading existing system, will be always someone who will not upgrade, delay or would like to support their own version, >>> - major role plays "economical" full-nodes who perform operations. >>> - SPV wallets can be fulled/misled by huge amount of non-economical full-nodes with different full-nodes rule.set >>> - miners majority impacting -> trx speed/hashrate >>> & hashrate should be high enough to protect "avg.coin-marketcap-price" from 51% attack >>> - users (coin owners) & biz.team - are free to choice and support any version of chains, if they not harm other chain. >>> >>> - harming other chain, directly, by mistake or by negligence is equal to attacking. >>> same about SPV wallets, using their technical misconceptions for misleading against the will of the owners - is kinda of attacking. >>> >>> different versions is okey, they is team doesn't trust they may create they own community, taking onboard all users who would like to join. >>> all current version improvements may happens only them huge amount of dev/users/biz agree & would like to see it. >>> protocol _compatibility_ should be supported by most nodes, changes should be pre-planed in safe way & and pre-agreed. >>> >>> all network & ecosystem should function stabile as possible in all cases. >>> all instabilities will harm trust of users, business & will 100% impact price. >>> >>>> On Oct 14, 2017, at 10:02, Jeff Garzik via Bitcoin-segwit2x wrote: >>>> >>>> "Strong, two-way replay protection" is poorly defined. >>>> >>>> Segwit2x is an upgrade to bitcoin, not an altcoin. >>>> >>>> It is an explicit design goal that SPV wallets continue working through the fork, following the strongest, most secure chain as they were programmed to do. >>>> >>>> Therefore, any method of replay protection that breaks over 10 million wallets - greatly exacerbating chain splits - is rejected (and this has been communicated repeatedly for months). >>>> >>>> Put simply, we want most wallets to Just Keep Working. Certain types of replay protection break that. >>>> >>>>> _____________________________________________ >>>> >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> -- THIS COMMUNICATION AND ANY ATTACHMENTS MAY CONTAIN CONFIDENTIAL INFORMATION OF THE SENDER. ALL UNAUTHORIZED USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE NOTIFY THE SENDER IMMEDIATELY AND DESTROY ALL COPIES OF THIS COMMUNICATION. THANK YOU. > > -- THIS COMMUNICATION AND ANY ATTACHMENTS MAY CONTAIN CONFIDENTIAL INFORMATION OF THE SENDER. ALL UNAUTHORIZED USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE NOTIFY THE SENDER IMMEDIATELY AND DESTROY ALL COPIES OF THIS COMMUNICATION. THANK YOU. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wordsgalore at gmail.com Sat Oct 14 14:14:42 2017 From: wordsgalore at gmail.com (Scott Roberts) Date: Sat, 14 Oct 2017 10:14:42 -0400 Subject: [Bitcoin-segwit2x] We are all bitcoin Message-ID: I apologize for my previous post. I just learned more about SegWit2x and saw the twitter polls saying SegWit2x is not being defined by the vast majority of people as "bitcoin". Majority usage is the definition of a word. I recommend SegWit2x advocates stop calling it "bitcoin" without qualification because it is trolling for disruptions to their mailing list. BTW Adam Back's response was in no way trolling or disruptive or off-topic like others were saying. From pekatete at hotmail.com Sat Oct 14 14:20:15 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Sat, 14 Oct 2017 14:20:15 +0000 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. Basing any analysis on what are effectively straw polls in a bubble will not yield any useful insights. You?ll also do well reading the whitepaper (I suggest doing it with a clear mind, so a good rest beforehand would do you no harm). From: Scott Roberts via Bitcoin-segwit2x Sent: 14 October 2017 15:14 To: bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] We are all bitcoin I apologize for my previous post. I just learned more about SegWit2x and saw the twitter polls saying SegWit2x is not being defined by the vast majority of people as "bitcoin". Majority usage is the definition of a word. I recommend SegWit2x advocates stop calling it "bitcoin" without qualification because it is trolling for disruptions to their mailing list. BTW Adam Back's response was in no way trolling or disruptive or off-topic like others were saying. _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7Cd6ee2d3fb48248ab8ace08d5130df033%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435872934798227&sdata=r6xZTh2lsvyiSdG4rPzVZJfUwnOV6sikWfj4k0zdWHM%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wordsgalore at gmail.com Sat Oct 14 14:24:57 2017 From: wordsgalore at gmail.com (Scott Roberts) Date: Sat, 14 Oct 2017 10:24:57 -0400 Subject: [Bitcoin-segwit2x] We are all bitcoin Message-ID: > I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. 1,168 with 30x difference in responses is very significant. Show me the twitter bubble where like-minded SegWit2x supporters show their support. From segwit2x_mailinglist at bitcoinreminder.com Sat Oct 14 14:26:42 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Sat, 14 Oct 2017 16:26:42 +0200 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: Scott, maybe also check out: https://en.bitcoin.it/wiki/Segwit_support and see which core developer / contributors are supporting b2x (spoiler: none). So you are probably right, that the newspeak that segwit2x IS bitcoin, is not as true as some mailing list members here want to it to be. > Am 14.10.2017 um 16:20 schrieb Phillip Katete via Bitcoin-segwit2x : > > I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. Basing any analysis on what are effectively straw polls in a bubble will not yield any useful insights. > > You?ll also do well reading the whitepaper (I suggest doing it with a clear mind, so a good rest beforehand would do you no harm). > > From: Scott Roberts via Bitcoin-segwit2x > Sent: 14 October 2017 15:14 > To: bitcoin-segwit2x at lists.linuxfoundation.org > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > > I apologize for my previous post. I just learned more about SegWit2x > and saw the twitter polls saying SegWit2x is not being defined by the > vast majority of people as "bitcoin". Majority usage is the definition > of a word. I recommend SegWit2x advocates stop calling it "bitcoin" > without qualification because it is trolling for disruptions to their > mailing list. BTW Adam Back's response was in no way trolling or > disruptive or off-topic like others were saying. > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7Cd6ee2d3fb48248ab8ace08d5130df033%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435872934798227&sdata=r6xZTh2lsvyiSdG4rPzVZJfUwnOV6sikWfj4k0zdWHM%3D&reserved=0 > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Sat Oct 14 14:27:22 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Sat, 14 Oct 2017 14:27:22 +0000 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: , Message-ID: At the risk of fanning off-topic discussion on a technical list, may I point out that SegWit2x is an upgrade to the bitcoin consensus rules. At and after the Nov HF, the upgraded chain shall be bitcoin, that is not in dispute. Also, core devs are NOT bitcoin. From: Peter Lampesberger Sent: 14 October 2017 15:23 To: Phillip Katete Cc: Scott Roberts; bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] We are all bitcoin Scott, maybe also check out: https://en.bitcoin.it/wiki/Segwit_support and see which core developer / contributors are supporting b2x (spoiler: none). So you are probably right, that the newspeak that segwit2x IS bitcoin, is not as true as some mailing list members here wants to it to be. Am 14.10.2017 um 16:20 schrieb Phillip Katete via Bitcoin-segwit2x >: I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. Basing any analysis on what are effectively straw polls in a bubble will not yield any useful insights. You?ll also do well reading the whitepaper (I suggest doing it with a clear mind, so a good rest beforehand would do you no harm). From: Scott Roberts via Bitcoin-segwit2x Sent: 14 October 2017 15:14 To: bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] We are all bitcoin I apologize for my previous post. I just learned more about SegWit2x and saw the twitter polls saying SegWit2x is not being defined by the vast majority of people as "bitcoin". Majority usage is the definition of a word. I recommend SegWit2x advocates stop calling it "bitcoin" without qualification because it is trolling for disruptions to their mailing list. BTW Adam Back's response was in no way trolling or disruptive or off-topic like others were saying. _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7Cd6ee2d3fb48248ab8ace08d5130df033%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435872934798227&sdata=r6xZTh2lsvyiSdG4rPzVZJfUwnOV6sikWfj4k0zdWHM%3D&reserved=0 _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Sat Oct 14 14:32:05 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Sat, 14 Oct 2017 14:32:05 +0000 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: In the grand scheme of things, 1,168 responders is not exactly representative of the bitcoin community, is it? But that number, for a sample size, falls in the range of what is referred to as statistically irrelevant. It seems like you?ll have to do even more reading up! From: Scott Roberts via Bitcoin-segwit2x Sent: 14 October 2017 15:25 To: bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. 1,168 with 30x difference in responses is very significant. Show me the twitter bubble where like-minded SegWit2x supporters show their support. _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Sat Oct 14 14:44:26 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 10:44:26 -0400 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: In the grand scheme of things, 10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of miners do not count but you only count a tiny thousand people on a Twitter poll. How funny this is. If you actually look into Twitter, there are only around a thousand people who has the "no2x" tag. Not all of them are trolling. However, people who state that those are everything that counts, especially on a segwit2x mailing list, is certainly trolling and does not worth any people's attention. Bitcoin will be what majority calls it. Period. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > Local Time: October 14, 2017 10:32 PM > UTC Time: October 14, 2017 2:32 PM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: Scott Roberts , bitcoin-segwit2x at lists.linuxfoundation.org > > In the grand scheme of things, 1,168 responders is not exactly representative of the bitcoin community, is it? But that number, for a sample size, falls in the range of what is referred to as statistically irrelevant. It seems like you?ll have to do even more reading up! > > From: [Scott Roberts via Bitcoin-segwit2x](mailto:bitcoin-segwit2x at lists.linuxfoundation.org) > Sent: 14 October 2017 15:25 > To: bitcoin-segwit2x at lists.linuxfoundation.org > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > >> I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. > > 1,168 with 30x difference in responses is very significant. Show me > the twitter bubble where like-minded SegWit2x supporters show their > support. > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Sat Oct 14 14:46:51 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 10:46:51 -0400 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: Segwit2x people are not hostile trollers like you. No silly Twitter polls created from segwit2x people and the general welcome atmosphere on this mailing list shows this. They want better Bitcoin, but not some silly Blockstream propaganda battle. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > Local Time: October 14, 2017 10:44 PM > UTC Time: October 14, 2017 2:44 PM > From: cedrickperrigo at protonmail.com > To: Phillip Katete > Scott Roberts , bitcoin-segwit2x at lists.linuxfoundation.org > > In the grand scheme of things, 10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of miners do not count but you only count a tiny thousand people on a Twitter poll. How funny this is. > > If you actually look into Twitter, there are only around a thousand people who has the "no2x" tag. Not all of them are trolling. However, people who state that those are everything that counts, especially on a segwit2x mailing list, is certainly trolling and does not worth any people's attention. > > Bitcoin will be what majority calls it. Period. > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > >> -------- Original Message -------- >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> Local Time: October 14, 2017 10:32 PM >> UTC Time: October 14, 2017 2:32 PM >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> To: Scott Roberts , bitcoin-segwit2x at lists.linuxfoundation.org >> >> In the grand scheme of things, 1,168 responders is not exactly representative of the bitcoin community, is it? But that number, for a sample size, falls in the range of what is referred to as statistically irrelevant. It seems like you?ll have to do even more reading up! >> >> From: [Scott Roberts via Bitcoin-segwit2x](mailto:bitcoin-segwit2x at lists.linuxfoundation.org) >> Sent: 14 October 2017 15:25 >> To: bitcoin-segwit2x at lists.linuxfoundation.org >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >>> I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. >> >> 1,168 with 30x difference in responses is very significant. Show me >> the twitter bubble where like-minded SegWit2x supporters show their >> support. >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From segwit2x_mailinglist at bitcoinreminder.com Sat Oct 14 14:48:19 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Sat, 14 Oct 2017 16:48:19 +0200 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: It?s funny how you imply that "10,000 merchants of BitPay, millions of users of Blockchain.info , Bitcoin.com , Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? The only sybill resistant poll which I know (even created by data of users from Coinbase!!!) shows that most of the coinbase customers are not in favour of b2x? https://luke.dashjr.org/programs/kycpoll/answers.php This link was twittered on /r/bitcoin, /r/btc and reweeted also by many B2X proponents. So please, show me some data how these "10,000 merchants of BitPay, millions of users of Blockchain.info , Bitcoin.com , Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? > Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x : > > In the grand scheme of things, 10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of miners do not count but you only count a tiny thousand people on a Twitter poll. How funny this is. > > If you actually look into Twitter, there are only around a thousand people who has the "no2x" tag. Not all of them are trolling. However, people who state that those are everything that counts, especially on a segwit2x mailing list, is certainly trolling and does not worth any people's attention. > > Bitcoin will be what majority calls it. Period. > > > Sent with ProtonMail Secure Email. > >> -------- Original Message -------- >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> Local Time: October 14, 2017 10:32 PM >> UTC Time: October 14, 2017 2:32 PM >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> To: Scott Roberts , bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> In the grand scheme of things, 1,168 responders is not exactly representative of the bitcoin community, is it? But that number, for a sample size, falls in the range of what is referred to as statistically irrelevant. It seems like you?ll have to do even more reading up! >> >> >> >> >> From: Scott Roberts via Bitcoin-segwit2x >> Sent: 14 October 2017 15:25 >> To: bitcoin-segwit2x at lists.linuxfoundation.org >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> > I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. >> >> >> 1,168 with 30x difference in responses is very significant. Show me >> the twitter bubble where like-minded SegWit2x supporters show their >> support. >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From wordsgalore at gmail.com Sat Oct 14 14:58:07 2017 From: wordsgalore at gmail.com (Scott Roberts) Date: Sat, 14 Oct 2017 10:58:07 -0400 Subject: [Bitcoin-segwit2x] Satoshi Nakamoto said... Message-ID: August 15, 2015: The developers of this [XT] pretender-Bitcoin claim to be following my original vision, but nothing could be further from the truth. When I designed Bitcoin, I designed it in such a way as to make future modifications to the consensus rules difficult without near unanimous agreement. .... Nearly everyone has to agree on a change, and they have to do it without being forced or pressured into it. By doing a fork in this way, these developers are violating the "original vision" they claim to honour. Satoshi Nakamoto From pekatete at hotmail.com Sat Oct 14 15:00:17 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Sat, 14 Oct 2017 15:00:17 +0000 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: , Message-ID: I did refer you to read the whitepaper ? obviously I do not expect you to have read it by now, but I?ll just mention this now anyway. The most relevant Sybil resistant poll you are ever likely to come across is right in front of your eyes, aka the bitcoin blockchain. Now when you get that time to read the whitepaper, you?ll learn that the consensus mechanism of the bitcoin network is 1CPU 1 vote, aka hashpower. Once you take that on-board, then it?ll dawn on you that the rest of your musings are simply, for lack of a better word, pointless. From: Peter BitcoinReminder.com Sent: 14 October 2017 15:48 To: Cedrick Perrigo Cc: Phillip Katete; bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] We are all bitcoin It?s funny how you imply that "10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? The only sybill resistant poll which I know (even created by data of users from Coinbase!!!) shows that most of the coinbase customers are not in favour of b2x? https://luke.dashjr.org/programs/kycpoll/answers.php This link was twittered on /r/bitcoin, /r/btc and reweeted also by many B2X proponents. So please, show me some data how these "10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x >: In the grand scheme of things, 10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of miners do not count but you only count a tiny thousand people on a Twitter poll. How funny this is. If you actually look into Twitter, there are only around a thousand people who has the "no2x" tag. Not all of them are trolling. However, people who state that those are everything that counts, especially on a segwit2x mailing list, is certainly trolling and does not worth any people's attention. Bitcoin will be what majority calls it. Period. Sent with ProtonMail Secure Email. -------- Original Message -------- Subject: Re: [Bitcoin-segwit2x] We are all bitcoin Local Time: October 14, 2017 10:32 PM UTC Time: October 14, 2017 2:32 PM From: bitcoin-segwit2x at lists.linuxfoundation.org To: Scott Roberts >, bitcoin-segwit2x at lists.linuxfoundation.org > In the grand scheme of things, 1,168 responders is not exactly representative of the bitcoin community, is it? But that number, for a sample size, falls in the range of what is referred to as statistically irrelevant. It seems like you?ll have to do even more reading up! From: Scott Roberts via Bitcoin-segwit2x Sent: 14 October 2017 15:25 To: bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. 1,168 with 30x difference in responses is very significant. Show me the twitter bubble where like-minded SegWit2x supporters show their support. _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Sat Oct 14 15:00:11 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 11:00:11 -0400 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: Funny you listed something that only has less than 400 responses. How is that something "objective"? Many people don't care or are neutral to segwit1x vs segwit2x, of course. Businesses and services they use would take them to segwit2x, like the 10,000 merchants and millions of users. If any of them are pro-segwit1x, they should immediately terminate their business with those companies or stop using those wallets. We didn't see it happen. If you truly think those poll counts, why would you still arguing with me on a segwit2x mailing list? It only shows that you're extremely doubtful of your belief. I never see people arguing on a Bitcoin Cash mailing list to show which one has the majority support. Also you missed the counter-argument for "majority of miners". So I assume at least we agree that majority of miners support segwit2x. :) Now this is a technical mailing list. Would trolls please find elsewhere for those nonsense? Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > Local Time: October 14, 2017 10:48 PM > UTC Time: October 14, 2017 2:48 PM > From: segwit2x_mailinglist at bitcoinreminder.com > To: Cedrick Perrigo > Phillip Katete , bitcoin-segwit2x at lists.linuxfoundation.org > > It?s funny how you imply that "10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? > > The only sybill resistant poll which I know (even created by data of users from Coinbase!!!) shows that most of the coinbase customers are not in favour of b2x? > > https://luke.dashjr.org/programs/kycpoll/answers.php > > This link was twittered on /r/bitcoin, /r/btc and reweeted also by many B2X proponents. > > So please, show me some data how these "10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? > >> Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x : >> >> In the grand scheme of things, 10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of miners do not count but you only count a tiny thousand people on a Twitter poll. How funny this is. >> >> If you actually look into Twitter, there are only around a thousand people who has the "no2x" tag. Not all of them are trolling. However, people who state that those are everything that counts, especially on a segwit2x mailing list, is certainly trolling and does not worth any people's attention. >> >> Bitcoin will be what majority calls it. Period. >> >> Sent with [ProtonMail](https://protonmail.com/) Secure Email. >> >>> -------- Original Message -------- >>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>> Local Time: October 14, 2017 10:32 PM >>> UTC Time: October 14, 2017 2:32 PM >>> From: bitcoin-segwit2x at lists.linuxfoundation.org >>> To: Scott Roberts , bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> In the grand scheme of things, 1,168 responders is not exactly representative of the bitcoin community, is it? But that number, for a sample size, falls in the range of what is referred to as statistically irrelevant. It seems like you?ll have to do even more reading up! >>> >>> From: [Scott Roberts via Bitcoin-segwit2x](mailto:bitcoin-segwit2x at lists.linuxfoundation.org) >>> Sent: 14 October 2017 15:25 >>> To: bitcoin-segwit2x at lists.linuxfoundation.org >>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>> >>>> I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. >>> >>> 1,168 with 30x difference in responses is very significant. Show me >>> the twitter bubble where like-minded SegWit2x supporters show their >>> support. >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From segwit2x_mailinglist at bitcoinreminder.com Sat Oct 14 15:04:13 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Sat, 14 Oct 2017 17:04:13 +0200 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: > If any of them are pro-segwit1x, they should immediately terminate their business with those companies or stop using those wallets. I wonder then why Coinbase, Bitpay,.. etc are not asking its users or telling them to " immediately terminate their business with those companies or stop using those wallets?? > I never see people arguing on a Bitcoin Cash mailing list to show which one has the majority support. BCash was professional enough to include replay protection - which is not the case with B2X until now. > Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo : > > Funny you listed something that only has less than 400 responses. How is that something "objective"? > > Many people don't care or are neutral to segwit1x vs segwit2x, of course. Businesses and services they use would take them to segwit2x, like the 10,000 merchants and millions of users. If any of them are pro-segwit1x, they should immediately terminate their business with those companies or stop using those wallets. We didn't see it happen. > > If you truly think those poll counts, why would you still arguing with me on a segwit2x mailing list? It only shows that you're extremely doubtful of your belief. I never see people arguing on a Bitcoin Cash mailing list to show which one has the majority support. > > Also you missed the counter-argument for "majority of miners". So I assume at least we agree that majority of miners support segwit2x. :) > > Now this is a technical mailing list. Would trolls please find elsewhere for those nonsense? > > > Sent with ProtonMail Secure Email. > >> -------- Original Message -------- >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> Local Time: October 14, 2017 10:48 PM >> UTC Time: October 14, 2017 2:48 PM >> From: segwit2x_mailinglist at bitcoinreminder.com >> To: Cedrick Perrigo >> Phillip Katete , bitcoin-segwit2x at lists.linuxfoundation.org >> >> It?s funny how you imply that "10,000 merchants of BitPay, millions of users of Blockchain.info , Bitcoin.com , Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? >> >> The only sybill resistant poll which I know (even created by data of users from Coinbase!!!) shows that most of the coinbase customers are not in favour of b2x? >> >> https://luke.dashjr.org/programs/kycpoll/answers.php >> >> This link was twittered on /r/bitcoin, /r/btc and reweeted also by many B2X proponents. >> >> So please, show me some data how these "10,000 merchants of BitPay, millions of users of Blockchain.info , Bitcoin.com , Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? >> >> >>> Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x >: >>> >>> In the grand scheme of things, 10,000 merchants of BitPay, millions of users of Blockchain.info , Bitcoin.com , Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of miners do not count but you only count a tiny thousand people on a Twitter poll. How funny this is. >>> >>> If you actually look into Twitter, there are only around a thousand people who has the "no2x" tag. Not all of them are trolling. However, people who state that those are everything that counts, especially on a segwit2x mailing list, is certainly trolling and does not worth any people's attention. >>> >>> Bitcoin will be what majority calls it. Period. >>> >>> >>> Sent with ProtonMail Secure Email. >>> >>>> -------- Original Message -------- >>>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>>> Local Time: October 14, 2017 10:32 PM >>>> UTC Time: October 14, 2017 2:32 PM >>>> From: bitcoin-segwit2x at lists.linuxfoundation.org >>>> To: Scott Roberts >, bitcoin-segwit2x at lists.linuxfoundation.org > >>>> >>>> >>>> In the grand scheme of things, 1,168 responders is not exactly representative of the bitcoin community, is it? But that number, for a sample size, falls in the range of what is referred to as statistically irrelevant. It seems like you?ll have to do even more reading up! >>>> >>>> >>>> >>>> >>>> From: Scott Roberts via Bitcoin-segwit2x >>>> Sent: 14 October 2017 15:25 >>>> To: bitcoin-segwit2x at lists.linuxfoundation.org >>>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>>> >>>> >>>> >>>> > I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. >>>> >>>> >>>> 1,168 with 30x difference in responses is very significant. Show me >>>> the twitter bubble where like-minded SegWit2x supporters show their >>>> support. >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 >>>> >>>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Sat Oct 14 15:07:51 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 11:07:51 -0400 Subject: [Bitcoin-segwit2x] Satoshi Nakamoto said... In-Reply-To: References: Message-ID: Quotations not relevant should not be in this mailing list, please. Also you made the fallacy of "referring to the authority". Here's another piece from "Bitcoin: A Peer-to-Peer Electronic Cash System" by Satoshi Nakamoto. > They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Now tell me why 80% of miners don't count. They will produce valid 2MB blockchains. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: [Bitcoin-segwit2x] Satoshi Nakamoto said... > Local Time: October 14, 2017 10:58 PM > UTC Time: October 14, 2017 2:58 PM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: bitcoin-segwit2x at lists.linuxfoundation.org > > August 15, 2015: > > The developers of this [XT] pretender-Bitcoin claim to be following my > original vision, but nothing could be further from the truth. When I > designed Bitcoin, I designed it in such a way as to make future > modifications to the consensus rules difficult without near unanimous > agreement. .... Nearly everyone has to agree on a change, and they > have to do it without being forced or pressured into it. By doing a > fork in this way, these developers are violating the "original vision" > they claim to honour. > > Satoshi Nakamoto > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Sat Oct 14 15:09:06 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Sat, 14 Oct 2017 17:09:06 +0200 Subject: [Bitcoin-segwit2x] Satoshi Nakamoto said... In-Reply-To: References: Message-ID: On 14 October 2017 at 16:58, Scott Roberts via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > August 15, 2015: > > The developers of this [XT] pretender-Bitcoin claim to be following my > original vision, but nothing could be further from the truth. When I > designed Bitcoin, I designed it in such a way as to make future > modifications to the consensus rules difficult without near unanimous > agreement. .... Nearly everyone has to agree on a change, and they > have to do it without being forced or pressured into it. By doing a > fork in this way, these developers are violating the "original vision" > they claim to honour. > Satoshi is not with us, and has not been for a while. I think the quote you may be looking for is : https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 "Don't use this patch, it'll make you incompatible with the network, to your own detriment. We can phase in a change later if we get closer to needing it." I'm not sure it's all that relevant, today. Except that there are mixed opinions on that last bit. > > > Satoshi Nakamoto > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Sat Oct 14 15:11:21 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 11:11:21 -0400 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: You wonders do not belong to this mailing list. Get those silly speculations elsewhere. It's users deciding to use those services, not the other way around. If users are not happy, they can leave any time. But yet you see, that's not what's happening. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > Local Time: October 14, 2017 11:04 PM > UTC Time: October 14, 2017 3:04 PM > From: segwit2x_mailinglist at bitcoinreminder.com > To: Cedrick Perrigo > Phillip Katete , bitcoin-segwit2x at lists.linuxfoundation.org > >> If any of them are pro-segwit1x, they should immediately terminate their business with those companies or stop using those wallets. > > I wonder then why Coinbase, Bitpay,.. etc are not asking its users or telling them to " immediately terminate their business with those companies or stop using those wallets?? > >> I never see people arguing on a Bitcoin Cash mailing list to show which one has the majority support. > > BCash was professional enough to include replay protection - which is not the case with B2X until now. > >> Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo : >> >> Funny you listed something that only has less than 400 responses. How is that something "objective"? >> >> Many people don't care or are neutral to segwit1x vs segwit2x, of course. Businesses and services they use would take them to segwit2x, like the 10,000 merchants and millions of users. If any of them are pro-segwit1x, they should immediately terminate their business with those companies or stop using those wallets. We didn't see it happen. >> >> If you truly think those poll counts, why would you still arguing with me on a segwit2x mailing list? It only shows that you're extremely doubtful of your belief. I never see people arguing on a Bitcoin Cash mailing list to show which one has the majority support. >> >> Also you missed the counter-argument for "majority of miners". So I assume at least we agree that majority of miners support segwit2x. :) >> >> Now this is a technical mailing list. Would trolls please find elsewhere for those nonsense? >> >> Sent with [ProtonMail](https://protonmail.com/) Secure Email. >> >>> -------- Original Message -------- >>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>> Local Time: October 14, 2017 10:48 PM >>> UTC Time: October 14, 2017 2:48 PM >>> From: segwit2x_mailinglist at bitcoinreminder.com >>> To: Cedrick Perrigo >>> Phillip Katete , bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> It?s funny how you imply that "10,000 merchants of BitPay, millions of users of [Blockchain.info](http://blockchain.info/), [Bitcoin.com](http://bitcoin.com/), Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? >>> >>> The only sybill resistant poll which I know (even created by data of users from Coinbase!!!) shows that most of the coinbase customers are not in favour of b2x? >>> >>> https://luke.dashjr.org/programs/kycpoll/answers.php >>> >>> This link was twittered on /r/bitcoin, /r/btc and reweeted also by many B2X proponents. >>> >>> So please, show me some data how these "10,000 merchants of BitPay, millions of users of [Blockchain.info](http://blockchain.info/), [Bitcoin.com](http://bitcoin.com/), Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? >>> >>>> Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x : >>>> >>>> In the grand scheme of things, 10,000 merchants of BitPay, millions of users of [Blockchain.info](http://blockchain.info/), [Bitcoin.com](http://bitcoin.com/), Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of miners do not count but you only count a tiny thousand people on a Twitter poll. How funny this is. >>>> >>>> If you actually look into Twitter, there are only around a thousand people who has the "no2x" tag. Not all of them are trolling. However, people who state that those are everything that counts, especially on a segwit2x mailing list, is certainly trolling and does not worth any people's attention. >>>> >>>> Bitcoin will be what majority calls it. Period. >>>> >>>> Sent with [ProtonMail](https://protonmail.com/) Secure Email. >>>> >>>>> -------- Original Message -------- >>>>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>>>> Local Time: October 14, 2017 10:32 PM >>>>> UTC Time: October 14, 2017 2:32 PM >>>>> From: bitcoin-segwit2x at lists.linuxfoundation.org >>>>> To: Scott Roberts , bitcoin-segwit2x at lists.linuxfoundation.org >>>>> >>>>> In the grand scheme of things, 1,168 responders is not exactly representative of the bitcoin community, is it? But that number, for a sample size, falls in the range of what is referred to as statistically irrelevant. It seems like you?ll have to do even more reading up! >>>>> >>>>> From: [Scott Roberts via Bitcoin-segwit2x](mailto:bitcoin-segwit2x at lists.linuxfoundation.org) >>>>> Sent: 14 October 2017 15:25 >>>>> To: bitcoin-segwit2x at lists.linuxfoundation.org >>>>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>>>> >>>>>> I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. >>>>> >>>>> 1,168 with 30x difference in responses is very significant. Show me >>>>> the twitter bubble where like-minded SegWit2x supporters show their >>>>> support. >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at bitgo.com Sat Oct 14 15:18:42 2017 From: mike at bitgo.com (Mike Belshe) Date: Sat, 14 Oct 2017 08:18:42 -0700 Subject: [Bitcoin-segwit2x] Satoshi Nakamoto said... In-Reply-To: References: Message-ID: Please don't waste our time with this sort of post; you know this is not helpful. We have too many people on this list and will ban those that insist on spamming. Mike On Sat, Oct 14, 2017 at 8:09 AM, Melvin Carvalho via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > > On 14 October 2017 at 16:58, Scott Roberts via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> August 15, 2015: >> >> The developers of this [XT] pretender-Bitcoin claim to be following my >> original vision, but nothing could be further from the truth. When I >> designed Bitcoin, I designed it in such a way as to make future >> modifications to the consensus rules difficult without near unanimous >> agreement. .... Nearly everyone has to agree on a change, and they >> have to do it without being forced or pressured into it. By doing a >> fork in this way, these developers are violating the "original vision" >> they claim to honour. >> > > Satoshi is not with us, and has not been for a while. > > I think the quote you may be looking for is : > > https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 > > "Don't use this patch, it'll make you incompatible with the network, to > your own detriment. > > We can phase in a change later if we get closer to needing it." > > I'm not sure it's all that relevant, today. Except that there are mixed > opinions on that last bit. > >> >> >> Satoshi Nakamoto >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- *Mike Belshe* *CEO, BitGo, Inc*408-718-6885 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at bitgo.com Sat Oct 14 15:19:19 2017 From: mike at bitgo.com (Mike Belshe) Date: Sat, 14 Oct 2017 08:19:19 -0700 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: I've banned Scott. On Sat, Oct 14, 2017 at 8:11 AM, Cedrick Perrigo via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > You wonders do not belong to this mailing list. Get those silly > speculations elsewhere. > > It's users deciding to use those services, not the other way around. If > users are not happy, they can leave any time. But yet you see, that's not > what's happening. > > > Sent with ProtonMail Secure Email. > > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > Local Time: October 14, 2017 11:04 PM > UTC Time: October 14, 2017 3:04 PM > From: segwit2x_mailinglist at bitcoinreminder.com > To: Cedrick Perrigo > Phillip Katete , bitcoin-segwit2x at lists. > linuxfoundation.org > > If any of them are pro-segwit1x, they should immediately terminate their > business with those companies or stop using those wallets. > > > I wonder then why Coinbase, Bitpay,.. etc are not asking its users or > telling them to " immediately terminate their business with those companies > or stop using those wallets?? > > > I never see people arguing on a Bitcoin Cash mailing list to show which > one has the majority support. > > > BCash was professional enough to include replay protection - which is not > the case with B2X until now. > > Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo < > cedrickperrigo at protonmail.com>: > > Funny you listed something that only has less than 400 responses. How is > that something "objective"? > > Many people don't care or are neutral to segwit1x vs segwit2x, of course. > Businesses and services they use would take them to segwit2x, like the > 10,000 merchants and millions of users. If any of them are pro-segwit1x, > they should immediately terminate their business with those companies or > stop using those wallets. We didn't see it happen. > > If you truly think those poll counts, why would you still arguing with me > on a segwit2x mailing list? It only shows that you're extremely doubtful of > your belief. I never see people arguing on a Bitcoin Cash mailing list to > show which one has the majority support. > > Also you missed the counter-argument for "majority of miners". So I assume > at least we agree that majority of miners support segwit2x. :) > > Now this is a technical mailing list. Would trolls please find elsewhere > for those nonsense? > > > Sent with ProtonMail Secure Email. > > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > Local Time: October 14, 2017 10:48 PM > UTC Time: October 14, 2017 2:48 PM > From: segwit2x_mailinglist at bitcoinreminder.com > To: Cedrick Perrigo > Phillip Katete , bitcoin-segwit2x at lists. > linuxfoundation.org > > It?s funny how you imply that "10,000 merchants of BitPay, millions of > users of Blockchain.info , Bitcoin.com > , Xapo, Coinbase, millions of buyers and sellers of > OpenBazar? are in favour of b2x? > > The only sybill resistant poll which I know (even created by data of users > from Coinbase!!!) shows that most of the coinbase customers are not in > favour of b2x? > > https://luke.dashjr.org/programs/kycpoll/answers.php > > This link was twittered on /r/bitcoin, /r/btc and reweeted also by many > B2X proponents. > > So please, show me some data how these "10,000 merchants of BitPay, > millions of users of Blockchain.info , Bitcoin. > com , Xapo, Coinbase, millions of buyers and sellers > of OpenBazar? are in favour of b2x? > > > Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org>: > > In the grand scheme of things, 10,000 merchants of BitPay, millions of > users of Blockchain.info , Bitcoin.com > , Xapo, Coinbase, millions of buyers and sellers of > OpenBazar, majority of miners do not count but you only count a tiny > thousand people on a Twitter poll. How funny this is. > > If you actually look into Twitter, there are only around a thousand people > who has the "no2x" tag. Not all of them are trolling. However, people who > state that those are everything that counts, especially on a segwit2x > mailing list, is certainly trolling and does not worth any people's > attention. > > Bitcoin will be what majority calls it. Period. > > > Sent with ProtonMail Secure Email. > > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > Local Time: October 14, 2017 10:32 PM > UTC Time: October 14, 2017 2:32 PM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: Scott Roberts , bitcoin-segwit2x at lists. > linuxfoundation.org > > > In the grand scheme of things, 1,168 responders is not exactly > representative of the bitcoin community, is it? But that number, for a > sample size, falls in the range of what is referred to as statistically > irrelevant. It seems like you?ll have to do even more reading up! > > > > *From: *Scott Roberts via Bitcoin-segwit2x > > *Sent: *14 October 2017 15:25 > *To: *bitcoin-segwit2x at lists.linuxfoundation.org > *Subject: *Re: [Bitcoin-segwit2x] We are all bitcoin > > > > > I have NEVER seen a twitter poll on bitcoin that had a statistically > relevant sample size. But also bear in mind that by it?s very nature, > twitter creates bubbles where like minded people follow each other. > > > 1,168 with 30x difference in responses is very significant. Show me > the twitter bubble where like-minded SegWit2x supporters show their > support. > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists. > linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x& > data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0% > 7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata= > 2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- *Mike Belshe* *CEO, BitGo, Inc*408-718-6885 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Sat Oct 14 15:29:41 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Sat, 14 Oct 2017 17:29:41 +0200 Subject: [Bitcoin-segwit2x] Satoshi Nakamoto said... In-Reply-To: References: Message-ID: On 14 October 2017 at 17:18, Mike Belshe wrote: > Please don't waste our time with this sort of post; you know this is not > helpful. > > We have too many people on this list and will ban those that insist on > spamming. > Hi Mike Appreciate your guidance on this. I hope you are not referring to my response. I noticed that someone posted a 'fake' quote by satsohi from 2015. Satoshi was not with us in 2015, and the post very likely an impostor. I corrected it to the conversation, to one between jgarzik and satoshi regarding increasing the block size limit. I would hope that is on-topic. And also of (at least historical) interest wrt the current situation we find ourselves in. If you could have a process document, code of conduct or etiquette guide, I would be very happy to comply. I try to and hope I do! :) Thanks > > Mike > > > On Sat, Oct 14, 2017 at 8:09 AM, Melvin Carvalho via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> >> >> On 14 October 2017 at 16:58, Scott Roberts via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> August 15, 2015: >>> >>> The developers of this [XT] pretender-Bitcoin claim to be following my >>> original vision, but nothing could be further from the truth. When I >>> designed Bitcoin, I designed it in such a way as to make future >>> modifications to the consensus rules difficult without near unanimous >>> agreement. .... Nearly everyone has to agree on a change, and they >>> have to do it without being forced or pressured into it. By doing a >>> fork in this way, these developers are violating the "original vision" >>> they claim to honour. >>> >> >> Satoshi is not with us, and has not been for a while. >> >> I think the quote you may be looking for is : >> >> https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 >> >> "Don't use this patch, it'll make you incompatible with the network, to >> your own detriment. >> >> We can phase in a change later if we get closer to needing it." >> >> I'm not sure it's all that relevant, today. Except that there are mixed >> opinions on that last bit. >> >>> >>> >>> Satoshi Nakamoto >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > > -- > > > *Mike Belshe* > *CEO, BitGo, Inc*408-718-6885 <(408)%20718-6885> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at bitgo.com Sat Oct 14 15:32:23 2017 From: mike at bitgo.com (Mike Belshe) Date: Sat, 14 Oct 2017 08:32:23 -0700 Subject: [Bitcoin-segwit2x] Satoshi Nakamoto said... In-Reply-To: References: Message-ID: Sorry - was referring to Scott. Mike On Sat, Oct 14, 2017 at 8:29 AM, Melvin Carvalho wrote: > > > On 14 October 2017 at 17:18, Mike Belshe wrote: > >> Please don't waste our time with this sort of post; you know this is not >> helpful. >> >> We have too many people on this list and will ban those that insist on >> spamming. >> > > Hi Mike > > Appreciate your guidance on this. > > I hope you are not referring to my response. > > I noticed that someone posted a 'fake' quote by satsohi from 2015. > Satoshi was not with us in 2015, and the post very likely an impostor. > > I corrected it to the conversation, to one between jgarzik and satoshi > regarding increasing the block size limit. I would hope that is on-topic. > And also of (at least historical) interest wrt the current situation we > find ourselves in. > > If you could have a process document, code of conduct or etiquette guide, > I would be very happy to comply. I try to and hope I do! :) > > Thanks > > >> >> Mike >> >> >> On Sat, Oct 14, 2017 at 8:09 AM, Melvin Carvalho via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> >>> >>> On 14 October 2017 at 16:58, Scott Roberts via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> August 15, 2015: >>>> >>>> The developers of this [XT] pretender-Bitcoin claim to be following my >>>> original vision, but nothing could be further from the truth. When I >>>> designed Bitcoin, I designed it in such a way as to make future >>>> modifications to the consensus rules difficult without near unanimous >>>> agreement. .... Nearly everyone has to agree on a change, and they >>>> have to do it without being forced or pressured into it. By doing a >>>> fork in this way, these developers are violating the "original vision" >>>> they claim to honour. >>>> >>> >>> Satoshi is not with us, and has not been for a while. >>> >>> I think the quote you may be looking for is : >>> >>> https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 >>> >>> "Don't use this patch, it'll make you incompatible with the network, to >>> your own detriment. >>> >>> We can phase in a change later if we get closer to needing it." >>> >>> I'm not sure it's all that relevant, today. Except that there are mixed >>> opinions on that last bit. >>> >>>> >>>> >>>> Satoshi Nakamoto >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> >> >> -- >> >> >> *Mike Belshe* >> *CEO, BitGo, Inc*408-718-6885 <(408)%20718-6885> >> > > -- *Mike Belshe* *CEO, BitGo, Inc*408-718-6885 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Sat Oct 14 09:08:12 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Sat, 14 Oct 2017 11:08:12 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: On 14 October 2017 at 08:58, Tony Gallippi via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > If users are that particular that they want their transaction *only* > included in a 1MB container block, and *never* in any 2MB container block, > that is their choice. But, even with just a 50% decrease in hashing power > those users will start to pay very high fees for that 1MB preference and > likely wait a very long time between blocks. > > The companies that signed the NYA represent probably 60%, maybe 80%, of > all transactions on the bitcoin network today. Blockchain and Coinbase > together have 30 million users. Those users are all the silent majority > that don't comment on social media. They just want their transaction to > work, without preference for container size, but with a preference for a > lower fee and less congestion. These users have likely never run a full > node and have no reason to. > Not all users would want increased capacity, if it means putting at risk 87% of the value of their asset. I wouldn't, for example. Increased capacity is already a common goal. Let's do it in a way that's safe and protects the assets of everyone. > > I expect at the moment of the fork, bitcoin core will still have a > majority of nodes. But BTC1, bcoin, and many other implementations allowing > a larger container block will have more than enough nodes to make a viable > mesh network. > > We could use more implementations of bitcoin, and a defensive consensus > amongst them. With that, bitcoin can evolve and will be impossible to stop. > > > > > > > On Sat, Oct 14, 2017 at 2:38 AM, Jacob Eliosoff via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> My link included approaches that at least make it easy for users to send >> 1x-only txs - approaches that could conceivably get deployed by 2x, and >> thus protect 1x users. Just repeatedly banging your head against the wall >> with a proposal everyone can see has 0 chance at deployment (want to bet?) >> doesn't protect users at all. It accomplishes exactly as much for your >> cause as sending 100 mails to this list saying "DON'T HF!" >> >> Anyway that's my 2c. If you want to discuss further let's talk offline >> or on Twitter - somewhere other than a list for plausible technical >> proposals. >> >> >> On Sat, Oct 14, 2017 at 2:24 AM, Marcel Jamin wrote: >> >>> I wouldn't consider any opt-in approach as "strong" replay protection. >>> If this WG as NACKed strong two way replay protection, then it's not a >>> safe upgrade path und thus not an implementation honoring the NYA. >>> >>> On 14 October 2017 at 07:53, Jacob Eliosoff >>> wrote: >>> > Can I ask that anyone advocating 2-way replay protection (which I also >>> > support) be specific about how they propose it be done? No disrespect >>> > meant, but BCH-style RP, that would require old wallets to upgrade, >>> has been >>> > proposed and emphatically NACKed here umpteen times: it is just >>> unrealistic >>> > to think this project would adopt it at this stage. There are other >>> 2-way >>> > RP approaches that I still believe are worth pursuing, but at this >>> point any >>> > discussion of 2-way RP as if it's a simple binary decision is a >>> complete >>> > waste of everyone's time. >>> > >>> > >>> > On Sat, Oct 14, 2017 at 1:31 AM, Marcel Jamin via Bitcoin-segwit2x >>> > wrote: >>> >> >>> >> On 14 October 2017 at 02:20, Ben Peters via Bitcoin-segwit2x >>> >> wrote: >>> >> > I think there is a fundamental misunderstanding about the nature of >>> the >>> >> > NYA/Segwit2x endeavour. What is happening here is that an >>> alternative, >>> >> > minimally modified, version of the Bitcoin code is being developed >>> that >>> >> > will >>> >> > implement a change that has long been sought by the mining >>> community and >>> >> > many in industry and beyond (a change that they presumably feel is >>> >> > important >>> >> > for the future success of Bitcoin and thus their respective >>> >> > investments). >>> >> > >>> >> > That candidate code will be offered to the miners and mining pools, >>> who >>> >> > may >>> >> > or may not opt to apply hashing power to it. If they apply more >>> than the >>> >> > threshold amount of hashing power, then that new code will >>> effectively >>> >> > takeover from the previous consensus rule, and take most SPV >>> wallets and >>> >> > economic activity along with it. >>> >> > >>> >> > Rather than lobbying this technical working group to ?call off? >>> their >>> >> > efforts, your time might be better spent lobbying the miners. The >>> >> > function >>> >> > of this group is to produce candidate code, thus fulfilling the >>> >> > obligations >>> >> > as set out under the NYA. >>> >> >>> >> Fair enough, but this working group is making technical decisions that >>> >> can create a lof of confusion and cause many problems for bitcoin >>> >> users. >>> >> >>> >> Much of the lobbying is targeted towards implementing strong two-way >>> >> replay protection. The reason for not implementing this protection, is >>> >> that it would reveal this project as an alternative fork of bitcoin >>> >> and is based on the assumption, that most miners will in fact employ >>> >> the client put forward by this WG and apply their hashpower to it. >>> >> >>> >> Many indicators however point towards a virtually guaranteed network >>> >> split. >>> >> >>> >> The NYA committed signers to "deployment of safe solutions that >>> >> increase bitcoin capacity". This implementation doesn't fulfill that >>> >> goal. Without strong replay protection, this will be a mess for both >>> >> sides. >>> >> >>> >> > >>> >> > >>> >> > On Oct 13, 2017, at 8:55 AM, Melvin Carvalho via Bitcoin-segwit2x >>> >> > wrote: >>> >> > >>> >> > >>> >> > >>> >> > On 13 October 2017 at 12:45, Melvin Carvalho >>> >> > wrote: >>> >> >> >>> >> >> >>> >> >> >>> >> >> On 13 October 2017 at 12:30, Phillip Katete >>> >> >> wrote: >>> >> >>> >>> >> >>> The disingenuity here is ?painful to watch?. First you make hay of >>> >> >>> f2pool >>> >> >>> switching off NYA signaling intent THEN you rubbish signaling >>> intent >>> >> >>> as >>> >> >>> cheap and not worthy of consideration as a metric. More >>> worryingly, >>> >> >>> you then >>> >> >>> want to predicate the HF on miner signaling at the 80% threshold. >>> So >>> >> >>> which >>> >> >>> is it then? >>> >> >>> >>> >> >>> Even with the EDA induced hash oscillations, I am confident hash >>> at >>> >> >>> and >>> >> >>> post fork will mirror signaling intent. >>> >> >> >>> >> >> >>> >> >> 24h signaling fell to 79.86% [1] >>> >> > >>> >> > >>> >> > NYA signaling is now down to 77.70% in the last 24h (down from over >>> 90% >>> >> > a >>> >> > day ago) >>> >> > >>> >> > https://coin.dance/blocks >>> >> > >>> >> > This does not take into account ViaBTC which may support either >>> chain, >>> >> > but >>> >> > are currently signaling 100% NYA. >>> >> > >>> >> > However, much hash is mining bitcoin cash right now, and probably >>> >> > favourable >>> >> > to seg2x >>> >> > >>> >> > Additionally, you can monitor the futures market in realtime >>> >> > >>> >> > https://cryptowat.ch/bitfinex/bt2btc >>> >> > >>> >> > Currently trading at 10.6% of bitcoin (down from over 20% a day ago) >>> >> > >>> >> > You may wish to consider these metrics a source of new information >>> for >>> >> > this >>> >> > project. And / or watch them as they develop. >>> >> > >>> >> >> >>> >> >> >>> >> >> [1] https://coin.dance/blocks#thisweek >>> >> >> >>> >> >>> >>> >> >>> >>> >> >>> From: Melvin Carvalho >>> >> >>> Sent: 13 October 2017 11:11 >>> >> >>> To: Phillip Katete >>> >> >>> Cc: Dr Adam Back; Emil Oldenburg; Peter Todd via Bitcoin-segwit2x >>> >> >>> >>> >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork >>> still >>> >> >>> happening? >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> On 13 October 2017 at 11:47, Phillip Katete via Bitcoin-segwit2x >>> >> >>> wrote: >>> >> >>> >>> >> >>> You are barking up the wrong tree by using a ?rigged? futures? >>> price >>> >> >>> to >>> >> >>> estimate the hash supporting the upgrade at fork time. They NYA >>> was >>> >> >>> presented as being backed by at least 80% of the network hash >>> then and >>> >> >>> was >>> >> >>> activated / locked-in by over 90%. Since then, it has continued to >>> >> >>> receive >>> >> >>> and sustain intent signalling above the introduction threshold. >>> It is >>> >> >>> only >>> >> >>> rational to expect the hash on fork to reflect the latter as >>> opposed >>> >> >>> to >>> >> >>> futures? prices. >>> >> >>> >>> >> >>> Obiter dicta: the futures? price is more reflective of the >>> wavering >>> >> >>> non >>> >> >>> mining, none economic users. It goes without saying, a lot of >>> people >>> >> >>> are >>> >> >>> going to loose a lot of money on this otherwise rigged futures? >>> >> >>> market. >>> >> >>> >>> >> >>> >>> >> >>> Markets are not always accurate, but simply a form of price >>> discovery, >>> >> >>> I >>> >> >>> think "rigged" is perhaps a loaded term in this case and >>> stretching >>> >> >>> things. >>> >> >>> A 12% futures market does not bode well for success, but, you >>> never >>> >> >>> know. >>> >> >>> Since F2Pool stopped signaling NYA yesterday the signaling ratio >>> is >>> >> >>> now >>> >> >>> about 81%, though this might have something to do with the feast >>> and >>> >> >>> famine >>> >> >>> EDA in bitcoin cash which has just been activated. Around 83% >>> might >>> >> >>> be a >>> >> >>> better guess. >>> >> >>> However signaling is cheap, and many miners act in economic self >>> >> >>> interest. Having helped run a coin for many years, I have >>> witnessed >>> >> >>> this >>> >> >>> being the case. There's nothing developers would like more than >>> >> >>> steady >>> >> >>> miners that stick with a coin, but sites such as coinwarz [1] all >>> too >>> >> >>> often >>> >> >>> create spikes in hash power related to profitability. >>> >> >>> Wishing to stay on topic, I'd like to ask the following >>> question. If >>> >> >>> signaling falls below the described 80% threshold stated above >>> (ie one >>> >> >>> more >>> >> >>> miner stops signaling), will this this be grounds to rethink the >>> >> >>> timing of >>> >> >>> the release schedule? >>> >> >>> >>> >> >>> [1] https://www.coinwarz.com/cryptocurrency >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> From:Dr Adam Back via Bitcoin-segwit2x >>> >> >>> Sent: 13 October 2017 10:11 >>> >> >>> To: Emil Oldenburg >>> >> >>> Cc: Peter Todd via Bitcoin-segwit2x >>> >> >>> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork >>> still >>> >> >>> happening? >>> >> >>> >>> >> >>> The futures price is 1/3 of 40% so yes actually < 40% hashrate is >>> >> >>> quite >>> >> >>> likely. >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https >>> %3a%2f%2fwww.google.com%2f >>> >> >>> >>> >> >>> Nodes should upgrade because code changes are being made and it's >>> not >>> >> >>> a good idea to run pre-production code on the live network. Do >>> you >>> >> >>> recall when the company you work for lost bitcoin by running >>> >> >>> pre-release fork code before on the pool? >>> >> >>> >>> >> >>> Is anyone running BTC1 head in production? Protecting how much >>> value. >>> >> >>> Reminder this is a public list. >>> >> >>> >>> >> >>> Adam >>> >> >>> >>> >> >>> On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via >>> Bitcoin-segwit2x >>> >> >>> wrote: >>> >> >>> > The hardfork part is already locked in and is not subject to >>> change. >>> >> >>> > Many >>> >> >>> > btc1 nodes are already deployed and they should not and don't >>> need >>> >> >>> > to >>> >> >>> > update. The only thing left is a potential extra softfork for >>> opt-in >>> >> >>> > replay >>> >> >>> > protection. Only the miners need this softfork. >>> >> >>> > >>> >> >>> > What makes you think the hardfork will have less than 40% >>> hashpower? >>> >> >>> > >>> >> >>> > >>> >> >>> > Emil Oldenburg, CTO >>> >> >>> > Emil at bitcoin.com >>> >> >>> > Visit the all new https://bitcoin.com >>> >> >>> > Wechat: emilold >>> >> >>> > Telegram: emilold >>> >> >>> > >>> >> >>> > On 2017 >>> >> >>> ?10?13?17:31, Peter BitcoinReminder.com wrote: >>> >> >>> >>> >> >>> > >>> >> >>> > Thats not a reason, the BTC1 sourcecode is still in development >>> >> >>> > (f.e. >>> >> >>> > replay >>> >> >>> > protection was reverted just 1-2 days ago?) - so the argument >>> ?it >>> >> >>> > can?t >>> >> >>> > be >>> >> >>> > called off? is just wrong. >>> >> >>> > >>> >> >>> > So wouldn?t it make sense to add a minimum required hashrate >>> for the >>> >> >>> > HF >>> >> >>> > to >>> >> >>> > lock in? You are really going to fork off with f.e. 40 % >>> hashpower? >>> >> >>> > >>> >> >>> > >>> >> >>> > Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via >>> Bitcoin-segwit2x >>> >> >>> > : >>> >> >>> > >>> >> >>> > If we try to be technical here. The HF is already activated, is >>> >> >>> > estimated to >>> >> >>> > trigger in 36 days, and can't be "called off". Nor is there any >>> >> >>> > logic >>> >> >>> > to >>> >> >>> > delay it if hashrate deflects. That's the rules of the btc1 >>> client. >>> >> >>> > >>> >> >>> > >>> >> >>> > Emil Oldenburg, CTO >>> >> >>> > Emil at bitcoin.com >>> >> >>> > Visit the all new https://bitcoin.com >>> >> >>> > Wechat: emilold >>> >> >>> > Telegram: emilold >>> >> >>> > >>> >> >>> > On 2017 >>> >> >>> ?10?13?05:31, John Heathco via Bitcoin-segwit2x wrote: >>> >> >>> >>> >> >>> > >>> >> >>> > I don't believe there is an explicitly stated hashpower in >>> which the >>> >> >>> > fork >>> >> >>> > would be "called off", but I would assume it is much lower than >>> what >>> >> >>> > is >>> >> >>> > currently signaling, even if we make the (unwise) assumption >>> that >>> >> >>> > F2Pool >>> >> >>> > would not contribute to mining 2x whatsoever. >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> > On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via >>> >> >>> > Bitcoin-segwit2x >>> wrote: >>> >> >>> >> >>> >> >>> >> I?m not Peter Todd, we just share the same (nice) firstname. >>> >> >>> >> >>> >> >>> >> I still didn?t get an answer what the minimum amount of >>> hashpower >>> >> >>> >> is >>> >> >>> >> required, before the fork is getting delayed? >>> >> >>> >> We have to plan time for the whole security measures etc, so I >>> >> >>> >> think >>> >> >>> >> it?s >>> >> >>> >> reasonable to get more information about this? >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> Am 12.10.2017 um 21:53 schrieb bitPico : >>> >> >>> >> >>> >> >>> >> Without you knowing why they stopped signaling this is FUD and >>> >> >>> >> off-topic >>> >> >>> >> for this list. Please instead let F2Pool state their own >>> opinion >>> >> >>> >> here >>> >> >>> >> since >>> >> >>> >> yours doesn?t count. If you think your opinion does count then >>> show >>> >> >>> >> us >>> >> >>> >> your >>> >> >>> >> blocks that your pool has produced; until then you are simply >>> an >>> >> >>> >> end-user >>> >> >>> >> and still you are off-topic for this list. If you need ELI5 >>> for how >>> >> >>> >> this >>> >> >>> >> list works please let us know and we can help you Peter Todd. >>> >> >>> >> >>> >> >>> >> Have a groovy day! >>> >> >>> >> >>> >> >>> >> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via >>> >> >>> >> Bitcoin-segwit2x >>> >> >>> >> wrote: >>> >> >>> >> >>> >> >>> >> Since F2Pool stopped signaling for the NYA[1] and slush also >>> mines >>> >> >>> >> mostly >>> >> >>> >> non-NYA blocks, are you still going to fork off in November - >>> >> >>> >> splitting the >>> >> >>> >> chain intentionally? >>> >> >>> >> >>> >> >>> >> ? >>> >> >>> >> [1] https://imgur.com/LgYdFKw >>> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > > -- > *Tony Gallippi* > Co-founder and Executive Chairman > BitPay, Inc. > https://bitpay.com > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry.d.chan at bittoku.co.jp Sat Oct 14 10:28:08 2017 From: jerry.d.chan at bittoku.co.jp (digitsu) Date: Sat, 14 Oct 2017 19:28:08 +0900 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: If this line of argument sounds strangely familiar to those in the list, then it is because Adam, James, Peter, and his supporters have been using the exact same argument to stop hardforks in the first place, namely, that changing the existing codebase via a hard fork will cause inadvertent chain split and some poor souls who did not get the message to upgrade will lose money. In this case, as we have the majority of miners signalling segwit2x, and presumably some large proportion of them are actually running btc1, this means that a ?backing out? of 2x part now will forcefully fork them off the network and have them waste tens of thousands of dollars a day because they forgot to upgrade. While Adam and friends seem to care very much about the odd miss-sent payment made due to lack of replay protection, I find it strange that they seem to not care too much about these poor ?small miners? that will be inadvertently hurt by a backing out of 2x part. These are the same ?small miners? who struggle to compete with the big ones that James Hilliard is so fond of calling up as an example of mining decentralization worries. Why should we forget about these innocents? I don?t see why they are any different than other users. As Emil O. said, btc1 and segwit2x is already locked in and a large but indeterminate number of miners are already using the software. (even though they are hard to count, I see this no different than trying to count ?economic majority? or ?user community support? that the 1x side keeps on claiming to have a majority on. > On Oct 13, 2017, at 18:11, Dr Adam Back via Bitcoin-segwit2x wrote: > > The futures price is 1/3 of 40% so yes actually < 40% hashrate is quite likely. > > https://www.cryptonator.com/rates/BT2-BTC?utm_referrer=https%3a%2f%2fwww.google.com%2f > > Nodes should upgrade because code changes are being made and it's not > a good idea to run pre-production code on the live network. Do you > recall when the company you work for lost bitcoin by running > pre-release fork code before on the pool? > > Is anyone running BTC1 head in production? Protecting how much value. > Reminder this is a public list. > > Adam > > On Fri, Oct 13, 2017 at 11:01 AM, Emil Oldenburg via Bitcoin-segwit2x > wrote: >> The hardfork part is already locked in and is not subject to change. Many >> btc1 nodes are already deployed and they should not and don't need to >> update. The only thing left is a potential extra softfork for opt-in replay >> protection. Only the miners need this softfork. >> >> What makes you think the hardfork will have less than 40% hashpower? >> >> >> Emil Oldenburg, CTO >> Emil at bitcoin.com >> Visit the all new https://bitcoin.com >> Wechat: emilold >> Telegram: emilold >> >> On 2017?10?13? 17:31, Peter BitcoinReminder.com wrote: >> >> Thats not a reason, the BTC1 sourcecode is still in development (f.e. replay >> protection was reverted just 1-2 days ago?) - so the argument ?it can?t be >> called off? is just wrong. >> >> So wouldn?t it make sense to add a minimum required hashrate for the HF to >> lock in? You are really going to fork off with f.e. 40 % hashpower? >> >> >> Am 13.10.2017 um 03:42 schrieb Emil Oldenburg via Bitcoin-segwit2x >> : >> >> If we try to be technical here. The HF is already activated, is estimated to >> trigger in 36 days, and can't be "called off". Nor is there any logic to >> delay it if hashrate deflects. That's the rules of the btc1 client. >> >> >> Emil Oldenburg, CTO >> Emil at bitcoin.com >> Visit the all new https://bitcoin.com >> Wechat: emilold >> Telegram: emilold >> >> On 2017?10?13? 05:31, John Heathco via Bitcoin-segwit2x wrote: >> >> I don't believe there is an explicitly stated hashpower in which the fork >> would be "called off", but I would assume it is much lower than what is >> currently signaling, even if we make the (unwise) assumption that F2Pool >> would not contribute to mining 2x whatsoever. >> >> >> >> On Thu, Oct 12, 2017 at 12:57 PM Peter BitcoinReminder.com via >> Bitcoin-segwit2x wrote: >>> >>> I?m not Peter Todd, we just share the same (nice) firstname. >>> >>> I still didn?t get an answer what the minimum amount of hashpower is >>> required, before the fork is getting delayed? >>> We have to plan time for the whole security measures etc, so I think it?s >>> reasonable to get more information about this? >>> >>> >>> Am 12.10.2017 um 21:53 schrieb bitPico : >>> >>> Without you knowing why they stopped signaling this is FUD and off-topic >>> for this list. Please instead let F2Pool state their own opinion here since >>> yours doesn?t count. If you think your opinion does count then show us your >>> blocks that your pool has produced; until then you are simply an end-user >>> and still you are off-topic for this list. If you need ELI5 for how this >>> list works please let us know and we can help you Peter Todd. >>> >>> Have a groovy day! >>> >>> On Oct 12, 2017, at 8:49 AM, Peter BitcoinReminder.com via >>> Bitcoin-segwit2x wrote: >>> >>> Since F2Pool stopped signaling for the NYA[1] and slush also mines mostly >>> non-NYA blocks, are you still going to fork off in November - splitting the >>> chain intentionally? >>> >>> ? >>> [1] https://imgur.com/LgYdFKw >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From adam at blockstream.com Sat Oct 14 16:50:03 2017 From: adam at blockstream.com (Dr Adam Back) Date: Sat, 14 Oct 2017 18:50:03 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: > all the disruptive part you talked about happens only on the segwit1x altcoin. Segwit2x Bitcoin is not affected. the disruption is symmetric. Adam On Sat, Oct 14, 2017 at 1:50 PM, Cedrick Perrigo wrote: > Arguing about strong two-way replay protection is a waste of time for Core. > People had made clear that won't happen. You'd better spending time thinking > about how you would make segwit1x altcoin survive. > > Talking about financial/support tickets. More would be complaining why the > transaction on segwit1x altcoin is not confirmed and why the fee is too > high. Exchanges will likely not want to handle this, and drop segwit1x > altcoin support all together. That's the simple game theory. > > Adam, what you didn't get is that all the disruptive part you talked about > happens only on the segwit1x altcoin. Segwit2x Bitcoin is not affected. So > better spend you time on bitcoin-dev discussing with Blockstream devs on how > to hard fork the difficulty algorithm and add replay protection on the > segwit1x altcoin. > > > Sent with ProtonMail Secure Email. > > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still > happening? > Local Time: October 14, 2017 7:19 PM > UTC Time: October 14, 2017 11:19 AM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: Ben Peters > Peter Todd via Bitcoin-segwit2x > > A lot of what you described doesn"t work the way you seem to expect. > > There"s a few levels: > > Mining economics: I do some mining, and there are a number of data > points from alt-coins that share mining algorithms: miners short / mid > term mine what is profitable. That is driven by relative price. > Difficulty adjusts to equilibrium. This is a feature, it is the > incentive that secures blockchains. Bitcoin security works by > economically incentivised creation of valid blocks as measured by the > nodes on the network. > > Nodes and wallets mechanically todays software: Existing full nodes > won"t follow. Most smart phone wallets will not automatically switch > but either ignore a new chain, stop functioning, go into some kind of > warning state pending bugfix, some older wallets may get stuck on > random chain. And because there is no proper replay protection > randomly transactions will be made on one or both chains unless mixed > with new coinbase over time. That will be pretty disruptive because > people writing wallet software don"t know what segwit2x code will be > as they keep changing. Bitcoin cash changed up to 5days before > release. > > Services: Also it"s a big job to defend all existing all existing > services and wallets. Never the less as both chains have value each > service and wallet must over time offer some solution even if it is > replay protected withdrawal. So nothing is achieved in practice vs > proper replay protection other than disruption. > > Due Care & safety: Doing reckless and risky things to the network may > not be a good advertisement for service or wallet. Users will > research and make some decision about which wallets and services will > preserve their coins and allow them to split and sell or hold > whichever of the 3 or 4 spinoffs are created. People will likely not > recommend software and services that promote dand advocated for > creating the disruption and risk. > > Financial, support tickets: users will complain via support tickets > and formal complaints about experience and asset loss as that happens. > > Would be interested in proponents views of how their companies (if > they have users) will handle this, and also how they suppose different > use cases from other services and wallets will interoperate. > > It sort of feels like there is an expected game-theory reaction here > that no one is talking about, but maybe people have different views of > what the logical game theory is? > > ps please trip replies list posts are bouncing as too large. > > Adam > > On Sat, Oct 14, 2017 at 2:20 AM, Ben Peters via Bitcoin-segwit2x > wrote: >> I think there is a fundamental misunderstanding about the nature of the >> NYA/Segwit2x endeavour. What is happening here is that an alternative, >> minimally modified, version of the Bitcoin code is being developed that >> will >> implement a change that has long been sought by the mining community and >> many in industry and beyond (a change that they presumably feel is >> important >> for the future success of Bitcoin and thus their respective investments). >> >> That candidate code will be offered to the miners and mining pools, who >> may >> or may not opt to apply hashing power to it. If they apply more than the >> threshold amount of hashing power, then that new code will effectively >> takeover from the previous consensus rule, and take most SPV wallets and >> economic activity along with it. >> >> Rather than lobbying this technical working group to ?call off? their >> efforts, your time might be better spent lobbying the miners. The function >> of this group is to produce candidate code, thus fulfilling the >> obligations >> as set out under the NYA. >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > From bitcoinerrorlog at gmail.com Sat Oct 14 16:50:21 2017 From: bitcoinerrorlog at gmail.com (Bitcoin Error Log) Date: Sat, 14 Oct 2017 16:50:21 +0000 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: If you won't accept that a significant portion of Bitcoin does not want this, let's at least address that some of the tech people in NYA-signing businesses, like Jameson Lopp of BitGo, and Alex Petrov of BitFury also disagree with the implementation. Are these companies going to ignore the very people they hired to be knowledgeable? I'd argue a minority of developers overall do not want strong replay protection. You do not have consensus of developers, Core, or not. On Sat, Oct 14, 2017, 6:19 PM Mike Belshe via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > I've banned Scott. > > On Sat, Oct 14, 2017 at 8:11 AM, Cedrick Perrigo via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> You wonders do not belong to this mailing list. Get those silly >> speculations elsewhere. >> >> It's users deciding to use those services, not the other way around. If >> users are not happy, they can leave any time. But yet you see, that's not >> what's happening. >> >> >> Sent with ProtonMail Secure Email. >> >> -------- Original Message -------- >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> Local Time: October 14, 2017 11:04 PM >> UTC Time: October 14, 2017 3:04 PM >> From: segwit2x_mailinglist at bitcoinreminder.com >> To: Cedrick Perrigo >> Phillip Katete , >> bitcoin-segwit2x at lists.linuxfoundation.org < >> bitcoin-segwit2x at lists.linuxfoundation.org> >> >> If any of them are pro-segwit1x, they should immediately terminate their >> business with those companies or stop using those wallets. >> >> >> I wonder then why Coinbase, Bitpay,.. etc are not asking its users or >> telling them to " immediately terminate their business with those companies >> or stop using those wallets?? >> >> >> I never see people arguing on a Bitcoin Cash mailing list to show which >> one has the majority support. >> >> >> BCash was professional enough to include replay protection - which is not >> the case with B2X until now. >> >> Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo < >> cedrickperrigo at protonmail.com>: >> >> Funny you listed something that only has less than 400 responses. How is >> that something "objective"? >> >> Many people don't care or are neutral to segwit1x vs segwit2x, of course. >> Businesses and services they use would take them to segwit2x, like the >> 10,000 merchants and millions of users. If any of them are pro-segwit1x, >> they should immediately terminate their business with those companies or >> stop using those wallets. We didn't see it happen. >> >> If you truly think those poll counts, why would you still arguing with me >> on a segwit2x mailing list? It only shows that you're extremely doubtful of >> your belief. I never see people arguing on a Bitcoin Cash mailing list to >> show which one has the majority support. >> >> Also you missed the counter-argument for "majority of miners". So I >> assume at least we agree that majority of miners support segwit2x. :) >> >> Now this is a technical mailing list. Would trolls please find elsewhere >> for those nonsense? >> >> >> Sent with ProtonMail Secure Email. >> >> -------- Original Message -------- >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> Local Time: October 14, 2017 10:48 PM >> UTC Time: October 14, 2017 2:48 PM >> From: segwit2x_mailinglist at bitcoinreminder.com >> To: Cedrick Perrigo >> Phillip Katete , >> bitcoin-segwit2x at lists.linuxfoundation.org < >> bitcoin-segwit2x at lists.linuxfoundation.org> >> >> It?s funny how you imply that "10,000 merchants of BitPay, millions of >> users of Blockchain.info , Bitcoin.com >> , Xapo, Coinbase, millions of buyers and sellers of >> OpenBazar? are in favour of b2x? >> >> The only sybill resistant poll which I know (even created by data of >> users from Coinbase!!!) shows that most of the coinbase customers are not >> in favour of b2x? >> >> https://luke.dashjr.org/programs/kycpoll/answers.php >> >> This link was twittered on /r/bitcoin, /r/btc and reweeted also by many >> B2X proponents. >> >> So please, show me some data how these "10,000 merchants of BitPay, >> millions of users of Blockchain.info , >> Bitcoin.com , Xapo, Coinbase, millions of buyers >> and sellers of OpenBazar? are in favour of b2x? >> >> >> Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org>: >> >> In the grand scheme of things, 10,000 merchants of BitPay, millions of >> users of Blockchain.info , Bitcoin.com >> , Xapo, Coinbase, millions of buyers and sellers of >> OpenBazar, majority of miners do not count but you only count a tiny >> thousand people on a Twitter poll. How funny this is. >> >> If you actually look into Twitter, there are only around a thousand >> people who has the "no2x" tag. Not all of them are trolling. However, >> people who state that those are everything that counts, especially on a >> segwit2x mailing list, is certainly trolling and does not worth any >> people's attention. >> >> Bitcoin will be what majority calls it. Period. >> >> >> Sent with ProtonMail Secure Email. >> >> -------- Original Message -------- >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> Local Time: October 14, 2017 10:32 PM >> UTC Time: October 14, 2017 2:32 PM >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> To: Scott Roberts , >> bitcoin-segwit2x at lists.linuxfoundation.org < >> bitcoin-segwit2x at lists.linuxfoundation.org> >> >> >> In the grand scheme of things, 1,168 responders is not exactly >> representative of the bitcoin community, is it? But that number, for a >> sample size, falls in the range of what is referred to as statistically >> irrelevant. It seems like you?ll have to do even more reading up! >> >> >> >> *From: *Scott Roberts via Bitcoin-segwit2x >> >> *Sent: *14 October 2017 15:25 >> *To: *bitcoin-segwit2x at lists.linuxfoundation.org >> *Subject: *Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> > I have NEVER seen a twitter poll on bitcoin that had a statistically >> relevant sample size. But also bear in mind that by it?s very nature, >> twitter creates bubbles where like minded people follow each other. >> >> >> 1,168 with 30x difference in responses is very significant. Show me >> the twitter bubble where like-minded SegWit2x supporters show their >> support. >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > > -- > > > *Mike Belshe* > *CEO, BitGo, Inc*408-718-6885 > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- John C Bitcoin Error Log www.bitcoinerrorlog.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Sat Oct 14 16:54:31 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Sat, 14 Oct 2017 12:54:31 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: Oh Adam, then enjoy. If the disruption is symmetric you have no argument for segwit2x people to enable strong two-way RP. So stop trolling. Have fun! Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 15, 2017 12:50 AM > UTC Time: October 14, 2017 4:50 PM > From: adam at blockstream.com > To: Cedrick Perrigo > Ben Peters , Peter Todd via Bitcoin-segwit2x > >> all the disruptive part you talked about happens only on the segwit1x altcoin. Segwit2x Bitcoin is not affected. > > the disruption is symmetric. > > Adam > > On Sat, Oct 14, 2017 at 1:50 PM, Cedrick Perrigo > wrote: >> Arguing about strong two-way replay protection is a waste of time for Core. >> People had made clear that won"t happen. You"d better spending time thinking >> about how you would make segwit1x altcoin survive. >> >> Talking about financial/support tickets. More would be complaining why the >> transaction on segwit1x altcoin is not confirmed and why the fee is too >> high. Exchanges will likely not want to handle this, and drop segwit1x >> altcoin support all together. That"s the simple game theory. >> >> Adam, what you didn"t get is that all the disruptive part you talked about >> happens only on the segwit1x altcoin. Segwit2x Bitcoin is not affected. So >> better spend you time on bitcoin-dev discussing with Blockstream devs on how >> to hard fork the difficulty algorithm and add replay protection on the >> segwit1x altcoin. >> >> >> Sent with ProtonMail Secure Email. >> >> -------- Original Message -------- >> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still >> happening? >> Local Time: October 14, 2017 7:19 PM >> UTC Time: October 14, 2017 11:19 AM >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> To: Ben Peters >> Peter Todd via Bitcoin-segwit2x >> >> A lot of what you described doesn"t work the way you seem to expect. >> >> There"s a few levels: >> >> Mining economics: I do some mining, and there are a number of data >> points from alt-coins that share mining algorithms: miners short / mid >> term mine what is profitable. That is driven by relative price. >> Difficulty adjusts to equilibrium. This is a feature, it is the >> incentive that secures blockchains. Bitcoin security works by >> economically incentivised creation of valid blocks as measured by the >> nodes on the network. >> >> Nodes and wallets mechanically todays software: Existing full nodes >> won"t follow. Most smart phone wallets will not automatically switch >> but either ignore a new chain, stop functioning, go into some kind of >> warning state pending bugfix, some older wallets may get stuck on >> random chain. And because there is no proper replay protection >> randomly transactions will be made on one or both chains unless mixed >> with new coinbase over time. That will be pretty disruptive because >> people writing wallet software don"t know what segwit2x code will be >> as they keep changing. Bitcoin cash changed up to 5days before >> release. >> >> Services: Also it"s a big job to defend all existing all existing >> services and wallets. Never the less as both chains have value each >> service and wallet must over time offer some solution even if it is >> replay protected withdrawal. So nothing is achieved in practice vs >> proper replay protection other than disruption. >> >> Due Care & safety: Doing reckless and risky things to the network may >> not be a good advertisement for service or wallet. Users will >> research and make some decision about which wallets and services will >> preserve their coins and allow them to split and sell or hold >> whichever of the 3 or 4 spinoffs are created. People will likely not >> recommend software and services that promote dand advocated for >> creating the disruption and risk. >> >> Financial, support tickets: users will complain via support tickets >> and formal complaints about experience and asset loss as that happens. >> >> Would be interested in proponents views of how their companies (if >> they have users) will handle this, and also how they suppose different >> use cases from other services and wallets will interoperate. >> >> It sort of feels like there is an expected game-theory reaction here >> that no one is talking about, but maybe people have different views of >> what the logical game theory is? >> >> ps please trip replies list posts are bouncing as too large. >> >> Adam >> >> On Sat, Oct 14, 2017 at 2:20 AM, Ben Peters via Bitcoin-segwit2x >> wrote: >>> I think there is a fundamental misunderstanding about the nature of the >>> NYA/Segwit2x endeavour. What is happening here is that an alternative, >>> minimally modified, version of the Bitcoin code is being developed that >>> will >>> implement a change that has long been sought by the mining community and >>> many in industry and beyond (a change that they presumably feel is >>> important >>> for the future success of Bitcoin and thus their respective investments). >>> >>> That candidate code will be offered to the miners and mining pools, who >>> may >>> or may not opt to apply hashing power to it. If they apply more than the >>> threshold amount of hashing power, then that new code will effectively >>> takeover from the previous consensus rule, and take most SPV wallets and >>> economic activity along with it. >>> >>> Rather than lobbying this technical working group to ?call off? their >>> efforts, your time might be better spent lobbying the miners. The function >>> of this group is to produce candidate code, thus fulfilling the >>> obligations >>> as set out under the NYA. >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Sat Oct 14 17:02:18 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Sat, 14 Oct 2017 17:02:18 +0000 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: , Message-ID: The terns of reference for the working group, as has been stated multiple times, is to avoid a network split. Implementing strong 2 way RP would effectively render the agreement voidable as it?d be fostering a network split. From ALL Sybil resistant data available on the blockchain, and despite what core would like everyone else to believe, the risk of a ?viable? split, sans HF by core, though existent is at this particular moment remote. As such, it matter not whether developers that do not want strong 2 way RP are in the minority, what matters is that the client does not render the agreement voidable. From: Bitcoin Error Log via Bitcoin-segwit2x Sent: 14 October 2017 17:50 To: Mike Belshe Cc: bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] We are all bitcoin If you won't accept that a significant portion of Bitcoin does not want this, let's at least address that some of the tech people in NYA-signing businesses, like Jameson Lopp of BitGo, and Alex Petrov of BitFury also disagree with the implementation. Are these companies going to ignore the very people they hired to be knowledgeable? I'd argue a minority of developers overall do not want strong replay protection. You do not have consensus of developers, Core, or not. On Sat, Oct 14, 2017, 6:19 PM Mike Belshe via Bitcoin-segwit2x > wrote: I've banned Scott. On Sat, Oct 14, 2017 at 8:11 AM, Cedrick Perrigo via Bitcoin-segwit2x > wrote: You wonders do not belong to this mailing list. Get those silly speculations elsewhere. It's users deciding to use those services, not the other way around. If users are not happy, they can leave any time. But yet you see, that's not what's happening. Sent with ProtonMail Secure Email. -------- Original Message -------- Subject: Re: [Bitcoin-segwit2x] We are all bitcoin Local Time: October 14, 2017 11:04 PM UTC Time: October 14, 2017 3:04 PM From: segwit2x_mailinglist at bitcoinreminder.com To: Cedrick Perrigo > Phillip Katete >, bitcoin-segwit2x at lists.linuxfoundation.org > If any of them are pro-segwit1x, they should immediately terminate their business with those companies or stop using those wallets. I wonder then why Coinbase, Bitpay,.. etc are not asking its users or telling them to " immediately terminate their business with those companies or stop using those wallets?? I never see people arguing on a Bitcoin Cash mailing list to show which one has the majority support. BCash was professional enough to include replay protection - which is not the case with B2X until now. Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo >: Funny you listed something that only has less than 400 responses. How is that something "objective"? Many people don't care or are neutral to segwit1x vs segwit2x, of course. Businesses and services they use would take them to segwit2x, like the 10,000 merchants and millions of users. If any of them are pro-segwit1x, they should immediately terminate their business with those companies or stop using those wallets. We didn't see it happen. If you truly think those poll counts, why would you still arguing with me on a segwit2x mailing list? It only shows that you're extremely doubtful of your belief. I never see people arguing on a Bitcoin Cash mailing list to show which one has the majority support. Also you missed the counter-argument for "majority of miners". So I assume at least we agree that majority of miners support segwit2x. :) Now this is a technical mailing list. Would trolls please find elsewhere for those nonsense? Sent with ProtonMail Secure Email. -------- Original Message -------- Subject: Re: [Bitcoin-segwit2x] We are all bitcoin Local Time: October 14, 2017 10:48 PM UTC Time: October 14, 2017 2:48 PM From: segwit2x_mailinglist at bitcoinreminder.com To: Cedrick Perrigo > Phillip Katete >, bitcoin-segwit2x at lists.linuxfoundation.org > It?s funny how you imply that "10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? The only sybill resistant poll which I know (even created by data of users from Coinbase!!!) shows that most of the coinbase customers are not in favour of b2x? https://luke.dashjr.org/programs/kycpoll/answers.php This link was twittered on /r/bitcoin, /r/btc and reweeted also by many B2X proponents. So please, show me some data how these "10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x >: In the grand scheme of things, 10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of miners do not count but you only count a tiny thousand people on a Twitter poll. How funny this is. If you actually look into Twitter, there are only around a thousand people who has the "no2x" tag. Not all of them are trolling. However, people who state that those are everything that counts, especially on a segwit2x mailing list, is certainly trolling and does not worth any people's attention. Bitcoin will be what majority calls it. Period. Sent with ProtonMail Secure Email. -------- Original Message -------- Subject: Re: [Bitcoin-segwit2x] We are all bitcoin Local Time: October 14, 2017 10:32 PM UTC Time: October 14, 2017 2:32 PM From: bitcoin-segwit2x at lists.linuxfoundation.org To: Scott Roberts >, bitcoin-segwit2x at lists.linuxfoundation.org > In the grand scheme of things, 1,168 responders is not exactly representative of the bitcoin community, is it? But that number, for a sample size, falls in the range of what is referred to as statistically irrelevant. It seems like you?ll have to do even more reading up! From: Scott Roberts via Bitcoin-segwit2x Sent: 14 October 2017 15:25 To: bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. 1,168 with 30x difference in responses is very significant. Show me the twitter bubble where like-minded SegWit2x supporters show their support. _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -- Mike Belshe CEO, BitGo, Inc 408-718-6885 _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -- John C Bitcoin Error Log www.bitcoinerrorlog.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at bitgo.com Sat Oct 14 17:13:01 2017 From: mike at bitgo.com (Mike Belshe) Date: Sat, 14 Oct 2017 10:13:01 -0700 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: Hey Adam - Your long and winding messages are often hard to follow ;-) A few succinct replies: a) The SPV wallets will follow the longest chain; if Core diverges from the longest chain, Core will be alienating 15+million wallets. I think this is a shame, but I know we disagree. b) Counter to your claim, BTC1 is not changing up to 5 days before the fork. It's an open source project, so I don't control it, but general sentiment is that it is done for now. The team prefers to keep it stable rather than add various opt-in replay protections that both sides seem to not like anyway. c) You claim that "most smart phone wallets" will not follow the longest chain. I believe this is untrue. Can you tell me which wallets you're referring to? Mike On Sat, Oct 14, 2017 at 4:19 AM, Dr Adam Back via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > A lot of what you described doesn't work the way you seem to expect. > > There's a few levels: > > Mining economics: I do some mining, and there are a number of data > points from alt-coins that share mining algorithms: miners short / mid > term mine what is profitable. That is driven by relative price. > Difficulty adjusts to equilibrium. This is a feature, it is the > incentive that secures blockchains. Bitcoin security works by > economically incentivised creation of valid blocks as measured by the > nodes on the network. > > Nodes and wallets mechanically todays software: Existing full nodes > won't follow. Most smart phone wallets will not automatically switch > but either ignore a new chain, stop functioning, go into some kind of > warning state pending bugfix, some older wallets may get stuck on > random chain. And because there is no proper replay protection > randomly transactions will be made on one or both chains unless mixed > with new coinbase over time. That will be pretty disruptive because > people writing wallet software don't know what segwit2x code will be > as they keep changing. Bitcoin cash changed up to 5days before > release. > > Services: Also it's a big job to defend all existing all existing > services and wallets. Never the less as both chains have value each > service and wallet must over time offer some solution even if it is > replay protected withdrawal. So nothing is achieved in practice vs > proper replay protection other than disruption. > > Due Care & safety: Doing reckless and risky things to the network may > not be a good advertisement for service or wallet. Users will > research and make some decision about which wallets and services will > preserve their coins and allow them to split and sell or hold > whichever of the 3 or 4 spinoffs are created. People will likely not > recommend software and services that promote dand advocated for > creating the disruption and risk. > > Financial, support tickets: users will complain via support tickets > and formal complaints about experience and asset loss as that happens. > > Would be interested in proponents views of how their companies (if > they have users) will handle this, and also how they suppose different > use cases from other services and wallets will interoperate. > > It sort of feels like there is an expected game-theory reaction here > that no one is talking about, but maybe people have different views of > what the logical game theory is? > > ps please trip replies list posts are bouncing as too large. > > Adam > > On Sat, Oct 14, 2017 at 2:20 AM, Ben Peters via Bitcoin-segwit2x > wrote: > > I think there is a fundamental misunderstanding about the nature of the > > NYA/Segwit2x endeavour. What is happening here is that an alternative, > > minimally modified, version of the Bitcoin code is being developed that > will > > implement a change that has long been sought by the mining community and > > many in industry and beyond (a change that they presumably feel is > important > > for the future success of Bitcoin and thus their respective investments). > > > > That candidate code will be offered to the miners and mining pools, who > may > > or may not opt to apply hashing power to it. If they apply more than the > > threshold amount of hashing power, then that new code will effectively > > takeover from the previous consensus rule, and take most SPV wallets and > > economic activity along with it. > > > > Rather than lobbying this technical working group to ?call off? their > > efforts, your time might be better spent lobbying the miners. The > function > > of this group is to produce candidate code, thus fulfilling the > obligations > > as set out under the NYA. > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- *Mike Belshe* *CEO, BitGo, Inc*408-718-6885 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjors at sprovoost.nl Sat Oct 14 19:09:20 2017 From: sjors at sprovoost.nl (Sjors Provoost) Date: Sat, 14 Oct 2017 21:09:20 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> Message-ID: <1508008160.1718434.1138834792.3A0A543C@webmail.messagingengine.com> Unupgraded SPV wallets *might* follow the longest chain. This assumption has not been well tested. Perhaps there are private experiments that I'm not aware of. I asked multiple specific questions about the expected behavior of SPV wallets on various pull requests, the answer was generally "not sure, we should probably check". This topic is not well understood (by anyone, not just the SegWit2x team). There's three problems: 1 - the wallet actually needs to find the longest chain in order to follow it 2 - if they initially followed the shorter chain, they may need to handle a very large reorg; typical reorgs are just a few blocks, so these wallets may not have been stress tested for larger reorgs. They crash or misbehave in other ways. 3 - more recent, Luke-Jr proposed a fairly trivial upgrade to SPV wallets that could be rolled out to most users before the fork. It basically tells the wallet to inspect the size of the hard-fork block 494784. The wallet can then give users a choice or default to what the wallet author believes is safe. They might listen to Core for advice, but it's not up to Core. It's worth your (staff's) time trying to understand what Adam is pointing at. As for (b) I have still not heard a formal statement from the SegWit2x leadership that the consensus rules and code are frozen and will not have any replay protection. Of course I don't know what the decision making process is there. Whether code is open source doesn't really matter for such decision making process; I hope the plan isn't to just wait and see which replay protection branch miners run. :-) Sjors On Sat, Oct 14, 2017, at 19:13, Mike Belshe via Bitcoin-segwit2x wrote:> Hey Adam - > > Your long and winding messages are often hard to follow ;-) > > A few succinct replies: > a) The SPV wallets will follow the longest chain; if Core diverges > from the longest chain, Core will be alienating 15+million > wallets. I think this is a shame, but I know we disagree.> > b) Counter to your claim, BTC1 is not changing up to 5 days before > the fork. It's an open source project, so I don't control it, > but general sentiment is that it is done for now. The team > prefers to keep it stable rather than add various opt-in replay > protections that both sides seem to not like anyway.> > c) You claim that "most smart phone wallets" will not follow the > longest chain. I believe this is untrue. Can you tell me which > wallets you're referring to?> > Mike > > > On Sat, Oct 14, 2017 at 4:19 AM, Dr Adam Back via Bitcoin-segwit2x segwit2x at lists.linuxfoundation.org> wrote:>> A lot of what you described doesn't work the way you seem to expect.>> >> There's a few levels: >> >> Mining economics: I do some mining, and there are a number of data >> points from alt-coins that share mining algorithms: miners >> short / mid>> term mine what is profitable. That is driven by relative price. >> Difficulty adjusts to equilibrium. This is a feature, it is the >> incentive that secures blockchains. Bitcoin security works by >> economically incentivised creation of valid blocks as measured >> by the>> nodes on the network. >> >> Nodes and wallets mechanically todays software: Existing full nodes>> won't follow. Most smart phone wallets will not automatically >> switch>> but either ignore a new chain, stop functioning, go into some >> kind of>> warning state pending bugfix, some older wallets may get stuck on >> random chain. And because there is no proper replay protection >> randomly transactions will be made on one or both chains >> unless mixed>> with new coinbase over time. That will be pretty disruptive because>> people writing wallet software don't know what segwit2x code will be>> as they keep changing. Bitcoin cash changed up to 5days before >> release. >> >> Services: Also it's a big job to defend all existing all existing >> services and wallets. Never the less as both chains have value each>> service and wallet must over time offer some solution even if it is>> replay protected withdrawal. So nothing is achieved in practice vs>> proper replay protection other than disruption. >> >> Due Care & safety: Doing reckless and risky things to the >> network may>> not be a good advertisement for service or wallet. Users will >> research and make some decision about which wallets and >> services will>> preserve their coins and allow them to split and sell or hold >> whichever of the 3 or 4 spinoffs are created. People will >> likely not>> recommend software and services that promote dand advocated for >> creating the disruption and risk. >> >> Financial, support tickets: users will complain via support tickets>> and formal complaints about experience and asset loss as that >> happens.>> >> Would be interested in proponents views of how their companies (if >> they have users) will handle this, and also how they suppose >> different>> use cases from other services and wallets will interoperate. >> >> It sort of feels like there is an expected game-theory reaction here>> that no one is talking about, but maybe people have different >> views of>> what the logical game theory is? >> >> ps please trip replies list posts are bouncing as too large. >> >> Adam >> >> On Sat, Oct 14, 2017 at 2:20 AM, Ben Peters via Bitcoin-segwit2x > segwit2x at lists.linuxfoundation.org> wrote: >> > I think there is a fundamental misunderstanding about the nature >> > of the NYA/Segwit2x endeavour. What is happening here is that an >> > alternative, minimally modified, version of the Bitcoin code is >> > being developed that will implement a change that has long been >> > sought by the mining community and many in industry and beyond (a >> > change that they presumably feel is important for the future >> > success of Bitcoin and thus their respective investments). >> > >> > That candidate code will be offered to the miners and mining >> > pools, who may or may not opt to apply hashing power to it. If >> > they apply more than the threshold amount of hashing power, then >> > that new code will effectively takeover from the previous >> > consensus rule, and take most SPV wallets and economic activity >> > along with it. >> > >> > Rather than lobbying this technical working group to ?call off? >> > their efforts, your time might be better spent lobbying the >> > miners. The function of this group is to produce candidate code, >> > thus fulfilling the obligations as set out under the NYA. >> >>> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > -- > *Mike Belshe **CEO, BitGo, Inc *408-718-6885 > _________________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at blockstream.com Sat Oct 14 19:12:46 2017 From: adam at blockstream.com (Dr Adam Back) Date: Sat, 14 Oct 2017 21:12:46 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: <1508008160.1718434.1138834792.3A0A543C@webmail.messagingengine.com> References: <51A8F892-3BA9-45A8-8987-D66D6E8C5A72@icloud.com> <32a90681-0160-41ec-f018-e7def1cf232c@bitcoin.com> <8E765460-59BF-468B-A568-49927E4777DF@bitcoinreminder.com> <1508008160.1718434.1138834792.3A0A543C@webmail.messagingengine.com> Message-ID: Here's breadwallet's summary of how they so far think two networks may behave for their SPV wallet. https://breadapp.com/blog/how-bread-will-handle-segwit2x-fork-november/ Adam On Sat, Oct 14, 2017 at 9:09 PM, Sjors Provoost via Bitcoin-segwit2x wrote: > Unupgraded SPV wallets *might* follow the longest chain. > > This assumption has not been well tested. Perhaps there are private > experiments that I'm not aware of. I asked multiple specific questions about > the expected behavior of SPV wallets on various pull requests, the answer > was generally "not sure, we should probably check". This topic is not well > understood (by anyone, not just the SegWit2x team). > > There's three problems: > > 1 - the wallet actually needs to find the longest chain in order to follow > it > > 2 - if they initially followed the shorter chain, they may need to handle a > very large reorg; typical reorgs are just a few blocks, so these wallets may > not have been stress tested for larger reorgs. They crash or misbehave in > other ways. > > 3 - more recent, Luke-Jr proposed a fairly trivial upgrade to SPV wallets > that could be rolled out to most users before the fork. It basically tells > the wallet to inspect the size of the hard-fork block 494784. The wallet can > then give users a choice or default to what the wallet author believes is > safe. They might listen to Core for advice, but it's not up to Core. > > It's worth your (staff's) time trying to understand what Adam is pointing > at. > > As for (b) I have still not heard a formal statement from the SegWit2x > leadership that the consensus rules and code are frozen and will not have > any replay protection. Of course I don't know what the decision making > process is there. Whether code is open source doesn't really matter for such > decision making process; I hope the plan isn't to just wait and see which > replay protection branch miners run. :-) > > Sjors > > On Sat, Oct 14, 2017, at 19:13, Mike Belshe via Bitcoin-segwit2x wrote: > > Hey Adam - > > Your long and winding messages are often hard to follow ;-) > > A few succinct replies: > a) The SPV wallets will follow the longest chain; if Core diverges from > the longest chain, Core will be alienating 15+million wallets. I think this > is a shame, but I know we disagree. > > b) Counter to your claim, BTC1 is not changing up to 5 days before the > fork. It's an open source project, so I don't control it, but general > sentiment is that it is done for now. The team prefers to keep it stable > rather than add various opt-in replay protections that both sides seem to > not like anyway. > > c) You claim that "most smart phone wallets" will not follow the longest > chain. I believe this is untrue. Can you tell me which wallets you're > referring to? > > Mike > > > On Sat, Oct 14, 2017 at 4:19 AM, Dr Adam Back via Bitcoin-segwit2x > wrote: > > A lot of what you described doesn't work the way you seem to expect. > > There's a few levels: > > Mining economics: I do some mining, and there are a number of data > points from alt-coins that share mining algorithms: miners short / mid > term mine what is profitable. That is driven by relative price. > Difficulty adjusts to equilibrium. This is a feature, it is the > incentive that secures blockchains. Bitcoin security works by > economically incentivised creation of valid blocks as measured by the > nodes on the network. > > Nodes and wallets mechanically todays software: Existing full nodes > won't follow. Most smart phone wallets will not automatically switch > but either ignore a new chain, stop functioning, go into some kind of > warning state pending bugfix, some older wallets may get stuck on > random chain. And because there is no proper replay protection > randomly transactions will be made on one or both chains unless mixed > with new coinbase over time. That will be pretty disruptive because > people writing wallet software don't know what segwit2x code will be > as they keep changing. Bitcoin cash changed up to 5days before > release. > > Services: Also it's a big job to defend all existing all existing > services and wallets. Never the less as both chains have value each > service and wallet must over time offer some solution even if it is > replay protected withdrawal. So nothing is achieved in practice vs > proper replay protection other than disruption. > > Due Care & safety: Doing reckless and risky things to the network may > not be a good advertisement for service or wallet. Users will > research and make some decision about which wallets and services will > preserve their coins and allow them to split and sell or hold > whichever of the 3 or 4 spinoffs are created. People will likely not > recommend software and services that promote dand advocated for > creating the disruption and risk. > > Financial, support tickets: users will complain via support tickets > and formal complaints about experience and asset loss as that happens. > > Would be interested in proponents views of how their companies (if > they have users) will handle this, and also how they suppose different > use cases from other services and wallets will interoperate. > > It sort of feels like there is an expected game-theory reaction here > that no one is talking about, but maybe people have different views of > what the logical game theory is? > > ps please trip replies list posts are bouncing as too large. > > Adam > > On Sat, Oct 14, 2017 at 2:20 AM, Ben Peters via Bitcoin-segwit2x > wrote: >> I think there is a fundamental misunderstanding about the nature of the >> NYA/Segwit2x endeavour. What is happening here is that an alternative, >> minimally modified, version of the Bitcoin code is being developed that >> will >> implement a change that has long been sought by the mining community and >> many in industry and beyond (a change that they presumably feel is >> important >> for the future success of Bitcoin and thus their respective investments). >> >> That candidate code will be offered to the miners and mining pools, who >> may >> or may not opt to apply hashing power to it. If they apply more than the >> threshold amount of hashing power, then that new code will effectively >> takeover from the previous consensus rule, and take most SPV wallets and >> economic activity along with it. >> >> Rather than lobbying this technical working group to ?call off? their >> efforts, your time might be better spent lobbying the miners. The function >> of this group is to produce candidate code, thus fulfilling the >> obligations >> as set out under the NYA. >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > -- > > Mike Belshe > CEO, BitGo, Inc > 408-718-6885 > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From bitpico at icloud.com Sat Oct 14 22:49:41 2017 From: bitpico at icloud.com (bitPico) Date: Sat, 14 Oct 2017 18:49:41 -0400 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: <3310EDD1-3D6F-45B7-9FB6-743ED9E50C74@icloud.com> The weaker chain (if it survives) MUST implement replay protection. The stronger chain does nothing. BreadWallet devs said similar. We are not implementing it into our non-Satoshi codebase and neither is any other 2x implementations. Bitcoin Core Developers already stated they will make a rage move instead of their previous statement of rage quitting and moving on to other projects. Most likely a change to their Proof-of-Work is coming (their own words). Some people are encouraging a chain split for financial gains which makes the cryptocurrency environment more toxic than it already is... > On Oct 14, 2017, at 1:02 PM, Phillip Katete via Bitcoin-segwit2x wrote: > > The terns of reference for the working group, as has been stated multiple times, is to avoid a network split. Implementing strong 2 way RP would effectively render the agreement voidable as it?d be fostering a network split. From ALL Sybil resistant data available on the blockchain, and despite what core would like everyone else to believe, the risk of a ?viable? split, sans HF by core, though existent is at this particular moment remote. As such, it matter not whether developers that do not want strong 2 way RP are in the minority, what matters is that the client does not render the agreement voidable. > > From: Bitcoin Error Log via Bitcoin-segwit2x > Sent: 14 October 2017 17:50 > To: Mike Belshe > Cc: bitcoin-segwit2x at lists.linuxfoundation.org > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > > If you won't accept that a significant portion of Bitcoin does not want this, let's at least address that some of the tech people in NYA-signing businesses, like Jameson Lopp of BitGo, and Alex Petrov of BitFury also disagree with the implementation. Are these companies going to ignore the very people they hired to be knowledgeable? > > I'd argue a minority of developers overall do not want strong replay protection. You do not have consensus of developers, Core, or not. > > > On Sat, Oct 14, 2017, 6:19 PM Mike Belshe via Bitcoin-segwit2x wrote: > I've banned Scott. > > On Sat, Oct 14, 2017 at 8:11 AM, Cedrick Perrigo via Bitcoin-segwit2x wrote: > You wonders do not belong to this mailing list. Get those silly speculations elsewhere. > > It's users deciding to use those services, not the other way around. If users are not happy, they can leave any time. But yet you see, that's not what's happening. > > > Sent with ProtonMail Secure Email. > > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > Local Time: October 14, 2017 11:04 PM > UTC Time: October 14, 2017 3:04 PM > From: segwit2x_mailinglist at bitcoinreminder.com > To: Cedrick Perrigo > Phillip Katete , bitcoin-segwit2x at lists.linuxfoundation.org > > If any of them are pro-segwit1x, they should immediately terminate their business with those companies or stop using those wallets. > > I wonder then why Coinbase, Bitpay,.. etc are not asking its users or telling them to " immediately terminate their business with those companies or stop using those wallets?? > > > I never see people arguing on a Bitcoin Cash mailing list to show which one has the majority support. > > BCash was professional enough to include replay protection - which is not the case with B2X until now. > > Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo : > > Funny you listed something that only has less than 400 responses. How is that something "objective"? > > Many people don't care or are neutral to segwit1x vs segwit2x, of course. Businesses and services they use would take them to segwit2x, like the 10,000 merchants and millions of users. If any of them are pro-segwit1x, they should immediately terminate their business with those companies or stop using those wallets. We didn't see it happen. > > If you truly think those poll counts, why would you still arguing with me on a segwit2x mailing list? It only shows that you're extremely doubtful of your belief. I never see people arguing on a Bitcoin Cash mailing list to show which one has the majority support. > > Also you missed the counter-argument for "majority of miners". So I assume at least we agree that majority of miners support segwit2x. :) > > Now this is a technical mailing list. Would trolls please find elsewhere for those nonsense? > > > Sent with ProtonMail Secure Email. > > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > Local Time: October 14, 2017 10:48 PM > UTC Time: October 14, 2017 2:48 PM > From: segwit2x_mailinglist at bitcoinreminder.com > To: Cedrick Perrigo > Phillip Katete , bitcoin-segwit2x at lists.linuxfoundation.org > > It?s funny how you imply that "10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? > > The only sybill resistant poll which I know (even created by data of users from Coinbase!!!) shows that most of the coinbase customers are not in favour of b2x? > > https://luke.dashjr.org/programs/kycpoll/answers.php > > This link was twittered on /r/bitcoin, /r/btc and reweeted also by many B2X proponents. > > So please, show me some data how these "10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? > > > Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x : > > In the grand scheme of things, 10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of miners do not count but you only count a tiny thousand people on a Twitter poll. How funny this is. > > If you actually look into Twitter, there are only around a thousand people who has the "no2x" tag. Not all of them are trolling. However, people who state that those are everything that counts, especially on a segwit2x mailing list, is certainly trolling and does not worth any people's attention. > > Bitcoin will be what majority calls it. Period. > > > Sent with ProtonMail Secure Email. > > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > Local Time: October 14, 2017 10:32 PM > UTC Time: October 14, 2017 2:32 PM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: Scott Roberts , bitcoin-segwit2x at lists.linuxfoundation.org > > > In the grand scheme of things, 1,168 responders is not exactly representative of the bitcoin community, is it? But that number, for a sample size, falls in the range of what is referred to as statistically irrelevant. It seems like you?ll have to do even more reading up! > > > From: Scott Roberts via Bitcoin-segwit2x > Sent: 14 October 2017 15:25 > To: bitcoin-segwit2x at lists.linuxfoundation.org > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > > > > I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. > > > 1,168 with 30x difference in responses is very significant. Show me > the twitter bubble where like-minded SegWit2x supporters show their > support. > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > -- > Mike Belshe > CEO, BitGo, Inc > 408-718-6885 > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- > > John C > Bitcoin Error Log > www.bitcoinerrorlog.com > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at blockstream.com Sun Oct 15 12:20:15 2017 From: adam at blockstream.com (Dr Adam Back) Date: Sun, 15 Oct 2017 14:20:15 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: <20171015115753.aakyynd4czxvej4s@fedora-23-dvm> References: <20171015115753.aakyynd4czxvej4s@fedora-23-dvm> Message-ID: My other point was as per breadwallet's explanation of the malfunctions they so far expect of their SPV wallet, which chain followed is chaotic and dynamic because the Bitcoin nodes will ban nodes that send them invalid blocks, and phone wallets select nodes somewhat at random from peer caches and seeds. It is a dynamic and high risk situation, and also existing wallets will be changing in a rush to avert disaster so that there is not a stationary behaviour to test with. (Most phone wallets have auto upgrade features). The node ban has bi-directional effect, but given Bitcoin2x lacks wipe-out protection there is risk of full re-org incurring funds loss for 2X users. Greg Maxwell wrote about some other scenarios here https://www.reddit.com/r/Bitcoin/comments/7465sd/btc1_just_merged_the_ability_for_segwit2x_to/dnw2djt/ The full matrix of what can fail in this dynamic situation not fully understood and analysed (by anyone). Ben Davenport and James Lopp (CTO and lead architect at BitGo), are also warning about these kinds of issues. Adam On Sun, Oct 15, 2017 at 1:57 PM, David A. Harding wrote: > On Sat, Oct 14, 2017 at 10:13:01AM -0700, Mike Belshe via Bitcoin-segwit2x wrote: >> a) The SPV wallets will follow the longest chain >> [...] >> c) You claim that "most smart phone wallets" will not follow the longest >> chain. I believe this is untrue. Can you tell me which wallets you're >> referring to? > > I'm not Adam, and I don't even know if these two points were supposed to > be related, but I did want to note that several SPV wallets don't use > the peer-to-peer network even though they do check SPV inclusion proofs. > > For example, an Electrum wallet connects to an Electrum server that > itself gets information from a particular Bitcoin Core-compatible full > node (Core, ABC, Unlimited, btc1, etc). > > Wallet <-> Electrum Server <-> Node > > Whatever node the server operates determines which chain the wallet user > sees transactions for. Electrum does provide SPV proofs to wallets to > prove to the user that their transactions connect to the node's header > chain, and there is a secure initial header download that prevents > someone from tricking clients with a difficulty-1 chain, but ultimately > Electron users don't necessarily follow the strongest chain. > > We saw this particularly at work during the 4 and 5 July 2015 accidental > forks where some pre-0.10 Electrum servers would return the invalid > chain and some 0.10+ servers would return the valid chain. > > Of the 11 mobile wallets currently listed on > https://bitcoin.org/en/choose-your-wallet, five connect to the P2P network > directly and so are likely to follow the strongest valid chain of headers > they see[1]: > > user at devbco:~/bitcoin.org/_wallets$ git grep -l 'compat.*mobile' | xargs grep -l spvp2p > bitcoinwallet.md > bither.md > breadwallet.md > greenbits.md > simplebitcoinwallet.md > > Seven do not use the P2P network and will not follow a chain their > server's nodes consider invalid. > > user at devbco:~/bitcoin.org/_wallets$ git grep -l 'compat.*mobile' | xargs grep -L spvp2p > airbitzwallet.md > arcbit.md > coinspace.md > electrum.md > greenaddress.md > mycelium.md > > This is obviously not a comprehensive survey of all mobile wallets. > > Hopefully that helps, > > -Dave > > [1] As discussed elsewhere in this thread, this may not necessarily be > the strongest chain in existence if the P2P SPV clients are unable to > connect to nodes serving that chain. From dave at dtrt.org Sun Oct 15 11:57:53 2017 From: dave at dtrt.org (David A. Harding) Date: Sun, 15 Oct 2017 07:57:53 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: Message-ID: <20171015115753.aakyynd4czxvej4s@fedora-23-dvm> On Sat, Oct 14, 2017 at 10:13:01AM -0700, Mike Belshe via Bitcoin-segwit2x wrote: > a) The SPV wallets will follow the longest chain > [...] > c) You claim that "most smart phone wallets" will not follow the longest > chain. I believe this is untrue. Can you tell me which wallets you're > referring to? I'm not Adam, and I don't even know if these two points were supposed to be related, but I did want to note that several SPV wallets don't use the peer-to-peer network even though they do check SPV inclusion proofs. For example, an Electrum wallet connects to an Electrum server that itself gets information from a particular Bitcoin Core-compatible full node (Core, ABC, Unlimited, btc1, etc). Wallet <-> Electrum Server <-> Node Whatever node the server operates determines which chain the wallet user sees transactions for. Electrum does provide SPV proofs to wallets to prove to the user that their transactions connect to the node's header chain, and there is a secure initial header download that prevents someone from tricking clients with a difficulty-1 chain, but ultimately Electron users don't necessarily follow the strongest chain. We saw this particularly at work during the 4 and 5 July 2015 accidental forks where some pre-0.10 Electrum servers would return the invalid chain and some 0.10+ servers would return the valid chain. Of the 11 mobile wallets currently listed on https://bitcoin.org/en/choose-your-wallet, five connect to the P2P network directly and so are likely to follow the strongest valid chain of headers they see[1]: user at devbco:~/bitcoin.org/_wallets$ git grep -l 'compat.*mobile' | xargs grep -l spvp2p bitcoinwallet.md bither.md breadwallet.md greenbits.md simplebitcoinwallet.md Seven do not use the P2P network and will not follow a chain their server's nodes consider invalid. user at devbco:~/bitcoin.org/_wallets$ git grep -l 'compat.*mobile' | xargs grep -L spvp2p airbitzwallet.md arcbit.md coinspace.md electrum.md greenaddress.md mycelium.md This is obviously not a comprehensive survey of all mobile wallets. Hopefully that helps, -Dave [1] As discussed elsewhere in this thread, this may not necessarily be the strongest chain in existence if the P2P SPV clients are unable to connect to nodes serving that chain. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kekcoin at protonmail.com Sun Oct 15 12:41:33 2017 From: kekcoin at protonmail.com (Kekcoin) Date: Sun, 15 Oct 2017 08:41:33 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <20171015115753.aakyynd4czxvej4s@fedora-23-dvm> Message-ID: > Bitcoin2x lacks wipe-out protection Incorrect, B2X has wipeout protection in the form of a "must be big" requirement on the hardfork-blockheight. See https://github.com/btc1/bitcoin/pull/50 Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 15, 2017 12:20 PM > UTC Time: October 15, 2017 12:20 PM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: David A. Harding > Bitcoin-segwit2x > > My other point was as per breadwallet"s explanation of the > malfunctions they so far expect of their SPV wallet, which chain > followed is chaotic and dynamic because the Bitcoin nodes will ban > nodes that send them invalid blocks, and phone wallets select nodes > somewhat at random from peer caches and seeds. > > It is a dynamic and high risk situation, and also existing wallets > will be changing in a rush to avert disaster so that there is not a > stationary behaviour to test with. (Most phone wallets have auto > upgrade features). > > The node ban has bi-directional effect, but given Bitcoin2x lacks > wipe-out protection there is risk of full re-org incurring funds loss > for 2X users. > > Greg Maxwell wrote about some other scenarios here > https://www.reddit.com/r/Bitcoin/comments/7465sd/btc1_just_merged_the_ability_for_segwit2x_to/dnw2djt/ > > The full matrix of what can fail in this dynamic situation not fully > understood and analysed (by anyone). > > Ben Davenport and James Lopp (CTO and lead architect at BitGo), are > also warning about these kinds of issues. > > Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjors at sprovoost.nl Sun Oct 15 14:01:46 2017 From: sjors at sprovoost.nl (Sjors Provoost) Date: Sun, 15 Oct 2017 16:01:46 +0200 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: References: <20171015115753.aakyynd4czxvej4s@fedora-23-dvm> Message-ID: <611D8568-FF69-46F2-9F42-FC5176562B69@sprovoost.nl> There's a confusion about the term wipeout here. A full node, or a modified SPV wallet which explicitly checks the forking block, can use the "must [not] be big" requirement. If the 1x chain overtakes the 2x chain and such a node becomes aware of the 1x chain again, it will stay on the 2x chain. But an SPV wallet that doesn't check the block size and isn't behind a trusted node, would switch back to the 1x chain again. From the point of view of its user, their transaction history is wiped out. They could of course still export their private keys and use a full node wallet on either chain. This second scenario is less bad than a "true" wipe-out, where neither a 1x or a 2x full node would recognize the transaction history as valid. We should probably call this phenomon something else, to make it clear the SPV wallet got broken, but the funds are fine (ignoring replay issues). Maybe chain-snapping? Sjors > Op 15 okt. 2017, om 14:41 heeft Kekcoin via Bitcoin-segwit2x het volgende geschreven: > > > Bitcoin2x lacks wipe-out protection > > Incorrect, B2X has wipeout protection in the form of a "must be big" requirement on the hardfork-blockheight. See https://github.com/btc1/bitcoin/pull/50 > > > Sent with ProtonMail Secure Email. > >> -------- Original Message -------- >> Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? >> Local Time: October 15, 2017 12:20 PM >> UTC Time: October 15, 2017 12:20 PM >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> To: David A. Harding >> Bitcoin-segwit2x >> >> My other point was as per breadwallet"s explanation of the >> malfunctions they so far expect of their SPV wallet, which chain >> followed is chaotic and dynamic because the Bitcoin nodes will ban >> nodes that send them invalid blocks, and phone wallets select nodes >> somewhat at random from peer caches and seeds. >> >> It is a dynamic and high risk situation, and also existing wallets >> will be changing in a rush to avert disaster so that there is not a >> stationary behaviour to test with. (Most phone wallets have auto >> upgrade features). >> >> The node ban has bi-directional effect, but given Bitcoin2x lacks >> wipe-out protection there is risk of full re-org incurring funds loss >> for 2X users. >> >> Greg Maxwell wrote about some other scenarios here >> https://www.reddit.com/r/Bitcoin/comments/7465sd/btc1_just_merged_the_ability_for_segwit2x_to/dnw2djt/ >> >> The full matrix of what can fail in this dynamic situation not fully >> understood and analysed (by anyone). >> >> Ben Davenport and James Lopp (CTO and lead architect at BitGo), are >> also warning about these kinds of issues. >> >> Adam > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From kekcoin at protonmail.com Sun Oct 15 14:59:01 2017 From: kekcoin at protonmail.com (Kekcoin) Date: Sun, 15 Oct 2017 10:59:01 -0400 Subject: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? In-Reply-To: <611D8568-FF69-46F2-9F42-FC5176562B69@sprovoost.nl> References: <20171015115753.aakyynd4czxvej4s@fedora-23-dvm> <611D8568-FF69-46F2-9F42-FC5176562B69@sprovoost.nl> Message-ID: Right, "SPV wipeout protection" is inherently impossible for any 2X-agnostic wallet (a big target demographic for Jeff Garzik et al.) I would venture that this situation (weak wipeout protection) might be worse than no wipeout protection at all, as it is hypothetically possible that the two chains keep overtaking each other in terms of most work, and SPV wallets keep jumping back and forth. Let's hope that all wallets build in 2X-awareness to head off this attack vector. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] F2Pool backing out of NYA - Fork still happening? > Local Time: October 15, 2017 2:01 PM > UTC Time: October 15, 2017 2:01 PM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: bitcoin-segwit2x at lists.linuxfoundation.org > > There's a confusion about the term wipeout here. > > A full node, or a modified SPV wallet which explicitly checks the forking block, can use the "must [not] be big" requirement. If the 1x chain overtakes the 2x chain and such a node becomes aware of the 1x chain again, it will stay on the 2x chain. > > But an SPV wallet that doesn't check the block size and isn't behind a trusted node, would switch back to the 1x chain again. From the point of view of its user, their transaction history is wiped out. They could of course still export their private keys and use a full node wallet on either chain. > > This second scenario is less bad than a "true" wipe-out, where neither a 1x or a 2x full node would recognize the transaction history as valid. We should probably call this phenomon something else, to make it clear the SPV wallet got broken, but the funds are fine (ignoring replay issues). Maybe chain-snapping? > > Sjors -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Mon Oct 16 00:19:48 2017 From: chris at suredbits.com (Chris Stewart) Date: Sun, 15 Oct 2017 19:19:48 -0500 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: >The terns of reference for the working group, as has been stated multiple times, is to avoid a network split. If there is consensus on one thing, I think we can all admit there is going to be a network split. Therefore, if this working group insists on creating an altcoin, it should have strong 2 way replay protection. -Chris On Sat, Oct 14, 2017 at 12:02 PM, Phillip Katete via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > The terns of reference for the working group, as has been stated multiple > times, is to avoid a network split. Implementing strong 2 way RP would > effectively render the agreement voidable as it?d be fostering a network > split. From ALL Sybil resistant data available on the blockchain, and > despite what core would like everyone else to believe, the risk of a > ?viable? split, sans HF by core, though existent is at this particular > moment remote. As such, it matter not whether developers that do not want > strong 2 way RP are in the minority, what matters is that the client does > not render the agreement voidable. > > > > *From: *Bitcoin Error Log via Bitcoin-segwit2x > > *Sent: *14 October 2017 17:50 > *To: *Mike Belshe > *Cc: *bitcoin-segwit2x at lists.linuxfoundation.org > > *Subject: *Re: [Bitcoin-segwit2x] We are all bitcoin > > > > If you won't accept that a significant portion of Bitcoin does not want > this, let's at least address that some of the tech people in NYA-signing > businesses, like Jameson Lopp of BitGo, and Alex Petrov of BitFury also > disagree with the implementation. Are these companies going to ignore the > very people they hired to be knowledgeable? > > I'd argue a minority of developers overall do not want strong replay > protection. You do not have consensus of developers, Core, or not. > > > > On Sat, Oct 14, 2017, 6:19 PM Mike Belshe via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > I've banned Scott. > > > > On Sat, Oct 14, 2017 at 8:11 AM, Cedrick Perrigo via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > You wonders do not belong to this mailing list. Get those silly > speculations elsewhere. > > > > It's users deciding to use those services, not the other way around. If > users are not happy, they can leave any time. But yet you see, that's not > what's happening. > > > > > > Sent with ProtonMail > > Secure Email. > > > > -------- Original Message -------- > > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > > Local Time: October 14, 2017 11:04 PM > > UTC Time: October 14, 2017 3:04 PM > > From: segwit2x_mailinglist at bitcoinreminder.com > > To: Cedrick Perrigo > > Phillip Katete , bitcoin-segwit2x at lists. > linuxfoundation.org > > > > If any of them are pro-segwit1x, they should immediately terminate their > business with those companies or stop using those wallets. > > > > I wonder then why Coinbase, Bitpay,.. etc are not asking its users or > telling them to " immediately terminate their business with those companies > or stop using those wallets?? > > > > > > I never see people arguing on a Bitcoin Cash mailing list to show which > one has the majority support. > > > > BCash was professional enough to include replay protection - which is not > the case with B2X until now. > > > > Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo < > cedrickperrigo at protonmail.com>: > > > > Funny you listed something that only has less than 400 responses. How is > that something "objective"? > > > > Many people don't care or are neutral to segwit1x vs segwit2x, of course. > Businesses and services they use would take them to segwit2x, like the > 10,000 merchants and millions of users. If any of them are pro-segwit1x, > they should immediately terminate their business with those companies or > stop using those wallets. We didn't see it happen. > > > > If you truly think those poll counts, why would you still arguing with me > on a segwit2x mailing list? It only shows that you're extremely doubtful of > your belief. I never see people arguing on a Bitcoin Cash mailing list to > show which one has the majority support. > > > > Also you missed the counter-argument for "majority of miners". So I assume > at least we agree that majority of miners support segwit2x. :) > > > > Now this is a technical mailing list. Would trolls please find elsewhere > for those nonsense? > > > > > > Sent with ProtonMail > > Secure Email. > > > > -------- Original Message -------- > > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > > Local Time: October 14, 2017 10:48 PM > > UTC Time: October 14, 2017 2:48 PM > > From: segwit2x_mailinglist at bitcoinreminder.com > > To: Cedrick Perrigo > > Phillip Katete , bitcoin-segwit2x at lists. > linuxfoundation.org > > > > It?s funny how you imply that "10,000 merchants of BitPay, millions of > users of Blockchain.info > > , Bitcoin.com > , > Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour > of b2x? > > > > The only sybill resistant poll which I know (even created by data of users > from Coinbase!!!) shows that most of the coinbase customers are not in > favour of b2x? > > > > https://luke.dashjr.org/programs/kycpoll/answers.php > > > > > This link was twittered on /r/bitcoin, /r/btc and reweeted also by many > B2X proponents. > > > > So please, show me some data how these "10,000 merchants of BitPay, > millions of users of Blockchain.info > > , Bitcoin.com > , > Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour > of b2x? > > > > > > Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org>: > > > > In the grand scheme of things, 10,000 merchants of BitPay, millions of > users of Blockchain.info > , > Bitcoin.com > , > Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of > miners do not count but you only count a tiny thousand people on a Twitter > poll. How funny this is. > > > > If you actually look into Twitter, there are only around a thousand people > who has the "no2x" tag. Not all of them are trolling. However, people who > state that those are everything that counts, especially on a segwit2x > mailing list, is certainly trolling and does not worth any people's > attention. > > > > Bitcoin will be what majority calls it. Period. > > > > > > Sent with ProtonMail > > Secure Email. > > > > -------- Original Message -------- > > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > > Local Time: October 14, 2017 10:32 PM > > UTC Time: October 14, 2017 2:32 PM > > From: bitcoin-segwit2x at lists.linuxfoundation.org > > To: Scott Roberts , bitcoin-segwit2x at lists. > linuxfoundation.org > > > > > > In the grand scheme of things, 1,168 responders is not exactly > representative of the bitcoin community, is it? But that number, for a > sample size, falls in the range of what is referred to as statistically > irrelevant. It seems like you?ll have to do even more reading up! > > > > > > *From: *Scott Roberts via Bitcoin-segwit2x > > > *Sent: *14 October 2017 15:25 > > *To: *bitcoin-segwit2x at lists.linuxfoundation.org > > *Subject: *Re: [Bitcoin-segwit2x] We are all bitcoin > > > > > > > I have NEVER seen a twitter poll on bitcoin that had a statistically > relevant sample size. But also bear in mind that by it?s very nature, > twitter creates bubbles where like minded people follow each other. > > > 1,168 with 30x difference in responses is very significant. Show me > the twitter bubble where like-minded SegWit2x supporters show their > support. > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists. > linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x& > data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0% > 7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata= > 2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > > -- > > > > *Mike Belshe CEO, BitGo, Inc *408-718-6885 <(408)%20718-6885> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > -- > > > John C > > Bitcoin Error Log > > www.bitcoinerrorlog.com > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaredr26 at gmail.com Mon Oct 16 00:23:14 2017 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Sun, 15 Oct 2017 17:23:14 -0700 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: > I think we can all admit there is going to be a network split. Network split != altcoin. 2x is Bitcoin. Bitcoin does not need protection against Bitcoin. If the legacy chains survives as a minority, it can add replay protection as the minority chain. If 2x is the minority chain, it'll fade, it is not BCH. With more than 85% signaling, that is not likely. Jared On Sun, Oct 15, 2017 at 5:19 PM, Chris Stewart via Bitcoin-segwit2x wrote: >>The terns of reference for the working group, as has been stated multiple >> times, is to avoid a network split. > > If there is consensus on one thing, I think we can all admit there is going > to be a network split. > > Therefore, if this working group insists on creating an altcoin, it should > have strong 2 way replay protection. > > -Chris > > > > On Sat, Oct 14, 2017 at 12:02 PM, Phillip Katete via Bitcoin-segwit2x > wrote: >> >> The terns of reference for the working group, as has been stated multiple >> times, is to avoid a network split. Implementing strong 2 way RP would >> effectively render the agreement voidable as it?d be fostering a network >> split. From ALL Sybil resistant data available on the blockchain, and >> despite what core would like everyone else to believe, the risk of a >> ?viable? split, sans HF by core, though existent is at this particular >> moment remote. As such, it matter not whether developers that do not want >> strong 2 way RP are in the minority, what matters is that the client does >> not render the agreement voidable. >> >> >> >> From: Bitcoin Error Log via Bitcoin-segwit2x >> Sent: 14 October 2017 17:50 >> To: Mike Belshe >> Cc: bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> If you won't accept that a significant portion of Bitcoin does not want >> this, let's at least address that some of the tech people in NYA-signing >> businesses, like Jameson Lopp of BitGo, and Alex Petrov of BitFury also >> disagree with the implementation. Are these companies going to ignore the >> very people they hired to be knowledgeable? >> >> I'd argue a minority of developers overall do not want strong replay >> protection. You do not have consensus of developers, Core, or not. >> >> >> >> On Sat, Oct 14, 2017, 6:19 PM Mike Belshe via Bitcoin-segwit2x >> wrote: >> >> I've banned Scott. >> >> >> >> On Sat, Oct 14, 2017 at 8:11 AM, Cedrick Perrigo via Bitcoin-segwit2x >> wrote: >> >> You wonders do not belong to this mailing list. Get those silly >> speculations elsewhere. >> >> >> >> It's users deciding to use those services, not the other way around. If >> users are not happy, they can leave any time. But yet you see, that's not >> what's happening. >> >> >> >> >> >> Sent with ProtonMail Secure Email. >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> Local Time: October 14, 2017 11:04 PM >> >> UTC Time: October 14, 2017 3:04 PM >> >> From: segwit2x_mailinglist at bitcoinreminder.com >> >> To: Cedrick Perrigo >> >> Phillip Katete , >> bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> If any of them are pro-segwit1x, they should immediately terminate their >> business with those companies or stop using those wallets. >> >> >> >> I wonder then why Coinbase, Bitpay,.. etc are not asking its users or >> telling them to " immediately terminate their business with those companies >> or stop using those wallets?? >> >> >> >> >> >> I never see people arguing on a Bitcoin Cash mailing list to show which >> one has the majority support. >> >> >> >> BCash was professional enough to include replay protection - which is not >> the case with B2X until now. >> >> >> >> Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo >> : >> >> >> >> Funny you listed something that only has less than 400 responses. How is >> that something "objective"? >> >> >> >> Many people don't care or are neutral to segwit1x vs segwit2x, of course. >> Businesses and services they use would take them to segwit2x, like the >> 10,000 merchants and millions of users. If any of them are pro-segwit1x, >> they should immediately terminate their business with those companies or >> stop using those wallets. We didn't see it happen. >> >> >> >> If you truly think those poll counts, why would you still arguing with me >> on a segwit2x mailing list? It only shows that you're extremely doubtful of >> your belief. I never see people arguing on a Bitcoin Cash mailing list to >> show which one has the majority support. >> >> >> >> Also you missed the counter-argument for "majority of miners". So I assume >> at least we agree that majority of miners support segwit2x. :) >> >> >> >> Now this is a technical mailing list. Would trolls please find elsewhere >> for those nonsense? >> >> >> >> >> >> Sent with ProtonMail Secure Email. >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> Local Time: October 14, 2017 10:48 PM >> >> UTC Time: October 14, 2017 2:48 PM >> >> From: segwit2x_mailinglist at bitcoinreminder.com >> >> To: Cedrick Perrigo >> >> Phillip Katete , >> bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> It?s funny how you imply that "10,000 merchants of BitPay, millions of >> users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers >> and sellers of OpenBazar? are in favour of b2x? >> >> >> >> The only sybill resistant poll which I know (even created by data of users >> from Coinbase!!!) shows that most of the coinbase customers are not in >> favour of b2x? >> >> >> >> https://luke.dashjr.org/programs/kycpoll/answers.php >> >> >> >> This link was twittered on /r/bitcoin, /r/btc and reweeted also by many >> B2X proponents. >> >> >> >> So please, show me some data how these "10,000 merchants of BitPay, >> millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions >> of buyers and sellers of OpenBazar? are in favour of b2x? >> >> >> >> >> >> Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x >> : >> >> >> >> In the grand scheme of things, 10,000 merchants of BitPay, millions of >> users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers >> and sellers of OpenBazar, majority of miners do not count but you only count >> a tiny thousand people on a Twitter poll. How funny this is. >> >> >> >> If you actually look into Twitter, there are only around a thousand people >> who has the "no2x" tag. Not all of them are trolling. However, people who >> state that those are everything that counts, especially on a segwit2x >> mailing list, is certainly trolling and does not worth any people's >> attention. >> >> >> >> Bitcoin will be what majority calls it. Period. >> >> >> >> >> >> Sent with ProtonMail Secure Email. >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> Local Time: October 14, 2017 10:32 PM >> >> UTC Time: October 14, 2017 2:32 PM >> >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> >> To: Scott Roberts , >> bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> >> >> In the grand scheme of things, 1,168 responders is not exactly >> representative of the bitcoin community, is it? But that number, for a >> sample size, falls in the range of what is referred to as statistically >> irrelevant. It seems like you?ll have to do even more reading up! >> >> >> >> >> >> From: Scott Roberts via Bitcoin-segwit2x >> >> Sent: 14 October 2017 15:25 >> >> To: bitcoin-segwit2x at lists.linuxfoundation.org >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> >> >> > I have NEVER seen a twitter poll on bitcoin that had a statistically >> > relevant sample size. But also bear in mind that by it?s very nature, >> > twitter creates bubbles where like minded people follow each other. >> >> >> 1,168 with 30x difference in responses is very significant. Show me >> the twitter bubble where like-minded SegWit2x supporters show their >> support. >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 >> >> >> >> >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> >> -- >> >> Mike Belshe >> CEO, BitGo, Inc >> 408-718-6885 >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> -- >> >> >> John C >> >> Bitcoin Error Log >> >> www.bitcoinerrorlog.com >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From pekatete at hotmail.com Mon Oct 16 00:37:27 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Mon, 16 Oct 2017 00:37:27 +0000 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: , Message-ID: In the same breath we can add that the consensus on the theoretical split (sans core HF) is that the split will result in an unusable legacy chain. This simple fact is borne out from verifiable signalling-intent on the blockchain From: Chris Stewart Sent: 16 October 2017 01:20 To: Phillip Katete Cc: Bitcoin Error Log; Mike Belshe; bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >The terns of reference for the working group, as has been stated multiple times, is to avoid a network split. If there is consensus on one thing, I think we can all admit there is going to be a network split. Therefore, if this working group insists on creating an altcoin, it should have strong 2 way replay protection. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Mon Oct 16 00:39:32 2017 From: chris at suredbits.com (Chris Stewart) Date: Sun, 15 Oct 2017 19:39:32 -0500 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: >Network split != altcoin. Ok, fair enough, a consensus incompatible chain that does not have consensus from the wider ecosystem. If it had consensus I would agree with you that there would not be a chain split. This isn't the case -- if it was there wouldn't been hundreds of emails on the list arguing. I find it amusing how this working group developed 'consensus' for their proposed protocol change. It seems to me, if we were drawing parallels between the legacy financial system and bitcoin, the equivalent of what is happening in this working group would be JP Morgan Chase, Wells Fargo, Citigroup and Goldman getting together in a room and dictating monetary policy because they are some of the largest custodians of USD. After deciding 'what's best' they would decree this is the way things are going to be. Does it really give them the authority to set the rules of the system just because they are custodians of *other* people's capital? -Chris On Sun, Oct 15, 2017 at 7:23 PM, Jared Lee Richardson wrote: > > I think we can all admit there is going to be a network split. > > Network split != altcoin. > > 2x is Bitcoin. Bitcoin does not need protection against Bitcoin. > > If the legacy chains survives as a minority, it can add replay > protection as the minority chain. If 2x is the minority chain, it'll > fade, it is not BCH. With more than 85% signaling, that is not > likely. > > Jared > > On Sun, Oct 15, 2017 at 5:19 PM, Chris Stewart via Bitcoin-segwit2x > wrote: > >>The terns of reference for the working group, as has been stated multiple > >> times, is to avoid a network split. > > > > If there is consensus on one thing, I think we can all admit there is > going > > to be a network split. > > > > Therefore, if this working group insists on creating an altcoin, it > should > > have strong 2 way replay protection. > > > > -Chris > > > > > > > > On Sat, Oct 14, 2017 at 12:02 PM, Phillip Katete via Bitcoin-segwit2x > > wrote: > >> > >> The terns of reference for the working group, as has been stated > multiple > >> times, is to avoid a network split. Implementing strong 2 way RP would > >> effectively render the agreement voidable as it?d be fostering a network > >> split. From ALL Sybil resistant data available on the blockchain, and > >> despite what core would like everyone else to believe, the risk of a > >> ?viable? split, sans HF by core, though existent is at this particular > >> moment remote. As such, it matter not whether developers that do not > want > >> strong 2 way RP are in the minority, what matters is that the client > does > >> not render the agreement voidable. > >> > >> > >> > >> From: Bitcoin Error Log via Bitcoin-segwit2x > >> Sent: 14 October 2017 17:50 > >> To: Mike Belshe > >> Cc: bitcoin-segwit2x at lists.linuxfoundation.org > >> > >> > >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > >> > >> > >> > >> If you won't accept that a significant portion of Bitcoin does not want > >> this, let's at least address that some of the tech people in NYA-signing > >> businesses, like Jameson Lopp of BitGo, and Alex Petrov of BitFury also > >> disagree with the implementation. Are these companies going to ignore > the > >> very people they hired to be knowledgeable? > >> > >> I'd argue a minority of developers overall do not want strong replay > >> protection. You do not have consensus of developers, Core, or not. > >> > >> > >> > >> On Sat, Oct 14, 2017, 6:19 PM Mike Belshe via Bitcoin-segwit2x > >> wrote: > >> > >> I've banned Scott. > >> > >> > >> > >> On Sat, Oct 14, 2017 at 8:11 AM, Cedrick Perrigo via Bitcoin-segwit2x > >> wrote: > >> > >> You wonders do not belong to this mailing list. Get those silly > >> speculations elsewhere. > >> > >> > >> > >> It's users deciding to use those services, not the other way around. If > >> users are not happy, they can leave any time. But yet you see, that's > not > >> what's happening. > >> > >> > >> > >> > >> > >> Sent with ProtonMail Secure Email. > >> > >> > >> > >> -------- Original Message -------- > >> > >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > >> > >> Local Time: October 14, 2017 11:04 PM > >> > >> UTC Time: October 14, 2017 3:04 PM > >> > >> From: segwit2x_mailinglist at bitcoinreminder.com > >> > >> To: Cedrick Perrigo > >> > >> Phillip Katete , > >> bitcoin-segwit2x at lists.linuxfoundation.org > >> > >> > >> > >> > >> If any of them are pro-segwit1x, they should immediately terminate > their > >> business with those companies or stop using those wallets. > >> > >> > >> > >> I wonder then why Coinbase, Bitpay,.. etc are not asking its users or > >> telling them to " immediately terminate their business with those > companies > >> or stop using those wallets?? > >> > >> > >> > >> > >> > >> I never see people arguing on a Bitcoin Cash mailing list to show which > >> one has the majority support. > >> > >> > >> > >> BCash was professional enough to include replay protection - which is > not > >> the case with B2X until now. > >> > >> > >> > >> Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo > >> : > >> > >> > >> > >> Funny you listed something that only has less than 400 responses. How is > >> that something "objective"? > >> > >> > >> > >> Many people don't care or are neutral to segwit1x vs segwit2x, of > course. > >> Businesses and services they use would take them to segwit2x, like the > >> 10,000 merchants and millions of users. If any of them are pro-segwit1x, > >> they should immediately terminate their business with those companies or > >> stop using those wallets. We didn't see it happen. > >> > >> > >> > >> If you truly think those poll counts, why would you still arguing with > me > >> on a segwit2x mailing list? It only shows that you're extremely > doubtful of > >> your belief. I never see people arguing on a Bitcoin Cash mailing list > to > >> show which one has the majority support. > >> > >> > >> > >> Also you missed the counter-argument for "majority of miners". So I > assume > >> at least we agree that majority of miners support segwit2x. :) > >> > >> > >> > >> Now this is a technical mailing list. Would trolls please find elsewhere > >> for those nonsense? > >> > >> > >> > >> > >> > >> Sent with ProtonMail Secure Email. > >> > >> > >> > >> -------- Original Message -------- > >> > >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > >> > >> Local Time: October 14, 2017 10:48 PM > >> > >> UTC Time: October 14, 2017 2:48 PM > >> > >> From: segwit2x_mailinglist at bitcoinreminder.com > >> > >> To: Cedrick Perrigo > >> > >> Phillip Katete , > >> bitcoin-segwit2x at lists.linuxfoundation.org > >> > >> > >> > >> > >> It?s funny how you imply that "10,000 merchants of BitPay, millions of > >> users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of > buyers > >> and sellers of OpenBazar? are in favour of b2x? > >> > >> > >> > >> The only sybill resistant poll which I know (even created by data of > users > >> from Coinbase!!!) shows that most of the coinbase customers are not in > >> favour of b2x? > >> > >> > >> > >> https://luke.dashjr.org/programs/kycpoll/answers.php > >> > >> > >> > >> This link was twittered on /r/bitcoin, /r/btc and reweeted also by many > >> B2X proponents. > >> > >> > >> > >> So please, show me some data how these "10,000 merchants of BitPay, > >> millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, > millions > >> of buyers and sellers of OpenBazar? are in favour of b2x? > >> > >> > >> > >> > >> > >> Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x > >> : > >> > >> > >> > >> In the grand scheme of things, 10,000 merchants of BitPay, millions of > >> users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of > buyers > >> and sellers of OpenBazar, majority of miners do not count but you only > count > >> a tiny thousand people on a Twitter poll. How funny this is. > >> > >> > >> > >> If you actually look into Twitter, there are only around a thousand > people > >> who has the "no2x" tag. Not all of them are trolling. However, people > who > >> state that those are everything that counts, especially on a segwit2x > >> mailing list, is certainly trolling and does not worth any people's > >> attention. > >> > >> > >> > >> Bitcoin will be what majority calls it. Period. > >> > >> > >> > >> > >> > >> Sent with ProtonMail Secure Email. > >> > >> > >> > >> -------- Original Message -------- > >> > >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > >> > >> Local Time: October 14, 2017 10:32 PM > >> > >> UTC Time: October 14, 2017 2:32 PM > >> > >> From: bitcoin-segwit2x at lists.linuxfoundation.org > >> > >> To: Scott Roberts , > >> bitcoin-segwit2x at lists.linuxfoundation.org > >> > >> > >> > >> > >> > >> > >> In the grand scheme of things, 1,168 responders is not exactly > >> representative of the bitcoin community, is it? But that number, for a > >> sample size, falls in the range of what is referred to as statistically > >> irrelevant. It seems like you?ll have to do even more reading up! > >> > >> > >> > >> > >> > >> From: Scott Roberts via Bitcoin-segwit2x > >> > >> Sent: 14 October 2017 15:25 > >> > >> To: bitcoin-segwit2x at lists.linuxfoundation.org > >> > >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > >> > >> > >> > >> > >> > >> > I have NEVER seen a twitter poll on bitcoin that had a statistically > >> > relevant sample size. But also bear in mind that by it?s very nature, > >> > twitter creates bubbles where like minded people follow each other. > >> > >> > >> 1,168 with 30x difference in responses is very significant. Show me > >> the twitter bubble where like-minded SegWit2x supporters show their > >> support. > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> > >> https://eur01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Flists.linuxfoundation.org%2Fmailman% > 2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com% > 7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaa > aaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz% > 2FMMOgKN3XMKyY%3D&reserved=0 > >> > >> > >> > >> > >> > >> _______________________________________________ > >> > >> Bitcoin-segwit2x mailing list > >> > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > >> > >> > >> > >> > >> -- > >> > >> Mike Belshe > >> CEO, BitGo, Inc > >> 408-718-6885 > >> > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > >> -- > >> > >> > >> John C > >> > >> Bitcoin Error Log > >> > >> www.bitcoinerrorlog.com > >> > >> > >> > >> > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jheathco at gmail.com Mon Oct 16 00:48:24 2017 From: jheathco at gmail.com (John Heathco) Date: Mon, 16 Oct 2017 00:48:24 +0000 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: It's demonization tactics such as these that have contributed to the toxic environment we're currently dealing with. To compare segwit2x to big "evil" banks dictating monetary policy is completely disingenuous. This thread has gotten completely off-topic. On Sun, Oct 15, 2017 at 5:39 PM Chris Stewart via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >Network split != altcoin. > > Ok, fair enough, a consensus incompatible chain that does not have > consensus from the wider ecosystem. If it had consensus I would agree with > you that there would not be a chain split. This isn't the case -- if it was > there wouldn't been hundreds of emails on the list arguing. > > I find it amusing how this working group developed 'consensus' for their > proposed protocol change. It seems to me, if we were drawing parallels > between the legacy financial system and bitcoin, the equivalent of what is > happening in this working group would be JP Morgan Chase, Wells Fargo, > Citigroup and Goldman getting together in a room and dictating monetary > policy because they are some of the largest custodians of USD. After > deciding 'what's best' they would decree this is the way things are going > to be. > > Does it really give them the authority to set the rules of the system just > because they are custodians of *other* people's capital? > > -Chris > > On Sun, Oct 15, 2017 at 7:23 PM, Jared Lee Richardson > wrote: > >> > I think we can all admit there is going to be a network split. >> >> Network split != altcoin. >> >> 2x is Bitcoin. Bitcoin does not need protection against Bitcoin. >> >> If the legacy chains survives as a minority, it can add replay >> protection as the minority chain. If 2x is the minority chain, it'll >> fade, it is not BCH. With more than 85% signaling, that is not >> likely. >> >> Jared >> >> On Sun, Oct 15, 2017 at 5:19 PM, Chris Stewart via Bitcoin-segwit2x >> wrote: >> >>The terns of reference for the working group, as has been stated >> multiple >> >> times, is to avoid a network split. >> > >> > If there is consensus on one thing, I think we can all admit there is >> going >> > to be a network split. >> > >> > Therefore, if this working group insists on creating an altcoin, it >> should >> > have strong 2 way replay protection. >> > >> > -Chris >> > >> > >> > >> > On Sat, Oct 14, 2017 at 12:02 PM, Phillip Katete via Bitcoin-segwit2x >> > wrote: >> >> >> >> The terns of reference for the working group, as has been stated >> multiple >> >> times, is to avoid a network split. Implementing strong 2 way RP would >> >> effectively render the agreement voidable as it?d be fostering a >> network >> >> split. From ALL Sybil resistant data available on the blockchain, and >> >> despite what core would like everyone else to believe, the risk of a >> >> ?viable? split, sans HF by core, though existent is at this particular >> >> moment remote. As such, it matter not whether developers that do not >> want >> >> strong 2 way RP are in the minority, what matters is that the client >> does >> >> not render the agreement voidable. >> >> >> >> >> >> >> >> From: Bitcoin Error Log via Bitcoin-segwit2x >> >> Sent: 14 October 2017 17:50 >> >> To: Mike Belshe >> >> Cc: bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> >> >> >> >> If you won't accept that a significant portion of Bitcoin does not want >> >> this, let's at least address that some of the tech people in >> NYA-signing >> >> businesses, like Jameson Lopp of BitGo, and Alex Petrov of BitFury also >> >> disagree with the implementation. Are these companies going to ignore >> the >> >> very people they hired to be knowledgeable? >> >> >> >> I'd argue a minority of developers overall do not want strong replay >> >> protection. You do not have consensus of developers, Core, or not. >> >> >> >> >> >> >> >> On Sat, Oct 14, 2017, 6:19 PM Mike Belshe via Bitcoin-segwit2x >> >> wrote: >> >> >> >> I've banned Scott. >> >> >> >> >> >> >> >> On Sat, Oct 14, 2017 at 8:11 AM, Cedrick Perrigo via Bitcoin-segwit2x >> >> wrote: >> >> >> >> You wonders do not belong to this mailing list. Get those silly >> >> speculations elsewhere. >> >> >> >> >> >> >> >> It's users deciding to use those services, not the other way around. If >> >> users are not happy, they can leave any time. But yet you see, that's >> not >> >> what's happening. >> >> >> >> >> >> >> >> >> >> >> >> Sent with ProtonMail Secure Email. >> >> >> >> >> >> >> >> -------- Original Message -------- >> >> >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> Local Time: October 14, 2017 11:04 PM >> >> >> >> UTC Time: October 14, 2017 3:04 PM >> >> >> >> From: segwit2x_mailinglist at bitcoinreminder.com >> >> >> >> To: Cedrick Perrigo >> >> >> >> Phillip Katete , >> >> bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> >> >> >> >> >> If any of them are pro-segwit1x, they should immediately terminate >> their >> >> business with those companies or stop using those wallets. >> >> >> >> >> >> >> >> I wonder then why Coinbase, Bitpay,.. etc are not asking its users or >> >> telling them to " immediately terminate their business with those >> companies >> >> or stop using those wallets?? >> >> >> >> >> >> >> >> >> >> >> >> I never see people arguing on a Bitcoin Cash mailing list to show which >> >> one has the majority support. >> >> >> >> >> >> >> >> BCash was professional enough to include replay protection - which is >> not >> >> the case with B2X until now. >> >> >> >> >> >> >> >> Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo >> >> : >> >> >> >> >> >> >> >> Funny you listed something that only has less than 400 responses. How >> is >> >> that something "objective"? >> >> >> >> >> >> >> >> Many people don't care or are neutral to segwit1x vs segwit2x, of >> course. >> >> Businesses and services they use would take them to segwit2x, like the >> >> 10,000 merchants and millions of users. If any of them are >> pro-segwit1x, >> >> they should immediately terminate their business with those companies >> or >> >> stop using those wallets. We didn't see it happen. >> >> >> >> >> >> >> >> If you truly think those poll counts, why would you still arguing with >> me >> >> on a segwit2x mailing list? It only shows that you're extremely >> doubtful of >> >> your belief. I never see people arguing on a Bitcoin Cash mailing list >> to >> >> show which one has the majority support. >> >> >> >> >> >> >> >> Also you missed the counter-argument for "majority of miners". So I >> assume >> >> at least we agree that majority of miners support segwit2x. :) >> >> >> >> >> >> >> >> Now this is a technical mailing list. Would trolls please find >> elsewhere >> >> for those nonsense? >> >> >> >> >> >> >> >> >> >> >> >> Sent with ProtonMail Secure Email. >> >> >> >> >> >> >> >> -------- Original Message -------- >> >> >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> Local Time: October 14, 2017 10:48 PM >> >> >> >> UTC Time: October 14, 2017 2:48 PM >> >> >> >> From: segwit2x_mailinglist at bitcoinreminder.com >> >> >> >> To: Cedrick Perrigo >> >> >> >> Phillip Katete , >> >> bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> >> >> >> >> >> It?s funny how you imply that "10,000 merchants of BitPay, millions of >> >> users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of >> buyers >> >> and sellers of OpenBazar? are in favour of b2x? >> >> >> >> >> >> >> >> The only sybill resistant poll which I know (even created by data of >> users >> >> from Coinbase!!!) shows that most of the coinbase customers are not in >> >> favour of b2x? >> >> >> >> >> >> >> >> https://luke.dashjr.org/programs/kycpoll/answers.php >> >> >> >> >> >> >> >> This link was twittered on /r/bitcoin, /r/btc and reweeted also by many >> >> B2X proponents. >> >> >> >> >> >> >> >> So please, show me some data how these "10,000 merchants of BitPay, >> >> millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, >> millions >> >> of buyers and sellers of OpenBazar? are in favour of b2x? >> >> >> >> >> >> >> >> >> >> >> >> Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x >> >> : >> >> >> >> >> >> >> >> In the grand scheme of things, 10,000 merchants of BitPay, millions of >> >> users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of >> buyers >> >> and sellers of OpenBazar, majority of miners do not count but you only >> count >> >> a tiny thousand people on a Twitter poll. How funny this is. >> >> >> >> >> >> >> >> If you actually look into Twitter, there are only around a thousand >> people >> >> who has the "no2x" tag. Not all of them are trolling. However, people >> who >> >> state that those are everything that counts, especially on a segwit2x >> >> mailing list, is certainly trolling and does not worth any people's >> >> attention. >> >> >> >> >> >> >> >> Bitcoin will be what majority calls it. Period. >> >> >> >> >> >> >> >> >> >> >> >> Sent with ProtonMail Secure Email. >> >> >> >> >> >> >> >> -------- Original Message -------- >> >> >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> Local Time: October 14, 2017 10:32 PM >> >> >> >> UTC Time: October 14, 2017 2:32 PM >> >> >> >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> To: Scott Roberts , >> >> bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> >> >> >> >> >> >> >> >> >> In the grand scheme of things, 1,168 responders is not exactly >> >> representative of the bitcoin community, is it? But that number, for a >> >> sample size, falls in the range of what is referred to as statistically >> >> irrelevant. It seems like you?ll have to do even more reading up! >> >> >> >> >> >> >> >> >> >> >> >> From: Scott Roberts via Bitcoin-segwit2x >> >> >> >> Sent: 14 October 2017 15:25 >> >> >> >> To: bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> >> >> >> >> >> >> >> >> > I have NEVER seen a twitter poll on bitcoin that had a statistically >> >> > relevant sample size. But also bear in mind that by it?s very nature, >> >> > twitter creates bubbles where like minded people follow each other. >> >> >> >> >> >> 1,168 with 30x difference in responses is very significant. Show me >> >> the twitter bubble where like-minded SegWit2x supporters show their >> >> support. >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> Bitcoin-segwit2x mailing list >> >> >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Mike Belshe >> >> CEO, BitGo, Inc >> >> 408-718-6885 >> >> >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> -- >> >> >> >> >> >> John C >> >> >> >> Bitcoin Error Log >> >> >> >> www.bitcoinerrorlog.com >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> > >> > >> > _______________________________________________ >> > Bitcoin-segwit2x mailing list >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaredr26 at gmail.com Mon Oct 16 00:49:34 2017 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Sun, 15 Oct 2017 17:49:34 -0700 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: > I find it amusing how this working group developed 'consensus' for their proposed protocol change. It seems to me, if we were drawing parallels between the legacy financial system and bitcoin And it seems amusing to me that the working group you favor defined "consensus" as only within their group, the opinions of others does not count. Source: The rules behind who gets added to the "segwit_support" page on the bitcoin wiki, created by several core developers, measuring several core developers. Where else do they look to for "consensus"? A forum where people who disagree with them are *banned*. Run by the same people who make the rules on the bitcoin wiki. This working group is moving Bitcoin forward. 2mb is a very small change, and there are literally no technical arguments against such a small increase. Core's refusal to get on board is their own problem. This group dictates nothing; People are free to run the btc1 client, and they are free to not run it. The miners agreed to activate segwit conditionally upon this hardfork. The hardfork will happen. On Sun, Oct 15, 2017 at 5:39 PM, Chris Stewart wrote: >>Network split != altcoin. > > Ok, fair enough, a consensus incompatible chain that does not have consensus > from the wider ecosystem. If it had consensus I would agree with you that > there would not be a chain split. This isn't the case -- if it was there > wouldn't been hundreds of emails on the list arguing. > > I find it amusing how this working group developed 'consensus' for their > proposed protocol change. It seems to me, if we were drawing parallels > between the legacy financial system and bitcoin, the equivalent of what is > happening in this working group would be JP Morgan Chase, Wells Fargo, > Citigroup and Goldman getting together in a room and dictating monetary > policy because they are some of the largest custodians of USD. After > deciding 'what's best' they would decree this is the way things are going to > be. > > Does it really give them the authority to set the rules of the system just > because they are custodians of *other* people's capital? > > -Chris > > On Sun, Oct 15, 2017 at 7:23 PM, Jared Lee Richardson > wrote: >> >> > I think we can all admit there is going to be a network split. >> >> Network split != altcoin. >> >> 2x is Bitcoin. Bitcoin does not need protection against Bitcoin. >> >> If the legacy chains survives as a minority, it can add replay >> protection as the minority chain. If 2x is the minority chain, it'll >> fade, it is not BCH. With more than 85% signaling, that is not >> likely. >> >> Jared >> >> On Sun, Oct 15, 2017 at 5:19 PM, Chris Stewart via Bitcoin-segwit2x >> wrote: >> >>The terns of reference for the working group, as has been stated >> >> multiple >> >> times, is to avoid a network split. >> > >> > If there is consensus on one thing, I think we can all admit there is >> > going >> > to be a network split. >> > >> > Therefore, if this working group insists on creating an altcoin, it >> > should >> > have strong 2 way replay protection. >> > >> > -Chris >> > >> > >> > >> > On Sat, Oct 14, 2017 at 12:02 PM, Phillip Katete via Bitcoin-segwit2x >> > wrote: >> >> >> >> The terns of reference for the working group, as has been stated >> >> multiple >> >> times, is to avoid a network split. Implementing strong 2 way RP would >> >> effectively render the agreement voidable as it?d be fostering a >> >> network >> >> split. From ALL Sybil resistant data available on the blockchain, and >> >> despite what core would like everyone else to believe, the risk of a >> >> ?viable? split, sans HF by core, though existent is at this particular >> >> moment remote. As such, it matter not whether developers that do not >> >> want >> >> strong 2 way RP are in the minority, what matters is that the client >> >> does >> >> not render the agreement voidable. >> >> >> >> >> >> >> >> From: Bitcoin Error Log via Bitcoin-segwit2x >> >> Sent: 14 October 2017 17:50 >> >> To: Mike Belshe >> >> Cc: bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> >> >> >> >> If you won't accept that a significant portion of Bitcoin does not want >> >> this, let's at least address that some of the tech people in >> >> NYA-signing >> >> businesses, like Jameson Lopp of BitGo, and Alex Petrov of BitFury also >> >> disagree with the implementation. Are these companies going to ignore >> >> the >> >> very people they hired to be knowledgeable? >> >> >> >> I'd argue a minority of developers overall do not want strong replay >> >> protection. You do not have consensus of developers, Core, or not. >> >> >> >> >> >> >> >> On Sat, Oct 14, 2017, 6:19 PM Mike Belshe via Bitcoin-segwit2x >> >> wrote: >> >> >> >> I've banned Scott. >> >> >> >> >> >> >> >> On Sat, Oct 14, 2017 at 8:11 AM, Cedrick Perrigo via Bitcoin-segwit2x >> >> wrote: >> >> >> >> You wonders do not belong to this mailing list. Get those silly >> >> speculations elsewhere. >> >> >> >> >> >> >> >> It's users deciding to use those services, not the other way around. If >> >> users are not happy, they can leave any time. But yet you see, that's >> >> not >> >> what's happening. >> >> >> >> >> >> >> >> >> >> >> >> Sent with ProtonMail Secure Email. >> >> >> >> >> >> >> >> -------- Original Message -------- >> >> >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> Local Time: October 14, 2017 11:04 PM >> >> >> >> UTC Time: October 14, 2017 3:04 PM >> >> >> >> From: segwit2x_mailinglist at bitcoinreminder.com >> >> >> >> To: Cedrick Perrigo >> >> >> >> Phillip Katete , >> >> bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> >> >> >> >> >> If any of them are pro-segwit1x, they should immediately terminate >> >> their >> >> business with those companies or stop using those wallets. >> >> >> >> >> >> >> >> I wonder then why Coinbase, Bitpay,.. etc are not asking its users or >> >> telling them to " immediately terminate their business with those >> >> companies >> >> or stop using those wallets?? >> >> >> >> >> >> >> >> >> >> >> >> I never see people arguing on a Bitcoin Cash mailing list to show which >> >> one has the majority support. >> >> >> >> >> >> >> >> BCash was professional enough to include replay protection - which is >> >> not >> >> the case with B2X until now. >> >> >> >> >> >> >> >> Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo >> >> : >> >> >> >> >> >> >> >> Funny you listed something that only has less than 400 responses. How >> >> is >> >> that something "objective"? >> >> >> >> >> >> >> >> Many people don't care or are neutral to segwit1x vs segwit2x, of >> >> course. >> >> Businesses and services they use would take them to segwit2x, like the >> >> 10,000 merchants and millions of users. If any of them are >> >> pro-segwit1x, >> >> they should immediately terminate their business with those companies >> >> or >> >> stop using those wallets. We didn't see it happen. >> >> >> >> >> >> >> >> If you truly think those poll counts, why would you still arguing with >> >> me >> >> on a segwit2x mailing list? It only shows that you're extremely >> >> doubtful of >> >> your belief. I never see people arguing on a Bitcoin Cash mailing list >> >> to >> >> show which one has the majority support. >> >> >> >> >> >> >> >> Also you missed the counter-argument for "majority of miners". So I >> >> assume >> >> at least we agree that majority of miners support segwit2x. :) >> >> >> >> >> >> >> >> Now this is a technical mailing list. Would trolls please find >> >> elsewhere >> >> for those nonsense? >> >> >> >> >> >> >> >> >> >> >> >> Sent with ProtonMail Secure Email. >> >> >> >> >> >> >> >> -------- Original Message -------- >> >> >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> Local Time: October 14, 2017 10:48 PM >> >> >> >> UTC Time: October 14, 2017 2:48 PM >> >> >> >> From: segwit2x_mailinglist at bitcoinreminder.com >> >> >> >> To: Cedrick Perrigo >> >> >> >> Phillip Katete , >> >> bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> >> >> >> >> >> It?s funny how you imply that "10,000 merchants of BitPay, millions of >> >> users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of >> >> buyers >> >> and sellers of OpenBazar? are in favour of b2x? >> >> >> >> >> >> >> >> The only sybill resistant poll which I know (even created by data of >> >> users >> >> from Coinbase!!!) shows that most of the coinbase customers are not in >> >> favour of b2x? >> >> >> >> >> >> >> >> https://luke.dashjr.org/programs/kycpoll/answers.php >> >> >> >> >> >> >> >> This link was twittered on /r/bitcoin, /r/btc and reweeted also by many >> >> B2X proponents. >> >> >> >> >> >> >> >> So please, show me some data how these "10,000 merchants of BitPay, >> >> millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, >> >> millions >> >> of buyers and sellers of OpenBazar? are in favour of b2x? >> >> >> >> >> >> >> >> >> >> >> >> Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x >> >> : >> >> >> >> >> >> >> >> In the grand scheme of things, 10,000 merchants of BitPay, millions of >> >> users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of >> >> buyers >> >> and sellers of OpenBazar, majority of miners do not count but you only >> >> count >> >> a tiny thousand people on a Twitter poll. How funny this is. >> >> >> >> >> >> >> >> If you actually look into Twitter, there are only around a thousand >> >> people >> >> who has the "no2x" tag. Not all of them are trolling. However, people >> >> who >> >> state that those are everything that counts, especially on a segwit2x >> >> mailing list, is certainly trolling and does not worth any people's >> >> attention. >> >> >> >> >> >> >> >> Bitcoin will be what majority calls it. Period. >> >> >> >> >> >> >> >> >> >> >> >> Sent with ProtonMail Secure Email. >> >> >> >> >> >> >> >> -------- Original Message -------- >> >> >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> Local Time: October 14, 2017 10:32 PM >> >> >> >> UTC Time: October 14, 2017 2:32 PM >> >> >> >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> To: Scott Roberts , >> >> bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> >> >> >> >> >> >> >> >> >> In the grand scheme of things, 1,168 responders is not exactly >> >> representative of the bitcoin community, is it? But that number, for a >> >> sample size, falls in the range of what is referred to as statistically >> >> irrelevant. It seems like you?ll have to do even more reading up! >> >> >> >> >> >> >> >> >> >> >> >> From: Scott Roberts via Bitcoin-segwit2x >> >> >> >> Sent: 14 October 2017 15:25 >> >> >> >> To: bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> >> >> >> >> >> >> >> >> > I have NEVER seen a twitter poll on bitcoin that had a statistically >> >> > relevant sample size. But also bear in mind that by it?s very nature, >> >> > twitter creates bubbles where like minded people follow each other. >> >> >> >> >> >> 1,168 with 30x difference in responses is very significant. Show me >> >> the twitter bubble where like-minded SegWit2x supporters show their >> >> support. >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> Bitcoin-segwit2x mailing list >> >> >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Mike Belshe >> >> CEO, BitGo, Inc >> >> 408-718-6885 >> >> >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> -- >> >> >> >> >> >> John C >> >> >> >> Bitcoin Error Log >> >> >> >> www.bitcoinerrorlog.com >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> > >> > >> > _______________________________________________ >> > Bitcoin-segwit2x mailing list >> > Bitcoin-segwit2x at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > > From bitpico at icloud.com Mon Oct 16 01:06:33 2017 From: bitpico at icloud.com (bitPico) Date: Sun, 15 Oct 2017 21:06:33 -0400 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: <9F66B1FE-9030-44B8-9D6A-47EA9507DF8D@icloud.com> There is no fork. Perhaps it?s a spoon? Bitcoin1x if it exists post upgrade with less hashrate will be an Altcoin. The inverse is also true. But this list isn?t for speculation; just the facts. One of those facts is people are encouraging a chain split for self financial gain. Nobody knows the legality of printing money by blockchain duplication but we do know it is ignorant economics like a central bank would do. That said; those that want to keep the deprecated 1x base block size are economically ignorant or greedy or both as there is no scientific reasoning. ? > On Oct 15, 2017, at 8:19 PM, Chris Stewart via Bitcoin-segwit2x wrote: > > >The terns of reference for the working group, as has been stated multiple times, is to avoid a network split. > > If there is consensus on one thing, I think we can all admit there is going to be a network split. > > Therefore, if this working group insists on creating an altcoin, it should have strong 2 way replay protection. > > -Chris > > > >> On Sat, Oct 14, 2017 at 12:02 PM, Phillip Katete via Bitcoin-segwit2x wrote: >> The terns of reference for the working group, as has been stated multiple times, is to avoid a network split. Implementing strong 2 way RP would effectively render the agreement voidable as it?d be fostering a network split. From ALL Sybil resistant data available on the blockchain, and despite what core would like everyone else to believe, the risk of a ?viable? split, sans HF by core, though existent is at this particular moment remote. As such, it matter not whether developers that do not want strong 2 way RP are in the minority, what matters is that the client does not render the agreement voidable. >> >> >> >> From: Bitcoin Error Log via Bitcoin-segwit2x >> Sent: 14 October 2017 17:50 >> To: Mike Belshe >> Cc: bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> If you won't accept that a significant portion of Bitcoin does not want this, let's at least address that some of the tech people in NYA-signing businesses, like Jameson Lopp of BitGo, and Alex Petrov of BitFury also disagree with the implementation. Are these companies going to ignore the very people they hired to be knowledgeable? >> >> I'd argue a minority of developers overall do not want strong replay protection. You do not have consensus of developers, Core, or not. >> >> >> >> On Sat, Oct 14, 2017, 6:19 PM Mike Belshe via Bitcoin-segwit2x wrote: >> >> I've banned Scott. >> >> >> >> On Sat, Oct 14, 2017 at 8:11 AM, Cedrick Perrigo via Bitcoin-segwit2x wrote: >> >> You wonders do not belong to this mailing list. Get those silly speculations elsewhere. >> >> >> >> It's users deciding to use those services, not the other way around. If users are not happy, they can leave any time. But yet you see, that's not what's happening. >> >> >> >> >> >> Sent with ProtonMail Secure Email. >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> Local Time: October 14, 2017 11:04 PM >> >> UTC Time: October 14, 2017 3:04 PM >> >> From: segwit2x_mailinglist at bitcoinreminder.com >> >> To: Cedrick Perrigo >> >> Phillip Katete , bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> If any of them are pro-segwit1x, they should immediately terminate their business with those companies or stop using those wallets. >> >> >> >> I wonder then why Coinbase, Bitpay,.. etc are not asking its users or telling them to " immediately terminate their business with those companies or stop using those wallets?? >> >> >> >> >> >> I never see people arguing on a Bitcoin Cash mailing list to show which one has the majority support. >> >> >> >> BCash was professional enough to include replay protection - which is not the case with B2X until now. >> >> >> >> Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo : >> >> >> >> Funny you listed something that only has less than 400 responses. How is that something "objective"? >> >> >> >> Many people don't care or are neutral to segwit1x vs segwit2x, of course. Businesses and services they use would take them to segwit2x, like the 10,000 merchants and millions of users. If any of them are pro-segwit1x, they should immediately terminate their business with those companies or stop using those wallets. We didn't see it happen. >> >> >> >> If you truly think those poll counts, why would you still arguing with me on a segwit2x mailing list? It only shows that you're extremely doubtful of your belief. I never see people arguing on a Bitcoin Cash mailing list to show which one has the majority support. >> >> >> >> Also you missed the counter-argument for "majority of miners". So I assume at least we agree that majority of miners support segwit2x. :) >> >> >> >> Now this is a technical mailing list. Would trolls please find elsewhere for those nonsense? >> >> >> >> >> >> Sent with ProtonMail Secure Email. >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> Local Time: October 14, 2017 10:48 PM >> >> UTC Time: October 14, 2017 2:48 PM >> >> From: segwit2x_mailinglist at bitcoinreminder.com >> >> To: Cedrick Perrigo >> >> Phillip Katete , bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> It?s funny how you imply that "10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? >> >> >> >> The only sybill resistant poll which I know (even created by data of users from Coinbase!!!) shows that most of the coinbase customers are not in favour of b2x? >> >> >> >> https://luke.dashjr.org/programs/kycpoll/answers.php >> >> >> >> This link was twittered on /r/bitcoin, /r/btc and reweeted also by many B2X proponents. >> >> >> >> So please, show me some data how these "10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? >> >> >> >> >> >> Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x : >> >> >> >> In the grand scheme of things, 10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of miners do not count but you only count a tiny thousand people on a Twitter poll. How funny this is. >> >> >> >> If you actually look into Twitter, there are only around a thousand people who has the "no2x" tag. Not all of them are trolling. However, people who state that those are everything that counts, especially on a segwit2x mailing list, is certainly trolling and does not worth any people's attention. >> >> >> >> Bitcoin will be what majority calls it. Period. >> >> >> >> >> >> Sent with ProtonMail Secure Email. >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> Local Time: October 14, 2017 10:32 PM >> >> UTC Time: October 14, 2017 2:32 PM >> >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> >> To: Scott Roberts , bitcoin-segwit2x at lists.linuxfoundation.org >> >> >> >> >> >> In the grand scheme of things, 1,168 responders is not exactly representative of the bitcoin community, is it? But that number, for a sample size, falls in the range of what is referred to as statistically irrelevant. It seems like you?ll have to do even more reading up! >> >> >> >> >> >> From: Scott Roberts via Bitcoin-segwit2x >> >> Sent: 14 October 2017 15:25 >> >> To: bitcoin-segwit2x at lists.linuxfoundation.org >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> >> >> > I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. >> >> >> 1,168 with 30x difference in responses is very significant. Show me >> the twitter bubble where like-minded SegWit2x supporters show their >> support. >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 >> >> >> >> >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> >> >> -- >> >> Mike Belshe >> CEO, BitGo, Inc >> 408-718-6885 >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> -- >> >> >> John C >> >> Bitcoin Error Log >> >> www.bitcoinerrorlog.com >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinny at civic.com Mon Oct 16 02:31:24 2017 From: vinny at civic.com (Vinny Lingham) Date: Sun, 15 Oct 2017 19:31:24 -0700 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: <9F66B1FE-9030-44B8-9D6A-47EA9507DF8D@icloud.com> References: <9F66B1FE-9030-44B8-9D6A-47EA9507DF8D@icloud.com> Message-ID: <68BC6DC2-AC59-44F8-92ED-37A79BD0D1A4@civic.com> I have an even more poignant question : If the broader Bitcoin ecosystem is so against S2X, then why is virtually every Bitcoin business, with an ?evil? CEO, booming and not losing customers in droves? Reason for the question is: I?m very well plugged into the ecosystem and an investor in some of these companies - all of them are hitting all time record numbers on their KPI?s. And this is the prevailing trend right now. ?Users? aren?t going anywhere or leaving these businesses, in contrast to what one would expect if there was no support for S2X? These facts belies the narrative that there is no support for Segwit2x, from a quantitative perspective. One could argue that the market is rallying now because of S2X. > On Oct 15, 2017, at 18:06, bitPico via Bitcoin-segwit2x wrote: > > There is no fork. Perhaps it?s a spoon? > > Bitcoin1x if it exists post upgrade with less hashrate will be an Altcoin. The inverse is also true. But this list isn?t for speculation; just the facts. > > One of those facts is people are encouraging a chain split for self financial gain. Nobody knows the legality of printing money by blockchain duplication but we do know it is ignorant economics like a central bank would do. That said; those that want to keep the deprecated 1x base block size are economically ignorant or greedy or both as there is no scientific reasoning. > > ? > >> On Oct 15, 2017, at 8:19 PM, Chris Stewart via Bitcoin-segwit2x wrote: >> >> >The terns of reference for the working group, as has been stated multiple times, is to avoid a network split. >> >> If there is consensus on one thing, I think we can all admit there is going to be a network split. >> >> Therefore, if this working group insists on creating an altcoin, it should have strong 2 way replay protection. >> >> -Chris >> >> >> >>> On Sat, Oct 14, 2017 at 12:02 PM, Phillip Katete via Bitcoin-segwit2x wrote: >>> The terns of reference for the working group, as has been stated multiple times, is to avoid a network split. Implementing strong 2 way RP would effectively render the agreement voidable as it?d be fostering a network split. From ALL Sybil resistant data available on the blockchain, and despite what core would like everyone else to believe, the risk of a ?viable? split, sans HF by core, though existent is at this particular moment remote. As such, it matter not whether developers that do not want strong 2 way RP are in the minority, what matters is that the client does not render the agreement voidable. >>> >>> >>> >>> From: Bitcoin Error Log via Bitcoin-segwit2x >>> Sent: 14 October 2017 17:50 >>> To: Mike Belshe >>> Cc: bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> >>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>> >>> >>> If you won't accept that a significant portion of Bitcoin does not want this, let's at least address that some of the tech people in NYA-signing businesses, like Jameson Lopp of BitGo, and Alex Petrov of BitFury also disagree with the implementation. Are these companies going to ignore the very people they hired to be knowledgeable? >>> >>> I'd argue a minority of developers overall do not want strong replay protection. You do not have consensus of developers, Core, or not. >>> >>> >>> >>> On Sat, Oct 14, 2017, 6:19 PM Mike Belshe via Bitcoin-segwit2x wrote: >>> >>> I've banned Scott. >>> >>> >>> >>> On Sat, Oct 14, 2017 at 8:11 AM, Cedrick Perrigo via Bitcoin-segwit2x wrote: >>> >>> You wonders do not belong to this mailing list. Get those silly speculations elsewhere. >>> >>> >>> >>> It's users deciding to use those services, not the other way around. If users are not happy, they can leave any time. But yet you see, that's not what's happening. >>> >>> >>> >>> >>> >>> Sent with ProtonMail Secure Email. >>> >>> >>> >>> -------- Original Message -------- >>> >>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>> >>> Local Time: October 14, 2017 11:04 PM >>> >>> UTC Time: October 14, 2017 3:04 PM >>> >>> From: segwit2x_mailinglist at bitcoinreminder.com >>> >>> To: Cedrick Perrigo >>> >>> Phillip Katete , bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> >>> >>> If any of them are pro-segwit1x, they should immediately terminate their business with those companies or stop using those wallets. >>> >>> >>> >>> I wonder then why Coinbase, Bitpay,.. etc are not asking its users or telling them to " immediately terminate their business with those companies or stop using those wallets?? >>> >>> >>> >>> >>> >>> I never see people arguing on a Bitcoin Cash mailing list to show which one has the majority support. >>> >>> >>> >>> BCash was professional enough to include replay protection - which is not the case with B2X until now. >>> >>> >>> >>> Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo : >>> >>> >>> >>> Funny you listed something that only has less than 400 responses. How is that something "objective"? >>> >>> >>> >>> Many people don't care or are neutral to segwit1x vs segwit2x, of course. Businesses and services they use would take them to segwit2x, like the 10,000 merchants and millions of users. If any of them are pro-segwit1x, they should immediately terminate their business with those companies or stop using those wallets. We didn't see it happen. >>> >>> >>> >>> If you truly think those poll counts, why would you still arguing with me on a segwit2x mailing list? It only shows that you're extremely doubtful of your belief. I never see people arguing on a Bitcoin Cash mailing list to show which one has the majority support. >>> >>> >>> >>> Also you missed the counter-argument for "majority of miners". So I assume at least we agree that majority of miners support segwit2x. :) >>> >>> >>> >>> Now this is a technical mailing list. Would trolls please find elsewhere for those nonsense? >>> >>> >>> >>> >>> >>> Sent with ProtonMail Secure Email. >>> >>> >>> >>> -------- Original Message -------- >>> >>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>> >>> Local Time: October 14, 2017 10:48 PM >>> >>> UTC Time: October 14, 2017 2:48 PM >>> >>> From: segwit2x_mailinglist at bitcoinreminder.com >>> >>> To: Cedrick Perrigo >>> >>> Phillip Katete , bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> >>> >>> It?s funny how you imply that "10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? >>> >>> >>> >>> The only sybill resistant poll which I know (even created by data of users from Coinbase!!!) shows that most of the coinbase customers are not in favour of b2x? >>> >>> >>> >>> https://luke.dashjr.org/programs/kycpoll/answers.php >>> >>> >>> >>> This link was twittered on /r/bitcoin, /r/btc and reweeted also by many B2X proponents. >>> >>> >>> >>> So please, show me some data how these "10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour of b2x? >>> >>> >>> >>> >>> >>> Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x : >>> >>> >>> >>> In the grand scheme of things, 10,000 merchants of BitPay, millions of users of Blockchain.info, Bitcoin.com, Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of miners do not count but you only count a tiny thousand people on a Twitter poll. How funny this is. >>> >>> >>> >>> If you actually look into Twitter, there are only around a thousand people who has the "no2x" tag. Not all of them are trolling. However, people who state that those are everything that counts, especially on a segwit2x mailing list, is certainly trolling and does not worth any people's attention. >>> >>> >>> >>> Bitcoin will be what majority calls it. Period. >>> >>> >>> >>> >>> >>> Sent with ProtonMail Secure Email. >>> >>> >>> >>> -------- Original Message -------- >>> >>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>> >>> Local Time: October 14, 2017 10:32 PM >>> >>> UTC Time: October 14, 2017 2:32 PM >>> >>> From: bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> To: Scott Roberts , bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> >>> >>> >>> >>> In the grand scheme of things, 1,168 responders is not exactly representative of the bitcoin community, is it? But that number, for a sample size, falls in the range of what is referred to as statistically irrelevant. It seems like you?ll have to do even more reading up! >>> >>> >>> >>> >>> >>> From: Scott Roberts via Bitcoin-segwit2x >>> >>> Sent: 14 October 2017 15:25 >>> >>> To: bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>> >>> >>> >>> >>> >>> > I have NEVER seen a twitter poll on bitcoin that had a statistically relevant sample size. But also bear in mind that by it?s very nature, twitter creates bubbles where like minded people follow each other. >>> >>> >>> 1,168 with 30x difference in responses is very significant. Show me >>> the twitter bubble where like-minded SegWit2x supporters show their >>> support. >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Bitcoin-segwit2x mailing list >>> >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Mike Belshe >>> CEO, BitGo, Inc >>> 408-718-6885 >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> -- >>> >>> >>> John C >>> >>> Bitcoin Error Log >>> >>> www.bitcoinerrorlog.com >>> >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Mon Oct 16 02:52:45 2017 From: chris at suredbits.com (Chris Stewart) Date: Sun, 15 Oct 2017 21:52:45 -0500 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: <68BC6DC2-AC59-44F8-92ED-37A79BD0D1A4@civic.com> References: <9F66B1FE-9030-44B8-9D6A-47EA9507DF8D@icloud.com> <68BC6DC2-AC59-44F8-92ED-37A79BD0D1A4@civic.com> Message-ID: >If the broader Bitcoin ecosystem is so against S2X, then why is virtually every Bitcoin business, with an ?evil? CEO, booming and not losing customers in droves? The chain split hasn't happened yet. Businesses -- especially those that act as custodians -- will have to credit users with tokens on both chains. Those that aren't acting as custodians haven't had the opportunity to transact with the new segwit2x currency. >These facts belies the narrative that there is no support for Segwit2x, from a quantitative perspective. One could argue that the market is rallying now because of S2X. The closest thing we've had to a quantitative measurement is the bitfinex future token for the economic majority (I don't count custodians voting unilaterally on behalf of all their customers). Currently it is trading at ~0.85/1 BT1/BTC (bitcoin) and 0.15/1 BT2/BTC (segwit2x coin). I'm not saying that this future token is perfect -- there are problems with it's structure and some people don't trust bitfinex. I think it is a better indicator of support for the two coins rather than just saying price increase implies support for segwit2x. https://www.bitfinex.com/stats -Chris On Sun, Oct 15, 2017 at 9:31 PM, Vinny Lingham wrote: > I have an even more poignant question : > > If the broader Bitcoin ecosystem is so against S2X, then why is virtually > every Bitcoin business, with an ?evil? CEO, booming and not losing > customers in droves? > > Reason for the question is: > > I?m very well plugged into the ecosystem and an investor in some of these > companies - all of them are hitting all time record numbers on their KPI?s. > And this is the prevailing trend right now. > > ?Users? aren?t going anywhere or leaving these businesses, in contrast to > what one would expect if there was no support for S2X? > > These facts belies the narrative that there is no support for Segwit2x, > from a quantitative perspective. One could argue that the market is > rallying now because of S2X. > > > On Oct 15, 2017, at 18:06, bitPico via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > There is no fork. Perhaps it?s a spoon? > > Bitcoin1x if it exists post upgrade with less hashrate will be an Altcoin. > The inverse is also true. But this list isn?t for speculation; just the > facts. > > One of those facts is people are encouraging a chain split for self > financial gain. Nobody knows the legality of printing money by blockchain > duplication but we do know it is ignorant economics like a central bank > would do. That said; those that want to keep the deprecated 1x base block > size are economically ignorant or greedy or both as there is no scientific > reasoning. > > ? > > On Oct 15, 2017, at 8:19 PM, Chris Stewart via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > >The terns of reference for the working group, as has been stated multiple > times, is to avoid a network split. > > If there is consensus on one thing, I think we can all admit there is > going to be a network split. > > Therefore, if this working group insists on creating an altcoin, it should > have strong 2 way replay protection. > > -Chris > > > > On Sat, Oct 14, 2017 at 12:02 PM, Phillip Katete via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> The terns of reference for the working group, as has been stated multiple >> times, is to avoid a network split. Implementing strong 2 way RP would >> effectively render the agreement voidable as it?d be fostering a network >> split. From ALL Sybil resistant data available on the blockchain, and >> despite what core would like everyone else to believe, the risk of a >> ?viable? split, sans HF by core, though existent is at this particular >> moment remote. As such, it matter not whether developers that do not want >> strong 2 way RP are in the minority, what matters is that the client does >> not render the agreement voidable. >> >> >> >> *From: *Bitcoin Error Log via Bitcoin-segwit2x >> >> *Sent: *14 October 2017 17:50 >> *To: *Mike Belshe >> *Cc: *bitcoin-segwit2x at lists.linuxfoundation.org >> >> *Subject: *Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> If you won't accept that a significant portion of Bitcoin does not want >> this, let's at least address that some of the tech people in NYA-signing >> businesses, like Jameson Lopp of BitGo, and Alex Petrov of BitFury also >> disagree with the implementation. Are these companies going to ignore the >> very people they hired to be knowledgeable? >> >> I'd argue a minority of developers overall do not want strong replay >> protection. You do not have consensus of developers, Core, or not. >> >> >> >> On Sat, Oct 14, 2017, 6:19 PM Mike Belshe via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> I've banned Scott. >> >> >> >> On Sat, Oct 14, 2017 at 8:11 AM, Cedrick Perrigo via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> You wonders do not belong to this mailing list. Get those silly >> speculations elsewhere. >> >> >> >> It's users deciding to use those services, not the other way around. If >> users are not happy, they can leave any time. But yet you see, that's not >> what's happening. >> >> >> >> >> >> Sent with ProtonMail >> >> Secure Email. >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> Local Time: October 14, 2017 11:04 PM >> >> UTC Time: October 14, 2017 3:04 PM >> >> From: segwit2x_mailinglist at bitcoinreminder.com >> >> To: Cedrick Perrigo >> >> Phillip Katete , bitcoin-segwit2x at lists.linuxfo >> undation.org >> >> >> >> If any of them are pro-segwit1x, they should immediately terminate their >> business with those companies or stop using those wallets. >> >> >> >> I wonder then why Coinbase, Bitpay,.. etc are not asking its users or >> telling them to " immediately terminate their business with those companies >> or stop using those wallets?? >> >> >> >> >> >> I never see people arguing on a Bitcoin Cash mailing list to show which >> one has the majority support. >> >> >> >> BCash was professional enough to include replay protection - which is not >> the case with B2X until now. >> >> >> >> Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo < >> cedrickperrigo at protonmail.com>: >> >> >> >> Funny you listed something that only has less than 400 responses. How is >> that something "objective"? >> >> >> >> Many people don't care or are neutral to segwit1x vs segwit2x, of course. >> Businesses and services they use would take them to segwit2x, like the >> 10,000 merchants and millions of users. If any of them are pro-segwit1x, >> they should immediately terminate their business with those companies or >> stop using those wallets. We didn't see it happen. >> >> >> >> If you truly think those poll counts, why would you still arguing with me >> on a segwit2x mailing list? It only shows that you're extremely doubtful of >> your belief. I never see people arguing on a Bitcoin Cash mailing list to >> show which one has the majority support. >> >> >> >> Also you missed the counter-argument for "majority of miners". So I >> assume at least we agree that majority of miners support segwit2x. :) >> >> >> >> Now this is a technical mailing list. Would trolls please find elsewhere >> for those nonsense? >> >> >> >> >> >> Sent with ProtonMail >> >> Secure Email. >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> Local Time: October 14, 2017 10:48 PM >> >> UTC Time: October 14, 2017 2:48 PM >> >> From: segwit2x_mailinglist at bitcoinreminder.com >> >> To: Cedrick Perrigo >> >> Phillip Katete , bitcoin-segwit2x at lists.linuxfo >> undation.org >> >> >> >> It?s funny how you imply that "10,000 merchants of BitPay, millions of >> users of Blockchain.info >> >> , Bitcoin.com >> , >> Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour >> of b2x? >> >> >> >> The only sybill resistant poll which I know (even created by data of >> users from Coinbase!!!) shows that most of the coinbase customers are not >> in favour of b2x? >> >> >> >> https://luke.dashjr.org/programs/kycpoll/answers.php >> >> >> >> >> This link was twittered on /r/bitcoin, /r/btc and reweeted also by many >> B2X proponents. >> >> >> >> So please, show me some data how these "10,000 merchants of BitPay, >> millions of users of Blockchain.info >> >> , Bitcoin.com >> , >> Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour >> of b2x? >> >> >> >> >> >> Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org>: >> >> >> >> In the grand scheme of things, 10,000 merchants of BitPay, millions of >> users of Blockchain.info >> , >> Bitcoin.com >> , >> Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of >> miners do not count but you only count a tiny thousand people on a Twitter >> poll. How funny this is. >> >> >> >> If you actually look into Twitter, there are only around a thousand >> people who has the "no2x" tag. Not all of them are trolling. However, >> people who state that those are everything that counts, especially on a >> segwit2x mailing list, is certainly trolling and does not worth any >> people's attention. >> >> >> >> Bitcoin will be what majority calls it. Period. >> >> >> >> >> >> Sent with ProtonMail >> >> Secure Email. >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> >> Local Time: October 14, 2017 10:32 PM >> >> UTC Time: October 14, 2017 2:32 PM >> >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> >> To: Scott Roberts , bitcoin-segwit2x at lists.linuxfo >> undation.org >> >> >> >> >> >> In the grand scheme of things, 1,168 responders is not exactly >> representative of the bitcoin community, is it? But that number, for a >> sample size, falls in the range of what is referred to as statistically >> irrelevant. It seems like you?ll have to do even more reading up! >> >> >> >> >> >> *From: *Scott Roberts via Bitcoin-segwit2x >> >> >> *Sent: *14 October 2017 15:25 >> >> *To: *bitcoin-segwit2x at lists.linuxfoundation.org >> >> *Subject: *Re: [Bitcoin-segwit2x] We are all bitcoin >> >> >> >> >> >> > I have NEVER seen a twitter poll on bitcoin that had a statistically >> relevant sample size. But also bear in mind that by it?s very nature, >> twitter creates bubbles where like minded people follow each other. >> >> >> 1,168 with 30x difference in responses is very significant. Show me >> the twitter bubble where like-minded SegWit2x supporters show their >> support. >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://eur01.safelinks.protection.outlook.com/?url=https% >> 3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo% >> 2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com% >> 7C34137d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaa >> aaaaaaaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9 >> h%2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 >> >> >> >> >> >> _______________________________________________ >> >> Bitcoin-segwit2x mailing list >> >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> >> >> -- >> >> >> >> *Mike Belshe CEO, BitGo, Inc *408-718-6885 <(408)%20718-6885> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> -- >> >> >> John C >> >> Bitcoin Error Log >> >> www.bitcoinerrorlog.com >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at foldapp.com Mon Oct 16 03:49:14 2017 From: matt at foldapp.com (Matt Luongo) Date: Sun, 15 Oct 2017 20:49:14 -0700 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: <9F66B1FE-9030-44B8-9D6A-47EA9507DF8D@icloud.com> <68BC6DC2-AC59-44F8-92ED-37A79BD0D1A4@civic.com> Message-ID: You've skipped Vinny's other point, Chris, which is that users of SegWit2x supporting services aren't leaving those services. You can certainly argue that they aren't participating in consensus if you want, but they're almost certainly the economic majority- it just turns out the economic majority doesn't all trade on BitFinex. -- Matt Luongo foldapp.com On Sun, Oct 15, 2017 at 7:52 PM, Chris Stewart via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >If the broader Bitcoin ecosystem is so against S2X, then why is virtually > every Bitcoin business, with an ?evil? CEO, booming and not losing > customers in droves? > > The chain split hasn't happened yet. Businesses -- especially those that > act as custodians -- will have to credit users with tokens on both chains. > Those that aren't acting as custodians haven't had the opportunity to > transact with the new segwit2x currency. > > >These facts belies the narrative that there is no support for Segwit2x, > from a quantitative perspective. One could argue that the market is > rallying now because of S2X. > > The closest thing we've had to a quantitative measurement is the bitfinex > future token for the economic majority (I don't count custodians voting > unilaterally on behalf of all their customers). Currently it is trading at > ~0.85/1 BT1/BTC (bitcoin) and 0.15/1 BT2/BTC (segwit2x coin). I'm not > saying that this future token is perfect -- there are problems with it's > structure and some people don't trust bitfinex. I think it is a better > indicator of support for the two coins rather than just saying price > increase implies support for segwit2x. > > https://www.bitfinex.com/stats > > -Chris > > On Sun, Oct 15, 2017 at 9:31 PM, Vinny Lingham wrote: > >> I have an even more poignant question : >> >> If the broader Bitcoin ecosystem is so against S2X, then why is virtually >> every Bitcoin business, with an ?evil? CEO, booming and not losing >> customers in droves? >> >> Reason for the question is: >> >> I?m very well plugged into the ecosystem and an investor in some of these >> companies - all of them are hitting all time record numbers on their KPI?s. >> And this is the prevailing trend right now. >> >> ?Users? aren?t going anywhere or leaving these businesses, in contrast to >> what one would expect if there was no support for S2X? >> >> These facts belies the narrative that there is no support for Segwit2x, >> from a quantitative perspective. One could argue that the market is >> rallying now because of S2X. >> >> >> On Oct 15, 2017, at 18:06, bitPico via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> There is no fork. Perhaps it?s a spoon? >> >> Bitcoin1x if it exists post upgrade with less hashrate will be an >> Altcoin. The inverse is also true. But this list isn?t for speculation; >> just the facts. >> >> One of those facts is people are encouraging a chain split for self >> financial gain. Nobody knows the legality of printing money by blockchain >> duplication but we do know it is ignorant economics like a central bank >> would do. That said; those that want to keep the deprecated 1x base block >> size are economically ignorant or greedy or both as there is no scientific >> reasoning. >> >> ? >> >> On Oct 15, 2017, at 8:19 PM, Chris Stewart via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> >The terns of reference for the working group, as has been stated >> multiple times, is to avoid a network split. >> >> If there is consensus on one thing, I think we can all admit there is >> going to be a network split. >> >> Therefore, if this working group insists on creating an altcoin, it >> should have strong 2 way replay protection. >> >> -Chris >> >> >> >> On Sat, Oct 14, 2017 at 12:02 PM, Phillip Katete via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> The terns of reference for the working group, as has been stated >>> multiple times, is to avoid a network split. Implementing strong 2 way RP >>> would effectively render the agreement voidable as it?d be fostering a >>> network split. From ALL Sybil resistant data available on the blockchain, >>> and despite what core would like everyone else to believe, the risk of a >>> ?viable? split, sans HF by core, though existent is at this particular >>> moment remote. As such, it matter not whether developers that do not want >>> strong 2 way RP are in the minority, what matters is that the client does >>> not render the agreement voidable. >>> >>> >>> >>> *From: *Bitcoin Error Log via Bitcoin-segwit2x >>> >>> *Sent: *14 October 2017 17:50 >>> *To: *Mike Belshe >>> *Cc: *bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> *Subject: *Re: [Bitcoin-segwit2x] We are all bitcoin >>> >>> >>> >>> If you won't accept that a significant portion of Bitcoin does not want >>> this, let's at least address that some of the tech people in NYA-signing >>> businesses, like Jameson Lopp of BitGo, and Alex Petrov of BitFury also >>> disagree with the implementation. Are these companies going to ignore the >>> very people they hired to be knowledgeable? >>> >>> I'd argue a minority of developers overall do not want strong replay >>> protection. You do not have consensus of developers, Core, or not. >>> >>> >>> >>> On Sat, Oct 14, 2017, 6:19 PM Mike Belshe via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>> I've banned Scott. >>> >>> >>> >>> On Sat, Oct 14, 2017 at 8:11 AM, Cedrick Perrigo via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>> You wonders do not belong to this mailing list. Get those silly >>> speculations elsewhere. >>> >>> >>> >>> It's users deciding to use those services, not the other way around. If >>> users are not happy, they can leave any time. But yet you see, that's not >>> what's happening. >>> >>> >>> >>> >>> >>> Sent with ProtonMail >>> >>> Secure Email. >>> >>> >>> >>> -------- Original Message -------- >>> >>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>> >>> Local Time: October 14, 2017 11:04 PM >>> >>> UTC Time: October 14, 2017 3:04 PM >>> >>> From: segwit2x_mailinglist at bitcoinreminder.com >>> >>> To: Cedrick Perrigo >>> >>> Phillip Katete , bitcoin-segwit2x at lists.linuxfo >>> undation.org >>> >>> >>> >>> If any of them are pro-segwit1x, they should immediately terminate >>> their business with those companies or stop using those wallets. >>> >>> >>> >>> I wonder then why Coinbase, Bitpay,.. etc are not asking its users or >>> telling them to " immediately terminate their business with those companies >>> or stop using those wallets?? >>> >>> >>> >>> >>> >>> I never see people arguing on a Bitcoin Cash mailing list to show which >>> one has the majority support. >>> >>> >>> >>> BCash was professional enough to include replay protection - which is >>> not the case with B2X until now. >>> >>> >>> >>> Am 14.10.2017 um 17:00 schrieb Cedrick Perrigo < >>> cedrickperrigo at protonmail.com>: >>> >>> >>> >>> Funny you listed something that only has less than 400 responses. How is >>> that something "objective"? >>> >>> >>> >>> Many people don't care or are neutral to segwit1x vs segwit2x, of >>> course. Businesses and services they use would take them to segwit2x, like >>> the 10,000 merchants and millions of users. If any of them are >>> pro-segwit1x, they should immediately terminate their business with those >>> companies or stop using those wallets. We didn't see it happen. >>> >>> >>> >>> If you truly think those poll counts, why would you still arguing with >>> me on a segwit2x mailing list? It only shows that you're extremely doubtful >>> of your belief. I never see people arguing on a Bitcoin Cash mailing list >>> to show which one has the majority support. >>> >>> >>> >>> Also you missed the counter-argument for "majority of miners". So I >>> assume at least we agree that majority of miners support segwit2x. :) >>> >>> >>> >>> Now this is a technical mailing list. Would trolls please find elsewhere >>> for those nonsense? >>> >>> >>> >>> >>> >>> Sent with ProtonMail >>> >>> Secure Email. >>> >>> >>> >>> -------- Original Message -------- >>> >>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>> >>> Local Time: October 14, 2017 10:48 PM >>> >>> UTC Time: October 14, 2017 2:48 PM >>> >>> From: segwit2x_mailinglist at bitcoinreminder.com >>> >>> To: Cedrick Perrigo >>> >>> Phillip Katete , bitcoin-segwit2x at lists.linuxfo >>> undation.org >>> >>> >>> >>> It?s funny how you imply that "10,000 merchants of BitPay, millions of >>> users of Blockchain.info >>> >>> , Bitcoin.com >>> , >>> Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour >>> of b2x? >>> >>> >>> >>> The only sybill resistant poll which I know (even created by data of >>> users from Coinbase!!!) shows that most of the coinbase customers are not >>> in favour of b2x? >>> >>> >>> >>> https://luke.dashjr.org/programs/kycpoll/answers.php >>> >>> >>> >>> >>> This link was twittered on /r/bitcoin, /r/btc and reweeted also by many >>> B2X proponents. >>> >>> >>> >>> So please, show me some data how these "10,000 merchants of BitPay, >>> millions of users of Blockchain.info >>> >>> , Bitcoin.com >>> , >>> Xapo, Coinbase, millions of buyers and sellers of OpenBazar? are in favour >>> of b2x? >>> >>> >>> >>> >>> >>> Am 14.10.2017 um 16:44 schrieb Cedrick Perrigo via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org>: >>> >>> >>> >>> In the grand scheme of things, 10,000 merchants of BitPay, millions of >>> users of Blockchain.info >>> , >>> Bitcoin.com >>> , >>> Xapo, Coinbase, millions of buyers and sellers of OpenBazar, majority of >>> miners do not count but you only count a tiny thousand people on a Twitter >>> poll. How funny this is. >>> >>> >>> >>> If you actually look into Twitter, there are only around a thousand >>> people who has the "no2x" tag. Not all of them are trolling. However, >>> people who state that those are everything that counts, especially on a >>> segwit2x mailing list, is certainly trolling and does not worth any >>> people's attention. >>> >>> >>> >>> Bitcoin will be what majority calls it. Period. >>> >>> >>> >>> >>> >>> Sent with ProtonMail >>> >>> Secure Email. >>> >>> >>> >>> -------- Original Message -------- >>> >>> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >>> >>> Local Time: October 14, 2017 10:32 PM >>> >>> UTC Time: October 14, 2017 2:32 PM >>> >>> From: bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> To: Scott Roberts , >>> bitcoin-segwit2x at lists.linuxfoundation.org < >>> bitcoin-segwit2x at lists.linuxfoundation.org> >>> >>> >>> >>> >>> >>> In the grand scheme of things, 1,168 responders is not exactly >>> representative of the bitcoin community, is it? But that number, for a >>> sample size, falls in the range of what is referred to as statistically >>> irrelevant. It seems like you?ll have to do even more reading up! >>> >>> >>> >>> >>> >>> *From: *Scott Roberts via Bitcoin-segwit2x >>> >>> >>> *Sent: *14 October 2017 15:25 >>> >>> *To: *bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> *Subject: *Re: [Bitcoin-segwit2x] We are all bitcoin >>> >>> >>> >>> >>> >>> > I have NEVER seen a twitter poll on bitcoin that had a statistically >>> relevant sample size. But also bear in mind that by it?s very nature, >>> twitter creates bubbles where like minded people follow each other. >>> >>> >>> 1,168 with 30x difference in responses is very significant. Show me >>> the twitter bubble where like-minded SegWit2x supporters show their >>> support. >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A >>> %2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitco >>> in-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C341 >>> 37d5584c04799c18b08d5130f5dd0%7C84df9e7fe9f640afb435aaaaaaaa >>> aaaa%7C1%7C0%7C636435879064911890&sdata=2tpwhMVlH96kQI9h% >>> 2BEwbedJtbEffjz%2FMMOgKN3XMKyY%3D&reserved=0 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Bitcoin-segwit2x mailing list >>> >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> >>> >>> >>> >>> -- >>> >>> >>> >>> *Mike Belshe CEO, BitGo, Inc *408-718-6885 <(408)%20718-6885> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> -- >>> >>> >>> John C >>> >>> Bitcoin Error Log >>> >>> www.bitcoinerrorlog.com >>> >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Mon Oct 16 05:19:25 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Mon, 16 Oct 2017 01:19:25 -0400 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: This has been stated hundreds of times -- strong two-way RP won't happen on the segwit2x Bitcoin chain. Chris, do you understand how human interaction works? Segwit2x working group owe you nothing. The thing you proposed only help yourself, but not the broader segwit2x Bitcoin community. It's just like you ask some random person on a street to give you one million dollars, and complain why they refuse to do so or even talk to you. Stop begging. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > Local Time: October 16, 2017 8:19 AM > UTC Time: October 16, 2017 12:19 AM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: Phillip Katete > bitcoin-segwit2x at lists.linuxfoundation.org > >>The terns of reference for the working group, as has been stated multiple times, is to avoid a network split. > If there is consensus on one thing, I think we can all admit there is going to be a network split. > > Therefore, if this working group insists on creating an altcoin, it should have strong 2 way replay protection. > > -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinny at civic.com Mon Oct 16 05:27:26 2017 From: vinny at civic.com (Vinny Lingham) Date: Sun, 15 Oct 2017 22:27:26 -0700 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: Message-ID: <7E5F8E68-4B45-4487-9B49-75AFA1146850@civic.com> To put it more bluntly, RP means that the agreement will fall apart so asking for 2-way RP is akin to asking for it to end. Sent from my iPhone > On Oct 15, 2017, at 22:19, Cedrick Perrigo via Bitcoin-segwit2x wrote: > > This has been stated hundreds of times -- strong two-way RP won't happen on the segwit2x Bitcoin chain. > > Chris, do you understand how human interaction works? Segwit2x working group owe you nothing. The thing you proposed only help yourself, but not the broader segwit2x Bitcoin community. It's just like you ask some random person on a street to give you one million dollars, and complain why they refuse to do so or even talk to you. > > Stop begging. > > > Sent with ProtonMail Secure Email. > >> -------- Original Message -------- >> Subject: Re: [Bitcoin-segwit2x] We are all bitcoin >> Local Time: October 16, 2017 8:19 AM >> UTC Time: October 16, 2017 12:19 AM >> From: bitcoin-segwit2x at lists.linuxfoundation.org >> To: Phillip Katete >> bitcoin-segwit2x at lists.linuxfoundation.org >> >> >The terns of reference for the working group, as has been stated multiple times, is to avoid a network split. >> If there is consensus on one thing, I think we can all admit there is going to be a network split. >> >> Therefore, if this working group insists on creating an altcoin, it should have strong 2 way replay protection. >> >> -Chris > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrickperrigo at protonmail.com Mon Oct 16 05:33:40 2017 From: cedrickperrigo at protonmail.com (Cedrick Perrigo) Date: Mon, 16 Oct 2017 01:33:40 -0400 Subject: [Bitcoin-segwit2x] We are all bitcoin In-Reply-To: References: <9F66B1FE-9030-44B8-9D6A-47EA9507DF8D@icloud.com> <68BC6DC2-AC59-44F8-92ED-37A79BD0D1A4@civic.com> Message-ID: First, have you ever looked at the BT1/BTC and BT2/BTC volume? Segwit2x Bitcoin constantly has 10 times more volume compared with segwit1x altcoin. Usually the market makes it so that trading volume and market price is aligned. This can be seen from coinmarketcap. Volume is less likely to be manipulated compared with price given the nature of BT1 and BT2. The conclusion we can get so far is at best indecisive. How is that in favor of you? Second, what happened during the Clinton and Trump president election? Given the toxicity from Blockstream/Core's segwit1x altcoin, most people won't vote until the last minute. By the way, at that time, those in the future market on the Trump side made a good fortune. Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [Bitcoin-segwit2x] We are all bitcoin > Local Time: October 16, 2017 10:52 AM > UTC Time: October 16, 2017 2:52 AM > From: bitcoin-segwit2x at lists.linuxfoundation.org > To: Vinny Lingham > bitcoin-segwit2x at lists.linuxfoundation.org > >>If the broader Bitcoin ecosystem is so against S2X, then why is virtually every Bitcoin business, with an ?evil? CEO, booming and not losing customers in droves? > The chain split hasn't happened yet. Businesses -- especially those that act as custodians -- will have to credit users with tokens on both chains. Those that aren't acting as custodians haven't had the opportunity to transact with the new segwit2x currency. > >>These facts belies the narrative that there is no support for Segwit2x, from a quantitative perspective. One could argue that the market is rallying now because of S2X. > The closest thing we've had to a quantitative measurement is the bitfinex future token for the economic majority (I don't count custodians voting unilaterally on behalf of all their customers). Currently it is trading at ~0.85/1 BT1/BTC (bitcoin) and 0.15/1 BT2/BTC (segwit2x coin). I'm not saying that this future token is perfect -- there are problems with it's structure and some people don't trust bitfinex. I think it is a better indicator of support for the two coins rather than just saying price increase implies support for segwit2x. > > https://www.bitfinex.com/stats > > -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From robtcspier1 at tutanota.com Wed Oct 18 15:43:33 2017 From: robtcspier1 at tutanota.com (robtcspier1 at tutanota.com) Date: Wed, 18 Oct 2017 17:43:33 +0200 (CEST) Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split Message-ID: THIS IS A DRAFT A lot of anxiety and confusion regarding the future direction ofBitcoin around the 2x fork date has appeared. The potential of a chainsplit and resulting chaos in the markets keeps coming up repeatedly. In here, a comparatively simple change to the legacy ("1x") and 2xchain is proposed that will solve this problem. This change is a combination of two soft forks (one on eachchain), meaning it will be backwards compatible with all existingclients, no matter on which chain they operate. As a soft fork, itis also an upgrade that solely concerns the Bitcoin miners, needingno further action on part of the users of any touched block chain. This change will ensure a smooth transition through the 2x phase ofSegWit2x and ensure just a single chain will emerge. Principle The change involves a deliberation of abandonment (DOA) chain,defined as follows: This DOA is the chain of just block headers and coin base transactions,compatible with the legacy chain rules, starting at the 2x fork point(FP; starting at block height 494,784). All rules for difficulty andmaximum cumulative difficulty and so forth are left unchanged. >From the maximum difficulty DOA, a state flag "abandoned" (A) will becalculated, like this: If the DOA is empty, A amounts to 'true'.If the DOA is non-empty, the coin base transactions and merkle roots inthe DOA will be checked: if any transaction merkle roots in any of the DOA block headersindicate that more than just the coin base transaction would be inthe merkle tree, A amounts to 'false'. (Requirement 1) likewise, if any coin base transaction in the DOA has more than oneoutput or an output that does not follow a simple TBD "burn"pattern, A amounts to 'false' as well. (Requirement 2) If the above checks pass, 'A' will be true. It should be noted here that the DOA chain of headers can not beconfused with the 2x chain, as the 2x chain has a requirement ofhaving a base block being truly bigger than 1000,000 bytes at the FP,contradicting Requirement 1. To ensure a smooth transaction on the 2x chain, a soft fork ruleis then added to that chain. It simply requires that the DOA criterion, as defined above,evaluates to true. If this hash is out of date (does not reflect the DOA chain tip) or the DOA criterionfalse, a block is to be considered invalid and orphaned. Implementing this change on 2x will ensure that each miner isurged to create empty blocks on the legacy chain, assuminga simple 50% majority is willing to upgrade to SegWit2X at the FP. And if not, it will symmetrically cause all miners to stick with the legacy chain - and thus ensure a smooth, continuous operation. >From the POV of both chains, this appears as a simple, respective softfork. It is compatible with all old legacy nodes and will cleanly signalthat it is time to upgrade. Protocol issues On the network level, the change is conceptually simple. "block"messages will be accepted, both if they fulfill the "must be greaterthan 1MB" rule of the SegWit2X chain, as well as if they don't. But in the latter case, the messages are added to the DOA chain, ifthe checks for proof of work on the block header pass. SegWit2X compatible clients will will forward both DOA blocks as well asregular blocks in "block" messages. Sunset clause After 3 months, the requirement to keep track of the DOA chain will be dropped. Activation The soft forks in this proposal are to be considered active with the simple majority (>50%) of blocks from height 494352 .. 494783 have the uppercase string "B0RG" anywhere in their coin base or by an activation through another, TBD mechanism. This idea has been posted to reddit a discussion thread as well: https://www.reddit.com/r/btc/comments/775o5q/proposal_b0rg_bitcoin_zero_replay_guarantee -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Sat Oct 21 20:02:57 2017 From: bitpico at icloud.com (bitPico) Date: Sat, 21 Oct 2017 16:02:57 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: Message-ID: This is the SegWit2x mailing list; if you desire to discuss the legacy 1x chain this is not the place. Kind Regards > On Oct 18, 2017, at 11:43 AM, robtcspierre via Bitcoin-segwit2x wrote: > > THIS IS A DRAFT > > A lot of anxiety and confusion regarding the future direction of Bitcoin around the 2x fork date has appeared. The potential of a chain split and resulting chaos in the markets keeps coming up repeatedly. > > In here, a comparatively simple change to the legacy ("1x") and 2x chain is proposed that will solve this problem. > > This change is a combination of two soft forks (one on each chain), meaning it will be backwards compatible with all existing clients, no matter on which chain they operate. As a soft fork, it is also an upgrade that solely concerns the Bitcoin miners, needing no further action on part of the users of any touched block chain. > > This change will ensure a smooth transition through the 2x phase of SegWit2x and ensure just a single chain will emerge. > > > > Principle > > The change involves a deliberation of abandonment (DOA) chain, defined as follows: > > This DOA is the chain of just block headers and coin base transactions, compatible with the legacy chain rules, starting at the 2x fork point (FP; starting at block height 494,784). All rules for difficulty and maximum cumulative difficulty and so forth are left unchanged. > > From the maximum difficulty DOA, a state flag "abandoned" (A) will be calculated, like this: > > If the DOA is empty, A amounts to 'true'. If the DOA is non-empty, the coin base transactions and merkle roots in the DOA will be checked: > > if any transaction merkle roots in any of the DOA block headers indicate that more than just the coin base transaction would be in the merkle tree, A amounts to 'false'. (Requirement 1) > > likewise, if any coin base transaction in the DOA has more than one output or an output that does not follow a simple TBD "burn" pattern, A amounts to 'false' as well. (Requirement 2) > > If the above checks pass, 'A' will be true. > > > > It should be noted here that the DOA chain of headers can not be confused with the 2x chain, as the 2x chain has a requirement of having a base block being truly bigger than 1000,000 bytes at the FP, contradicting Requirement 1. > > > > To ensure a smooth transaction on the 2x chain, a soft fork rule is then added to that chain. It simply requires that the DOA criterion, as defined above, evaluates to true. > > > > If this hash is out of date (does not reflect the DOA chain tip) or the DOA criterion false, a block is to be considered invalid and orphaned. > > > > Implementing this change on 2x will ensure that each miner is urged to create empty blocks on the legacy chain, assuming a simple 50% majority is willing to upgrade to SegWit2X at the FP. And if not, it will symmetrically cause all miners to stick with the legacy chain - and thus ensure a smooth, continuous operation. > > > > From the POV of both chains, this appears as a simple, respective soft fork. > > It is compatible with all old legacy nodes and will cleanly signal that it is time to upgrade. > > > > Protocol issues > > > > On the network level, the change is conceptually simple. "block" messages will be accepted, both if they fulfill the "must be greater than 1MB" rule of the SegWit2X chain, as well as if they don't. > > But in the latter case, the messages are added to the DOA chain, if the checks for proof of work on the block header pass. > > SegWit2X compatible clients will will forward both DOA blocks as well as regular blocks in "block" messages. > > > > Sunset clause > > After 3 months, the requirement to keep track of the DOA chain will be dropped. > > > > Activation > > The soft forks in this proposal are to be considered active with the simple majority (>50%) of blocks from height 494352 .. 494783 have the uppercase string "B0RG" anywhere in their coin base or by an activation through another, TBD mechanism. > > > > This idea has been posted to reddit a discussion thread as well: https://www.reddit.com/r/btc/comments/775o5q/proposal_b0rg_bitcoin_zero_replay_guarantee > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From robtcspier1 at tutanota.com Sun Oct 22 08:38:24 2017 From: robtcspier1 at tutanota.com (robtcspier1 at tutanota.com) Date: Sun, 22 Oct 2017 10:38:24 +0200 (CEST) Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <> Message-ID: 21. Oct 2017 22:02 by bitpico at icloud.com: > This is the SegWit2x mailing list; if you desire to discuss the legacy 1x chain this is not the place. But this proposal draft primarily deals exactly with a soft fork on the *2x* chain - which, when accepted by hash power majority, would *also* imply a soft fork on the legacy chain. What is not on-topic about that? This is an attempt to ensure a single chain going forward. As an upcoming brand war ("what is Bitcoin?") seems to be a major issue going forward when both chains are mined, it appears to me that a mandatory stopping of the respective other chain would help immensely with keeping Bitcoin intact - which implies keeping it in a single piece! Note also that this should be symmetric: You either mine 1x (and stop 2x) or you mine 2x (and stop 1x). Kind regards, robtcspierre -------------- next part -------------- An HTML attachment was scrubbed... URL: From dizzle at pointbiz.com Sun Oct 22 13:55:29 2017 From: dizzle at pointbiz.com (Peter) Date: Sun, 22 Oct 2017 09:55:29 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: Message-ID: Can this proposal be done using merged mining? Peter On Oct 22, 2017 4:38 AM, "robtcspierre via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > 21. Oct 2017 22:02 by bitpico at icloud.com: > > This is the SegWit2x mailing list; if you desire to discuss the legacy 1x > chain this is not the place. > > > But this proposal draft primarily deals exactly with a soft fork on the > *2x* chain - which, when accepted by hash power majority, would *also* > imply a soft fork on the legacy chain. What is not on-topic about that? > > > This is an attempt to ensure a single chain going forward. As an upcoming > brand war ("what is Bitcoin?") seems to be a major issue going forward when > both chains are mined, it appears to me that a mandatory stopping of the > respective other chain would help immensely with keeping Bitcoin intact - > which implies keeping it in a single piece! > > > Note also that this should be symmetric: You either mine 1x (and stop 2x) > or you mine 2x (and stop 1x). > > > Kind regards, > > > robtcspierre > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robtcspier1 at tutanota.com Tue Oct 24 09:06:03 2017 From: robtcspier1 at tutanota.com (robtcspier1 at tutanota.com) Date: Tue, 24 Oct 2017 11:06:03 +0200 (CEST) Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <> <> Message-ID: Hi, > Can this proposal be done using merged mining?? As far as I can see, only by hard forking btc1 once more.? The B0RG proposal has the advantage of being just a soft fork. Best regards, robtcspierre -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitcoinerrorlog at gmail.com Tue Oct 24 09:24:45 2017 From: bitcoinerrorlog at gmail.com (Bitcoin Error Log) Date: Tue, 24 Oct 2017 09:24:45 +0000 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: Message-ID: All of the exchanges and the community have conceded that this fork will result in two coins. They all decided to name the new one B2X. There is no longer any reason to entertain the illusion of everyone migrating, thus you are obligated to include strong replay protection at this point. Otherwise you are choosing to be hostile and if you cause loss, you may expose yourself to risks or recourse. Thank you for understanding, I look forward to everyone playing nicely together, as appropriate. On Tue, Oct 24, 2017 at 5:06 AM robtcspierre via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Hi, > > Can this proposal be done using merged mining? > > > As far as I can see, only by hard forking btc1 once more. The B0RG > proposal has the advantage of being just a soft fork. > > > Best regards, > > > robtcspierre > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- John C Bitcoin Error Log www.bitcoinerrorlog.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Tue Oct 24 11:01:06 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Tue, 24 Oct 2017 11:01:06 +0000 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: , Message-ID: WRONG. The exchanges are speculating that there will be 2 coins, quite distinct from 2 chains let alone 2 viable chains, whereas it is the intent of the NYA WG (thus btc1 client) not to split the network. In-fact the overwhelming majority of the community concede that the minority chain (should there be a viable one post Nov HF) MUST implement RP otherwise they will expose their users to the risk of losses and themselves to risks of recourse. From: Bitcoin Error Log via Bitcoin-segwit2x Sent: 24 October 2017 10:25 To: robtcspier1 at tutanota.com Cc: Bitcoin Segwit2x Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split All of the exchanges and the community have conceded that this fork will result in two coins. They all decided to name the new one B2X. There is no longer any reason to entertain the illusion of everyone migrating, thus you are obligated to include strong replay protection at this point. Otherwise you are choosing to be hostile and if you cause loss, you may expose yourself to risks or recourse. Thank you for understanding, I look forward to everyone playing nicely together, as appropriate. On Tue, Oct 24, 2017 at 5:06 AM robtcspierre via Bitcoin-segwit2x > wrote: Hi, Can this proposal be done using merged mining? As far as I can see, only by hard forking btc1 once more. The B0RG proposal has the advantage of being just a soft fork. Best regards, robtcspierre _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -- John C Bitcoin Error Log www.bitcoinerrorlog.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaredr26 at gmail.com Tue Oct 24 14:04:24 2017 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Tue, 24 Oct 2017 07:04:24 -0700 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: Message-ID: Per longtime major Core Developers, upgrades to Bitcoin (which this is) do not need replay protection, nor should they have it: https://twitter.com/LukeDashjr/status/921944291777437697 On Tue, Oct 24, 2017 at 2:24 AM, Bitcoin Error Log via Bitcoin-segwit2x wrote: > All of the exchanges and the community have conceded that this fork will > result in two coins. They all decided to name the new one B2X. > > There is no longer any reason to entertain the illusion of everyone > migrating, thus you are obligated to include strong replay protection at > this point. Otherwise you are choosing to be hostile and if you cause loss, > you may expose yourself to risks or recourse. > > Thank you for understanding, I look forward to everyone playing nicely > together, as appropriate. > > > > On Tue, Oct 24, 2017 at 5:06 AM robtcspierre via Bitcoin-segwit2x > wrote: >> >> Hi, >> >> Can this proposal be done using merged mining? >> >> >> As far as I can see, only by hard forking btc1 once more. The B0RG >> proposal has the advantage of being just a soft fork. >> >> >> Best regards, >> >> >> robtcspierre >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- > > John C > Bitcoin Error Log > www.bitcoinerrorlog.com > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From vogel at bitso.com Tue Oct 24 14:08:09 2017 From: vogel at bitso.com (Daniel Vogel) Date: Tue, 24 Oct 2017 09:08:09 -0500 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: Message-ID: <3554E58F-588C-4D0B-B642-72B7162DA6E3@bitso.com> We are not adding support for both chains because we are speculating. We are adding support because our customers are demanding it. Of note is that not a single one of our customers demanded support for the recent legacy Ethereum chain. But just as much as some people are speculating that there'll be two chains you are also speculating that there will only be one chain. What is happening is irresponsible. Daniel Daniel Vogel ? Bitso President Facebook ? Twitter ? LinkedIn > On Oct 24, 2017, at 6:01 AM, Phillip Katete via Bitcoin-segwit2x wrote: > > WRONG. The exchanges are speculating that there will be 2 coins, quite distinct from 2 chains let alone 2 viable chains, whereas it is the intent of the NYA WG (thus btc1 client) not to split the network. > In-fact the overwhelming majority of the community concede that the minority chain (should there be a viable one post Nov HF) MUST implement RP otherwise they will expose their users to the risk of losses and themselves to risks of recourse. > > From: Bitcoin Error Log via Bitcoin-segwit2x > Sent: 24 October 2017 10:25 > To: robtcspier1 at tutanota.com > Cc: Bitcoin Segwit2x > Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split > > All of the exchanges and the community have conceded that this fork will result in two coins. They all decided to name the new one B2X. > > There is no longer any reason to entertain the illusion of everyone migrating, thus you are obligated to include strong replay protection at this point. Otherwise you are choosing to be hostile and if you cause loss, you may expose yourself to risks or recourse. > > Thank you for understanding, I look forward to everyone playing nicely together, as appropriate. > > > > On Tue, Oct 24, 2017 at 5:06 AM robtcspierre via Bitcoin-segwit2x wrote: > Hi, > > Can this proposal be done using merged mining? > > > As far as I can see, only by hard forking btc1 once more. The B0RG proposal has the advantage of being just a soft fork. > > > > Best regards, > > > > robtcspierre > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- > > John C > Bitcoin Error Log > www.bitcoinerrorlog.com > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitcoinerrorlog at gmail.com Tue Oct 24 14:19:35 2017 From: bitcoinerrorlog at gmail.com (Bitcoin Error Log) Date: Tue, 24 Oct 2017 14:19:35 +0000 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: <3554E58F-588C-4D0B-B642-72B7162DA6E3@bitso.com> References: <3554E58F-588C-4D0B-B642-72B7162DA6E3@bitso.com> Message-ID: Phillip, there's no speculating going on. These are published policies and official. Everyone in Bitcoin world other than the S2X team has decided the legacy chain will live, and that replay protection is appropriate. Jared, I don't care to take what you, or Luke, or any Core dev said as gospel. I am presenting verifiable facts and imploring the S2X team to come to reality. Otherwise you are choosing indefensible negligence and malfeasance. On Tue, Oct 24, 2017 at 10:08 AM Daniel Vogel wrote: > We are not adding support for both chains because we are speculating. We > are adding support because our customers are demanding it. > > Of note is that not a single one of our customers demanded support for the > recent legacy Ethereum chain. > > But just as much as some people are speculating that there'll be two > chains you are also speculating that there will only be one chain. > > What is happening is irresponsible. > > Daniel > > > *Daniel Vogel * ? *Bitso * > President <+525563828572> > Facebook ? Twitter > ? LinkedIn > > > On Oct 24, 2017, at 6:01 AM, Phillip Katete via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > WRONG. The exchanges are speculating that there will be 2 coins, quite > distinct from 2 chains let alone 2 viable chains, whereas it is the intent > of the NYA WG (thus btc1 client) not to split the network. > > In-fact the overwhelming majority of the community concede that the > minority chain (should there be a viable one post Nov HF) MUST implement RP > otherwise they will expose their users to the risk of losses and themselves > to risks of recourse. > > > > *From: *Bitcoin Error Log via Bitcoin-segwit2x > > *Sent: *24 October 2017 10:25 > *To: *robtcspier1 at tutanota.com > *Cc: *Bitcoin Segwit2x > *Subject: *Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay > guarantee) - Ensuring a smooth 2X upgrade without a chain split > > > > All of the exchanges and the community have conceded that this fork will > result in two coins. They all decided to name the new one B2X. > > > > There is no longer any reason to entertain the illusion of everyone > migrating, thus you are obligated to include strong replay protection at > this point. Otherwise you are choosing to be hostile and if you cause loss, > you may expose yourself to risks or recourse. > > > > Thank you for understanding, I look forward to everyone playing nicely > together, as appropriate. > > > > > > > > On Tue, Oct 24, 2017 at 5:06 AM robtcspierre via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > Hi, > > > > Can this proposal be done using merged mining? > > > > As far as I can see, only by hard forking btc1 once more. The B0RG > proposal has the advantage of being just a soft fork. > > > > Best regards, > > > > robtcspierre > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > -- > > > John C > > Bitcoin Error Log > > www.bitcoinerrorlog.com > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- John C Bitcoin Error Log www.bitcoinerrorlog.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Tue Oct 24 14:26:59 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Tue, 24 Oct 2017 14:26:59 +0000 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: <3554E58F-588C-4D0B-B642-72B7162DA6E3@bitso.com> References: , <3554E58F-588C-4D0B-B642-72B7162DA6E3@bitso.com> Message-ID: 1. There are going to be 2 chains ? there is NO speculation in this, we know it, aka legacy chain and the upgraded chain. 2. By hash, there is going to be a majority and minority chain ? there is NO speculation here as it flows from 1 above. 3. Users (and exchanges by proxy) are speculating that both chains are going to be viable ? no doubt at all that this is pure speculation. 4. All the data available, even at this late stage, clearly indicates that the legacy chain will not be viable. There is no speculation in this at all. Ignoring all other data points (which do / may not favour the legacy chain anyway) and relying on signalling intent alone, the data indicates that the legacy chain can not be viable post HF. Quite aside from the stated objective of the NYA WG not implementing code that?ll encourage a split, there is no compelling reason to protect against replay attacks on an otherwise unusable chain. If the legacy chain were to show signs of stuttering back to life, then the responsibility would be on the legacy chain, as the minority chain, to implement RP. From: Daniel Vogel Sent: 24 October 2017 15:08 To: Phillip Katete Cc: Bitcoin Error Log; robtcspier1 at tutanota.com; Bitcoin Segwit2x Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split We are not adding support for both chains because we are speculating. We are adding support because our customers are demanding it. Of note is that not a single one of our customers demanded support for the recent legacy Ethereum chain. But just as much as some people are speculating that there'll be two chains you are also speculating that there will only be one chain. What is happening is irresponsible. Daniel [http://cloudfront.giantuser.com/data/images/4ae191b55e616cc4360ce7a890bca68f/original.png] Daniel Vogel ? Bitso President Facebook ? Twitter ? LinkedIn On Oct 24, 2017, at 6:01 AM, Phillip Katete via Bitcoin-segwit2x > wrote: WRONG. The exchanges are speculating that there will be 2 coins, quite distinct from 2 chains let alone 2 viable chains, whereas it is the intent of the NYA WG (thus btc1 client) not to split the network. In-fact the overwhelming majority of the community concede that the minority chain (should there be a viable one post Nov HF) MUST implement RP otherwise they will expose their users to the risk of losses and themselves to risks of recourse. From: Bitcoin Error Log via Bitcoin-segwit2x Sent: 24 October 2017 10:25 To: robtcspier1 at tutanota.com Cc: Bitcoin Segwit2x Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split All of the exchanges and the community have conceded that this fork will result in two coins. They all decided to name the new one B2X. There is no longer any reason to entertain the illusion of everyone migrating, thus you are obligated to include strong replay protection at this point. Otherwise you are choosing to be hostile and if you cause loss, you may expose yourself to risks or recourse. Thank you for understanding, I look forward to everyone playing nicely together, as appropriate. On Tue, Oct 24, 2017 at 5:06 AM robtcspierre via Bitcoin-segwit2x > wrote: Hi, Can this proposal be done using merged mining? As far as I can see, only by hard forking btc1 once more. The B0RG proposal has the advantage of being just a soft fork. Best regards, robtcspierre _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -- John C Bitcoin Error Log www.bitcoinerrorlog.com _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam at bitmex.com Tue Oct 24 14:27:10 2017 From: sam at bitmex.com (Samuel Reed) Date: Tue, 24 Oct 2017 09:27:10 -0500 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: Message-ID: <59EF4DBE.3040006@bitmex.com> BEL has the right idea. It is irresponsible to pretend you have the consensus necessary to do a smooth upgrade without replay protection, when you do not. Continuing on this path is hostile to Bitcoin and its users. Of course upgrades with consensus do not require replay protection, as the original chain is meant to die. It is very obvious now that the 1x chain will not die and any assertion otherwise is intentional ignorance. There are only two responsible options for the 2x team now that the mindshare has been lost: 1. Launch 2x with replay protection, creating another altcoin; this will give miners another SHA256 coin to mine when it is profitable to do so, but will not provide much real value to the community and will even compete against BCH, or 2. Don't launch 2x at all, and attempt to create consensus another day. A responsible team should not consider a third option, where 2x is launched without protection, causing potentially millions of coins to leak and untold accounting nightmares for every user and exchange. -- Samuel Reed CTO, BitMEX bitcoin-segwit2x-request at lists.linuxfoundation.org wrote: > Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay > guarantee) - Ensuring a smooth 2X upgrade without a chain split From pekatete at hotmail.com Tue Oct 24 14:40:05 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Tue, 24 Oct 2017 14:40:05 +0000 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: <59EF4DBE.3040006@bitmex.com> References: , <59EF4DBE.3040006@bitmex.com> Message-ID: Samuel you are barking up the wrong tree here (as has been said a multitude of times). RP that encourages a network split would render the NYA voidable. I am sure that is what you want, but clearly that is not going to happen. The SegWit2x upgrade has overwhelming consensus as measured by the only Sybil resistant consensus mechanism, the results of which are permanently recorded on the blockchain. Repeatedly claiming the opposite is simply being disingenuous. Please refrain from exacerbating the hostility and toxicity that?s been created in the space. From: Samuel Reed via Bitcoin-segwit2x Sent: 24 October 2017 15:27 To: bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split BEL has the right idea. It is irresponsible to pretend you have the consensus necessary to do a smooth upgrade without replay protection, when you do not. Continuing on this path is hostile to Bitcoin and its users. Of course upgrades with consensus do not require replay protection, as the original chain is meant to die. It is very obvious now that the 1x chain will not die and any assertion otherwise is intentional ignorance. There are only two responsible options for the 2x team now that the mindshare has been lost: 1. Launch 2x with replay protection, creating another altcoin; this will give miners another SHA256 coin to mine when it is profitable to do so, but will not provide much real value to the community and will even compete against BCH, or 2. Don't launch 2x at all, and attempt to create consensus another day. A responsible team should not consider a third option, where 2x is launched without protection, causing potentially millions of coins to leak and untold accounting nightmares for every user and exchange. -- Samuel Reed CTO, BitMEX bitcoin-segwit2x-request at lists.linuxfoundation.org wrote: > Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay > guarantee) - Ensuring a smooth 2X upgrade without a chain split _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C241581e8a6a14c53413308d51aeb57c9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636444520439849694&sdata=1ZrRVa76hgQrEBFZLqyLeTO5487WSiHFnqEvWbVHBc0%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam at bitmex.com Tue Oct 24 14:51:28 2017 From: sam at bitmex.com (Samuel Reed) Date: Tue, 24 Oct 2017 09:51:28 -0500 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: , <59EF4DBE.3040006@bitmex.com> Message-ID: <59EF5370.9090205@bitmex.com> You may have mining consensus, although you know how fickle that is by practice. It is dwindling now and is likely to break below 80%. You do not have user consensus. We have only the safety of our users in mind and I strongly encourage you to consider the many ways in which this split could end in disaster. Phillip Katete wrote: > > Samuel you are barking up the wrong tree here (as has been said a > multitude of times). RP that encourages a network split would render > the NYA voidable. I am sure that is what you want, but clearly that is > not going to happen. > > > > The SegWit2x upgrade has overwhelming consensus as measured by the > only Sybil resistant consensus mechanism, the results of which are > permanently recorded on the blockchain. Repeatedly claiming the > opposite is simply being disingenuous. Please refrain from > exacerbating the hostility and toxicity that?s been created in the space. > > > > *From: *Samuel Reed via Bitcoin-segwit2x > > *Sent: *24 October 2017 15:27 > *To: *bitcoin-segwit2x at lists.linuxfoundation.org > > *Subject: *Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, > guarantee) - Ensuring a smooth 2X upgrade without a chain split > > > > BEL has the right idea. It is irresponsible to pretend you have the > consensus necessary to do a smooth upgrade without replay protection, > when you do not. Continuing on this path is hostile to Bitcoin and its > users. > > Of course upgrades with consensus do not require replay protection, as > the original chain is meant to die. It is very obvious now that the 1x > chain will not die and any assertion otherwise is intentional ignorance. > > There are only two responsible options for the 2x team now that the > mindshare has been lost: > > 1. Launch 2x with replay protection, creating another altcoin; this will > give miners another SHA256 coin to mine when it is profitable to do so, > but will not provide much real value to the community and will even > compete against BCH, or > 2. Don't launch 2x at all, and attempt to create consensus another day. > > A responsible team should not consider a third option, where 2x is > launched without protection, causing potentially millions of coins to > leak and untold accounting nightmares for every user and exchange. > > -- > Samuel Reed > CTO, > BitMEX > > bitcoin-segwit2x-request at lists.linuxfoundation.org wrote: > > Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay > > guarantee) - Ensuring a smooth 2X upgrade without a chain split > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C241581e8a6a14c53413308d51aeb57c9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636444520439849694&sdata=1ZrRVa76hgQrEBFZLqyLeTO5487WSiHFnqEvWbVHBc0%3D&reserved=0 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Tue Oct 24 14:58:57 2017 From: chris at suredbits.com (Chris Stewart) Date: Tue, 24 Oct 2017 09:58:57 -0500 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: <59EF5370.9090205@bitmex.com> References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> Message-ID: >RP that encourages a network split would render the NYA voidable Phillip, if there is consensus on one thing, it is there is going to be a network split. Every exchange is publishing policies for the chain split. Some even saying that they will not support the segwit2x token. -Chris On Tue, Oct 24, 2017 at 9:51 AM, Samuel Reed via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > You may have mining consensus, although you know how fickle that is by > practice. It is dwindling now and is likely to break below 80%. You do not > have user consensus. We have only the safety of our users in mind and I > strongly encourage you to consider the many ways in which this split could > end in disaster. > > > Phillip Katete wrote: > > Samuel you are barking up the wrong tree here (as has been said a > multitude of times). RP that encourages a network split would render the > NYA voidable. I am sure that is what you want, but clearly that is not > going to happen. > > > > The SegWit2x upgrade has overwhelming consensus as measured by the only > Sybil resistant consensus mechanism, the results of which are permanently > recorded on the blockchain. Repeatedly claiming the opposite is simply > being disingenuous. Please refrain from exacerbating the hostility and > toxicity that?s been created in the space. > > > > *From: *Samuel Reed via Bitcoin-segwit2x > > *Sent: *24 October 2017 15:27 > *To: *bitcoin-segwit2x at lists.linuxfoundation.org > *Subject: *Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, > guarantee) - Ensuring a smooth 2X upgrade without a chain split > > > > BEL has the right idea. It is irresponsible to pretend you have the > consensus necessary to do a smooth upgrade without replay protection, > when you do not. Continuing on this path is hostile to Bitcoin and its > users. > > Of course upgrades with consensus do not require replay protection, as > the original chain is meant to die. It is very obvious now that the 1x > chain will not die and any assertion otherwise is intentional ignorance. > > There are only two responsible options for the 2x team now that the > mindshare has been lost: > > 1. Launch 2x with replay protection, creating another altcoin; this will > give miners another SHA256 coin to mine when it is profitable to do so, > but will not provide much real value to the community and will even > compete against BCH, or > 2. Don't launch 2x at all, and attempt to create consensus another day. > > A responsible team should not consider a third option, where 2x is > launched without protection, causing potentially millions of coins to > leak and untold accounting nightmares for every user and exchange. > > -- > Samuel Reed > CTO, > BitMEX > > bitcoin-segwit2x-request at lists.linuxfoundation.org wrote: > > Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay > > guarantee) - Ensuring a smooth 2X upgrade without a chain split > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists. > linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x& > data=02%7C01%7Cpekatete%40hotmail.com%7C241581e8a6a14c53413308d51aeb57c9% > 7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636444520439849694&sdata= > 1ZrRVa76hgQrEBFZLqyLeTO5487WSiHFnqEvWbVHBc0%3D&reserved=0 > > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dizzle at pointbiz.com Tue Oct 24 15:28:02 2017 From: dizzle at pointbiz.com (Peter) Date: Tue, 24 Oct 2017 11:28:02 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> Message-ID: On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >RP that encourages a network split would render the NYA voidable Phillip, if there is consensus on one thing, it is there is going to be a network split. Every exchange is publishing policies for the chain split. Some even saying that they will not support the segwit2x token. -Chris The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing any exchange (or custodian) said mattered. Indeed because significant sha256 hashpower was deployed towards the fork it gained value and customers of exchanges pressured the exchanges into the financially sensible decision. This proposal, SegWit2x, is for the miners to decide. Transaction selection is not a consensus rule. Any miners that want to go against the Nakamoto signaling is free to do so and the responsible party (not the 2x devs who have no control over transaction selection). If because of the political climate some miner sees an economic opportunity to resurrect the legacy chain then they can modify their node (without consensus change) to listen to 2x blocks and not mine any transaction IDs found in the 2x chain. Additionally, to complete a safe chain resurrection such a miner can airdrop the mining reward from the forked block (after 100 depth) and send it to to all addresses with UTXOs over $x value. So that users of the 1x chain can spend the combined UTXOs which cannot be replayed on 2x, as a simple splitting solution. Safety efforts which do not require consensus changes should be exhausted first before suggesting consensus changes. Regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Tue Oct 24 15:28:28 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Tue, 24 Oct 2017 15:28:28 +0000 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com>, Message-ID: Chris ? on that specific issue my point is that it does not matter what the consensus is on whether there?s going to be a network split (we?ll ignore the degrees of splits here), what matters is that coding and implementing RP that encourages the speculated split is contra to the NYA WG ToR and would certainly render the agreement voidable. No amount of ?pressure? can yield the outcome that a small section of the community craves (in my understanding), aka the implementation of RP that encourages a split. But like I mentioned earlier, the chain split is an expected outcome, it is another story all together when it comes to a viable legacy chain san HF post Nov HF. From: Chris Stewart via Bitcoin-segwit2x Sent: 24 October 2017 16:00 To: Samuel Reed Cc: bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split >RP that encourages a network split would render the NYA voidable Phillip, if there is consensus on one thing, it is there is going to be a network split. Every exchange is publishing policies for the chain split. Some even saying that they will not support the segwit2x token. -Chris On Tue, Oct 24, 2017 at 9:51 AM, Samuel Reed via Bitcoin-segwit2x > wrote: You may have mining consensus, although you know how fickle that is by practice. It is dwindling now and is likely to break below 80%. You do not have user consensus. We have only the safety of our users in mind and I strongly encourage you to consider the many ways in which this split could end in disaster. Phillip Katete wrote: Samuel you are barking up the wrong tree here (as has been said a multitude of times). RP that encourages a network split would render the NYA voidable. I am sure that is what you want, but clearly that is not going to happen. The SegWit2x upgrade has overwhelming consensus as measured by the only Sybil resistant consensus mechanism, the results of which are permanently recorded on the blockchain. Repeatedly claiming the opposite is simply being disingenuous. Please refrain from exacerbating the hostility and toxicity that?s been created in the space. From: Samuel Reed via Bitcoin-segwit2x Sent: 24 October 2017 15:27 To: bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split BEL has the right idea. It is irresponsible to pretend you have the consensus necessary to do a smooth upgrade without replay protection, when you do not. Continuing on this path is hostile to Bitcoin and its users. Of course upgrades with consensus do not require replay protection, as the original chain is meant to die. It is very obvious now that the 1x chain will not die and any assertion otherwise is intentional ignorance. There are only two responsible options for the 2x team now that the mindshare has been lost: 1. Launch 2x with replay protection, creating another altcoin; this will give miners another SHA256 coin to mine when it is profitable to do so, but will not provide much real value to the community and will even compete against BCH, or 2. Don't launch 2x at all, and attempt to create consensus another day. A responsible team should not consider a third option, where 2x is launched without protection, causing potentially millions of coins to leak and untold accounting nightmares for every user and exchange. -- Samuel Reed CTO, BitMEX bitcoin-segwit2x-request at lists.linuxfoundation.org wrote: > Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay > guarantee) - Ensuring a smooth 2X upgrade without a chain split _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-segwit2x&data=02%7C01%7Cpekatete%40hotmail.com%7C241581e8a6a14c53413308d51aeb57c9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636444520439849694&sdata=1ZrRVa76hgQrEBFZLqyLeTO5487WSiHFnqEvWbVHBc0%3D&reserved=0 _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam at bitmex.com Tue Oct 24 15:31:43 2017 From: sam at bitmex.com (Samuel Reed) Date: Tue, 24 Oct 2017 10:31:43 -0500 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> Message-ID: <59EF5CDF.3020006@bitmex.com> Another lesson to be learned from BCH is that incentives matter - where miners can sell coins depends on markets, and market prices depend on user and exchange support. Even if the 80% of miners signaling 2x at this time choose to go forward, if there are not viable markets willing to buy 2x coins at near 1x prices, 2x hash power will quickly revert to the old chain. Peter wrote: > > > On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" > > wrote: > > >RP that encourages a network split would render the NYA voidable > > Phillip, if there is consensus on one thing, it is there is going > to be a network split. Every exchange is publishing policies for > the chain split. Some even saying that they will not support the > segwit2x token. > > -Chris > > > The technical lesson from the BCH fork was that 1 hash = 1 vote. > Nothing any exchange (or custodian) said mattered. Indeed because > significant sha256 hashpower was deployed towards the fork it gained > value and customers of exchanges pressured the exchanges into the > financially sensible decision. > > This proposal, SegWit2x, is for the miners to decide. > > Transaction selection is not a consensus rule. Any miners that want to > go against the Nakamoto signaling is free to do so and the responsible > party (not the 2x devs who have no control over transaction > selection). If because of the political climate some miner sees an > economic opportunity to resurrect the legacy chain then they can > modify their node (without consensus change) to listen to 2x blocks > and not mine any transaction IDs found in the 2x chain. > > Additionally, to complete a safe chain resurrection such a miner can > airdrop the mining reward from the forked block (after 100 depth) and > send it to to all addresses with UTXOs over $x value. So that users of > the 1x chain can spend the combined UTXOs which cannot be replayed on > 2x, as a simple splitting solution. > > Safety efforts which do not require consensus changes should be > exhausted first before suggesting consensus changes. > > Regards > Peter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Tue Oct 24 15:36:54 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Tue, 24 Oct 2017 15:36:54 +0000 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: <59EF5CDF.3020006@bitmex.com> References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> , <59EF5CDF.3020006@bitmex.com> Message-ID: It is at this point that common sense needs to be applied. Even the most ardent anti SegWit2x upgrade individual would snap up the ?airdrop? should there be 2 viable chains post Nov HF. That in itself is demand enough to have a market for both tokens. The flip side is that with an unusable chain, it matters not whether exchanges respond to user requests for listing as you won?t be able to move your tokens anyway. From: Samuel Reed via Bitcoin-segwit2x Sent: 24 October 2017 16:31 To: Peter Cc: Bitcoin Segwit2x Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split Another lesson to be learned from BCH is that incentives matter - where miners can sell coins depends on markets, and market prices depend on user and exchange support. Even if the 80% of miners signaling 2x at this time choose to go forward, if there are not viable markets willing to buy 2x coins at near 1x prices, 2x hash power will quickly revert to the old chain. Peter wrote: On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" > wrote: >RP that encourages a network split would render the NYA voidable Phillip, if there is consensus on one thing, it is there is going to be a network split. Every exchange is publishing policies for the chain split. Some even saying that they will not support the segwit2x token. -Chris The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing any exchange (or custodian) said mattered. Indeed because significant sha256 hashpower was deployed towards the fork it gained value and customers of exchanges pressured the exchanges into the financially sensible decision. This proposal, SegWit2x, is for the miners to decide. Transaction selection is not a consensus rule. Any miners that want to go against the Nakamoto signaling is free to do so and the responsible party (not the 2x devs who have no control over transaction selection). If because of the political climate some miner sees an economic opportunity to resurrect the legacy chain then they can modify their node (without consensus change) to listen to 2x blocks and not mine any transaction IDs found in the 2x chain. Additionally, to complete a safe chain resurrection such a miner can airdrop the mining reward from the forked block (after 100 depth) and send it to to all addresses with UTXOs over $x value. So that users of the 1x chain can spend the combined UTXOs which cannot be replayed on 2x, as a simple splitting solution. Safety efforts which do not require consensus changes should be exhausted first before suggesting consensus changes. Regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From moe at bitaccess.co Tue Oct 24 15:47:12 2017 From: moe at bitaccess.co (Moe Adham) Date: Tue, 24 Oct 2017 11:47:12 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: Miners need to move their funds into exchanges to sell them. If they can't deposit coins to an exchange, they become valueless. Assuming an 80-20 split, Block times for the minority chain spike to ~49.3 minutes and will remain that long for ~69 days. This would effectively block the minority chain's functionality as a payment system, as it will become increasingly impossible to deposit funds, or move them between exchanges (assuming transaction demand remains linear). Miners can prioritize their own transactions in blocks, but regular customers will be left out to dry. I don't anyone should under-estimate the negative effects of this on market participants. A lot of us have customers who expect bitcoin to just "work". If we start telling them they can't spend their money for several days/weeks, the choice of which chain is viable will quickly become clear. It will be neither Bitcoin1x or Bitcoin2x. It will be a different blockchain altogether. (To be clear, Bitaccess is neutral on this fork, we just want customers to remain happy. They way this is going, that doesn't seem to be a likely outcome) -- *Moe Adham, MSc, BEng **|* Co-Founder *bitaccess.co * Cell: *+1 858 877 3420* On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > It is at this point that common sense needs to be applied. Even the most > ardent anti SegWit2x upgrade individual would snap up the ?airdrop? should > there be 2 viable chains post Nov HF. That in itself is demand enough to > have a market for both tokens. The flip side is that with an unusable > chain, it matters not whether exchanges respond to user requests for > listing as you won?t be able to move your tokens anyway. > > > > *From: *Samuel Reed via Bitcoin-segwit2x > > *Sent: *24 October 2017 16:31 > *To: *Peter > *Cc: *Bitcoin Segwit2x > *Subject: *Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, > guarantee) - Ensuring a smooth 2X upgrade without a chain split > > > > Another lesson to be learned from BCH is that incentives matter - where > miners can sell coins depends on markets, and market prices depend on user > and exchange support. Even if the 80% of miners signaling 2x at this time > choose to go forward, if there are not viable markets willing to buy 2x > coins at near 1x prices, 2x hash power will quickly revert to the old chain. > > Peter wrote: > > > > > > On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > >RP that encourages a network split would render the NYA voidable > > Phillip, if there is consensus on one thing, it is there is going to be a > network split. Every exchange is publishing policies for the chain split. > Some even saying that they will not support the segwit2x token. > > -Chris > > > > The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing > any exchange (or custodian) said mattered. Indeed because significant > sha256 hashpower was deployed towards the fork it gained value and > customers of exchanges pressured the exchanges into the financially > sensible decision. > > > > This proposal, SegWit2x, is for the miners to decide. > > > > Transaction selection is not a consensus rule. Any miners that want to go > against the Nakamoto signaling is free to do so and the responsible party > (not the 2x devs who have no control over transaction selection). If > because of the political climate some miner sees an economic opportunity to > resurrect the legacy chain then they can modify their node (without > consensus change) to listen to 2x blocks and not mine any transaction IDs > found in the 2x chain. > > > > Additionally, to complete a safe chain resurrection such a miner can > airdrop the mining reward from the forked block (after 100 depth) and send > it to to all addresses with UTXOs over $x value. So that users of the 1x > chain can spend the combined UTXOs which cannot be replayed on 2x, as a > simple splitting solution. > > > > Safety efforts which do not require consensus changes should be exhausted > first before suggesting consensus changes. > > > > Regards > > Peter > > > > > > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Tue Oct 24 15:57:53 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Tue, 24 Oct 2017 17:57:53 +0200 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Miners need to move their funds into exchanges to sell them. If they can't > deposit coins to an exchange, they become valueless. > > Assuming an 80-20 split, Block times for the minority chain spike to ~49.3 > minutes and will remain that long for ~69 days. This would effectively > block the minority chain's functionality as a payment system, as it will > become increasingly impossible to deposit funds, or move them between > exchanges (assuming transaction demand remains linear). Miners can > prioritize their own transactions in blocks, but regular customers will be > left out to dry. > > I don't anyone should under-estimate the negative effects of this on > market participants. > > A lot of us have customers who expect bitcoin to just "work". If we start > telling them they can't spend their money for several days/weeks, the > choice of which chain is viable will quickly become clear. It will be > neither Bitcoin1x or Bitcoin2x. It will be a different blockchain > altogether. > > (To be clear, Bitaccess is neutral on this fork, we just want customers to > remain happy. They way this is going, that doesn't seem to be a likely > outcome) > What typically happens is (shock horror) miners will mine in self interest. If you consider mining as a commodity, it makes sense that they'll just go for the most profitable coin, and not act altruistically, which was suggested in the original white paper. Mining is therefore common is a 0% / 100% until fees for a block make it profitable to mine that block (cab take several days) or the difficulty adjusts the profitability. This phenomenon is often referred to as "feast and famine". Given the market is showing that the 2x coin will be valued under 20% of bitcoin, miners acting in self interest will mine bitcoin and the 2x chain will freeze up, requiring subsidy to mine. Such subsidies could be added by creating a few transactions with high mining fees. > > > -- > *Moe Adham, MSc, BEng **|* Co-Founder > > *bitaccess.co * > Cell: *+1 858 877 3420 <(858)%20877-3420>* > > On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> It is at this point that common sense needs to be applied. Even the most >> ardent anti SegWit2x upgrade individual would snap up the ?airdrop? should >> there be 2 viable chains post Nov HF. That in itself is demand enough to >> have a market for both tokens. The flip side is that with an unusable >> chain, it matters not whether exchanges respond to user requests for >> listing as you won?t be able to move your tokens anyway. >> >> >> >> *From: *Samuel Reed via Bitcoin-segwit2x >> >> *Sent: *24 October 2017 16:31 >> *To: *Peter >> *Cc: *Bitcoin Segwit2x >> *Subject: *Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >> guarantee) - Ensuring a smooth 2X upgrade without a chain split >> >> >> >> Another lesson to be learned from BCH is that incentives matter - where >> miners can sell coins depends on markets, and market prices depend on user >> and exchange support. Even if the 80% of miners signaling 2x at this time >> choose to go forward, if there are not viable markets willing to buy 2x >> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >> >> Peter wrote: >> >> >> >> >> >> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> >RP that encourages a network split would render the NYA voidable >> >> Phillip, if there is consensus on one thing, it is there is going to be a >> network split. Every exchange is publishing policies for the chain split. >> Some even saying that they will not support the segwit2x token. >> >> -Chris >> >> >> >> The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing >> any exchange (or custodian) said mattered. Indeed because significant >> sha256 hashpower was deployed towards the fork it gained value and >> customers of exchanges pressured the exchanges into the financially >> sensible decision. >> >> >> >> This proposal, SegWit2x, is for the miners to decide. >> >> >> >> Transaction selection is not a consensus rule. Any miners that want to go >> against the Nakamoto signaling is free to do so and the responsible party >> (not the 2x devs who have no control over transaction selection). If >> because of the political climate some miner sees an economic opportunity to >> resurrect the legacy chain then they can modify their node (without >> consensus change) to listen to 2x blocks and not mine any transaction IDs >> found in the 2x chain. >> >> >> >> Additionally, to complete a safe chain resurrection such a miner can >> airdrop the mining reward from the forked block (after 100 depth) and send >> it to to all addresses with UTXOs over $x value. So that users of the 1x >> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >> simple splitting solution. >> >> >> >> Safety efforts which do not require consensus changes should be exhausted >> first before suggesting consensus changes. >> >> >> >> Regards >> >> Peter >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at shapeshift.io Tue Oct 24 16:27:37 2017 From: erik at shapeshift.io (Erik Voorhees) Date: Tue, 24 Oct 2017 09:27:37 -0700 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: I have a question for the group... "Given the market is showing that the 2x coin will be valued under 20% of bitcoin, miners acting in self interest will mine bitcoin and the 2x chain will freeze up, requiring subsidy to mine.? - Mo Adham -Let?s assume, immediately following the fork, 1x has 20% of hash power, and 2x has 80% (as indicated by miner signaling) -Let?s assume also that the price, immediately following the fork, 1x is $4,000 and 2x is $1,000 (as indicated by futures) Most people see the above and think, ?okay, soon after the fork the miners will switch back to 1x because price is higher.? But, is it not the case that while price might be higher, block times are lower. So if you consider it from a $ revenue per day: - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m per day ($4,000 x 360) - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or $1.44m per day ($1,000 x 1,440) In the above case, the revenue stream of both coins is equal, at $1.44m per day. So even though one coin is priced higher, it doesn?t mean miners will necessarily choose that chain to mine. Am I missing something? Kind regards, -Erik Voorhees CEO ShapeShift AG On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( bitcoin-segwit2x at lists.linuxfoundation.org) wrote: On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Miners need to move their funds into exchanges to sell them. If they can't > deposit coins to an exchange, they become valueless. > > Assuming an 80-20 split, Block times for the minority chain spike to ~49.3 > minutes and will remain that long for ~69 days. This would effectively > block the minority chain's functionality as a payment system, as it will > become increasingly impossible to deposit funds, or move them between > exchanges (assuming transaction demand remains linear). Miners can > prioritize their own transactions in blocks, but regular customers will be > left out to dry. > > I don't anyone should under-estimate the negative effects of this on > market participants. > > A lot of us have customers who expect bitcoin to just "work". If we start > telling them they can't spend their money for several days/weeks, the > choice of which chain is viable will quickly become clear. It will be > neither Bitcoin1x or Bitcoin2x. It will be a different blockchain > altogether. > > (To be clear, Bitaccess is neutral on this fork, we just want customers to > remain happy. They way this is going, that doesn't seem to be a likely > outcome) > What typically happens is (shock horror) miners will mine in self interest. If you consider mining as a commodity, it makes sense that they'll just go for the most profitable coin, and not act altruistically, which was suggested in the original white paper. Mining is therefore common is a 0% / 100% until fees for a block make it profitable to mine that block (cab take several days) or the difficulty adjusts the profitability. This phenomenon is often referred to as "feast and famine". Given the market is showing that the 2x coin will be valued under 20% of bitcoin, miners acting in self interest will mine bitcoin and the 2x chain will freeze up, requiring subsidy to mine. Such subsidies could be added by creating a few transactions with high mining fees. > > > -- > *Moe Adham, MSc, BEng **|* Co-Founder > > *bitaccess.co * > Cell: *+1 858 877 3420 <(858)%20877-3420>* > > On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> It is at this point that common sense needs to be applied. Even the most >> ardent anti SegWit2x upgrade individual would snap up the ?airdrop? should >> there be 2 viable chains post Nov HF. That in itself is demand enough to >> have a market for both tokens. The flip side is that with an unusable >> chain, it matters not whether exchanges respond to user requests for >> listing as you won?t be able to move your tokens anyway. >> >> >> >> *From:* Samuel Reed via Bitcoin-segwit2x >> >> *Sent:* 24 October 2017 16:31 >> *To:* Peter >> *Cc:* Bitcoin Segwit2x >> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >> guarantee) - Ensuring a smooth 2X upgrade without a chain split >> >> >> >> Another lesson to be learned from BCH is that incentives matter - where >> miners can sell coins depends on markets, and market prices depend on user >> and exchange support. Even if the 80% of miners signaling 2x at this time >> choose to go forward, if there are not viable markets willing to buy 2x >> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >> >> Peter wrote: >> >> >> >> >> >> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> >RP that encourages a network split would render the NYA voidable >> >> Phillip, if there is consensus on one thing, it is there is going to be a >> network split. Every exchange is publishing policies for the chain split. >> Some even saying that they will not support the segwit2x token. >> >> -Chris >> >> >> >> The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing >> any exchange (or custodian) said mattered. Indeed because significant >> sha256 hashpower was deployed towards the fork it gained value and >> customers of exchanges pressured the exchanges into the financially >> sensible decision. >> >> >> >> This proposal, SegWit2x, is for the miners to decide. >> >> >> >> Transaction selection is not a consensus rule. Any miners that want to go >> against the Nakamoto signaling is free to do so and the responsible party >> (not the 2x devs who have no control over transaction selection). If >> because of the political climate some miner sees an economic opportunity to >> resurrect the legacy chain then they can modify their node (without >> consensus change) to listen to 2x blocks and not mine any transaction IDs >> found in the 2x chain. >> >> >> >> Additionally, to complete a safe chain resurrection such a miner can >> airdrop the mining reward from the forked block (after 100 depth) and send >> it to to all addresses with UTXOs over $x value. So that users of the 1x >> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >> simple splitting solution. >> >> >> >> Safety efforts which do not require consensus changes should be exhausted >> first before suggesting consensus changes. >> >> >> >> Regards >> >> Peter >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at blockstream.com Tue Oct 24 16:38:37 2017 From: adam at blockstream.com (Dr Adam Back) Date: Tue, 24 Oct 2017 18:38:37 +0200 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: Well difficulty during an adjustment period is independent of hashrate, so as many or as few miners can mine at the profit determined by difficulty and price. That's why some miners mine BCH when the difficulty is low due to the EDA bug. What happens is blocks get faster, hastening the adjustment period end but the faster blocks don't affect profitability. I think people are also not understanding fees. Fees on Bitcoin are often 1.5BTC/block, if there are priority exchange transactions people will have no qualms paying $10, as they are also paying 0.2% or more trade commission and $40 wire fees. (On either chain). Consequently a chain can pay for processing even with 0 reward. Adam On Oct 24, 2017 17:27, "Erik Voorhees via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > I have a question for the group... > > > "Given the market is showing that the 2x coin will be valued under 20% of > bitcoin, miners acting in self interest will mine bitcoin and the 2x chain > will freeze up, requiring subsidy to mine.? - Mo Adham > > -Let?s assume, immediately following the fork, 1x has 20% of hash power, > and 2x has 80% (as indicated by miner signaling) > -Let?s assume also that the price, immediately following the fork, 1x is > $4,000 and 2x is $1,000 (as indicated by futures) > > Most people see the above and think, ?okay, soon after the fork the miners > will switch back to 1x because price is higher.? > > But, is it not the case that while price might be higher, block times are > lower. So if you consider it from a $ revenue per day: > - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m > per day ($4,000 x 360) > - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or $1.44m > per day ($1,000 x 1,440) > > In the above case, the revenue stream of both coins is equal, at $1.44m > per day. So even though one coin is priced higher, it doesn?t mean miners > will necessarily choose that chain to mine. > > Am I missing something? > > > Kind regards, > -Erik Voorhees > CEO ShapeShift AG > > On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( > bitcoin-segwit2x at lists.linuxfoundation.org) wrote: > > > > On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Miners need to move their funds into exchanges to sell them. If they >> can't deposit coins to an exchange, they become valueless. >> >> Assuming an 80-20 split, Block times for the minority chain spike to >> ~49.3 minutes and will remain that long for ~69 days. This would >> effectively block the minority chain's functionality as a payment system, >> as it will become increasingly impossible to deposit funds, or move them >> between exchanges (assuming transaction demand remains linear). Miners can >> prioritize their own transactions in blocks, but regular customers will be >> left out to dry. >> >> I don't anyone should under-estimate the negative effects of this on >> market participants. >> >> A lot of us have customers who expect bitcoin to just "work". If we start >> telling them they can't spend their money for several days/weeks, the >> choice of which chain is viable will quickly become clear. It will be >> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >> altogether. >> >> (To be clear, Bitaccess is neutral on this fork, we just want customers >> to remain happy. They way this is going, that doesn't seem to be a likely >> outcome) >> > > What typically happens is (shock horror) miners will mine in self > interest. If you consider mining as a commodity, it makes sense that > they'll just go for the most profitable coin, and not act altruistically, > which was suggested in the original white paper. > > Mining is therefore common is a 0% / 100% until fees for a block make it > profitable to mine that block (cab take several days) or the difficulty > adjusts the profitability. > > This phenomenon is often referred to as "feast and famine". > > Given the market is showing that the 2x coin will be valued under 20% of > bitcoin, miners acting in self interest will mine bitcoin and the 2x chain > will freeze up, requiring subsidy to mine. Such subsidies could be added > by creating a few transactions with high mining fees. > >> >> >> -- >> *Moe Adham, MSc, BEng **|* Co-Founder >> >> *bitaccess.co * >> Cell: *+1 858 877 3420 <(858)%20877-3420>* >> >> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> It is at this point that common sense needs to be applied. Even the most >>> ardent anti SegWit2x upgrade individual would snap up the ?airdrop? should >>> there be 2 viable chains post Nov HF. That in itself is demand enough to >>> have a market for both tokens. The flip side is that with an unusable >>> chain, it matters not whether exchanges respond to user requests for >>> listing as you won?t be able to move your tokens anyway. >>> >>> >>> >>> *From:* Samuel Reed via Bitcoin-segwit2x >>> >>> *Sent:* 24 October 2017 16:31 >>> *To:* Peter >>> *Cc:* Bitcoin Segwit2x >>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >>> guarantee) - Ensuring a smooth 2X upgrade without a chain split >>> >>> >>> >>> Another lesson to be learned from BCH is that incentives matter - where >>> miners can sell coins depends on markets, and market prices depend on user >>> and exchange support. Even if the 80% of miners signaling 2x at this time >>> choose to go forward, if there are not viable markets willing to buy 2x >>> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >>> >>> Peter wrote: >>> >>> >>> >>> >>> >>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>> >RP that encourages a network split would render the NYA voidable >>> >>> Phillip, if there is consensus on one thing, it is there is going to be >>> a network split. Every exchange is publishing policies for the chain split. >>> Some even saying that they will not support the segwit2x token. >>> >>> -Chris >>> >>> >>> >>> The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing >>> any exchange (or custodian) said mattered. Indeed because significant >>> sha256 hashpower was deployed towards the fork it gained value and >>> customers of exchanges pressured the exchanges into the financially >>> sensible decision. >>> >>> >>> >>> This proposal, SegWit2x, is for the miners to decide. >>> >>> >>> >>> Transaction selection is not a consensus rule. Any miners that want to >>> go against the Nakamoto signaling is free to do so and the responsible >>> party (not the 2x devs who have no control over transaction selection). If >>> because of the political climate some miner sees an economic opportunity to >>> resurrect the legacy chain then they can modify their node (without >>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>> found in the 2x chain. >>> >>> >>> >>> Additionally, to complete a safe chain resurrection such a miner can >>> airdrop the mining reward from the forked block (after 100 depth) and send >>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>> simple splitting solution. >>> >>> >>> >>> Safety efforts which do not require consensus changes should be >>> exhausted first before suggesting consensus changes. >>> >>> >>> >>> Regards >>> >>> Peter >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitcoinerrorlog at gmail.com Tue Oct 24 16:38:30 2017 From: bitcoinerrorlog at gmail.com (Bitcoin Error Log) Date: Tue, 24 Oct 2017 16:38:30 +0000 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: What you are missing is that YOU are now heavily speculating, Erik. It doesn't matter if miners express indecision. There will be two chains, and you are nuts if you think some volatility in hashrate allows for a definitive diagnosis that RP is not needed. Miners will mine what pays best. Ask yourself, who will be paying for S2X coins? You may have gotten miners to agree, and some businesses to support your fork, but NO ONE WANTS TO BUY B2X. The demand isn't there, and if we're realistic, our example scenario would be whether the S2X chain is sustainable, not the reverse. On Tue, Oct 24, 2017 at 12:27 PM Erik Voorhees via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > I have a question for the group... > > > "Given the market is showing that the 2x coin will be valued under 20% of > bitcoin, miners acting in self interest will mine bitcoin and the 2x chain > will freeze up, requiring subsidy to mine.? - Mo Adham > > -Let?s assume, immediately following the fork, 1x has 20% of hash power, > and 2x has 80% (as indicated by miner signaling) > -Let?s assume also that the price, immediately following the fork, 1x is > $4,000 and 2x is $1,000 (as indicated by futures) > > Most people see the above and think, ?okay, soon after the fork the miners > will switch back to 1x because price is higher.? > > But, is it not the case that while price might be higher, block times are > lower. So if you consider it from a $ revenue per day: > - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m > per day ($4,000 x 360) > - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or $1.44m > per day ($1,000 x 1,440) > > In the above case, the revenue stream of both coins is equal, at $1.44m > per day. So even though one coin is priced higher, it doesn?t mean miners > will necessarily choose that chain to mine. > > Am I missing something? > > > Kind regards, > -Erik Voorhees > CEO ShapeShift AG > > On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( > bitcoin-segwit2x at lists.linuxfoundation.org) wrote: > > > > On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Miners need to move their funds into exchanges to sell them. If they >> can't deposit coins to an exchange, they become valueless. >> >> Assuming an 80-20 split, Block times for the minority chain spike to >> ~49.3 minutes and will remain that long for ~69 days. This would >> effectively block the minority chain's functionality as a payment system, >> as it will become increasingly impossible to deposit funds, or move them >> between exchanges (assuming transaction demand remains linear). Miners can >> prioritize their own transactions in blocks, but regular customers will be >> left out to dry. >> >> I don't anyone should under-estimate the negative effects of this on >> market participants. >> >> A lot of us have customers who expect bitcoin to just "work". If we start >> telling them they can't spend their money for several days/weeks, the >> choice of which chain is viable will quickly become clear. It will be >> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >> altogether. >> >> (To be clear, Bitaccess is neutral on this fork, we just want customers >> to remain happy. They way this is going, that doesn't seem to be a likely >> outcome) >> > > What typically happens is (shock horror) miners will mine in self > interest. If you consider mining as a commodity, it makes sense that > they'll just go for the most profitable coin, and not act altruistically, > which was suggested in the original white paper. > > Mining is therefore common is a 0% / 100% until fees for a block make it > profitable to mine that block (cab take several days) or the difficulty > adjusts the profitability. > > This phenomenon is often referred to as "feast and famine". > > Given the market is showing that the 2x coin will be valued under 20% of > bitcoin, miners acting in self interest will mine bitcoin and the 2x chain > will freeze up, requiring subsidy to mine. Such subsidies could be added > by creating a few transactions with high mining fees. > >> >> >> -- >> *Moe Adham, MSc, BEng **|* Co-Founder >> >> *bitaccess.co * >> Cell: *+1 858 877 3420 <(858)%20877-3420>* >> >> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> It is at this point that common sense needs to be applied. Even the most >>> ardent anti SegWit2x upgrade individual would snap up the ?airdrop? should >>> there be 2 viable chains post Nov HF. That in itself is demand enough to >>> have a market for both tokens. The flip side is that with an unusable >>> chain, it matters not whether exchanges respond to user requests for >>> listing as you won?t be able to move your tokens anyway. >>> >>> >>> >>> *From:* Samuel Reed via Bitcoin-segwit2x >>> >>> *Sent:* 24 October 2017 16:31 >>> *To:* Peter >>> *Cc:* Bitcoin Segwit2x >>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >>> guarantee) - Ensuring a smooth 2X upgrade without a chain split >>> >>> >>> >>> Another lesson to be learned from BCH is that incentives matter - where >>> miners can sell coins depends on markets, and market prices depend on user >>> and exchange support. Even if the 80% of miners signaling 2x at this time >>> choose to go forward, if there are not viable markets willing to buy 2x >>> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >>> >>> Peter wrote: >>> >>> >>> >>> >>> >>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>> >RP that encourages a network split would render the NYA voidable >>> >>> Phillip, if there is consensus on one thing, it is there is going to be >>> a network split. Every exchange is publishing policies for the chain split. >>> Some even saying that they will not support the segwit2x token. >>> >>> -Chris >>> >>> >>> >>> The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing >>> any exchange (or custodian) said mattered. Indeed because significant >>> sha256 hashpower was deployed towards the fork it gained value and >>> customers of exchanges pressured the exchanges into the financially >>> sensible decision. >>> >>> >>> >>> This proposal, SegWit2x, is for the miners to decide. >>> >>> >>> >>> Transaction selection is not a consensus rule. Any miners that want to >>> go against the Nakamoto signaling is free to do so and the responsible >>> party (not the 2x devs who have no control over transaction selection). If >>> because of the political climate some miner sees an economic opportunity to >>> resurrect the legacy chain then they can modify their node (without >>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>> found in the 2x chain. >>> >>> >>> >>> Additionally, to complete a safe chain resurrection such a miner can >>> airdrop the mining reward from the forked block (after 100 depth) and send >>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>> simple splitting solution. >>> >>> >>> >>> Safety efforts which do not require consensus changes should be >>> exhausted first before suggesting consensus changes. >>> >>> >>> >>> Regards >>> >>> Peter >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- John C Bitcoin Error Log www.bitcoinerrorlog.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hubert.maslin at gmail.com Tue Oct 24 16:39:50 2017 From: hubert.maslin at gmail.com (hubert maslin) Date: Tue, 24 Oct 2017 18:39:50 +0200 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: Hi Erik, You are most definitely missing something: the total revenue streams, for all miners mining a chain, can be unequal (because the amount of mining power pointing at each chain can be unequal), but the odds of for one miner to find a block are the same on both chains (because none of the chains will adjust difficulty); it's just that the revenue from mining a block on the B2X chain will likely be much lower than the revenue from a block mining on the original chain. Best regards. 2017-10-24 18:38 GMT+02:00 Dr Adam Back via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org>: > Well difficulty during an adjustment period is independent of hashrate, so > as many or as few miners can mine at the profit determined by difficulty > and price. That's why some miners mine BCH when the difficulty is low due > to the EDA bug. What happens is blocks get faster, hastening the adjustment > period end but the faster blocks don't affect profitability. > > I think people are also not understanding fees. Fees on Bitcoin are often > 1.5BTC/block, if there are priority exchange transactions people will have > no qualms paying $10, as they are also paying 0.2% or more trade > commission and $40 wire fees. (On either chain). Consequently a chain can > pay for processing even with 0 reward. > > Adam > > On Oct 24, 2017 17:27, "Erik Voorhees via Bitcoin-segwit2x" < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> I have a question for the group... >> >> >> "Given the market is showing that the 2x coin will be valued under 20% >> of bitcoin, miners acting in self interest will mine bitcoin and the 2x >> chain will freeze up, requiring subsidy to mine.? - Mo Adham >> >> -Let?s assume, immediately following the fork, 1x has 20% of hash power, >> and 2x has 80% (as indicated by miner signaling) >> -Let?s assume also that the price, immediately following the fork, 1x is >> $4,000 and 2x is $1,000 (as indicated by futures) >> >> Most people see the above and think, ?okay, soon after the fork the >> miners will switch back to 1x because price is higher.? >> >> But, is it not the case that while price might be higher, block times are >> lower. So if you consider it from a $ revenue per day: >> - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m >> per day ($4,000 x 360) >> - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or >> $1.44m per day ($1,000 x 1,440) >> >> In the above case, the revenue stream of both coins is equal, at $1.44m >> per day. So even though one coin is priced higher, it doesn?t mean miners >> will necessarily choose that chain to mine. >> >> Am I missing something? >> >> >> Kind regards, >> -Erik Voorhees >> CEO ShapeShift AG >> >> On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( >> bitcoin-segwit2x at lists.linuxfoundation.org) wrote: >> >> >> >> On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> Miners need to move their funds into exchanges to sell them. If they >>> can't deposit coins to an exchange, they become valueless. >>> >>> Assuming an 80-20 split, Block times for the minority chain spike to >>> ~49.3 minutes and will remain that long for ~69 days. This would >>> effectively block the minority chain's functionality as a payment system, >>> as it will become increasingly impossible to deposit funds, or move them >>> between exchanges (assuming transaction demand remains linear). Miners can >>> prioritize their own transactions in blocks, but regular customers will be >>> left out to dry. >>> >>> I don't anyone should under-estimate the negative effects of this on >>> market participants. >>> >>> A lot of us have customers who expect bitcoin to just "work". If we >>> start telling them they can't spend their money for several days/weeks, the >>> choice of which chain is viable will quickly become clear. It will be >>> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >>> altogether. >>> >>> (To be clear, Bitaccess is neutral on this fork, we just want customers >>> to remain happy. They way this is going, that doesn't seem to be a likely >>> outcome) >>> >> >> What typically happens is (shock horror) miners will mine in self >> interest. If you consider mining as a commodity, it makes sense that >> they'll just go for the most profitable coin, and not act altruistically, >> which was suggested in the original white paper. >> >> Mining is therefore common is a 0% / 100% until fees for a block make it >> profitable to mine that block (cab take several days) or the difficulty >> adjusts the profitability. >> >> This phenomenon is often referred to as "feast and famine". >> >> Given the market is showing that the 2x coin will be valued under 20% of >> bitcoin, miners acting in self interest will mine bitcoin and the 2x chain >> will freeze up, requiring subsidy to mine. Such subsidies could be added >> by creating a few transactions with high mining fees. >> >>> >>> >>> -- >>> *Moe Adham, MSc, BEng **|* Co-Founder >>> >>> *bitaccess.co * >>> Cell: *+1 858 877 3420 <(858)%20877-3420>* >>> >>> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> It is at this point that common sense needs to be applied. Even the >>>> most ardent anti SegWit2x upgrade individual would snap up the ?airdrop? >>>> should there be 2 viable chains post Nov HF. That in itself is demand >>>> enough to have a market for both tokens. The flip side is that with an >>>> unusable chain, it matters not whether exchanges respond to user requests >>>> for listing as you won?t be able to move your tokens anyway. >>>> >>>> >>>> >>>> *From:* Samuel Reed via Bitcoin-segwit2x >>>> >>>> *Sent:* 24 October 2017 16:31 >>>> *To:* Peter >>>> *Cc:* Bitcoin Segwit2x >>>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >>>> guarantee) - Ensuring a smooth 2X upgrade without a chain split >>>> >>>> >>>> >>>> Another lesson to be learned from BCH is that incentives matter - where >>>> miners can sell coins depends on markets, and market prices depend on user >>>> and exchange support. Even if the 80% of miners signaling 2x at this time >>>> choose to go forward, if there are not viable markets willing to buy 2x >>>> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >>>> >>>> Peter wrote: >>>> >>>> >>>> >>>> >>>> >>>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>> >RP that encourages a network split would render the NYA voidable >>>> >>>> Phillip, if there is consensus on one thing, it is there is going to be >>>> a network split. Every exchange is publishing policies for the chain split. >>>> Some even saying that they will not support the segwit2x token. >>>> >>>> -Chris >>>> >>>> >>>> >>>> The technical lesson from the BCH fork was that 1 hash = 1 vote. >>>> Nothing any exchange (or custodian) said mattered. Indeed because >>>> significant sha256 hashpower was deployed towards the fork it gained value >>>> and customers of exchanges pressured the exchanges into the financially >>>> sensible decision. >>>> >>>> >>>> >>>> This proposal, SegWit2x, is for the miners to decide. >>>> >>>> >>>> >>>> Transaction selection is not a consensus rule. Any miners that want to >>>> go against the Nakamoto signaling is free to do so and the responsible >>>> party (not the 2x devs who have no control over transaction selection). If >>>> because of the political climate some miner sees an economic opportunity to >>>> resurrect the legacy chain then they can modify their node (without >>>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>>> found in the 2x chain. >>>> >>>> >>>> >>>> Additionally, to complete a safe chain resurrection such a miner can >>>> airdrop the mining reward from the forked block (after 100 depth) and send >>>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>>> simple splitting solution. >>>> >>>> >>>> >>>> Safety efforts which do not require consensus changes should be >>>> exhausted first before suggesting consensus changes. >>>> >>>> >>>> >>>> Regards >>>> >>>> Peter >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at blockstream.com Tue Oct 24 16:42:52 2017 From: adam at blockstream.com (Dr Adam Back) Date: Tue, 24 Oct 2017 18:42:52 +0200 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: Reminds me I was going to ask, will Erik, or anyone here buy B2X coins at 3 for 2 BTC? No fork no trade. I want to sell them. Adam On Oct 24, 2017 17:38, "Bitcoin Error Log via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > What you are missing is that YOU are now heavily speculating, Erik. It > doesn't matter if miners express indecision. There will be two chains, and > you are nuts if you think some volatility in hashrate allows for a > definitive diagnosis that RP is not needed. > > Miners will mine what pays best. Ask yourself, who will be paying for S2X > coins? You may have gotten miners to agree, and some businesses to support > your fork, but NO ONE WANTS TO BUY B2X. The demand isn't there, and if > we're realistic, our example scenario would be whether the S2X chain is > sustainable, not the reverse. > > > On Tue, Oct 24, 2017 at 12:27 PM Erik Voorhees via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> I have a question for the group... >> >> >> "Given the market is showing that the 2x coin will be valued under 20% >> of bitcoin, miners acting in self interest will mine bitcoin and the 2x >> chain will freeze up, requiring subsidy to mine.? - Mo Adham >> >> -Let?s assume, immediately following the fork, 1x has 20% of hash power, >> and 2x has 80% (as indicated by miner signaling) >> -Let?s assume also that the price, immediately following the fork, 1x is >> $4,000 and 2x is $1,000 (as indicated by futures) >> >> Most people see the above and think, ?okay, soon after the fork the >> miners will switch back to 1x because price is higher.? >> >> But, is it not the case that while price might be higher, block times are >> lower. So if you consider it from a $ revenue per day: >> - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m >> per day ($4,000 x 360) >> - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or >> $1.44m per day ($1,000 x 1,440) >> >> In the above case, the revenue stream of both coins is equal, at $1.44m >> per day. So even though one coin is priced higher, it doesn?t mean miners >> will necessarily choose that chain to mine. >> >> Am I missing something? >> >> >> Kind regards, >> -Erik Voorhees >> CEO ShapeShift AG >> >> On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( >> bitcoin-segwit2x at lists.linuxfoundation.org) wrote: >> >> >> >> On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> Miners need to move their funds into exchanges to sell them. If they >>> can't deposit coins to an exchange, they become valueless. >>> >>> Assuming an 80-20 split, Block times for the minority chain spike to >>> ~49.3 minutes and will remain that long for ~69 days. This would >>> effectively block the minority chain's functionality as a payment system, >>> as it will become increasingly impossible to deposit funds, or move them >>> between exchanges (assuming transaction demand remains linear). Miners can >>> prioritize their own transactions in blocks, but regular customers will be >>> left out to dry. >>> >>> I don't anyone should under-estimate the negative effects of this on >>> market participants. >>> >>> A lot of us have customers who expect bitcoin to just "work". If we >>> start telling them they can't spend their money for several days/weeks, the >>> choice of which chain is viable will quickly become clear. It will be >>> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >>> altogether. >>> >>> (To be clear, Bitaccess is neutral on this fork, we just want customers >>> to remain happy. They way this is going, that doesn't seem to be a likely >>> outcome) >>> >> >> What typically happens is (shock horror) miners will mine in self >> interest. If you consider mining as a commodity, it makes sense that >> they'll just go for the most profitable coin, and not act altruistically, >> which was suggested in the original white paper. >> >> Mining is therefore common is a 0% / 100% until fees for a block make it >> profitable to mine that block (cab take several days) or the difficulty >> adjusts the profitability. >> >> This phenomenon is often referred to as "feast and famine". >> >> Given the market is showing that the 2x coin will be valued under 20% of >> bitcoin, miners acting in self interest will mine bitcoin and the 2x chain >> will freeze up, requiring subsidy to mine. Such subsidies could be added >> by creating a few transactions with high mining fees. >> >>> >>> >>> -- >>> *Moe Adham, MSc, BEng **|* Co-Founder >>> >>> *bitaccess.co * >>> Cell: *+1 858 877 3420 <(858)%20877-3420>* >>> >>> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> It is at this point that common sense needs to be applied. Even the >>>> most ardent anti SegWit2x upgrade individual would snap up the ?airdrop? >>>> should there be 2 viable chains post Nov HF. That in itself is demand >>>> enough to have a market for both tokens. The flip side is that with an >>>> unusable chain, it matters not whether exchanges respond to user requests >>>> for listing as you won?t be able to move your tokens anyway. >>>> >>>> >>>> >>>> *From:* Samuel Reed via Bitcoin-segwit2x >>>> >>>> *Sent:* 24 October 2017 16:31 >>>> *To:* Peter >>>> *Cc:* Bitcoin Segwit2x >>>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >>>> guarantee) - Ensuring a smooth 2X upgrade without a chain split >>>> >>>> >>>> >>>> Another lesson to be learned from BCH is that incentives matter - where >>>> miners can sell coins depends on markets, and market prices depend on user >>>> and exchange support. Even if the 80% of miners signaling 2x at this time >>>> choose to go forward, if there are not viable markets willing to buy 2x >>>> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >>>> >>>> Peter wrote: >>>> >>>> >>>> >>>> >>>> >>>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>> >RP that encourages a network split would render the NYA voidable >>>> >>>> Phillip, if there is consensus on one thing, it is there is going to be >>>> a network split. Every exchange is publishing policies for the chain split. >>>> Some even saying that they will not support the segwit2x token. >>>> >>>> -Chris >>>> >>>> >>>> >>>> The technical lesson from the BCH fork was that 1 hash = 1 vote. >>>> Nothing any exchange (or custodian) said mattered. Indeed because >>>> significant sha256 hashpower was deployed towards the fork it gained value >>>> and customers of exchanges pressured the exchanges into the financially >>>> sensible decision. >>>> >>>> >>>> >>>> This proposal, SegWit2x, is for the miners to decide. >>>> >>>> >>>> >>>> Transaction selection is not a consensus rule. Any miners that want to >>>> go against the Nakamoto signaling is free to do so and the responsible >>>> party (not the 2x devs who have no control over transaction selection). If >>>> because of the political climate some miner sees an economic opportunity to >>>> resurrect the legacy chain then they can modify their node (without >>>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>>> found in the 2x chain. >>>> >>>> >>>> >>>> Additionally, to complete a safe chain resurrection such a miner can >>>> airdrop the mining reward from the forked block (after 100 depth) and send >>>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>>> simple splitting solution. >>>> >>>> >>>> >>>> Safety efforts which do not require consensus changes should be >>>> exhausted first before suggesting consensus changes. >>>> >>>> >>>> >>>> Regards >>>> >>>> Peter >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > -- > > John C > Bitcoin Error Log > www.bitcoinerrorlog.com > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaredr26 at gmail.com Tue Oct 24 16:44:24 2017 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Tue, 24 Oct 2017 09:44:24 -0700 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: Yes Erik, The $1.44m per day is split among 20% on one side, and among 80% on the other side. The miners on the 80% get a much smaller piece of the pie each. The miners will stick to the NYA and mine unprofitably for a time. The question is whether users will switch faster or miners. Also, the futures prices will rise before the fork. At the moment the futures prices must price-in the possibility of a fork not happening, which under the terms chosen by Bitfinex(and others) favors BT1 entirely. As we get closer to the fork event, that possibility will stop weighing on the price. Jared On Tue, Oct 24, 2017 at 9:27 AM, Erik Voorhees via Bitcoin-segwit2x wrote: > I have a question for the group... > > > "Given the market is showing that the 2x coin will be valued under 20% of > bitcoin, miners acting in self interest will mine bitcoin and the 2x chain > will freeze up, requiring subsidy to mine.? - Mo Adham > > -Let?s assume, immediately following the fork, 1x has 20% of hash power, and > 2x has 80% (as indicated by miner signaling) > -Let?s assume also that the price, immediately following the fork, 1x is > $4,000 and 2x is $1,000 (as indicated by futures) > > Most people see the above and think, ?okay, soon after the fork the miners > will switch back to 1x because price is higher.? > > But, is it not the case that while price might be higher, block times are > lower. So if you consider it from a $ revenue per day: > - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m per > day ($4,000 x 360) > - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or $1.44m > per day ($1,000 x 1,440) > > In the above case, the revenue stream of both coins is equal, at $1.44m per > day. So even though one coin is priced higher, it doesn?t mean miners will > necessarily choose that chain to mine. > > Am I missing something? > > > Kind regards, > -Erik Voorhees > CEO ShapeShift AG > > On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x > (bitcoin-segwit2x at lists.linuxfoundation.org) wrote: > > > > On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x > wrote: >> >> Miners need to move their funds into exchanges to sell them. If they can't >> deposit coins to an exchange, they become valueless. >> >> Assuming an 80-20 split, Block times for the minority chain spike to ~49.3 >> minutes and will remain that long for ~69 days. This would effectively block >> the minority chain's functionality as a payment system, as it will become >> increasingly impossible to deposit funds, or move them between exchanges >> (assuming transaction demand remains linear). Miners can prioritize their >> own transactions in blocks, but regular customers will be left out to dry. >> >> I don't anyone should under-estimate the negative effects of this on >> market participants. >> >> A lot of us have customers who expect bitcoin to just "work". If we start >> telling them they can't spend their money for several days/weeks, the choice >> of which chain is viable will quickly become clear. It will be neither >> Bitcoin1x or Bitcoin2x. It will be a different blockchain altogether. >> >> (To be clear, Bitaccess is neutral on this fork, we just want customers to >> remain happy. They way this is going, that doesn't seem to be a likely >> outcome) > > > What typically happens is (shock horror) miners will mine in self interest. > If you consider mining as a commodity, it makes sense that they'll just go > for the most profitable coin, and not act altruistically, which was > suggested in the original white paper. > > Mining is therefore common is a 0% / 100% until fees for a block make it > profitable to mine that block (cab take several days) or the difficulty > adjusts the profitability. > > This phenomenon is often referred to as "feast and famine". > > Given the market is showing that the 2x coin will be valued under 20% of > bitcoin, miners acting in self interest will mine bitcoin and the 2x chain > will freeze up, requiring subsidy to mine. Such subsidies could be added by > creating a few transactions with high mining fees. > >> >> >> -- >> Moe Adham, MSc, BEng | Co-Founder >> >> bitaccess.co >> Cell: +1 858 877 3420 >> >> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x >> wrote: >>> >>> It is at this point that common sense needs to be applied. Even the most >>> ardent anti SegWit2x upgrade individual would snap up the ?airdrop? should >>> there be 2 viable chains post Nov HF. That in itself is demand enough to >>> have a market for both tokens. The flip side is that with an unusable chain, >>> it matters not whether exchanges respond to user requests for listing as you >>> won?t be able to move your tokens anyway. >>> >>> >>> >>> From: Samuel Reed via Bitcoin-segwit2x >>> Sent: 24 October 2017 16:31 >>> To: Peter >>> Cc: Bitcoin Segwit2x >>> Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >>> guarantee) - Ensuring a smooth 2X upgrade without a chain split >>> >>> >>> >>> Another lesson to be learned from BCH is that incentives matter - where >>> miners can sell coins depends on markets, and market prices depend on user >>> and exchange support. Even if the 80% of miners signaling 2x at this time >>> choose to go forward, if there are not viable markets willing to buy 2x >>> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >>> >>> Peter wrote: >>> >>> >>> >>> >>> >>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" >>> wrote: >>> >>> >RP that encourages a network split would render the NYA voidable >>> >>> Phillip, if there is consensus on one thing, it is there is going to be a >>> network split. Every exchange is publishing policies for the chain split. >>> Some even saying that they will not support the segwit2x token. >>> >>> -Chris >>> >>> >>> >>> The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing >>> any exchange (or custodian) said mattered. Indeed because significant sha256 >>> hashpower was deployed towards the fork it gained value and customers of >>> exchanges pressured the exchanges into the financially sensible decision. >>> >>> >>> >>> This proposal, SegWit2x, is for the miners to decide. >>> >>> >>> >>> Transaction selection is not a consensus rule. Any miners that want to go >>> against the Nakamoto signaling is free to do so and the responsible party >>> (not the 2x devs who have no control over transaction selection). If because >>> of the political climate some miner sees an economic opportunity to >>> resurrect the legacy chain then they can modify their node (without >>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>> found in the 2x chain. >>> >>> >>> >>> Additionally, to complete a safe chain resurrection such a miner can >>> airdrop the mining reward from the forked block (after 100 depth) and send >>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>> simple splitting solution. >>> >>> >>> >>> Safety efforts which do not require consensus changes should be exhausted >>> first before suggesting consensus changes. >>> >>> >>> >>> Regards >>> >>> Peter >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From hubert.maslin at gmail.com Tue Oct 24 16:44:33 2017 From: hubert.maslin at gmail.com (hubert maslin) Date: Tue, 24 Oct 2017 18:44:33 +0200 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: The only way there could be demand for B2X would be by having miners deny mining on the original chain for long enough as to make its price tank - and it's not even sure it would tank so much - so as to orient new capital to the B2X chain. This hard fork would be a denial of service activated hard fork: it counts on DoSing Bitcoin so as to create demand for the forked chain. 2017-10-24 18:38 GMT+02:00 Bitcoin Error Log via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org>: > What you are missing is that YOU are now heavily speculating, Erik. It > doesn't matter if miners express indecision. There will be two chains, and > you are nuts if you think some volatility in hashrate allows for a > definitive diagnosis that RP is not needed. > > Miners will mine what pays best. Ask yourself, who will be paying for S2X > coins? You may have gotten miners to agree, and some businesses to support > your fork, but NO ONE WANTS TO BUY B2X. The demand isn't there, and if > we're realistic, our example scenario would be whether the S2X chain is > sustainable, not the reverse. > > > On Tue, Oct 24, 2017 at 12:27 PM Erik Voorhees via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> I have a question for the group... >> >> >> "Given the market is showing that the 2x coin will be valued under 20% >> of bitcoin, miners acting in self interest will mine bitcoin and the 2x >> chain will freeze up, requiring subsidy to mine.? - Mo Adham >> >> -Let?s assume, immediately following the fork, 1x has 20% of hash power, >> and 2x has 80% (as indicated by miner signaling) >> -Let?s assume also that the price, immediately following the fork, 1x is >> $4,000 and 2x is $1,000 (as indicated by futures) >> >> Most people see the above and think, ?okay, soon after the fork the >> miners will switch back to 1x because price is higher.? >> >> But, is it not the case that while price might be higher, block times are >> lower. So if you consider it from a $ revenue per day: >> - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m >> per day ($4,000 x 360) >> - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or >> $1.44m per day ($1,000 x 1,440) >> >> In the above case, the revenue stream of both coins is equal, at $1.44m >> per day. So even though one coin is priced higher, it doesn?t mean miners >> will necessarily choose that chain to mine. >> >> Am I missing something? >> >> >> Kind regards, >> -Erik Voorhees >> CEO ShapeShift AG >> >> On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( >> bitcoin-segwit2x at lists.linuxfoundation.org) wrote: >> >> >> >> On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> Miners need to move their funds into exchanges to sell them. If they >>> can't deposit coins to an exchange, they become valueless. >>> >>> Assuming an 80-20 split, Block times for the minority chain spike to >>> ~49.3 minutes and will remain that long for ~69 days. This would >>> effectively block the minority chain's functionality as a payment system, >>> as it will become increasingly impossible to deposit funds, or move them >>> between exchanges (assuming transaction demand remains linear). Miners can >>> prioritize their own transactions in blocks, but regular customers will be >>> left out to dry. >>> >>> I don't anyone should under-estimate the negative effects of this on >>> market participants. >>> >>> A lot of us have customers who expect bitcoin to just "work". If we >>> start telling them they can't spend their money for several days/weeks, the >>> choice of which chain is viable will quickly become clear. It will be >>> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >>> altogether. >>> >>> (To be clear, Bitaccess is neutral on this fork, we just want customers >>> to remain happy. They way this is going, that doesn't seem to be a likely >>> outcome) >>> >> >> What typically happens is (shock horror) miners will mine in self >> interest. If you consider mining as a commodity, it makes sense that >> they'll just go for the most profitable coin, and not act altruistically, >> which was suggested in the original white paper. >> >> Mining is therefore common is a 0% / 100% until fees for a block make it >> profitable to mine that block (cab take several days) or the difficulty >> adjusts the profitability. >> >> This phenomenon is often referred to as "feast and famine". >> >> Given the market is showing that the 2x coin will be valued under 20% of >> bitcoin, miners acting in self interest will mine bitcoin and the 2x chain >> will freeze up, requiring subsidy to mine. Such subsidies could be added >> by creating a few transactions with high mining fees. >> >>> >>> >>> -- >>> *Moe Adham, MSc, BEng **|* Co-Founder >>> >>> *bitaccess.co * >>> Cell: *+1 858 877 3420 <(858)%20877-3420>* >>> >>> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> It is at this point that common sense needs to be applied. Even the >>>> most ardent anti SegWit2x upgrade individual would snap up the ?airdrop? >>>> should there be 2 viable chains post Nov HF. That in itself is demand >>>> enough to have a market for both tokens. The flip side is that with an >>>> unusable chain, it matters not whether exchanges respond to user requests >>>> for listing as you won?t be able to move your tokens anyway. >>>> >>>> >>>> >>>> *From:* Samuel Reed via Bitcoin-segwit2x >>>> >>>> *Sent:* 24 October 2017 16:31 >>>> *To:* Peter >>>> *Cc:* Bitcoin Segwit2x >>>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >>>> guarantee) - Ensuring a smooth 2X upgrade without a chain split >>>> >>>> >>>> >>>> Another lesson to be learned from BCH is that incentives matter - where >>>> miners can sell coins depends on markets, and market prices depend on user >>>> and exchange support. Even if the 80% of miners signaling 2x at this time >>>> choose to go forward, if there are not viable markets willing to buy 2x >>>> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >>>> >>>> Peter wrote: >>>> >>>> >>>> >>>> >>>> >>>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>> >RP that encourages a network split would render the NYA voidable >>>> >>>> Phillip, if there is consensus on one thing, it is there is going to be >>>> a network split. Every exchange is publishing policies for the chain split. >>>> Some even saying that they will not support the segwit2x token. >>>> >>>> -Chris >>>> >>>> >>>> >>>> The technical lesson from the BCH fork was that 1 hash = 1 vote. >>>> Nothing any exchange (or custodian) said mattered. Indeed because >>>> significant sha256 hashpower was deployed towards the fork it gained value >>>> and customers of exchanges pressured the exchanges into the financially >>>> sensible decision. >>>> >>>> >>>> >>>> This proposal, SegWit2x, is for the miners to decide. >>>> >>>> >>>> >>>> Transaction selection is not a consensus rule. Any miners that want to >>>> go against the Nakamoto signaling is free to do so and the responsible >>>> party (not the 2x devs who have no control over transaction selection). If >>>> because of the political climate some miner sees an economic opportunity to >>>> resurrect the legacy chain then they can modify their node (without >>>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>>> found in the 2x chain. >>>> >>>> >>>> >>>> Additionally, to complete a safe chain resurrection such a miner can >>>> airdrop the mining reward from the forked block (after 100 depth) and send >>>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>>> simple splitting solution. >>>> >>>> >>>> >>>> Safety efforts which do not require consensus changes should be >>>> exhausted first before suggesting consensus changes. >>>> >>>> >>>> >>>> Regards >>>> >>>> Peter >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > -- > > John C > Bitcoin Error Log > www.bitcoinerrorlog.com > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Tue Oct 24 16:48:29 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Tue, 24 Oct 2017 16:48:29 +0000 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> , Message-ID: The only thing you are missing (probably unrelated) is that the NYA miners are slightly dis-incentivised to mine coinbase tx only blocks on the legacy chain as they?d be giving up fee revenue (double the existing average). From: Erik Voorhees via Bitcoin-segwit2x Sent: 24 October 2017 17:27 To: Melvin Carvalho; Moe Adham; Melvin Carvalho via Bitcoin-segwit2x Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split I have a question for the group... "Given the market is showing that the 2x coin will be valued under 20% of bitcoin, miners acting in self interest will mine bitcoin and the 2x chain will freeze up, requiring subsidy to mine.? - Mo Adham -Let?s assume, immediately following the fork, 1x has 20% of hash power, and 2x has 80% (as indicated by miner signaling) -Let?s assume also that the price, immediately following the fork, 1x is $4,000 and 2x is $1,000 (as indicated by futures) Most people see the above and think, ?okay, soon after the fork the miners will switch back to 1x because price is higher.? But, is it not the case that while price might be higher, block times are lower. So if you consider it from a $ revenue per day: - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m per day ($4,000 x 360) - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or $1.44m per day ($1,000 x 1,440) In the above case, the revenue stream of both coins is equal, at $1.44m per day. So even though one coin is priced higher, it doesn?t mean miners will necessarily choose that chain to mine. Am I missing something? Kind regards, -Erik Voorhees CEO ShapeShift AG On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x (bitcoin-segwit2x at lists.linuxfoundation.org) wrote: On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x > wrote: Miners need to move their funds into exchanges to sell them. If they can't deposit coins to an exchange, they become valueless. Assuming an 80-20 split, Block times for the minority chain spike to ~49.3 minutes and will remain that long for ~69 days. This would effectively block the minority chain's functionality as a payment system, as it will become increasingly impossible to deposit funds, or move them between exchanges (assuming transaction demand remains linear). Miners can prioritize their own transactions in blocks, but regular customers will be left out to dry. I don't anyone should under-estimate the negative effects of this on market participants. A lot of us have customers who expect bitcoin to just "work". If we start telling them they can't spend their money for several days/weeks, the choice of which chain is viable will quickly become clear. It will be neither Bitcoin1x or Bitcoin2x. It will be a different blockchain altogether. (To be clear, Bitaccess is neutral on this fork, we just want customers to remain happy. They way this is going, that doesn't seem to be a likely outcome) What typically happens is (shock horror) miners will mine in self interest. If you consider mining as a commodity, it makes sense that they'll just go for the most profitable coin, and not act altruistically, which was suggested in the original white paper. Mining is therefore common is a 0% / 100% until fees for a block make it profitable to mine that block (cab take several days) or the difficulty adjusts the profitability. This phenomenon is often referred to as "feast and famine". Given the market is showing that the 2x coin will be valued under 20% of bitcoin, miners acting in self interest will mine bitcoin and the 2x chain will freeze up, requiring subsidy to mine. Such subsidies could be added by creating a few transactions with high mining fees. -- Moe Adham, MSc, BEng | Co-Founder bitaccess.co Cell: +1 858 877 3420 On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x > wrote: It is at this point that common sense needs to be applied. Even the most ardent anti SegWit2x upgrade individual would snap up the ?airdrop? should there be 2 viable chains post Nov HF. That in itself is demand enough to have a market for both tokens. The flip side is that with an unusable chain, it matters not whether exchanges respond to user requests for listing as you won?t be able to move your tokens anyway. From: Samuel Reed via Bitcoin-segwit2x Sent: 24 October 2017 16:31 To: Peter Cc: Bitcoin Segwit2x Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split Another lesson to be learned from BCH is that incentives matter - where miners can sell coins depends on markets, and market prices depend on user and exchange support. Even if the 80% of miners signaling 2x at this time choose to go forward, if there are not viable markets willing to buy 2x coins at near 1x prices, 2x hash power will quickly revert to the old chain. Peter wrote: On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" > wrote: >RP that encourages a network split would render the NYA voidable Phillip, if there is consensus on one thing, it is there is going to be a network split. Every exchange is publishing policies for the chain split. Some even saying that they will not support the segwit2x token. -Chris The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing any exchange (or custodian) said mattered. Indeed because significant sha256 hashpower was deployed towards the fork it gained value and customers of exchanges pressured the exchanges into the financially sensible decision. This proposal, SegWit2x, is for the miners to decide. Transaction selection is not a consensus rule. Any miners that want to go against the Nakamoto signaling is free to do so and the responsible party (not the 2x devs who have no control over transaction selection). If because of the political climate some miner sees an economic opportunity to resurrect the legacy chain then they can modify their node (without consensus change) to listen to 2x blocks and not mine any transaction IDs found in the 2x chain. Additionally, to complete a safe chain resurrection such a miner can airdrop the mining reward from the forked block (after 100 depth) and send it to to all addresses with UTXOs over $x value. So that users of the 1x chain can spend the combined UTXOs which cannot be replayed on 2x, as a simple splitting solution. Safety efforts which do not require consensus changes should be exhausted first before suggesting consensus changes. Regards Peter _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at shapeshift.io Tue Oct 24 16:50:50 2017 From: erik at shapeshift.io (Erik Voorhees) Date: Tue, 24 Oct 2017 12:50:50 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: "What you are missing is that YOU are now heavily speculating, Erik. " Bitcoin Error Log - stop turning everything into an attack. I was asking a mathematical question. To everyone else who responded civilily, thank you. Kind regards, -Erik Voorhees CEO ShapeShift AG On October 24, 2017 at 10:44:52 AM, hubert maslin via Bitcoin-segwit2x ( bitcoin-segwit2x at lists.linuxfoundation.org) wrote: The only way there could be demand for B2X would be by having miners deny mining on the original chain for long enough as to make its price tank - and it's not even sure it would tank so much - so as to orient new capital to the B2X chain. This hard fork would be a denial of service activated hard fork: it counts on DoSing Bitcoin so as to create demand for the forked chain. 2017-10-24 18:38 GMT+02:00 Bitcoin Error Log via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org>: > What you are missing is that YOU are now heavily speculating, Erik. It > doesn't matter if miners express indecision. There will be two chains, and > you are nuts if you think some volatility in hashrate allows for a > definitive diagnosis that RP is not needed. > > Miners will mine what pays best. Ask yourself, who will be paying for S2X > coins? You may have gotten miners to agree, and some businesses to support > your fork, but NO ONE WANTS TO BUY B2X. The demand isn't there, and if > we're realistic, our example scenario would be whether the S2X chain is > sustainable, not the reverse. > > > On Tue, Oct 24, 2017 at 12:27 PM Erik Voorhees via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> I have a question for the group... >> >> >> "Given the market is showing that the 2x coin will be valued under 20% >> of bitcoin, miners acting in self interest will mine bitcoin and the 2x >> chain will freeze up, requiring subsidy to mine.? - Mo Adham >> >> -Let?s assume, immediately following the fork, 1x has 20% of hash power, >> and 2x has 80% (as indicated by miner signaling) >> -Let?s assume also that the price, immediately following the fork, 1x is >> $4,000 and 2x is $1,000 (as indicated by futures) >> >> Most people see the above and think, ?okay, soon after the fork the >> miners will switch back to 1x because price is higher.? >> >> But, is it not the case that while price might be higher, block times are >> lower. So if you consider it from a $ revenue per day: >> - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m >> per day ($4,000 x 360) >> - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or >> $1.44m per day ($1,000 x 1,440) >> >> In the above case, the revenue stream of both coins is equal, at $1.44m >> per day. So even though one coin is priced higher, it doesn?t mean miners >> will necessarily choose that chain to mine. >> >> Am I missing something? >> >> >> Kind regards, >> -Erik Voorhees >> CEO ShapeShift AG >> >> On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( >> bitcoin-segwit2x at lists.linuxfoundation.org) wrote: >> >> >> >> On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> Miners need to move their funds into exchanges to sell them. If they >>> can't deposit coins to an exchange, they become valueless. >>> >>> Assuming an 80-20 split, Block times for the minority chain spike to >>> ~49.3 minutes and will remain that long for ~69 days. This would >>> effectively block the minority chain's functionality as a payment system, >>> as it will become increasingly impossible to deposit funds, or move them >>> between exchanges (assuming transaction demand remains linear). Miners can >>> prioritize their own transactions in blocks, but regular customers will be >>> left out to dry. >>> >>> I don't anyone should under-estimate the negative effects of this on >>> market participants. >>> >>> A lot of us have customers who expect bitcoin to just "work". If we >>> start telling them they can't spend their money for several days/weeks, the >>> choice of which chain is viable will quickly become clear. It will be >>> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >>> altogether. >>> >>> (To be clear, Bitaccess is neutral on this fork, we just want customers >>> to remain happy. They way this is going, that doesn't seem to be a likely >>> outcome) >>> >> >> What typically happens is (shock horror) miners will mine in self >> interest. If you consider mining as a commodity, it makes sense that >> they'll just go for the most profitable coin, and not act altruistically, >> which was suggested in the original white paper. >> >> Mining is therefore common is a 0% / 100% until fees for a block make it >> profitable to mine that block (cab take several days) or the difficulty >> adjusts the profitability. >> >> This phenomenon is often referred to as "feast and famine". >> >> Given the market is showing that the 2x coin will be valued under 20% of >> bitcoin, miners acting in self interest will mine bitcoin and the 2x chain >> will freeze up, requiring subsidy to mine. Such subsidies could be added >> by creating a few transactions with high mining fees. >> >>> >>> >>> -- >>> *Moe Adham, MSc, BEng **|* Co-Founder >>> >>> *bitaccess.co * >>> Cell: *+1 858 877 3420 <(858)%20877-3420>* >>> >>> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> It is at this point that common sense needs to be applied. Even the >>>> most ardent anti SegWit2x upgrade individual would snap up the ?airdrop? >>>> should there be 2 viable chains post Nov HF. That in itself is demand >>>> enough to have a market for both tokens. The flip side is that with an >>>> unusable chain, it matters not whether exchanges respond to user requests >>>> for listing as you won?t be able to move your tokens anyway. >>>> >>>> >>>> >>>> *From:* Samuel Reed via Bitcoin-segwit2x >>>> >>>> *Sent:* 24 October 2017 16:31 >>>> *To:* Peter >>>> *Cc:* Bitcoin Segwit2x >>>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >>>> guarantee) - Ensuring a smooth 2X upgrade without a chain split >>>> >>>> >>>> >>>> Another lesson to be learned from BCH is that incentives matter - where >>>> miners can sell coins depends on markets, and market prices depend on user >>>> and exchange support. Even if the 80% of miners signaling 2x at this time >>>> choose to go forward, if there are not viable markets willing to buy 2x >>>> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >>>> >>>> Peter wrote: >>>> >>>> >>>> >>>> >>>> >>>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>> >RP that encourages a network split would render the NYA voidable >>>> >>>> Phillip, if there is consensus on one thing, it is there is going to be >>>> a network split. Every exchange is publishing policies for the chain split. >>>> Some even saying that they will not support the segwit2x token. >>>> >>>> -Chris >>>> >>>> >>>> >>>> The technical lesson from the BCH fork was that 1 hash = 1 vote. >>>> Nothing any exchange (or custodian) said mattered. Indeed because >>>> significant sha256 hashpower was deployed towards the fork it gained value >>>> and customers of exchanges pressured the exchanges into the financially >>>> sensible decision. >>>> >>>> >>>> >>>> This proposal, SegWit2x, is for the miners to decide. >>>> >>>> >>>> >>>> Transaction selection is not a consensus rule. Any miners that want to >>>> go against the Nakamoto signaling is free to do so and the responsible >>>> party (not the 2x devs who have no control over transaction selection). If >>>> because of the political climate some miner sees an economic opportunity to >>>> resurrect the legacy chain then they can modify their node (without >>>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>>> found in the 2x chain. >>>> >>>> >>>> >>>> Additionally, to complete a safe chain resurrection such a miner can >>>> airdrop the mining reward from the forked block (after 100 depth) and send >>>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>>> simple splitting solution. >>>> >>>> >>>> >>>> Safety efforts which do not require consensus changes should be >>>> exhausted first before suggesting consensus changes. >>>> >>>> >>>> >>>> Regards >>>> >>>> Peter >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > -- > > John C > Bitcoin Error Log > www.bitcoinerrorlog.com > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at thancodes.com Tue Oct 24 16:51:07 2017 From: jon at thancodes.com (Jonathan Sterling) Date: Wed, 25 Oct 2017 00:51:07 +0800 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: Most easily understood by example: 11 miners with equal hash power on current BTC chain Split happens and 10 go to 2x 1x worth 4000 2x worth 1000 1x is 10 times slower but split across 10 times less miners So 1x miner gets *4000 every 100 mins* So 2x miners split 1000 every 10 mins, for an average of *1000 each every 100 mins* Hope that makes sense. Hubert is right that the price would have to tank to make mining the other chain more viable. Game-theory wise, it might make sense to tank the price of the current BTC chain by slowing block time down on the incumbent BTC chain to ensure the 2x chain goes up in price and makes mining worthwhile in the long run. I think all involved should focus more on the endgame rather than the short-term ramifications. Higher throughput + faster transaction confirmation time + lower fees == better user experience == 2x being more valuable *in the long run*. Kind Regards, Jonathan Sterling On Wed, Oct 25, 2017 at 12:44 AM, hubert maslin via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > The only way there could be demand for B2X would be by having miners deny > mining on the original chain for long enough as to make its price tank - > and it's not even sure it would tank so much - so as to orient new capital > to the B2X chain. This hard fork would be a denial of service activated > hard fork: it counts on DoSing Bitcoin so as to create demand for the > forked chain. > > 2017-10-24 18:38 GMT+02:00 Bitcoin Error Log via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org>: > >> What you are missing is that YOU are now heavily speculating, Erik. It >> doesn't matter if miners express indecision. There will be two chains, and >> you are nuts if you think some volatility in hashrate allows for a >> definitive diagnosis that RP is not needed. >> >> Miners will mine what pays best. Ask yourself, who will be paying for S2X >> coins? You may have gotten miners to agree, and some businesses to support >> your fork, but NO ONE WANTS TO BUY B2X. The demand isn't there, and if >> we're realistic, our example scenario would be whether the S2X chain is >> sustainable, not the reverse. >> >> >> On Tue, Oct 24, 2017 at 12:27 PM Erik Voorhees via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> I have a question for the group... >>> >>> >>> "Given the market is showing that the 2x coin will be valued under 20% >>> of bitcoin, miners acting in self interest will mine bitcoin and the 2x >>> chain will freeze up, requiring subsidy to mine.? - Mo Adham >>> >>> -Let?s assume, immediately following the fork, 1x has 20% of hash power, >>> and 2x has 80% (as indicated by miner signaling) >>> -Let?s assume also that the price, immediately following the fork, 1x is >>> $4,000 and 2x is $1,000 (as indicated by futures) >>> >>> Most people see the above and think, ?okay, soon after the fork the >>> miners will switch back to 1x because price is higher.? >>> >>> But, is it not the case that while price might be higher, block times >>> are lower. So if you consider it from a $ revenue per day: >>> - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m >>> per day ($4,000 x 360) >>> - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or >>> $1.44m per day ($1,000 x 1,440) >>> >>> In the above case, the revenue stream of both coins is equal, at $1.44m >>> per day. So even though one coin is priced higher, it doesn?t mean miners >>> will necessarily choose that chain to mine. >>> >>> Am I missing something? >>> >>> >>> Kind regards, >>> -Erik Voorhees >>> CEO ShapeShift AG >>> >>> On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( >>> bitcoin-segwit2x at lists.linuxfoundation.org) wrote: >>> >>> >>> >>> On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> Miners need to move their funds into exchanges to sell them. If they >>>> can't deposit coins to an exchange, they become valueless. >>>> >>>> Assuming an 80-20 split, Block times for the minority chain spike to >>>> ~49.3 minutes and will remain that long for ~69 days. This would >>>> effectively block the minority chain's functionality as a payment system, >>>> as it will become increasingly impossible to deposit funds, or move them >>>> between exchanges (assuming transaction demand remains linear). Miners can >>>> prioritize their own transactions in blocks, but regular customers will be >>>> left out to dry. >>>> >>>> I don't anyone should under-estimate the negative effects of this on >>>> market participants. >>>> >>>> A lot of us have customers who expect bitcoin to just "work". If we >>>> start telling them they can't spend their money for several days/weeks, the >>>> choice of which chain is viable will quickly become clear. It will be >>>> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >>>> altogether. >>>> >>>> (To be clear, Bitaccess is neutral on this fork, we just want customers >>>> to remain happy. They way this is going, that doesn't seem to be a likely >>>> outcome) >>>> >>> >>> What typically happens is (shock horror) miners will mine in self >>> interest. If you consider mining as a commodity, it makes sense that >>> they'll just go for the most profitable coin, and not act altruistically, >>> which was suggested in the original white paper. >>> >>> Mining is therefore common is a 0% / 100% until fees for a block make it >>> profitable to mine that block (cab take several days) or the difficulty >>> adjusts the profitability. >>> >>> This phenomenon is often referred to as "feast and famine". >>> >>> Given the market is showing that the 2x coin will be valued under 20% of >>> bitcoin, miners acting in self interest will mine bitcoin and the 2x chain >>> will freeze up, requiring subsidy to mine. Such subsidies could be added >>> by creating a few transactions with high mining fees. >>> >>>> >>>> >>>> -- >>>> *Moe Adham, MSc, BEng **|* Co-Founder >>>> >>>> *bitaccess.co * >>>> Cell: *+1 858 877 3420 <(858)%20877-3420>* >>>> >>>> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>>> It is at this point that common sense needs to be applied. Even the >>>>> most ardent anti SegWit2x upgrade individual would snap up the ?airdrop? >>>>> should there be 2 viable chains post Nov HF. That in itself is demand >>>>> enough to have a market for both tokens. The flip side is that with an >>>>> unusable chain, it matters not whether exchanges respond to user requests >>>>> for listing as you won?t be able to move your tokens anyway. >>>>> >>>>> >>>>> >>>>> *From:* Samuel Reed via Bitcoin-segwit2x >>>>> >>>>> *Sent:* 24 October 2017 16:31 >>>>> *To:* Peter >>>>> *Cc:* Bitcoin Segwit2x >>>>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero >>>>> replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split >>>>> >>>>> >>>>> >>>>> Another lesson to be learned from BCH is that incentives matter - >>>>> where miners can sell coins depends on markets, and market prices depend on >>>>> user and exchange support. Even if the 80% of miners signaling 2x at this >>>>> time choose to go forward, if there are not viable markets willing to buy >>>>> 2x coins at near 1x prices, 2x hash power will quickly revert to the old >>>>> chain. >>>>> >>>>> Peter wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>>> >>>>> >RP that encourages a network split would render the NYA voidable >>>>> >>>>> Phillip, if there is consensus on one thing, it is there is going to >>>>> be a network split. Every exchange is publishing policies for the chain >>>>> split. Some even saying that they will not support the segwit2x token. >>>>> >>>>> -Chris >>>>> >>>>> >>>>> >>>>> The technical lesson from the BCH fork was that 1 hash = 1 vote. >>>>> Nothing any exchange (or custodian) said mattered. Indeed because >>>>> significant sha256 hashpower was deployed towards the fork it gained value >>>>> and customers of exchanges pressured the exchanges into the financially >>>>> sensible decision. >>>>> >>>>> >>>>> >>>>> This proposal, SegWit2x, is for the miners to decide. >>>>> >>>>> >>>>> >>>>> Transaction selection is not a consensus rule. Any miners that want to >>>>> go against the Nakamoto signaling is free to do so and the responsible >>>>> party (not the 2x devs who have no control over transaction selection). If >>>>> because of the political climate some miner sees an economic opportunity to >>>>> resurrect the legacy chain then they can modify their node (without >>>>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>>>> found in the 2x chain. >>>>> >>>>> >>>>> >>>>> Additionally, to complete a safe chain resurrection such a miner can >>>>> airdrop the mining reward from the forked block (after 100 depth) and send >>>>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>>>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>>>> simple splitting solution. >>>>> >>>>> >>>>> >>>>> Safety efforts which do not require consensus changes should be >>>>> exhausted first before suggesting consensus changes. >>>>> >>>>> >>>>> >>>>> Regards >>>>> >>>>> Peter >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >> -- >> >> John C >> Bitcoin Error Log >> www.bitcoinerrorlog.com >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -- Kind Regards, Jonathan Sterling +44 (0)7415 512691 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbeaugas at gmail.com Tue Oct 24 16:51:20 2017 From: jbeaugas at gmail.com (John Beauregard) Date: Tue, 24 Oct 2017 16:51:20 +0000 Subject: [Bitcoin-segwit2x] E Message-ID: -- John Beauregard MD -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Tue Oct 24 16:51:29 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Tue, 24 Oct 2017 16:51:29 +0000 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> , Message-ID: Miners secure the network, SegWit2x is an upgrade to the network consensus rules. From: hubert maslin via Bitcoin-segwit2x Sent: 24 October 2017 17:44 To: segwit2x at lists.linuxfoundation.org Cc: bitcoin-segwit2x at lists.linuxfoundation.org Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split The only way there could be demand for B2X would be by having miners deny mining on the original chain for long enough as to make its price tank - and it's not even sure it would tank so much - so as to orient new capital to the B2X chain. This hard fork would be a denial of service activated hard fork: it counts on DoSing Bitcoin so as to create demand for the forked chain. 2017-10-24 18:38 GMT+02:00 Bitcoin Error Log via Bitcoin-segwit2x >: What you are missing is that YOU are now heavily speculating, Erik. It doesn't matter if miners express indecision. There will be two chains, and you are nuts if you think some volatility in hashrate allows for a definitive diagnosis that RP is not needed. Miners will mine what pays best. Ask yourself, who will be paying for S2X coins? You may have gotten miners to agree, and some businesses to support your fork, but NO ONE WANTS TO BUY B2X. The demand isn't there, and if we're realistic, our example scenario would be whether the S2X chain is sustainable, not the reverse. On Tue, Oct 24, 2017 at 12:27 PM Erik Voorhees via Bitcoin-segwit2x > wrote: I have a question for the group... "Given the market is showing that the 2x coin will be valued under 20% of bitcoin, miners acting in self interest will mine bitcoin and the 2x chain will freeze up, requiring subsidy to mine.? - Mo Adham -Let?s assume, immediately following the fork, 1x has 20% of hash power, and 2x has 80% (as indicated by miner signaling) -Let?s assume also that the price, immediately following the fork, 1x is $4,000 and 2x is $1,000 (as indicated by futures) Most people see the above and think, ?okay, soon after the fork the miners will switch back to 1x because price is higher.? But, is it not the case that while price might be higher, block times are lower. So if you consider it from a $ revenue per day: - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m per day ($4,000 x 360) - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or $1.44m per day ($1,000 x 1,440) In the above case, the revenue stream of both coins is equal, at $1.44m per day. So even though one coin is priced higher, it doesn?t mean miners will necessarily choose that chain to mine. Am I missing something? Kind regards, -Erik Voorhees CEO ShapeShift AG On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x (bitcoin-segwit2x at lists.linuxfoundation.org) wrote: On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x > wrote: Miners need to move their funds into exchanges to sell them. If they can't deposit coins to an exchange, they become valueless. Assuming an 80-20 split, Block times for the minority chain spike to ~49.3 minutes and will remain that long for ~69 days. This would effectively block the minority chain's functionality as a payment system, as it will become increasingly impossible to deposit funds, or move them between exchanges (assuming transaction demand remains linear). Miners can prioritize their own transactions in blocks, but regular customers will be left out to dry. I don't anyone should under-estimate the negative effects of this on market participants. A lot of us have customers who expect bitcoin to just "work". If we start telling them they can't spend their money for several days/weeks, the choice of which chain is viable will quickly become clear. It will be neither Bitcoin1x or Bitcoin2x. It will be a different blockchain altogether. (To be clear, Bitaccess is neutral on this fork, we just want customers to remain happy. They way this is going, that doesn't seem to be a likely outcome) What typically happens is (shock horror) miners will mine in self interest. If you consider mining as a commodity, it makes sense that they'll just go for the most profitable coin, and not act altruistically, which was suggested in the original white paper. Mining is therefore common is a 0% / 100% until fees for a block make it profitable to mine that block (cab take several days) or the difficulty adjusts the profitability. This phenomenon is often referred to as "feast and famine". Given the market is showing that the 2x coin will be valued under 20% of bitcoin, miners acting in self interest will mine bitcoin and the 2x chain will freeze up, requiring subsidy to mine. Such subsidies could be added by creating a few transactions with high mining fees. -- Moe Adham, MSc, BEng | Co-Founder bitaccess.co Cell: +1 858 877 3420 On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x > wrote: It is at this point that common sense needs to be applied. Even the most ardent anti SegWit2x upgrade individual would snap up the ?airdrop? should there be 2 viable chains post Nov HF. That in itself is demand enough to have a market for both tokens. The flip side is that with an unusable chain, it matters not whether exchanges respond to user requests for listing as you won?t be able to move your tokens anyway. From: Samuel Reed via Bitcoin-segwit2x Sent: 24 October 2017 16:31 To: Peter Cc: Bitcoin Segwit2x Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split Another lesson to be learned from BCH is that incentives matter - where miners can sell coins depends on markets, and market prices depend on user and exchange support. Even if the 80% of miners signaling 2x at this time choose to go forward, if there are not viable markets willing to buy 2x coins at near 1x prices, 2x hash power will quickly revert to the old chain. Peter wrote: On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" > wrote: >RP that encourages a network split would render the NYA voidable Phillip, if there is consensus on one thing, it is there is going to be a network split. Every exchange is publishing policies for the chain split. Some even saying that they will not support the segwit2x token. -Chris The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing any exchange (or custodian) said mattered. Indeed because significant sha256 hashpower was deployed towards the fork it gained value and customers of exchanges pressured the exchanges into the financially sensible decision. This proposal, SegWit2x, is for the miners to decide. Transaction selection is not a consensus rule. Any miners that want to go against the Nakamoto signaling is free to do so and the responsible party (not the 2x devs who have no control over transaction selection). If because of the political climate some miner sees an economic opportunity to resurrect the legacy chain then they can modify their node (without consensus change) to listen to 2x blocks and not mine any transaction IDs found in the 2x chain. Additionally, to complete a safe chain resurrection such a miner can airdrop the mining reward from the forked block (after 100 depth) and send it to to all addresses with UTXOs over $x value. So that users of the 1x chain can spend the combined UTXOs which cannot be replayed on 2x, as a simple splitting solution. Safety efforts which do not require consensus changes should be exhausted first before suggesting consensus changes. Regards Peter _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -- John C Bitcoin Error Log www.bitcoinerrorlog.com _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Tue Oct 24 16:54:44 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Tue, 24 Oct 2017 18:54:44 +0200 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: On 24 October 2017 at 18:27, Erik Voorhees wrote: > I have a question for the group... > > > "Given the market is showing that the 2x coin will be valued under 20% of > bitcoin, miners acting in self interest will mine bitcoin and the 2x chain > will freeze up, requiring subsidy to mine.? - Mo Adham > > > -Let?s assume, immediately following the fork, 1x has 20% of hash power, > and 2x has 80% (as indicated by miner signaling) > -Let?s assume also that the price, immediately following the fork, 1x is > $4,000 and 2x is $1,000 (as indicated by futures) > Questionable assumptions as signaling is not binding, and this turns out to be important, as miners can and do, switch between chains. > > > Most people see the above and think, ?okay, soon after the fork the miners > will switch back to 1x because price is higher.? > > But, is it not the case that while price might be higher, block times are > lower. So if you consider it from a $ revenue per day: > - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m > per day ($4,000 x 360) > - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or $1.44m > per day ($1,000 x 1,440) > > In the above case, the revenue stream of both coins is equal, at $1.44m > per day. So even though one coin is priced higher, it doesn?t mean miners > will necessarily choose that chain to mine. > If the difficulty of BTC2X adjusted down 80% both chains would be equally profitable to mine. Getting the difficulty down is the problem. More insights can be gained at https://www.coinwarz.com/cryptocurrency > > > Am I missing something? > > > Kind regards, > -Erik Voorhees > CEO ShapeShift AG > > On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( > bitcoin-segwit2x at lists.linuxfoundation.org) wrote: > > > > On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Miners need to move their funds into exchanges to sell them. If they >> can't deposit coins to an exchange, they become valueless. >> >> Assuming an 80-20 split, Block times for the minority chain spike to >> ~49.3 minutes and will remain that long for ~69 days. This would >> effectively block the minority chain's functionality as a payment system, >> as it will become increasingly impossible to deposit funds, or move them >> between exchanges (assuming transaction demand remains linear). Miners can >> prioritize their own transactions in blocks, but regular customers will be >> left out to dry. >> >> I don't anyone should under-estimate the negative effects of this on >> market participants. >> >> A lot of us have customers who expect bitcoin to just "work". If we start >> telling them they can't spend their money for several days/weeks, the >> choice of which chain is viable will quickly become clear. It will be >> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >> altogether. >> >> (To be clear, Bitaccess is neutral on this fork, we just want customers >> to remain happy. They way this is going, that doesn't seem to be a likely >> outcome) >> > > What typically happens is (shock horror) miners will mine in self > interest. If you consider mining as a commodity, it makes sense that > they'll just go for the most profitable coin, and not act altruistically, > which was suggested in the original white paper. > > Mining is therefore common is a 0% / 100% until fees for a block make it > profitable to mine that block (cab take several days) or the difficulty > adjusts the profitability. > > This phenomenon is often referred to as "feast and famine". > > Given the market is showing that the 2x coin will be valued under 20% of > bitcoin, miners acting in self interest will mine bitcoin and the 2x chain > will freeze up, requiring subsidy to mine. Such subsidies could be added > by creating a few transactions with high mining fees. > >> >> >> -- >> *Moe Adham, MSc, BEng **|* Co-Founder >> >> *bitaccess.co * >> Cell: *+1 858 877 3420 <%28858%29%20877-3420>* >> >> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> It is at this point that common sense needs to be applied. Even the most >>> ardent anti SegWit2x upgrade individual would snap up the ?airdrop? should >>> there be 2 viable chains post Nov HF. That in itself is demand enough to >>> have a market for both tokens. The flip side is that with an unusable >>> chain, it matters not whether exchanges respond to user requests for >>> listing as you won?t be able to move your tokens anyway. >>> >>> >>> >>> *From:* Samuel Reed via Bitcoin-segwit2x >>> >>> *Sent:* 24 October 2017 16:31 >>> *To:* Peter >>> *Cc:* Bitcoin Segwit2x >>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >>> guarantee) - Ensuring a smooth 2X upgrade without a chain split >>> >>> >>> >>> Another lesson to be learned from BCH is that incentives matter - where >>> miners can sell coins depends on markets, and market prices depend on user >>> and exchange support. Even if the 80% of miners signaling 2x at this time >>> choose to go forward, if there are not viable markets willing to buy 2x >>> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >>> >>> Peter wrote: >>> >>> >>> >>> >>> >>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>> >RP that encourages a network split would render the NYA voidable >>> >>> Phillip, if there is consensus on one thing, it is there is going to be >>> a network split. Every exchange is publishing policies for the chain split. >>> Some even saying that they will not support the segwit2x token. >>> >>> -Chris >>> >>> >>> >>> The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing >>> any exchange (or custodian) said mattered. Indeed because significant >>> sha256 hashpower was deployed towards the fork it gained value and >>> customers of exchanges pressured the exchanges into the financially >>> sensible decision. >>> >>> >>> >>> This proposal, SegWit2x, is for the miners to decide. >>> >>> >>> >>> Transaction selection is not a consensus rule. Any miners that want to >>> go against the Nakamoto signaling is free to do so and the responsible >>> party (not the 2x devs who have no control over transaction selection). If >>> because of the political climate some miner sees an economic opportunity to >>> resurrect the legacy chain then they can modify their node (without >>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>> found in the 2x chain. >>> >>> >>> >>> Additionally, to complete a safe chain resurrection such a miner can >>> airdrop the mining reward from the forked block (after 100 depth) and send >>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>> simple splitting solution. >>> >>> >>> >>> Safety efforts which do not require consensus changes should be >>> exhausted first before suggesting consensus changes. >>> >>> >>> >>> Regards >>> >>> Peter >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at dtrt.org Tue Oct 24 17:00:27 2017 From: dave at dtrt.org (David A. Harding) Date: Tue, 24 Oct 2017 13:00:27 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: <20171024170026.t66rhqbgjq25yh6d@fedora-23-dvm> On Tue, Oct 24, 2017 at 09:27:37AM -0700, Erik Voorhees via Bitcoin-segwit2x wrote: > So if you consider it from a $ revenue per day: > - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m per > day ($4,000 x 360) > - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or $1.44m > per day ($1,000 x 1,440) > > Am I missing something? Umm, yeah. 2x did four times as much work to make the same amount of money as 1x. By, "work", I of course mean that they expended four times as much electricity and tied up four times as much capital equipment. Maybe this isn't obvious since you're treating 1x miners and 2x miners as a group, but if you consider them as individual miners, it becomes clear that there's a strong incentive to defect to the more profitable chain. For example: Average daily blocks | 1x potential revenue | 2x potential revenue -------+----------------------+-----------------------+----------------------- Alice | 5 | 5*12.5*4000 = 250k | 5*12.5*1000 = 62.5k Bob | 10 | 10*12.5*4000 = 500k | 10*12.5*1000 = 125.0k Chalie | 25 | 25*12.5*4000 = 1,500k | 25*12.5*1000 = 312.5k You can replace "average daily blocks" with "kiloWatt hours (kWh) plus capital equipment depreciation costs" for a difficulty-neutral factor. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From chris at suredbits.com Tue Oct 24 17:11:41 2017 From: chris at suredbits.com (Chris Stewart) Date: Tue, 24 Oct 2017 12:11:41 -0500 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: Don't forget about transaction fees. If blocks are slower on bitcoin, an auction effectively starts on block space. If the economic majority is still using the bitcoin blockchain, while the majority of miners are mining the segwit2x chain we will see a large backlog that causes tx fees to increase in price. The bitcoin blockchain miners will make a killing in collecting those fees while segwit2x miners (if the economic majority stays with bitcoin) will miss out on them. -Chris On Tue, Oct 24, 2017 at 11:27 AM, Erik Voorhees via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > I have a question for the group... > > > "Given the market is showing that the 2x coin will be valued under 20% of > bitcoin, miners acting in self interest will mine bitcoin and the 2x chain > will freeze up, requiring subsidy to mine.? - Mo Adham > > -Let?s assume, immediately following the fork, 1x has 20% of hash power, > and 2x has 80% (as indicated by miner signaling) > -Let?s assume also that the price, immediately following the fork, 1x is > $4,000 and 2x is $1,000 (as indicated by futures) > > Most people see the above and think, ?okay, soon after the fork the miners > will switch back to 1x because price is higher.? > > But, is it not the case that while price might be higher, block times are > lower. So if you consider it from a $ revenue per day: > - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m > per day ($4,000 x 360) > - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or $1.44m > per day ($1,000 x 1,440) > > In the above case, the revenue stream of both coins is equal, at $1.44m > per day. So even though one coin is priced higher, it doesn?t mean miners > will necessarily choose that chain to mine. > > Am I missing something? > > > Kind regards, > -Erik Voorhees > CEO ShapeShift AG > > On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( > bitcoin-segwit2x at lists.linuxfoundation.org) wrote: > > > > On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Miners need to move their funds into exchanges to sell them. If they >> can't deposit coins to an exchange, they become valueless. >> >> Assuming an 80-20 split, Block times for the minority chain spike to >> ~49.3 minutes and will remain that long for ~69 days. This would >> effectively block the minority chain's functionality as a payment system, >> as it will become increasingly impossible to deposit funds, or move them >> between exchanges (assuming transaction demand remains linear). Miners can >> prioritize their own transactions in blocks, but regular customers will be >> left out to dry. >> >> I don't anyone should under-estimate the negative effects of this on >> market participants. >> >> A lot of us have customers who expect bitcoin to just "work". If we start >> telling them they can't spend their money for several days/weeks, the >> choice of which chain is viable will quickly become clear. It will be >> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >> altogether. >> >> (To be clear, Bitaccess is neutral on this fork, we just want customers >> to remain happy. They way this is going, that doesn't seem to be a likely >> outcome) >> > > What typically happens is (shock horror) miners will mine in self > interest. If you consider mining as a commodity, it makes sense that > they'll just go for the most profitable coin, and not act altruistically, > which was suggested in the original white paper. > > Mining is therefore common is a 0% / 100% until fees for a block make it > profitable to mine that block (cab take several days) or the difficulty > adjusts the profitability. > > This phenomenon is often referred to as "feast and famine". > > Given the market is showing that the 2x coin will be valued under 20% of > bitcoin, miners acting in self interest will mine bitcoin and the 2x chain > will freeze up, requiring subsidy to mine. Such subsidies could be added > by creating a few transactions with high mining fees. > >> >> >> -- >> *Moe Adham, MSc, BEng **|* Co-Founder >> >> *bitaccess.co * >> Cell: *+1 858 877 3420 <(858)%20877-3420>* >> >> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> It is at this point that common sense needs to be applied. Even the most >>> ardent anti SegWit2x upgrade individual would snap up the ?airdrop? should >>> there be 2 viable chains post Nov HF. That in itself is demand enough to >>> have a market for both tokens. The flip side is that with an unusable >>> chain, it matters not whether exchanges respond to user requests for >>> listing as you won?t be able to move your tokens anyway. >>> >>> >>> >>> *From:* Samuel Reed via Bitcoin-segwit2x >>> >>> *Sent:* 24 October 2017 16:31 >>> *To:* Peter >>> *Cc:* Bitcoin Segwit2x >>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >>> guarantee) - Ensuring a smooth 2X upgrade without a chain split >>> >>> >>> >>> Another lesson to be learned from BCH is that incentives matter - where >>> miners can sell coins depends on markets, and market prices depend on user >>> and exchange support. Even if the 80% of miners signaling 2x at this time >>> choose to go forward, if there are not viable markets willing to buy 2x >>> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >>> >>> Peter wrote: >>> >>> >>> >>> >>> >>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>> >RP that encourages a network split would render the NYA voidable >>> >>> Phillip, if there is consensus on one thing, it is there is going to be >>> a network split. Every exchange is publishing policies for the chain split. >>> Some even saying that they will not support the segwit2x token. >>> >>> -Chris >>> >>> >>> >>> The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing >>> any exchange (or custodian) said mattered. Indeed because significant >>> sha256 hashpower was deployed towards the fork it gained value and >>> customers of exchanges pressured the exchanges into the financially >>> sensible decision. >>> >>> >>> >>> This proposal, SegWit2x, is for the miners to decide. >>> >>> >>> >>> Transaction selection is not a consensus rule. Any miners that want to >>> go against the Nakamoto signaling is free to do so and the responsible >>> party (not the 2x devs who have no control over transaction selection). If >>> because of the political climate some miner sees an economic opportunity to >>> resurrect the legacy chain then they can modify their node (without >>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>> found in the 2x chain. >>> >>> >>> >>> Additionally, to complete a safe chain resurrection such a miner can >>> airdrop the mining reward from the forked block (after 100 depth) and send >>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>> simple splitting solution. >>> >>> >>> >>> Safety efforts which do not require consensus changes should be >>> exhausted first before suggesting consensus changes. >>> >>> >>> >>> Regards >>> >>> Peter >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimmy2991 at icloud.com Tue Oct 24 17:33:20 2017 From: jimmy2991 at icloud.com (James Walton) Date: Tue, 24 Oct 2017 18:33:20 +0100 Subject: [Bitcoin-segwit2x] Bitcoin-segwit2x Digest, Vol 5, Issue 108 In-Reply-To: References: Message-ID: Please unsubscribe me Sent from my iPhone > On 24 Oct 2017, at 18:20, bitcoin-segwit2x-request at lists.linuxfoundation.org wrote: > > Send Bitcoin-segwit2x mailing list submissions to > bitcoin-segwit2x at lists.linuxfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > or, via email, send a message with subject or body 'help' to > bitcoin-segwit2x-request at lists.linuxfoundation.org > > You can reach the person managing the list at > bitcoin-segwit2x-owner at lists.linuxfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Bitcoin-segwit2x digest..." > > > Today's Topics: > > 1. Re: PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - > Ensuring a smooth 2X upgrade without a chain split (David A. Harding) > 2. Re: PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - > Ensuring a smooth 2X upgrade without a chain split (Chris Stewart) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 24 Oct 2017 13:00:27 -0400 > From: "David A. Harding" > To: Erik Voorhees > Cc: Bitcoin-segwit2x > Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, > guarantee) - Ensuring a smooth 2X upgrade without a chain split > Message-ID: <20171024170026.t66rhqbgjq25yh6d at fedora-23-dvm> > Content-Type: text/plain; charset="us-ascii" > >> On Tue, Oct 24, 2017 at 09:27:37AM -0700, Erik Voorhees via Bitcoin-segwit2x wrote: >> So if you consider it from a $ revenue per day: >> - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m per >> day ($4,000 x 360) >> - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or $1.44m >> per day ($1,000 x 1,440) >> >> Am I missing something? > > Umm, yeah. 2x did four times as much work to make the same amount of > money as 1x. By, "work", I of course mean that they expended four times > as much electricity and tied up four times as much capital equipment. > > Maybe this isn't obvious since you're treating 1x miners and 2x miners > as a group, but if you consider them as individual miners, it becomes > clear that there's a strong incentive to defect to the more profitable > chain. For example: > > Average daily blocks | 1x potential revenue | 2x potential revenue > -------+----------------------+-----------------------+----------------------- > Alice | 5 | 5*12.5*4000 = 250k | 5*12.5*1000 = 62.5k > Bob | 10 | 10*12.5*4000 = 500k | 10*12.5*1000 = 125.0k > Chalie | 25 | 25*12.5*4000 = 1,500k | 25*12.5*1000 = 312.5k > > You can replace "average daily blocks" with "kiloWatt hours (kWh) plus > capital equipment depreciation costs" for a difficulty-neutral factor. > > -Dave > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 819 bytes > Desc: not available > URL: > > ------------------------------ > > Message: 2 > Date: Tue, 24 Oct 2017 12:11:41 -0500 > From: Chris Stewart > To: Erik Voorhees > Cc: Melvin Carvalho via Bitcoin-segwit2x > > Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, > guarantee) - Ensuring a smooth 2X upgrade without a chain split > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Don't forget about transaction fees. If blocks are slower on bitcoin, an > auction effectively starts on block space. If the economic majority is > still using the bitcoin blockchain, while the majority of miners are mining > the segwit2x chain we will see a large backlog that causes tx fees to > increase in price. The bitcoin blockchain miners will make a killing in > collecting those fees while segwit2x miners (if the economic majority stays > with bitcoin) will miss out on them. > > -Chris > > On Tue, Oct 24, 2017 at 11:27 AM, Erik Voorhees via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> I have a question for the group... >> >> >> "Given the market is showing that the 2x coin will be valued under 20% of >> bitcoin, miners acting in self interest will mine bitcoin and the 2x chain >> will freeze up, requiring subsidy to mine.? - Mo Adham >> >> -Let?s assume, immediately following the fork, 1x has 20% of hash power, >> and 2x has 80% (as indicated by miner signaling) >> -Let?s assume also that the price, immediately following the fork, 1x is >> $4,000 and 2x is $1,000 (as indicated by futures) >> >> Most people see the above and think, ?okay, soon after the fork the miners >> will switch back to 1x because price is higher.? >> >> But, is it not the case that while price might be higher, block times are >> lower. So if you consider it from a $ revenue per day: >> - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m >> per day ($4,000 x 360) >> - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or $1.44m >> per day ($1,000 x 1,440) >> >> In the above case, the revenue stream of both coins is equal, at $1.44m >> per day. So even though one coin is priced higher, it doesn?t mean miners >> will necessarily choose that chain to mine. >> >> Am I missing something? >> >> >> Kind regards, >> -Erik Voorhees >> CEO ShapeShift AG >> >> On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( >> bitcoin-segwit2x at lists.linuxfoundation.org) wrote: >> >> >> >> On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> Miners need to move their funds into exchanges to sell them. If they >>> can't deposit coins to an exchange, they become valueless. >>> >>> Assuming an 80-20 split, Block times for the minority chain spike to >>> ~49.3 minutes and will remain that long for ~69 days. This would >>> effectively block the minority chain's functionality as a payment system, >>> as it will become increasingly impossible to deposit funds, or move them >>> between exchanges (assuming transaction demand remains linear). Miners can >>> prioritize their own transactions in blocks, but regular customers will be >>> left out to dry. >>> >>> I don't anyone should under-estimate the negative effects of this on >>> market participants. >>> >>> A lot of us have customers who expect bitcoin to just "work". If we start >>> telling them they can't spend their money for several days/weeks, the >>> choice of which chain is viable will quickly become clear. It will be >>> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >>> altogether. >>> >>> (To be clear, Bitaccess is neutral on this fork, we just want customers >>> to remain happy. They way this is going, that doesn't seem to be a likely >>> outcome) >>> >> >> What typically happens is (shock horror) miners will mine in self >> interest. If you consider mining as a commodity, it makes sense that >> they'll just go for the most profitable coin, and not act altruistically, >> which was suggested in the original white paper. >> >> Mining is therefore common is a 0% / 100% until fees for a block make it >> profitable to mine that block (cab take several days) or the difficulty >> adjusts the profitability. >> >> This phenomenon is often referred to as "feast and famine". >> >> Given the market is showing that the 2x coin will be valued under 20% of >> bitcoin, miners acting in self interest will mine bitcoin and the 2x chain >> will freeze up, requiring subsidy to mine. Such subsidies could be added >> by creating a few transactions with high mining fees. >> >>> >>> >>> -- >>> *Moe Adham, MSc, BEng **|* Co-Founder >>> >>> *bitaccess.co * >>> Cell: *+1 858 877 3420 <(858)%20877-3420>* >>> >>> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> It is at this point that common sense needs to be applied. Even the most >>>> ardent anti SegWit2x upgrade individual would snap up the ?airdrop? should >>>> there be 2 viable chains post Nov HF. That in itself is demand enough to >>>> have a market for both tokens. The flip side is that with an unusable >>>> chain, it matters not whether exchanges respond to user requests for >>>> listing as you won?t be able to move your tokens anyway. >>>> >>>> >>>> >>>> *From:* Samuel Reed via Bitcoin-segwit2x >>>> >>>> *Sent:* 24 October 2017 16:31 >>>> *To:* Peter >>>> *Cc:* Bitcoin Segwit2x >>>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >>>> guarantee) - Ensuring a smooth 2X upgrade without a chain split >>>> >>>> >>>> >>>> Another lesson to be learned from BCH is that incentives matter - where >>>> miners can sell coins depends on markets, and market prices depend on user >>>> and exchange support. Even if the 80% of miners signaling 2x at this time >>>> choose to go forward, if there are not viable markets willing to buy 2x >>>> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >>>> >>>> Peter wrote: >>>> >>>> >>>> >>>> >>>> >>>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>>> RP that encourages a network split would render the NYA voidable >>>> >>>> Phillip, if there is consensus on one thing, it is there is going to be >>>> a network split. Every exchange is publishing policies for the chain split. >>>> Some even saying that they will not support the segwit2x token. >>>> >>>> -Chris >>>> >>>> >>>> >>>> The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing >>>> any exchange (or custodian) said mattered. Indeed because significant >>>> sha256 hashpower was deployed towards the fork it gained value and >>>> customers of exchanges pressured the exchanges into the financially >>>> sensible decision. >>>> >>>> >>>> >>>> This proposal, SegWit2x, is for the miners to decide. >>>> >>>> >>>> >>>> Transaction selection is not a consensus rule. Any miners that want to >>>> go against the Nakamoto signaling is free to do so and the responsible >>>> party (not the 2x devs who have no control over transaction selection). If >>>> because of the political climate some miner sees an economic opportunity to >>>> resurrect the legacy chain then they can modify their node (without >>>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>>> found in the 2x chain. >>>> >>>> >>>> >>>> Additionally, to complete a safe chain resurrection such a miner can >>>> airdrop the mining reward from the forked block (after 100 depth) and send >>>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>>> simple splitting solution. >>>> >>>> >>>> >>>> Safety efforts which do not require consensus changes should be >>>> exhausted first before suggesting consensus changes. >>>> >>>> >>>> >>>> Regards >>>> >>>> Peter >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > End of Bitcoin-segwit2x Digest, Vol 5, Issue 108 > ************************************************ From djpnewton at gmail.com Tue Oct 24 17:38:25 2017 From: djpnewton at gmail.com (Daniel Newton) Date: Wed, 25 Oct 2017 06:38:25 +1300 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: > Am I missing something? Yes the miners as a group have the possibility of all mining the original chain for $7,200,000 (144 * 12.5 * $4000) + fees per day... A large opportunity cost On 25/10/2017 5:27 AM, "Erik Voorhees via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > I have a question for the group... > > > "Given the market is showing that the 2x coin will be valued under 20% of > bitcoin, miners acting in self interest will mine bitcoin and the 2x chain > will freeze up, requiring subsidy to mine.? - Mo Adham > > -Let?s assume, immediately following the fork, 1x has 20% of hash power, > and 2x has 80% (as indicated by miner signaling) > -Let?s assume also that the price, immediately following the fork, 1x is > $4,000 and 2x is $1,000 (as indicated by futures) > > Most people see the above and think, ?okay, soon after the fork the miners > will switch back to 1x because price is higher.? > > But, is it not the case that while price might be higher, block times are > lower. So if you consider it from a $ revenue per day: > - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m > per day ($4,000 x 360) > - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or $1.44m > per day ($1,000 x 1,440) > > In the above case, the revenue stream of both coins is equal, at $1.44m > per day. So even though one coin is priced higher, it doesn?t mean miners > will necessarily choose that chain to mine. > > Am I missing something? > > > Kind regards, > -Erik Voorhees > CEO ShapeShift AG > > On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( > bitcoin-segwit2x at lists.linuxfoundation.org) wrote: > > > > On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Miners need to move their funds into exchanges to sell them. If they >> can't deposit coins to an exchange, they become valueless. >> >> Assuming an 80-20 split, Block times for the minority chain spike to >> ~49.3 minutes and will remain that long for ~69 days. This would >> effectively block the minority chain's functionality as a payment system, >> as it will become increasingly impossible to deposit funds, or move them >> between exchanges (assuming transaction demand remains linear). Miners can >> prioritize their own transactions in blocks, but regular customers will be >> left out to dry. >> >> I don't anyone should under-estimate the negative effects of this on >> market participants. >> >> A lot of us have customers who expect bitcoin to just "work". If we start >> telling them they can't spend their money for several days/weeks, the >> choice of which chain is viable will quickly become clear. It will be >> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >> altogether. >> >> (To be clear, Bitaccess is neutral on this fork, we just want customers >> to remain happy. They way this is going, that doesn't seem to be a likely >> outcome) >> > > What typically happens is (shock horror) miners will mine in self > interest. If you consider mining as a commodity, it makes sense that > they'll just go for the most profitable coin, and not act altruistically, > which was suggested in the original white paper. > > Mining is therefore common is a 0% / 100% until fees for a block make it > profitable to mine that block (cab take several days) or the difficulty > adjusts the profitability. > > This phenomenon is often referred to as "feast and famine". > > Given the market is showing that the 2x coin will be valued under 20% of > bitcoin, miners acting in self interest will mine bitcoin and the 2x chain > will freeze up, requiring subsidy to mine. Such subsidies could be added > by creating a few transactions with high mining fees. > >> >> >> -- >> *Moe Adham, MSc, BEng **|* Co-Founder >> >> *bitaccess.co * >> Cell: *+1 858 877 3420 <(858)%20877-3420>* >> >> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> It is at this point that common sense needs to be applied. Even the most >>> ardent anti SegWit2x upgrade individual would snap up the ?airdrop? should >>> there be 2 viable chains post Nov HF. That in itself is demand enough to >>> have a market for both tokens. The flip side is that with an unusable >>> chain, it matters not whether exchanges respond to user requests for >>> listing as you won?t be able to move your tokens anyway. >>> >>> >>> >>> *From:* Samuel Reed via Bitcoin-segwit2x >>> >>> *Sent:* 24 October 2017 16:31 >>> *To:* Peter >>> *Cc:* Bitcoin Segwit2x >>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >>> guarantee) - Ensuring a smooth 2X upgrade without a chain split >>> >>> >>> >>> Another lesson to be learned from BCH is that incentives matter - where >>> miners can sell coins depends on markets, and market prices depend on user >>> and exchange support. Even if the 80% of miners signaling 2x at this time >>> choose to go forward, if there are not viable markets willing to buy 2x >>> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >>> >>> Peter wrote: >>> >>> >>> >>> >>> >>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>> >RP that encourages a network split would render the NYA voidable >>> >>> Phillip, if there is consensus on one thing, it is there is going to be >>> a network split. Every exchange is publishing policies for the chain split. >>> Some even saying that they will not support the segwit2x token. >>> >>> -Chris >>> >>> >>> >>> The technical lesson from the BCH fork was that 1 hash = 1 vote. Nothing >>> any exchange (or custodian) said mattered. Indeed because significant >>> sha256 hashpower was deployed towards the fork it gained value and >>> customers of exchanges pressured the exchanges into the financially >>> sensible decision. >>> >>> >>> >>> This proposal, SegWit2x, is for the miners to decide. >>> >>> >>> >>> Transaction selection is not a consensus rule. Any miners that want to >>> go against the Nakamoto signaling is free to do so and the responsible >>> party (not the 2x devs who have no control over transaction selection). If >>> because of the political climate some miner sees an economic opportunity to >>> resurrect the legacy chain then they can modify their node (without >>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>> found in the 2x chain. >>> >>> >>> >>> Additionally, to complete a safe chain resurrection such a miner can >>> airdrop the mining reward from the forked block (after 100 depth) and send >>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>> simple splitting solution. >>> >>> >>> >>> Safety efforts which do not require consensus changes should be >>> exhausted first before suggesting consensus changes. >>> >>> >>> >>> Regards >>> >>> Peter >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voisine at gmail.com Tue Oct 24 17:44:33 2017 From: voisine at gmail.com (Aaron Voisine) Date: Tue, 24 Oct 2017 17:44:33 +0000 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: Indeed, the miners can?t go against the economic majority. If the 2x chain doesn?t have it, it will quickly die. If the 1x doesn?t have it, it will quickly die. Re: Erik, miners act individually, so until the difficulty adjusts, they will make more money from block rewards on the chain with the higher market price. The difficulty will be identical on both sides to start, so the same hashing power will yield the same reward in coins on either chain. The more valuable coin then gives the larger reward. As far as fees, without replay protection, the same tx can (usually) be mined on either side, so again the most valuable coin gives the greater reward. The minority chain will quickly grind to a halt. Aaron On Tue, Oct 24, 2017 at 10:20 AM Chris Stewart via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Don't forget about transaction fees. If blocks are slower on bitcoin, an > auction effectively starts on block space. If the economic majority is > still using the bitcoin blockchain, while the majority of miners are mining > the segwit2x chain we will see a large backlog that causes tx fees to > increase in price. The bitcoin blockchain miners will make a killing in > collecting those fees while segwit2x miners (if the economic majority stays > with bitcoin) will miss out on them. > > -Chris > > On Tue, Oct 24, 2017 at 11:27 AM, Erik Voorhees via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> I have a question for the group... >> >> >> "Given the market is showing that the 2x coin will be valued under 20% >> of bitcoin, miners acting in self interest will mine bitcoin and the 2x >> chain will freeze up, requiring subsidy to mine.? - Mo Adham >> >> -Let?s assume, immediately following the fork, 1x has 20% of hash power, >> and 2x has 80% (as indicated by miner signaling) >> -Let?s assume also that the price, immediately following the fork, 1x is >> $4,000 and 2x is $1,000 (as indicated by futures) >> >> Most people see the above and think, ?okay, soon after the fork the >> miners will switch back to 1x because price is higher.? >> >> But, is it not the case that while price might be higher, block times are >> lower. So if you consider it from a $ revenue per day: >> - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m >> per day ($4,000 x 360) >> - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or >> $1.44m per day ($1,000 x 1,440) >> >> In the above case, the revenue stream of both coins is equal, at $1.44m >> per day. So even though one coin is priced higher, it doesn?t mean miners >> will necessarily choose that chain to mine. >> >> Am I missing something? >> >> >> Kind regards, >> -Erik Voorhees >> CEO ShapeShift AG >> >> On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( >> bitcoin-segwit2x at lists.linuxfoundation.org) wrote: >> >> >> >> On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> Miners need to move their funds into exchanges to sell them. If they >>> can't deposit coins to an exchange, they become valueless. >>> >>> Assuming an 80-20 split, Block times for the minority chain spike to >>> ~49.3 minutes and will remain that long for ~69 days. This would >>> effectively block the minority chain's functionality as a payment system, >>> as it will become increasingly impossible to deposit funds, or move them >>> between exchanges (assuming transaction demand remains linear). Miners can >>> prioritize their own transactions in blocks, but regular customers will be >>> left out to dry. >>> >>> I don't anyone should under-estimate the negative effects of this on >>> market participants. >>> >>> A lot of us have customers who expect bitcoin to just "work". If we >>> start telling them they can't spend their money for several days/weeks, the >>> choice of which chain is viable will quickly become clear. It will be >>> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >>> altogether. >>> >>> (To be clear, Bitaccess is neutral on this fork, we just want customers >>> to remain happy. They way this is going, that doesn't seem to be a likely >>> outcome) >>> >> >> What typically happens is (shock horror) miners will mine in self >> interest. If you consider mining as a commodity, it makes sense that >> they'll just go for the most profitable coin, and not act altruistically, >> which was suggested in the original white paper. >> >> Mining is therefore common is a 0% / 100% until fees for a block make it >> profitable to mine that block (cab take several days) or the difficulty >> adjusts the profitability. >> >> This phenomenon is often referred to as "feast and famine". >> >> Given the market is showing that the 2x coin will be valued under 20% of >> bitcoin, miners acting in self interest will mine bitcoin and the 2x chain >> will freeze up, requiring subsidy to mine. Such subsidies could be added >> by creating a few transactions with high mining fees. >> >>> >>> >>> -- >>> *Moe Adham, MSc, BEng **|* Co-Founder >>> >>> *bitaccess.co * >>> Cell: *+1 858 877 3420 <(858)%20877-3420>* >>> >>> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> It is at this point that common sense needs to be applied. Even the >>>> most ardent anti SegWit2x upgrade individual would snap up the ?airdrop? >>>> should there be 2 viable chains post Nov HF. That in itself is demand >>>> enough to have a market for both tokens. The flip side is that with an >>>> unusable chain, it matters not whether exchanges respond to user requests >>>> for listing as you won?t be able to move your tokens anyway. >>>> >>>> >>>> >>>> *From:* Samuel Reed via Bitcoin-segwit2x >>>> >>>> *Sent:* 24 October 2017 16:31 >>>> *To:* Peter >>>> *Cc:* Bitcoin Segwit2x >>>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >>>> guarantee) - Ensuring a smooth 2X upgrade without a chain split >>>> >>>> >>>> >>>> Another lesson to be learned from BCH is that incentives matter - where >>>> miners can sell coins depends on markets, and market prices depend on user >>>> and exchange support. Even if the 80% of miners signaling 2x at this time >>>> choose to go forward, if there are not viable markets willing to buy 2x >>>> coins at near 1x prices, 2x hash power will quickly revert to the old chain. >>>> >>>> Peter wrote: >>>> >>>> >>>> >>>> >>>> >>>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>> >RP that encourages a network split would render the NYA voidable >>>> >>>> Phillip, if there is consensus on one thing, it is there is going to be >>>> a network split. Every exchange is publishing policies for the chain split. >>>> Some even saying that they will not support the segwit2x token. >>>> >>>> -Chris >>>> >>>> >>>> >>>> The technical lesson from the BCH fork was that 1 hash = 1 vote. >>>> Nothing any exchange (or custodian) said mattered. Indeed because >>>> significant sha256 hashpower was deployed towards the fork it gained value >>>> and customers of exchanges pressured the exchanges into the financially >>>> sensible decision. >>>> >>>> >>>> >>>> This proposal, SegWit2x, is for the miners to decide. >>>> >>>> >>>> >>>> Transaction selection is not a consensus rule. Any miners that want to >>>> go against the Nakamoto signaling is free to do so and the responsible >>>> party (not the 2x devs who have no control over transaction selection). If >>>> because of the political climate some miner sees an economic opportunity to >>>> resurrect the legacy chain then they can modify their node (without >>>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>>> found in the 2x chain. >>>> >>>> >>>> >>>> Additionally, to complete a safe chain resurrection such a miner can >>>> airdrop the mining reward from the forked block (after 100 depth) and send >>>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>>> simple splitting solution. >>>> >>>> >>>> >>>> Safety efforts which do not require consensus changes should be >>>> exhausted first before suggesting consensus changes. >>>> >>>> >>>> >>>> Regards >>>> >>>> Peter >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- Aaron Voisine co-founder and CEO breadwallet.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Tue Oct 24 18:39:44 2017 From: bitpico at icloud.com (bitPico) Date: Tue, 24 Oct 2017 14:39:44 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <3554E58F-588C-4D0B-B642-72B7162DA6E3@bitso.com> Message-ID: <178F6261-3954-4AC9-B62C-2ED2C809B9DE@icloud.com> This is a technical discussion list not for Speculation or Market chit-chat. If you don?t have a time machine then you can unsubscribe, become unsubscribed or refrain from posting Speculative posts. Sent from my Space Ship > On Oct 24, 2017, at 10:26 AM, Phillip Katete via Bitcoin-segwit2x wrote: > > There are going to be 2 chains ? there is NO speculation in this, -------------- next part -------------- An HTML attachment was scrubbed... URL: From dizzle at pointbiz.com Tue Oct 24 18:59:26 2017 From: dizzle at pointbiz.com (Peter) Date: Tue, 24 Oct 2017 14:59:26 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: I agree the minority chain will quickly grind to a halt. Pure SPV users will just want Bitcoin to work as Moe indicated. They won't know if they are on the 1x or 2x chain but what they will know is Bitcoin (BTC) still works and in 1 day 2x (BTC) will pass 100 blocks and have a market price and be usable by exchanges globally. The 1x chain will not have a market price for 5 days because it didn't reach the 100 block milestone to enable deposits and coin splitting. In that time it can die out. Also, it's likely to take an extra week or so for exchanges to get all their coin splitting transactions confirmed by mixing with 1x coinbases. Honeybadger won't care much and people won't want to say 1x is BTC because then they have to admit BTC had a 1 or 2 week service interruption. Sorry if this is not technical enough for the list. Regards Peter On Oct 24, 2017 1:44 PM, "Aaron Voisine via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Indeed, the miners can?t go against the economic majority. If the 2x chain > doesn?t have it, it will quickly die. If the 1x doesn?t have it, it will > quickly die. > > Re: Erik, miners act individually, so until the difficulty adjusts, they > will make more money from block rewards on the chain with the higher market > price. The difficulty will be identical on both sides to start, so the same > hashing power will yield the same reward in coins on either chain. The more > valuable coin then gives the larger reward. > > As far as fees, without replay protection, the same tx can (usually) be > mined on either side, so again the most valuable coin gives the greater > reward. > > The minority chain will quickly grind to a halt. > > Aaron > > On Tue, Oct 24, 2017 at 10:20 AM Chris Stewart via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Don't forget about transaction fees. If blocks are slower on bitcoin, an >> auction effectively starts on block space. If the economic majority is >> still using the bitcoin blockchain, while the majority of miners are mining >> the segwit2x chain we will see a large backlog that causes tx fees to >> increase in price. The bitcoin blockchain miners will make a killing in >> collecting those fees while segwit2x miners (if the economic majority stays >> with bitcoin) will miss out on them. >> >> -Chris >> >> On Tue, Oct 24, 2017 at 11:27 AM, Erik Voorhees via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> I have a question for the group... >>> >>> >>> "Given the market is showing that the 2x coin will be valued under 20% >>> of bitcoin, miners acting in self interest will mine bitcoin and the 2x >>> chain will freeze up, requiring subsidy to mine.? - Mo Adham >>> >>> -Let?s assume, immediately following the fork, 1x has 20% of hash power, >>> and 2x has 80% (as indicated by miner signaling) >>> -Let?s assume also that the price, immediately following the fork, 1x is >>> $4,000 and 2x is $1,000 (as indicated by futures) >>> >>> Most people see the above and think, ?okay, soon after the fork the >>> miners will switch back to 1x because price is higher.? >>> >>> But, is it not the case that while price might be higher, block times >>> are lower. So if you consider it from a $ revenue per day: >>> - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m >>> per day ($4,000 x 360) >>> - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or >>> $1.44m per day ($1,000 x 1,440) >>> >>> In the above case, the revenue stream of both coins is equal, at $1.44m >>> per day. So even though one coin is priced higher, it doesn?t mean miners >>> will necessarily choose that chain to mine. >>> >>> Am I missing something? >>> >>> >>> Kind regards, >>> -Erik Voorhees >>> CEO ShapeShift AG >>> >>> On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( >>> bitcoin-segwit2x at lists.linuxfoundation.org) wrote: >>> >>> >>> >>> On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> Miners need to move their funds into exchanges to sell them. If they >>>> can't deposit coins to an exchange, they become valueless. >>>> >>>> Assuming an 80-20 split, Block times for the minority chain spike to >>>> ~49.3 minutes and will remain that long for ~69 days. This would >>>> effectively block the minority chain's functionality as a payment system, >>>> as it will become increasingly impossible to deposit funds, or move them >>>> between exchanges (assuming transaction demand remains linear). Miners can >>>> prioritize their own transactions in blocks, but regular customers will be >>>> left out to dry. >>>> >>>> I don't anyone should under-estimate the negative effects of this on >>>> market participants. >>>> >>>> A lot of us have customers who expect bitcoin to just "work". If we >>>> start telling them they can't spend their money for several days/weeks, the >>>> choice of which chain is viable will quickly become clear. It will be >>>> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >>>> altogether. >>>> >>>> (To be clear, Bitaccess is neutral on this fork, we just want customers >>>> to remain happy. They way this is going, that doesn't seem to be a likely >>>> outcome) >>>> >>> >>> What typically happens is (shock horror) miners will mine in self >>> interest. If you consider mining as a commodity, it makes sense that >>> they'll just go for the most profitable coin, and not act altruistically, >>> which was suggested in the original white paper. >>> >>> Mining is therefore common is a 0% / 100% until fees for a block make it >>> profitable to mine that block (cab take several days) or the difficulty >>> adjusts the profitability. >>> >>> This phenomenon is often referred to as "feast and famine". >>> >>> Given the market is showing that the 2x coin will be valued under 20% of >>> bitcoin, miners acting in self interest will mine bitcoin and the 2x chain >>> will freeze up, requiring subsidy to mine. Such subsidies could be added >>> by creating a few transactions with high mining fees. >>> >>>> >>>> >>>> -- >>>> *Moe Adham, MSc, BEng **|* Co-Founder >>>> >>>> *bitaccess.co * >>>> Cell: *+1 858 877 3420 <(858)%20877-3420>* >>>> >>>> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>>> It is at this point that common sense needs to be applied. Even the >>>>> most ardent anti SegWit2x upgrade individual would snap up the ?airdrop? >>>>> should there be 2 viable chains post Nov HF. That in itself is demand >>>>> enough to have a market for both tokens. The flip side is that with an >>>>> unusable chain, it matters not whether exchanges respond to user requests >>>>> for listing as you won?t be able to move your tokens anyway. >>>>> >>>>> >>>>> >>>>> *From:* Samuel Reed via Bitcoin-segwit2x >>>>> >>>>> *Sent:* 24 October 2017 16:31 >>>>> *To:* Peter >>>>> *Cc:* Bitcoin Segwit2x >>>>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero >>>>> replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split >>>>> >>>>> >>>>> >>>>> Another lesson to be learned from BCH is that incentives matter - >>>>> where miners can sell coins depends on markets, and market prices depend on >>>>> user and exchange support. Even if the 80% of miners signaling 2x at this >>>>> time choose to go forward, if there are not viable markets willing to buy >>>>> 2x coins at near 1x prices, 2x hash power will quickly revert to the old >>>>> chain. >>>>> >>>>> Peter wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>>> >>>>> >RP that encourages a network split would render the NYA voidable >>>>> >>>>> Phillip, if there is consensus on one thing, it is there is going to >>>>> be a network split. Every exchange is publishing policies for the chain >>>>> split. Some even saying that they will not support the segwit2x token. >>>>> >>>>> -Chris >>>>> >>>>> >>>>> >>>>> The technical lesson from the BCH fork was that 1 hash = 1 vote. >>>>> Nothing any exchange (or custodian) said mattered. Indeed because >>>>> significant sha256 hashpower was deployed towards the fork it gained value >>>>> and customers of exchanges pressured the exchanges into the financially >>>>> sensible decision. >>>>> >>>>> >>>>> >>>>> This proposal, SegWit2x, is for the miners to decide. >>>>> >>>>> >>>>> >>>>> Transaction selection is not a consensus rule. Any miners that want to >>>>> go against the Nakamoto signaling is free to do so and the responsible >>>>> party (not the 2x devs who have no control over transaction selection). If >>>>> because of the political climate some miner sees an economic opportunity to >>>>> resurrect the legacy chain then they can modify their node (without >>>>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>>>> found in the 2x chain. >>>>> >>>>> >>>>> >>>>> Additionally, to complete a safe chain resurrection such a miner can >>>>> airdrop the mining reward from the forked block (after 100 depth) and send >>>>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>>>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>>>> simple splitting solution. >>>>> >>>>> >>>>> >>>>> Safety efforts which do not require consensus changes should be >>>>> exhausted first before suggesting consensus changes. >>>>> >>>>> >>>>> >>>>> Regards >>>>> >>>>> Peter >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > -- > Aaron Voisine > co-founder and CEO > breadwallet.com > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at shapeshift.io Tue Oct 24 19:04:53 2017 From: erik at shapeshift.io (Erik Voorhees) Date: Tue, 24 Oct 2017 15:04:53 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: Peter - I disagree that 1x won?t have a market price. Exchanges can turn off all deposits and withdraws completely for a week and you?ll still see markets of both coins working, because there is already 1x and 2x in the exchanges (in large quantities). Kind regards, -Erik Voorhees CEO ShapeShift AG On October 24, 2017 at 12:59:28 PM, Peter (dizzle at pointbiz.com) wrote: I agree the minority chain will quickly grind to a halt. Pure SPV users will just want Bitcoin to work as Moe indicated. They won't know if they are on the 1x or 2x chain but what they will know is Bitcoin (BTC) still works and in 1 day 2x (BTC) will pass 100 blocks and have a market price and be usable by exchanges globally. The 1x chain will not have a market price for 5 days because it didn't reach the 100 block milestone to enable deposits and coin splitting. In that time it can die out. Also, it's likely to take an extra week or so for exchanges to get all their coin splitting transactions confirmed by mixing with 1x coinbases. Honeybadger won't care much and people won't want to say 1x is BTC because then they have to admit BTC had a 1 or 2 week service interruption. Sorry if this is not technical enough for the list. Regards Peter On Oct 24, 2017 1:44 PM, "Aaron Voisine via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Indeed, the miners can?t go against the economic majority. If the 2x chain > doesn?t have it, it will quickly die. If the 1x doesn?t have it, it will > quickly die. > > Re: Erik, miners act individually, so until the difficulty adjusts, they > will make more money from block rewards on the chain with the higher market > price. The difficulty will be identical on both sides to start, so the same > hashing power will yield the same reward in coins on either chain. The more > valuable coin then gives the larger reward. > > As far as fees, without replay protection, the same tx can (usually) be > mined on either side, so again the most valuable coin gives the greater > reward. > > The minority chain will quickly grind to a halt. > > Aaron > > On Tue, Oct 24, 2017 at 10:20 AM Chris Stewart via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Don't forget about transaction fees. If blocks are slower on bitcoin, an >> auction effectively starts on block space. If the economic majority is >> still using the bitcoin blockchain, while the majority of miners are mining >> the segwit2x chain we will see a large backlog that causes tx fees to >> increase in price. The bitcoin blockchain miners will make a killing in >> collecting those fees while segwit2x miners (if the economic majority stays >> with bitcoin) will miss out on them. >> >> -Chris >> >> On Tue, Oct 24, 2017 at 11:27 AM, Erik Voorhees via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> I have a question for the group... >>> >>> >>> "Given the market is showing that the 2x coin will be valued under 20% >>> of bitcoin, miners acting in self interest will mine bitcoin and the 2x >>> chain will freeze up, requiring subsidy to mine.? - Mo Adham >>> >>> -Let?s assume, immediately following the fork, 1x has 20% of hash power, >>> and 2x has 80% (as indicated by miner signaling) >>> -Let?s assume also that the price, immediately following the fork, 1x is >>> $4,000 and 2x is $1,000 (as indicated by futures) >>> >>> Most people see the above and think, ?okay, soon after the fork the >>> miners will switch back to 1x because price is higher.? >>> >>> But, is it not the case that while price might be higher, block times >>> are lower. So if you consider it from a $ revenue per day: >>> - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m >>> per day ($4,000 x 360) >>> - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or >>> $1.44m per day ($1,000 x 1,440) >>> >>> In the above case, the revenue stream of both coins is equal, at $1.44m >>> per day. So even though one coin is priced higher, it doesn?t mean miners >>> will necessarily choose that chain to mine. >>> >>> Am I missing something? >>> >>> >>> Kind regards, >>> -Erik Voorhees >>> CEO ShapeShift AG >>> >>> On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via Bitcoin-segwit2x ( >>> bitcoin-segwit2x at lists.linuxfoundation.org) wrote: >>> >>> >>> >>> On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> Miners need to move their funds into exchanges to sell them. If they >>>> can't deposit coins to an exchange, they become valueless. >>>> >>>> Assuming an 80-20 split, Block times for the minority chain spike to >>>> ~49.3 minutes and will remain that long for ~69 days. This would >>>> effectively block the minority chain's functionality as a payment system, >>>> as it will become increasingly impossible to deposit funds, or move them >>>> between exchanges (assuming transaction demand remains linear). Miners can >>>> prioritize their own transactions in blocks, but regular customers will be >>>> left out to dry. >>>> >>>> I don't anyone should under-estimate the negative effects of this on >>>> market participants. >>>> >>>> A lot of us have customers who expect bitcoin to just "work". If we >>>> start telling them they can't spend their money for several days/weeks, the >>>> choice of which chain is viable will quickly become clear. It will be >>>> neither Bitcoin1x or Bitcoin2x. It will be a different blockchain >>>> altogether. >>>> >>>> (To be clear, Bitaccess is neutral on this fork, we just want customers >>>> to remain happy. They way this is going, that doesn't seem to be a likely >>>> outcome) >>>> >>> >>> What typically happens is (shock horror) miners will mine in self >>> interest. If you consider mining as a commodity, it makes sense that >>> they'll just go for the most profitable coin, and not act altruistically, >>> which was suggested in the original white paper. >>> >>> Mining is therefore common is a 0% / 100% until fees for a block make it >>> profitable to mine that block (cab take several days) or the difficulty >>> adjusts the profitability. >>> >>> This phenomenon is often referred to as "feast and famine". >>> >>> Given the market is showing that the 2x coin will be valued under 20% of >>> bitcoin, miners acting in self interest will mine bitcoin and the 2x chain >>> will freeze up, requiring subsidy to mine. Such subsidies could be added >>> by creating a few transactions with high mining fees. >>> >>>> >>>> >>>> -- >>>> *Moe Adham, MSc, BEng **|* Co-Founder >>>> >>>> *bitaccess.co * >>>> Cell: *+1 858 877 3420 <(858)%20877-3420>* >>>> >>>> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via Bitcoin-segwit2x < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>>> It is at this point that common sense needs to be applied. Even the >>>>> most ardent anti SegWit2x upgrade individual would snap up the ?airdrop? >>>>> should there be 2 viable chains post Nov HF. That in itself is demand >>>>> enough to have a market for both tokens. The flip side is that with an >>>>> unusable chain, it matters not whether exchanges respond to user requests >>>>> for listing as you won?t be able to move your tokens anyway. >>>>> >>>>> >>>>> >>>>> *From:* Samuel Reed via Bitcoin-segwit2x >>>>> >>>>> *Sent:* 24 October 2017 16:31 >>>>> *To:* Peter >>>>> *Cc:* Bitcoin Segwit2x >>>>> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero >>>>> replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split >>>>> >>>>> >>>>> >>>>> Another lesson to be learned from BCH is that incentives matter - >>>>> where miners can sell coins depends on markets, and market prices depend on >>>>> user and exchange support. Even if the 80% of miners signaling 2x at this >>>>> time choose to go forward, if there are not viable markets willing to buy >>>>> 2x coins at near 1x prices, 2x hash power will quickly revert to the old >>>>> chain. >>>>> >>>>> Peter wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Oct 24, 2017 10:58 AM, "Chris Stewart via Bitcoin-segwit2x" < >>>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>>> >>>>> >RP that encourages a network split would render the NYA voidable >>>>> >>>>> Phillip, if there is consensus on one thing, it is there is going to >>>>> be a network split. Every exchange is publishing policies for the chain >>>>> split. Some even saying that they will not support the segwit2x token. >>>>> >>>>> -Chris >>>>> >>>>> >>>>> >>>>> The technical lesson from the BCH fork was that 1 hash = 1 vote. >>>>> Nothing any exchange (or custodian) said mattered. Indeed because >>>>> significant sha256 hashpower was deployed towards the fork it gained value >>>>> and customers of exchanges pressured the exchanges into the financially >>>>> sensible decision. >>>>> >>>>> >>>>> >>>>> This proposal, SegWit2x, is for the miners to decide. >>>>> >>>>> >>>>> >>>>> Transaction selection is not a consensus rule. Any miners that want to >>>>> go against the Nakamoto signaling is free to do so and the responsible >>>>> party (not the 2x devs who have no control over transaction selection). If >>>>> because of the political climate some miner sees an economic opportunity to >>>>> resurrect the legacy chain then they can modify their node (without >>>>> consensus change) to listen to 2x blocks and not mine any transaction IDs >>>>> found in the 2x chain. >>>>> >>>>> >>>>> >>>>> Additionally, to complete a safe chain resurrection such a miner can >>>>> airdrop the mining reward from the forked block (after 100 depth) and send >>>>> it to to all addresses with UTXOs over $x value. So that users of the 1x >>>>> chain can spend the combined UTXOs which cannot be replayed on 2x, as a >>>>> simple splitting solution. >>>>> >>>>> >>>>> >>>>> Safety efforts which do not require consensus changes should be >>>>> exhausted first before suggesting consensus changes. >>>>> >>>>> >>>>> >>>>> Regards >>>>> >>>>> Peter >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > -- > Aaron Voisine > co-founder and CEO > breadwallet.com > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.eliosoff at gmail.com Tue Oct 24 19:06:32 2017 From: jacob.eliosoff at gmail.com (Jacob Eliosoff) Date: Tue, 24 Oct 2017 15:06:32 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: <178F6261-3954-4AC9-B62C-2ED2C809B9DE@icloud.com> References: <3554E58F-588C-4D0B-B642-72B7162DA6E3@bitso.com> <178F6261-3954-4AC9-B62C-2ED2C809B9DE@icloud.com> Message-ID: I'm against this B0RG proposal. 1. Of course, ceteris paribus we'd all rather end up with one Bitcoin chain than two, or 3-5 or whatever. 2. Like most users, I'd avoid a chain that easily *could* be snuffed out by miners this way, just as I wouldn't use a bike lock known to be easily broken. Using an exploitable system because you trust people not to exploit it is not very Bitcoin - which is exactly why miner support is important. 3. All that said, the reality is both 1x and 2x have many people who want to use them. Those users will reasonably perceive B0RG orphaning as an attack. I say let users have the chain(s) they want, and I do not condone this sort of attack. On Oct 24, 2017 2:41 PM, "bitPico via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > This is a technical discussion list not for Speculation or Market > chit-chat. > > If you don?t have a time machine then you can unsubscribe, become > unsubscribed or refrain from posting Speculative posts. > > Sent from my Space Ship > > On Oct 24, 2017, at 10:26 AM, Phillip Katete via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > > 1. There are going to be 2 chains ? there is NO speculation in this, > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From segwit2x_mailinglist at bitcoinreminder.com Tue Oct 24 19:41:30 2017 From: segwit2x_mailinglist at bitcoinreminder.com (Peter BitcoinReminder.com) Date: Tue, 24 Oct 2017 21:41:30 +0200 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> You are also missing the point that many people dont use bitcoin for payments - but as store of value - so they don?t care if there are long confirmation times (or even none in one week!) - you only see it from the payment/transaction side, but this is not the case for many people which are motivated to stay and fight for bitcoin. Open your mind - there are many people which give a shit about confirmation times and fees. > Am 24.10.2017 um 21:04 schrieb Erik Voorhees via Bitcoin-segwit2x : > > Peter - I disagree that 1x won?t have a market price. Exchanges can turn off all deposits and withdraws completely for a week and you?ll still see markets of both coins working, because there is already 1x and 2x in the exchanges (in large quantities). > > > > Kind regards, > -Erik Voorhees > CEO ShapeShift AG > > On October 24, 2017 at 12:59:28 PM, Peter (dizzle at pointbiz.com ) wrote: > >> I agree the minority chain will quickly grind to a halt. Pure SPV users will just want Bitcoin to work as Moe indicated. They won't know if they are on the 1x or 2x chain but what they will know is Bitcoin (BTC) still works and in 1 day 2x (BTC) will pass 100 blocks and have a market price and be usable by exchanges globally. The 1x chain will not have a market price for 5 days because it didn't reach the 100 block milestone to enable deposits and coin splitting. In that time it can die out. Also, it's likely to take an extra week or so for exchanges to get all their coin splitting transactions confirmed by mixing with 1x coinbases. Honeybadger won't care much and people won't want to say 1x is BTC because then they have to admit BTC had a 1 or 2 week service interruption. >> >> Sorry if this is not technical enough for the list. >> >> Regards >> Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlie at decentral.ca Tue Oct 24 19:55:51 2017 From: charlie at decentral.ca (Charlie Shrem) Date: Tue, 24 Oct 2017 15:55:51 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> Message-ID: ?Peter, that many people dont use bitcoin for payments - but as store of value - so > they don?t care if there are long confirmation times (or even none in one > week!) ?That absolutely makes no logical sense. ?From an economic perspective, the reason Bitcoin is an amazing store of value is because its coupled as a payment system as well. If people cannot spend their Bitcoin when they want, its utility as a store of value will massively decrease. C ?harlie? On Tue, Oct 24, 2017 at 3:41 PM, Peter BitcoinReminder.com via Bitcoin-segwit2x wrote: > You are also missing the point that many people dont use bitcoin for > payments - but as store of value - so they don?t care if there are long > confirmation times (or even none in one week!) - you only see it from the > payment/transaction side, but this is not the case for many people which > are motivated to stay and fight for bitcoin. > > Open your mind - there are many people which give a shit about > confirmation times and fees. > > Am 24.10.2017 um 21:04 schrieb Erik Voorhees via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org>: > > Peter - I disagree that 1x won?t have a market price. Exchanges can turn > off all deposits and withdraws completely for a week and you?ll still see > markets of both coins working, because there is already 1x and 2x in the > exchanges (in large quantities). > > > > Kind regards, > -Erik Voorhees > CEO ShapeShift AG > > On October 24, 2017 at 12:59:28 PM, Peter (dizzle at pointbiz.com) wrote: > > I agree the minority chain will quickly grind to a halt. Pure SPV users > will just want Bitcoin to work as Moe indicated. They won't know if they > are on the 1x or 2x chain but what they will know is Bitcoin (BTC) still > works and in 1 day 2x (BTC) will pass 100 blocks and have a market price > and be usable by exchanges globally. The 1x chain will not have a market > price for 5 days because it didn't reach the 100 block milestone to enable > deposits and coin splitting. In that time it can die out. Also, it's likely > to take an extra week or so for exchanges to get all their coin splitting > transactions confirmed by mixing with 1x coinbases. Honeybadger won't care > much and people won't want to say 1x is BTC because then they have to admit > BTC had a 1 or 2 week service interruption. > > Sorry if this is not technical enough for the list. > > Regards > Peter > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Jaxx_Decentral_Signature.png Type: image/png Size: 4457 bytes Desc: not available URL: From jacob.eliosoff at gmail.com Tue Oct 24 20:09:18 2017 From: jacob.eliosoff at gmail.com (Jacob Eliosoff) Date: Tue, 24 Oct 2017 16:09:18 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: <20171024170026.t66rhqbgjq25yh6d@fedora-23-dvm> References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <20171024170026.t66rhqbgjq25yh6d@fedora-23-dvm> Message-ID: The easiest way to think about this is, difficulty is a measure of how long your rig takes to mine a block, and until the first difficulty adjustment, *both chains will have identical difficulty!* Each will take equally long to mine. So *regardless* of overall hashrate split, a miner's short-term incentive is to just mine the coin with the higher price. In the longer run, difficulty will adjust so that each chain is producing 10-minute blocks, and the steady state will be where hashrate ratio follows price ratio. Eg, if B1X price stays 4x B2X, then the short-term-incentive steady state will be where B1X has 4x the difficulty and 80% of hashrate: ie, "mining B1X is a lottery you win 4x less often, with a prize 4x as valuable." But immediately post-split, short-term incentives may not dominate. Many miners don't sell immediately, so long-term price will influence them too. This could benefit either B2X, if low tx rate/high fees make B1X unusable and users shift to B2X; or B1X, if miners foresee B1X's price rising when it makes it to the difficulty adjustment(s) & becomes usable again. As Adam said, higher tx fees may also give B1X an edge with miners (if people are sending...). In short, I think people overstate the short-term incentives - many miners are in this for the long haul - but the post-split short-term incentive is simple and *independent* of hashrate distribution: just mine the coin with the higher price. On Oct 24, 2017 1:01 PM, "David A. Harding via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > On Tue, Oct 24, 2017 at 09:27:37AM -0700, Erik Voorhees via > Bitcoin-segwit2x wrote: > > So if you consider it from a $ revenue per day: > > - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or $1.44m > per > > day ($4,000 x 360) > > - 2x finds 115.2 blocks per day (0.8x144) and earns 1440 BTC2x, or > $1.44m > > per day ($1,000 x 1,440) > > > > Am I missing something? > > Umm, yeah. 2x did four times as much work to make the same amount of > money as 1x. By, "work", I of course mean that they expended four times > as much electricity and tied up four times as much capital equipment. > > Maybe this isn't obvious since you're treating 1x miners and 2x miners > as a group, but if you consider them as individual miners, it becomes > clear that there's a strong incentive to defect to the more profitable > chain. For example: > > Average daily blocks | 1x potential revenue | 2x potential > revenue > -------+----------------------+-----------------------+----- > ------------------ > Alice | 5 | 5*12.5*4000 = 250k | 5*12.5*1000 = > 62.5k > Bob | 10 | 10*12.5*4000 = 500k | 10*12.5*1000 = > 125.0k > Chalie | 25 | 25*12.5*4000 = 1,500k | 25*12.5*1000 = > 312.5k > > You can replace "average daily blocks" with "kiloWatt hours (kWh) plus > capital equipment depreciation costs" for a difficulty-neutral factor. > > -Dave > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Tue Oct 24 20:16:49 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Tue, 24 Oct 2017 20:16:49 +0000 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> , <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> Message-ID: Unfortunately, it is a double whammy for the legacy chain. Despite there being a general assumption that the legacy chain will have at least 20% of the current network hash, it?s going to be less than that and more likely the majority of that hash will mine coinbase only blocks in order to stall the chain. The closer the attack happens to the fork time (and therefore unknown block times & mempool), the more potent the attack as the fees will still be low relative to when block times are more accurately predicted and mempool settled. Once confirmation times on the legacy chain become unusually long (and the price begins to tend to reflect that), then attackers can abandon the chain and the ardent legacy miners will also start divesting/splitting their hash to the 2x chain. From: Peter BitcoinReminder.com via Bitcoin-segwit2x Sent: 24 October 2017 20:41 To: Erik Voorhees Cc: Melvin Carvalho via Bitcoin-segwit2x Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split You are also missing the point that many people dont use bitcoin for payments - but as store of value - so they don?t care if there are long confirmation times (or even none in one week!) - you only see it from the payment/transaction side, but this is not the case for many people which are motivated to stay and fight for bitcoin. Open your mind - there are many people which give a shit about confirmation times and fees. Am 24.10.2017 um 21:04 schrieb Erik Voorhees via Bitcoin-segwit2x >: Peter - I disagree that 1x won?t have a market price. Exchanges can turn off all deposits and withdraws completely for a week and you?ll still see markets of both coins working, because there is already 1x and 2x in the exchanges (in large quantities). Kind regards, -Erik Voorhees CEO ShapeShift AG On October 24, 2017 at 12:59:28 PM, Peter (dizzle at pointbiz.com) wrote: I agree the minority chain will quickly grind to a halt. Pure SPV users will just want Bitcoin to work as Moe indicated. They won't know if they are on the 1x or 2x chain but what they will know is Bitcoin (BTC) still works and in 1 day 2x (BTC) will pass 100 blocks and have a market price and be usable by exchanges globally. The 1x chain will not have a market price for 5 days because it didn't reach the 100 block milestone to enable deposits and coin splitting. In that time it can die out. Also, it's likely to take an extra week or so for exchanges to get all their coin splitting transactions confirmed by mixing with 1x coinbases. Honeybadger won't care much and people won't want to say 1x is BTC because then they have to admit BTC had a 1 or 2 week service interruption. Sorry if this is not technical enough for the list. Regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Tue Oct 24 20:22:39 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Tue, 24 Oct 2017 20:22:39 +0000 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <20171024170026.t66rhqbgjq25yh6d@fedora-23-dvm>, Message-ID: > So regardless of overall hashrate split, a miner's short-term incentive is to just mine the coin with the higher price. I think we need to start thinking of NYA miners rather than just plain miners as that is the reality of the situation. The toxicity experienced during this upgrade, from the HK agreement to date certainly mandates that we do not have plain ?game theory compliant? miners anymore. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at q32.com Tue Oct 24 20:26:34 2017 From: erik at q32.com (Erik Aronesty) Date: Tue, 24 Oct 2017 16:26:34 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> Message-ID: At this point *either* chain can be the "legacy" chain. Most exchanges are going to support both coins. Coinbase's announcement that 2x will be initially called B2X was big (they reserve the right to rename it later). Users will be thus be free to dump either coin according to their personal feelings on the matter. Hashpower is probably not going to be a consideration for the majority of holders. At the end of the day... if users dump 1x, miners will jump on 2x, and if users dump 2x, miners will jump on 1x. Trying to predict what investors and users will do is really not "politics". It's pure speculation. And basing any real decisions off "hashpower signaling" is patently absurd. In other words: - This is a risky proposition either way - There is no reasonable way to predict the outcome Anyone who claims otherwise is probably entrenched in a particular "camp", and isn't thinking rationally about the current situation. (Personally, I'm simply going to dump on the first day... regardless of the price and based on my preference. I suspect I'm in the minority here.) On Tue, Oct 24, 2017 at 4:16 PM, Phillip Katete via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Unfortunately, it is a double whammy for the legacy chain. > > > > Despite there being a general assumption that the legacy chain will have > at least 20% of the current network hash, it?s going to be less than that > and more likely the majority of that hash will mine coinbase only blocks in > order to stall the chain. The closer the attack happens to the fork time > (and therefore unknown block times & mempool), the more potent the attack > as the fees will still be low relative to when block times are more > accurately predicted and mempool settled. > > > > Once confirmation times on the legacy chain become unusually long (and the > price begins to tend to reflect that), then attackers can abandon the chain > and the ardent legacy miners will also start divesting/splitting their hash > to the 2x chain. > > > > *From: *Peter BitcoinReminder.com via Bitcoin-segwit2x > > *Sent: *24 October 2017 20:41 > *To: *Erik Voorhees > *Cc: *Melvin Carvalho via Bitcoin-segwit2x > > *Subject: *Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, > guarantee) - Ensuring a smooth 2X upgrade without a chain split > > > > You are also missing the point that many people dont use bitcoin for > payments - but as store of value - so they don?t care if there are long > confirmation times (or even none in one week!) - you only see it from the > payment/transaction side, but this is not the case for many people which > are motivated to stay and fight for bitcoin. > > > > Open your mind - there are many people which give a shit about > confirmation times and fees. > > > > Am 24.10.2017 um 21:04 schrieb Erik Voorhees via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org>: > > > > Peter - I disagree that 1x won?t have a market price. Exchanges can turn > off all deposits and withdraws completely for a week and you?ll still see > markets of both coins working, because there is already 1x and 2x in the > exchanges (in large quantities). > > > > > > > > Kind regards, > > -Erik Voorhees > > CEO ShapeShift AG > > > > On October 24, 2017 at 12:59:28 PM, Peter (dizzle at pointbiz.com) wrote: > > I agree the minority chain will quickly grind to a halt. Pure SPV users > will just want Bitcoin to work as Moe indicated. They won't know if they > are on the 1x or 2x chain but what they will know is Bitcoin (BTC) still > works and in 1 day 2x (BTC) will pass 100 blocks and have a market price > and be usable by exchanges globally. The 1x chain will not have a market > price for 5 days because it didn't reach the 100 block milestone to enable > deposits and coin splitting. In that time it can die out. Also, it's likely > to take an extra week or so for exchanges to get all their coin splitting > transactions confirmed by mixing with 1x coinbases. Honeybadger won't care > much and people won't want to say 1x is BTC because then they have to admit > BTC had a 1 or 2 week service interruption. > > > > Sorry if this is not technical enough for the list. > > > > Regards > > Peter > > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moe at bitaccess.co Tue Oct 24 20:41:02 2017 From: moe at bitaccess.co (Moe Adham) Date: Tue, 24 Oct 2017 16:41:02 -0400 Subject: [Bitcoin-segwit2x] Orderly Process for Coin-Splitting after the fork Message-ID: Hello, I would like to have a *non-political discussion on best practices* for companies looking to split coins between the two (possible) chains after the fork. Given the lack of replay protection, a number of companies that enable payments will need to temporarily halt operations and split balances to properly protect our users. This will need to be done quickly to minimize network downtime Please don't respond with speculation on why replay protection is needed. That is not the topic of discussion. The topic of discussion is: *- Technical means companies can take to securely split coins as quickly as possible after the fork* Some approaches are: 1. RBF: Generate an RBF transactions to a wallet you control, wait for transaction to confirm in only 1 chain. Relay another RBF transaction on the second chain that spends the entire balance as a fee. Repeat if you fail. 2. Coinbase: Have miners agree to send a small amount of newly generated coins to wallet operators as quickly as possible after the fork, to allow wallet operators to split wallets 3. nLockTime: Wait for chains to sufficiently diverge, and create two transactions, which should only confirm on one or the other chain. Repeat if you fail Any suggestions or code snippets are welcome. -- *Moe Adham, MSc, BEng **|* Co-Founder -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe.biocca at gmail.com Tue Oct 24 20:53:30 2017 From: christophe.biocca at gmail.com (Christophe Biocca) Date: Tue, 24 Oct 2017 16:53:30 -0400 Subject: [Bitcoin-segwit2x] Orderly Process for Coin-Splitting after the fork In-Reply-To: References: Message-ID: > Relay another RBF transaction on the second chain that spends the entire balance as a fee. Repeat if you fail. I'm pretty sure that's not the right way to do this? RBF, with a higher fee, to a different address (or the same one). Spending the whole balance as a fee = Free gift to miners. On 24 October 2017 at 16:41, Moe Adham via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Hello, > > I would like to have a *non-political discussion on best practices* for > companies looking to split coins between the two (possible) chains after > the fork. > > Given the lack of replay protection, a number of companies that enable > payments will need to temporarily halt operations and split balances to > properly protect our users. This will need to be done quickly to minimize > network downtime > > Please don't respond with speculation on why replay protection is needed. > That is not the topic of discussion. The topic of discussion is: > *- Technical means companies can take to securely split coins as quickly > as possible after the fork* > > Some approaches are: > > 1. RBF: Generate an RBF transactions to a wallet you control, wait for > transaction to confirm in only 1 chain. Relay another RBF transaction on > the second chain that spends the entire balance as a fee. Repeat if you > fail. > 2. Coinbase: Have miners agree to send a small amount of newly > generated coins to wallet operators as quickly as possible after the fork, > to allow wallet operators to split wallets > 3. nLockTime: Wait for chains to sufficiently diverge, and create two > transactions, which should only confirm on one or the other chain. Repeat > if you fail > > Any suggestions or code snippets are welcome. > > -- > *Moe Adham, MSc, BEng **|* Co-Founder > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinny at civic.com Wed Oct 25 00:11:53 2017 From: vinny at civic.com (Vinny Lingham) Date: Tue, 24 Oct 2017 17:11:53 -0700 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> Message-ID: <8F950CE7-B3D4-4720-9B3A-C6C9D789AE18@civic.com> I?d love to get a sense of what the hash rate threshold will be for exchanges to stop accepting 1x coin, even with 6 confirmations? With the risk of a selfish mining attack increasing the lower the 1x hashrate is, why would an exchange accept the coins knowing that someone could be double spending across multiple exchanges? https://bitcointalk.org/index.php?topic=2127697.0 I?m just trying to understand this attack vector better... I haven?t heard a good response to this question yet - would really appreciate some insight here. This is largely why I believe hashrate secures the network and why I?ve been against the UASF. Sent from my iPad > On Oct 24, 2017, at 13:26, Erik Aronesty via Bitcoin-segwit2x wrote: > > At this point *either* chain can be the "legacy" chain. Most exchanges are going to support both coins. Coinbase's announcement that 2x will be initially called B2X was big (they reserve the right to rename it later). > > Users will be thus be free to dump either coin according to their personal feelings on the matter. > > Hashpower is probably not going to be a consideration for the majority of holders. At the end of the day... if users dump 1x, miners will jump on 2x, and if users dump 2x, miners will jump on 1x. > > Trying to predict what investors and users will do is really not "politics". It's pure speculation. And basing any real decisions off "hashpower signaling" is patently absurd. > > In other words: > > - This is a risky proposition either way > - There is no reasonable way to predict the outcome > > Anyone who claims otherwise is probably entrenched in a particular "camp", and isn't thinking rationally about the current situation. > > (Personally, I'm simply going to dump on the first day... regardless of the price and based on my preference. I suspect I'm in the minority here.) > > >> On Tue, Oct 24, 2017 at 4:16 PM, Phillip Katete via Bitcoin-segwit2x wrote: >> Unfortunately, it is a double whammy for the legacy chain. >> >> >> >> Despite there being a general assumption that the legacy chain will have at least 20% of the current network hash, it?s going to be less than that and more likely the majority of that hash will mine coinbase only blocks in order to stall the chain. The closer the attack happens to the fork time (and therefore unknown block times & mempool), the more potent the attack as the fees will still be low relative to when block times are more accurately predicted and mempool settled. >> >> >> >> Once confirmation times on the legacy chain become unusually long (and the price begins to tend to reflect that), then attackers can abandon the chain and the ardent legacy miners will also start divesting/splitting their hash to the 2x chain. >> >> >> >> From: Peter BitcoinReminder.com via Bitcoin-segwit2x >> Sent: 24 October 2017 20:41 >> To: Erik Voorhees >> Cc: Melvin Carvalho via Bitcoin-segwit2x >> Subject: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split >> >> >> >> You are also missing the point that many people dont use bitcoin for payments - but as store of value - so they don?t care if there are long confirmation times (or even none in one week!) - you only see it from the payment/transaction side, but this is not the case for many people which are motivated to stay and fight for bitcoin. >> >> >> >> Open your mind - there are many people which give a shit about confirmation times and fees. >> >> >> >> Am 24.10.2017 um 21:04 schrieb Erik Voorhees via Bitcoin-segwit2x : >> >> >> >> Peter - I disagree that 1x won?t have a market price. Exchanges can turn off all deposits and withdraws completely for a week and you?ll still see markets of both coins working, because there is already 1x and 2x in the exchanges (in large quantities). >> >> >> >> >> >> >> >> Kind regards, >> >> -Erik Voorhees >> >> CEO ShapeShift AG >> >> >> >> >> On October 24, 2017 at 12:59:28 PM, Peter (dizzle at pointbiz.com) wrote: >> >> I agree the minority chain will quickly grind to a halt. Pure SPV users will just want Bitcoin to work as Moe indicated. They won't know if they are on the 1x or 2x chain but what they will know is Bitcoin (BTC) still works and in 1 day 2x (BTC) will pass 100 blocks and have a market price and be usable by exchanges globally. The 1x chain will not have a market price for 5 days because it didn't reach the 100 block milestone to enable deposits and coin splitting. In that time it can die out. Also, it's likely to take an extra week or so for exchanges to get all their coin splitting transactions confirmed by mixing with 1x coinbases. Honeybadger won't care much and people won't want to say 1x is BTC because then they have to admit BTC had a 1 or 2 week service interruption. >> >> >> >> Sorry if this is not technical enough for the list. >> >> >> >> Regards >> >> Peter >> >> >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From morcos at gmail.com Wed Oct 25 00:42:16 2017 From: morcos at gmail.com (Alex Morcos) Date: Tue, 24 Oct 2017 20:42:16 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: <8F950CE7-B3D4-4720-9B3A-C6C9D789AE18@civic.com> References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> <8F950CE7-B3D4-4720-9B3A-C6C9D789AE18@civic.com> Message-ID: If we start seeing 6-block deep reorgs because miners are attempting to pull off a double-spend attack then I think the fundamental economic incentives of Bitcoin will be shown to have failed and we might as well all go home. It's somewhat reasonable to come to differing opinions on what's long term economically rational for miners as to which fork to mine, but it's clearly very detrimental to the future utility of Bitcoin to try double spend attacks. I'm quite confident we will not see that. On Tue, Oct 24, 2017 at 8:11 PM, Vinny Lingham via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > I?d love to get a sense of what the hash rate threshold will be for > exchanges to stop accepting 1x coin, even with 6 confirmations? With the > risk of a selfish mining attack increasing the lower the 1x hashrate is, > why would an exchange accept the coins knowing that someone could be double > spending across multiple exchanges? > > https://bitcointalk.org/index.php?topic=2127697.0 > > I?m just trying to understand this attack vector better... I haven?t heard > a good response to this question yet - would really appreciate some insight > here. This is largely why I believe hashrate secures the network and why > I?ve been against the UASF. > > Sent from my iPad > > On Oct 24, 2017, at 13:26, Erik Aronesty via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > At this point *either* chain can be the "legacy" chain. Most exchanges > are going to support both coins. Coinbase's announcement that 2x will be > initially called B2X was big (they reserve the right to rename it later). > > Users will be thus be free to dump either coin according to their personal > feelings on the matter. > > Hashpower is probably not going to be a consideration for the majority of > holders. At the end of the day... if users dump 1x, miners will jump on > 2x, and if users dump 2x, miners will jump on 1x. > > Trying to predict what investors and users will do is really not > "politics". It's pure speculation. And basing any real decisions off > "hashpower signaling" is patently absurd. > > In other words: > > - This is a risky proposition either way > - There is no reasonable way to predict the outcome > > Anyone who claims otherwise is probably entrenched in a particular "camp", > and isn't thinking rationally about the current situation. > > (Personally, I'm simply going to dump on the first day... regardless of > the price and based on my preference. I suspect I'm in the minority here.) > > > On Tue, Oct 24, 2017 at 4:16 PM, Phillip Katete via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Unfortunately, it is a double whammy for the legacy chain. >> >> >> >> Despite there being a general assumption that the legacy chain will have >> at least 20% of the current network hash, it?s going to be less than that >> and more likely the majority of that hash will mine coinbase only blocks in >> order to stall the chain. The closer the attack happens to the fork time >> (and therefore unknown block times & mempool), the more potent the attack >> as the fees will still be low relative to when block times are more >> accurately predicted and mempool settled. >> >> >> >> Once confirmation times on the legacy chain become unusually long (and >> the price begins to tend to reflect that), then attackers can abandon the >> chain and the ardent legacy miners will also start divesting/splitting >> their hash to the 2x chain. >> >> >> >> *From: *Peter BitcoinReminder.com via Bitcoin-segwit2x >> >> *Sent: *24 October 2017 20:41 >> *To: *Erik Voorhees >> *Cc: *Melvin Carvalho via Bitcoin-segwit2x >> >> *Subject: *Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >> guarantee) - Ensuring a smooth 2X upgrade without a chain split >> >> >> >> You are also missing the point that many people dont use bitcoin for >> payments - but as store of value - so they don?t care if there are long >> confirmation times (or even none in one week!) - you only see it from the >> payment/transaction side, but this is not the case for many people which >> are motivated to stay and fight for bitcoin. >> >> >> >> Open your mind - there are many people which give a shit about >> confirmation times and fees. >> >> >> >> Am 24.10.2017 um 21:04 schrieb Erik Voorhees via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org>: >> >> >> >> Peter - I disagree that 1x won?t have a market price. Exchanges can turn >> off all deposits and withdraws completely for a week and you?ll still see >> markets of both coins working, because there is already 1x and 2x in the >> exchanges (in large quantities). >> >> >> >> >> >> >> >> Kind regards, >> >> -Erik Voorhees >> >> CEO ShapeShift AG >> >> >> >> On October 24, 2017 at 12:59:28 PM, Peter (dizzle at pointbiz.com) wrote: >> >> I agree the minority chain will quickly grind to a halt. Pure SPV users >> will just want Bitcoin to work as Moe indicated. They won't know if they >> are on the 1x or 2x chain but what they will know is Bitcoin (BTC) still >> works and in 1 day 2x (BTC) will pass 100 blocks and have a market price >> and be usable by exchanges globally. The 1x chain will not have a market >> price for 5 days because it didn't reach the 100 block milestone to enable >> deposits and coin splitting. In that time it can die out. Also, it's likely >> to take an extra week or so for exchanges to get all their coin splitting >> transactions confirmed by mixing with 1x coinbases. Honeybadger won't care >> much and people won't want to say 1x is BTC because then they have to admit >> BTC had a 1 or 2 week service interruption. >> >> >> >> Sorry if this is not technical enough for the list. >> >> >> >> Regards >> >> Peter >> >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.eliosoff at gmail.com Wed Oct 25 01:00:31 2017 From: jacob.eliosoff at gmail.com (Jacob Eliosoff) Date: Tue, 24 Oct 2017 21:00:31 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> <8F950CE7-B3D4-4720-9B3A-C6C9D789AE18@civic.com> Message-ID: I wouldn't assume that "clearly very detrimental to the future utility of Bitcoin" is much of a disincentive to double-spend attacks, or much reassurance to an exchange risking one, particularly where "Bitcoin" = "one, minority-hash branch of Bitcoin". The persistent attacks on Ethereum last year (replay, then gas pricing exploits) show that when attacks are feasible, it's fairly likely some schmuck will employ them. Eg in the extreme case where hashrate is split 99%/1%, we can probably agree accepting payments on the 1% chain is unwise. That said - 99/1 seems implausible to me, and as long as both chains have nontrivial (>5%?) support, my *guess* is Alex is right that double-spends (or, more likely, empty-/bad-block attacks) are unlikely. On Oct 24, 2017 8:42 PM, "Alex Morcos via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: If we start seeing 6-block deep reorgs because miners are attempting to pull off a double-spend attack then I think the fundamental economic incentives of Bitcoin will be shown to have failed and we might as well all go home. It's somewhat reasonable to come to differing opinions on what's long term economically rational for miners as to which fork to mine, but it's clearly very detrimental to the future utility of Bitcoin to try double spend attacks. I'm quite confident we will not see that. On Tue, Oct 24, 2017 at 8:11 PM, Vinny Lingham via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > I?d love to get a sense of what the hash rate threshold will be for > exchanges to stop accepting 1x coin, even with 6 confirmations? With the > risk of a selfish mining attack increasing the lower the 1x hashrate is, > why would an exchange accept the coins knowing that someone could be double > spending across multiple exchanges? > > https://bitcointalk.org/index.php?topic=2127697.0 > > I?m just trying to understand this attack vector better... I haven?t heard > a good response to this question yet - would really appreciate some insight > here. This is largely why I believe hashrate secures the network and why > I?ve been against the UASF. > > Sent from my iPad > > On Oct 24, 2017, at 13:26, Erik Aronesty via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > At this point *either* chain can be the "legacy" chain. Most exchanges > are going to support both coins. Coinbase's announcement that 2x will be > initially called B2X was big (they reserve the right to rename it later). > > Users will be thus be free to dump either coin according to their personal > feelings on the matter. > > Hashpower is probably not going to be a consideration for the majority of > holders. At the end of the day... if users dump 1x, miners will jump on > 2x, and if users dump 2x, miners will jump on 1x. > > Trying to predict what investors and users will do is really not > "politics". It's pure speculation. And basing any real decisions off > "hashpower signaling" is patently absurd. > > In other words: > > - This is a risky proposition either way > - There is no reasonable way to predict the outcome > > Anyone who claims otherwise is probably entrenched in a particular "camp", > and isn't thinking rationally about the current situation. > > (Personally, I'm simply going to dump on the first day... regardless of > the price and based on my preference. I suspect I'm in the minority here.) > > > On Tue, Oct 24, 2017 at 4:16 PM, Phillip Katete via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Unfortunately, it is a double whammy for the legacy chain. >> >> >> >> Despite there being a general assumption that the legacy chain will have >> at least 20% of the current network hash, it?s going to be less than that >> and more likely the majority of that hash will mine coinbase only blocks in >> order to stall the chain. The closer the attack happens to the fork time >> (and therefore unknown block times & mempool), the more potent the attack >> as the fees will still be low relative to when block times are more >> accurately predicted and mempool settled. >> >> >> >> Once confirmation times on the legacy chain become unusually long (and >> the price begins to tend to reflect that), then attackers can abandon the >> chain and the ardent legacy miners will also start divesting/splitting >> their hash to the 2x chain. >> >> >> >> *From: *Peter BitcoinReminder.com via Bitcoin-segwit2x >> >> *Sent: *24 October 2017 20:41 >> *To: *Erik Voorhees >> *Cc: *Melvin Carvalho via Bitcoin-segwit2x >> >> *Subject: *Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >> guarantee) - Ensuring a smooth 2X upgrade without a chain split >> >> >> >> You are also missing the point that many people dont use bitcoin for >> payments - but as store of value - so they don?t care if there are long >> confirmation times (or even none in one week!) - you only see it from the >> payment/transaction side, but this is not the case for many people which >> are motivated to stay and fight for bitcoin. >> >> >> >> Open your mind - there are many people which give a shit about >> confirmation times and fees. >> >> >> >> Am 24.10.2017 um 21:04 schrieb Erik Voorhees via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org>: >> >> >> >> Peter - I disagree that 1x won?t have a market price. Exchanges can turn >> off all deposits and withdraws completely for a week and you?ll still see >> markets of both coins working, because there is already 1x and 2x in the >> exchanges (in large quantities). >> >> >> >> >> >> >> >> Kind regards, >> >> -Erik Voorhees >> >> CEO ShapeShift AG >> >> >> >> On October 24, 2017 at 12:59:28 PM, Peter (dizzle at pointbiz.com) wrote: >> >> I agree the minority chain will quickly grind to a halt. Pure SPV users >> will just want Bitcoin to work as Moe indicated. They won't know if they >> are on the 1x or 2x chain but what they will know is Bitcoin (BTC) still >> works and in 1 day 2x (BTC) will pass 100 blocks and have a market price >> and be usable by exchanges globally. The 1x chain will not have a market >> price for 5 days because it didn't reach the 100 block milestone to enable >> deposits and coin splitting. In that time it can die out. Also, it's likely >> to take an extra week or so for exchanges to get all their coin splitting >> transactions confirmed by mixing with 1x coinbases. Honeybadger won't care >> much and people won't want to say 1x is BTC because then they have to admit >> BTC had a 1 or 2 week service interruption. >> >> >> >> Sorry if this is not technical enough for the list. >> >> >> >> Regards >> >> Peter >> >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From benkloester at gmail.com Wed Oct 25 01:38:04 2017 From: benkloester at gmail.com (Ben Kloester) Date: Wed, 25 Oct 2017 12:38:04 +1100 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> <8F950CE7-B3D4-4720-9B3A-C6C9D789AE18@civic.com> Message-ID: Given that the futures markets believe that 1X will be far more valuable than 2X, there's only a few means by which 2X proponents and miners are likely to be able to shift the expected values more in favour of 2X. The least insidious and most natural is simply to mine only 2X - eg if 99% or even 95% of miners only mined 2X, it's conceivable that the very long time to find blocks and to adjust difficulty on 1X might make it sufficiently unusable that its value in expectation goes down. However I find this somewhat doubtful, as there is now a fairly strong precedent of coins retaining significant value even when their chain is fraught (Bitcoin Cash in the early days, and arguably even now with its schizophrenic EDA), or even where no chain exists! (observe Bitcoin Gold, in all its ignominy). Given this, it seems pretty likely that the market can stay 'irrational' (may not actually be irrational if you look at the longer-run incentives) longer than miners can stay solvent, so defections become more likely the longer the price continues to ascribe much greater value to 1X than 2X, despite problems with actually using 1X to transact. That means that if miners are really very determined that 2X be the only surviving chain, which seems possible - observe current favoured framing of it as an 'upgrade' amongst proponents, then they may employ more insidious tactics. These could include selfish mining on the 1X, with or without transactions. If they chose to include transactions in their selfish-mined blocks, they can also double-spend costlessly. I say costlessly, but that's only true in Bitcoin terms - it could crash the real value of those coins though. Since double spending against exchanges screws the entire ecosystem, it seems unlikely they'd do that, I agree. But in any case, more explicit attacks like any of these would be much more likely to move the expected value. This is where something like B0rg is potentially very powerful, because it creates the possibility of forcing an all-or-nothing equilibrium, so a simple majority of support quickly converts itself into consensus at one of the two extrema (in a way futures prices do the same - as there is positive feedback from the price to miner support, and to the extent that you believe miner support affects viability/expected value, back to price. So we should expect futures price to be 'bipolar', just as we'd expect miner suppport with something like B0rg to be bipolar) For the record I actually think B0rg is evil, and I'm also not sure that in its current form it's found a way to achieve what it's trying to do - force consensus as the stable equilibrium (for a start it seems that there is a problem with withholding blocks). But I think I agree that something like it could, when combined with an initial simple majority of miners supporting it, move incentives and expected values very far very quickly. The existence of futures also makes these attacks cost less, because miners could buy 2X at a large discoutn just before the fork, knowing their intentions. Of course, this fact, combined with the low current value of the 2X future, is actually pretty reassuring, from a Hansonian perspective, as it's a signal that miners too believe that 2X won't be worth more. *Ben Kloester* On 25 October 2017 at 12:00, Jacob Eliosoff via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > I wouldn't assume that "clearly very detrimental to the future utility of > Bitcoin" is much of a disincentive to double-spend attacks, or much > reassurance to an exchange risking one, particularly where "Bitcoin" = > "one, minority-hash branch of Bitcoin". The persistent attacks on Ethereum > last year (replay, then gas pricing exploits) show that when attacks are > feasible, it's fairly likely some schmuck will employ them. Eg in the > extreme case where hashrate is split 99%/1%, we can probably agree > accepting payments on the 1% chain is unwise. > > That said - 99/1 seems implausible to me, and as long as both chains have > nontrivial (>5%?) support, my *guess* is Alex is right that double-spends > (or, more likely, empty-/bad-block attacks) are unlikely. > > > On Oct 24, 2017 8:42 PM, "Alex Morcos via Bitcoin-segwit2x" < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > If we start seeing 6-block deep reorgs because miners are attempting to > pull off a double-spend attack then I think the fundamental economic > incentives of Bitcoin will be shown to have failed and we might as well all > go home. It's somewhat reasonable to come to differing opinions on what's > long term economically rational for miners as to which fork to mine, but > it's clearly very detrimental to the future utility of Bitcoin to try > double spend attacks. I'm quite confident we will not see that. > > > > On Tue, Oct 24, 2017 at 8:11 PM, Vinny Lingham via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> I?d love to get a sense of what the hash rate threshold will be for >> exchanges to stop accepting 1x coin, even with 6 confirmations? With the >> risk of a selfish mining attack increasing the lower the 1x hashrate is, >> why would an exchange accept the coins knowing that someone could be double >> spending across multiple exchanges? >> >> https://bitcointalk.org/index.php?topic=2127697.0 >> >> I?m just trying to understand this attack vector better... I haven?t >> heard a good response to this question yet - would really appreciate some >> insight here. This is largely why I believe hashrate secures the network >> and why I?ve been against the UASF. >> >> Sent from my iPad >> >> On Oct 24, 2017, at 13:26, Erik Aronesty via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >> At this point *either* chain can be the "legacy" chain. Most exchanges >> are going to support both coins. Coinbase's announcement that 2x will be >> initially called B2X was big (they reserve the right to rename it later). >> >> Users will be thus be free to dump either coin according to their >> personal feelings on the matter. >> >> Hashpower is probably not going to be a consideration for the majority of >> holders. At the end of the day... if users dump 1x, miners will jump on >> 2x, and if users dump 2x, miners will jump on 1x. >> >> Trying to predict what investors and users will do is really not >> "politics". It's pure speculation. And basing any real decisions off >> "hashpower signaling" is patently absurd. >> >> In other words: >> >> - This is a risky proposition either way >> - There is no reasonable way to predict the outcome >> >> Anyone who claims otherwise is probably entrenched in a particular >> "camp", and isn't thinking rationally about the current situation. >> >> (Personally, I'm simply going to dump on the first day... regardless of >> the price and based on my preference. I suspect I'm in the minority here.) >> >> >> On Tue, Oct 24, 2017 at 4:16 PM, Phillip Katete via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> Unfortunately, it is a double whammy for the legacy chain. >>> >>> >>> >>> Despite there being a general assumption that the legacy chain will have >>> at least 20% of the current network hash, it?s going to be less than that >>> and more likely the majority of that hash will mine coinbase only blocks in >>> order to stall the chain. The closer the attack happens to the fork time >>> (and therefore unknown block times & mempool), the more potent the attack >>> as the fees will still be low relative to when block times are more >>> accurately predicted and mempool settled. >>> >>> >>> >>> Once confirmation times on the legacy chain become unusually long (and >>> the price begins to tend to reflect that), then attackers can abandon the >>> chain and the ardent legacy miners will also start divesting/splitting >>> their hash to the 2x chain. >>> >>> >>> >>> *From: *Peter BitcoinReminder.com via Bitcoin-segwit2x >>> >>> *Sent: *24 October 2017 20:41 >>> *To: *Erik Voorhees >>> *Cc: *Melvin Carvalho via Bitcoin-segwit2x >>> >>> *Subject: *Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >>> guarantee) - Ensuring a smooth 2X upgrade without a chain split >>> >>> >>> >>> You are also missing the point that many people dont use bitcoin for >>> payments - but as store of value - so they don?t care if there are long >>> confirmation times (or even none in one week!) - you only see it from the >>> payment/transaction side, but this is not the case for many people which >>> are motivated to stay and fight for bitcoin. >>> >>> >>> >>> Open your mind - there are many people which give a shit about >>> confirmation times and fees. >>> >>> >>> >>> Am 24.10.2017 um 21:04 schrieb Erik Voorhees via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org>: >>> >>> >>> >>> Peter - I disagree that 1x won?t have a market price. Exchanges can turn >>> off all deposits and withdraws completely for a week and you?ll still see >>> markets of both coins working, because there is already 1x and 2x in the >>> exchanges (in large quantities). >>> >>> >>> >>> >>> >>> >>> >>> Kind regards, >>> >>> -Erik Voorhees >>> >>> CEO ShapeShift AG >>> >>> >>> >>> On October 24, 2017 at 12:59:28 PM, Peter (dizzle at pointbiz.com) wrote: >>> >>> I agree the minority chain will quickly grind to a halt. Pure SPV users >>> will just want Bitcoin to work as Moe indicated. They won't know if they >>> are on the 1x or 2x chain but what they will know is Bitcoin (BTC) still >>> works and in 1 day 2x (BTC) will pass 100 blocks and have a market price >>> and be usable by exchanges globally. The 1x chain will not have a market >>> price for 5 days because it didn't reach the 100 block milestone to enable >>> deposits and coin splitting. In that time it can die out. Also, it's likely >>> to take an extra week or so for exchanges to get all their coin splitting >>> transactions confirmed by mixing with 1x coinbases. Honeybadger won't care >>> much and people won't want to say 1x is BTC because then they have to admit >>> BTC had a 1 or 2 week service interruption. >>> >>> >>> >>> Sorry if this is not technical enough for the list. >>> >>> >>> >>> Regards >>> >>> Peter >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Wed Oct 25 02:00:55 2017 From: bitpico at icloud.com (bitPico) Date: Tue, 24 Oct 2017 22:00:55 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> <8F950CE7-B3D4-4720-9B3A-C6C9D789AE18@civic.com> Message-ID: <722E0C7F-337D-4C29-9331-5C6CC6DBDFCA@icloud.com> Correct; hardly anyone will continue to run the deprecated SegWit1x like all old software. Coinbase, BitPay, and all of the other big names will upgrade as appropriate. > On Oct 24, 2017, at 9:38 PM, Ben Kloester via Bitcoin-segwit2x wrote: > > believe that ... From bitpico at icloud.com Wed Oct 25 02:03:39 2017 From: bitpico at icloud.com (bitPico) Date: Tue, 24 Oct 2017 22:03:39 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> <8F950CE7-B3D4-4720-9B3A-C6C9D789AE18@civic.com> Message-ID: 2 + 2 != 5 > On Oct 24, 2017, at 9:00 PM, Jacob Eliosoff via Bitcoin-segwit2x wrote: > > I wouldn't assume that ... From benkloester at gmail.com Wed Oct 25 02:03:50 2017 From: benkloester at gmail.com (Ben Kloester) Date: Wed, 25 Oct 2017 13:03:50 +1100 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: <722E0C7F-337D-4C29-9331-5C6CC6DBDFCA@icloud.com> References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> <8F950CE7-B3D4-4720-9B3A-C6C9D789AE18@civic.com> <722E0C7F-337D-4C29-9331-5C6CC6DBDFCA@icloud.com> Message-ID: bitPico, this is demonstrably false based on announcements from those orgs - in order to support both chains which Coinbase is doing, they will obviously need to run 1X compatible software. Also, for someone that always pipes up about this list being only for technical discussion, that was a particularly non-techical and frankly useless contribution. Please try to take your own advice a little more often. *Ben Kloester* On 25 October 2017 at 13:00, bitPico wrote: > Correct; hardly anyone will continue to run the deprecated SegWit1x like > all old software. > > Coinbase, BitPay, and all of the other big names will upgrade as > appropriate. > > > On Oct 24, 2017, at 9:38 PM, Ben Kloester via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > > > believe that ... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Wed Oct 25 02:12:20 2017 From: bitpico at icloud.com (bitPico) Date: Tue, 24 Oct 2017 22:12:20 -0400 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> <8F950CE7-B3D4-4720-9B3A-C6C9D789AE18@civic.com> <722E0C7F-337D-4C29-9331-5C6CC6DBDFCA@icloud.com> Message-ID: <9A5AF218-BE46-46DA-8B17-AEA1D926821B@icloud.com> Incorrect you don?t need any node to create a SegWit1x transaction. This can be done with a python script and broadcast through any 2x node (1x has no replay protection). You only need a SegWit2x node; there is no replay protection so 1x nodes are not needed even whatsoever. Bitcoin for dummies could help you. > On Oct 24, 2017, at 10:03 PM, Ben Kloester wrote: > > bitPico, this is demonstrably false based on announcements from those orgs - in order to support both chains which Coinbase is doing, they will obviously need to run 1X compatible software. > > Also, for someone that always pipes up about this list being only for technical discussion, that was a particularly non-techical and frankly useless contribution. Please try to take your own advice a little more often. > > Ben Kloester > > >> On 25 October 2017 at 13:00, bitPico wrote: >> Correct; hardly anyone will continue to run the deprecated SegWit1x like all old software. >> >> Coinbase, BitPay, and all of the other big names will upgrade as appropriate. >> >> > On Oct 24, 2017, at 9:38 PM, Ben Kloester via Bitcoin-segwit2x wrote: >> > >> > believe that ... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benkloester at gmail.com Wed Oct 25 02:21:48 2017 From: benkloester at gmail.com (Ben Kloester) Date: Wed, 25 Oct 2017 13:21:48 +1100 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: <9A5AF218-BE46-46DA-8B17-AEA1D926821B@icloud.com> References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> <8F950CE7-B3D4-4720-9B3A-C6C9D789AE18@civic.com> <722E0C7F-337D-4C29-9331-5C6CC6DBDFCA@icloud.com> <9A5AF218-BE46-46DA-8B17-AEA1D926821B@icloud.com> Message-ID: It there are two chains, which seems all but guaranteed at least in the short run, then you are simply mistaken. The P2P networks are likely to be disjunct, for a start, even if transactions constructed by a 1x node are valid on 2x (and vice versa, due to no replay protection). Furthermore, a 2x and a 1x node will disagree about what is the tip of the chain, which means that from the fork onwards they have a different ledger state (utxo set), which will obviously matter when it comes to validating transactions. So what you say is trivially incorrect. For someone that harps on about using this list for only technical discussion, you seem to have a pretty inadequate technical understanding of things. I once strongly supported the 2X fork, but you and your ilk certainly don't help its case with behaviour and discussion like this. *Ben Kloester* On 25 October 2017 at 13:12, bitPico wrote: > Incorrect you don?t need any node to create a SegWit1x transaction. This > can be done with a python script and broadcast through any 2x node (1x has > no replay protection). > > You only need a SegWit2x node; there is no replay protection so 1x nodes > are not needed even whatsoever. > > Bitcoin for dummies could help you. > > On Oct 24, 2017, at 10:03 PM, Ben Kloester wrote: > > bitPico, this is demonstrably false based on announcements from those orgs > - in order to support both chains which Coinbase is doing, they will > obviously need to run 1X compatible software. > > Also, for someone that always pipes up about this list being only for > technical discussion, that was a particularly non-techical and frankly > useless contribution. Please try to take your own advice a little more > often. > > *Ben Kloester* > > On 25 October 2017 at 13:00, bitPico wrote: > >> Correct; hardly anyone will continue to run the deprecated SegWit1x like >> all old software. >> >> Coinbase, BitPay, and all of the other big names will upgrade as >> appropriate. >> >> > On Oct 24, 2017, at 9:38 PM, Ben Kloester via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> > >> > believe that ... >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at bitcrust.org Wed Oct 25 08:24:38 2017 From: tomas at bitcrust.org (Tomas) Date: Wed, 25 Oct 2017 10:24:38 +0200 Subject: [Bitcoin-segwit2x] Orderly Process for Coin-Splitting after the fork In-Reply-To: References: Message-ID: <1508919878.3804114.1150261632.0DD7BDDB@webmail.messagingengine.com> On Tue, Oct 24, 2017, at 22:41, Moe Adham via Bitcoin-segwit2x wrote: > > Coinbase: Have miners agree to send a small amount of newly generated > coins to wallet operators as quickly as possible after the fork, to > allow wallet operators to split wallets I don't think miners actually need to send these coins to wallet operators. A miner or someone else who has acquired some newly minted coins can create transactions with one input and one output that pay to self with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY and provide these replay protected transaction "templates" in large numbers over an API for everyone to use. Tomas bitcrust -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Wed Oct 25 12:05:43 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Wed, 25 Oct 2017 14:05:43 +0200 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: <8F950CE7-B3D4-4720-9B3A-C6C9D789AE18@civic.com> References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <77DC5C05-EFEA-4756-BAC8-039CDB97B934@bitcoinreminder.com> <8F950CE7-B3D4-4720-9B3A-C6C9D789AE18@civic.com> Message-ID: On 25 October 2017 at 02:11, Vinny Lingham via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > I?d love to get a sense of what the hash rate threshold will be for > exchanges to stop accepting 1x coin, even with 6 confirmations? With the > risk of a selfish mining attack increasing the lower the 1x hashrate is, > why would an exchange accept the coins knowing that someone could be double > spending across multiple exchanges? > > https://bitcointalk.org/index.php?topic=2127697.0 > > I?m just trying to understand this attack vector better... I haven?t heard > a good response to this question yet - would really appreciate some insight > here. This is largely why I believe hashrate secures the network and why > I?ve been against the UASF. > It will vary according to the exchange. Trex and so will be conservative, and maybe go as high as 30 confirms for the seg2x minority chain What's likely to happen in an efficient mining market is that bitcoin will get 100% hashing, and the seg2x chain will get 0% hashing in an efficient market. This is not unusual with forks, it is very very common. Therefore, the seg2x chain will require subsidy to reach the first difficulty rebase of (insert estimate here?) lets say of the order of 7 million usd a day (too high? too low?) Believers will subsidise the chain until they get tired of it. We've seen this with bitcoin cash, and 100 other alt coins. The big winners will be the exchanges, and likely there will be many (eg smaller exchanges trying to gain market share) with as low as 1-2 confirms, to give themselves an advantage. This scenario doesnt actually benefit any rational stake holder. I would assume experienced miners could just end it by stopping signaling NYA. > > > Sent from my iPad > > On Oct 24, 2017, at 13:26, Erik Aronesty via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > At this point *either* chain can be the "legacy" chain. Most exchanges > are going to support both coins. Coinbase's announcement that 2x will be > initially called B2X was big (they reserve the right to rename it later). > > Users will be thus be free to dump either coin according to their personal > feelings on the matter. > > Hashpower is probably not going to be a consideration for the majority of > holders. At the end of the day... if users dump 1x, miners will jump on > 2x, and if users dump 2x, miners will jump on 1x. > > Trying to predict what investors and users will do is really not > "politics". It's pure speculation. And basing any real decisions off > "hashpower signaling" is patently absurd. > > In other words: > > - This is a risky proposition either way > - There is no reasonable way to predict the outcome > > Anyone who claims otherwise is probably entrenched in a particular "camp", > and isn't thinking rationally about the current situation. > > (Personally, I'm simply going to dump on the first day... regardless of > the price and based on my preference. I suspect I'm in the minority here.) > > > On Tue, Oct 24, 2017 at 4:16 PM, Phillip Katete via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Unfortunately, it is a double whammy for the legacy chain. >> >> >> >> Despite there being a general assumption that the legacy chain will have >> at least 20% of the current network hash, it?s going to be less than that >> and more likely the majority of that hash will mine coinbase only blocks in >> order to stall the chain. The closer the attack happens to the fork time >> (and therefore unknown block times & mempool), the more potent the attack >> as the fees will still be low relative to when block times are more >> accurately predicted and mempool settled. >> >> >> >> Once confirmation times on the legacy chain become unusually long (and >> the price begins to tend to reflect that), then attackers can abandon the >> chain and the ardent legacy miners will also start divesting/splitting >> their hash to the 2x chain. >> >> >> >> *From: *Peter BitcoinReminder.com via Bitcoin-segwit2x >> >> *Sent: *24 October 2017 20:41 >> *To: *Erik Voorhees >> *Cc: *Melvin Carvalho via Bitcoin-segwit2x >> >> *Subject: *Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, >> guarantee) - Ensuring a smooth 2X upgrade without a chain split >> >> >> >> You are also missing the point that many people dont use bitcoin for >> payments - but as store of value - so they don?t care if there are long >> confirmation times (or even none in one week!) - you only see it from the >> payment/transaction side, but this is not the case for many people which >> are motivated to stay and fight for bitcoin. >> >> >> >> Open your mind - there are many people which give a shit about >> confirmation times and fees. >> >> >> >> Am 24.10.2017 um 21:04 schrieb Erik Voorhees via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org>: >> >> >> >> Peter - I disagree that 1x won?t have a market price. Exchanges can turn >> off all deposits and withdraws completely for a week and you?ll still see >> markets of both coins working, because there is already 1x and 2x in the >> exchanges (in large quantities). >> >> >> >> >> >> >> >> Kind regards, >> >> -Erik Voorhees >> >> CEO ShapeShift AG >> >> >> >> On October 24, 2017 at 12:59:28 PM, Peter (dizzle at pointbiz.com) wrote: >> >> I agree the minority chain will quickly grind to a halt. Pure SPV users >> will just want Bitcoin to work as Moe indicated. They won't know if they >> are on the 1x or 2x chain but what they will know is Bitcoin (BTC) still >> works and in 1 day 2x (BTC) will pass 100 blocks and have a market price >> and be usable by exchanges globally. The 1x chain will not have a market >> price for 5 days because it didn't reach the 100 block milestone to enable >> deposits and coin splitting. In that time it can die out. Also, it's likely >> to take an extra week or so for exchanges to get all their coin splitting >> transactions confirmed by mixing with 1x coinbases. Honeybadger won't care >> much and people won't want to say 1x is BTC because then they have to admit >> BTC had a 1 or 2 week service interruption. >> >> >> >> Sorry if this is not technical enough for the list. >> >> >> >> Regards >> >> Peter >> >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at bloq.com Wed Oct 25 17:54:10 2017 From: jeff at bloq.com (Jeff Garzik) Date: Wed, 25 Oct 2017 10:54:10 -0700 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update Message-ID: Hi all! This is a follow-on from the previous status update in August: https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html 1. To state the obvious, everything is still full steam ahead for segwit2x upgrade in mid-November. 2. As noted in August, the project continues to be in a code freeze for the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) Only changes or fixes thought to be important pre-fork will be included. 3. Reviewing the btc1 project and branch policies, btc1 is a source code fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution intended for end users. As such, we track Bitcoin Core updates as necessary and pull those into the project. 4. "segwit2x" is the production release branch for the SegWit2x Working Group, and the latest release can be downloaded here: https://github.com/btc1/bitcoin/releases/tag/v1.14.5 5. "segwit2x-dev" is the development and testing release branch. New changes go to segwit2x-dev first, for external testing and feedback, before being merged into the production branch, and labelled a production release. 6. The current segwit2x production release, on the segwit2x branch, is based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin Core 0.15.x. 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. Based on instability and bugs that upstream Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the November fork. This is the most stable path for users, based on upstream Bitcoin Core instability. In short we -do not- feel that Bitcoin Core bugs and instability will impact our project in the short term, because this is not yet in a segwit2x production release on a production branch. 8. The only change worth noting is a likely be an adjustment of miner policy defaults that will be accepted through the code freeze: https://github.com/btc1/bitcoin/pull/136 Thanks everyone! -- Jeff Garzik CEO and Co Founder Bloq, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe.biocca at gmail.com Wed Oct 25 18:08:16 2017 From: christophe.biocca at gmail.com (Christophe Biocca) Date: Wed, 25 Oct 2017 14:08:16 -0400 Subject: [Bitcoin-segwit2x] Orderly Process for Coin-Splitting after the fork In-Reply-To: <1508919878.3804114.1150261632.0DD7BDDB@webmail.messagingengine.com> References: <1508919878.3804114.1150261632.0DD7BDDB@webmail.messagingengine.com> Message-ID: I'll also mention for completeness that the big-block bounty transaction ( http://www.blockbounties.info/) has many anyone-can spend outputs which are meant to be used to enable anyone else to add funds to the bounty, but also effectively can be used for splitting funds. This is similar to the coinbase-tx approach, but can happen essentially immediately post fork (no need to wait 100 blocks). The downside is that the originator of the transaction could invalidate it before the fork happens, so it's not 100% guaranteed to work. On 25 October 2017 at 04:24, Tomas via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > On Tue, Oct 24, 2017, at 22:41, Moe Adham via Bitcoin-segwit2x wrote: > > > Coinbase: Have miners agree to send a small amount of newly generated > coins to wallet operators as quickly as possible after the fork, to allow > wallet operators to split wallets > > > I don't think miners actually need to send these coins to wallet > operators. > > A miner or someone else who has acquired some newly minted coins can > create transactions with one input and one output that pay to self with > SIGHASH_SINGLE | SIGHASH_ANYONECANPAY and provide these replay protected > transaction "templates" in large numbers over an API for everyone to use. > > Tomas > bitcrust > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Wed Oct 25 18:19:31 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Wed, 25 Oct 2017 20:19:31 +0200 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Hi all! > > This is a follow-on from the previous status update in August: > https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/ > 000265.html > > 1. To state the obvious, everything is still full steam ahead for segwit2x > upgrade in mid-November. > > 2. As noted in August, the project continues to be in a code freeze for > the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) > Only changes or fixes thought to be important pre-fork will be included. > > 3. Reviewing the btc1 project and branch policies, btc1 is a source code > fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution > intended for end users. As such, we track Bitcoin Core updates as > necessary and pull those into the project. > > 4. "segwit2x" is the production release branch for the SegWit2x Working > Group, and the latest release can be downloaded here: > https://github.com/btc1/bitcoin/releases/tag/v1.14.5 > > 5. "segwit2x-dev" is the development and testing release branch. New > changes go to segwit2x-dev first, for external testing and feedback, before > being merged into the production branch, and labelled a production release. > > 6. The current segwit2x production release, on the segwit2x branch, is > based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin > Core 0.15.x. > > 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. > Based on instability and bugs that upstream Bitcoin Core project is seeing > - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x > through the November fork. This is the most stable path for users, based > on upstream Bitcoin Core instability. > > In short we -do not- feel that Bitcoin Core bugs and instability will > impact our project in the short term, because this is not yet in a segwit2x > production release on a production branch. > > 8. The only change worth noting is a likely be an adjustment of miner > policy defaults that will be accepted through the code freeze: > https://github.com/btc1/bitcoin/pull/136 > > Thanks everyone! > Thanks for the update. There was a question on a previous thread that I think went unanswered. Is the threshold for release still 80% miner signaling? If miner signaling for NYA falls significantly, would it be considered new information? FYI: latest metric is NYA signaling at 75% in the last 24h [1], with the position of ViaBTC still unclear [1] https://coin.dance/blocks > > > -- > Jeff Garzik > CEO and Co Founder > Bloq, Inc. > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Wed Oct 25 18:28:17 2017 From: bitpico at icloud.com (bitPico) Date: Wed, 25 Oct 2017 14:28:17 -0400 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Thanks Jeff! > On Oct 25, 2017, at 1:54 PM, Jeff Garzik via Bitcoin-segwit2x wrote: > > Hi all! > > This is a follow-on from the previous status update in August: https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html > > 1. To state the obvious, everything is still full steam ahead for segwit2x upgrade in mid-November. > > 2. As noted in August, the project continues to be in a code freeze for the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) Only changes or fixes thought to be important pre-fork will be included. > > 3. Reviewing the btc1 project and branch policies, btc1 is a source code fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution intended for end users. As such, we track Bitcoin Core updates as necessary and pull those into the project. > > 4. "segwit2x" is the production release branch for the SegWit2x Working Group, and the latest release can be downloaded here: https://github.com/btc1/bitcoin/releases/tag/v1.14.5 > > 5. "segwit2x-dev" is the development and testing release branch. New changes go to segwit2x-dev first, for external testing and feedback, before being merged into the production branch, and labelled a production release. > > 6. The current segwit2x production release, on the segwit2x branch, is based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin Core 0.15.x. > > 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. Based on instability and bugs that upstream Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the November fork. This is the most stable path for users, based on upstream Bitcoin Core instability. > > In short we -do not- feel that Bitcoin Core bugs and instability will impact our project in the short term, because this is not yet in a segwit2x production release on a production branch. > > 8. The only change worth noting is a likely be an adjustment of miner policy defaults that will be accepted through the code freeze: https://github.com/btc1/bitcoin/pull/136 > > Thanks everyone! > > -- > Jeff Garzik > CEO and Co Founder > Bloq, Inc. > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Wed Oct 25 18:32:40 2017 From: chris at suredbits.com (Chris Stewart) Date: Wed, 25 Oct 2017 13:32:40 -0500 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Has there been any thought to who will be maintaining B2X after the chain split is completed? It seems the only dev, Jeff, has committed his time to a new project called Metronome . It doesn't appear that any significant portion of the bitcoin core developers are willing to put their time and effort into this project. So is the plan to just fork and abandon the btc1 codebase? -Chris On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > > On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Hi all! >> >> This is a follow-on from the previous status update in August: >> https://lists.linuxfoundation.org/pipermail/bitcoin- >> segwit2x/2017-August/000265.html >> >> 1. To state the obvious, everything is still full steam ahead for >> segwit2x upgrade in mid-November. >> >> 2. As noted in August, the project continues to be in a code freeze for >> the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) >> Only changes or fixes thought to be important pre-fork will be included. >> >> 3. Reviewing the btc1 project and branch policies, btc1 is a source code >> fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution >> intended for end users. As such, we track Bitcoin Core updates as >> necessary and pull those into the project. >> >> 4. "segwit2x" is the production release branch for the SegWit2x Working >> Group, and the latest release can be downloaded here: >> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >> >> 5. "segwit2x-dev" is the development and testing release branch. New >> changes go to segwit2x-dev first, for external testing and feedback, before >> being merged into the production branch, and labelled a production release. >> >> 6. The current segwit2x production release, on the segwit2x branch, is >> based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin >> Core 0.15.x. >> >> 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. >> Based on instability and bugs that upstream Bitcoin Core project is seeing >> - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x >> through the November fork. This is the most stable path for users, based >> on upstream Bitcoin Core instability. >> >> In short we -do not- feel that Bitcoin Core bugs and instability will >> impact our project in the short term, because this is not yet in a segwit2x >> production release on a production branch. >> >> 8. The only change worth noting is a likely be an adjustment of miner >> policy defaults that will be accepted through the code freeze: >> https://github.com/btc1/bitcoin/pull/136 >> >> Thanks everyone! >> > > Thanks for the update. > > There was a question on a previous thread that I think went unanswered. > > Is the threshold for release still 80% miner signaling? > > If miner signaling for NYA falls significantly, would it be considered new > information? > > FYI: latest metric is NYA signaling at 75% in the last 24h [1], with the > position of ViaBTC still unclear > > [1] https://coin.dance/blocks > >> >> >> -- >> Jeff Garzik >> CEO and Co Founder >> Bloq, Inc. >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at bloq.com Wed Oct 25 18:57:33 2017 From: jeff at bloq.com (Jeff Garzik) Date: Wed, 25 Oct 2017 11:57:33 -0700 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Chris, There is no reallocation of time or commitment. Metronome and Bloq are off-topic on this list, so I'll only cover this once. I run a company, Bloq, with over 25 team members -- not just one. Just like many other companies, we have multiple projects running simultaneously, and Metronome is one of those. Our primary product is BloqEnterprise, which is a supported-Bitcoin product in the style of Red Hat Enterprise Linux. Majority of Bloq revenue comes from Bitcoin. If you are a large enterprise that needs Bitcoin support (or a very well funded startup), we would be happy to discuss a customer agreement. BloqEnterprise v1 is Bitcoin-only; BloqEnterprise v2 will be adding other chains to our product, such as Litecoin or Bitcoin Cash, as well as Eth/Etc support, based on customer demand. Our vision at Bloq has always been: Multi-chain, multi-token, multi-network, with Bitcoin - BTC - as the root of a security tree. As for btc1: As was stated in August, months ago, the code is in feature freeze until after the fork. It is a software engineering goal to keep changes to an absolute minimum, and that is what btc1 is doing. After the fork, btc1 will be continuing as a sort of "Fedora for Bitcoin" -- very exciting stuff, and a useful way to risk adjust versus Bitcoin Core instability or feature selection. Several btc1 members have proposed new btc1 changes for post-fork, large and small. It will be a very nice addition to the Bitcoin community to have an additional outlet for feature requests such as this one, a small change that makes life easier for DevOps: https://github.com/btc1/bitcoin/issues/107 On Wed, Oct 25, 2017 at 11:32 AM, Chris Stewart wrote: > Has there been any thought to who will be maintaining B2X after the chain > split is completed? It seems the only dev, Jeff, has committed his time to > a new project called Metronome > . > It doesn't appear that any significant portion of the bitcoin core > developers are willing to put their time and effort into this project. > > So is the plan to just fork and abandon the btc1 codebase? > > -Chris > > On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> >> >> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> Hi all! >>> >>> This is a follow-on from the previous status update in August: >>> https://lists.linuxfoundation.org/pipermail/bitcoin- >>> segwit2x/2017-August/000265.html >>> >>> 1. To state the obvious, everything is still full steam ahead for >>> segwit2x upgrade in mid-November. >>> >>> 2. As noted in August, the project continues to be in a code freeze for >>> the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) >>> Only changes or fixes thought to be important pre-fork will be included. >>> >>> 3. Reviewing the btc1 project and branch policies, btc1 is a source code >>> fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution >>> intended for end users. As such, we track Bitcoin Core updates as >>> necessary and pull those into the project. >>> >>> 4. "segwit2x" is the production release branch for the SegWit2x Working >>> Group, and the latest release can be downloaded here: >>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>> >>> 5. "segwit2x-dev" is the development and testing release branch. New >>> changes go to segwit2x-dev first, for external testing and feedback, before >>> being merged into the production branch, and labelled a production release. >>> >>> 6. The current segwit2x production release, on the segwit2x branch, is >>> based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin >>> Core 0.15.x. >>> >>> 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. >>> Based on instability and bugs that upstream Bitcoin Core project is >>> seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core >>> 0.14.x through the November fork. This is the most stable path for users, >>> based on upstream Bitcoin Core instability. >>> >>> In short we -do not- feel that Bitcoin Core bugs and instability will >>> impact our project in the short term, because this is not yet in a segwit2x >>> production release on a production branch. >>> >>> 8. The only change worth noting is a likely be an adjustment of miner >>> policy defaults that will be accepted through the code freeze: >>> https://github.com/btc1/bitcoin/pull/136 >>> >>> Thanks everyone! >>> >> >> Thanks for the update. >> >> There was a question on a previous thread that I think went unanswered. >> >> Is the threshold for release still 80% miner signaling? >> >> If miner signaling for NYA falls significantly, would it be considered >> new information? >> >> FYI: latest metric is NYA signaling at 75% in the last 24h [1], with the >> position of ViaBTC still unclear >> >> [1] https://coin.dance/blocks >> >>> >>> >>> -- >>> Jeff Garzik >>> CEO and Co Founder >>> Bloq, Inc. >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > -- Jeff Garzik CEO and Co Founder Bloq, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at wksit.com Wed Oct 25 19:04:26 2017 From: william at wksit.com (William K. Santiago) Date: Wed, 25 Oct 2017 19:04:26 +0000 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Thanks Jeff On Wed, Oct 25, 2017 at 2:58 PM Jeff Garzik via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Chris, > > There is no reallocation of time or commitment. Metronome and Bloq are > off-topic on this list, so I'll only cover this once. > > I run a company, Bloq, with over 25 team members -- not just one. Just > like many other companies, we have multiple projects running > simultaneously, and Metronome is one of those. Our primary product is > BloqEnterprise, which is a supported-Bitcoin product in the style of Red > Hat Enterprise Linux. Majority of Bloq revenue comes from Bitcoin. If you > are a large enterprise that needs Bitcoin support (or a very well funded > startup), we would be happy to discuss a customer agreement. > BloqEnterprise v1 is Bitcoin-only; BloqEnterprise v2 will be adding other > chains to our product, such as Litecoin or Bitcoin Cash, as well as Eth/Etc > support, based on customer demand. > > Our vision at Bloq has always been: Multi-chain, multi-token, > multi-network, with Bitcoin - BTC - as the root of a security tree. > > > As for btc1: As was stated in August, months ago, the code is in feature > freeze until after the fork. It is a software engineering goal to keep > changes to an absolute minimum, and that is what btc1 is doing. > > After the fork, btc1 will be continuing as a sort of "Fedora for Bitcoin" > -- very exciting stuff, and a useful way to risk adjust versus Bitcoin Core > instability or feature selection. Several btc1 members have proposed new > btc1 changes for post-fork, large and small. It will be a very nice > addition to the Bitcoin community to have an additional outlet for feature > requests such as this one, a small change that makes life easier for > DevOps: https://github.com/btc1/bitcoin/issues/107 > > > > > > > > On Wed, Oct 25, 2017 at 11:32 AM, Chris Stewart > wrote: > >> Has there been any thought to who will be maintaining B2X after the chain >> split is completed? It seems the only dev, Jeff, has committed his time to >> a new project called Metronome >> . >> It doesn't appear that any significant portion of the bitcoin core >> developers are willing to put their time and effort into this project. >> >> So is the plan to just fork and abandon the btc1 codebase? >> >> -Chris >> >> On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> >>> >>> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> Hi all! >>>> >>>> This is a follow-on from the previous status update in August: >>>> https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html >>>> >>>> 1. To state the obvious, everything is still full steam ahead for >>>> segwit2x upgrade in mid-November. >>>> >>>> 2. As noted in August, the project continues to be in a code freeze for >>>> the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) >>>> Only changes or fixes thought to be important pre-fork will be included. >>>> >>>> 3. Reviewing the btc1 project and branch policies, btc1 is a source >>>> code fork of Bitcoin Core, very much like Fedora Linux is a >>>> fork/distribution intended for end users. As such, we track Bitcoin Core >>>> updates as necessary and pull those into the project. >>>> >>>> 4. "segwit2x" is the production release branch for the SegWit2x Working >>>> Group, and the latest release can be downloaded here: >>>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>>> >>>> 5. "segwit2x-dev" is the development and testing release branch. New >>>> changes go to segwit2x-dev first, for external testing and feedback, before >>>> being merged into the production branch, and labelled a production release. >>>> >>>> 6. The current segwit2x production release, on the segwit2x branch, is >>>> based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin >>>> Core 0.15.x. >>>> >>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. >>>> Based on instability and bugs that upstream Bitcoin Core project is >>>> seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core >>>> 0.14.x through the November fork. This is the most stable path for users, >>>> based on upstream Bitcoin Core instability. >>>> >>>> In short we -do not- feel that Bitcoin Core bugs and instability will >>>> impact our project in the short term, because this is not yet in a segwit2x >>>> production release on a production branch. >>>> >>>> 8. The only change worth noting is a likely be an adjustment of miner >>>> policy defaults that will be accepted through the code freeze: >>>> https://github.com/btc1/bitcoin/pull/136 >>>> >>>> Thanks everyone! >>>> >>> >>> Thanks for the update. >>> >>> There was a question on a previous thread that I think went unanswered. >>> >>> Is the threshold for release still 80% miner signaling? >>> >>> If miner signaling for NYA falls significantly, would it be considered >>> new information? >>> >>> FYI: latest metric is NYA signaling at 75% in the last 24h [1], with the >>> position of ViaBTC still unclear >>> >>> [1] https://coin.dance/blocks >>> >>>> >>>> >>>> -- >>>> Jeff Garzik >>>> CEO and Co Founder >>>> Bloq, Inc. >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> > > > -- > Jeff Garzik > CEO and Co Founder > Bloq, Inc. > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- William K. Santiago, C4 CBP WhatsApp +1-716-222-0886 https://about.me/wksantiago https://onename.io/williamsantiago My Resume: https://www.linkedin.com/in/wksantiago Secure e-mail: williamsantiago at protonmail.com Public OpenPGP key: https://goo.gl/9XvzY5 https://keybase.io/williamsantiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Wed Oct 25 19:04:56 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Wed, 25 Oct 2017 19:04:56 +0000 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: , Message-ID: Master Jeff thanks for the update. I was hoping this update would herald btc1 as the new bitcoin reference client post Nov HF, but having read you latter message I am pleased that there is a commitment to keep the client up to date post fork. I suppose that?ll suffice as it?ll effectively become the reference client in all but name. All good. * Is the threshold for release still 80% miner signaling? * If miner signaling for NYA falls significantly, would it be considered new information? * FYI: latest metric is NYA signaling at 75% in the last 24h [1], with the position of ViaBTC still unclear * [1] https://coin.dance/blocks Why would the threshold (if any that is) be compared to metrics based on 24h signalling when the upgrade was in the works for over 2 years? The upgrade was activated and locked-in over 2 difficulty adjustment windows, which I suggest would be an appropriate time-span to gather metrics when suggesting a threshold. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugh at anxintl.com Wed Oct 25 19:41:35 2017 From: hugh at anxintl.com (Hugh Madden) Date: Thu, 26 Oct 2017 03:41:35 +0800 Subject: [Bitcoin-segwit2x] Orderly Process for Coin-Splitting after the fork In-Reply-To: References: <1508919878.3804114.1150261632.0DD7BDDB@webmail.messagingengine.com> Message-ID: If I understand correctly, using s2x's opt in replay protection is the only option that will work safe without needing ongoing splitting for every utxo. With ETH/ETH account based blockchain you could just do something to invalidate the nonce and job done. With 1X / 2X I think you need to split every single uxto. Easier I think to just use the opt-in replay protection. The helps with the sends side of the equation. The bigger issue is deposits and extended period chain reorgs due to flip flopping of hash rate over the two chains. I don't have any solution for this except an extended outage. Any thoughts on how many blocks are required to be safe from extended period chain reorgs ? On 25 Oct. 2017 11:08 am, "Christophe Biocca via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > I'll also mention for completeness that the big-block bounty transaction ( > http://www.blockbounties.info/) has many anyone-can spend outputs which > are meant to be used to enable anyone else to add funds to the bounty, but > also effectively can be used for splitting funds. > > This is similar to the coinbase-tx approach, but can happen essentially > immediately post fork (no need to wait 100 blocks). > > The downside is that the originator of the transaction could invalidate it > before the fork happens, so it's not 100% guaranteed to work. > > On 25 October 2017 at 04:24, Tomas via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> On Tue, Oct 24, 2017, at 22:41, Moe Adham via Bitcoin-segwit2x wrote: >> >> >> Coinbase: Have miners agree to send a small amount of newly generated >> coins to wallet operators as quickly as possible after the fork, to allow >> wallet operators to split wallets >> >> >> I don't think miners actually need to send these coins to wallet >> operators. >> >> A miner or someone else who has acquired some newly minted coins can >> create transactions with one input and one output that pay to self with >> SIGHASH_SINGLE | SIGHASH_ANYONECANPAY and provide these replay protected >> transaction "templates" in large numbers over an API for everyone to use. >> >> Tomas >> bitcrust >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morcos at gmail.com Wed Oct 25 19:46:23 2017 From: morcos at gmail.com (Alex Morcos) Date: Wed, 25 Oct 2017 15:46:23 -0400 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Jeff, I'd just like to clarify what you envision for btc1 after the fork. Let's assume 1X wins: OK, makes sense to me, additional implementation with extra features. Let's assume 2X wins: There is no Bitcoin Core working on "Bitcoin". Bitcoin Core will either work on the minority chain (with different rules!) for as long as that seems like it has a chance to be the Bitcoin again OR it will just cease to exist. The model of continuing to base development off of the work of Bitcoin Core contributors when Bitcoin is clearly defined by the 2X rules just doesn't make sense. There will be no Bitcoin Core contributors working on the 2X rules (or very few). I'm not someone who thinks that the contributors to the Bitcoin Core project are the only ones who can do this, but I think you should have some plan for who is going to work on it. It won't be btc1 and Bitcoin Core, it'll just be btc1 after the fork (I don't know and maybe Classic/Unlimited?) NB: I think this has very low probability, but it's kind of crazy to me that you don't even have a plan for what to do if you succeed. On Wed, Oct 25, 2017 at 2:57 PM, Jeff Garzik via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Chris, > > There is no reallocation of time or commitment. Metronome and Bloq are > off-topic on this list, so I'll only cover this once. > > I run a company, Bloq, with over 25 team members -- not just one. Just > like many other companies, we have multiple projects running > simultaneously, and Metronome is one of those. Our primary product is > BloqEnterprise, which is a supported-Bitcoin product in the style of Red > Hat Enterprise Linux. Majority of Bloq revenue comes from Bitcoin. If you > are a large enterprise that needs Bitcoin support (or a very well funded > startup), we would be happy to discuss a customer agreement. > BloqEnterprise v1 is Bitcoin-only; BloqEnterprise v2 will be adding other > chains to our product, such as Litecoin or Bitcoin Cash, as well as Eth/Etc > support, based on customer demand. > > Our vision at Bloq has always been: Multi-chain, multi-token, > multi-network, with Bitcoin - BTC - as the root of a security tree. > > > As for btc1: As was stated in August, months ago, the code is in feature > freeze until after the fork. It is a software engineering goal to keep > changes to an absolute minimum, and that is what btc1 is doing. > > After the fork, btc1 will be continuing as a sort of "Fedora for Bitcoin" > -- very exciting stuff, and a useful way to risk adjust versus Bitcoin Core > instability or feature selection. Several btc1 members have proposed new > btc1 changes for post-fork, large and small. It will be a very nice > addition to the Bitcoin community to have an additional outlet for feature > requests such as this one, a small change that makes life easier for > DevOps: https://github.com/btc1/bitcoin/issues/107 > > > > > > > > On Wed, Oct 25, 2017 at 11:32 AM, Chris Stewart > wrote: > >> Has there been any thought to who will be maintaining B2X after the chain >> split is completed? It seems the only dev, Jeff, has committed his time to >> a new project called Metronome >> . >> It doesn't appear that any significant portion of the bitcoin core >> developers are willing to put their time and effort into this project. >> >> So is the plan to just fork and abandon the btc1 codebase? >> >> -Chris >> >> On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> >>> >>> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> Hi all! >>>> >>>> This is a follow-on from the previous status update in August: >>>> https://lists.linuxfoundation.org/pipermail/bitcoin- >>>> segwit2x/2017-August/000265.html >>>> >>>> 1. To state the obvious, everything is still full steam ahead for >>>> segwit2x upgrade in mid-November. >>>> >>>> 2. As noted in August, the project continues to be in a code freeze for >>>> the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) >>>> Only changes or fixes thought to be important pre-fork will be included. >>>> >>>> 3. Reviewing the btc1 project and branch policies, btc1 is a source >>>> code fork of Bitcoin Core, very much like Fedora Linux is a >>>> fork/distribution intended for end users. As such, we track Bitcoin Core >>>> updates as necessary and pull those into the project. >>>> >>>> 4. "segwit2x" is the production release branch for the SegWit2x Working >>>> Group, and the latest release can be downloaded here: >>>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>>> >>>> 5. "segwit2x-dev" is the development and testing release branch. New >>>> changes go to segwit2x-dev first, for external testing and feedback, before >>>> being merged into the production branch, and labelled a production release. >>>> >>>> 6. The current segwit2x production release, on the segwit2x branch, is >>>> based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin >>>> Core 0.15.x. >>>> >>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. >>>> Based on instability and bugs that upstream Bitcoin Core project is >>>> seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core >>>> 0.14.x through the November fork. This is the most stable path for users, >>>> based on upstream Bitcoin Core instability. >>>> >>>> In short we -do not- feel that Bitcoin Core bugs and instability will >>>> impact our project in the short term, because this is not yet in a segwit2x >>>> production release on a production branch. >>>> >>>> 8. The only change worth noting is a likely be an adjustment of miner >>>> policy defaults that will be accepted through the code freeze: >>>> https://github.com/btc1/bitcoin/pull/136 >>>> >>>> Thanks everyone! >>>> >>> >>> Thanks for the update. >>> >>> There was a question on a previous thread that I think went unanswered. >>> >>> Is the threshold for release still 80% miner signaling? >>> >>> If miner signaling for NYA falls significantly, would it be considered >>> new information? >>> >>> FYI: latest metric is NYA signaling at 75% in the last 24h [1], with the >>> position of ViaBTC still unclear >>> >>> [1] https://coin.dance/blocks >>> >>>> >>>> >>>> -- >>>> Jeff Garzik >>>> CEO and Co Founder >>>> Bloq, Inc. >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> > > > -- > Jeff Garzik > CEO and Co Founder > Bloq, Inc. > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at bloq.com Wed Oct 25 19:53:12 2017 From: jeff at bloq.com (Jeff Garzik) Date: Wed, 25 Oct 2017 12:53:12 -0700 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Alex, The plan was already stated in the thread. This is a well defined open source pattern and situation. btc1 will continue as a sort of Fedora for Bitcoin after the fork. It is irrelevant whether or not Bitcoin Core merges patches such as the 2X patches. The codebase remains 99% the same either way. That is what Fedora does on Linux: Carry patches that haven't made their way upstream. Either the upstream developers merge or they don't; either way, the project continues. Consider reviewing another example from open source history, the GCC vs. EGCS situation. https://gcc.gnu.org/wiki/History#EGCS On Wed, Oct 25, 2017 at 12:46 PM, Alex Morcos wrote: > Jeff, I'd just like to clarify what you envision for btc1 after the fork. > > Let's assume 1X wins: OK, makes sense to me, additional implementation > with extra features. > > Let's assume 2X wins: There is no Bitcoin Core working on "Bitcoin". > Bitcoin Core will either work on the minority chain (with different rules!) > for as long as that seems like it has a chance to be the Bitcoin again OR > it will just cease to exist. The model of continuing to base development > off of the work of Bitcoin Core contributors when Bitcoin is clearly > defined by the 2X rules just doesn't make sense. There will be no Bitcoin > Core contributors working on the 2X rules (or very few). I'm not someone > who thinks that the contributors to the Bitcoin Core project are the only > ones who can do this, but I think you should have some plan for who is > going to work on it. It won't be btc1 and Bitcoin Core, it'll just be btc1 > after the fork (I don't know and maybe Classic/Unlimited?) > > NB: I think this has very low probability, but it's kind of crazy to me > that you don't even have a plan for what to do if you succeed. > > > > > > > > On Wed, Oct 25, 2017 at 2:57 PM, Jeff Garzik via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Chris, >> >> There is no reallocation of time or commitment. Metronome and Bloq are >> off-topic on this list, so I'll only cover this once. >> >> I run a company, Bloq, with over 25 team members -- not just one. Just >> like many other companies, we have multiple projects running >> simultaneously, and Metronome is one of those. Our primary product is >> BloqEnterprise, which is a supported-Bitcoin product in the style of Red >> Hat Enterprise Linux. Majority of Bloq revenue comes from Bitcoin. If you >> are a large enterprise that needs Bitcoin support (or a very well funded >> startup), we would be happy to discuss a customer agreement. >> BloqEnterprise v1 is Bitcoin-only; BloqEnterprise v2 will be adding other >> chains to our product, such as Litecoin or Bitcoin Cash, as well as Eth/Etc >> support, based on customer demand. >> >> Our vision at Bloq has always been: Multi-chain, multi-token, >> multi-network, with Bitcoin - BTC - as the root of a security tree. >> >> >> As for btc1: As was stated in August, months ago, the code is in >> feature freeze until after the fork. It is a software engineering goal to >> keep changes to an absolute minimum, and that is what btc1 is doing. >> >> After the fork, btc1 will be continuing as a sort of "Fedora for Bitcoin" >> -- very exciting stuff, and a useful way to risk adjust versus Bitcoin Core >> instability or feature selection. Several btc1 members have proposed new >> btc1 changes for post-fork, large and small. It will be a very nice >> addition to the Bitcoin community to have an additional outlet for feature >> requests such as this one, a small change that makes life easier for >> DevOps: https://github.com/btc1/bitcoin/issues/107 >> >> >> >> >> >> >> >> On Wed, Oct 25, 2017 at 11:32 AM, Chris Stewart >> wrote: >> >>> Has there been any thought to who will be maintaining B2X after the >>> chain split is completed? It seems the only dev, Jeff, has committed his >>> time to a new project called Metronome >>> . >>> It doesn't appear that any significant portion of the bitcoin core >>> developers are willing to put their time and effort into this project. >>> >>> So is the plan to just fork and abandon the btc1 codebase? >>> >>> -Chris >>> >>> On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> >>>> >>>> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>>> Hi all! >>>>> >>>>> This is a follow-on from the previous status update in August: >>>>> https://lists.linuxfoundation.org/pipermail/bitcoin- >>>>> segwit2x/2017-August/000265.html >>>>> >>>>> 1. To state the obvious, everything is still full steam ahead for >>>>> segwit2x upgrade in mid-November. >>>>> >>>>> 2. As noted in August, the project continues to be in a code freeze >>>>> for the fork: https://en.wikipedia.org/wiki >>>>> /Freeze_(software_engineering) Only changes or fixes thought to be >>>>> important pre-fork will be included. >>>>> >>>>> 3. Reviewing the btc1 project and branch policies, btc1 is a source >>>>> code fork of Bitcoin Core, very much like Fedora Linux is a >>>>> fork/distribution intended for end users. As such, we track Bitcoin Core >>>>> updates as necessary and pull those into the project. >>>>> >>>>> 4. "segwit2x" is the production release branch for the SegWit2x >>>>> Working Group, and the latest release can be downloaded here: >>>>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>>>> >>>>> 5. "segwit2x-dev" is the development and testing release branch. New >>>>> changes go to segwit2x-dev first, for external testing and feedback, before >>>>> being merged into the production branch, and labelled a production release. >>>>> >>>>> 6. The current segwit2x production release, on the segwit2x branch, is >>>>> based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin >>>>> Core 0.15.x. >>>>> >>>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x >>>>> rollout. Based on instability and bugs that upstream Bitcoin Core >>>>> project is seeing - ie. Core's bugs not ours - segwit2x will stay on >>>>> Bitcoin Core 0.14.x through the November fork. This is the most stable >>>>> path for users, based on upstream Bitcoin Core instability. >>>>> >>>>> In short we -do not- feel that Bitcoin Core bugs and instability will >>>>> impact our project in the short term, because this is not yet in a segwit2x >>>>> production release on a production branch. >>>>> >>>>> 8. The only change worth noting is a likely be an adjustment of miner >>>>> policy defaults that will be accepted through the code freeze: >>>>> https://github.com/btc1/bitcoin/pull/136 >>>>> >>>>> Thanks everyone! >>>>> >>>> >>>> Thanks for the update. >>>> >>>> There was a question on a previous thread that I think went unanswered. >>>> >>>> Is the threshold for release still 80% miner signaling? >>>> >>>> If miner signaling for NYA falls significantly, would it be considered >>>> new information? >>>> >>>> FYI: latest metric is NYA signaling at 75% in the last 24h [1], with >>>> the position of ViaBTC still unclear >>>> >>>> [1] https://coin.dance/blocks >>>> >>>>> >>>>> >>>>> -- >>>>> Jeff Garzik >>>>> CEO and Co Founder >>>>> Bloq, Inc. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >> >> >> -- >> Jeff Garzik >> CEO and Co Founder >> Bloq, Inc. >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > -- Jeff Garzik CEO and Co Founder Bloq, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From morcos at gmail.com Wed Oct 25 19:57:25 2017 From: morcos at gmail.com (Alex Morcos) Date: Wed, 25 Oct 2017 15:57:25 -0400 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Yes but you're assuming the continued existence of the Bitcoin Core project, but in the hypothetical situation where Segwit2X is the completely dominant chain, there is no continued existence of the Bitcoin Core project. There is no upstream in this scenario. On Wed, Oct 25, 2017 at 3:53 PM, Jeff Garzik wrote: > Alex, > > The plan was already stated in the thread. This is a well defined open > source pattern and situation. btc1 will continue as a sort of Fedora for > Bitcoin after the fork. > > It is irrelevant whether or not Bitcoin Core merges patches such as the 2X > patches. The codebase remains 99% the same either way. > > That is what Fedora does on Linux: Carry patches that haven't made their > way upstream. Either the upstream developers merge or they don't; either > way, the project continues. > > Consider reviewing another example from open source history, the GCC vs. > EGCS situation. https://gcc.gnu.org/wiki/History#EGCS > > > > On Wed, Oct 25, 2017 at 12:46 PM, Alex Morcos wrote: > >> Jeff, I'd just like to clarify what you envision for btc1 after the fork. >> >> Let's assume 1X wins: OK, makes sense to me, additional implementation >> with extra features. >> >> Let's assume 2X wins: There is no Bitcoin Core working on "Bitcoin". >> Bitcoin Core will either work on the minority chain (with different rules!) >> for as long as that seems like it has a chance to be the Bitcoin again OR >> it will just cease to exist. The model of continuing to base development >> off of the work of Bitcoin Core contributors when Bitcoin is clearly >> defined by the 2X rules just doesn't make sense. There will be no Bitcoin >> Core contributors working on the 2X rules (or very few). I'm not someone >> who thinks that the contributors to the Bitcoin Core project are the only >> ones who can do this, but I think you should have some plan for who is >> going to work on it. It won't be btc1 and Bitcoin Core, it'll just be btc1 >> after the fork (I don't know and maybe Classic/Unlimited?) >> >> NB: I think this has very low probability, but it's kind of crazy to me >> that you don't even have a plan for what to do if you succeed. >> >> >> >> >> >> >> >> On Wed, Oct 25, 2017 at 2:57 PM, Jeff Garzik via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> Chris, >>> >>> There is no reallocation of time or commitment. Metronome and Bloq are >>> off-topic on this list, so I'll only cover this once. >>> >>> I run a company, Bloq, with over 25 team members -- not just one. Just >>> like many other companies, we have multiple projects running >>> simultaneously, and Metronome is one of those. Our primary product is >>> BloqEnterprise, which is a supported-Bitcoin product in the style of Red >>> Hat Enterprise Linux. Majority of Bloq revenue comes from Bitcoin. If you >>> are a large enterprise that needs Bitcoin support (or a very well funded >>> startup), we would be happy to discuss a customer agreement. >>> BloqEnterprise v1 is Bitcoin-only; BloqEnterprise v2 will be adding other >>> chains to our product, such as Litecoin or Bitcoin Cash, as well as Eth/Etc >>> support, based on customer demand. >>> >>> Our vision at Bloq has always been: Multi-chain, multi-token, >>> multi-network, with Bitcoin - BTC - as the root of a security tree. >>> >>> >>> As for btc1: As was stated in August, months ago, the code is in >>> feature freeze until after the fork. It is a software engineering goal to >>> keep changes to an absolute minimum, and that is what btc1 is doing. >>> >>> After the fork, btc1 will be continuing as a sort of "Fedora for >>> Bitcoin" -- very exciting stuff, and a useful way to risk adjust versus >>> Bitcoin Core instability or feature selection. Several btc1 members have >>> proposed new btc1 changes for post-fork, large and small. It will be a >>> very nice addition to the Bitcoin community to have an additional outlet >>> for feature requests such as this one, a small change that makes life >>> easier for DevOps: https://github.com/btc1/bitcoin/issues/107 >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Oct 25, 2017 at 11:32 AM, Chris Stewart >>> wrote: >>> >>>> Has there been any thought to who will be maintaining B2X after the >>>> chain split is completed? It seems the only dev, Jeff, has committed his >>>> time to a new project called Metronome >>>> . >>>> It doesn't appear that any significant portion of the bitcoin core >>>> developers are willing to put their time and effort into this project. >>>> >>>> So is the plan to just fork and abandon the btc1 codebase? >>>> >>>> -Chris >>>> >>>> On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via Bitcoin-segwit2x < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>>> >>>>> >>>>> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < >>>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>>> >>>>>> Hi all! >>>>>> >>>>>> This is a follow-on from the previous status update in August: >>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin- >>>>>> segwit2x/2017-August/000265.html >>>>>> >>>>>> 1. To state the obvious, everything is still full steam ahead for >>>>>> segwit2x upgrade in mid-November. >>>>>> >>>>>> 2. As noted in August, the project continues to be in a code freeze >>>>>> for the fork: https://en.wikipedia.org/wiki >>>>>> /Freeze_(software_engineering) Only changes or fixes thought to be >>>>>> important pre-fork will be included. >>>>>> >>>>>> 3. Reviewing the btc1 project and branch policies, btc1 is a source >>>>>> code fork of Bitcoin Core, very much like Fedora Linux is a >>>>>> fork/distribution intended for end users. As such, we track Bitcoin Core >>>>>> updates as necessary and pull those into the project. >>>>>> >>>>>> 4. "segwit2x" is the production release branch for the SegWit2x >>>>>> Working Group, and the latest release can be downloaded here: >>>>>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>>>>> >>>>>> 5. "segwit2x-dev" is the development and testing release branch. New >>>>>> changes go to segwit2x-dev first, for external testing and feedback, before >>>>>> being merged into the production branch, and labelled a production release. >>>>>> >>>>>> 6. The current segwit2x production release, on the segwit2x branch, >>>>>> is based on Bitcoin Core 0.14.x. The current dev release is based on >>>>>> Bitcoin Core 0.15.x. >>>>>> >>>>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x >>>>>> rollout. Based on instability and bugs that upstream Bitcoin Core >>>>>> project is seeing - ie. Core's bugs not ours - segwit2x will stay on >>>>>> Bitcoin Core 0.14.x through the November fork. This is the most stable >>>>>> path for users, based on upstream Bitcoin Core instability. >>>>>> >>>>>> In short we -do not- feel that Bitcoin Core bugs and instability will >>>>>> impact our project in the short term, because this is not yet in a segwit2x >>>>>> production release on a production branch. >>>>>> >>>>>> 8. The only change worth noting is a likely be an adjustment of miner >>>>>> policy defaults that will be accepted through the code freeze: >>>>>> https://github.com/btc1/bitcoin/pull/136 >>>>>> >>>>>> Thanks everyone! >>>>>> >>>>> >>>>> Thanks for the update. >>>>> >>>>> There was a question on a previous thread that I think went unanswered. >>>>> >>>>> Is the threshold for release still 80% miner signaling? >>>>> >>>>> If miner signaling for NYA falls significantly, would it be considered >>>>> new information? >>>>> >>>>> FYI: latest metric is NYA signaling at 75% in the last 24h [1], with >>>>> the position of ViaBTC still unclear >>>>> >>>>> [1] https://coin.dance/blocks >>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jeff Garzik >>>>>> CEO and Co Founder >>>>>> Bloq, Inc. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Bitcoin-segwit2x mailing list >>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>> >>>>> >>>> >>> >>> >>> -- >>> Jeff Garzik >>> CEO and Co Founder >>> Bloq, Inc. >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> > > > -- > Jeff Garzik > CEO and Co Founder > Bloq, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at bloq.com Wed Oct 25 20:00:25 2017 From: jeff at bloq.com (Jeff Garzik) Date: Wed, 25 Oct 2017 13:00:25 -0700 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Alex, No; the Fedora model exists and works precisely because it risk adjusts against all manner of upstream events: Project idleness, Developer departure, developer grumpiness with some changes otherwise widely accepted by the community, and more. You can read more background at https://en.wikipedia.org/wiki/Fedora_Project On Wed, Oct 25, 2017 at 12:57 PM, Alex Morcos wrote: > Yes but you're assuming the continued existence of the Bitcoin Core > project, but in the hypothetical situation where Segwit2X is the completely > dominant chain, there is no continued existence of the Bitcoin Core project. > There is no upstream in this scenario. > > On Wed, Oct 25, 2017 at 3:53 PM, Jeff Garzik wrote: > >> Alex, >> >> The plan was already stated in the thread. This is a well defined open >> source pattern and situation. btc1 will continue as a sort of Fedora for >> Bitcoin after the fork. >> >> It is irrelevant whether or not Bitcoin Core merges patches such as the >> 2X patches. The codebase remains 99% the same either way. >> >> That is what Fedora does on Linux: Carry patches that haven't made >> their way upstream. Either the upstream developers merge or they don't; >> either way, the project continues. >> >> Consider reviewing another example from open source history, the GCC vs. >> EGCS situation. https://gcc.gnu.org/wiki/History#EGCS >> >> >> >> On Wed, Oct 25, 2017 at 12:46 PM, Alex Morcos wrote: >> >>> Jeff, I'd just like to clarify what you envision for btc1 after the fork. >>> >>> Let's assume 1X wins: OK, makes sense to me, additional implementation >>> with extra features. >>> >>> Let's assume 2X wins: There is no Bitcoin Core working on "Bitcoin". >>> Bitcoin Core will either work on the minority chain (with different rules!) >>> for as long as that seems like it has a chance to be the Bitcoin again OR >>> it will just cease to exist. The model of continuing to base development >>> off of the work of Bitcoin Core contributors when Bitcoin is clearly >>> defined by the 2X rules just doesn't make sense. There will be no Bitcoin >>> Core contributors working on the 2X rules (or very few). I'm not someone >>> who thinks that the contributors to the Bitcoin Core project are the only >>> ones who can do this, but I think you should have some plan for who is >>> going to work on it. It won't be btc1 and Bitcoin Core, it'll just be btc1 >>> after the fork (I don't know and maybe Classic/Unlimited?) >>> >>> NB: I think this has very low probability, but it's kind of crazy to me >>> that you don't even have a plan for what to do if you succeed. >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Oct 25, 2017 at 2:57 PM, Jeff Garzik via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> Chris, >>>> >>>> There is no reallocation of time or commitment. Metronome and Bloq >>>> are off-topic on this list, so I'll only cover this once. >>>> >>>> I run a company, Bloq, with over 25 team members -- not just one. Just >>>> like many other companies, we have multiple projects running >>>> simultaneously, and Metronome is one of those. Our primary product is >>>> BloqEnterprise, which is a supported-Bitcoin product in the style of Red >>>> Hat Enterprise Linux. Majority of Bloq revenue comes from Bitcoin. If you >>>> are a large enterprise that needs Bitcoin support (or a very well funded >>>> startup), we would be happy to discuss a customer agreement. >>>> BloqEnterprise v1 is Bitcoin-only; BloqEnterprise v2 will be adding other >>>> chains to our product, such as Litecoin or Bitcoin Cash, as well as Eth/Etc >>>> support, based on customer demand. >>>> >>>> Our vision at Bloq has always been: Multi-chain, multi-token, >>>> multi-network, with Bitcoin - BTC - as the root of a security tree. >>>> >>>> >>>> As for btc1: As was stated in August, months ago, the code is in >>>> feature freeze until after the fork. It is a software engineering goal to >>>> keep changes to an absolute minimum, and that is what btc1 is doing. >>>> >>>> After the fork, btc1 will be continuing as a sort of "Fedora for >>>> Bitcoin" -- very exciting stuff, and a useful way to risk adjust versus >>>> Bitcoin Core instability or feature selection. Several btc1 members have >>>> proposed new btc1 changes for post-fork, large and small. It will be a >>>> very nice addition to the Bitcoin community to have an additional outlet >>>> for feature requests such as this one, a small change that makes life >>>> easier for DevOps: https://github.com/btc1/bitcoin/issues/107 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Oct 25, 2017 at 11:32 AM, Chris Stewart >>>> wrote: >>>> >>>>> Has there been any thought to who will be maintaining B2X after the >>>>> chain split is completed? It seems the only dev, Jeff, has committed his >>>>> time to a new project called Metronome >>>>> . >>>>> It doesn't appear that any significant portion of the bitcoin core >>>>> developers are willing to put their time and effort into this project. >>>>> >>>>> So is the plan to just fork and abandon the btc1 codebase? >>>>> >>>>> -Chris >>>>> >>>>> On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via Bitcoin-segwit2x >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < >>>>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>>>> >>>>>>> Hi all! >>>>>>> >>>>>>> This is a follow-on from the previous status update in August: >>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin- >>>>>>> segwit2x/2017-August/000265.html >>>>>>> >>>>>>> 1. To state the obvious, everything is still full steam ahead for >>>>>>> segwit2x upgrade in mid-November. >>>>>>> >>>>>>> 2. As noted in August, the project continues to be in a code freeze >>>>>>> for the fork: https://en.wikipedia.org/wiki >>>>>>> /Freeze_(software_engineering) Only changes or fixes thought to >>>>>>> be important pre-fork will be included. >>>>>>> >>>>>>> 3. Reviewing the btc1 project and branch policies, btc1 is a source >>>>>>> code fork of Bitcoin Core, very much like Fedora Linux is a >>>>>>> fork/distribution intended for end users. As such, we track Bitcoin Core >>>>>>> updates as necessary and pull those into the project. >>>>>>> >>>>>>> 4. "segwit2x" is the production release branch for the SegWit2x >>>>>>> Working Group, and the latest release can be downloaded here: >>>>>>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>>>>>> >>>>>>> 5. "segwit2x-dev" is the development and testing release branch. >>>>>>> New changes go to segwit2x-dev first, for external testing and feedback, >>>>>>> before being merged into the production branch, and labelled a production >>>>>>> release. >>>>>>> >>>>>>> 6. The current segwit2x production release, on the segwit2x branch, >>>>>>> is based on Bitcoin Core 0.14.x. The current dev release is based on >>>>>>> Bitcoin Core 0.15.x. >>>>>>> >>>>>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x >>>>>>> rollout. Based on instability and bugs that upstream Bitcoin Core >>>>>>> project is seeing - ie. Core's bugs not ours - segwit2x will stay on >>>>>>> Bitcoin Core 0.14.x through the November fork. This is the most stable >>>>>>> path for users, based on upstream Bitcoin Core instability. >>>>>>> >>>>>>> In short we -do not- feel that Bitcoin Core bugs and instability >>>>>>> will impact our project in the short term, because this is not yet in a >>>>>>> segwit2x production release on a production branch. >>>>>>> >>>>>>> 8. The only change worth noting is a likely be an adjustment of >>>>>>> miner policy defaults that will be accepted through the code freeze: >>>>>>> https://github.com/btc1/bitcoin/pull/136 >>>>>>> >>>>>>> Thanks everyone! >>>>>>> >>>>>> >>>>>> Thanks for the update. >>>>>> >>>>>> There was a question on a previous thread that I think went >>>>>> unanswered. >>>>>> >>>>>> Is the threshold for release still 80% miner signaling? >>>>>> >>>>>> If miner signaling for NYA falls significantly, would it be >>>>>> considered new information? >>>>>> >>>>>> FYI: latest metric is NYA signaling at 75% in the last 24h [1], with >>>>>> the position of ViaBTC still unclear >>>>>> >>>>>> [1] https://coin.dance/blocks >>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jeff Garzik >>>>>>> CEO and Co Founder >>>>>>> Bloq, Inc. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Bitcoin-segwit2x mailing list >>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Bitcoin-segwit2x mailing list >>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Jeff Garzik >>>> CEO and Co Founder >>>> Bloq, Inc. >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >> >> >> -- >> Jeff Garzik >> CEO and Co Founder >> Bloq, Inc. >> >> > -- Jeff Garzik CEO and Co Founder Bloq, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameson.lopp at gmail.com Wed Oct 25 20:04:10 2017 From: jameson.lopp at gmail.com (Jameson Lopp) Date: Wed, 25 Oct 2017 16:04:10 -0400 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Does this mean that there will be a "BTC1 Board" that acts as a governing body? On Wed, Oct 25, 2017 at 4:00 PM, Jeff Garzik via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Alex, > > No; the Fedora model exists and works precisely because it risk adjusts > against all manner of upstream events: Project idleness, Developer > departure, developer grumpiness with some changes otherwise widely accepted > by the community, and more. > > You can read more background at https://en.wikipedia.org/ > wiki/Fedora_Project > > > > On Wed, Oct 25, 2017 at 12:57 PM, Alex Morcos wrote: > >> Yes but you're assuming the continued existence of the Bitcoin Core >> project, but in the hypothetical situation where Segwit2X is the completely >> dominant chain, there is no continued existence of the Bitcoin Core project. >> There is no upstream in this scenario. >> >> On Wed, Oct 25, 2017 at 3:53 PM, Jeff Garzik wrote: >> >>> Alex, >>> >>> The plan was already stated in the thread. This is a well defined open >>> source pattern and situation. btc1 will continue as a sort of Fedora for >>> Bitcoin after the fork. >>> >>> It is irrelevant whether or not Bitcoin Core merges patches such as the >>> 2X patches. The codebase remains 99% the same either way. >>> >>> That is what Fedora does on Linux: Carry patches that haven't made >>> their way upstream. Either the upstream developers merge or they don't; >>> either way, the project continues. >>> >>> Consider reviewing another example from open source history, the GCC vs. >>> EGCS situation. https://gcc.gnu.org/wiki/History#EGCS >>> >>> >>> >>> On Wed, Oct 25, 2017 at 12:46 PM, Alex Morcos wrote: >>> >>>> Jeff, I'd just like to clarify what you envision for btc1 after the >>>> fork. >>>> >>>> Let's assume 1X wins: OK, makes sense to me, additional implementation >>>> with extra features. >>>> >>>> Let's assume 2X wins: There is no Bitcoin Core working on "Bitcoin". >>>> Bitcoin Core will either work on the minority chain (with different rules!) >>>> for as long as that seems like it has a chance to be the Bitcoin again OR >>>> it will just cease to exist. The model of continuing to base development >>>> off of the work of Bitcoin Core contributors when Bitcoin is clearly >>>> defined by the 2X rules just doesn't make sense. There will be no Bitcoin >>>> Core contributors working on the 2X rules (or very few). I'm not someone >>>> who thinks that the contributors to the Bitcoin Core project are the only >>>> ones who can do this, but I think you should have some plan for who is >>>> going to work on it. It won't be btc1 and Bitcoin Core, it'll just be btc1 >>>> after the fork (I don't know and maybe Classic/Unlimited?) >>>> >>>> NB: I think this has very low probability, but it's kind of crazy to me >>>> that you don't even have a plan for what to do if you succeed. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Oct 25, 2017 at 2:57 PM, Jeff Garzik via Bitcoin-segwit2x < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>>> Chris, >>>>> >>>>> There is no reallocation of time or commitment. Metronome and Bloq >>>>> are off-topic on this list, so I'll only cover this once. >>>>> >>>>> I run a company, Bloq, with over 25 team members -- not just one. >>>>> Just like many other companies, we have multiple projects running >>>>> simultaneously, and Metronome is one of those. Our primary product is >>>>> BloqEnterprise, which is a supported-Bitcoin product in the style of Red >>>>> Hat Enterprise Linux. Majority of Bloq revenue comes from Bitcoin. If you >>>>> are a large enterprise that needs Bitcoin support (or a very well funded >>>>> startup), we would be happy to discuss a customer agreement. >>>>> BloqEnterprise v1 is Bitcoin-only; BloqEnterprise v2 will be adding other >>>>> chains to our product, such as Litecoin or Bitcoin Cash, as well as Eth/Etc >>>>> support, based on customer demand. >>>>> >>>>> Our vision at Bloq has always been: Multi-chain, multi-token, >>>>> multi-network, with Bitcoin - BTC - as the root of a security tree. >>>>> >>>>> >>>>> As for btc1: As was stated in August, months ago, the code is in >>>>> feature freeze until after the fork. It is a software engineering goal to >>>>> keep changes to an absolute minimum, and that is what btc1 is doing. >>>>> >>>>> After the fork, btc1 will be continuing as a sort of "Fedora for >>>>> Bitcoin" -- very exciting stuff, and a useful way to risk adjust versus >>>>> Bitcoin Core instability or feature selection. Several btc1 members have >>>>> proposed new btc1 changes for post-fork, large and small. It will be a >>>>> very nice addition to the Bitcoin community to have an additional outlet >>>>> for feature requests such as this one, a small change that makes life >>>>> easier for DevOps: https://github.com/btc1/bitcoin/issues/107 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Oct 25, 2017 at 11:32 AM, Chris Stewart >>>>> wrote: >>>>> >>>>>> Has there been any thought to who will be maintaining B2X after the >>>>>> chain split is completed? It seems the only dev, Jeff, has committed his >>>>>> time to a new project called Metronome >>>>>> . >>>>>> It doesn't appear that any significant portion of the bitcoin core >>>>>> developers are willing to put their time and effort into this project. >>>>>> >>>>>> So is the plan to just fork and abandon the btc1 codebase? >>>>>> >>>>>> -Chris >>>>>> >>>>>> On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via Bitcoin-segwit2x >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < >>>>>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>>>>> >>>>>>>> Hi all! >>>>>>>> >>>>>>>> This is a follow-on from the previous status update in August: >>>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin- >>>>>>>> segwit2x/2017-August/000265.html >>>>>>>> >>>>>>>> 1. To state the obvious, everything is still full steam ahead for >>>>>>>> segwit2x upgrade in mid-November. >>>>>>>> >>>>>>>> 2. As noted in August, the project continues to be in a code freeze >>>>>>>> for the fork: https://en.wikipedia.org/wiki >>>>>>>> /Freeze_(software_engineering) Only changes or fixes thought to >>>>>>>> be important pre-fork will be included. >>>>>>>> >>>>>>>> 3. Reviewing the btc1 project and branch policies, btc1 is a source >>>>>>>> code fork of Bitcoin Core, very much like Fedora Linux is a >>>>>>>> fork/distribution intended for end users. As such, we track Bitcoin Core >>>>>>>> updates as necessary and pull those into the project. >>>>>>>> >>>>>>>> 4. "segwit2x" is the production release branch for the SegWit2x >>>>>>>> Working Group, and the latest release can be downloaded here: >>>>>>>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>>>>>>> >>>>>>>> 5. "segwit2x-dev" is the development and testing release branch. >>>>>>>> New changes go to segwit2x-dev first, for external testing and feedback, >>>>>>>> before being merged into the production branch, and labelled a production >>>>>>>> release. >>>>>>>> >>>>>>>> 6. The current segwit2x production release, on the segwit2x branch, >>>>>>>> is based on Bitcoin Core 0.14.x. The current dev release is based on >>>>>>>> Bitcoin Core 0.15.x. >>>>>>>> >>>>>>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x >>>>>>>> rollout. Based on instability and bugs that upstream Bitcoin Core >>>>>>>> project is seeing - ie. Core's bugs not ours - segwit2x will stay on >>>>>>>> Bitcoin Core 0.14.x through the November fork. This is the most stable >>>>>>>> path for users, based on upstream Bitcoin Core instability. >>>>>>>> >>>>>>>> In short we -do not- feel that Bitcoin Core bugs and instability >>>>>>>> will impact our project in the short term, because this is not yet in a >>>>>>>> segwit2x production release on a production branch. >>>>>>>> >>>>>>>> 8. The only change worth noting is a likely be an adjustment of >>>>>>>> miner policy defaults that will be accepted through the code freeze: >>>>>>>> https://github.com/btc1/bitcoin/pull/136 >>>>>>>> >>>>>>>> Thanks everyone! >>>>>>>> >>>>>>> >>>>>>> Thanks for the update. >>>>>>> >>>>>>> There was a question on a previous thread that I think went >>>>>>> unanswered. >>>>>>> >>>>>>> Is the threshold for release still 80% miner signaling? >>>>>>> >>>>>>> If miner signaling for NYA falls significantly, would it be >>>>>>> considered new information? >>>>>>> >>>>>>> FYI: latest metric is NYA signaling at 75% in the last 24h [1], with >>>>>>> the position of ViaBTC still unclear >>>>>>> >>>>>>> [1] https://coin.dance/blocks >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Jeff Garzik >>>>>>>> CEO and Co Founder >>>>>>>> Bloq, Inc. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Bitcoin-segwit2x mailing list >>>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Bitcoin-segwit2x mailing list >>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Jeff Garzik >>>>> CEO and Co Founder >>>>> Bloq, Inc. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>> >>>>> >>>> >>> >>> >>> -- >>> Jeff Garzik >>> CEO and Co Founder >>> Bloq, Inc. >>> >>> >> > > > -- > Jeff Garzik > CEO and Co Founder > Bloq, Inc. > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bitpay.com Wed Oct 25 20:06:37 2017 From: tony at bitpay.com (Tony Gallippi) Date: Wed, 25 Oct 2017 20:06:37 +0000 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Hi Alex, Nearly all bitcoin companies who operate at a large scale (say over 1 million users) need to run their own implementation of Bitcoin. Bitcoin Core just does not scale well for large web applications. While BTC1 may be the code people run for a while to get past the fork, however that turns out, my guess is most of us will go back to running what we need in our stacks. This could be Bitcoin Ruby, BitcoinJ (java), bcoin (nodejs), or something else. BTC1 will be maintained for those users who want to stick with C++, but the innovation and forward progress will be led by the other implementations. We all have extremely strong teams. Multiple implementations of the same consensus rules are a good thing for Bitcoin. A defensive consensus among the implementations would also be a good thing. On Wed, Oct 25, 2017 at 12:46 PM Alex Morcos via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Jeff, I'd just like to clarify what you envision for btc1 after the fork. > > Let's assume 1X wins: OK, makes sense to me, additional implementation > with extra features. > > Let's assume 2X wins: There is no Bitcoin Core working on "Bitcoin". > Bitcoin Core will either work on the minority chain (with different rules!) > for as long as that seems like it has a chance to be the Bitcoin again OR > it will just cease to exist. The model of continuing to base development > off of the work of Bitcoin Core contributors when Bitcoin is clearly > defined by the 2X rules just doesn't make sense. There will be no Bitcoin > Core contributors working on the 2X rules (or very few). I'm not someone > who thinks that the contributors to the Bitcoin Core project are the only > ones who can do this, but I think you should have some plan for who is > going to work on it. It won't be btc1 and Bitcoin Core, it'll just be btc1 > after the fork (I don't know and maybe Classic/Unlimited?) > > NB: I think this has very low probability, but it's kind of crazy to me > that you don't even have a plan for what to do if you succeed. > > > > > > > > On Wed, Oct 25, 2017 at 2:57 PM, Jeff Garzik via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Chris, >> >> There is no reallocation of time or commitment. Metronome and Bloq are >> off-topic on this list, so I'll only cover this once. >> >> I run a company, Bloq, with over 25 team members -- not just one. Just >> like many other companies, we have multiple projects running >> simultaneously, and Metronome is one of those. Our primary product is >> BloqEnterprise, which is a supported-Bitcoin product in the style of Red >> Hat Enterprise Linux. Majority of Bloq revenue comes from Bitcoin. If you >> are a large enterprise that needs Bitcoin support (or a very well funded >> startup), we would be happy to discuss a customer agreement. >> BloqEnterprise v1 is Bitcoin-only; BloqEnterprise v2 will be adding other >> chains to our product, such as Litecoin or Bitcoin Cash, as well as Eth/Etc >> support, based on customer demand. >> >> Our vision at Bloq has always been: Multi-chain, multi-token, >> multi-network, with Bitcoin - BTC - as the root of a security tree. >> >> >> As for btc1: As was stated in August, months ago, the code is in >> feature freeze until after the fork. It is a software engineering goal to >> keep changes to an absolute minimum, and that is what btc1 is doing. >> >> After the fork, btc1 will be continuing as a sort of "Fedora for Bitcoin" >> -- very exciting stuff, and a useful way to risk adjust versus Bitcoin Core >> instability or feature selection. Several btc1 members have proposed new >> btc1 changes for post-fork, large and small. It will be a very nice >> addition to the Bitcoin community to have an additional outlet for feature >> requests such as this one, a small change that makes life easier for >> DevOps: https://github.com/btc1/bitcoin/issues/107 >> >> >> >> >> >> >> >> On Wed, Oct 25, 2017 at 11:32 AM, Chris Stewart >> wrote: >> >>> Has there been any thought to who will be maintaining B2X after the >>> chain split is completed? It seems the only dev, Jeff, has committed his >>> time to a new project called Metronome >>> . >>> It doesn't appear that any significant portion of the bitcoin core >>> developers are willing to put their time and effort into this project. >>> >>> So is the plan to just fork and abandon the btc1 codebase? >>> >>> -Chris >>> >>> On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> >>>> >>>> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>>> Hi all! >>>>> >>>>> This is a follow-on from the previous status update in August: >>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html >>>>> >>>>> 1. To state the obvious, everything is still full steam ahead for >>>>> segwit2x upgrade in mid-November. >>>>> >>>>> 2. As noted in August, the project continues to be in a code freeze >>>>> for the fork: >>>>> https://en.wikipedia.org/wiki/Freeze_(software_engineering) Only >>>>> changes or fixes thought to be important pre-fork will be included. >>>>> >>>>> 3. Reviewing the btc1 project and branch policies, btc1 is a source >>>>> code fork of Bitcoin Core, very much like Fedora Linux is a >>>>> fork/distribution intended for end users. As such, we track Bitcoin Core >>>>> updates as necessary and pull those into the project. >>>>> >>>>> 4. "segwit2x" is the production release branch for the SegWit2x >>>>> Working Group, and the latest release can be downloaded here: >>>>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>>>> >>>>> 5. "segwit2x-dev" is the development and testing release branch. New >>>>> changes go to segwit2x-dev first, for external testing and feedback, before >>>>> being merged into the production branch, and labelled a production release. >>>>> >>>>> 6. The current segwit2x production release, on the segwit2x branch, is >>>>> based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin >>>>> Core 0.15.x. >>>>> >>>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x >>>>> rollout. Based on instability and bugs that upstream Bitcoin Core >>>>> project is seeing - ie. Core's bugs not ours - segwit2x will stay on >>>>> Bitcoin Core 0.14.x through the November fork. This is the most stable >>>>> path for users, based on upstream Bitcoin Core instability. >>>>> >>>>> In short we -do not- feel that Bitcoin Core bugs and instability will >>>>> impact our project in the short term, because this is not yet in a segwit2x >>>>> production release on a production branch. >>>>> >>>>> 8. The only change worth noting is a likely be an adjustment of miner >>>>> policy defaults that will be accepted through the code freeze: >>>>> https://github.com/btc1/bitcoin/pull/136 >>>>> >>>>> Thanks everyone! >>>>> >>>> >>>> Thanks for the update. >>>> >>>> There was a question on a previous thread that I think went unanswered. >>>> >>>> Is the threshold for release still 80% miner signaling? >>>> >>>> If miner signaling for NYA falls significantly, would it be considered >>>> new information? >>>> >>>> FYI: latest metric is NYA signaling at 75% in the last 24h [1], with >>>> the position of ViaBTC still unclear >>>> >>>> [1] https://coin.dance/blocks >>>> >>>>> >>>>> >>>>> -- >>>>> Jeff Garzik >>>>> CEO and Co Founder >>>>> Bloq, Inc. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >> >> >> -- >> Jeff Garzik >> CEO and Co Founder >> Bloq, Inc. >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at bloq.com Wed Oct 25 20:18:29 2017 From: jeff at bloq.com (Jeff Garzik) Date: Wed, 25 Oct 2017 13:18:29 -0700 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: 100% - this is key to underscore what Tony wrote. We are -not- moving to a situation where btc1 is a "decider of Bitcoin rules" We are moving -away- from a situation where Bitcoin Core is the "code is the spec" canonical implementation of Bitcoin rules. Multiple implementations and multiple teams create a far more healthy, more heterogenous ecosystem. On Wed, Oct 25, 2017 at 1:06 PM, Tony Gallippi wrote: > Hi Alex, > > Nearly all bitcoin companies who operate at a large scale (say over 1 > million users) need to run their own implementation of Bitcoin. Bitcoin > Core just does not scale well for large web applications. > > While BTC1 may be the code people run for a while to get past the fork, > however that turns out, my guess is most of us will go back to running what > we need in our stacks. This could be Bitcoin Ruby, BitcoinJ (java), bcoin > (nodejs), or something else. BTC1 will be maintained for those users who > want to stick with C++, but the innovation and forward progress will be led > by the other implementations. We all have extremely strong teams. > > Multiple implementations of the same consensus rules are a good thing for > Bitcoin. A defensive consensus among the implementations would also be a > good thing. > > > > > On Wed, Oct 25, 2017 at 12:46 PM Alex Morcos via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Jeff, I'd just like to clarify what you envision for btc1 after the fork. >> >> Let's assume 1X wins: OK, makes sense to me, additional implementation >> with extra features. >> >> Let's assume 2X wins: There is no Bitcoin Core working on "Bitcoin". >> Bitcoin Core will either work on the minority chain (with different rules!) >> for as long as that seems like it has a chance to be the Bitcoin again OR >> it will just cease to exist. The model of continuing to base development >> off of the work of Bitcoin Core contributors when Bitcoin is clearly >> defined by the 2X rules just doesn't make sense. There will be no Bitcoin >> Core contributors working on the 2X rules (or very few). I'm not someone >> who thinks that the contributors to the Bitcoin Core project are the only >> ones who can do this, but I think you should have some plan for who is >> going to work on it. It won't be btc1 and Bitcoin Core, it'll just be btc1 >> after the fork (I don't know and maybe Classic/Unlimited?) >> >> NB: I think this has very low probability, but it's kind of crazy to me >> that you don't even have a plan for what to do if you succeed. >> >> >> >> >> >> >> >> On Wed, Oct 25, 2017 at 2:57 PM, Jeff Garzik via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> Chris, >>> >>> There is no reallocation of time or commitment. Metronome and Bloq are >>> off-topic on this list, so I'll only cover this once. >>> >>> I run a company, Bloq, with over 25 team members -- not just one. Just >>> like many other companies, we have multiple projects running >>> simultaneously, and Metronome is one of those. Our primary product is >>> BloqEnterprise, which is a supported-Bitcoin product in the style of Red >>> Hat Enterprise Linux. Majority of Bloq revenue comes from Bitcoin. If you >>> are a large enterprise that needs Bitcoin support (or a very well funded >>> startup), we would be happy to discuss a customer agreement. >>> BloqEnterprise v1 is Bitcoin-only; BloqEnterprise v2 will be adding other >>> chains to our product, such as Litecoin or Bitcoin Cash, as well as Eth/Etc >>> support, based on customer demand. >>> >>> Our vision at Bloq has always been: Multi-chain, multi-token, >>> multi-network, with Bitcoin - BTC - as the root of a security tree. >>> >>> >>> As for btc1: As was stated in August, months ago, the code is in >>> feature freeze until after the fork. It is a software engineering goal to >>> keep changes to an absolute minimum, and that is what btc1 is doing. >>> >>> After the fork, btc1 will be continuing as a sort of "Fedora for >>> Bitcoin" -- very exciting stuff, and a useful way to risk adjust versus >>> Bitcoin Core instability or feature selection. Several btc1 members have >>> proposed new btc1 changes for post-fork, large and small. It will be a >>> very nice addition to the Bitcoin community to have an additional outlet >>> for feature requests such as this one, a small change that makes life >>> easier for DevOps: https://github.com/btc1/bitcoin/issues/107 >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Oct 25, 2017 at 11:32 AM, Chris Stewart >>> wrote: >>> >>>> Has there been any thought to who will be maintaining B2X after the >>>> chain split is completed? It seems the only dev, Jeff, has committed his >>>> time to a new project called Metronome >>>> . >>>> It doesn't appear that any significant portion of the bitcoin core >>>> developers are willing to put their time and effort into this project. >>>> >>>> So is the plan to just fork and abandon the btc1 codebase? >>>> >>>> -Chris >>>> >>>> On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via Bitcoin-segwit2x < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>>> >>>>> >>>>> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < >>>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>>> >>>>>> Hi all! >>>>>> >>>>>> This is a follow-on from the previous status update in August: >>>>>> https://lists.linuxfoundation.org/pipermail/ >>>>>> bitcoin-segwit2x/2017-August/000265.html >>>>>> >>>>>> 1. To state the obvious, everything is still full steam ahead for >>>>>> segwit2x upgrade in mid-November. >>>>>> >>>>>> 2. As noted in August, the project continues to be in a code freeze >>>>>> for the fork: https://en.wikipedia.org/wiki/Freeze_(software_ >>>>>> engineering) Only changes or fixes thought to be important >>>>>> pre-fork will be included. >>>>>> >>>>>> 3. Reviewing the btc1 project and branch policies, btc1 is a source >>>>>> code fork of Bitcoin Core, very much like Fedora Linux is a >>>>>> fork/distribution intended for end users. As such, we track Bitcoin Core >>>>>> updates as necessary and pull those into the project. >>>>>> >>>>>> 4. "segwit2x" is the production release branch for the SegWit2x >>>>>> Working Group, and the latest release can be downloaded here: >>>>>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>>>>> >>>>>> 5. "segwit2x-dev" is the development and testing release branch. New >>>>>> changes go to segwit2x-dev first, for external testing and feedback, before >>>>>> being merged into the production branch, and labelled a production release. >>>>>> >>>>>> 6. The current segwit2x production release, on the segwit2x branch, >>>>>> is based on Bitcoin Core 0.14.x. The current dev release is based on >>>>>> Bitcoin Core 0.15.x. >>>>>> >>>>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x >>>>>> rollout. Based on instability and bugs that upstream Bitcoin Core >>>>>> project is seeing - ie. Core's bugs not ours - segwit2x will stay on >>>>>> Bitcoin Core 0.14.x through the November fork. This is the most stable >>>>>> path for users, based on upstream Bitcoin Core instability. >>>>>> >>>>>> In short we -do not- feel that Bitcoin Core bugs and instability will >>>>>> impact our project in the short term, because this is not yet in a segwit2x >>>>>> production release on a production branch. >>>>>> >>>>>> 8. The only change worth noting is a likely be an adjustment of miner >>>>>> policy defaults that will be accepted through the code freeze: >>>>>> https://github.com/btc1/bitcoin/pull/136 >>>>>> >>>>>> Thanks everyone! >>>>>> >>>>> >>>>> Thanks for the update. >>>>> >>>>> There was a question on a previous thread that I think went unanswered. >>>>> >>>>> Is the threshold for release still 80% miner signaling? >>>>> >>>>> If miner signaling for NYA falls significantly, would it be considered >>>>> new information? >>>>> >>>>> FYI: latest metric is NYA signaling at 75% in the last 24h [1], with >>>>> the position of ViaBTC still unclear >>>>> >>>>> [1] https://coin.dance/blocks >>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jeff Garzik >>>>>> CEO and Co Founder >>>>>> Bloq, Inc. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Bitcoin-segwit2x mailing list >>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>> >>>>> >>>> >>> >>> >>> -- >>> Jeff Garzik >>> CEO and Co Founder >>> Bloq, Inc. >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > -- > Sent from Gmail Mobile > -- Jeff Garzik CEO and Co Founder Bloq, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From djpnewton at gmail.com Wed Oct 25 20:20:00 2017 From: djpnewton at gmail.com (Daniel Newton) Date: Thu, 26 Oct 2017 09:20:00 +1300 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: This seems surprising. So why was the BTC1 project not based off something web scale like Bitcoin Ruby? If your stack is tailored to use Bitcoin Ruby in production how can you just switch to BTC1 to "get past the fork" and then just switch back? Does Bitcoin Ruby even support the B2X consensus changes? On 26/10/2017 9:06 AM, "Tony Gallippi via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: Hi Alex, Nearly all bitcoin companies who operate at a large scale (say over 1 million users) need to run their own implementation of Bitcoin. Bitcoin Core just does not scale well for large web applications. While BTC1 may be the code people run for a while to get past the fork, however that turns out, my guess is most of us will go back to running what we need in our stacks. This could be Bitcoin Ruby, BitcoinJ (java), bcoin (nodejs), or something else. BTC1 will be maintained for those users who want to stick with C++, but the innovation and forward progress will be led by the other implementations. We all have extremely strong teams. Multiple implementations of the same consensus rules are a good thing for Bitcoin. A defensive consensus among the implementations would also be a good thing. On Wed, Oct 25, 2017 at 12:46 PM Alex Morcos via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Jeff, I'd just like to clarify what you envision for btc1 after the fork. > > Let's assume 1X wins: OK, makes sense to me, additional implementation > with extra features. > > Let's assume 2X wins: There is no Bitcoin Core working on "Bitcoin". > Bitcoin Core will either work on the minority chain (with different rules!) > for as long as that seems like it has a chance to be the Bitcoin again OR > it will just cease to exist. The model of continuing to base development > off of the work of Bitcoin Core contributors when Bitcoin is clearly > defined by the 2X rules just doesn't make sense. There will be no Bitcoin > Core contributors working on the 2X rules (or very few). I'm not someone > who thinks that the contributors to the Bitcoin Core project are the only > ones who can do this, but I think you should have some plan for who is > going to work on it. It won't be btc1 and Bitcoin Core, it'll just be btc1 > after the fork (I don't know and maybe Classic/Unlimited?) > > NB: I think this has very low probability, but it's kind of crazy to me > that you don't even have a plan for what to do if you succeed. > > > > > > > > On Wed, Oct 25, 2017 at 2:57 PM, Jeff Garzik via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Chris, >> >> There is no reallocation of time or commitment. Metronome and Bloq are >> off-topic on this list, so I'll only cover this once. >> >> I run a company, Bloq, with over 25 team members -- not just one. Just >> like many other companies, we have multiple projects running >> simultaneously, and Metronome is one of those. Our primary product is >> BloqEnterprise, which is a supported-Bitcoin product in the style of Red >> Hat Enterprise Linux. Majority of Bloq revenue comes from Bitcoin. If you >> are a large enterprise that needs Bitcoin support (or a very well funded >> startup), we would be happy to discuss a customer agreement. >> BloqEnterprise v1 is Bitcoin-only; BloqEnterprise v2 will be adding other >> chains to our product, such as Litecoin or Bitcoin Cash, as well as Eth/Etc >> support, based on customer demand. >> >> Our vision at Bloq has always been: Multi-chain, multi-token, >> multi-network, with Bitcoin - BTC - as the root of a security tree. >> >> >> As for btc1: As was stated in August, months ago, the code is in >> feature freeze until after the fork. It is a software engineering goal to >> keep changes to an absolute minimum, and that is what btc1 is doing. >> >> After the fork, btc1 will be continuing as a sort of "Fedora for Bitcoin" >> -- very exciting stuff, and a useful way to risk adjust versus Bitcoin Core >> instability or feature selection. Several btc1 members have proposed new >> btc1 changes for post-fork, large and small. It will be a very nice >> addition to the Bitcoin community to have an additional outlet for feature >> requests such as this one, a small change that makes life easier for >> DevOps: https://github.com/btc1/bitcoin/issues/107 >> >> >> >> >> >> >> >> On Wed, Oct 25, 2017 at 11:32 AM, Chris Stewart >> wrote: >> >>> Has there been any thought to who will be maintaining B2X after the >>> chain split is completed? It seems the only dev, Jeff, has committed his >>> time to a new project called Metronome >>> . >>> It doesn't appear that any significant portion of the bitcoin core >>> developers are willing to put their time and effort into this project. >>> >>> So is the plan to just fork and abandon the btc1 codebase? >>> >>> -Chris >>> >>> On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> >>>> >>>> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>>> Hi all! >>>>> >>>>> This is a follow-on from the previous status update in August: >>>>> https://lists.linuxfoundation.org/pipermail/ >>>>> bitcoin-segwit2x/2017-August/000265.html >>>>> >>>>> 1. To state the obvious, everything is still full steam ahead for >>>>> segwit2x upgrade in mid-November. >>>>> >>>>> 2. As noted in August, the project continues to be in a code freeze >>>>> for the fork: https://en.wikipedia.org/wiki/Freeze_(software_ >>>>> engineering) Only changes or fixes thought to be important pre-fork >>>>> will be included. >>>>> >>>>> 3. Reviewing the btc1 project and branch policies, btc1 is a source >>>>> code fork of Bitcoin Core, very much like Fedora Linux is a >>>>> fork/distribution intended for end users. As such, we track Bitcoin Core >>>>> updates as necessary and pull those into the project. >>>>> >>>>> 4. "segwit2x" is the production release branch for the SegWit2x >>>>> Working Group, and the latest release can be downloaded here: >>>>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>>>> >>>>> 5. "segwit2x-dev" is the development and testing release branch. New >>>>> changes go to segwit2x-dev first, for external testing and feedback, before >>>>> being merged into the production branch, and labelled a production release. >>>>> >>>>> 6. The current segwit2x production release, on the segwit2x branch, is >>>>> based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin >>>>> Core 0.15.x. >>>>> >>>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x >>>>> rollout. Based on instability and bugs that upstream Bitcoin Core >>>>> project is seeing - ie. Core's bugs not ours - segwit2x will stay on >>>>> Bitcoin Core 0.14.x through the November fork. This is the most stable >>>>> path for users, based on upstream Bitcoin Core instability. >>>>> >>>>> In short we -do not- feel that Bitcoin Core bugs and instability will >>>>> impact our project in the short term, because this is not yet in a segwit2x >>>>> production release on a production branch. >>>>> >>>>> 8. The only change worth noting is a likely be an adjustment of miner >>>>> policy defaults that will be accepted through the code freeze: >>>>> https://github.com/btc1/bitcoin/pull/136 >>>>> >>>>> Thanks everyone! >>>>> >>>> >>>> Thanks for the update. >>>> >>>> There was a question on a previous thread that I think went unanswered. >>>> >>>> Is the threshold for release still 80% miner signaling? >>>> >>>> If miner signaling for NYA falls significantly, would it be considered >>>> new information? >>>> >>>> FYI: latest metric is NYA signaling at 75% in the last 24h [1], with >>>> the position of ViaBTC still unclear >>>> >>>> [1] https://coin.dance/blocks >>>> >>>>> >>>>> >>>>> -- >>>>> Jeff Garzik >>>>> CEO and Co Founder >>>>> Bloq, Inc. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >> >> >> -- >> Jeff Garzik >> CEO and Co Founder >> Bloq, Inc. >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -- Sent from Gmail Mobile _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at suredbits.com Wed Oct 25 20:34:27 2017 From: chris at suredbits.com (Chris Stewart) Date: Wed, 25 Oct 2017 15:34:27 -0500 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: >No; the Fedora model exists and works precisely because it risk adjusts against all manner of upstream events: Project idleness, Developer departure, developer grumpiness with some changes otherwise widely accepted by the community, and more. So I have a couple gripes with the analogy, you are mixing the following interchangeably: 1.) btc1's ambition to alter the consensus rules of the bitcoin protocol 2.) providing a more efficient implementation of non-consensus critical components of bitcoin core. I have no problems with 2. However it appears you are trying to achieve 1 by using 2 as a trojan horse in this thread. Operating systems are not consensus critical protocols and readers of this mailing list should have a high amount of skepticism when the two are compared. -Chris On Wed, Oct 25, 2017 at 3:00 PM, Jeff Garzik wrote: > Alex, > > No; the Fedora model exists and works precisely because it risk adjusts > against all manner of upstream events: Project idleness, Developer > departure, developer grumpiness with some changes otherwise widely accepted > by the community, and more. > > You can read more background at https://en.wikipedia.org/ > wiki/Fedora_Project > > > > On Wed, Oct 25, 2017 at 12:57 PM, Alex Morcos wrote: > >> Yes but you're assuming the continued existence of the Bitcoin Core >> project, but in the hypothetical situation where Segwit2X is the completely >> dominant chain, there is no continued existence of the Bitcoin Core project. >> There is no upstream in this scenario. >> >> On Wed, Oct 25, 2017 at 3:53 PM, Jeff Garzik wrote: >> >>> Alex, >>> >>> The plan was already stated in the thread. This is a well defined open >>> source pattern and situation. btc1 will continue as a sort of Fedora for >>> Bitcoin after the fork. >>> >>> It is irrelevant whether or not Bitcoin Core merges patches such as the >>> 2X patches. The codebase remains 99% the same either way. >>> >>> That is what Fedora does on Linux: Carry patches that haven't made >>> their way upstream. Either the upstream developers merge or they don't; >>> either way, the project continues. >>> >>> Consider reviewing another example from open source history, the GCC vs. >>> EGCS situation. https://gcc.gnu.org/wiki/History#EGCS >>> >>> >>> >>> On Wed, Oct 25, 2017 at 12:46 PM, Alex Morcos wrote: >>> >>>> Jeff, I'd just like to clarify what you envision for btc1 after the >>>> fork. >>>> >>>> Let's assume 1X wins: OK, makes sense to me, additional implementation >>>> with extra features. >>>> >>>> Let's assume 2X wins: There is no Bitcoin Core working on "Bitcoin". >>>> Bitcoin Core will either work on the minority chain (with different rules!) >>>> for as long as that seems like it has a chance to be the Bitcoin again OR >>>> it will just cease to exist. The model of continuing to base development >>>> off of the work of Bitcoin Core contributors when Bitcoin is clearly >>>> defined by the 2X rules just doesn't make sense. There will be no Bitcoin >>>> Core contributors working on the 2X rules (or very few). I'm not someone >>>> who thinks that the contributors to the Bitcoin Core project are the only >>>> ones who can do this, but I think you should have some plan for who is >>>> going to work on it. It won't be btc1 and Bitcoin Core, it'll just be btc1 >>>> after the fork (I don't know and maybe Classic/Unlimited?) >>>> >>>> NB: I think this has very low probability, but it's kind of crazy to me >>>> that you don't even have a plan for what to do if you succeed. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Oct 25, 2017 at 2:57 PM, Jeff Garzik via Bitcoin-segwit2x < >>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>> >>>>> Chris, >>>>> >>>>> There is no reallocation of time or commitment. Metronome and Bloq >>>>> are off-topic on this list, so I'll only cover this once. >>>>> >>>>> I run a company, Bloq, with over 25 team members -- not just one. >>>>> Just like many other companies, we have multiple projects running >>>>> simultaneously, and Metronome is one of those. Our primary product is >>>>> BloqEnterprise, which is a supported-Bitcoin product in the style of Red >>>>> Hat Enterprise Linux. Majority of Bloq revenue comes from Bitcoin. If you >>>>> are a large enterprise that needs Bitcoin support (or a very well funded >>>>> startup), we would be happy to discuss a customer agreement. >>>>> BloqEnterprise v1 is Bitcoin-only; BloqEnterprise v2 will be adding other >>>>> chains to our product, such as Litecoin or Bitcoin Cash, as well as Eth/Etc >>>>> support, based on customer demand. >>>>> >>>>> Our vision at Bloq has always been: Multi-chain, multi-token, >>>>> multi-network, with Bitcoin - BTC - as the root of a security tree. >>>>> >>>>> >>>>> As for btc1: As was stated in August, months ago, the code is in >>>>> feature freeze until after the fork. It is a software engineering goal to >>>>> keep changes to an absolute minimum, and that is what btc1 is doing. >>>>> >>>>> After the fork, btc1 will be continuing as a sort of "Fedora for >>>>> Bitcoin" -- very exciting stuff, and a useful way to risk adjust versus >>>>> Bitcoin Core instability or feature selection. Several btc1 members have >>>>> proposed new btc1 changes for post-fork, large and small. It will be a >>>>> very nice addition to the Bitcoin community to have an additional outlet >>>>> for feature requests such as this one, a small change that makes life >>>>> easier for DevOps: https://github.com/btc1/bitcoin/issues/107 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Oct 25, 2017 at 11:32 AM, Chris Stewart >>>>> wrote: >>>>> >>>>>> Has there been any thought to who will be maintaining B2X after the >>>>>> chain split is completed? It seems the only dev, Jeff, has committed his >>>>>> time to a new project called Metronome >>>>>> . >>>>>> It doesn't appear that any significant portion of the bitcoin core >>>>>> developers are willing to put their time and effort into this project. >>>>>> >>>>>> So is the plan to just fork and abandon the btc1 codebase? >>>>>> >>>>>> -Chris >>>>>> >>>>>> On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via Bitcoin-segwit2x >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < >>>>>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>>>>>> >>>>>>>> Hi all! >>>>>>>> >>>>>>>> This is a follow-on from the previous status update in August: >>>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin- >>>>>>>> segwit2x/2017-August/000265.html >>>>>>>> >>>>>>>> 1. To state the obvious, everything is still full steam ahead for >>>>>>>> segwit2x upgrade in mid-November. >>>>>>>> >>>>>>>> 2. As noted in August, the project continues to be in a code freeze >>>>>>>> for the fork: https://en.wikipedia.org/wiki >>>>>>>> /Freeze_(software_engineering) Only changes or fixes thought to >>>>>>>> be important pre-fork will be included. >>>>>>>> >>>>>>>> 3. Reviewing the btc1 project and branch policies, btc1 is a source >>>>>>>> code fork of Bitcoin Core, very much like Fedora Linux is a >>>>>>>> fork/distribution intended for end users. As such, we track Bitcoin Core >>>>>>>> updates as necessary and pull those into the project. >>>>>>>> >>>>>>>> 4. "segwit2x" is the production release branch for the SegWit2x >>>>>>>> Working Group, and the latest release can be downloaded here: >>>>>>>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>>>>>>> >>>>>>>> 5. "segwit2x-dev" is the development and testing release branch. >>>>>>>> New changes go to segwit2x-dev first, for external testing and feedback, >>>>>>>> before being merged into the production branch, and labelled a production >>>>>>>> release. >>>>>>>> >>>>>>>> 6. The current segwit2x production release, on the segwit2x branch, >>>>>>>> is based on Bitcoin Core 0.14.x. The current dev release is based on >>>>>>>> Bitcoin Core 0.15.x. >>>>>>>> >>>>>>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x >>>>>>>> rollout. Based on instability and bugs that upstream Bitcoin Core >>>>>>>> project is seeing - ie. Core's bugs not ours - segwit2x will stay on >>>>>>>> Bitcoin Core 0.14.x through the November fork. This is the most stable >>>>>>>> path for users, based on upstream Bitcoin Core instability. >>>>>>>> >>>>>>>> In short we -do not- feel that Bitcoin Core bugs and instability >>>>>>>> will impact our project in the short term, because this is not yet in a >>>>>>>> segwit2x production release on a production branch. >>>>>>>> >>>>>>>> 8. The only change worth noting is a likely be an adjustment of >>>>>>>> miner policy defaults that will be accepted through the code freeze: >>>>>>>> https://github.com/btc1/bitcoin/pull/136 >>>>>>>> >>>>>>>> Thanks everyone! >>>>>>>> >>>>>>> >>>>>>> Thanks for the update. >>>>>>> >>>>>>> There was a question on a previous thread that I think went >>>>>>> unanswered. >>>>>>> >>>>>>> Is the threshold for release still 80% miner signaling? >>>>>>> >>>>>>> If miner signaling for NYA falls significantly, would it be >>>>>>> considered new information? >>>>>>> >>>>>>> FYI: latest metric is NYA signaling at 75% in the last 24h [1], with >>>>>>> the position of ViaBTC still unclear >>>>>>> >>>>>>> [1] https://coin.dance/blocks >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Jeff Garzik >>>>>>>> CEO and Co Founder >>>>>>>> Bloq, Inc. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Bitcoin-segwit2x mailing list >>>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Bitcoin-segwit2x mailing list >>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Jeff Garzik >>>>> CEO and Co Founder >>>>> Bloq, Inc. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>> >>>>> >>>> >>> >>> >>> -- >>> Jeff Garzik >>> CEO and Co Founder >>> Bloq, Inc. >>> >>> >> > > > -- > Jeff Garzik > CEO and Co Founder > Bloq, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaredr26 at gmail.com Wed Oct 25 20:37:49 2017 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Wed, 25 Oct 2017 13:37:49 -0700 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: > However it appears you are trying to achieve 1 by using 2 as a trojan horse in this thread There's no trojan horse, this is literally what the ecosystem and the miners agreed to in May, Jeff has just implemented it so that it can be followed, complete with specifications of the consensus rule changes. And until the Core developers came out swinging against it and Theymos started banning everyone who supported 2x, 2x aka segwit2mb was very popular in the community. No one was surprised, of course, as Core's and Theymos' behavior here have become extremely predictable. On Wed, Oct 25, 2017 at 1:34 PM, Chris Stewart via Bitcoin-segwit2x wrote: >>No; the Fedora model exists and works precisely because it risk adjusts >> against all manner of upstream events: Project idleness, Developer >> departure, developer grumpiness with some changes otherwise widely accepted >> by the community, and more. > > So I have a couple gripes with the analogy, you are mixing the following > interchangeably: > > 1.) btc1's ambition to alter the consensus rules of the bitcoin protocol > 2.) providing a more efficient implementation of non-consensus critical > components of bitcoin core. > > I have no problems with 2. > > However it appears you are trying to achieve 1 by using 2 as a trojan horse > in this thread. Operating systems are not consensus critical protocols and > readers of this mailing list should have a high amount of skepticism when > the two are compared. > > -Chris > > On Wed, Oct 25, 2017 at 3:00 PM, Jeff Garzik wrote: >> >> Alex, >> >> No; the Fedora model exists and works precisely because it risk adjusts >> against all manner of upstream events: Project idleness, Developer >> departure, developer grumpiness with some changes otherwise widely accepted >> by the community, and more. >> >> You can read more background at >> https://en.wikipedia.org/wiki/Fedora_Project >> >> >> >> On Wed, Oct 25, 2017 at 12:57 PM, Alex Morcos wrote: >>> >>> Yes but you're assuming the continued existence of the Bitcoin Core >>> project, but in the hypothetical situation where Segwit2X is the completely >>> dominant chain, there is no continued existence of the Bitcoin Core project. >>> There is no upstream in this scenario. >>> >>> On Wed, Oct 25, 2017 at 3:53 PM, Jeff Garzik wrote: >>>> >>>> Alex, >>>> >>>> The plan was already stated in the thread. This is a well defined open >>>> source pattern and situation. btc1 will continue as a sort of Fedora for >>>> Bitcoin after the fork. >>>> >>>> It is irrelevant whether or not Bitcoin Core merges patches such as the >>>> 2X patches. The codebase remains 99% the same either way. >>>> >>>> That is what Fedora does on Linux: Carry patches that haven't made >>>> their way upstream. Either the upstream developers merge or they don't; >>>> either way, the project continues. >>>> >>>> Consider reviewing another example from open source history, the GCC vs. >>>> EGCS situation. https://gcc.gnu.org/wiki/History#EGCS >>>> >>>> >>>> >>>> On Wed, Oct 25, 2017 at 12:46 PM, Alex Morcos wrote: >>>>> >>>>> Jeff, I'd just like to clarify what you envision for btc1 after the >>>>> fork. >>>>> >>>>> Let's assume 1X wins: OK, makes sense to me, additional implementation >>>>> with extra features. >>>>> >>>>> Let's assume 2X wins: There is no Bitcoin Core working on "Bitcoin". >>>>> Bitcoin Core will either work on the minority chain (with different rules!) >>>>> for as long as that seems like it has a chance to be the Bitcoin again OR it >>>>> will just cease to exist. The model of continuing to base development off >>>>> of the work of Bitcoin Core contributors when Bitcoin is clearly defined by >>>>> the 2X rules just doesn't make sense. There will be no Bitcoin Core >>>>> contributors working on the 2X rules (or very few). I'm not someone who >>>>> thinks that the contributors to the Bitcoin Core project are the only ones >>>>> who can do this, but I think you should have some plan for who is going to >>>>> work on it. It won't be btc1 and Bitcoin Core, it'll just be btc1 after the >>>>> fork (I don't know and maybe Classic/Unlimited?) >>>>> >>>>> NB: I think this has very low probability, but it's kind of crazy to me >>>>> that you don't even have a plan for what to do if you succeed. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Oct 25, 2017 at 2:57 PM, Jeff Garzik via Bitcoin-segwit2x >>>>> wrote: >>>>>> >>>>>> Chris, >>>>>> >>>>>> There is no reallocation of time or commitment. Metronome and Bloq >>>>>> are off-topic on this list, so I'll only cover this once. >>>>>> >>>>>> I run a company, Bloq, with over 25 team members -- not just one. >>>>>> Just like many other companies, we have multiple projects running >>>>>> simultaneously, and Metronome is one of those. Our primary product is >>>>>> BloqEnterprise, which is a supported-Bitcoin product in the style of Red Hat >>>>>> Enterprise Linux. Majority of Bloq revenue comes from Bitcoin. If you are >>>>>> a large enterprise that needs Bitcoin support (or a very well funded >>>>>> startup), we would be happy to discuss a customer agreement. BloqEnterprise >>>>>> v1 is Bitcoin-only; BloqEnterprise v2 will be adding other chains to our >>>>>> product, such as Litecoin or Bitcoin Cash, as well as Eth/Etc support, based >>>>>> on customer demand. >>>>>> >>>>>> Our vision at Bloq has always been: Multi-chain, multi-token, >>>>>> multi-network, with Bitcoin - BTC - as the root of a security tree. >>>>>> >>>>>> >>>>>> As for btc1: As was stated in August, months ago, the code is in >>>>>> feature freeze until after the fork. It is a software engineering goal to >>>>>> keep changes to an absolute minimum, and that is what btc1 is doing. >>>>>> >>>>>> After the fork, btc1 will be continuing as a sort of "Fedora for >>>>>> Bitcoin" -- very exciting stuff, and a useful way to risk adjust versus >>>>>> Bitcoin Core instability or feature selection. Several btc1 members have >>>>>> proposed new btc1 changes for post-fork, large and small. It will be a very >>>>>> nice addition to the Bitcoin community to have an additional outlet for >>>>>> feature requests such as this one, a small change that makes life easier for >>>>>> DevOps: https://github.com/btc1/bitcoin/issues/107 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Oct 25, 2017 at 11:32 AM, Chris Stewart >>>>>> wrote: >>>>>>> >>>>>>> Has there been any thought to who will be maintaining B2X after the >>>>>>> chain split is completed? It seems the only dev, Jeff, has committed his >>>>>>> time to a new project called Metronome. It doesn't appear that any >>>>>>> significant portion of the bitcoin core developers are willing to put their >>>>>>> time and effort into this project. >>>>>>> >>>>>>> So is the plan to just fork and abandon the btc1 codebase? >>>>>>> >>>>>>> -Chris >>>>>>> >>>>>>> On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via Bitcoin-segwit2x >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi all! >>>>>>>>> >>>>>>>>> This is a follow-on from the previous status update in August: >>>>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html >>>>>>>>> >>>>>>>>> 1. To state the obvious, everything is still full steam ahead for >>>>>>>>> segwit2x upgrade in mid-November. >>>>>>>>> >>>>>>>>> 2. As noted in August, the project continues to be in a code freeze >>>>>>>>> for the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) >>>>>>>>> Only changes or fixes thought to be important pre-fork will be included. >>>>>>>>> >>>>>>>>> 3. Reviewing the btc1 project and branch policies, btc1 is a source >>>>>>>>> code fork of Bitcoin Core, very much like Fedora Linux is a >>>>>>>>> fork/distribution intended for end users. As such, we track Bitcoin Core >>>>>>>>> updates as necessary and pull those into the project. >>>>>>>>> >>>>>>>>> 4. "segwit2x" is the production release branch for the SegWit2x >>>>>>>>> Working Group, and the latest release can be downloaded here: >>>>>>>>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>>>>>>>> >>>>>>>>> 5. "segwit2x-dev" is the development and testing release branch. >>>>>>>>> New changes go to segwit2x-dev first, for external testing and feedback, >>>>>>>>> before being merged into the production branch, and labelled a production >>>>>>>>> release. >>>>>>>>> >>>>>>>>> 6. The current segwit2x production release, on the segwit2x branch, >>>>>>>>> is based on Bitcoin Core 0.14.x. The current dev release is based on >>>>>>>>> Bitcoin Core 0.15.x. >>>>>>>>> >>>>>>>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x >>>>>>>>> rollout. Based on instability and bugs that upstream Bitcoin Core project >>>>>>>>> is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core >>>>>>>>> 0.14.x through the November fork. This is the most stable path for users, >>>>>>>>> based on upstream Bitcoin Core instability. >>>>>>>>> >>>>>>>>> In short we -do not- feel that Bitcoin Core bugs and instability >>>>>>>>> will impact our project in the short term, because this is not yet in a >>>>>>>>> segwit2x production release on a production branch. >>>>>>>>> >>>>>>>>> 8. The only change worth noting is a likely be an adjustment of >>>>>>>>> miner policy defaults that will be accepted through the code freeze: >>>>>>>>> https://github.com/btc1/bitcoin/pull/136 >>>>>>>>> >>>>>>>>> Thanks everyone! >>>>>>>> >>>>>>>> >>>>>>>> Thanks for the update. >>>>>>>> >>>>>>>> There was a question on a previous thread that I think went >>>>>>>> unanswered. >>>>>>>> >>>>>>>> Is the threshold for release still 80% miner signaling? >>>>>>>> >>>>>>>> If miner signaling for NYA falls significantly, would it be >>>>>>>> considered new information? >>>>>>>> >>>>>>>> FYI: latest metric is NYA signaling at 75% in the last 24h [1], with >>>>>>>> the position of ViaBTC still unclear >>>>>>>> >>>>>>>> [1] https://coin.dance/blocks >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jeff Garzik >>>>>>>>> CEO and Co Founder >>>>>>>>> Bloq, Inc. >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Bitcoin-segwit2x mailing list >>>>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Bitcoin-segwit2x mailing list >>>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jeff Garzik >>>>>> CEO and Co Founder >>>>>> Bloq, Inc. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Bitcoin-segwit2x mailing list >>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Jeff Garzik >>>> CEO and Co Founder >>>> Bloq, Inc. >>>> >>> >> >> >> >> -- >> Jeff Garzik >> CEO and Co Founder >> Bloq, Inc. >> > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From melvincarvalho at gmail.com Wed Oct 25 20:51:21 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Wed, 25 Oct 2017 22:51:21 +0200 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: On 25 October 2017 at 22:37, Jared Lee Richardson via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > However it appears you are trying to achieve 1 by using 2 as a trojan > horse in this thread > > There's no trojan horse, this is literally what the ecosystem and the > miners agreed to in May, Jeff has just implemented it so that it can > be followed, complete with specifications of the consensus rule > changes. > > And until the Core developers came out swinging against it and Theymos > started banning everyone who supported 2x, 2x aka segwit2mb was very > popular in the community. No one was surprised, of course, as Core's > and Theymos' behavior here have become extremely predictable. > Possibly best to avoid ad hominems. I think 2x had, and continues to have mind share. But certainly not on an accelerated timescale, which lacks consensus. That is simply suicidal. > > > > On Wed, Oct 25, 2017 at 1:34 PM, Chris Stewart via Bitcoin-segwit2x > wrote: > >>No; the Fedora model exists and works precisely because it risk adjusts > >> against all manner of upstream events: Project idleness, Developer > >> departure, developer grumpiness with some changes otherwise widely > accepted > >> by the community, and more. > > > > So I have a couple gripes with the analogy, you are mixing the following > > interchangeably: > > > > 1.) btc1's ambition to alter the consensus rules of the bitcoin protocol > > 2.) providing a more efficient implementation of non-consensus critical > > components of bitcoin core. > > > > I have no problems with 2. > > > > However it appears you are trying to achieve 1 by using 2 as a trojan > horse > > in this thread. Operating systems are not consensus critical protocols > and > > readers of this mailing list should have a high amount of skepticism when > > the two are compared. > > > > -Chris > > > > On Wed, Oct 25, 2017 at 3:00 PM, Jeff Garzik wrote: > >> > >> Alex, > >> > >> No; the Fedora model exists and works precisely because it risk adjusts > >> against all manner of upstream events: Project idleness, Developer > >> departure, developer grumpiness with some changes otherwise widely > accepted > >> by the community, and more. > >> > >> You can read more background at > >> https://en.wikipedia.org/wiki/Fedora_Project > >> > >> > >> > >> On Wed, Oct 25, 2017 at 12:57 PM, Alex Morcos wrote: > >>> > >>> Yes but you're assuming the continued existence of the Bitcoin Core > >>> project, but in the hypothetical situation where Segwit2X is the > completely > >>> dominant chain, there is no continued existence of the Bitcoin Core > project. > >>> There is no upstream in this scenario. > >>> > >>> On Wed, Oct 25, 2017 at 3:53 PM, Jeff Garzik wrote: > >>>> > >>>> Alex, > >>>> > >>>> The plan was already stated in the thread. This is a well defined > open > >>>> source pattern and situation. btc1 will continue as a sort of Fedora > for > >>>> Bitcoin after the fork. > >>>> > >>>> It is irrelevant whether or not Bitcoin Core merges patches such as > the > >>>> 2X patches. The codebase remains 99% the same either way. > >>>> > >>>> That is what Fedora does on Linux: Carry patches that haven't made > >>>> their way upstream. Either the upstream developers merge or they > don't; > >>>> either way, the project continues. > >>>> > >>>> Consider reviewing another example from open source history, the GCC > vs. > >>>> EGCS situation. https://gcc.gnu.org/wiki/History#EGCS > >>>> > >>>> > >>>> > >>>> On Wed, Oct 25, 2017 at 12:46 PM, Alex Morcos > wrote: > >>>>> > >>>>> Jeff, I'd just like to clarify what you envision for btc1 after the > >>>>> fork. > >>>>> > >>>>> Let's assume 1X wins: OK, makes sense to me, additional > implementation > >>>>> with extra features. > >>>>> > >>>>> Let's assume 2X wins: There is no Bitcoin Core working on "Bitcoin". > >>>>> Bitcoin Core will either work on the minority chain (with different > rules!) > >>>>> for as long as that seems like it has a chance to be the Bitcoin > again OR it > >>>>> will just cease to exist. The model of continuing to base > development off > >>>>> of the work of Bitcoin Core contributors when Bitcoin is clearly > defined by > >>>>> the 2X rules just doesn't make sense. There will be no Bitcoin Core > >>>>> contributors working on the 2X rules (or very few). I'm not someone > who > >>>>> thinks that the contributors to the Bitcoin Core project are the > only ones > >>>>> who can do this, but I think you should have some plan for who is > going to > >>>>> work on it. It won't be btc1 and Bitcoin Core, it'll just be btc1 > after the > >>>>> fork (I don't know and maybe Classic/Unlimited?) > >>>>> > >>>>> NB: I think this has very low probability, but it's kind of crazy to > me > >>>>> that you don't even have a plan for what to do if you succeed. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Oct 25, 2017 at 2:57 PM, Jeff Garzik via Bitcoin-segwit2x > >>>>> wrote: > >>>>>> > >>>>>> Chris, > >>>>>> > >>>>>> There is no reallocation of time or commitment. Metronome and Bloq > >>>>>> are off-topic on this list, so I'll only cover this once. > >>>>>> > >>>>>> I run a company, Bloq, with over 25 team members -- not just one. > >>>>>> Just like many other companies, we have multiple projects running > >>>>>> simultaneously, and Metronome is one of those. Our primary product > is > >>>>>> BloqEnterprise, which is a supported-Bitcoin product in the style > of Red Hat > >>>>>> Enterprise Linux. Majority of Bloq revenue comes from Bitcoin. If > you are > >>>>>> a large enterprise that needs Bitcoin support (or a very well funded > >>>>>> startup), we would be happy to discuss a customer agreement. > BloqEnterprise > >>>>>> v1 is Bitcoin-only; BloqEnterprise v2 will be adding other chains > to our > >>>>>> product, such as Litecoin or Bitcoin Cash, as well as Eth/Etc > support, based > >>>>>> on customer demand. > >>>>>> > >>>>>> Our vision at Bloq has always been: Multi-chain, multi-token, > >>>>>> multi-network, with Bitcoin - BTC - as the root of a security tree. > >>>>>> > >>>>>> > >>>>>> As for btc1: As was stated in August, months ago, the code is in > >>>>>> feature freeze until after the fork. It is a software engineering > goal to > >>>>>> keep changes to an absolute minimum, and that is what btc1 is doing. > >>>>>> > >>>>>> After the fork, btc1 will be continuing as a sort of "Fedora for > >>>>>> Bitcoin" -- very exciting stuff, and a useful way to risk adjust > versus > >>>>>> Bitcoin Core instability or feature selection. Several btc1 > members have > >>>>>> proposed new btc1 changes for post-fork, large and small. It will > be a very > >>>>>> nice addition to the Bitcoin community to have an additional outlet > for > >>>>>> feature requests such as this one, a small change that makes life > easier for > >>>>>> DevOps: https://github.com/btc1/bitcoin/issues/107 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Wed, Oct 25, 2017 at 11:32 AM, Chris Stewart < > chris at suredbits.com> > >>>>>> wrote: > >>>>>>> > >>>>>>> Has there been any thought to who will be maintaining B2X after the > >>>>>>> chain split is completed? It seems the only dev, Jeff, has > committed his > >>>>>>> time to a new project called Metronome. It doesn't appear that any > >>>>>>> significant portion of the bitcoin core developers are willing to > put their > >>>>>>> time and effort into this project. > >>>>>>> > >>>>>>> So is the plan to just fork and abandon the btc1 codebase? > >>>>>>> > >>>>>>> -Chris > >>>>>>> > >>>>>>> On Wed, Oct 25, 2017 at 1:19 PM, Melvin Carvalho via > Bitcoin-segwit2x > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi all! > >>>>>>>>> > >>>>>>>>> This is a follow-on from the previous status update in August: > >>>>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin- > segwit2x/2017-August/000265.html > >>>>>>>>> > >>>>>>>>> 1. To state the obvious, everything is still full steam ahead for > >>>>>>>>> segwit2x upgrade in mid-November. > >>>>>>>>> > >>>>>>>>> 2. As noted in August, the project continues to be in a code > freeze > >>>>>>>>> for the fork: https://en.wikipedia.org/wiki/ > Freeze_(software_engineering) > >>>>>>>>> Only changes or fixes thought to be important pre-fork will be > included. > >>>>>>>>> > >>>>>>>>> 3. Reviewing the btc1 project and branch policies, btc1 is a > source > >>>>>>>>> code fork of Bitcoin Core, very much like Fedora Linux is a > >>>>>>>>> fork/distribution intended for end users. As such, we track > Bitcoin Core > >>>>>>>>> updates as necessary and pull those into the project. > >>>>>>>>> > >>>>>>>>> 4. "segwit2x" is the production release branch for the SegWit2x > >>>>>>>>> Working Group, and the latest release can be downloaded here: > >>>>>>>>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 > >>>>>>>>> > >>>>>>>>> 5. "segwit2x-dev" is the development and testing release branch. > >>>>>>>>> New changes go to segwit2x-dev first, for external testing and > feedback, > >>>>>>>>> before being merged into the production branch, and labelled a > production > >>>>>>>>> release. > >>>>>>>>> > >>>>>>>>> 6. The current segwit2x production release, on the segwit2x > branch, > >>>>>>>>> is based on Bitcoin Core 0.14.x. The current dev release is > based on > >>>>>>>>> Bitcoin Core 0.15.x. > >>>>>>>>> > >>>>>>>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x > >>>>>>>>> rollout. Based on instability and bugs that upstream Bitcoin > Core project > >>>>>>>>> is seeing - ie. Core's bugs not ours - segwit2x will stay on > Bitcoin Core > >>>>>>>>> 0.14.x through the November fork. This is the most stable path > for users, > >>>>>>>>> based on upstream Bitcoin Core instability. > >>>>>>>>> > >>>>>>>>> In short we -do not- feel that Bitcoin Core bugs and instability > >>>>>>>>> will impact our project in the short term, because this is not > yet in a > >>>>>>>>> segwit2x production release on a production branch. > >>>>>>>>> > >>>>>>>>> 8. The only change worth noting is a likely be an adjustment of > >>>>>>>>> miner policy defaults that will be accepted through the code > freeze: > >>>>>>>>> https://github.com/btc1/bitcoin/pull/136 > >>>>>>>>> > >>>>>>>>> Thanks everyone! > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks for the update. > >>>>>>>> > >>>>>>>> There was a question on a previous thread that I think went > >>>>>>>> unanswered. > >>>>>>>> > >>>>>>>> Is the threshold for release still 80% miner signaling? > >>>>>>>> > >>>>>>>> If miner signaling for NYA falls significantly, would it be > >>>>>>>> considered new information? > >>>>>>>> > >>>>>>>> FYI: latest metric is NYA signaling at 75% in the last 24h [1], > with > >>>>>>>> the position of ViaBTC still unclear > >>>>>>>> > >>>>>>>> [1] https://coin.dance/blocks > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Jeff Garzik > >>>>>>>>> CEO and Co Founder > >>>>>>>>> Bloq, Inc. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Bitcoin-segwit2x mailing list > >>>>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org > >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin- > segwit2x > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Bitcoin-segwit2x mailing list > >>>>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org > >>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin- > segwit2x > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Jeff Garzik > >>>>>> CEO and Co Founder > >>>>>> Bloq, Inc. > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Bitcoin-segwit2x mailing list > >>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org > >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Jeff Garzik > >>>> CEO and Co Founder > >>>> Bloq, Inc. > >>>> > >>> > >> > >> > >> > >> -- > >> Jeff Garzik > >> CEO and Co Founder > >> Bloq, Inc. > >> > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.eliosoff at gmail.com Wed Oct 25 20:53:46 2017 From: jacob.eliosoff at gmail.com (Jacob Eliosoff) Date: Wed, 25 Oct 2017 16:53:46 -0400 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: > > FYI: latest metric is NYA signaling at 75% in the last 24h [1], with the > position of ViaBTC still unclear > For the record, the drop from 85% to 77% appears to be entirely because in the last 24 hrs F2Pool shot up from ~7% to ~15%. We'll see if they maintain that or if it's just a blip, but it's not because, eg, another big miner/pool stopped signaling 2x. (If one does, many of us will be interested to hear about it!) On Wed, Oct 25, 2017 at 2:19 PM, Melvin Carvalho via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > > On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> Hi all! >> >> This is a follow-on from the previous status update in August: >> https://lists.linuxfoundation.org/pipermail/bitcoin- >> segwit2x/2017-August/000265.html >> >> 1. To state the obvious, everything is still full steam ahead for >> segwit2x upgrade in mid-November. >> >> 2. As noted in August, the project continues to be in a code freeze for >> the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) >> Only changes or fixes thought to be important pre-fork will be included. >> >> 3. Reviewing the btc1 project and branch policies, btc1 is a source code >> fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution >> intended for end users. As such, we track Bitcoin Core updates as >> necessary and pull those into the project. >> >> 4. "segwit2x" is the production release branch for the SegWit2x Working >> Group, and the latest release can be downloaded here: >> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >> >> 5. "segwit2x-dev" is the development and testing release branch. New >> changes go to segwit2x-dev first, for external testing and feedback, before >> being merged into the production branch, and labelled a production release. >> >> 6. The current segwit2x production release, on the segwit2x branch, is >> based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin >> Core 0.15.x. >> >> 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. >> Based on instability and bugs that upstream Bitcoin Core project is seeing >> - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x >> through the November fork. This is the most stable path for users, based >> on upstream Bitcoin Core instability. >> >> In short we -do not- feel that Bitcoin Core bugs and instability will >> impact our project in the short term, because this is not yet in a segwit2x >> production release on a production branch. >> >> 8. The only change worth noting is a likely be an adjustment of miner >> policy defaults that will be accepted through the code freeze: >> https://github.com/btc1/bitcoin/pull/136 >> >> Thanks everyone! >> > > Thanks for the update. > > There was a question on a previous thread that I think went unanswered. > > Is the threshold for release still 80% miner signaling? > > If miner signaling for NYA falls significantly, would it be considered new > information? > > FYI: latest metric is NYA signaling at 75% in the last 24h [1], with the > position of ViaBTC still unclear > > [1] https://coin.dance/blocks > >> >> >> -- >> Jeff Garzik >> CEO and Co Founder >> Bloq, Inc. >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekatete at hotmail.com Wed Oct 25 21:23:36 2017 From: pekatete at hotmail.com (Phillip Katete) Date: Wed, 25 Oct 2017 21:23:36 +0000 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: , Message-ID: * I think 2x had, and continues to have mind share. * But certainly not on an accelerated timescale, which lacks consensus. * That is simply suicidal. What constitutes an accelerated timescale? When it comes to consensus (the none Sybil resistant kind that Core would consider adequate), the opportunity to establish that was snuffed out by censorship. It is the same crowd that instigated, supported and condoned that censorship that are claiming a lack of consensus as being reason enough to halt the upgrade of network rules because it is apparently being done on an ?accelerated timescale? . -------------- next part -------------- An HTML attachment was scrubbed... URL: From djpnewton at gmail.com Wed Oct 25 22:52:05 2017 From: djpnewton at gmail.com (Daniel Newton) Date: Thu, 26 Oct 2017 11:52:05 +1300 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: >7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. Based on instability and bugs that upstream >Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the >November fork. This is the most stable path for users, based on upstream Bitcoin Core instability. Is there a list of these issues? I havent heard of any problems except for the GUI issue that prompted the 0.15.0.1 release The issue tracker ( https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+label%3ABug+is%3Aopen) does not show anything out of the ordinary On Thu, Oct 26, 2017 at 6:54 AM, Jeff Garzik via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Hi all! > > This is a follow-on from the previous status update in August: > https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/ > 000265.html > > 1. To state the obvious, everything is still full steam ahead for segwit2x > upgrade in mid-November. > > 2. As noted in August, the project continues to be in a code freeze for > the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) > Only changes or fixes thought to be important pre-fork will be included. > > 3. Reviewing the btc1 project and branch policies, btc1 is a source code > fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution > intended for end users. As such, we track Bitcoin Core updates as > necessary and pull those into the project. > > 4. "segwit2x" is the production release branch for the SegWit2x Working > Group, and the latest release can be downloaded here: > https://github.com/btc1/bitcoin/releases/tag/v1.14.5 > > 5. "segwit2x-dev" is the development and testing release branch. New > changes go to segwit2x-dev first, for external testing and feedback, before > being merged into the production branch, and labelled a production release. > > 6. The current segwit2x production release, on the segwit2x branch, is > based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin > Core 0.15.x. > > 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. > Based on instability and bugs that upstream Bitcoin Core project is seeing > - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x > through the November fork. This is the most stable path for users, based > on upstream Bitcoin Core instability. > > In short we -do not- feel that Bitcoin Core bugs and instability will > impact our project in the short term, because this is not yet in a segwit2x > production release on a production branch. > > 8. The only change worth noting is a likely be an adjustment of miner > policy defaults that will be accepted through the code freeze: > https://github.com/btc1/bitcoin/pull/136 > > Thanks everyone! > > -- > Jeff Garzik > CEO and Co Founder > Bloq, Inc. > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.madden at gmail.com Wed Oct 25 23:04:14 2017 From: will.madden at gmail.com (Will M) Date: Wed, 25 Oct 2017 16:04:14 -0700 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Daniel, https://github.com/bitcoin/bitcoin/issues Will On Oct 25, 2017, 3:52 PM -0700, Daniel Newton via Bitcoin-segwit2x , wrote: > >7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. ? ?Based on instability and bugs that upstream > >Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the > >November fork.? This is the most stable path for users, based on upstream Bitcoin Core instability. > > Is there a list of these issues? > > I havent heard of any problems except for the GUI issue that prompted the 0.15.0.1 release > > The issue tracker (https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+label%3ABug+is%3Aopen) does not show anything out of the ordinary > > > On Thu, Oct 26, 2017 at 6:54 AM, Jeff Garzik via Bitcoin-segwit2x wrote: > > > Hi all! > > > > > > This is a follow-on from the previous status update in August:?https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html > > > > > > 1. To state the obvious, everything is still full steam ahead for segwit2x upgrade in mid-November. > > > > > > 2. As noted in August, the project continues to be in a code freeze for the fork: ?https://en.wikipedia.org/wiki/Freeze_(software_engineering) ? Only changes or fixes thought to be important pre-fork will be included. > > > > > > 3. Reviewing the btc1 project and branch policies, btc1 is a source code fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution intended for end users.? As such, we track Bitcoin Core updates as necessary and pull those into the project. > > > > > > 4. "segwit2x" is the production release branch for the SegWit2x Working Group, and the latest release can be downloaded here:?https://github.com/btc1/bitcoin/releases/tag/v1.14.5 > > > > > > 5. "segwit2x-dev" is the development and testing release branch.? New changes go to segwit2x-dev first, for external testing and feedback, before being merged into the production branch, and labelled a production release. > > > > > > 6. The current segwit2x production release, on the segwit2x branch, is based on Bitcoin Core 0.14.x. ? The current dev release is based on Bitcoin Core 0.15.x. > > > > > > 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. ? ?Based on instability and bugs that upstream Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the November fork.? This is the most stable path for users, based on upstream Bitcoin Core instability. > > > > > > In short we -do not- feel that Bitcoin Core bugs and instability will impact our project in the short term, because this is not yet in a segwit2x production release on a production branch. > > > > > > 8. The only change worth noting is a likely be an adjustment of miner policy defaults that will be accepted through the code freeze:?https://github.com/btc1/bitcoin/pull/136 > > > > > > Thanks everyone! > > > > > > -- > > > Jeff Garzik > > > CEO and Co Founder > > > Bloq, Inc. > > > > > > > > > _______________________________________________ > > > Bitcoin-segwit2x mailing list > > > Bitcoin-segwit2x at lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Wed Oct 25 23:39:50 2017 From: bitpico at icloud.com (bitPico) Date: Wed, 25 Oct 2017 19:39:50 -0400 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: <230866A5-27A1-4AD8-9322-54A5B5875921@icloud.com> Bitcoin Core does not open GitHub tickets for ZeroDay exploits. That said; 0.15 is very experimental and most likely contains exploits that only the Core Developers are aware of. 0.14 is the most stable Bitcoin Core codebase and cannot be attacked by ?secret bugs? because they don?t exist any longer. Sent from my Space Ship. > On Oct 25, 2017, at 6:52 PM, Daniel Newton via Bitcoin-segwit2x wrote: > > >7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. Based on instability and bugs that upstream > >Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the > >November fork. This is the most stable path for users, based on upstream Bitcoin Core instability. > > Is there a list of these issues? > > I havent heard of any problems except for the GUI issue that prompted the 0.15.0.1 release > > The issue tracker (https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+label%3ABug+is%3Aopen) does not show anything out of the ordinary > >> On Thu, Oct 26, 2017 at 6:54 AM, Jeff Garzik via Bitcoin-segwit2x wrote: >> Hi all! >> >> This is a follow-on from the previous status update in August: https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html >> >> 1. To state the obvious, everything is still full steam ahead for segwit2x upgrade in mid-November. >> >> 2. As noted in August, the project continues to be in a code freeze for the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) Only changes or fixes thought to be important pre-fork will be included. >> >> 3. Reviewing the btc1 project and branch policies, btc1 is a source code fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution intended for end users. As such, we track Bitcoin Core updates as necessary and pull those into the project. >> >> 4. "segwit2x" is the production release branch for the SegWit2x Working Group, and the latest release can be downloaded here: https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >> >> 5. "segwit2x-dev" is the development and testing release branch. New changes go to segwit2x-dev first, for external testing and feedback, before being merged into the production branch, and labelled a production release. >> >> 6. The current segwit2x production release, on the segwit2x branch, is based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin Core 0.15.x. >> >> 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. Based on instability and bugs that upstream Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the November fork. This is the most stable path for users, based on upstream Bitcoin Core instability. >> >> In short we -do not- feel that Bitcoin Core bugs and instability will impact our project in the short term, because this is not yet in a segwit2x production release on a production branch. >> >> 8. The only change worth noting is a likely be an adjustment of miner policy defaults that will be accepted through the code freeze: https://github.com/btc1/bitcoin/pull/136 >> >> Thanks everyone! >> >> -- >> Jeff Garzik >> CEO and Co Founder >> Bloq, Inc. >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.madden at gmail.com Wed Oct 25 23:43:16 2017 From: will.madden at gmail.com (Will M) Date: Wed, 25 Oct 2017 16:43:16 -0700 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: <230866A5-27A1-4AD8-9322-54A5B5875921@icloud.com> References: <230866A5-27A1-4AD8-9322-54A5B5875921@icloud.com> Message-ID: bitPico, so you can say with confidence that the 518 open issues are all thoroughly analyzed and non-critical issues? I do not believe you. On Oct 25, 2017, 4:40 PM -0700, bitPico via Bitcoin-segwit2x , wrote: > Bitcoin Core does not open GitHub tickets for ZeroDay exploits. That said; 0.15 is very experimental and most likely contains exploits that only the Core Developers are aware of. 0.14 is the most stable Bitcoin Core codebase and cannot be attacked by ?secret bugs? because they don?t exist any longer. > > Sent from my Space Ship. > > On Oct 25, 2017, at 6:52 PM, Daniel Newton via Bitcoin-segwit2x wrote: > > > >7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. ? ?Based on instability and bugs that upstream > > >Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the > > >November fork.? This is the most stable path for users, based on upstream Bitcoin Core instability. > > > > Is there a list of these issues? > > > > I havent heard of any problems except for the GUI issue that prompted the 0.15.0.1 release > > > > The issue tracker (https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+label%3ABug+is%3Aopen) does not show anything out of the ordinary > > > > > On Thu, Oct 26, 2017 at 6:54 AM, Jeff Garzik via Bitcoin-segwit2x wrote: > > > > Hi all! > > > > > > > > This is a follow-on from the previous status update in August:?https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html > > > > > > > > 1. To state the obvious, everything is still full steam ahead for segwit2x upgrade in mid-November. > > > > > > > > 2. As noted in August, the project continues to be in a code freeze for the fork: ?https://en.wikipedia.org/wiki/Freeze_(software_engineering) ? Only changes or fixes thought to be important pre-fork will be included. > > > > > > > > 3. Reviewing the btc1 project and branch policies, btc1 is a source code fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution intended for end users.? As such, we track Bitcoin Core updates as necessary and pull those into the project. > > > > > > > > 4. "segwit2x" is the production release branch for the SegWit2x Working Group, and the latest release can be downloaded here:?https://github.com/btc1/bitcoin/releases/tag/v1.14.5 > > > > > > > > 5. "segwit2x-dev" is the development and testing release branch.? New changes go to segwit2x-dev first, for external testing and feedback, before being merged into the production branch, and labelled a production release. > > > > > > > > 6. The current segwit2x production release, on the segwit2x branch, is based on Bitcoin Core 0.14.x. ? The current dev release is based on Bitcoin Core 0.15.x. > > > > > > > > 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. ? ?Based on instability and bugs that upstream Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the November fork.? This is the most stable path for users, based on upstream Bitcoin Core instability. > > > > > > > > In short we -do not- feel that Bitcoin Core bugs and instability will impact our project in the short term, because this is not yet in a segwit2x production release on a production branch. > > > > > > > > 8. The only change worth noting is a likely be an adjustment of miner policy defaults that will be accepted through the code freeze:?https://github.com/btc1/bitcoin/pull/136 > > > > > > > > Thanks everyone! > > > > > > > > -- > > > > Jeff Garzik > > > > CEO and Co Founder > > > > Bloq, Inc. > > > > > > > > > > > > _______________________________________________ > > > > Bitcoin-segwit2x mailing list > > > > Bitcoin-segwit2x at lists.linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.madden at gmail.com Wed Oct 25 23:46:28 2017 From: will.madden at gmail.com (Will M) Date: Wed, 25 Oct 2017 16:46:28 -0700 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: <230866A5-27A1-4AD8-9322-54A5B5875921@icloud.com> Message-ID: Apologies, and I think we agree. There is an unacceptably high risk that ?secret bugs? could be hidden in the 518 open issues, it?s unreasonable to resolve this much noise by the blockheight of the fork, and therefore 0.15 is a no-go for 2x. Again, I apologize. I believe I misread your email. On Oct 25, 2017, 4:43 PM -0700, Will M , wrote: > bitPico, so you can say with confidence that the 518 open issues are all thoroughly analyzed and non-critical issues? I do not believe you. > > On Oct 25, 2017, 4:40 PM -0700, bitPico via Bitcoin-segwit2x , wrote: > > Bitcoin Core does not open GitHub tickets for ZeroDay exploits. That said; 0.15 is very experimental and most likely contains exploits that only the Core Developers are aware of. 0.14 is the most stable Bitcoin Core codebase and cannot be attacked by ?secret bugs? because they don?t exist any longer. > > > > Sent from my Space Ship. > > > > On Oct 25, 2017, at 6:52 PM, Daniel Newton via Bitcoin-segwit2x wrote: > > > > > >7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. ? ?Based on instability and bugs that upstream > > > >Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the > > > >November fork.? This is the most stable path for users, based on upstream Bitcoin Core instability. > > > > > > Is there a list of these issues? > > > > > > I havent heard of any problems except for the GUI issue that prompted the 0.15.0.1 release > > > > > > The issue tracker (https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+label%3ABug+is%3Aopen) does not show anything out of the ordinary > > > > > > > On Thu, Oct 26, 2017 at 6:54 AM, Jeff Garzik via Bitcoin-segwit2x wrote: > > > > > Hi all! > > > > > > > > > > This is a follow-on from the previous status update in August:?https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html > > > > > > > > > > 1. To state the obvious, everything is still full steam ahead for segwit2x upgrade in mid-November. > > > > > > > > > > 2. As noted in August, the project continues to be in a code freeze for the fork: ?https://en.wikipedia.org/wiki/Freeze_(software_engineering) ? Only changes or fixes thought to be important pre-fork will be included. > > > > > > > > > > 3. Reviewing the btc1 project and branch policies, btc1 is a source code fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution intended for end users.? As such, we track Bitcoin Core updates as necessary and pull those into the project. > > > > > > > > > > 4. "segwit2x" is the production release branch for the SegWit2x Working Group, and the latest release can be downloaded here:?https://github.com/btc1/bitcoin/releases/tag/v1.14.5 > > > > > > > > > > 5. "segwit2x-dev" is the development and testing release branch.? New changes go to segwit2x-dev first, for external testing and feedback, before being merged into the production branch, and labelled a production release. > > > > > > > > > > 6. The current segwit2x production release, on the segwit2x branch, is based on Bitcoin Core 0.14.x. ? The current dev release is based on Bitcoin Core 0.15.x. > > > > > > > > > > 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. ? ?Based on instability and bugs that upstream Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the November fork.? This is the most stable path for users, based on upstream Bitcoin Core instability. > > > > > > > > > > In short we -do not- feel that Bitcoin Core bugs and instability will impact our project in the short term, because this is not yet in a segwit2x production release on a production branch. > > > > > > > > > > 8. The only change worth noting is a likely be an adjustment of miner policy defaults that will be accepted through the code freeze:?https://github.com/btc1/bitcoin/pull/136 > > > > > > > > > > Thanks everyone! > > > > > > > > > > -- > > > > > Jeff Garzik > > > > > CEO and Co Founder > > > > > Bloq, Inc. > > > > > > > > > > > > > > > _______________________________________________ > > > > > Bitcoin-segwit2x mailing list > > > > > Bitcoin-segwit2x at lists.linuxfoundation.org > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > > > > > > _______________________________________________ > > > Bitcoin-segwit2x mailing list > > > Bitcoin-segwit2x at lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Wed Oct 25 23:49:46 2017 From: bitpico at icloud.com (bitPico) Date: Wed, 25 Oct 2017 19:49:46 -0400 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: <230866A5-27A1-4AD8-9322-54A5B5875921@icloud.com> Message-ID: <9B745FED-4461-4501-8C47-8B4A99076E78@icloud.com> No; our statement was clear: Bitcoin Core 0.15 most likely contains developer only known bugs or ZeroDay flaws. 0.14 is the safest base code in that regard. EOC Thanks! > On Oct 25, 2017, at 7:43 PM, Will M wrote: > > bitPico, so you can say with confidence that the 518 open issues are all thoroughly analyzed and non-critical issues? I do not believe you. > >> On Oct 25, 2017, 4:40 PM -0700, bitPico via Bitcoin-segwit2x , wrote: >> Bitcoin Core does not open GitHub tickets for ZeroDay exploits. That said; 0.15 is very experimental and most likely contains exploits that only the Core Developers are aware of. 0.14 is the most stable Bitcoin Core codebase and cannot be attacked by ?secret bugs? because they don?t exist any longer. >> >> Sent from my Space Ship. >> >> On Oct 25, 2017, at 6:52 PM, Daniel Newton via Bitcoin-segwit2x wrote: >> >>> >7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. Based on instability and bugs that upstream >>> >Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the >>> >November fork. This is the most stable path for users, based on upstream Bitcoin Core instability. >>> >>> Is there a list of these issues? >>> >>> I havent heard of any problems except for the GUI issue that prompted the 0.15.0.1 release >>> >>> The issue tracker (https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+label%3ABug+is%3Aopen) does not show anything out of the ordinary >>> >>>> On Thu, Oct 26, 2017 at 6:54 AM, Jeff Garzik via Bitcoin-segwit2x wrote: >>>> Hi all! >>>> >>>> This is a follow-on from the previous status update in August: https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html >>>> >>>> 1. To state the obvious, everything is still full steam ahead for segwit2x upgrade in mid-November. >>>> >>>> 2. As noted in August, the project continues to be in a code freeze for the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) Only changes or fixes thought to be important pre-fork will be included. >>>> >>>> 3. Reviewing the btc1 project and branch policies, btc1 is a source code fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution intended for end users. As such, we track Bitcoin Core updates as necessary and pull those into the project. >>>> >>>> 4. "segwit2x" is the production release branch for the SegWit2x Working Group, and the latest release can be downloaded here: https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>>> >>>> 5. "segwit2x-dev" is the development and testing release branch. New changes go to segwit2x-dev first, for external testing and feedback, before being merged into the production branch, and labelled a production release. >>>> >>>> 6. The current segwit2x production release, on the segwit2x branch, is based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin Core 0.15.x. >>>> >>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. Based on instability and bugs that upstream Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the November fork. This is the most stable path for users, based on upstream Bitcoin Core instability. >>>> >>>> In short we -do not- feel that Bitcoin Core bugs and instability will impact our project in the short term, because this is not yet in a segwit2x production release on a production branch. >>>> >>>> 8. The only change worth noting is a likely be an adjustment of miner policy defaults that will be accepted through the code freeze: https://github.com/btc1/bitcoin/pull/136 >>>> >>>> Thanks everyone! >>>> >>>> -- >>>> Jeff Garzik >>>> CEO and Co Founder >>>> Bloq, Inc. >>>> >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.madden at gmail.com Wed Oct 25 23:50:56 2017 From: will.madden at gmail.com (Will M) Date: Wed, 25 Oct 2017 16:50:56 -0700 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: <9B745FED-4461-4501-8C47-8B4A99076E78@icloud.com> References: <230866A5-27A1-4AD8-9322-54A5B5875921@icloud.com> <9B745FED-4461-4501-8C47-8B4A99076E78@icloud.com> Message-ID: <7d79b5ef-598f-4991-aa12-bd43e91c3769@Spark> Are you aware of a ZeroDay flaw that you are at liberty to share? Even if you cannot, I agree with your statement and position. On Oct 25, 2017, 4:49 PM -0700, bitPico , wrote: > No; our statement was clear: Bitcoin Core 0.15 most likely contains developer only known bugs or ZeroDay flaws. 0.14 is the safest base code in that regard. > > EOC > > Thanks! > > On Oct 25, 2017, at 7:43 PM, Will M wrote: > > > bitPico, so you can say with confidence that the 518 open issues are all thoroughly analyzed and non-critical issues? I do not believe you. > > > > On Oct 25, 2017, 4:40 PM -0700, bitPico via Bitcoin-segwit2x , wrote: > > > Bitcoin Core does not open GitHub tickets for ZeroDay exploits. That said; 0.15 is very experimental and most likely contains exploits that only the Core Developers are aware of. 0.14 is the most stable Bitcoin Core codebase and cannot be attacked by ?secret bugs? because they don?t exist any longer. > > > > > > Sent from my Space Ship. > > > > > > On Oct 25, 2017, at 6:52 PM, Daniel Newton via Bitcoin-segwit2x wrote: > > > > > > > >7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. ? ?Based on instability and bugs that upstream > > > > >Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the > > > > >November fork.? This is the most stable path for users, based on upstream Bitcoin Core instability. > > > > > > > > Is there a list of these issues? > > > > > > > > I havent heard of any problems except for the GUI issue that prompted the 0.15.0.1 release > > > > > > > > The issue tracker (https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+label%3ABug+is%3Aopen) does not show anything out of the ordinary > > > > > > > > > On Thu, Oct 26, 2017 at 6:54 AM, Jeff Garzik via Bitcoin-segwit2x wrote: > > > > > > Hi all! > > > > > > > > > > > > This is a follow-on from the previous status update in August:?https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html > > > > > > > > > > > > 1. To state the obvious, everything is still full steam ahead for segwit2x upgrade in mid-November. > > > > > > > > > > > > 2. As noted in August, the project continues to be in a code freeze for the fork: ?https://en.wikipedia.org/wiki/Freeze_(software_engineering) ? Only changes or fixes thought to be important pre-fork will be included. > > > > > > > > > > > > 3. Reviewing the btc1 project and branch policies, btc1 is a source code fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution intended for end users.? As such, we track Bitcoin Core updates as necessary and pull those into the project. > > > > > > > > > > > > 4. "segwit2x" is the production release branch for the SegWit2x Working Group, and the latest release can be downloaded here:?https://github.com/btc1/bitcoin/releases/tag/v1.14.5 > > > > > > > > > > > > 5. "segwit2x-dev" is the development and testing release branch.? New changes go to segwit2x-dev first, for external testing and feedback, before being merged into the production branch, and labelled a production release. > > > > > > > > > > > > 6. The current segwit2x production release, on the segwit2x branch, is based on Bitcoin Core 0.14.x. ? The current dev release is based on Bitcoin Core 0.15.x. > > > > > > > > > > > > 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. ? ?Based on instability and bugs that upstream Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the November fork.? This is the most stable path for users, based on upstream Bitcoin Core instability. > > > > > > > > > > > > In short we -do not- feel that Bitcoin Core bugs and instability will impact our project in the short term, because this is not yet in a segwit2x production release on a production branch. > > > > > > > > > > > > 8. The only change worth noting is a likely be an adjustment of miner policy defaults that will be accepted through the code freeze:?https://github.com/btc1/bitcoin/pull/136 > > > > > > > > > > > > Thanks everyone! > > > > > > > > > > > > -- > > > > > > Jeff Garzik > > > > > > CEO and Co Founder > > > > > > Bloq, Inc. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Bitcoin-segwit2x mailing list > > > > > > Bitcoin-segwit2x at lists.linuxfoundation.org > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > > > > > > > > > _______________________________________________ > > > > Bitcoin-segwit2x mailing list > > > > Bitcoin-segwit2x at lists.linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Wed Oct 25 23:58:10 2017 From: bitpico at icloud.com (bitPico) Date: Wed, 25 Oct 2017 19:58:10 -0400 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: <7d79b5ef-598f-4991-aa12-bd43e91c3769@Spark> References: <230866A5-27A1-4AD8-9322-54A5B5875921@icloud.com> <9B745FED-4461-4501-8C47-8B4A99076E78@icloud.com> <7d79b5ef-598f-4991-aa12-bd43e91c3769@Spark> Message-ID: <5FCE2622-80FB-4438-832B-24B9B7ED16D0@icloud.com> ZeroDay flaws are to be reserved for special occasions. They are not meant to be shared or discussed. They have a very high value dollar-wise and also make for good bartering or deal making. Does 0.15 have ZeroDay flaws? Perhaps... > On Oct 25, 2017, at 7:50 PM, Will M wrote: > > Are you aware of a ZeroDay flaw that you are at liberty to share? Even if you cannot, I agree with your statement and position. > >> On Oct 25, 2017, 4:49 PM -0700, bitPico , wrote: >> No; our statement was clear: Bitcoin Core 0.15 most likely contains developer only known bugs or ZeroDay flaws. 0.14 is the safest base code in that regard. >> >> EOC >> >> Thanks! >> >> On Oct 25, 2017, at 7:43 PM, Will M wrote: >> >>> bitPico, so you can say with confidence that the 518 open issues are all thoroughly analyzed and non-critical issues? I do not believe you. >>> >>>> On Oct 25, 2017, 4:40 PM -0700, bitPico via Bitcoin-segwit2x , wrote: >>>> Bitcoin Core does not open GitHub tickets for ZeroDay exploits. That said; 0.15 is very experimental and most likely contains exploits that only the Core Developers are aware of. 0.14 is the most stable Bitcoin Core codebase and cannot be attacked by ?secret bugs? because they don?t exist any longer. >>>> >>>> Sent from my Space Ship. >>>> >>>> On Oct 25, 2017, at 6:52 PM, Daniel Newton via Bitcoin-segwit2x wrote: >>>> >>>>> >7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. Based on instability and bugs that upstream >>>>> >Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the >>>>> >November fork. This is the most stable path for users, based on upstream Bitcoin Core instability. >>>>> >>>>> Is there a list of these issues? >>>>> >>>>> I havent heard of any problems except for the GUI issue that prompted the 0.15.0.1 release >>>>> >>>>> The issue tracker (https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+label%3ABug+is%3Aopen) does not show anything out of the ordinary >>>>> >>>>>> On Thu, Oct 26, 2017 at 6:54 AM, Jeff Garzik via Bitcoin-segwit2x wrote: >>>>>> Hi all! >>>>>> >>>>>> This is a follow-on from the previous status update in August: https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html >>>>>> >>>>>> 1. To state the obvious, everything is still full steam ahead for segwit2x upgrade in mid-November. >>>>>> >>>>>> 2. As noted in August, the project continues to be in a code freeze for the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) Only changes or fixes thought to be important pre-fork will be included. >>>>>> >>>>>> 3. Reviewing the btc1 project and branch policies, btc1 is a source code fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution intended for end users. As such, we track Bitcoin Core updates as necessary and pull those into the project. >>>>>> >>>>>> 4. "segwit2x" is the production release branch for the SegWit2x Working Group, and the latest release can be downloaded here: https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>>>>> >>>>>> 5. "segwit2x-dev" is the development and testing release branch. New changes go to segwit2x-dev first, for external testing and feedback, before being merged into the production branch, and labelled a production release. >>>>>> >>>>>> 6. The current segwit2x production release, on the segwit2x branch, is based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin Core 0.15.x. >>>>>> >>>>>> 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. Based on instability and bugs that upstream Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the November fork. This is the most stable path for users, based on upstream Bitcoin Core instability. >>>>>> >>>>>> In short we -do not- feel that Bitcoin Core bugs and instability will impact our project in the short term, because this is not yet in a segwit2x production release on a production branch. >>>>>> >>>>>> 8. The only change worth noting is a likely be an adjustment of miner policy defaults that will be accepted through the code freeze: https://github.com/btc1/bitcoin/pull/136 >>>>>> >>>>>> Thanks everyone! >>>>>> >>>>>> -- >>>>>> Jeff Garzik >>>>>> CEO and Co Founder >>>>>> Bloq, Inc. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Bitcoin-segwit2x mailing list >>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Bitcoin-segwit2x mailing list >>>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.madden at gmail.com Wed Oct 25 23:59:24 2017 From: will.madden at gmail.com (Will M) Date: Wed, 25 Oct 2017 16:59:24 -0700 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: <5FCE2622-80FB-4438-832B-24B9B7ED16D0@icloud.com> References: <230866A5-27A1-4AD8-9322-54A5B5875921@icloud.com> <9B745FED-4461-4501-8C47-8B4A99076E78@icloud.com> <7d79b5ef-598f-4991-aa12-bd43e91c3769@Spark> <5FCE2622-80FB-4438-832B-24B9B7ED16D0@icloud.com> Message-ID: <664ea170-40ef-4b7c-9539-a3c86b4ebdf4@Spark> We need to move onto a model where hammered cryptographic hash functions and ?peer reviewed? cryptographic primitives are insufficient; all of these things should be approached with suspicion. All that said, if you are selling, I?ll find a buyer. Cheers. On Oct 25, 2017, 4:58 PM -0700, bitPico , wrote: > ZeroDay flaws are to be reserved for special occasions. They are not meant to be shared or discussed. They have a very high value dollar-wise and also make for good bartering or deal making. Does 0.15 have ZeroDay flaws? Perhaps... > > On Oct 25, 2017, at 7:50 PM, Will M wrote: > > > Are you aware of a ZeroDay flaw that you are at liberty to share? Even if you cannot, I agree with your statement and position. > > > > On Oct 25, 2017, 4:49 PM -0700, bitPico , wrote: > > > No; our statement was clear: Bitcoin Core 0.15 most likely contains developer only known bugs or ZeroDay flaws. 0.14 is the safest base code in that regard. > > > > > > EOC > > > > > > Thanks! > > > > > > On Oct 25, 2017, at 7:43 PM, Will M wrote: > > > > > > > bitPico, so you can say with confidence that the 518 open issues are all thoroughly analyzed and non-critical issues? I do not believe you. > > > > > > > > On Oct 25, 2017, 4:40 PM -0700, bitPico via Bitcoin-segwit2x , wrote: > > > > > Bitcoin Core does not open GitHub tickets for ZeroDay exploits. That said; 0.15 is very experimental and most likely contains exploits that only the Core Developers are aware of. 0.14 is the most stable Bitcoin Core codebase and cannot be attacked by ?secret bugs? because they don?t exist any longer. > > > > > > > > > > Sent from my Space Ship. > > > > > > > > > > On Oct 25, 2017, at 6:52 PM, Daniel Newton via Bitcoin-segwit2x wrote: > > > > > > > > > > > >7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. ? ?Based on instability and bugs that upstream > > > > > > >Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the > > > > > > >November fork.? This is the most stable path for users, based on upstream Bitcoin Core instability. > > > > > > > > > > > > Is there a list of these issues? > > > > > > > > > > > > I havent heard of any problems except for the GUI issue that prompted the 0.15.0.1 release > > > > > > > > > > > > The issue tracker (https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+label%3ABug+is%3Aopen) does not show anything out of the ordinary > > > > > > > > > > > > > On Thu, Oct 26, 2017 at 6:54 AM, Jeff Garzik via Bitcoin-segwit2x wrote: > > > > > > > > Hi all! > > > > > > > > > > > > > > > > This is a follow-on from the previous status update in August:?https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html > > > > > > > > > > > > > > > > 1. To state the obvious, everything is still full steam ahead for segwit2x upgrade in mid-November. > > > > > > > > > > > > > > > > 2. As noted in August, the project continues to be in a code freeze for the fork: ?https://en.wikipedia.org/wiki/Freeze_(software_engineering) ? Only changes or fixes thought to be important pre-fork will be included. > > > > > > > > > > > > > > > > 3. Reviewing the btc1 project and branch policies, btc1 is a source code fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution intended for end users.? As such, we track Bitcoin Core updates as necessary and pull those into the project. > > > > > > > > > > > > > > > > 4. "segwit2x" is the production release branch for the SegWit2x Working Group, and the latest release can be downloaded here:?https://github.com/btc1/bitcoin/releases/tag/v1.14.5 > > > > > > > > > > > > > > > > 5. "segwit2x-dev" is the development and testing release branch.? New changes go to segwit2x-dev first, for external testing and feedback, before being merged into the production branch, and labelled a production release. > > > > > > > > > > > > > > > > 6. The current segwit2x production release, on the segwit2x branch, is based on Bitcoin Core 0.14.x. ? The current dev release is based on Bitcoin Core 0.15.x. > > > > > > > > > > > > > > > > 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. ? ?Based on instability and bugs that upstream Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through the November fork.? This is the most stable path for users, based on upstream Bitcoin Core instability. > > > > > > > > > > > > > > > > In short we -do not- feel that Bitcoin Core bugs and instability will impact our project in the short term, because this is not yet in a segwit2x production release on a production branch. > > > > > > > > > > > > > > > > 8. The only change worth noting is a likely be an adjustment of miner policy defaults that will be accepted through the code freeze:?https://github.com/btc1/bitcoin/pull/136 > > > > > > > > > > > > > > > > Thanks everyone! > > > > > > > > > > > > > > > > -- > > > > > > > > Jeff Garzik > > > > > > > > CEO and Co Founder > > > > > > > > Bloq, Inc. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Bitcoin-segwit2x mailing list > > > > > > > > Bitcoin-segwit2x at lists.linuxfoundation.org > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Bitcoin-segwit2x mailing list > > > > > > Bitcoin-segwit2x at lists.linuxfoundation.org > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From djpnewton at gmail.com Thu Oct 26 00:06:19 2017 From: djpnewton at gmail.com (Daniel Newton) Date: Thu, 26 Oct 2017 13:06:19 +1300 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: > https://github.com/bitcoin/bitcoin/issues > That is a big bucket that includes all sorts of things including feature requests. Specifically I am interested in the "instability and bugs" mentioned -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Thu Oct 26 00:35:34 2017 From: bitpico at icloud.com (bitPico) Date: Wed, 25 Oct 2017 20:35:34 -0400 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: <98F2A070-9B4E-45E0-A273-347715B95991@icloud.com> No need to pay attention to the GitHub issues; instead focus on the pull requests and most important the merges. This is where you find the ZeroDay exploits and other nasty bugs that go unreported but are patched in the dark of the night. The GitHub issues however do help when it comes to finding merge dates and this is where the gold is to be found. ;-) > On Oct 25, 2017, at 8:06 PM, Daniel Newton via Bitcoin-segwit2x wrote: > > > https://github.com/bitcoin/bitcoin/issues > > That is a big bucket that includes all sorts of things including feature requests. Specifically I am interested in the "instability and bugs" mentioned > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at blockstream.com Thu Oct 26 00:59:32 2017 From: adam at blockstream.com (Dr Adam Back) Date: Thu, 26 Oct 2017 01:59:32 +0100 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Indeed it's the reverse, and bad advice - there are things fixed in 0.15 from 0.14. Unless Jeff claims to know an unreported bug... btw I probably mentioned on list that I was offering 3 B2X for 2 BTC, as I got no buyers I have improved the offer to 2 B2X coins for 1 BTC, sold in 500 B2X for 250 BTC batches. No fork, no B2X coins. Adam On Wed, Oct 25, 2017 at 11:52 PM, Daniel Newton via Bitcoin-segwit2x wrote: >>7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. >> Based on instability and bugs that upstream >>Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will >> stay on Bitcoin Core 0.14.x through the >>November fork. This is the most stable path for users, based on upstream >> Bitcoin Core instability. > > Is there a list of these issues? > > I havent heard of any problems except for the GUI issue that prompted the > 0.15.0.1 release > > The issue tracker > (https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+label%3ABug+is%3Aopen) > does not show anything out of the ordinary > > On Thu, Oct 26, 2017 at 6:54 AM, Jeff Garzik via Bitcoin-segwit2x > wrote: >> >> Hi all! >> >> This is a follow-on from the previous status update in August: >> https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-August/000265.html >> >> 1. To state the obvious, everything is still full steam ahead for segwit2x >> upgrade in mid-November. >> >> 2. As noted in August, the project continues to be in a code freeze for >> the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) >> Only changes or fixes thought to be important pre-fork will be included. >> >> 3. Reviewing the btc1 project and branch policies, btc1 is a source code >> fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution >> intended for end users. As such, we track Bitcoin Core updates as necessary >> and pull those into the project. >> >> 4. "segwit2x" is the production release branch for the SegWit2x Working >> Group, and the latest release can be downloaded here: >> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >> >> 5. "segwit2x-dev" is the development and testing release branch. New >> changes go to segwit2x-dev first, for external testing and feedback, before >> being merged into the production branch, and labelled a production release. >> >> 6. The current segwit2x production release, on the segwit2x branch, is >> based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin >> Core 0.15.x. >> >> 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. >> Based on instability and bugs that upstream Bitcoin Core project is seeing - >> ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x through >> the November fork. This is the most stable path for users, based on >> upstream Bitcoin Core instability. >> >> In short we -do not- feel that Bitcoin Core bugs and instability will >> impact our project in the short term, because this is not yet in a segwit2x >> production release on a production branch. >> >> 8. The only change worth noting is a likely be an adjustment of miner >> policy defaults that will be accepted through the code freeze: >> https://github.com/btc1/bitcoin/pull/136 >> >> Thanks everyone! >> >> -- >> Jeff Garzik >> CEO and Co Founder >> Bloq, Inc. >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > From matthewpclancy at gmail.com Thu Oct 26 01:25:35 2017 From: matthewpclancy at gmail.com (Matthew Clancy) Date: Wed, 25 Oct 2017 21:25:35 -0400 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Adam, I've seen you several times now soliciting people for this gambling get-rich-quick scheme. I know it's not the place, but I just want to make sure everything is okay with you. Do you need to earn a lot of money quickly, or are you just trying to make a cheap political point? If it's the former, I hope someone here can point you in the direction of more gainful endeavors. There are better are safer ways to earn money, feel free to reach out if you're stuck and can't think of anything productive to do. If it's the latter, again, feel free to reach out if you're stuck and can't think of anything productive to do. Either way, I'm sure someone here can point you in the right direction. ?Best,? Matt On Wed, Oct 25, 2017 at 8:59 PM, Dr Adam Back via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > Indeed it's the reverse, and bad advice - there are things fixed in > 0.15 from 0.14. > > Unless Jeff claims to know an unreported bug... > > btw I probably mentioned on list that I was offering 3 B2X for 2 BTC, > as I got no buyers I have improved the offer to 2 B2X coins for 1 BTC, > sold in 500 B2X for 250 BTC batches. No fork, no B2X coins. > > Adam > > > On Wed, Oct 25, 2017 at 11:52 PM, Daniel Newton via Bitcoin-segwit2x > wrote: > >>7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. > >> Based on instability and bugs that upstream > >>Bitcoin Core project is seeing - ie. Core's bugs not ours - segwit2x will > >> stay on Bitcoin Core 0.14.x through the > >>November fork. This is the most stable path for users, based on upstream > >> Bitcoin Core instability. > > > > Is there a list of these issues? > > > > I havent heard of any problems except for the GUI issue that prompted the > > 0.15.0.1 release > > > > The issue tracker > > (https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+ > label%3ABug+is%3Aopen) > > does not show anything out of the ordinary > > > > On Thu, Oct 26, 2017 at 6:54 AM, Jeff Garzik via Bitcoin-segwit2x > > wrote: > >> > >> Hi all! > >> > >> This is a follow-on from the previous status update in August: > >> https://lists.linuxfoundation.org/pipermail/bitcoin- > segwit2x/2017-August/000265.html > >> > >> 1. To state the obvious, everything is still full steam ahead for > segwit2x > >> upgrade in mid-November. > >> > >> 2. As noted in August, the project continues to be in a code freeze for > >> the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) > >> Only changes or fixes thought to be important pre-fork will be included. > >> > >> 3. Reviewing the btc1 project and branch policies, btc1 is a source code > >> fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution > >> intended for end users. As such, we track Bitcoin Core updates as > necessary > >> and pull those into the project. > >> > >> 4. "segwit2x" is the production release branch for the SegWit2x Working > >> Group, and the latest release can be downloaded here: > >> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 > >> > >> 5. "segwit2x-dev" is the development and testing release branch. New > >> changes go to segwit2x-dev first, for external testing and feedback, > before > >> being merged into the production branch, and labelled a production > release. > >> > >> 6. The current segwit2x production release, on the segwit2x branch, is > >> based on Bitcoin Core 0.14.x. The current dev release is based on > Bitcoin > >> Core 0.15.x. > >> > >> 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. > >> Based on instability and bugs that upstream Bitcoin Core project is > seeing - > >> ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x > through > >> the November fork. This is the most stable path for users, based on > >> upstream Bitcoin Core instability. > >> > >> In short we -do not- feel that Bitcoin Core bugs and instability will > >> impact our project in the short term, because this is not yet in a > segwit2x > >> production release on a production branch. > >> > >> 8. The only change worth noting is a likely be an adjustment of miner > >> policy defaults that will be accepted through the code freeze: > >> https://github.com/btc1/bitcoin/pull/136 > >> > >> Thanks everyone! > >> > >> -- > >> Jeff Garzik > >> CEO and Co Founder > >> Bloq, Inc. > >> > >> > >> _______________________________________________ > >> Bitcoin-segwit2x mailing list > >> Bitcoin-segwit2x at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > >> > > > > > > _______________________________________________ > > Bitcoin-segwit2x mailing list > > Bitcoin-segwit2x at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Thu Oct 26 01:26:34 2017 From: bitpico at icloud.com (bitPico) Date: Wed, 25 Oct 2017 21:26:34 -0400 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: <7BFB447B-9C0E-40A7-BD9C-BE2F080108C6@icloud.com> We would be willing to do 250 BTC (or possibly double that amount). Please have your counsel email us and we will forward to our counsel so they can get the contract started and then we will talk. No further discussion here is needed and we can publicly disclose the contract once it?s completed and signed off on by all parties. Thanks Adam. > On Oct 25, 2017, at 8:59 PM, Dr Adam Back via Bitcoin-segwit2x wrote: > > Indeed it's the reverse, and bad advice - there are things fixed in > 0.15 from 0.14. > > Unless Jeff claims to know an unreported bug... > > btw I probably mentioned on list that I was offering 3 B2X for 2 BTC, > as I got no buyers I have improved the offer to 2 B2X coins for 1 BTC, > sold in 500 B2X for 250 BTC batches. No fork, no B2X coins. > > Adam > > > On Wed, Oct 25, 2017 at 11:52 PM, Daniel Newton via Bitcoin-segwit2x > wrote From bitpico at icloud.com Thu Oct 26 01:33:38 2017 From: bitpico at icloud.com (bitPico) Date: Wed, 25 Oct 2017 21:33:38 -0400 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: Our offer is out there; it?s up to Adam to come up with some coins. We have plenty to toss at this guy and nothing to lose in the process. At very least we double our money and at very worst we have plenty of Bitcoins and the loss is a NOP. You must take risk or you get no reward... > On Oct 25, 2017, at 9:25 PM, Matthew Clancy via Bitcoin-segwit2x wrote: > > Adam, > > I've seen you several times now soliciting people for this gambling get-rich-quick scheme. > > I know it's not the place, but I just want to make sure everything is okay with you. Do you need to earn a lot of money quickly, or are you just trying to make a cheap political point? > > If it's the former, I hope someone here can point you in the direction of more gainful endeavors. There are better are safer ways to earn money, feel free to reach out if you're stuck and can't think of anything productive to do. > > If it's the latter, again, feel free to reach out if you're stuck and can't think of anything productive to do. > > Either way, I'm sure someone here can point you in the right direction. > > ?Best,? > > Matt > > On Wed, Oct 25, 2017 at 8:59 PM, Dr Adam Back via Bitcoin-segwit2x > wrote: > Indeed it's the reverse, and bad advice - there are things fixed in > 0.15 from 0.14. > > Unless Jeff claims to know an unreported bug... > > btw I probably mentioned on list that I was offering 3 B2X for 2 BTC, > as I got no buyers I have improved the offer to 2 B2X coins for 1 BTC, > sold in 500 B2X for 250 BTC batches. No fork, no B2X coins. > > Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.madden at gmail.com Thu Oct 26 02:05:18 2017 From: will.madden at gmail.com (Will M) Date: Wed, 25 Oct 2017 20:05:18 -0600 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: <79df1089-a537-44da-9fd9-e3d4e553ae7b@Spark> Adam, speaking as someone who has had to stay up for days on end figuring out what was wrong with enterprise software when experts went to sleep 3 or 4 times, let me say, that is a preposterously bold statement. On Oct 25, 2017, 7:33 PM -0600, bitPico via Bitcoin-segwit2x , wrote: > Our offer is out there; it?s up to Adam to come up with some coins. We have plenty to toss at this guy and nothing to lose in the process. At very least we double our money and at very worst we have plenty of Bitcoins and the loss is a NOP. You must take risk or you get no reward... > > > On Oct 25, 2017, at 9:25 PM, Matthew Clancy via Bitcoin-segwit2x wrote: > > > > Adam, > > > > I've seen you several times now soliciting people for this gambling get-rich-quick scheme. > > > > I know it's not the place, but I just want to make sure everything is okay with you. Do you need to earn a lot of money quickly, or are you just trying to make a cheap political point? > > > > If it's the former, I hope someone here can point you in the direction of more gainful endeavors. There are better are safer ways to earn money, feel free to reach out if you're stuck and can't think of anything productive to do. > > > > If it's the latter, again, feel free to reach out if you're stuck and can't think of anything productive to do. > > > > Either way, I'm sure someone here can point you in the right direction. > > > > ?Best, > > > > Matt > > > > > On Wed, Oct 25, 2017 at 8:59 PM, Dr Adam Back via Bitcoin-segwit2x wrote: > > > > Indeed it's the reverse, and bad advice - there are things fixed in > > > > 0.15 from 0.14. > > > > > > > > Unless Jeff claims to know an unreported bug... > > > > > > > > btw I probably mentioned on list that I was offering 3 B2X for 2 BTC, > > > > as I got no buyers I have improved the offer to 2 B2X coins for 1 BTC, > > > > sold in 500 B2X for 250 BTC batches.? No fork, no B2X coins. > > > > > > > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benkloester at gmail.com Thu Oct 26 02:16:58 2017 From: benkloester at gmail.com (Ben Kloester) Date: Thu, 26 Oct 2017 13:16:58 +1100 Subject: [Bitcoin-segwit2x] Orderly Process for Coin-Splitting after the fork In-Reply-To: References: <1508919878.3804114.1150261632.0DD7BDDB@webmail.messagingengine.com> Message-ID: I'm not sure if you follow the Github but I believe the opt-in replay protection was removed. Hence this thread. I gather the options are: 1. Get a spend (w RBF) confirmed on one chain to an address you control. Spend the same utxo on the other chain to a different address you control, using RBF possibly with a higher fee. Hope the one that gets confirmed on the second chain is the different address, not the replayed transaction. If not, try again. Pros: Supported by using existing wallets and block explorers (kind of). No need for help from third parties / miners. No specially constructed transactions. Cons: No guarantee it works each time, might take several tries, and fees could get expensive. 2. Miners create transactions spending from coinbase outputs with signature hash type SIGHASH_SINGLE|SIGHASH_ANYONECANPAY and use some out-of-band means to make these 'templates' available. Users can then add their inputs and outputs to the transaction. Pros: Is essentially free, is guaranteed to work first try. Cons: 100 blocks before you can spend coinbase outputs! Also I think the out-of-band distribution and use of templates also requires some coordination between those wanting to use these 'template' transactions to split their coins - in theory one of these templates could be used by many users who all append their inputs and outputs to it, I think, but even if you used 1 template per user wanting to split, you'd ideally make sure that users didn't just grab the first template and add their splitting transaction to it, or you'd flood the mempool with lots of partial duplicate incompatible transactions. 3. Miners create transactions spending from the bounty outputs, with signature hash type SIGHASH_SINGLE|SIGHASH_ANYONECANPAY and use some out-of-band means to make these 'templates' available. Users can then add their inputs and outputs to the transaction. Pros: Is essentially free, is guaranteed to work straight away after the fork Cons: No guarantee that the bounty transaction is still valid at the fork height. Same issues with coordinating the use of the templates. 4. Wait until one chain is a couple of blocks ahead of the other, and use an nLocktime transaction with valid height of the higher block height + 1. Since nLocktime transactions that are not yet valid (ie the lock height is above the next block) are not relayed or accepted into the mempool, this should confirm on the longer chain, and be discarded on the slow chain. You can then spend the same output with a different transaction on the slow chain. Pros: No need for help from third parties, or coordination, posssibly more likely to work first try than RBF. Cons: Have to wait for chains to diverge (likely tens of minutes only, but this could be an issue for exchanges who will have time pressure). Not clear if it is easily supported in existing wallets? Seems like 3 (assuming the bounty transaction stays valid) and 4 are probably the best options, or if you're in a hurry then perhaps 1. *Ben Kloester* On 26 October 2017 at 06:41, Hugh Madden via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > If I understand correctly, using s2x's opt in replay protection is the > only option that will work safe without needing ongoing splitting for every > utxo. > > With ETH/ETH account based blockchain you could just do something to > invalidate the nonce and job done. > > With 1X / 2X I think you need to split every single uxto. > > Easier I think to just use the opt-in replay protection. > > The helps with the sends side of the equation. > > The bigger issue is deposits and extended period chain reorgs due to flip > flopping of hash rate over the two chains. > > I don't have any solution for this except an extended outage. Any thoughts > on how many blocks are required to be safe from extended period chain > reorgs ? > > On 25 Oct. 2017 11:08 am, "Christophe Biocca via Bitcoin-segwit2x" < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> I'll also mention for completeness that the big-block bounty transaction ( >> http://www.blockbounties.info/) has many anyone-can spend outputs which >> are meant to be used to enable anyone else to add funds to the bounty, but >> also effectively can be used for splitting funds. >> >> This is similar to the coinbase-tx approach, but can happen essentially >> immediately post fork (no need to wait 100 blocks). >> >> The downside is that the originator of the transaction could invalidate >> it before the fork happens, so it's not 100% guaranteed to work. >> >> On 25 October 2017 at 04:24, Tomas via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> On Tue, Oct 24, 2017, at 22:41, Moe Adham via Bitcoin-segwit2x wrote: >>> >>> >>> Coinbase: Have miners agree to send a small amount of newly generated >>> coins to wallet operators as quickly as possible after the fork, to allow >>> wallet operators to split wallets >>> >>> >>> I don't think miners actually need to send these coins to wallet >>> operators. >>> >>> A miner or someone else who has acquired some newly minted coins can >>> create transactions with one input and one output that pay to self with >>> SIGHASH_SINGLE | SIGHASH_ANYONECANPAY and provide these replay protected >>> transaction "templates" in large numbers over an API for everyone to use. >>> >>> Tomas >>> bitcrust >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitpico at icloud.com Thu Oct 26 02:36:24 2017 From: bitpico at icloud.com (bitPico) Date: Wed, 25 Oct 2017 22:36:24 -0400 Subject: [Bitcoin-segwit2x] Orderly Process for Coin-Splitting after the fork In-Reply-To: References: <1508919878.3804114.1150261632.0DD7BDDB@webmail.messagingengine.com> Message-ID: We will cross this bridge when we get there. > On Oct 25, 2017, at 10:16 PM, Ben Kloester via Bitcoin-segwit2x wrote: > > I'm not sure if you follow the Github but I believe the opt-in replay protection was removed. Hence this thread. From Hjalmar.Peters at gmx.de Fri Oct 27 00:08:00 2017 From: Hjalmar.Peters at gmx.de (Hjalmar Peters) Date: Thu, 26 Oct 2017 19:08:00 -0500 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> <77DC5C05-EFEA-4756-BAC8 -039CDB97B934@bitcoinr eminder.com> <8F950CE7-B3D4-4720-9B3A-C6C9D789AE18@civic.com> Message-ID: <001501d34eb7$a8270eb0$f8752c10$@gmx.de> Your confidence relies on miners being driven exclusively by economic incentives. However, maybe some Chinese miners have to obey instructions from their government, and maybe this government prefers to see Bitcoin failed. Even if considered unlikely, given the consequences, it might be worth keeping the possibility of large reorgs in mind. (I warned about this scenario before in https://medium.com/@HjalmarPeters/the-big-blockers-bead6027deb2 ) Von: bitcoin-segwit2x-bounces at lists.linuxfoundation.org [mailto:bitcoin-segwit2x-bounces at lists.linuxfoundation.org] Im Auftrag von Alex Morcos via Bitcoin-segwit2x Gesendet: Dienstag, 24. Oktober 2017 19:42 An: Vinny Lingham Cc: Melvin Carvalho via Bitcoin-segwit2x Betreff: Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split If we start seeing 6-block deep reorgs because miners are attempting to pull off a double-spend attack then I think the fundamental economic incentives of Bitcoin will be shown to have failed and we might as well all go home. It's somewhat reasonable to come to differing opinions on what's long term economically rational for miners as to which fork to mine, but it's clearly very detrimental to the future utility of Bitcoin to try double spend attacks. I'm quite confident we will not see that. On Tue, Oct 24, 2017 at 8:11 PM, Vinny Lingham via Bitcoin-segwit2x wrote: I?d love to get a sense of what the hash rate threshold will be for exchanges to stop accepting 1x coin, even with 6 confirmations? With the risk of a selfish mining attack increasing the lower the 1x hashrate is, why would an exchange accept the coins knowing that someone could be double spending across multiple exchanges? https://bitcointalk.org/index.php?topic=2127697.0 I?m just trying to understand this attack vector better... I haven?t heard a good response to this question yet - would really appreciate some insight here. This is largely why I believe hashrate secures the network and why I?ve been against the UASF. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dizzle at pointbiz.com Fri Oct 27 03:37:45 2017 From: dizzle at pointbiz.com (Peter) Date: Thu, 26 Oct 2017 23:37:45 -0400 Subject: [Bitcoin-segwit2x] Orderly Process for Coin-Splitting after the fork In-Reply-To: References: <1508919878.3804114.1150261632.0DD7BDDB@webmail.messagingengine.com> Message-ID: Thank you Ben. Looks like Electrum supports opt-in RBF. Is the need to use opt-in RBF because someone could be auto replaying the whole network? In that case if using Electrum should one have two instances connected to the two different chains and try to broadcast on both chains near simultaneously? Like version 1 to 1x and version 2 to 2x? Are there other GUIs for accomplishing this? There are python command line tools from Peter Todd. Regards Peter On Oct 25, 2017 10:16 PM, "Ben Kloester via Bitcoin-segwit2x" < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: I'm not sure if you follow the Github but I believe the opt-in replay protection was removed. Hence this thread. I gather the options are: 1. Get a spend (w RBF) confirmed on one chain to an address you control. Spend the same utxo on the other chain to a different address you control, using RBF possibly with a higher fee. Hope the one that gets confirmed on the second chain is the different address, not the replayed transaction. If not, try again. Pros: Supported by using existing wallets and block explorers (kind of). No need for help from third parties / miners. No specially constructed transactions. Cons: No guarantee it works each time, might take several tries, and fees could get expensive. 2. Miners create transactions spending from coinbase outputs with signature hash type SIGHASH_SINGLE|SIGHASH_ANYONECANPAY and use some out-of-band means to make these 'templates' available. Users can then add their inputs and outputs to the transaction. Pros: Is essentially free, is guaranteed to work first try. Cons: 100 blocks before you can spend coinbase outputs! Also I think the out-of-band distribution and use of templates also requires some coordination between those wanting to use these 'template' transactions to split their coins - in theory one of these templates could be used by many users who all append their inputs and outputs to it, I think, but even if you used 1 template per user wanting to split, you'd ideally make sure that users didn't just grab the first template and add their splitting transaction to it, or you'd flood the mempool with lots of partial duplicate incompatible transactions. 3. Miners create transactions spending from the bounty outputs, with signature hash type SIGHASH_SINGLE|SIGHASH_ANYONECANPAY and use some out-of-band means to make these 'templates' available. Users can then add their inputs and outputs to the transaction. Pros: Is essentially free, is guaranteed to work straight away after the fork Cons: No guarantee that the bounty transaction is still valid at the fork height. Same issues with coordinating the use of the templates. 4. Wait until one chain is a couple of blocks ahead of the other, and use an nLocktime transaction with valid height of the higher block height + 1. Since nLocktime transactions that are not yet valid (ie the lock height is above the next block) are not relayed or accepted into the mempool, this should confirm on the longer chain, and be discarded on the slow chain. You can then spend the same output with a different transaction on the slow chain. Pros: No need for help from third parties, or coordination, posssibly more likely to work first try than RBF. Cons: Have to wait for chains to diverge (likely tens of minutes only, but this could be an issue for exchanges who will have time pressure). Not clear if it is easily supported in existing wallets? Seems like 3 (assuming the bounty transaction stays valid) and 4 are probably the best options, or if you're in a hurry then perhaps 1. *Ben Kloester* On 26 October 2017 at 06:41, Hugh Madden via Bitcoin-segwit2x < bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > If I understand correctly, using s2x's opt in replay protection is the > only option that will work safe without needing ongoing splitting for every > utxo. > > With ETH/ETH account based blockchain you could just do something to > invalidate the nonce and job done. > > With 1X / 2X I think you need to split every single uxto. > > Easier I think to just use the opt-in replay protection. > > The helps with the sends side of the equation. > > The bigger issue is deposits and extended period chain reorgs due to flip > flopping of hash rate over the two chains. > > I don't have any solution for this except an extended outage. Any thoughts > on how many blocks are required to be safe from extended period chain > reorgs ? > > On 25 Oct. 2017 11:08 am, "Christophe Biocca via Bitcoin-segwit2x" < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> I'll also mention for completeness that the big-block bounty transaction ( >> http://www.blockbounties.info/) has many anyone-can spend outputs which >> are meant to be used to enable anyone else to add funds to the bounty, but >> also effectively can be used for splitting funds. >> >> This is similar to the coinbase-tx approach, but can happen essentially >> immediately post fork (no need to wait 100 blocks). >> >> The downside is that the originator of the transaction could invalidate >> it before the fork happens, so it's not 100% guaranteed to work. >> >> On 25 October 2017 at 04:24, Tomas via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> On Tue, Oct 24, 2017, at 22:41, Moe Adham via Bitcoin-segwit2x wrote: >>> >>> >>> Coinbase: Have miners agree to send a small amount of newly generated >>> coins to wallet operators as quickly as possible after the fork, to allow >>> wallet operators to split wallets >>> >>> >>> I don't think miners actually need to send these coins to wallet >>> operators. >>> >>> A miner or someone else who has acquired some newly minted coins can >>> create transactions with one input and one output that pay to self with >>> SIGHASH_SINGLE | SIGHASH_ANYONECANPAY and provide these replay protected >>> transaction "templates" in large numbers over an API for everyone to use. >>> >>> Tomas >>> bitcrust >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > _______________________________________________ Bitcoin-segwit2x mailing list Bitcoin-segwit2x at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: From benkloester at gmail.com Fri Oct 27 04:15:36 2017 From: benkloester at gmail.com (Ben Kloester) Date: Fri, 27 Oct 2017 15:15:36 +1100 Subject: [Bitcoin-segwit2x] Orderly Process for Coin-Splitting after the fork In-Reply-To: References: <1508919878.3804114.1150261632.0DD7BDDB@webmail.messagingengine.com> Message-ID: The need to use opt-in RBF is in case transaction A, intended for broadcast on the core network, gets replayed* to the s2x network, and accepted into the mempool. This might happen if someone was deliberately replaying transactions, or there might be other more esoteric scenarios. In the case this happens (tx A ends up in the mempool of 2x nodes), I believe policy rules would reject transaction B when you broadcast it since it is considered a double-spend, unless you use RBF. And yes, I think doing it that way with two copies of electrum, one using a 1x node and one using a 2x, would work (though no guarantees it works every time). (*or relayed! We expect these networks to be partitioned as soon as an invalid block gets relayed, ie post fork, but given the heterogeneity of nodes - XT, BU, glod knows what else - out there, who knows what might happen, particularly within the first block or two of divergence) *Ben Kloester* On 27 October 2017 at 14:37, Peter wrote: > Thank you Ben. > > Looks like Electrum supports opt-in RBF. Is the need to use opt-in RBF > because someone could be auto replaying the whole network? > > In that case if using Electrum should one have two instances connected to > the two different chains and try to broadcast on both chains near > simultaneously? Like version 1 to 1x and version 2 to 2x? > > Are there other GUIs for accomplishing this? > > There are python command line tools from Peter Todd. > > Regards > Peter > > > On Oct 25, 2017 10:16 PM, "Ben Kloester via Bitcoin-segwit2x" < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > > I'm not sure if you follow the Github but I believe the opt-in replay > protection was removed. Hence this thread. > > I gather the options are: > > > 1. Get a spend (w RBF) confirmed on one chain to an address you > control. Spend the same utxo on the other chain to a different address you > control, using RBF possibly with a higher fee. Hope the one that gets > confirmed on the second chain is the different address, not the replayed > transaction. If not, try again. > > Pros: Supported by using existing wallets and block explorers (kind > of). No need for help from third parties / miners. No specially constructed > transactions. > > Cons: No guarantee it works each time, might take several tries, and > fees could get expensive. > > 2. Miners create transactions spending from coinbase outputs with > signature hash type SIGHASH_SINGLE|SIGHASH_ANYONECANPAY > and use some > out-of-band means to make these 'templates' available. Users can then add > their inputs and outputs to the transaction. > > Pros: Is essentially free, is guaranteed to work first try. > Cons: 100 blocks before you can spend coinbase outputs! > > Also I think the out-of-band distribution and use of templates also > requires some coordination between those wanting to use these 'template' > transactions to split their coins - in theory one of these templates could > be used by many users who all append their inputs and outputs to it, I > think, but even if you used 1 template per user wanting to split, you'd > ideally make sure that users didn't just grab the first template and add > their splitting transaction to it, or you'd flood the mempool with lots of > partial duplicate incompatible transactions. > > 3. Miners create transactions spending from the bounty outputs, with > signature hash type SIGHASH_SINGLE|SIGHASH_ANYONECANPAY > and use some > out-of-band means to make these 'templates' available. Users can then add > their inputs and outputs to the transaction. > > Pros: Is essentially free, is guaranteed to work straight away after > the fork > Cons: No guarantee that the bounty transaction is still valid at the > fork height. Same issues with coordinating the use of the templates. > > 4. Wait until one chain is a couple of blocks ahead of the other, and > use an nLocktime transaction with valid height of the higher block height + > 1. Since nLocktime transactions that are not yet valid (ie the lock height > is above the next block) are not relayed or accepted into the mempool, this > should confirm on the longer chain, and be discarded on the slow chain. You > can then spend the same output with a different transaction on the slow > chain. > > Pros: No need for help from third parties, or coordination, posssibly > more likely to work first try than RBF. > Cons: Have to wait for chains to diverge (likely tens of minutes only, > but this could be an issue for exchanges who will have time pressure). Not > clear if it is easily supported in existing wallets? > > > Seems like 3 (assuming the bounty transaction stays valid) and 4 are > probably the best options, or if you're in a hurry then perhaps 1. > > *Ben Kloester* > > On 26 October 2017 at 06:41, Hugh Madden via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> If I understand correctly, using s2x's opt in replay protection is the >> only option that will work safe without needing ongoing splitting for every >> utxo. >> >> With ETH/ETH account based blockchain you could just do something to >> invalidate the nonce and job done. >> >> With 1X / 2X I think you need to split every single uxto. >> >> Easier I think to just use the opt-in replay protection. >> >> The helps with the sends side of the equation. >> >> The bigger issue is deposits and extended period chain reorgs due to flip >> flopping of hash rate over the two chains. >> >> I don't have any solution for this except an extended outage. Any >> thoughts on how many blocks are required to be safe from extended period >> chain reorgs ? >> >> On 25 Oct. 2017 11:08 am, "Christophe Biocca via Bitcoin-segwit2x" < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> I'll also mention for completeness that the big-block bounty transaction >>> (http://www.blockbounties.info/) has many anyone-can spend outputs >>> which are meant to be used to enable anyone else to add funds to the >>> bounty, but also effectively can be used for splitting funds. >>> >>> This is similar to the coinbase-tx approach, but can happen essentially >>> immediately post fork (no need to wait 100 blocks). >>> >>> The downside is that the originator of the transaction could invalidate >>> it before the fork happens, so it's not 100% guaranteed to work. >>> >>> On 25 October 2017 at 04:24, Tomas via Bitcoin-segwit2x < >>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >>> >>>> On Tue, Oct 24, 2017, at 22:41, Moe Adham via Bitcoin-segwit2x wrote: >>>> >>>> >>>> Coinbase: Have miners agree to send a small amount of newly generated >>>> coins to wallet operators as quickly as possible after the fork, to allow >>>> wallet operators to split wallets >>>> >>>> >>>> I don't think miners actually need to send these coins to wallet >>>> operators. >>>> >>>> A miner or someone else who has acquired some newly minted coins can >>>> create transactions with one input and one output that pay to self with >>>> SIGHASH_SINGLE | SIGHASH_ANYONECANPAY and provide these replay protected >>>> transaction "templates" in large numbers over an API for everyone to use. >>>> >>>> Tomas >>>> bitcrust >>>> >>>> _______________________________________________ >>>> Bitcoin-segwit2x mailing list >>>> Bitcoin-segwit2x at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>>> >>>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Fri Oct 27 09:49:33 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Fri, 27 Oct 2017 11:49:33 +0200 Subject: [Bitcoin-segwit2x] September/October SegWit2x Status Update In-Reply-To: References: Message-ID: On 25 October 2017 at 22:53, Jacob Eliosoff wrote: > FYI: latest metric is NYA signaling at 75% in the last 24h [1], with the >> position of ViaBTC still unclear >> > > For the record, the drop from 85% to 77% appears to be entirely because in > the last 24 hrs F2Pool shot up from ~7% to ~15%. We'll see if they > maintain that or if it's just a blip, but it's not because, eg, another big > miner/pool stopped signaling 2x. (If one does, many of us will be > interested to hear about it!) > Good point! FYI: GBMiners are now signaling NYA intermittently. Was off for 2 blocks in a row, then back. Hard to know what this means. And ViaBTC are signaling NYA despite saying they'll support both chains. I am unsure that it is at this point logical to assume that NYA signaling, is the strong predictor of future behavior that was originally anticipated. If nothing else, this unfolding story, will perhaps be a lesson we learn. Measurable consensus remains an important goal for both chains. > > > On Wed, Oct 25, 2017 at 2:19 PM, Melvin Carvalho via Bitcoin-segwit2x < > bitcoin-segwit2x at lists.linuxfoundation.org> wrote: > >> >> >> On 25 October 2017 at 19:54, Jeff Garzik via Bitcoin-segwit2x < >> bitcoin-segwit2x at lists.linuxfoundation.org> wrote: >> >>> Hi all! >>> >>> This is a follow-on from the previous status update in August: >>> https://lists.linuxfoundation.org/pipermail/bitcoin- >>> segwit2x/2017-August/000265.html >>> >>> 1. To state the obvious, everything is still full steam ahead for >>> segwit2x upgrade in mid-November. >>> >>> 2. As noted in August, the project continues to be in a code freeze for >>> the fork: https://en.wikipedia.org/wiki/Freeze_(software_engineering) >>> Only changes or fixes thought to be important pre-fork will be included. >>> >>> 3. Reviewing the btc1 project and branch policies, btc1 is a source code >>> fork of Bitcoin Core, very much like Fedora Linux is a fork/distribution >>> intended for end users. As such, we track Bitcoin Core updates as >>> necessary and pull those into the project. >>> >>> 4. "segwit2x" is the production release branch for the SegWit2x Working >>> Group, and the latest release can be downloaded here: >>> https://github.com/btc1/bitcoin/releases/tag/v1.14.5 >>> >>> 5. "segwit2x-dev" is the development and testing release branch. New >>> changes go to segwit2x-dev first, for external testing and feedback, before >>> being merged into the production branch, and labelled a production release. >>> >>> 6. The current segwit2x production release, on the segwit2x branch, is >>> based on Bitcoin Core 0.14.x. The current dev release is based on Bitcoin >>> Core 0.15.x. >>> >>> 7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. >>> Based on instability and bugs that upstream Bitcoin Core project is >>> seeing - ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core >>> 0.14.x through the November fork. This is the most stable path for users, >>> based on upstream Bitcoin Core instability. >>> >>> In short we -do not- feel that Bitcoin Core bugs and instability will >>> impact our project in the short term, because this is not yet in a segwit2x >>> production release on a production branch. >>> >>> 8. The only change worth noting is a likely be an adjustment of miner >>> policy defaults that will be accepted through the code freeze: >>> https://github.com/btc1/bitcoin/pull/136 >>> >>> Thanks everyone! >>> >> >> Thanks for the update. >> >> There was a question on a previous thread that I think went unanswered. >> >> Is the threshold for release still 80% miner signaling? >> >> If miner signaling for NYA falls significantly, would it be considered >> new information? >> >> FYI: latest metric is NYA signaling at 75% in the last 24h [1], with the >> position of ViaBTC still unclear >> >> [1] https://coin.dance/blocks >> >>> >>> >>> -- >>> Jeff Garzik >>> CEO and Co Founder >>> Bloq, Inc. >>> >>> >>> _______________________________________________ >>> Bitcoin-segwit2x mailing list >>> Bitcoin-segwit2x at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >>> >>> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emil at bitcoin.com Tue Oct 24 16:37:51 2017 From: emil at bitcoin.com (Emil Oldenburg) Date: Wed, 25 Oct 2017 01:37:51 +0900 Subject: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay, guarantee) - Ensuring a smooth 2X upgrade without a chain split In-Reply-To: References: <59EF4DBE.3040006@bitmex.com> <59EF5370.9090205@bitmex.com> <59EF5CDF.3020006@bitmex.com> Message-ID: Another very important thing to keep in mind is that as soon as the fork happens, the futures are not futures anymore. As soon as the fork happens traders will have more markets to trade on and we will see a quick price correction. Emil Oldenburg, CTO Emil at bitcoin.com Visit the all new https://bitcoin.com Wechat: emilold Telegram: emilold On 2017?10?25? 01:27, Erik Voorhees via Bitcoin-segwit2x wrote: > I have a question for the group... > > > "Given the market is showing that the 2x coin will be valued under 20% > of bitcoin, miners acting in self interest will mine bitcoin and the > 2x chain will freeze up, requiring subsidy to mine.? - Mo Adham > > -Let?s assume, immediately following the fork, 1x has 20% of?hash > power, and 2x has 80% ?(as indicated by miner?signaling) > -Let?s assume also that the price, immediately following the fork, 1x > is $4,000 and 2x is $1,000 ?(as indicated by futures) > > Most people see the above and think,??okay, soon after the fork the > miners will switch back to 1x because price is higher.?? > > But, is it not the case that while price might be higher, block times > are lower. So if you consider it from a $ revenue per day: > - 1x finds 28.8 blocks per day (0.2x144) and earns 360 BTC1x, or > $1.44m per day ($4,000 x 360)? > - 2x finds 115.2 blocks per day (0.8x144) and earns ?1440 BTC2x, or > $1.44m per day ($1,000 x 1,440) > > In the above case, the revenue stream of both coins is equal, at > $1.44m per day.? So even though one coin is priced higher, it doesn?t > mean miners will necessarily choose that chain to mine. > > Am I missing something? > > > Kind regards, > -Erik Voorhees > CEO ShapeShift AG > > On October 24, 2017 at 9:58:05 AM, Melvin Carvalho via > Bitcoin-segwit2x (bitcoin-segwit2x at lists.linuxfoundation.org > ) wrote: > >> >> >> On 24 October 2017 at 17:47, Moe Adham via Bitcoin-segwit2x >> > > wrote: >> >> Miners need to move their funds into exchanges to sell them. If >> they can't deposit coins to an exchange, they become valueless. >> >> Assuming an 80-20 split, Block times for the minority chain spike >> to ~49.3 minutes and will remain that long for ~69 days. This >> would effectively block the minority chain's functionality as a >> payment system, as it will become increasingly impossible to >> deposit funds, or move them between exchanges (assuming >> transaction demand remains linear). Miners can prioritize their >> own transactions in blocks, but regular customers will be left >> out to dry. >> >> I don't anyone should under-estimate the negative effects of this >> on market participants. >> >> A lot of us have customers who expect bitcoin to just "work". If >> we start telling them they can't spend their money for several >> days/weeks, the choice of which chain is viable will quickly >> become clear. It will be neither Bitcoin1x or Bitcoin2x. It will >> be a different blockchain altogether. >> >> (To be clear, Bitaccess is neutral on this fork, we just want >> customers to remain happy. They way this is going, that doesn't >> seem to be a likely outcome) >> >> >> What typically happens is (shock horror) miners will mine in self >> interest.? If you consider mining as a commodity, it makes sense that >> they'll just go for the most profitable coin, and not act >> altruistically, which was suggested in the original white paper. >> >> Mining is therefore common is a 0% / 100% until fees for a block make >> it profitable to mine that block (cab take several days) or the >> difficulty adjusts the profitability. >> >> This phenomenon is often referred to as "feast and famine". >> >> Given the market is showing that the 2x coin will be valued under 20% >> of bitcoin, miners acting in self interest will mine bitcoin and the >> 2x chain will freeze up, requiring subsidy to mine.? Such subsidies >> could be added by creating a few transactions with high mining fees. >> ? >> >> >> -- >> *Moe Adham, MSc, BEng?**|*?Co-Founder >> * >> * >> *bitaccess.co * >> Cell: _+1 858 877 3420 _?? >> >> On Tue, Oct 24, 2017 at 11:36 AM, Phillip Katete via >> Bitcoin-segwit2x > > wrote: >> >> It is at this point that common sense needs to be applied. >> Even the most ardent anti SegWit2x upgrade individual would >> snap up the ?airdrop? should there be 2 viable chains post >> Nov HF. That in itself is demand enough to have a market for >> both tokens. The flip side is that with an unusable chain, it >> matters not whether exchanges respond to user requests for >> listing as you won?t be able to move your tokens anyway. >> >> ? >> >> *From:* Samuel Reed via Bitcoin-segwit2x >> >> *Sent:* 24 October 2017 16:31 >> *To:* Peter >> *Cc:* Bitcoin Segwit2x >> >> *Subject:* Re: [Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin >> zero replay, guarantee) - Ensuring a smooth 2X upgrade >> without a chain split >> >> ? >> >> Another lesson to be learned from BCH is that incentives >> matter - where miners can sell coins depends on markets, and >> market prices depend on user and exchange support. Even if >> the 80% of miners signaling 2x at this time choose to go >> forward, if there are not viable markets willing to buy 2x >> coins at near 1x prices, 2x hash power will quickly revert to >> the old chain. >> >> Peter wrote: >> >> ? >> >> ? >> >> On Oct 24, 2017 10:58 AM, "Chris Stewart via >> Bitcoin-segwit2x" >> > > wrote: >> >> >RP that encourages a network split would render the NYA voidable >> >> Phillip, if there is consensus on one thing, it is >> there is going to be a network split. Every exchange >> is publishing policies for the chain split. Some even >> saying that they will not support the segwit2x token. >> >> -Chris >> >> ? >> >> The technical lesson from the BCH fork was that 1 hash = >> 1 vote. Nothing any exchange (or custodian) said >> mattered. Indeed because significant sha256 hashpower was >> deployed towards the fork it gained value and customers >> of exchanges pressured the exchanges into the financially >> sensible decision.? >> >> ? >> >> This proposal, SegWit2x, is for the miners to decide.? >> >> ? >> >> Transaction selection is not a consensus rule. Any miners >> that want to go against the Nakamoto signaling is free to >> do so and the responsible party (not the 2x devs who have >> no control over transaction selection). If because of the >> political climate some miner sees an economic opportunity >> to resurrect the legacy chain then they can modify their >> node (without consensus change) to listen to 2x blocks >> and not mine any transaction IDs found in the 2x chain.? >> >> ? >> >> Additionally, to complete a safe chain resurrection such >> a miner can airdrop the mining reward from the forked >> block (after 100 depth) and send it to to all addresses >> with UTXOs over $x value. So that users of the 1x chain >> can spend the combined UTXOs which cannot be replayed on >> 2x, as a simple splitting solution.? >> >> ? >> >> Safety efforts which do not require consensus changes >> should be exhausted first before suggesting consensus >> changes.? >> >> ? >> >> Regards? >> >> Peter >> >> ? >> >> ? >> >> ? >> >> ? >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x >> >> >> >> _______________________________________________ >> Bitcoin-segwit2x mailing list >> Bitcoin-segwit2x at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x > > > _______________________________________________ > Bitcoin-segwit2x mailing list > Bitcoin-segwit2x at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x -------------- next part -------------- An HTML attachment was scrubbed... URL: