|
Title: Proposal Support Post by: DooMAD on June 16, 2017, 03:51:51 PM As the debate rages on, it seems like some people are beginning to make assumptions about which proposals people actually do and don't support. For example, all "bigblockers" have to apparently support BU, which isn't necessarily the case. So if anyone would like to go on record and explicitly declare their support for the various proposals, you've come to the right thread.
For clarity: BIP141 (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki): This is Core's proposed softfork for Segregated Witness, commonly referred to as "SegWit". The reasoning for this proposal is outlined with both benefits (https://bitcoincore.org/en/2016/01/26/segwit-benefits/) and costs (https://bitcoincore.org/en/2016/10/28/segwit-costs/). BIP148 (https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki): This is a User Activated Softfork for SegWit, commonly referred to as "UASF". The reasoning for this proposal is outlined here (https://bitcointalk.org/index.php?topic=1805060.0). BIP149 (https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki): This is a User Activated Softfork for SegWit with an "activation on timeout". The reasoning for this proposal is outlined here (https://www.reddit.com/r/Bitcoin/comments/69xkvv/understanding_bip149_redeployment_of_segwit_with/). SegWit2x / New York Agreement (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013921.html): This is a SegWit hardfork with the addition of a 2MB blocksize, commonly referred to as "SegWit2x". The reasoning for this proposal is outlined here (https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-June/000042.html) and here (https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77). Extension Blocks (https://github.com/tothemoon-org/extension-blocks/blob/master/spec.md): This is a proposal to create an opt-in second layer for an on-chain capacity increase. The reasoning for this proposal is outlined here (https://medium.com/purse-essays/ready-for-liftoff-a5533f4de0b6) and here (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html) Segwit Adaptive (https://bitcointalk.org/index.php?topic=1911288.0): This is a proposal to allow dynamic resizing of blocks based on network traffic. Based on BIP106 (https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki). The reasoning for this proposal is outlined here (https://bitcointalk.org/index.php?topic=1911288.0). Emergent Consensus (https://bitcoinec.info/): This is a proposal for miners and nodes to dynamically declare the size of blocks they are willing to accept. The reasoning for this proposal is outlined here (https://medium.com/@solex1/introduction-to-emergent-consensus-c318c6c0e1bd). Bitmaincoin (https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip148/): This is an altcoin proposed by Bitmain and included as a joke of sorts.
If anyone wants me to add them to the list, please post in the following format (preferably still in the code tags): Code: [tr] (Optional) Colours are: Code: [glow=#00FF66,2,300]Prefer[/glow] Title: Re: Proposal Support Post by: Ost on June 16, 2017, 04:49:28 PM Code: [tr] I'm not sure about some of these though, since I don't know a lot about all of them. Maybe there should be something like a "No opinion" option? Title: Re: Proposal Support Post by: DooMAD on June 16, 2017, 05:32:44 PM I'm not sure about some of these though, since I don't know a lot about all of them. Maybe there should be something like a "No opinion" option? You can certainly put "Undecided" or "No Opinion" and leave those uncoloured if you like. Just don't delete any lines because it messes up the table formatting. :) Did you want to edit your submission before inclusion? Title: Re: Proposal Support Post by: Ost on June 16, 2017, 05:51:24 PM I'm not sure about some of these though, since I don't know a lot about all of them. Maybe there should be something like a "No opinion" option? You can certainly put "Undecided" or "No Opinion" and leave those uncoloured if you like. Just don't delete any lines because it messes up the table formatting. :) Did you want to edit your submission before inclusion? Code: [tr] Here you go! Title: Re: Proposal Support Post by: iCEBREAKER on June 16, 2017, 06:40:38 PM
Code: [tr] Title: Re: Proposal Support Post by: forevernoob on June 16, 2017, 06:49:06 PM Code: [tr] Title: Re: Proposal Support Post by: mindrust on June 16, 2017, 06:50:43 PM
Title: Re: Proposal Support Post by: franky1 on June 16, 2017, 06:59:54 PM
Code: [tr] they are all missing things. segwit148149 segwit2x are all 2merkle which is cludgy code, also doesnt limit txsigops of legacy tx's very well or uses cludgy maths to do it the dynamic bips have issues too like 106 for instance has crap bip of going down as well as up, which can cause blocks made before going down (thus being more then new limit) potentially getting orphaned out.. there should be no need to drop a consensus limit as that causes issues for the chain.. pools can simply do a policy blocksize drop instead segwit+size increases still rely on developer spoon feeding/promises after X. which is still empty promises/delays its as if devs want to promote the worse versions there are, as ways to keep the dev's in control/ or to make the devs remain relevant by always having issues for the devs to be needed to then fix later any bip that actually gives nodes full control to not rely on dev endless requirement ends up being tossed aside concepts i prefer dynamics - takes the dv spoonfeeding/2year debate out of the way because NODES control size (yep i said nodes not pools) but with other things aswell such as 1 merkle block where all keypairs sit side by side in same area all the stuff people want new keypairs, weak/thin blocks nodes request a UTXO set first to run in lite mode while it syncs so that people can see unspents and make tx's meaning they are not waiting a week before even being able to do anything other things like proper limiting sigops and bloat per tx add a new fee priority mechanism that penalises people that spend more then once a day and reward those that dont, (yep there are ways to do it) Title: Re: Proposal Support Post by: theymos on June 16, 2017, 08:08:51 PM
Code: [tr] * Despite the straightforward-sounding name, the meaning of "SegWit2x" is very unclear. There are like a dozen totally different proposals going by that name, most of them very bad, a few like COOP less bad. I can imagine a "SegWit + 2MB-hardfork" proposal that I would instead rate as Deficient. † I am completely opposed to that extblocks proposal, but the idea of extension blocks is OK. SegWit basically is an extension block proposal, after all. Title: Re: Proposal Support Post by: Lauda on June 16, 2017, 08:44:01 PM
Code: [tr] If my modifications to the last two are not acceptable, just replace with "No". * Despite the straightforward-sounding name, the meaning of "SegWit2x" is very unclear. There are like a dozen totally different proposals going by that name, most of them very bad, a few like COOP less bad. I can imagine a "SegWit + 2MB-hardfork" proposal that I would instead rate as Deficient. They are finally aiming to make it compatible with existing Segwit deployment and even BIP 148. In that variant, I'd find it acceptable even though I don't agree with the rushed hard fork in 6 months. If they do not do it, in the way that I've just specified then my vote would be 'No'.OP, I suggest putting in some time to make the formatting/styling of the OP better. Title: Re: Proposal Support Post by: andyatcrux on June 16, 2017, 09:21:10 PM Where is Bip 91? It is now compatible with Bip 148, is being chosen by miners as we speak and may very well give us Segwit prior to August 1st. Maybe it is classified here as Segwit2X (not the deployment method, but okay) ?
Title: Re: Proposal Support Post by: Lauda on June 16, 2017, 09:23:28 PM Where is Bip 91? It is now compatible with Bip 148, is being chosen by miners as we speak and may very well give us Segwit prior to August 1st. BIP 91 (https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki) seems to have been incorporated into the Segwit2x proposal. Therefore it should not be listed separately. Title: Re: Proposal Support Post by: andyatcrux on June 16, 2017, 09:24:31 PM Yeah, thanks. I edited my message to late. :D
Title: Re: Proposal Support Post by: frodocooper on June 17, 2017, 12:07:15 AM
Code: [tr] Title: Re: Proposal Support Post by: Variogam on June 17, 2017, 12:14:30 AM
Code: [tr] Title: Re: Proposal Support Post by: FiendCoin on June 17, 2017, 02:46:05 AM
Code: [tr] Title: Re: Proposal Support Post by: d5000 on June 17, 2017, 05:00:06 AM Nice initiative.
From the three "preferred" variants (these are those I consider "good", not just "acceptable"), I rank them the following way: 1) Extension blocks (the concept, not a particular initiative) 2) Segwit-Adaptive/BIP-106 3) "traditional" Segwit BIP-141 Code: [tr] Title: Re: Proposal Support Post by: DooMAD on June 17, 2017, 11:25:18 AM Checkpoint. Keep 'em coming. Currently it's loosely ordered by membership rank and the order in which you posted. Hope that's okay with everyone. I'm definitely too lazy to alphabetise or do anything overtly OCD with it. Looks like there are already some trends emerging in what we generally do and don't approve of.
OP, I suggest putting in some time to make the formatting/styling of the OP better. Yeah, could do with some tweaking. I did throw it together rather hastily, heh. Can't do a great deal with the table itself since, as far as I'm aware at least, there's no option for borders in SMF's BBCode unless you mod it. But the rest of the post cold be arranged a bit better. Might also try to add more of a summary for each proposal. add a new fee priority mechanism that penalises people that spend more then once a day and reward those that dont, (yep there are ways to do it) I'd like to include that in the proposal for SegWit Adaptive, but if you can't get behind it (or any of the other proposals) because of your views on the "1 merkle block where all keypairs sit side by side in same area" part, you're just going to isolate yourself. You have to recognise the main trend in this thread so far, which is that everyone else who has posted has, in some form or another, expressed support for SegWit. I don't mean to be blunt, but, regardless of your feelings towards it, there's too much momentum behind the idea for you to obstruct it. With the possible exception of extreme ossification and stagnation where this debate never ends, the only outcome moving forward is one that includes SegWit. Either accept that, or find yourself moving (of your own volition) to the fringes where your voice won't be heard. Title: Re: Proposal Support Post by: franky1 on June 17, 2017, 11:41:03 AM but if you can't get behind it (or any of the other proposals) because of your views on the "1 merkle block where all keypairs sit side by side in same area" part, you're just going to isolate yourself. You have to recognise the main trend in this thread so far, which is that everyone else who has posted has, in some form or another, expressed support for SegWit. I don't mean to be blunt, but, regardless of your feelings towards it, there's too much momentum behind the idea for you to obstruct it. With the possible exception of extreme ossification and stagnation where this debate never ends, the only outcome moving forward is one that includes SegWit. Either accept that, or find yourself moving (of your own volition) to the fringes where your voice won't be heard. you do realise that segwit can actually be done in a 1 merkle block.. ill leave you to think about that and have a lightbulb(epiphany) moment. Title: Re: Proposal Support Post by: quake313 on June 17, 2017, 06:18:56 PM
Code: [tr] Great idea btw DooMAD. Title: Re: Proposal Support Post by: DooMAD on June 18, 2017, 12:01:29 AM but if you can't get behind it (or any of the other proposals) because of your views on the "1 merkle block where all keypairs sit side by side in same area" part, you're just going to isolate yourself. You have to recognise the main trend in this thread so far, which is that everyone else who has posted has, in some form or another, expressed support for SegWit. I don't mean to be blunt, but, regardless of your feelings towards it, there's too much momentum behind the idea for you to obstruct it. With the possible exception of extreme ossification and stagnation where this debate never ends, the only outcome moving forward is one that includes SegWit. Either accept that, or find yourself moving (of your own volition) to the fringes where your voice won't be heard. you do realise that segwit can actually be done in a 1 merkle block.. Yes, you've made that abundantly clear from the dozens of posts you've made on that particular subject. We get it. We really do. But that's not the point, though. What's happening is that you're allowing your insistence on this particular detail to alienate those around you. The point is, it doesn't have to be perfect in the eyes of everyone, or more to the point, it can't, because that's impossible. Consensus doesn't work that way. It just has to be "good enough" for a significant proportion of users to agree with it. So far this thread seems to indicate a two-merkle SegWit is indeed "good enough", so each time you draw the line there, you find yourself further out of step with what almost everyone else is deeming to be acceptable. Fight the battles you have a chance of winning instead of marginalising yourself like that. Sure, I'd prefer adaptive over fixed blocksize, but I'm not going to dig my heels in, take my ball and go home if I can't get that. Because it achieves nothing. Consensus steamrolls over that lone-wolf shit. Sometimes we just have to settle for whatever we can realistically get. So rather than dismissing everything as weak, get behind something workable and move on. Because you're not going to get your perfect ideal unless you want an altcoin to your own personal specifications. Title: Re: Proposal Support Post by: Last of the V8s on June 18, 2017, 09:44:39 AM franky1 is far from alone in finding all these proposals weak, deficient, unnecessary, irrelevant, suspicious, laughable, disasters waiting to happen etc.
Generation after generation of older (ok theymos is q old!), richer bitcoiners than represented here have moved away from discussing such things here, or at all. And they, and we young scamps, can run whatever versions of bitcoin we like, with whatever tweaks we want to take from developer research or not. pl don't take your thread so seriously Title: Re: Proposal Support Post by: franky1 on June 18, 2017, 10:48:29 AM ever thought that all the options are just weak and deficient and that we should not just 'settle' for good enough.
each have flaws, each open up the network to new attack/spam/bloat vectors that can make things worse not better. we should not just let devs get their way and settle for whatever they do. if only devs were independent, rather than factions of BS vs 'the others' things would have moved on what needs to be done is for devs to get off their thrones and start listening to criticism and fix the issues. not let the devs form a faction and send out their reddit scripts to hypnotise and distract the conversations away from the issues. by saying 'its impossible' to get XYZ is a lie.. it is possible. but when the community want XYZ but the devs just want to offer is X+a or y+a or z+a but refuse XYZA, even knowing this drama can continue right up until 2019('late 2018'), devs are not ready to give in and offer XYZA.. any time soon.. if ever . what a true "reference" client should offer is the ability for users to turn off and on options, make choices and have settings.. then let consensus decide what goes forward. not spoon feed out v0.xxx every 3 months and wait for people to be hypnotised into following X Title: Re: Proposal Support Post by: Lauda on June 18, 2017, 11:32:32 AM Yes, you've made that abundantly clear from the dozens of posts you've made on that particular subject. We get it. We really do. Just ignore his gibberish. He's in no way qualified to judge a proposal like that anyways.Sure, I'd prefer adaptive over fixed blocksize, but I'm not going to dig my heels in, take my ball and go home if I can't get that. Because it achieves nothing. Consensus steamrolls over that lone-wolf shit. Correct. Actually I'd argue that someone who tried to disrupt discussions by forcing proposals which have almost 0 support into them is malevolent. It's absolutely clear that it's either BIP141, BIP148, Segwit2x for the foreseeable future. pl don't take your thread so seriously Don't take franky so seriously.each have flaws, each open up the network to new attack/spam/bloat vectors that can make things worse not better. No.Title: Re: Proposal Support Post by: franky1 on June 18, 2017, 11:40:11 AM each have flaws, each open up the network to new attack/spam/bloat vectors that can make things worse not better. No.keep sticking your head in the sand lauda. Title: Re: Proposal Support Post by: DooMAD on June 18, 2017, 12:28:56 PM Correct. Actually I'd argue that someone who tried to disrupt discussions by forcing proposals which have almost 0 support into them is malevolent. It's absolutely clear that it's either BIP141, BIP148, Segwit2x for the foreseeable future. You're probably right about BIP141 and SegWit2x, but I fundamentally disagree on BIP148. The general narrative on this board has always been that forced contentious splits are bad for Bitcoin, so I don't see why that narrative is suddenly changing just because the contentious split happens to include SegWit. That's hypocrisy. As for some of the other proposals that do clearly have less support, those are somewhat of a chicken and egg situation. How are those proposals supposed to gain any support if they aren't discussed and no one shines a light on them? Or is it merely malevolent to discuss any ideas that don't fit neatly into your own personal preferred vision? Updated the OP with some greater depth into the various proposals. Title: Re: Proposal Support Post by: Lauda on June 18, 2017, 12:32:13 PM You're probably right about BIP141 and SegWit2x, but I fundamentally disagree on BIP148. The general narrative on this board has always been that forced contentious splits are bad for Bitcoin, so I don't see why that narrative is suddenly changing just because the contentious split happens to include SegWit. That's hypocrisy. You do not fundamentally understand BIP148 then? It is happening for any client running the BIP148 patch. Meaning, if neither BIP141 nor SegWit2x happen in time then BIP148 is happening 100%. This does not mean that BIP148 will succeed, just that it will happen.As for some of the other proposals that do clearly have less support, those are somewhat of a chicken and egg situation. How are those proposals supposed to gain any support if they aren't discussed and no one shines a light on them? Or is it merely malevolent to discuss any ideas that don't fit neatly into your own personal preferred vision? Disagreed. Some of those proposals have been around for a while now, and have been debated. Once the upcoming storm clears, then you may start discussing them again. For now, I advise against doing this to avoid further stalling. Title: Re: Proposal Support Post by: DooMAD on June 18, 2017, 12:50:05 PM You're probably right about BIP141 and SegWit2x, but I fundamentally disagree on BIP148. The general narrative on this board has always been that forced contentious splits are bad for Bitcoin, so I don't see why that narrative is suddenly changing just because the contentious split happens to include SegWit. That's hypocrisy. You do not fundamentally understand BIP148 then? It is happening for any client running the BIP148 patch. Meaning, if neither BIP141 nor SegWit2x happen in time then BIP148 is happening 100%. This does not mean that BIP148 will succeed, just that it will happen.Yes, 100% happening, but (percentages varying a great deal depending on the level of mining support) 33.33% chance of creating an altcoin, 33.33% chance of creating a contentious split with two Bitcoins and 33% chance of a smooth transition and a longest chain with SegWit enabled. People argue that hardforks are too disruptive and risky, but are seemingly okay with that potential mess? The result is arguably less certain or predictable than that of a hardfork, so again, complete and utter hypocrisy to argue against hardforks or dismiss them as dangerous whilst simultaneously supporting UASF. As for some of the other proposals that do clearly have less support, those are somewhat of a chicken and egg situation. How are those proposals supposed to gain any support if they aren't discussed and no one shines a light on them? Or is it merely malevolent to discuss any ideas that don't fit neatly into your own personal preferred vision? Disagreed. Some of those proposals have been around for a while now, and have been debated. Once the upcoming storm clears, then you may start discussing them again. For now, I advise against doing this to avoid further stalling. The insistence to dictate what can and can't be discussed evidently doesn't work here. If anything, it tends to backfire and create more support for the proposals people try to bury than there otherwise would be. That particular mentality has done far more to stifle progress than anything else, IMO. Discussions should be as neutral and transparent as Bitcoin itself. Title: Re: Proposal Support Post by: Lauda on June 18, 2017, 12:54:02 PM Yes, 100% happening, but (percentages varying a great deal depending on the level of mining support) 33.33% chance of creating an altcoin, 33.33% chance of creating a contentious split with two Bitcoins and 33% chance of a smooth transition and a longest chain with SegWit enabled. People argue that hardforks are too disruptive and risky, but are seemingly okay with that potential mess? The result is arguably less certain or predictable than that of a hardfork, so again, complete and utter hypocrisy to argue against hardforks or dismiss them as dangerous whilst simultaneously supporting UASF. I did not comment whether a chain split is acceptable, nor the amount of support currently behind BIP 148 in this thread. I merely mentioned that it is happening if the other two proposals fail to activate before it. This is a factual/neutral observation. I don't think this thread is the place to discuss the nature of BIP 148 or BIP 149 for that matter? I'm rather surprised by the lack of spammers submitting their bullshit votes in there. ::)For now, I advise against doing this to avoid further stalling. The insistence to dictate what can and can't be discussed evidently doesn't work here. Title: Re: Proposal Support Post by: franky1 on June 18, 2017, 02:37:28 PM Discussions should be as neutral and transparent as Bitcoin itself. Updated the OP with some greater depth into the various proposals. yet BU (https://github.com/BitcoinUnlimited/BitcoinUnlimited)/EC (https://bitcoinec.info/): This is Bitcoin Unlimited or "Emergent Consensus", a proposal for miners and nodes to declare the size of blocks they are willing to accept. The reasoning for this proposal is outlined here (https://medium.com/@solex1/introduction-to-emergent-consensus-c318c6c0e1bd). EC is not a BU branded 'product' BU brand call theirs 'Adjustable Block-size Cap' (ABC) commonly people call EC 'dynamic blocksize' which again is not a BU product seems by making EC a BU option. you will get people to basiedly not vote for EC it purely because YOU branded it as BU, knowing peopl will respond 'oh no i read on reddit that its bad bad bad' other implementations totally unrelated to BU use EC Title: Re: Proposal Support Post by: jonald_fyookball on June 18, 2017, 03:06:22 PM so I am allowed to vote or does my negative feedback from Lauda and Blockstream CTO Greg Maxwell mean I will be censored?
Title: Re: Proposal Support Post by: DooMAD on June 18, 2017, 08:39:33 PM seems by making EC a BU option. you will get people to basiedly not vote for EC it purely because YOU branded it as BU, knowing peopl will respond 'oh no i read on reddit that its bad bad bad' other implementations totally unrelated to BU use EC So is it less biased to simply not mention BU? I don't mind just simply calling it EC. I'll edit the OP. //EDIT: Done, is that better? And would you like to edit your submission as a result? so I am allowed to vote or does my negative feedback from Lauda and Blockstream CTO Greg Maxwell mean I will be censored? I'm too lazy to check everyone's feedback, so if your declaration goes missing from the list, it wasn't me. Post away. Title: Re: Proposal Support Post by: jonald_fyookball on June 18, 2017, 09:47:10 PM Code:
Title: Re: Proposal Support Post by: Paashaas on June 19, 2017, 02:30:40 AM Code: [tr] Title: Re: Proposal Support Post by: theymos on June 19, 2017, 03:06:30 AM Your definitions aren't accurate.
BIP148 and BIP149 are virtually identical except that BIP149 activates 6-12 months later in order to reduce turbulence. Distinguishing BIP148 as a "UASF" and BIP149 as "timed" is misleading: they're both UASFs, and both timed with the possibility of early activation in case of miner cooperation. There are many very different "Segwit2x" proposals, but BIP91 is absolutely not one of them. It doesn't involve any max block size increase except for SegWit. BIP91 is a way of activating the original BIP141/BIP9 deployment at an 80% mining threshold rather than the original 95% threshold. There is no single "Segwit2x" proposal that you can clearly point to. Title: Re: Proposal Support Post by: franky1 on June 19, 2017, 03:12:04 AM There is no single "Segwit2x" proposal that you can clearly point to. i have to agree with theymos all the 'promises' of increase to a 2mb base block miss out on actually including code that actually includes a 2mb base block thus all same half gestures/ empty promises since 2015 Title: Re: Proposal Support Post by: DooMAD on June 19, 2017, 09:57:54 AM Your definitions aren't accurate. BIP148 and BIP149 are virtually identical except that BIP149 activates 6-12 months later in order to reduce turbulence. Distinguishing BIP148 as a "UASF" and BIP149 as "timed" is misleading: they're both UASFs, and both timed with the possibility of early activation in case of miner cooperation. There are many very different "Segwit2x" proposals, but BIP91 is absolutely not one of them. It doesn't involve any max block size increase except for SegWit. BIP91 is a way of activating the original BIP141/BIP9 deployment at an 80% mining threshold rather than the original 95% threshold. There is no single "Segwit2x" proposal that you can clearly point to. OP tweaked again to rectify. I think the latest plan to activate SegWit2x is to utilise the signalling bits from BIP91, which is where I got mixed up. Quote from: https://bitcoinmagazine.com/articles/bip91-segwit-activation-kludge-should-keep-bitcoin-whole/ (...)SegWit2x readiness would be signaled using another piece of activation data: “bit 4” instead of “bit 1.” This makes SegWit2x largely incompatible with BIP141, and especially with BIP148: Different nodes would be looking at different activation bits, meaning they could activate SegWit under different circumstances and at different times; and that would mess up SegWit-specific block relay policy between nodes, potentially fracturing the network. BIP91 Now, it seems BIP91 has provided the solution. BIP91 is a proposal by Bitmain Warranty (not to be confused with Bitmain) engineer James Hilliard which was specifically designed to prevent a coin-split by making SegWit2x and BIP148 compatible. The proposal resembles BIP148 to some extent. Upon activation of BIP91, all BIP91 nodes will reject any blocks that do not signal support for SegWit through bit 1. As such, if a majority of miners (by hash power) run BIP91, the longest valid Bitcoin chain will consist of SegWit-signaling blocks only, and all regular BIP141 SegWit nodes will activate the protocol upgrade. Where BIP91 differs from BIP148 is that it doesn’t have a set activation date, but is instead triggered by hash power. BIP91 nodes will reject any non-SegWit signalling blocks if, and only if, 80 percent of blocks first indicate within two days that’s what they’ll do. This indication is done with bit 4. As such, the Silbert Accord can technically be upheld — 80 percent hash power activation with bit 4 — while at the same time activating the existing SegWit proposal. And if this is done before August 1st, it’s also compatible with BIP148, since BIP148 nodes would reject non-bit 1 blocks just the same. This proposal gives miners a little over six weeks to avoid a coin-split, under their own agreed-upon terms. With a SegWit2x launch date planned for July 21st, that should not be a problem… assuming that the miners actually follow through. So obviously miners are jumping on board (https://cointelegraph.com/news/f2pool-announces-support-for-segwit2x) with this. //EDIT: -ck sums it up more succinctly in this thread (https://bitcointalk.org/index.php?topic=1928093.msg19646403#msg19646403). //DOUBLE EDIT: Look at the last 1000 blocks (https://coin.dance/blocks#corehistorical). This looks like a pretty momentous shift. Title: Re: Proposal Support Post by: azguard on June 20, 2017, 11:40:17 AM This should turn out to be interesting at the end
Code: [tr] Title: Re: Proposal Support Post by: Variogam on June 20, 2017, 03:39:58 PM There are many very different "Segwit2x" proposals, but BIP91 is absolutely not one of them. It doesn't involve any max block size increase except for SegWit. BIP91 is a way of activating the original BIP141/BIP9 deployment at an 80% mining threshold rather than the original 95% threshold. The working group Core code for Segwit2x is at https://github.com/btc1/bitcoin I never heard about any other Segwit2x code with which all the NYA signers would agree with. About the "It doesn't involve any max block size increase except for SegWit" where you got franky1 already tricked by him saying "all the 'promises' of increase to a 2mb base block miss out on actually including code that actually includes a 2mb base block" Commits on Jun 16, 2017: https://github.com/btc1/bitcoin/commit/c11c37b0d6cf434b6565b2d70ed5aa2b1e63ba3e most relevant code for the 2MB: +/** BIP102 block size increase height */ +static const unsigned int BIP102_FORK_MIN_HEIGHT = 485218; -static const unsigned int MAX_BLOCK_BASE_SIZE = 1000000; +static inline bool BIP102active(int nHeight, bool fSegwitSeasoned) +{ + if (!fSegwitSeasoned) + return false; + + if (nHeight < (int)BIP102_FORK_MIN_HEIGHT) + return false; + + return true; +} + +static const unsigned int MAX_LEGACY_BLOCK_SIZE = (1 * 1000 * 1000); +inline unsigned int MaxBlockBaseSize(int nHeight, bool fSegwitSeasoned) +{ + if (!BIP102active(nHeight, fSegwitSeasoned)) + return MAX_LEGACY_BLOCK_SIZE; + + return (2 * 1000 * 1000); +} obviously removed MAX_BLOCK_BASE_SIZE is replaced with new logic to check whether block is invalid at many other lines, just check the Segwit2x pull commit code if interested Title: Re: Proposal Support Post by: franky1 on June 20, 2017, 04:26:32 PM good to see an implementation finally showing the main block size increase... and with a ~3 month from now activation.
seems i should keep my eye on updates daily, rather than sporadically(few times a month/when they announce RC versions) im guessing things like this can change peoples opinions if all the other 'brands' followed suite with the same commits.. lets wait and see ........ i just wonder how many blocks are waving flags.. but not running the actual implementation that has the code. thus basically sybil flagging Title: Re: Proposal Support Post by: DooMAD on June 23, 2017, 01:54:36 PM I guess the timing of this thread wasn't ideal, since any further additions would likely be influenced by the unprecedented (and rather spectacular) shift in mining support towards a certain proposal, potentially skewing the results. It's not yet a foregone conclusion, though. Plus it's still interesting to compare everyone's preferences. So I hope people don't lose interest in the idea. I'm still paying attention and will continue to update the list as necessary.
good to see an implementation finally showing the main block size increase... and with a ~3 month from now activation. Now that you've taken another look at it, did you still want to declare "weak" for SegWit2x, or should I amend that? Title: Re: Proposal Support Post by: franky1 on June 23, 2017, 02:53:15 PM having to lower my standards...
Code: [tr] even though i reduced my standards.. its just the cludginess of the bips related to segwit.. the empty promises/ half gestures.. and still reliance of devs controlling when the next blocksize increase occurs (meaning endless debates lasting a couple years) its like they offer you a spoon of sugar but then put a fly on top Title: Re: Proposal Support Post by: sgbett on June 29, 2017, 02:29:21 PM
Code: [tr] Title: Re: Proposal Support Post by: mainpmf on June 29, 2017, 02:48:51 PM That's a good idea. It'll give an idea of the position of everyone
Code: [tr] Title: Re: Proposal Support Post by: ibminer on June 30, 2017, 04:07:55 PM
Code: [tr] https://youtu.be/ejorQVy3m8E Title: Re: Proposal Support Post by: Lauda on July 04, 2017, 09:30:55 AM Oddly enough, there have not been a lot of people posting their preferences. I doubt that it is because they do not "care". I think that the main issue here is that, one side is spreading a lot of misinformation (both do, but one does a lot more than the other). I often get questions, or even paid consulting jobs where people want explanations for all of these proposals/terms.
Title: Re: Proposal Support Post by: spartacusrex on July 04, 2017, 10:27:32 AM
Code: [tr] Oooooo.. this is a very funky topic DoomMAD. Thanks. Title: Re: Proposal Support Post by: hv_ on July 07, 2017, 03:04:18 PM
Code: [tr] Title: Re: Proposal Support Post by: Lauda on July 07, 2017, 03:11:52 PM
The following applies to you too, idiot: Are you brain dead? Something that is privately mined for 72 hours by a single company, then released into the *wild* is NOT Bitcoin. Title: Re: Proposal Support Post by: hv_ on July 07, 2017, 04:26:46 PM
The following applies to you too, idiot: Are you brain dead? Something that is privately mined for 72 hours by a single company, then released into the *wild* is NOT Bitcoin. Why? If its due to the SN white paper? Where is the issue? If you would write a proper white paper on SW we all can do a nice diff and see that SW is an alt, not the others with just a 2mb change. With SW you softly fork into a softer security model. Your SW coin will be of soft price. Thx Title: Re: Proposal Support Post by: DooMAD on July 07, 2017, 05:48:44 PM Are you brain dead? Something that is privately mined for 72 hours by a single company, then released into the *wild* is NOT Bitcoin. I guess Carlton was right when he questioned (https://bitcointalk.org/index.php?topic=1966169.msg19600656#msg19600656) whether excluding users with low ranks and/or negative feedback would produce the results you would expect or not. I figured we might see a few "prefer"s for EC, but I wasn't really expecting much in the way of Bitmaincoin support. Still, I suppose the community is littered with altcoins that had a significant premine, so I guess some don't feel as strongly about it as others. Title: Re: Proposal Support Post by: Lauda on July 07, 2017, 05:51:02 PM Why? If its due to the SN white paper? Where is the issue? If you think that the definition of Bitcoin is literally only "the longest PoW chain" then you fundamentally understood nothing from the whitepaper. Stop falsely quoting Satoshi.If you would write a proper white paper on SW we all can do a nice diff and see that SW is an alt, not the others with just a 2mb change. You are either ill or a government/corporate/institute/agency paid baboon. Nobody in their right mind could think that a privately mined chain, which alters consensus rules without anyone elsees consent is Bitcoin.With SW you softly fork into a softer security model. Your SW coin will be of soft price. Thx No.I guess Carlton was right when he questioned (https://bitcointalk.org/index.php?topic=1966169.msg19600656#msg19600656) whether excluding users with low ranks and/or negative feedback would produce the results you would expect or not. I figured we might see a few "prefer"s for EC, but I wasn't really expecting much in the way of Bitmaincoin support. I don't mind lowly educated individuals to vote for EC, but BitmainCoin is everything but Bitcoin. Still, I suppose the community is littered with altcoins that had a significant premine, so I guess some don't feel as strongly about it as others. The right wording is "individuals who are solely fueled by greed and do not have/care for any fundamental values". Title: Re: Proposal Support Post by: mindrust on July 07, 2017, 06:17:38 PM This will end up just like I predicted.
2 and maybe even more versions of bitcoin will exist and every bitcoin fork will claim that theirs is the tr00 bitcoin. Well that just has to happen I guess and there is nothing to do to prevent it. The merchants and the community will have different opinions too. Merchant A will say "I only accept bitcoin bipXXX" and Merchant B will say "I only accept 8mb Bitcoin" There will be countless versions of bitcoins. The majority chain won't always get the 100% support. Once we get into the Hard Fork business there will be no end to it. Yes! And they are already among us...! Dozens of them, even hundreds... For years, actually... We call them 'altcoins'... ;) And which bitcoin fork will be "altcoins"? No altcoin ever claimed that it was the real bitcoin. Would you support it if zcash changed its name into bitcoin? Because that's exactly what is going to happen with bitcoin. Bitcoin.org and Bitcoin.com will be promoting completely different blockchains. When somebody goes to an exchange to buy some bitcoins he'll be offered bitcoin bip148, bitcoin unlimited, bitcoin classic, bitcoin bip xxx and so on... And what about the merchants? How the hell people will be able to spend their coins to buy stuff then? Merchants will say "Fuck this shiet i'm out!" Title: Re: Proposal Support Post by: hv_ on July 07, 2017, 07:30:26 PM Why? If its due to the SN white paper? Where is the issue? If you think that the definition of Bitcoin is literally only "the longest PoW chain" then you fundamentally understood nothing from the whitepaper. Stop falsely quoting Satoshi.If you would write a proper white paper on SW we all can do a nice diff and see that SW is an alt, not the others with just a 2mb change. You are either ill or a government/corporate/institute/agency paid baboon. Nobody in their right mind could think that a privately mined chain, which alters consensus rules without anyone elsees consent is Bitcoin.With SW you softly fork into a softer security model. Your SW coin will be of soft price. Thx No.I guess Carlton was right when he questioned (https://bitcointalk.org/index.php?topic=1966169.msg19600656#msg19600656) whether excluding users with low ranks and/or negative feedback would produce the results you would expect or not. I figured we might see a few "prefer"s for EC, but I wasn't really expecting much in the way of Bitmaincoin support. I don't mind lowly educated individuals to vote for EC, but BitmainCoin is everything but Bitcoin. Still, I suppose the community is littered with altcoins that had a significant premine, so I guess some don't feel as strongly about it as others. The right wording is "individuals who are solely fueled by greed and do not have/care for any fundamental values". Sigh.. Ranting, insulting, twisting, BSshilling. Cant fix that. Take Carlton into your SWcoin and fork off. Title: Re: Proposal Support Post by: Lauda on July 08, 2017, 07:35:35 AM This will end up just like I predicted. Neither Jihan nor BU coin are Bitcoin in any way possible. Claiming that they are something which they clearly are not will not work as long as there are a lot of people on the *other side* of things. 2 and maybe even more versions of bitcoin will exist and every bitcoin fork will claim that theirs is the tr00 bitcoin. Well that just has to happen I guess and there is nothing to do to prevent it. Sigh.. Ranting, insulting, twisting, BSshilling. Cant fix that. Take Carlton into your SWcoin and fork off. Bullshit. Read the whitepaper and try to actually understand it, idiot. Title: Re: Proposal Support Post by: Foxpup on July 08, 2017, 08:12:41 AM I suppose I should get in on this, just to show I care.
Code: [tr] Title: Re: Proposal Support Post by: karisiak123 on August 30, 2017, 07:21:08 PM I strongly agree there is a support proposal but I will not know when the proposal will be made ,, hopefully there will be no obstacles.
|