As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features. witness data is transaction info!!!!! to older clients it would appear as screwed up tx's it cant validate.. meaning old clients will fork because they dont see it as valid.. meaning to stay on the network validating transactions (which is what a fullnode should do) they need to upgrade meaning its a damned hard fork!! because not upgrading makes old (true fullnodes) become limp and unsecure!! seriously are you being paid by the guys that want segwit!! Segwit is a feature. It is not forced on everyone. If you do not choose to you can still send and receive regular transactions whose signature data is not segregated. Full nodes continue to validate regular transactions. Upgraded full nodes validate Segwit data Happy? We can't have this conversation if you continue to play stupid. |
|
|
|
Anyhow, probably time to put on a full-node again,
I restarted 24/7 on mine about a month ago, due to the controversy. Currently running Core, but not as support for core dev position. I am _very_ motivated to find an alternative. If only the 'anything but 1MB4EVA stasis' crowd had a single standard to rally around... Do you run yours from your computer at home, or from a vps? I have been meaning to start running one, but I can't run mine from home, and it costs quite a lot for a decent vps that's reliable and has sufficient bandwidth. What's the lowest spec vps that can run a full node, and how much data would it probably use in a month? Home. My entire bitcoin folder tree amounts to less than 64 GiB - or less than USD $10 of disk space. Bandwidth is such that I don't even notice any degradation to other apps. I admit that my ISP is better than many. I've never thought to measure it with any finer resolution than 'computing demands are irrelevant'. Care to share how many peers you're connected to? |
|
|
|
Not true, miners will still push out blocks containing regular transactions which the full nodes who haven't updated can still fully verify.
Segwit does not change the nature of the blocks so as to make it incompatible with older Core versions. That's just plain wrong.
2 merkle tree's instead of one sounds very much like changing the nature of a block making relayed data incompatible with older clients relaying txdata without signatures sounds like making relayed data incompatible with older clients older clients that receives a block(with 1.3mb data(with signatures) will throw up an error older clients that receives a block(with 1.0mb data(no signatures) will throw up an error in both cases they will orphan those blocks and treat them as invalid. which is a fork! as they would only accept standard blocks.. and if you are going to now say that mining pools dont handle blocks differently.. then that means that there will still be a 4000tx per 1mb limit as always and not the 5000tx potential segwit 'promises' the only way segwit can promise more transactions is to change how blocks are created and relayed.. which will affect older clients.. I'd very much like to answer your questions but you are seemingly so confused I really don't know where to start. May I suggest reading the BIP? https://github.com/bitcoin/bips/pull/265You have a fundamental misunderstanding of how it works. As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features. |
|
|
|
accomodating more transactions means upgrading peoples clients to be able to stay part of the network if miners are using segwit.. (meaning its not a soft fork) No. Full nodes who have not updated can still safely use and deal with regular transactions and fully verify every economic activity they are involved with. require no upgrades and its just other people that treat the data differently locally to themselves.. That's exactly what segwit does segwit should not make such change to bitcoin-core.. as making miners change how a block is created and is relayed IS A HARD FORK!!!
Not true, miners will still push out blocks containing regular transactions which the full nodes who haven't updated can still fully verify. Segwit does not change the nature of the blocks so as to make it incompatible with older Core versions. That's just plain wrong. |
|
|
|
segwit is a sham!
the reasons for the 1mb block rule is that nodes hard drives should only grow by 1mb a block..
segwit wants to trick the bitcoin-core (fullnode) code by throwing only 70% of txdata into the 1mb block and putting the other 30% on the side.. but that simply makes fullnodes hard drives 1.3mb growth per block... which invalidates the whole damn point of the 1mb limit in the first place!
if lite clients want only 0.7mb per block by throwing away signatures.. then let them parse and ignore that data when they save the data locally to their lite client hard drives.. because bait and switching data in a full node is just tricking the blocklimit rule... which is implimented to keep hard drive space of full nodes below 1mb..
so it makes no sense to keep the 1mb block limit if hard drive storage increases by 1.3mb a block.. as the only reason for the limit is hard drive space rationing..
segwit just makes no sense in respects to the data structure of splitting the chain for full nodes.. again that all can be done by lite clients without even touching bitcoin-core source code
The point of segwit is not to persist with the 1MB limit but to accomodate more room for transactions without having to do a hard fork and meanwhile solve a plethora of issues with regards to malleability. It doesn't want to trick anyone and you're talking a whole lot of nonsense. It's just a hard fork tho. Srsly. What's the big woop? Have a look at network nodes version distribution? Although knowing you people surely you wouldn't feel bad about leaving a couple of persons behind. |
|
|
|
The point of segwit is not to persist with the 1MB limit but to accomodate more room for transactions without having to do a hard fork and meanwhile solve a plethora of issues with regards to malleability.
It doesn't want to trick anyone and you're talking a whole lot of nonsense.
More lying nonsense from the Blockstream Puppets. The MAIN point of Segwit is to buy time so that Blockstream can gain advantage in it's war for control over the financial institutions.  I mean I understand if you feel alone this Christmas but no need to come and spread your delusions all over the forum. |
|
|
|
segwit is a sham!
the reasons for the 1mb block rule is that nodes hard drives should only grow by 1mb a block..
segwit wants to trick the bitcoin-core (fullnode) code by throwing only 70% of txdata into the 1mb block and putting the other 30% on the side.. but that simply makes fullnodes hard drives 1.3mb growth per block... which invalidates the whole damn point of the 1mb limit in the first place!
if lite clients want only 0.7mb per block by throwing away signatures.. then let them parse and ignore that data when they save the data locally to their lite client hard drives.. because bait and switching data in a full node is just tricking the blocklimit rule... which is implimented to keep hard drive space of full nodes below 1mb..
so it makes no sense to keep the 1mb block limit if hard drive storage increases by 1.3mb a block.. as the only reason for the limit is hard drive space rationing..
segwit just makes no sense in respects to the data structure of splitting the chain for full nodes.. again that all can be done by lite clients without even touching bitcoin-core source code
The point of segwit is not to persist with the 1MB limit but to accomodate more room for transactions without having to do a hard fork and meanwhile solve a plethora of issues with regards to malleability. It doesn't want to trick anyone and you're talking a whole lot of nonsense. |
|
|
|
Nop, that's the urologist   |
|
|
|
ppl who lie and know they've done something wrong tend to hide.
Except sociopath weirdos who've made an habit out of defrauding people, isn't it so Dr. Marc A. Lowe? |
|
|
|
Some people here really couldn't handle being alone by themselves for Christmas  |
|
|
|
afaik segwit, it's only an effective 2mb increase as average with a 4mn as a peak, so it would be pointless to do it after a mini increase like 2mb
segwit is an increase of only 1,75 - 2 MB in the mid term and much more complicated than the 2 MB increase. a 2 MB hard fork (which everyone agrees on and has zero risks / easy to deploy) will at least double the capazity. funny that we are now at 2 MB and not even then some devs like Peter Todd agree on that. i guess when one or two people can veto against the will of 99%, bitcoin is in trouble. actually it seems that segwit is even less, around 1.3, i had a conversation with aguy here saying this https://bitcointalk.org/index.php?topic=1299293.msg13328502#msg13328502Obviously no one knows but 1.3 is pretty conservative. Understand that service providers and wallets responsible for most of the transactions on the network have a strong economic incentive to be proactive and implement SW as soon as possible so it is reasonable to expect SW to be deployed by most major companies quite quickly. |
|
|
|
Selfish, lazy, entitled little sh!ts that believe they get everything handed to them.
Your expecting intelligent conversations yet you propose that the people responsible for most of the Bitcoin code that's been churned out in the last year and a half are lazy. Sigh I guess this is the sort of reactions panic breeds |
|
|
|
Pretty standard code review there brg. I dont know the code intimately, but I reckon there is no more than a few hours to remedy it. You must be getting pretty desperate if you are skulking around in that forum. Maybe that was the smell Gavin was getting? Pretty standard except that it point out flaws in code already used in production I can only imagine how disappointed you were when your employer told you you had to shill for a bunch of amateur charlatans |
|
|
|
The author is Jonathan Toomim. Why are you confused?  You first linked a statement supposedly from representative of BTCC that was reported by Toomim. I pointed out to you that these statements had been made absent of clear consideration of the SW proposal. See the twitter link I posted? Now you reply with a completely different post from Toomim that is completely irrelevant so really I'm not sure why you think I'm the one who's confused. |
|
|
|
You specifically are one of the reasons Bitcoin is stagnating, and in jeopardy of dying at some point, or becoming irrelevant.
I know I hurt some feelings everytime you shills need to resort to FUD to emphasize your arguments |
|
|
|
Huh? The author in question was reporting hearsays from discussion w/ some people from BTCC and is not representing BTCC himself. |
|
|
|
That is a late comment that was retracted after announcement of the Seg Wit proposal. Nice try though. This was literally 2 days ago. Try 3 weeks ago https://twitter.com/Excellion/status/674834690377842691And consider this from the post you linked: I generally did not bring up SegWit during the conversations I had with miners, and neither did the miners, so it is also absent. (I thought that it was too early for miners to have an informed opinion of SegWit's relative merits.) |
|
|
|
core block size limit should be made dynamic, put in the realm of software, outside of human hands This might be the single most obvious statement ever and Blockstreamers aren't buyin' it. Not that it really matters but the only one who's put forward any kind of sensible dynamic cap proposal is a guy from Blockstream so as usual you don't know wtf you're talking about. |
|
|
|
That is a late comment that was retracted after announcement of the Seg Wit proposal. Nice try though. |
|
|
|
|
Show Posts
