Closed snavsenv closed 7 years ago
Thank you. That seems to be a hardfork. Are they aware it is incompatible with the current network?
@snavsenv dude, can you stop trolling, no one is falling for it.
@snavsenv me too. especially I'm looking for the technical documents that decision is based on (they claim to work like an IETF group, hence there must be such notes)
The segwit2x agreement has ~93% or more of the miners following it.
The non-hardfork portion of Bitcoin will effectively halt under that condition. With only 7% of the hashrate, the first difficulty adjustment will be more than 6 months out, and the chain will only be able to process ~35k transactions per day, down from a pre-segwit volume of over 200,000 transactions per day. As most of the businesses in the ecosystem are either signatories to the agreement or have stated they will follow the most proof-of-work chain, the legacy chain may be even more unusable.
The rationale behind the choice the miners and businesses have made is that the ecosystem has two fundamentally incompatible visions about what Bitcoin "is" and what it should become, and as a result Bitcoin progress stalled, and "Donate via Bitcoin" links across the web were replaced with "donate via ethereum" links, giving altcoins a huge boost in popularity. In the face of competing coins growing, fees rising, and zero compromise coming from the developers left over from the 2015 schism, the businesses formed this agreement as a last-ditch effort to keep the ecosystem whole.
Despite their attempt to keep the ecosystem in one piece, a vocal contingent deeply opposed to the holdover-developer vision forked off anyway, so it hasn't totally accomplished that goal. Regardless, the new fork is not doing very well and many expect it to die, so this remains the best possible bet to keep the Bitcoin ecosystem in one piece.
If this proposal isn't successful, we will almost certainly end up with two competing Bitcoin's, and the competition (and all its associated negative effects - on both sides - for breaking consensus in a consensus system) will be fierce; Ultimately the beneficiaries of this schism will be the competing altcoins, at least for a time.
That is why this project exists. Using the "actions speak louder than words" view, the Core Developer team is doing what they have always done and as they said they would do as early as 2013 - opposing any and all onchain scaling proposals outright regardless of any other considerations. With this project we can move past the issue and give scaling concepts like lightning and sidechains time to grow and prove themselves before blocks get full again. Without it, segwit-only gives us a very short time before blocks will be full again, and continues to leave the community stuck with only one developer vision and community forums who ban all competing viewpoints.
Please take your nonsense to r/btc where it belongs.
@CosmicHemorroid its a fact that 93% of miners will make the move to the hard fork. how is the legacy chain going to even be viable without another hard fork? if they do, then they will have to also signal a proper fork and hold their fork to the same standards they are trying to hold this one. which they obviously wont.
I'm asking for the technical documents and I have no interest in your fud-propaganda @JaredR26 (e.g. despite what your write, core does offer several on-chain scaling solutions, etc.). please troll somewhere else, github should be more technical.
I'm asking for the technical documents and I have no interest in your fud-propaganda
I answered snavsenv's question, and provided detail for anyone else who may read this thread later genuinely seeking answers.
Along with fud and propaganda.
@haraldschilly and yet you're name calling and not assuming good faith?
What kind of 'technical documents' are you looking for? Have you tried an internet search? I can recommend duckduckgo and google. Let us know if you need help using them.
and "Donate via Bitcoin" links across the web were replaced with "donate via ethereum" links
You care about donate buttons?
@mpatc I know how to use a search engine. No, I haven't found any such technical document. Therefore I'm, like the OP, wondering where they are and yes, please help me.
You care about donate buttons?
I care about all users and use-cases given how incredibly small Bitcoin relative to the world of finance.
You care about donate buttons?
I care about use cases. The business I had when I first got into bitcoin is no longer possible due to congestion and high fees. Many many many use cases have be destroyed over the past 2 years, and competing coins have snapped these up, along with market share.
@haraldschilly I linked to the document he asked for above. The best source for technical info I know of is the mailing list. You can find a link to the mailing list at the link above as well.
The business I had when I first got into bitcoin is no longer possible
100% offtopic and besides that, google for "pivot" in the context of startups.
100% offtopic and besides that, google for "pivot" in the context of startups.
Thanks officer but we were responding to @betawaffle's question directly.
Harald, Here are the technical specifications for the upcoming SegWit2x hardfork:
At the time of the hardfork, MaxBaseBlocksize is increased from 1M to 2M bytes.
At the time of the hardfork, MaxBlockWeight is increased from 4M to 8M bytes.
Hardfork and wipeout protection: A block larger than 1M base size is required at blockheight = (SegWit Activation blockheight + 12,960)
Legacy transaction size is limited to 1M bytes per tx (to mitigate quadratic hashing issue).
Any questions?
Oliver
On Aug 7, 2017 2:50 PM, "Harald Schilly" notifications@github.com wrote:
I'm asking for the technical documents and I have no interest in your fud-propaganda @JaredR26 https://github.com/jaredr26 (e.g. despite what your write, core does offer several on-chain scaling solutions, etc.). please troll somewhere else, github should be more technical.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/btc1/bitcoin/issues/104#issuecomment-320748721, or mute the thread https://github.com/notifications/unsubscribe-auth/AP9EnQh6EQ30UD0gvAZNpzVmAA55IkITks5sV1yDgaJpZM4OvvsQ .
@mpatc there is some text, but nothing else. Here is a medium post by garzik mentioning IETF group-like development as a model. They discuss their decisions in the open and provide technical documents as the foundation for their arguments. where are these technical documents that did motivate the decision in your link above?
For context: https://datatracker.ietf.org/ is a database containing such documents.
@jgarzik can you please close this off?
@opetruzel
Any questions?
Yes, I'm well aware of these technical specs. I'm asking for the technical studies/analysis/etc. that did lead to the decision and well, since you quote this here, also the basis for the motivation of these parameter changes, etc.
I imagine somewhere is a 20 page whitepaper, with statistical analysis, etc. I am very interested, and also some I know studying software engineering, would be very keen to see it.
where are these technical documents that did motivate the decision in your link above?
Motivations for complex political compromises are inherently not a technical specification. You're deliberately asking the impossible, something that much of the opposition to this compromise do frequently so they can point to it as evidence of shortcomings.
I gave you the motivation for the decision. I'm sorry that it doesn't live up to your arbitrary standards, but that's what it is, and we're not going to play the "lets make btc1 look disorganized" game with you.
@floreslorca if anyone is trolling its this github and its supposed supporters
Why make such an agreement and make everyone nervous?
Hi. Was wondering where i could find some more information about the "NYA" agreement and the rationale behind it. It would be nice to know whats going on.