Topic: Post your SegWit questions here - open discussion - big week for Bitcoin! - page 11. (Read 84845 times)
July 20, 2017, 04:52:12 AM
If BTC split wont happen what will the new update(BIP 91) be good for?
July 20, 2017, 01:05:30 AM
is there an official link to the BIP 91 and BIP148 UASF on here? Im curious if its really going to get locked in this week and we can finally moon....
I'm not sure what you mean, exactly; however, some folks are watching the closeness of the BIP91 locking in on these two websites.
https://coin.dance/blocks
https://www.xbt.eu/
July 20, 2017, 12:07:19 AM
is there an official link to the BIP 91 and BIP148 UASF on here? Im curious if its really going to get locked in this week and we can finally moon....
I'm not sure what you mean, exactly; however, some folks are watching the closeness of the BIP91 locking in on these two websites.
https://coin.dance/blocks
https://www.xbt.eu/
July 20, 2017, 12:01:48 AM
is there an official link to the BIP 91 and BIP148 UASF on here? Im curious if its really going to get locked in this week and we can finally moon....
July 09, 2017, 01:33:25 PM
I tweeted to Charlie today about what the best thing an individual can do to support Segwit was and he replied with convincing exchanges to run UASF code. That seems valid but are there other things that people can do? Asking for myself and anyone who is new to bitcoin.
BTC
BTC 
July 06, 2017, 07:56:20 AM
Thx - guess these guys have shown their Rust power the day before Peter...
why is this not taken up here?
Because it's FUD. In the German Forum a technically much more advanced user than me has explained it in a convincing way. The miners that would participate in such an attack would simply fork away because exchanges and other economic actors would never accept their blocks.
July 03, 2017, 10:13:58 AM
Thx - guess these guys have shown their Rust power the day before Peter...
why is this not taken up here?
July 03, 2017, 09:56:03 AM
According to Peter Rizun@ conf The Fututre of Bitcoin / Arnhem 1th July 2017
due to the SW - SF and potential fractional network there is an attack vector for selfish miners to hold back the initial small SW - witness data relatively easy and get into a potential success on a late but fast release to the network once they expect a next block coming up.
Could you pls comment on that or point me to some place where this was discussed or solved? How do you weight this impact?
due to the SW - SF and potential fractional network there is an attack vector for selfish miners to hold back the initial small SW - witness data relatively easy and get into a potential success on a late but fast release to the network once they expect a next block coming up.
Could you pls comment on that or point me to some place where this was discussed or solved? How do you weight this impact?
June 02, 2017, 05:09:44 AM
There were 2 hard forks, one unintentional fork due to a database locking bug, and a second intentional hard fork to fix the bug. Everyone worked together, and the drama was over in 48 hours. A few old servers continued running the broken release, but they were ignored and caused no problems on the network. Don't believe me, read the official Core account of what happened: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
The drama most certainly was not over in 48 hours. The intentional hard fork to fix the problem took until August 2013 while the unintentional one occurred several months before that in March 2013. Up until Autust, everyone was still using the consensus rules forced by the database locks. Even in the emergency situation, a hard fork still took several months to actually deploy. We aren't in such a situation now; a hard fork will need to take longer to deploy so that all of its consequences can be considered and tested.In 48 hours the the newer chain dominated the network and the chain split was resolved. There was a single double spend, but the person who did it returned the funds and stated that he was just a researcher.
There are still upwards of 20,000 lines of code in support software that still haven't been written. Another reason Segwit is simply dead in the water.
Just because what seems like a large number of lines of code have yet to be written does not mean that it is "dead in the water". More than half of the companies, services, and wallets listed on the segwit adoption page have already completed their implementations.In any case, Segwit software support is not ready at all. In fact, the coders are waiting on Segwit activation that likely will never happen... why waste time if the code won't be used? I also feel sorry that C0re wasted so much time developing code that won't run. An old wooden "Spruce Goose" that will not fly.
June 01, 2017, 05:07:45 PM
There were 2 hard forks, one unintentional fork due to a database locking bug, and a second intentional hard fork to fix the bug. Everyone worked together, and the drama was over in 48 hours. A few old servers continued running the broken release, but they were ignored and caused no problems on the network. Don't believe me, read the official Core account of what happened: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
The drama most certainly was not over in 48 hours. The intentional hard fork to fix the problem took until August 2013 while the unintentional one occurred several months before that in March 2013. Up until Autust, everyone was still using the consensus rules forced by the database locks. Even in the emergency situation, a hard fork still took several months to actually deploy. We aren't in such a situation now; a hard fork will need to take longer to deploy so that all of its consequences can be considered and tested.There are still upwards of 20,000 lines of code in support software that still haven't been written. Another reason Segwit is simply dead in the water.
Just because what seems like a large number of lines of code have yet to be written does not mean that it is "dead in the water". More than half of the companies, services, and wallets listed on the segwit adoption page have already completed their implementations. June 01, 2017, 02:49:54 PM
The 2013 a bitcoin hard fork was accomplished in less than 48 hours.
Actually, it was not.First of all, the hard fork was entirely unintentional. Secondly, deploying the final change that actually changed the consensus rules still took ~6 months before the situation was considered completely resolved with a block that would have been invalid under the old rules being mined and accepted by the network. The first chain split happened around the end of March. The block that marked the issue as resolved (since it would have been invalid to older clients) was mined in August (block 0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) ~6 months after the initial chain split.
There were 2 hard forks, one unintentional fork due to a database locking bug, and a second intentional hard fork to fix the bug. Everyone worked together, and the drama was over in 48 hours. A few old servers continued running the broken release, but they were ignored and caused no problems on the network. Don't believe me, read the official Core account of what happened: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
Segwit is hugely complicated, and as a result has been sitting around incomplete for almost a year.
Segwit is absolutely complete. It is not activated yet, but the code is absolutely complete and those clients which are supporting it have long since completed their implementations and testing of it. In fact, part of the reason it's start date was delayed was because other wallet developers will still implementing it and testing it and wanted segwit to be done by the time the activation period started.Funny, that's not what the official Core Segwit support page says: https://bitcoincore.org/en/segwit_adoption/
There are still upwards of 20,000 lines of code in support software that still haven't been written. Another reason Segwit is simply dead in the water.
Hard forks happen all of the time on production blockchains without incident. For example, Monero ($600 mil market cap) has hard forked 4 times in the past year.
But no altcoin has the same environment as Bitcoin. None have the same market cap, visibility, number of users, trade volume, etc. No altcoin is comparable to the Bitcoin and cannot serve as accurate measures as to how successfully a hard fork on Bitcoin would be.[/quote]
Ahh, the "not a true Scotsman" fallacy, yet again. Actually, Ethereum DOES have a comparable market cap to Bitcoin, and it DID have a hard fork AND a chain split. And they're going strong (much to my chagrin).
Simple facts are:
* Bitcoin and other cryptos have hard forked hundreds of times without issue.
* The proposed Segwit soft fork, whether sound or not, has failed
* The only hard fork that resulted in a split was Ethereum, because the devs rolled back the chain and restored stolen DAO coins, in direct violation of the consensus rules.
May 31, 2017, 08:19:39 PM
Absolute bollocks.
Actually your post is absolute bollocks.The 2013 a bitcoin hard fork was accomplished in less than 48 hours.
Actually, it was not.First of all, the hard fork was entirely unintentional. Secondly, deploying the final change that actually changed the consensus rules still took ~6 months before the situation was considered completely resolved with a block that would have been invalid under the old rules being mined and accepted by the network. The first chain split happened around the end of March. The block that marked the issue as resolved (since it would have been invalid to older clients) was mined in August (block 0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) ~6 months after the initial chain split.
Segwit is hugely complicated, and as a result has been sitting around incomplete for almost a year.
Segwit is absolutely complete. It is not activated yet, but the code is absolutely complete and those clients which are supporting it have long since completed their implementations and testing of it. In fact, part of the reason it's start date was delayed was because other wallet developers will still implementing it and testing it and wanted segwit to be done by the time the activation period started.Furthermore, Segwit changes almost 6000 lines of code versus one line for a 2MB hard fork.
You are comparing apples to oranges here. The segwit changes includes tests and deployment. Your one line of change for a 2MB hard fork contains no tests and no safe deployment parameters. IIRC if you add in the necessary tests, deployment logic, and other necessary parameter changes to make it deploy safely (as with Bitcoin Classic), then you end up with ~2000 lines of code changed.Hard forks happen all of the time on production blockchains without incident. For example, Monero ($600 mil market cap) has hard forked 4 times in the past year.
But no altcoin has the same environment as Bitcoin. None have the same market cap, visibility, number of users, trade volume, etc. No altcoin is comparable to the Bitcoin and cannot serve as accurate measures as to how successfully a hard fork on Bitcoin would be. May 31, 2017, 04:21:35 PM
I find it very hard to believe that implementing Segwit support in existing software will be easier than a 2MB hard fork, please cite a source for this.
It isn't that it is easier to implement but rather it is easier to deploy segwit than it is to deploy a 2 MB hard fork. In general, soft forks are easier to deploy as less people are required to upgrade and those that do not upgrade won't be kicked off of the network. OTOH, a hard fork requires everyone to upgrade in order for them to not be kicked off of the network. Having everyone upgrade is significantly harder than getting most of the miners and some users to upgrade.Absolute bollocks. The 2013 a bitcoin hard fork was accomplished in less than 48 hours. Segwit is hugely complicated, and as a result has been sitting around incomplete for almost a year. Even on Litecoin, with lower activation threshold, Segwit took several months and much cajoling to activate.
Furthermore, Segwit changes almost 6000 lines of code versus one line for a 2MB hard fork.
Viitalik Buterin, well-respected creator of Ethereum, says that soft forks are more coercive than hard forks:
http://vitalik.ca/general/2017/03/14/forks_and_markets.html
Hard forks happen all of the time on production blockchains without incident. For example, Monero ($600 mil market cap) has hard forked 4 times in the past year.
May 31, 2017, 10:27:03 AM
I find it very hard to believe that implementing Segwit support in existing software will be easier than a 2MB hard fork, please cite a source for this.
It isn't that it is easier to implement but rather it is easier to deploy segwit than it is to deploy a 2 MB hard fork. In general, soft forks are easier to deploy as less people are required to upgrade and those that do not upgrade won't be kicked off of the network. OTOH, a hard fork requires everyone to upgrade in order for them to not be kicked off of the network. Having everyone upgrade is significantly harder than getting most of the miners and some users to upgrade. May 31, 2017, 05:19:14 AM
I find it very hard to believe that implementing Segwit support in existing software will be easier than a 2MB hard fork, please cite a source for this.
May 30, 2017, 08:53:36 PM
What I don't understand is that if soft-forks are backward compatible why would other miners reject it? Doesn't backward compatibility mean that new blocks are seen as valid by old clients?
There are more things to consider than just whether the blocks that are produced will be valid. There are other concerns too. For example, segwit will likely reduce transaction fees. Thus a miner will be opposed to segwit since they will make less money in the short term if it activates. But at the same time, activating segwit can also earn them more money in the long term.And if you wait everyone to update what is the benefit for soft-fork?
Soft forks only require miners upgrade. It means that soft forks are more likely to successfully activate as less people need to upgrade and that those who don't upgrade won't be kicked off of the network. The reason most miners need to upgrade is so that chain splits do not happen if a block that is invalid under the new rules is mined.Is there a con of Hard-Fork if it has 95% support?
The remaining 5% could, in theory, maintain a separate blockchain but uses the same blockchain parameters as the main blockchain but with different consensus rules. Also, keep in mind that with a hard fork, basically everyone (miners and users) need to upgrade whilst with a soft fork, only the miners really need to upgrade. May 30, 2017, 01:13:36 PM
What I don't understand is that if soft-forks are backward compatible why would other miners reject it? Doesn't backward compatibility mean that new blocks are seen as valid by old clients? And if you wait everyone to update what is the benefit for soft-fork? Is there a con of Hard-Fork if it has 95% support?
May 26, 2017, 12:37:13 PM
I have read some article/discussion about SegWit, but i'm not sure about few things so i better ask it,
1. Is transaction size in SegWit always smaller or only smaller in certain condition?
2. Can we force UASF/MASF (and/or block split) even with less 95% miners approval?
3. Do you think Zero Confirmation will be possible after SegWit upgrade? Most likely no, but i want opinion from other users.
1. Is transaction size in SegWit always smaller or only smaller in certain condition?
2. Can we force UASF/MASF (and/or block split) even with less 95% miners approval?
3. Do you think Zero Confirmation will be possible after SegWit upgrade? Most likely no, but i want opinion from other users.
May 26, 2017, 09:30:25 PM
Any fork will maintain the blockchain prior to the fork, so any coins from before the fork will always exist on the two blockchains created by a fork.
How a fork will affect the value of a coin cannot be known.
How a fork will affect the value of a coin cannot be known.
Jump to: