* [bitcoin-dev] A Segwit2x BIP
@ 2017-07-07 22:25 Sergio Demian Lerner
2017-07-07 22:44 ` Matt Corallo
` (4 more replies)
0 siblings, 5 replies; 21+ messages in thread
From: Sergio Demian Lerner @ 2017-07-07 22:25 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
Hello,
Here is a BIP that matches the reference code that the Segwit2x group has
built and published a week ago.
This BIP and code satisfies the requests of a large part of the Bitcoin
community for a moderate increase in the Bitcoin non-witness block space
coupled with the activation of Segwit.
You can find the BIP draft in the following link:
https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-draft-sergiolerner-segwit2x.mediawiki
Reference source was kindly provided by the Segwit2x group.
Best regards,
Sergio.
[-- Attachment #2: Type: text/html, Size: 827 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-07 22:25 [bitcoin-dev] A Segwit2x BIP Sergio Demian Lerner @ 2017-07-07 22:44 ` Matt Corallo 2017-07-07 23:25 ` Gregory Maxwell 2017-07-07 23:22 ` Gregory Maxwell ` (3 subsequent siblings) 4 siblings, 1 reply; 21+ messages in thread From: Matt Corallo @ 2017-07-07 22:44 UTC (permalink / raw) To: Sergio Demian Lerner, bitcoin-dev This is horribly under-specified (ie not possible to implement from what you've written, and your implementation doesn't match at all, last I heard). > Specification > The plain block size is defined as the serialized block size without > witness programs. > Deploy a modified BIP91 to activate Segwit. The only modification is > that the signal "segsignal" is replaced by "segwit2x". This is not a protocol change. I have no idea why you included it in the "specification" section. > If segwit2x (BIP91 signal) activates at block N, then block N+12960 > activates a new plain block size limit of 2 MB (2,000,000 bytes). In > this case, at block N+12960 a hard-fork occurs. This is not a hard fork, simply adding a new limit is a soft fork. You appear to be confused - as originally written, AFAIR, Jeff's btc1 branch did not increase the block size, your specification here matches that original change, and does not increase the block size. > The block that activates the hard-fork must have a plain block size > greater than 1 MB. There is no hard fork, and this would violate consensus rules. Not sure what you mean. If you do add a hard fork to this BIP, you really need to flip the hard fork bit. > Any transaction with a non-witness serialized size exceeding 1,000,000 > is invalid. This is far from sufficient to protect from DoS attacks, you really should take a look through the mailing list archives and read some of the old discussions on the issues here. Matt On 07/07/17 18:25, Sergio Demian Lerner via bitcoin-dev wrote: > Hello, > > Here is a BIP that matches the reference code that the Segwit2x group > has built and published a week ago. > > This BIP and code satisfies the requests of a large part of the Bitcoin > community for a moderate increase in the Bitcoin non-witness block space > coupled with the activation of Segwit. > > You can find the BIP draft in the following link: > > https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-draft-sergiolerner-segwit2x.mediawiki > > Reference source was kindly provided by the Segwit2x group. > > Best regards, > Sergio. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-07 22:44 ` Matt Corallo @ 2017-07-07 23:25 ` Gregory Maxwell 0 siblings, 0 replies; 21+ messages in thread From: Gregory Maxwell @ 2017-07-07 23:25 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-dev On Fri, Jul 7, 2017 at 10:44 PM, Matt Corallo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > This is not a hard fork, simply adding a new limit is a soft fork. You > appear to be confused - as originally written, AFAIR, Jeff's btc1 branch > did not increase the block size, your specification here matches that > original change, and does not increase the block size. Indeed, their code previously did not increase the blocksize but it was adjusted at the last minute to do so-- so it may actually do that now. Because they don't appear to have implemented any tests for it, I wouldn't be too surprised if it still didn't work at all but also wouldn't be surprised if it did. You are correct that the specification text appears to refer to the prior change that did not. (In my response I just assumed that it meant what they actually did-- good catch). ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-07 22:25 [bitcoin-dev] A Segwit2x BIP Sergio Demian Lerner 2017-07-07 22:44 ` Matt Corallo @ 2017-07-07 23:22 ` Gregory Maxwell 2017-07-13 3:10 ` Sergio Demian Lerner 2017-07-07 23:27 ` Luke Dashjr ` (2 subsequent siblings) 4 siblings, 1 reply; 21+ messages in thread From: Gregory Maxwell @ 2017-07-07 23:22 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: bitcoin-dev On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Hello, > > Here is a BIP that matches the reference code that the Segwit2x group has > built and published a week ago. I'm happy to see that someone has begun writing a specification. But I am appalled to see one just being written now for change it's authors expect to be irreversibly applied to the network in less than 30 days. The timeline of this proposal is recklessly short to such an extreme level that we have never, to the best of my knowledge, seen a prior proposal so hasty. Nowhere does this specification provide justification or assurance that this is at all safe. The time line of it violates the most minimal of responsible engineering practices, by being shorter than even a fast development and release candidate timeframe. This proposal carries an extreme risk for parties to lose money due to transaction reversals at two distinct points in time and provides no proposed countermeasures to avoid these losses. The proposal adds another gratuitous limit to the system: A maximum transaction size where none existed before, yet this limit is almost certainly too small to prevent actual DOS attacks while it is also technically larger than any transaction that can be included today (the largest possible transaction today is 1mb minus the block overheads). The maximum resource usage for maliciously crafted 1MB transaction is enormous and permitting two of them greatly exacerbates the existing vulnerability. > Assuming the current transaction pattern is replicated in a 2 MB plain-sized block that is 100% filled with transactions, then the witness-serialized block would occupy 3.6 MB But in a worst case the result would be 8MB, which this document fails to mention. > This is considered safe by many users, companies, miners and academics [2]. The claim that the document's [2] says that these increases are "safe" is incorrect and is a matter which has been previously corrected by the authors of the document: https://www.reddit.com/r/btc/comments/626ud7/coauthor_of_the_paper_that_blockstream_core_keep/dflrshg/ . The cited paper does an approximate best case analysis considering only a couple of risk factors (in particular, block relay time, but ignoring durability to dos attacks, robustness against state intervention, and initial synchronization time) and concluded that 4MB was the largest they could argue was safe. The paper goes on to then argue that even if you crank Bitcoin's parameters to the maximum in those dimensions that it doesn't result in a truly meaningful increase in scalablity-- in effect, it's a weak argument against your proposal and ones like it. > Deploy a modified BIP91 to activate Segwit. The only modification is that the signal "segsignal" is replaced by "segwit2x". This means that BIP-91 and your proposal are indistinguishable on the network, because the string "segsignal" is merely a variable name used in the software. > If segwit2x (BIP91 signal) activates at block N, The proposal is unable to distinguish itself from BIP-91. Does this mean if segwit2x or BIP91 activates ? > This reduces the fee pressure on users and companies creating on-chain transactions, matching market expectations and preventing further market disruption Considering that we just spent the whole weekend with the mempool having ~1 block or less worth of transactions most of the time, it seems highly likely that just activating segwit will substantially disrupt the fee market; to say nothing for the further doubling that isn't even tempered by new wallet adoptions. There seems to be no consideration given to avoiding this disruption and preventing further emergency events when the new capacity is eventually used and software is again left unprepared for having to pay market fees. > and buy time for more comprehensive solutions to be developed and tested In effect, the document admits that it isn't a solution that meaningfully improves the scale or scalablity but rather it's just a bailout to temporarily lower/negate transaction fees. It doesn't seem to make any argument (or even acknowledge) that the risks and disruption are worth its benefit, and it exacerbates those risks by being the product of a closed process and having a timeline shorter than basically any software update for production software (much less the timeframe for any consensus update previously). Kudos for being frank here, but it's not exactly selling itself. It seems to me that the document doesn't really even make an effort to justify the bailout at all and don't explain how it will result in anything except an endless series of additional fee bailouts. Moreover, it doesn't discuss any remediation against the replay exposure that the proposed hardfork is sure to create. ( I can guarantee to you, I will not adopt this hardfork; especially given that is has been made completely clear that the terms of it were set in its closed door meetings and the input of non-supporters was not welcome. ) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-07 23:22 ` Gregory Maxwell @ 2017-07-13 3:10 ` Sergio Demian Lerner 2017-07-13 3:19 ` Sergio Demian Lerner 0 siblings, 1 reply; 21+ messages in thread From: Sergio Demian Lerner @ 2017-07-13 3:10 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2972 bytes --] Some responses.. > > The proposal adds another gratuitous limit to the system: A maximum > transaction size where none existed before, yet this limit is almost > certainly too small to prevent actual DOS attacks while it is also > technically larger than any transaction that can be included today > (the largest possible transaction today is 1mb minus the block > overheads). The maximum resource usage for maliciously crafted 1MB > transaction is enormous and permitting two of them greatly exacerbates > the existing vulnerability. > > I think that limiting the maximum transaction size may not be the best possible solution to the N^2 hashing problem, yet it is not a bad start. There are several viable soft-forking solutions to it: 1- Soft-fork to perform periodic reductions in the maximum non-segwit checksigs per input (down to 20) 2- Soft-fork to perform periodic reductions in the number of non-segwit checksigs per transaction. (down to 5K) 3- Soft-fork to perform periodic reductions in the amount of data hashed by non-segwit checksigs. Regardless which one one picks, the soft-fork can be deployed with enough time in advance to reduce the exposure. The risk is still low. Four years have passed since I reported this vulnerability and yet nobody has exploited it. The attack is highly anti-economical, yet every discussion about the block size ends up citing this vulnerability. , > > Assuming the current transaction pattern is replicated in a 2 MB > plain-sized block that is 100% filled with transactions, then the > witness-serialized block would occupy 3.6 MB > > But in a worst case the result would be 8MB, which this document fails > to mention. > I will mention this worst case in the BIP. Even if artificially filling the witness space up to 8 MB is anti-economical, Segwit exacerbates this problem because each witness byte costs 1/4th of a non-witness byte, so the block bloat attack gets cheaper than before. I think the guilt lies more in Segwit discount factor than in the plain block size increase. I would remove the discount factor altogether, and add a fixed (40 bytes) discount for each input with respect to outputs (not for certain input types), to incentivize the cleaning of the UTXO set. A discount for inputs cannot be used to bloat an unlimited number of blocks, because for each input the attacker needs to first create an output (without discount). There is no need to incentivize removing the signatures from blocks, because there is already an incentive to do so to save disk space. > > > Deploy a modified BIP91 to activate Segwit. The only modification is > that the signal "segsignal" is replaced by "segwit2x". > > This means that BIP-91 and your proposal are indistinguishable on the > network, because the string "segsignal" is merely a variable name used > in the software. > > No, it is exposed to the rpc mining interface (getblocktemplate). It must be redefined, even if it's not a consensus change. > [-- Attachment #2: Type: text/html, Size: 4011 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-13 3:10 ` Sergio Demian Lerner @ 2017-07-13 3:19 ` Sergio Demian Lerner 0 siblings, 0 replies; 21+ messages in thread From: Sergio Demian Lerner @ 2017-07-13 3:19 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3257 bytes --] Well, 40 bytes reduction per input is excessive too :) But 30 bytes reduction will do fine. On Thu, Jul 13, 2017 at 12:10 AM, Sergio Demian Lerner < sergio.d.lerner@gmail•com> wrote: > Some responses.. > >> >> The proposal adds another gratuitous limit to the system: A maximum >> transaction size where none existed before, yet this limit is almost >> certainly too small to prevent actual DOS attacks while it is also >> technically larger than any transaction that can be included today >> (the largest possible transaction today is 1mb minus the block >> overheads). The maximum resource usage for maliciously crafted 1MB >> transaction is enormous and permitting two of them greatly exacerbates >> the existing vulnerability. >> >> > I think that limiting the maximum transaction size may not be the best > possible solution to the N^2 hashing problem, yet it is not a bad start. > > There are several viable soft-forking solutions to it: > > 1- Soft-fork to perform periodic reductions in the maximum non-segwit > checksigs per input (down to 20) > 2- Soft-fork to perform periodic reductions in the number of non-segwit > checksigs per transaction. (down to 5K) > 3- Soft-fork to perform periodic reductions in the amount of data hashed > by non-segwit checksigs. > > Regardless which one one picks, the soft-fork can be deployed with enough > time in advance to reduce the exposure. The risk is still low. Four years > have passed since I reported this vulnerability and yet nobody has > exploited it. The attack is highly anti-economical, yet every discussion > about the block size ends up citing this vulnerability. > > , > >> > Assuming the current transaction pattern is replicated in a 2 MB >> plain-sized block that is 100% filled with transactions, then the >> witness-serialized block would occupy 3.6 MB >> >> But in a worst case the result would be 8MB, which this document fails >> to mention. >> > > I will mention this worst case in the BIP. > > Even if artificially filling the witness space up to 8 MB is > anti-economical, Segwit exacerbates this problem because each witness byte > costs 1/4th of a non-witness byte, so the block bloat attack gets cheaper > than before. I think the guilt lies more in Segwit discount factor than in > the plain block size increase. > I would remove the discount factor altogether, and add a fixed (40 bytes) > discount for each input with respect to outputs (not for certain input > types), to incentivize the cleaning of the UTXO set. A discount for inputs > cannot be used to bloat an unlimited number of blocks, because for each > input the attacker needs to first create an output (without discount). > There is no need to incentivize removing the signatures from blocks, > because there is already an incentive to do so to save disk space. > > >> >> > Deploy a modified BIP91 to activate Segwit. The only modification is >> that the signal "segsignal" is replaced by "segwit2x". >> >> This means that BIP-91 and your proposal are indistinguishable on the >> network, because the string "segsignal" is merely a variable name used >> in the software. >> >> No, it is exposed to the rpc mining interface (getblocktemplate). It must > be redefined, even if it's not a consensus change. > > >> [-- Attachment #2: Type: text/html, Size: 4617 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-07 22:25 [bitcoin-dev] A Segwit2x BIP Sergio Demian Lerner 2017-07-07 22:44 ` Matt Corallo 2017-07-07 23:22 ` Gregory Maxwell @ 2017-07-07 23:27 ` Luke Dashjr 2017-07-07 23:38 ` Gregory Maxwell 2017-07-08 6:30 ` Erik Aronesty 2017-07-08 13:28 ` Btc Drak 4 siblings, 1 reply; 21+ messages in thread From: Luke Dashjr @ 2017-07-07 23:27 UTC (permalink / raw) To: bitcoin-dev, Sergio Demian Lerner > Maximum transaction size is kept, to maximize compatibility with current > software and prevent algorithmic and data size DoS's. IIRC, it is actually increased by ~81 bytes, and doesn't count witness data if on Segwit transactions (so in effect, nearly 4 MB transactions are possible). This probably doesn't make the hashing problem worse, however it should be made clear in the BIP. > Assuming the current transaction pattern is replicated in a 2 MB > plain-sized block that is 100% filled with transactions, then the > witness-serialized block would occupy 3.6 MB [1]. This is considered safe > by many users, companies, miners and academics [2]. Citations do not support the claim. > The plain block size is defined as the serialized block size without > witness programs. This is deceptive and meaningless. There is no reason to *ever* refer to the size of the block serialised without witness programs. It is not a meaningful number. > Deploy a modified BIP91 to activate Segwit. The only modification is that > the signal "segsignal" is replaced by "segwit2x". What is modified here? "segsignal" does not appear in the BIP 91 protocol at all... > If segwit2x (BIP91 signal) activates at block N, then block N+12960 > activates a new plain block size limit of 2 MB (2,000,000 bytes). In this > case, at block N+12960 a hard-fork occurs. A "plain block size limit" of 2 MB would be a no-op. It would have literally no effect whatsoever on the network rules. Furthermore, this does not match what btc1/Segwit2x currently implements at all. The actual implementation is: If Segwit (via deployment method) activates at block N, then block N+12960 activates a new weight limit of 8M (which corresponds to a size of up to 8,000,000 bytes). > Any transaction with a non-witness serialized size exceeding 1,000,000 is > invalid. What is the rationale for excluding witness data from this measurement? > In the short term, an increase is needed to continue to facilitate network > growth, and buy time... Actual network growth does not reflect a pattern that supports this claim. > This reduces the fee pressure on users and companies creating on-chain > transactions, matching market expectations and preventing further market > disruption. Larger block sizes is not likely to have a meaningful impact on fee pressure. Any expectations that do not match the reality are merely misguided, and should not be a basis for changing Bitcoin. Luke ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-07 23:27 ` Luke Dashjr @ 2017-07-07 23:38 ` Gregory Maxwell 0 siblings, 0 replies; 21+ messages in thread From: Gregory Maxwell @ 2017-07-07 23:38 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev On Fri, Jul 7, 2017 at 11:27 PM, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Larger block sizes is not likely to have a meaningful impact on fee pressure. > Any expectations that do not match the reality are merely misguided, and > should not be a basis for changing Bitcoin. I think it's very clear that they will in the very short term (https://anduck.net/bitcoin/fees/4320_blocks.php note the rate drops when demand falls below supply). But I agree with you if you mean a somewhat longer term e.g. a year out. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-07 22:25 [bitcoin-dev] A Segwit2x BIP Sergio Demian Lerner ` (2 preceding siblings ...) 2017-07-07 23:27 ` Luke Dashjr @ 2017-07-08 6:30 ` Erik Aronesty 2017-07-08 13:28 ` Btc Drak 4 siblings, 0 replies; 21+ messages in thread From: Erik Aronesty @ 2017-07-08 6:30 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1756 bytes --] - The BIP91 portion of the fork seems OK to me. There are some issues with timing, but since this is for miner coordination of segwit activation, and has little to do with other network users, it could be included as an option. (I'm a fan of adding options;plugins, etc. to Bitcoin... some others aren't.) - This hard fork portion of the proposal is being deployed with "emergency" speed... even though there is not an emergency on the network today that I am aware of. If enacted, it will certainly result in two chains - and with no replay protection.. The results of this will be confusing - two ledgers with many transactions appearing on both and others appearing only on one. - The BIP should be modified to provide evidence and justification for the timeline that is consistent with the level of risk the network would bear if it were enacted. - The coercion used to drive production of this BIP is mired in a misinterpretation of BIP9 and sets a precedent for Bitcoin that may undermine the value prospect of all cryptocurrency in general. For this reason alone - even if all of the engineering concerns and timelines are improved - even assigning this BIP a number could be considered irresponsible. - If you still want to code up a fork for the Bitcoin network, consider starting with Luke's hard fork code and changing the rates of growth as needed for your desired effect. Also you might want to read this first (code references are in there): https://petertodd.org/2016/hardforks-after-the-segwit-blocksize-increase . Plans are already underway for a hard fork, for reasons that have nothing to do with block size, but could include a timeline for a block size growth consistent with global average residential bandwidth growth. [-- Attachment #2: Type: text/html, Size: 2011 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-07 22:25 [bitcoin-dev] A Segwit2x BIP Sergio Demian Lerner ` (3 preceding siblings ...) 2017-07-08 6:30 ` Erik Aronesty @ 2017-07-08 13:28 ` Btc Drak [not found] ` <A7FFF8F7-9806-44F1-B68F-F83C44893365@ob1.io> 4 siblings, 1 reply; 21+ messages in thread From: Btc Drak @ 2017-07-08 13:28 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3054 bytes --] I am utterly appalled by this proposal both technically, ethically, and by the process which it has adopted. Hard forks require consensus from the entire ecosystem in order to prevent a fork, funds loss, confusion and harm to the robust guarantees of the Bitcoin system has thus far displayed. I know this is a draft, but you are seeking reviews of a proposal that has just a few weeks remaining before deployment (where "technical review" is pointless because the is not actually open <https://pastebin.com/kktB1kaw> unless you are an approved member <https://github.com/btc1/bitcoin/commit/1719c872b6624c37b0f2d94e7a4a2656fac4804a#diff-6a3371457528722a734f3c51d9238c13>), making it totally unworkable and irresponsible. For example, exactly how are other implementations supposed to adopt the BIP in such a short timeframe? For all the talk of how important "alternative implementations" are, how does this rash and rushed action promote an ecosystem of multiple implementors? By encouraging fast upgrades, you are actually centralizing the ecosystem even further. The linked coded doesn't uniquely identify itself on the network by user-agent, something all distinct implementations have done to date. The draft BIP text looks like an afterthought and doesn't actually specify the proposal in enough detail to implement from the text. By contrast for example, BIP141 has a level of detail which allowed others to implement segwit without looking at any reference code (which consequently results to more confidence and testing of the specification all round). The Bitcoin system has a market cap of over $40bn supported by a robust and reliable network and your proposal is an offence to all Bitcoin has achieved because due to it's the strong foundations. I cannot not support this proposal in the current form and timeline, nor do I support the coercion that has been used behind closed doors to try and gain more support (not limited to, but including approaching company investors to twist arms and veiled threats of blacklisting companies from further funding/collaboration). I think the best you can hope for this hard fork proposal is for it to be quietly ignored. On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Hello, > > Here is a BIP that matches the reference code that the Segwit2x group has > built and published a week ago. > > This BIP and code satisfies the requests of a large part of the Bitcoin > community for a moderate increase in the Bitcoin non-witness block space > coupled with the activation of Segwit. > > You can find the BIP draft in the following link: > > https://github.com/SergioDemianLerner/BIPs/blob/ > master/BIP-draft-sergiolerner-segwit2x.mediawiki > > Reference source was kindly provided by the Segwit2x group. > > Best regards, > Sergio. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 4105 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <A7FFF8F7-9806-44F1-B68F-F83C44893365@ob1.io>]
* Re: [bitcoin-dev] A Segwit2x BIP [not found] ` <A7FFF8F7-9806-44F1-B68F-F83C44893365@ob1.io> @ 2017-07-10 11:50 ` Sergio Demian Lerner 2017-07-10 18:38 ` Jorge Timón 2017-07-12 1:06 ` Luke Dashjr 0 siblings, 2 replies; 21+ messages in thread From: Sergio Demian Lerner @ 2017-07-10 11:50 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4519 bytes --] Thank you for all your comments. I will improve the BIP based on the technical suggestions received. On the subjective/political side that has slipped into this discussion. Skip this part if not interested in politics. Regarding the timeline, its certainly rather short, but also is the UASF BIP 148 ultimatum. If Bitcoin were a democracy and we had somehow a way to securely perform a referendum, then this will solve easily. But neither is true. At least now. More than 80% of the miners and many users are willing to go in the Segwit2x direction. With the support and great talent of the Bitcoin Core developers, Segwit2x activation will not cause any major disruptions. Without Core, there will be a temporary split. Both sides will have to hard-fork. I want a Bitcoin united. But maybe a split of Bitcoin, each side with its own vision, is not so bad. On Sat, Jul 8, 2017 at 6:19 PM, Brian Hoffman <brian@ob1•io> wrote: > I don't feel threatened by investors. You're full of shit btcdrak. > > Proofread your emails. You just declared support for segwit2x. > > On Jul 8, 2017, at 9:28 AM, Btc Drak via bitcoin-dev <bitcoin-dev@lists. > linuxfoundation.org> wrote: > > I am utterly appalled by this proposal both technically, ethically, and by > the process which it has adopted. Hard forks require consensus from the > entire ecosystem in order to prevent a fork, funds loss, confusion and harm > to the robust guarantees of the Bitcoin system has thus far displayed. > > I know this is a draft, but you are seeking reviews of a proposal that has > just a few weeks remaining before deployment (where "technical review" is > pointless because the is not actually open <https://pastebin.com/kktB1kaw> unless > you are an approved member > <https://github.com/btc1/bitcoin/commit/1719c872b6624c37b0f2d94e7a4a2656fac4804a#diff-6a3371457528722a734f3c51d9238c13>), > making it totally unworkable and irresponsible. For example, exactly how > are other implementations supposed to adopt the BIP in such a short > timeframe? For all the talk of how important "alternative implementations" > are, how does this rash and rushed action promote an ecosystem of multiple > implementors? By encouraging fast upgrades, you are actually centralizing > the ecosystem even further. > > The linked coded doesn't uniquely identify itself on the network by > user-agent, something all distinct implementations have done to date. > > The draft BIP text looks like an afterthought and doesn't actually specify > the proposal in enough detail to implement from the text. By contrast for > example, BIP141 has a level of detail which allowed others to implement > segwit without looking at any reference code (which consequently results to > more confidence and testing of the specification all round). The Bitcoin > system has a market cap of over $40bn supported by a robust and reliable > network and your proposal is an offence to all Bitcoin has achieved because > due to it's the strong foundations. > > I cannot not support this proposal in the current form and timeline, nor > do I support the coercion that has been used behind closed doors to try and > gain more support (not limited to, but including approaching company > investors to twist arms and veiled threats of blacklisting companies from > further funding/collaboration). > > I think the best you can hope for this hard fork proposal is for it to be > quietly ignored. > > > > On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Hello, >> >> Here is a BIP that matches the reference code that the Segwit2x group has >> built and published a week ago. >> >> This BIP and code satisfies the requests of a large part of the Bitcoin >> community for a moderate increase in the Bitcoin non-witness block space >> coupled with the activation of Segwit. >> >> You can find the BIP draft in the following link: >> >> https://github.com/SergioDemianLerner/BIPs/blob/master/BIP- >> draft-sergiolerner-segwit2x.mediawiki >> >> Reference source was kindly provided by the Segwit2x group. >> >> Best regards, >> Sergio. >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 6414 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-10 11:50 ` Sergio Demian Lerner @ 2017-07-10 18:38 ` Jorge Timón 2017-07-12 8:15 ` Tom Zander 2017-07-12 1:06 ` Luke Dashjr 1 sibling, 1 reply; 21+ messages in thread From: Jorge Timón @ 2017-07-10 18:38 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: bitcoin-dev On Mon, Jul 10, 2017 at 1:50 PM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Regarding the timeline, its certainly rather short, but also is the UASF BIP > 148 ultimatum. This is correct. If you are trying to imply that makes the short timeline here right, you are falling for a "tu quoque" fallacy. > More than 80% of the miners and many users are willing to go in the Segwit2x > direction. There's no logical reason I can think of (and I've heard many attempts at explaining it) for miners to consider segwit bad for Bitcoin but segwitx2 harmless. But I don't see 80% hashrate support for bip141, so your claim doesn't seem accurate for the segwit part, let alone the more controversial hardfork part. I read some people controlling mining pools that control 80% of the hashrate signed a paper saying they would "support segwit immediately". Either what I read wasn't true, or the signed paper is just a proof of the signing pool operators word being something we cannot trust. So where does this 80% figure come from? How can we trust the source? > I want a Bitcoin united. But maybe a split of Bitcoin, each side with its > own vision, is not so bad. It would be unfortunate to split the network into 2 coins only because of lack of patience for deploying non-urgent consensus changes like a size increase or disagreements about the right time schedule. I think anything less than 1 year after release of tested code by some implementation would be irresponsible for any hardfork, even a very simple one. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-10 18:38 ` Jorge Timón @ 2017-07-12 8:15 ` Tom Zander 2017-07-12 12:38 ` Jonas Schnelli 2017-07-12 17:38 ` Jorge Timón 0 siblings, 2 replies; 21+ messages in thread From: Tom Zander @ 2017-07-12 8:15 UTC (permalink / raw) To: Bitcoin Protocol Discussion On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote: > I think anything less than 1 year after release of tested code by some > implementation would be irresponsible for any hardfork, even a very > simple one. Good news! Code to support 2x (the hard fork part of the proposal) has been out and tested for much longer than that. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-12 8:15 ` Tom Zander @ 2017-07-12 12:38 ` Jonas Schnelli 2017-07-12 17:38 ` Jorge Timón 1 sibling, 0 replies; 21+ messages in thread From: Jonas Schnelli @ 2017-07-12 12:38 UTC (permalink / raw) To: Tom Zander, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 228 bytes --] > Code to support 2x (the hard fork part of the proposal) has been out and > tested for much longer than that. Tested? Where? However, the hardfork part may be out there for a long time but _is still broken_. /jonas [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-12 8:15 ` Tom Zander 2017-07-12 12:38 ` Jonas Schnelli @ 2017-07-12 17:38 ` Jorge Timón 2017-07-13 19:19 ` Sergio Demian Lerner 1 sibling, 1 reply; 21+ messages in thread From: Jorge Timón @ 2017-07-12 17:38 UTC (permalink / raw) To: Bitcoin Dev, Tom Zander [-- Attachment #1: Type: text/plain, Size: 1319 bytes --] On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote: > I think anything less than 1 year after release of tested code by some > implementation would be irresponsible for any hardfork, even a very > simple one. Good news! Code to support 2x (the hard fork part of the proposal) has been out and tested for much longer than that. Not true. It's different code on top of segwit. The first attempt in btc1 (very recent) didn't even increased the size (because it changed the meaningless "base size" without touching the weight limit. As for the current code, I don't think it has been properly tested today, let alone "for mucj longer than 1 year. Anyway, I said, one year from tested release. Segwitx2 hasn't been released, has it? If so, too late to discuss a bip imo, the bip may end up being different from what has been released due to feedback (unless it is ignored again, of course). -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists•linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 2482 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-12 17:38 ` Jorge Timón @ 2017-07-13 19:19 ` Sergio Demian Lerner 2017-07-13 19:48 ` Andrew Chow 2017-07-14 13:50 ` Erik Aronesty 0 siblings, 2 replies; 21+ messages in thread From: Sergio Demian Lerner @ 2017-07-13 19:19 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2191 bytes --] The BIP has been updated. Changes: - The technical spec has been improved: now the block size increase is specified in terms of weight and not in terms of bytes. - The increase in the maximum block sigops after HF has been documented. - Comments added about the worst case block size. Happy weekend! And don't forget to start signaling something before block 475776 ! It's just 90 blocks away. Bit 1 or 4,1 or whatever you wish, but please signal something. To the moon! On Wed, Jul 12, 2017 at 2:38 PM, Jorge Timón via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > > > On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <bitcoin-dev@lists. > linuxfoundation.org> wrote: > > On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote: > > I think anything less than 1 year after release of tested code by some > > implementation would be irresponsible for any hardfork, even a very > > simple one. > > Good news! > > Code to support 2x (the hard fork part of the proposal) has been out and > tested for much longer than that. > > > Not true. It's different code on top of segwit. The first attempt in btc1 > (very recent) didn't even increased the size (because it changed the > meaningless "base size" without touching the weight limit. As for the > current code, I don't think it has been properly tested today, let alone > "for mucj longer than 1 year. > Anyway, I said, one year from tested release. Segwitx2 hasn't been > released, has it? If so, too late to discuss a bip imo, the bip may end up > being different from what has been released due to feedback (unless it is > ignored again, of course). > > > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 4076 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-13 19:19 ` Sergio Demian Lerner @ 2017-07-13 19:48 ` Andrew Chow 2017-07-13 21:18 ` Charlie 'Charles' Shrem 2017-07-14 13:50 ` Erik Aronesty 1 sibling, 1 reply; 21+ messages in thread From: Andrew Chow @ 2017-07-13 19:48 UTC (permalink / raw) To: Sergio Demian Lerner, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2558 bytes --] What's special about block 475776? On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > The BIP has been updated. > > Changes: > - The technical spec has been improved: now the block size increase is > specified in terms of weight and not in terms of bytes. > - The increase in the maximum block sigops after HF has been documented. > - Comments added about the worst case block size. > > Happy weekend! And don't forget to start signaling something before block > 475776 ! It's just 90 blocks away. > Bit 1 or 4,1 or whatever you wish, but please signal something. > > To the moon! > > > On Wed, Jul 12, 2017 at 2:38 PM, Jorge Timón via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> >> >> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <bitcoin-dev@lists. >> linuxfoundation.org> wrote: >> >> On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote: >> > I think anything less than 1 year after release of tested code by some >> > implementation would be irresponsible for any hardfork, even a very >> > simple one. >> >> Good news! >> >> Code to support 2x (the hard fork part of the proposal) has been out and >> tested for much longer than that. >> >> >> Not true. It's different code on top of segwit. The first attempt in btc1 >> (very recent) didn't even increased the size (because it changed the >> meaningless "base size" without touching the weight limit. As for the >> current code, I don't think it has been properly tested today, let alone >> "for mucj longer than 1 year. >> Anyway, I said, one year from tested release. Segwitx2 hasn't been >> released, has it? If so, too late to discuss a bip imo, the bip may end up >> being different from what has been released due to feedback (unless it is >> ignored again, of course). >> >> >> -- >> Tom Zander >> Blog: https://zander.github.io >> Vlog: https://vimeo.com/channels/tomscryptochannel >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > > > ---------- > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 5044 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-13 19:48 ` Andrew Chow @ 2017-07-13 21:18 ` Charlie 'Charles' Shrem 0 siblings, 0 replies; 21+ messages in thread From: Charlie 'Charles' Shrem @ 2017-07-13 21:18 UTC (permalink / raw) To: Andrew Chow, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3121 bytes --] Andrew, Block 475776 and block 477792 (July 26) are the last 2 difficulty adjustment periods before Aug 1st. Charlie On Thu, Jul 13, 2017 at 3:48 PM, Andrew Chow via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > What's special about block 475776? > > On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> The BIP has been updated. >> >> Changes: >> - The technical spec has been improved: now the block size increase is >> specified in terms of weight and not in terms of bytes. >> - The increase in the maximum block sigops after HF has been documented. >> - Comments added about the worst case block size. >> >> Happy weekend! And don't forget to start signaling something before block >> 475776 ! It's just 90 blocks away. >> Bit 1 or 4,1 or whatever you wish, but please signal something. >> >> To the moon! >> >> >> On Wed, Jul 12, 2017 at 2:38 PM, Jorge Timón via bitcoin-dev < >> bitcoin-dev@lists•linuxfoundation.org> wrote: >> >>> >>> >>> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" < >>> bitcoin-dev@lists•linuxfoundation.org> wrote: >>> >>> On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote: >>> > I think anything less than 1 year after release of tested code by some >>> > implementation would be irresponsible for any hardfork, even a very >>> > simple one. >>> >>> Good news! >>> >>> Code to support 2x (the hard fork part of the proposal) has been out and >>> tested for much longer than that. >>> >>> >>> Not true. It's different code on top of segwit. The first attempt in >>> btc1 (very recent) didn't even increased the size (because it changed the >>> meaningless "base size" without touching the weight limit. As for the >>> current code, I don't think it has been properly tested today, let alone >>> "for mucj longer than 1 year. >>> Anyway, I said, one year from tested release. Segwitx2 hasn't been >>> released, has it? If so, too late to discuss a bip imo, the bip may end up >>> being different from what has been released due to feedback (unless it is >>> ignored again, of course). >>> >>> >>> -- >>> Tom Zander >>> Blog: https://zander.github.io >>> Vlog: https://vimeo.com/channels/tomscryptochannel >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists•linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists•linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 7050 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-13 19:19 ` Sergio Demian Lerner 2017-07-13 19:48 ` Andrew Chow @ 2017-07-14 13:50 ` Erik Aronesty 1 sibling, 0 replies; 21+ messages in thread From: Erik Aronesty @ 2017-07-14 13:50 UTC (permalink / raw) To: Sergio Demian Lerner, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3028 bytes --] While BIP91 is probably not terribly harmful, because the vast majority of nodes and users are prepared for it - the hard fork portion of this BIP is being deployed like an emergency patch or quick bug fix to the system. Please consider updating the BIP to include some justification for the urgency of the consensus change, and the reasons for not delaying until a better engineered solution (spoonet, BIP103, etc.) can be deployed. On Thu, Jul 13, 2017 at 3:19 PM, Sergio Demian Lerner via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > The BIP has been updated. > > Changes: > - The technical spec has been improved: now the block size increase is > specified in terms of weight and not in terms of bytes. > - The increase in the maximum block sigops after HF has been documented. > - Comments added about the worst case block size. > > Happy weekend! And don't forget to start signaling something before block > 475776 ! It's just 90 blocks away. > Bit 1 or 4,1 or whatever you wish, but please signal something. > > To the moon! > > > On Wed, Jul 12, 2017 at 2:38 PM, Jorge Timón via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> >> >> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" < >> bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote: >> > I think anything less than 1 year after release of tested code by some >> > implementation would be irresponsible for any hardfork, even a very >> > simple one. >> >> Good news! >> >> Code to support 2x (the hard fork part of the proposal) has been out and >> tested for much longer than that. >> >> >> Not true. It's different code on top of segwit. The first attempt in btc1 >> (very recent) didn't even increased the size (because it changed the >> meaningless "base size" without touching the weight limit. As for the >> current code, I don't think it has been properly tested today, let alone >> "for mucj longer than 1 year. >> Anyway, I said, one year from tested release. Segwitx2 hasn't been >> released, has it? If so, too late to discuss a bip imo, the bip may end up >> being different from what has been released due to feedback (unless it is >> ignored again, of course). >> >> >> -- >> Tom Zander >> Blog: https://zander.github.io >> Vlog: https://vimeo.com/channels/tomscryptochannel >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 5507 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-10 11:50 ` Sergio Demian Lerner 2017-07-10 18:38 ` Jorge Timón @ 2017-07-12 1:06 ` Luke Dashjr 2017-07-12 15:41 ` Aymeric Vitte 1 sibling, 1 reply; 21+ messages in thread From: Luke Dashjr @ 2017-07-12 1:06 UTC (permalink / raw) To: bitcoin-dev, Sergio Demian Lerner On Monday 10 July 2017 11:50:33 AM Sergio Demian Lerner via bitcoin-dev wrote: > Regarding the timeline, its certainly rather short, but also is the UASF > BIP 148 ultimatum. BIP148 began with 8 months lead time, reduced to 5 months from popular request and technical considerations. There is nothing about BIP148 that compels an attempted hardfork 90 days later - that could just as well have been 18 months. > More than 80% of the miners and many users are willing to go in the > Segwit2x direction. With the support and great talent of the Bitcoin Core > developers, Segwit2x activation will not cause any major disruptions. That's not true at all. Based on my observations, only approximately 20% of the community follow Core's technical lead without significant consideration of their own - and who knows if that would change if Core were to suggest clearly-unsafe block size increases, or attempted to force a hardfork against consensus. Even with Core's support, many people would oppose the hardfork attempt, and it would fail. > Without Core, there will be a temporary split. Both sides will have to > hard-fork. Segwit2x's hardfork does not compel the remaining Bitcoin users to also hardfork. > I want a Bitcoin united. But maybe a split of Bitcoin, each side with its > own vision, is not so bad. I concur, but I disagree your approach has any possibility of a united Bitcoin. The only way to get that today, would be to do Segwit+Drivechain, not Segwit+Hardfork. Luke ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] A Segwit2x BIP 2017-07-12 1:06 ` Luke Dashjr @ 2017-07-12 15:41 ` Aymeric Vitte 0 siblings, 0 replies; 21+ messages in thread From: Aymeric Vitte @ 2017-07-12 15:41 UTC (permalink / raw) To: bitcoin-dev Le 12/07/2017 à 03:06, Luke Dashjr via bitcoin-dev a écrit : > Even with Core's support, many people would oppose the hardfork > attempt, and it would fail. Why with or without Core support are you sure that it will fail, what can those that are opposing the hardfork attempt do (with or without Core) and what does "fail" mean here in fact? -- Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2017-07-14 13:50 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-07 22:25 [bitcoin-dev] A Segwit2x BIP Sergio Demian Lerner
2017-07-07 22:44 ` Matt Corallo
2017-07-07 23:25 ` Gregory Maxwell
2017-07-07 23:22 ` Gregory Maxwell
2017-07-13 3:10 ` Sergio Demian Lerner
2017-07-13 3:19 ` Sergio Demian Lerner
2017-07-07 23:27 ` Luke Dashjr
2017-07-07 23:38 ` Gregory Maxwell
2017-07-08 6:30 ` Erik Aronesty
2017-07-08 13:28 ` Btc Drak
[not found] ` <A7FFF8F7-9806-44F1-B68F-F83C44893365@ob1.io>
2017-07-10 11:50 ` Sergio Demian Lerner
2017-07-10 18:38 ` Jorge Timón
2017-07-12 8:15 ` Tom Zander
2017-07-12 12:38 ` Jonas Schnelli
2017-07-12 17:38 ` Jorge Timón
2017-07-13 19:19 ` Sergio Demian Lerner
2017-07-13 19:48 ` Andrew Chow
2017-07-13 21:18 ` Charlie 'Charles' Shrem
2017-07-14 13:50 ` Erik Aronesty
2017-07-12 1:06 ` Luke Dashjr
2017-07-12 15:41 ` Aymeric Vitte
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox