I do not feel like upgrading my core wallet.

[spazzdla]

consequences?

[franky1]

your not a full validating node. and become reliant on the nodes connecting to you to validate a block before data even gets to you for you to be more sure it doesnt have iffy data or a badly constructed segwit transaction that would normally lead to it getting orphaned out. (still not perfect)

at 95% there is a 5% chance of orphaning. far greater than the usual 1-2% we see each day for the last ~8 years

if you are directly connected to a pool and cannot validate or invalidate a segwit transaction. you will blindly deem it ok and relay it on to your peers. which can lead to lot of nodes receiving data they are not suppose to get.

major downside is if the relayed block u get is from a legacy(old node) and that has a connection from a legacy node too.. all the way back to a legacy pool.. they all of you will get a potentially bad block if someone made a dodgy tx.

id suggest that you dont be directly connected to a pool but be a few hops(node connections) away so that they can do the orphaning of bad blocks. and also probably best to wait an extra couple of confirmations to be sure the network as a whole have deemed it ok

this is especially the case if you are handling alot of customer transactions where they are placing their trust in you.

[achow101]

consequences?

You'll miss out on some optimizations and improvements added since whatever version you are running. Once segwit activates, you will not be able to take advantage of it, and you will not be fully validating segwit transactions (but you will still be validating them and all other transactions).

You'll also see an annoying alert about how some unknown rules have activated and that you should upgrade.

If you run a version of Bitcoin Core earlier than 0.12.1, you'll see an alert about the alert system retirement. After 0.14 comes out, that message will change to "Alert key compromised"

[unamis76]

After 0.14 comes out, that message will change to "Alert key compromised"

So will the keys change hands? Or the failsafe code will be executed (if so, why)?

EDIT: Now I see, I guess it's because of this that the message will be displayed.

[clickerz]

Re: I do not feel like upgrading my core wallet.

I feel the same and I want to observe first the feedback from forums of other users who upgrade their core wallet. I am sure there are feedback. If there are good feedback then I think it is time to do the same.

[CraigWrightBTC]

Well because of i am not miner bitcoin, i think i don't too need upgrade my core wallets and i am just a traders everything about technically of bitcoins depend on my exchangers. What will do with my wallet on markets.

[franky1]

you will not be fully validating segwit transactions (but you will still be blindly accepting them while validating all other traditional transactions).

edited other post to be more upfront and avoid the contradiction which leads to misinterpretation

[achow101]

you will not be fully validating segwit transactions (but you will still be blindly accepting them while validating all other traditional transactions).

edited other post to be more upfront and avoid the contradiction which leads to misinterpretation

They are still validating them as best as they can. It is not just blindly accepting them, the only blind acceptance part is of the signatures for segwit inputs, but the transaction is still being validated. It still has to check that the inputs are spending non-spent outputs. It still has to check the locktime. It still checks inputs that are not segwit inputs. It still runs the script validation for the segwit input, but it simply does not know of the signatures for those inputs.

[BitcoinBarrel]

I haven't upgraded in YEARS lol

[unamis76]

I haven't upgraded in YEARS lol

Now's a good time to do it

Folks are finally getting more and more up to date, from what I can see on bitnodes...

[franky1]

you will not be fully validating segwit transactions (but you will still be blindly accepting them while validating all other traditional transactions).

edited other post to be more upfront and avoid the contradiction which leads to misinterpretation

They are still validating them as best as they can. It is not just blindly accepting them, the only blind acceptance part is of the signatures for segwit inputs, but the transaction is still being validated. but it simply does not know of the signatures for those inputs.

seriously??

her goes i can grab your address of funds you have not spend. and not sign it.. and push it through a malicious pool i bribe to add in the transaction knowing that 3000 nodes will not be asked to check for a signature anyways.
so the block (containing the tx) gets relayed around the majority of the nodes. BLINDLY

however 3000 nodes have to wait and "trust" segwit nodes that have seen the signature to validate it on your behalf. for you to blindly ACCEPT IT

if a node is not validating a transaction signature itself then the node is not validating the transaction. it is BLINDLY ACCEPTING it and trusting that its valid by the hopes of previous nodes doing the job for them.

i feel sorry for you trying to twist things to hide a problem by brushing it under the carpet rather then being brutally honest so people are aware of risks and be fully informed.

yes in 95%+ of cases this problem is not a worry. BUT if there was an issue, old nodes would still accept it blindly.

as i said best to wait an extra few confirmations to 'trust' that somewhere in the 5000+ nodes there are enough segwit nodes to orphan out malicious data to then "trust" that it must be second-party-valid(not by own checks) based on the network agreement of it not appearing to have orphaned out.

the only way old nodes know its a malicious tx is if the block orphans out. so you have to wait a few extra confirmations to gain "trust".

in short OLD NODES should if they originally waited 1confirm due to a 1% orphan risk, wait 5 confirms for the 5% orphan risk

atleast be brutally honest and stop shining the shoes of core devs.

[spazzdla]

Well that doesn't sound very good...

[achow101]

seriously??

her goes i can grab your address of funds you have not spend.

You cannot do this with any address. You can only do that with a segwit output type which does not have any address type associated with it.

Addresses for segwit will actually be P2SH addresses with the segwit script being the redeemscript of that p2sh address. Thus you cannot execute this attack with most segwit stuff since they will be protected by the Hash160.

and not sign it.. and push it through a malicious pool i bribe to add in the transaction knowing that 3000 nodes will not be asked to check for a signature anyways.
so the block (containing the tx) gets relayed around the majority of the nodes. BLINDLY

however 3000 nodes have to wait and "trust" segwit nodes that have seen the signature to validate it on your behalf. for you to blindly ACCEPT IT

if a node is not validating a transaction signature itself then the node is not validating the transaction. it is BLINDLY ACCEPTING it and trusting that its valid by the hopes of previous nodes doing the job for them.

It is still checking other parts of the transaction for validity. Signatures are not the only thing to check for when checking validity of a transaction. The fact that it still checks validity as best as it can means that it is not just blindy accepting the transaction. Blindly accepting would be accepting a transaction regardless, even if it is invalid in some other way than just signatures, i.e. included in block but locktime has not passed yet.

[franky1]

It is still checking other parts of the transaction for validity. Signatures are not the only thing to check for when checking validity of a transaction. The fact that it still checks validity as best as it can means that it is not just blindy accepting the transaction. Blindly accepting would be accepting a transaction regardless, even if it is invalid in some other way than just signatures, i.e. included in block but locktime has not passed yet.

seriously, again?
if you cannot verify the signature then you cannot validate the funds should be moved.
acceptance is different then validating it.

EG
someone writes out a cheque.  no signature seems to be present (wrote in vinsible ink).. "hey bank will you cash this while i stand here."
"well i can see that the amount is wrote correctly, i can see that the funds are going somewhere.. i dont see a signature.. but the date looks good enough..screw it lets cash that cheque. dont worry if it bounces later, its just a double spend"

above scenario is baddddd

hello wake up..
yes the network of segwit banks will validate the cheque because they have the special UV light to see the invisible ink signature. but the old fashioned bank should not cash the cheque. they should pass it on to the network of clearing houses and then the customer has to wait for a few days in the hope the other banks can validate it. for the bank to then cash it

again. if your not up to date, dont accept a tx in a block at just 1 confirm, let the block relay around the network and wait to see if other nodes throw out the block for having a dodgy tx. and then be satisfied it is TRUSTED to be settled by others doing the validation

i feel sorry for anyone to say. go ahead risk a double spend simply because the locktime date looks legit..

seriously stop shoe shining the devs and start being honest to the community.
are you that desperate to appease the devs due to probably wanting to get a salary??

seriously prioritise the community first

[achow101]

sriously, again?
if you cannot verify the signature then you cannot validate the funds should be moved. thus it dosnt matter whats contained in a transaction..

Seriously, again?

As I said before, the signatures are not everything that need to be checked for the validity of the transaction. The other data that the transaction contains do matter, not just the signatures. What part of that do you not understand? There are more to transactions than just a signature.

seriously stop shoe shining the devs and start being honest to the community.
are you that desperate to appease the devs due to probably wanting to get a salary??

seriously prioritise the community first

Why do you feel it necessary to include this at the bottom of every single response to me? I have not stated anything that is factually incorrect. If you look at the code (which I highly doubt you have) then you will see that everything I say is factually correct. And yet nearly everything you say has some false statement in it. I am not "shoe shining the devs", I am stating exactly what happens as specified by the code, you are not.

I am prioritising the community first by trying to help stop the spread of misinformation from people like you.

[crazyivan]

What is the problem? As soon as you have adequate backup, you ll be safe. So no worries and always keep your software updated.

[franky1]

I am prioritising the community first by trying to help stop the spread of misinformation from people like you.

ok lets break it down to a community helpful question

should old legacy clients trust a 1 confirm segwit tx.. i mean 100%.
please before putting the shoe shinner hat on.. think about the larger orphan risk.

again
should old legacy clients trust a 1 confirm segwit tx.. i mean 100%.

[achow101]

ok lets break it down to a community helpful question

should old legacy clients trust a 1 confirm segwit tx.. i mean 100%.
please before putting the shoe shinner hat on.. think about the larger orphan risk.

again
should old legacy clients trust a 1 confirm segwit tx.. i mean 100%.

IMO yes. I do not think that there is a larger orphan risk. Most miners are already following the standardness rules. If they do not upgrade but continue to follow the already existing standardness rules then their blocks will not be orphaned.

[franky1]

IMO yes. I do not think that there is a larger orphan risk. Most miners are already following the standardness rules. If they do not upgrade but continue to follow the already existing standardness rules then their blocks will not be orphaned.

OMG
all your IF if if.
your not thinking about risk your thinking of shying away from risks with 'if' statements
you are not even considering malicious intent to double spend.
instead your saying if there is no double spend then you can accept a tx with 1 confirm

hellloo... wakey wakey
you need to wait out more then one confirm to ensure there is no ifs, buts or maybes

seriously wake up

[achow101]

OMG
all your IF if if.
your not thinking about risk your thinking of shying away from risks with 'if' statements
you are not even considering malicious intent to double spend.
instead your saying if there is no double spend then you can accept a tx with 1 confirm

Are you ignorant, blind, terrible at reading comprehension, or all of the above?

The only IF that I said is IF A MINER DOES NOT UPGRADE. How about this, it means exactly the same thing: Miners who do not upgrade and continue to operate as they do now will not have their blocks orphaned by those who do upgrade.