NOT Upgrading to SegWit who's with me?!

[franky1]

SegWit solve malleability hole and double-spend.
Block Inflate don't solve this ... AT ALL.

lol
1. the double spend issue is still a problem RBF, CPFP, CSV and others still make it possible to bait someone with one tx, but have it not confirm due to another tx confirming that goes to another destination.

2. even the glossy roadmap explains the problem and hints to the solution. 'this caused accounting issues by services that only verify by TXID'
merchants should fully check the tx and wait for a confirm.

3. block inflate.. oooh so ur against blocks being above 0.1mb in 2009, 0.3mb in 2012 0.5mb in 2013 0.7mb in 2014. 0.9mb in 2015..
do you even grasp code/logic/understanding of how bitcoin works, it seems not. or are you just spitting out the same script as blockstream fanatics, like some christmas carol singers

3. as for LN
did you know it requires dual signatures..
meaning the tx is only valid if both sides sign the same thing. meaning a malicious party cannot then create a second malleated tx because the second party would be needed. and that second party wont sign something with obvious changes. thus it wont even be accepted into pools with only one signature.
the truth is LN solves malleability, not the other way round. by dual signing only one correct tx is acceptable thus malleability is not even a process that could be used within LN even if it wasnt fixed

[1714641128]

1714641128

[1714641128]

1714641128

[CoinCidental]

I also will NOt be upgrading to SEGWIT in its current form ...

If segwit came with a dynamic blocksize it would be a more appropriate solution
but a segwit we have no choice but rather forced upon us is not equivalent to the product of a free market

[BitHodler]

I personally haven't upgraded my Core client to the .13 version yet, but that's mostly due to the fact that I haven't taken any effort to do so.

Another factor that is part to me not having updated yet, is that people complain about the notifications that pop up when you receive transactions. They are gone.

I am however not sure if the notifications are put back in place with the .13.1 update. Would be nice to hear someone confirm that as I don't want to miss this feature.

[franky1]

I personally haven't upgraded my Core client to the .13 version yet, but that's mostly due to the fact that I haven't taken any effort to do so.

Another factor that is part to me not having updated yet, is that people complain about the notifications that pop up when you receive transactions. They are gone.

I am however not sure if the notifications are put back in place with the .13.1 update. Would be nice to hear someone confirm that as I don't want to miss this feature.

the human broadcasted alerts have gone and wont return.
but your node whether its super old or even latest will still alert you when your node itself cannot verify block/tx data

in short dont expect a message from a person telling you of issues.(as this has changed)
 but instead rely on your node doing its own independant checks/validation and alert you if there was a problem(this has not changed)

[Meuh6879]

lol
1. the double spend issue is still a problem

2. even the glossy roadmap explains the problem

3. block inflate.. oooh so ur against blocks being above 0.1mb in 2009, 0.3mb in 2012 0.5mb in 2013 0.7mb in 2014. 0.9mb in 2015..

4. as for LN
did you know it requires dual signatures..

1) In the ACTUAL network (mainnet) yes ... not in the TestNet SegWit.

2) You use the merchand problem, ok ... merchant MUST upgrade when SegWit is Enforced = problem solve.

3) Block Inflate want 8Mb permanently. You don't host a FULL node, yeah ... ? That's why you don't understand the decentralized manner of store the information and segregate this information for the storage.

4) And ?
LN is supported by the server in an offchain server ... not a problem.
Only benefic for HACKED exchanges (example, but plastic card is the next challenger for NFC/RFID Hack proximity sniffing).

[spartacusrex]

@OP - Can you come up with a FIX for txn malleability (the root of MANY issues) ? If you can, I'm all ears.

transaction malleability..

what does it solve. you show me what you think it solves and i can easily counter it with how that is an over hyped exaggeration used to push bitcoin in one direction that does not really give us any more expectations than the 'possibles' of 2009-2013

..eh ?

You such a 'hater' lately - Frank. 

Was the $1 billion dollars stolen from MtGOX an 'over hyped exaggeration' ?

I know - sloppy code. Well - what if every other exchange out there, (with BUCKETS of code complicating things trying to get around txn malleability), could now NOT worry about that issue, and simplify their withdrawal process by a factor of, I dunno, 100 ? Pretty useful if you ask me. (And I actually write code for an exchange)

..I could go on.. (there's almost too much).. but I know you're going to lay into this post whatever I say.. 

[European Central Bank]

I don't understand enough to pass a judgement. I am very curious to see what it looks like. Sounds like an alt such as lite coin may implement it first which should clear up a lot of shit talking, or confirm it.

[Kprawn]

That is the beauty of this technology, majority rules and everyone has a choice. If you do not want to switch, then that would be your choice.

We will soon see if other people agree with you, and if LiteCoin will test it successfully. You got to luv the ingenuity of this experiment. 

How hard can it be to implement something else that address the major issues and exclude preparation for LN and still upgrade the block

size?   

[CoinCidental]

@OP - Can you come up with a FIX for txn malleability (the root of MANY issues) ? If you can, I'm all ears.

transaction malleability..

what does it solve. you show me what you think it solves and i can easily counter it with how that is an over hyped exaggeration used to push bitcoin in one direction that does not really give us any more expectations than the 'possibles' of 2009-2013

..eh ?

You such a 'hater' lately - Frank. 

Was the $1 billion dollars stolen from MtGOX an 'over hyped exaggeration' ?

I know - sloppy code. Well - what if every other exchange out there, (with BUCKETS of code complicating things trying to get around txn malleability), could now NOT worry about that issue, and simplify their withdrawal process by a factor of, I dunno, 100 ? Pretty useful if you ask me. (And I actually write code for an exchange)

..I could go on.. (there's almost too much).. but I know you're going to lay into this post whatever I say.. 

karpeles robbed mt gox blind
tx malleability was a convenient excuse but if it ws that big of a problem ,it would have affected every player in the industry ,not only gox lol

[calkob]

Or at least until Satoshi makes a public statement about it. 

Nope,,,,,, your on your own 

[calkob]

SegWit is not Bitcoin.  SegWit is an altcoin being pushed by Blockstream/Core.  

Do not do the upgrade.

It is not in fact 'network inconsistent'.  SegWit is inconsistent with Bitcoin.  The provided warning is a total lie/sham.  They are propagating that warning to trick people into supporting something that is plainly not Bitcoin. 

Bitcoin is what the majority of the community say it is.......... simple

[TKeenan]

SegWit is not Bitcoin.  SegWit is an altcoin being pushed by Blockstream/Core.  

Do not do the upgrade.

It is not in fact 'network inconsistent'.  SegWit is inconsistent with Bitcoin.  The provided warning is a total lie/sham.  They are propagating that warning to trick people into supporting something that is plainly not Bitcoin. 

Bitcoin is what the majority of the community say it is.......... simple

'Bitcoin Protocol Consensus' has been arbitrarily defined by Greg Maxwell as 95%. 
'majority' is merely 51% 

So which is it? 

[pereira4]

Only idiots that don't understand technology want to block segwit. Andreas Antonopoulos has advice several times to activate segwit before we try to raise the blocksize, because it's a mistake and brings up many new vectors of attack.

Segwit first, blocksize increase later. If there is no segwit, blocksize will stay 1MB forever, so your choice.

[ebliever]

I don't see any basis for opposition to Segwit from this thread. The allegation is made that allowing Segwit will open the door to Blockstream (or whomever) creating off-chain payment channels that they can earn a profit on. Well, so what? If they succeed with the LN, sidechains, or whatever, is there anything in SegWit or anything else being discussed that will FORCE me to use their off-chain payment channel? Looks like the answer is no, so I can just choose to keep making on-chain transfers.

In other words, people seem to be afraid of increased choice, with no loss of the current option of doing on-chain TX. Does that make any sense?

[gmaxwell]

The amount of uncorrected lies in this thread is really absurd.

Segwit doesn't have anything to do with lightning. Lightning is already possible without it and can't be blocked. So if you're against having actual scalablity in Bitcoin: well too bad and fuck you: you already lost the day Satoshi released the software.  Similar, sidechains at least of the federated type are existing, unblockable, and undetectable.  If you want to force other people to not use them? Again too bad. You can't.


BitcoinBarrel, the notice in your software has nothing to do with segwit.  You're inconsistent with the network because you're not even running something that implements CSV.  You should at least run 0.13.0; if you do you won't get a notice until segwit activates.

Another factor that is part to me not having updated yet, is that people complain about the notifications that pop up when you receive transactions. They are gone.

I am not aware of any change here, have you opened an issue? https://github.com/bitcoin/bitcoin/issues/

[CoinCidental]

I don't see any basis for opposition to Segwit from this thread. The allegation is made that allowing Segwit will open the door to Blockstream (or whomever) creating off-chain payment channels that they can earn a profit on. Well, so what? If they succeed with the LN, sidechains, or whatever, is there anything in SegWit or anything else being discussed that will FORCE me to use their off-chain payment channel? Looks like the answer is no, so I can just choose to keep making on-chain transfers.

In other words, people seem to be afraid of increased choice, with no loss of the current option of doing on-chain TX. Does that make any sense?

youre ignoring the basics here
if the block stays at 1MB everyone will be shoehorned onto LN whether they want to be or not
the space in the 1mb block will become so expensive that only businesses like coinbase etc can afford to use it

if we had dynamic blocks + LN at least there would be some choice ,if LN is cheaper ,faster and better everyone will use it anyway so why the need to force them ?

[franky1]

1) In the ACTUAL network (mainnet) yes ... not in the TestNet SegWit.

2) You use the merchand problem, ok ... merchant MUST upgrade when SegWit is Enforced = problem solve.

3) Block Inflate want 8Mb permanently. You don't host a FULL node, yeah ... ? That's why you don't understand the decentralized manner of store the information and segregate this information for the storage.

4) And ?
LN is supported by the server in an offchain server ... not a problem.
Only benefic for HACKED exchanges (example, but plastic card is the next challenger for NFC/RFID Hack proximity sniffing).

i have recieved many attempts of malleability in the past.. but guess what. i reject them, i never been a victim of malleability because i know what to look for.
however things like RBF, CPFP CSV open up a new can of worms.. the funny part is you snipped off that part because you fear talking about it to realise im right. double spends have not been fixed for those too lame to do proper checks.

if you think double spends have been fixed. your in for a rude awakening.

block inflate??, 8mb... um.. no.. the consensus round tables and multiple debates have settled and compromised to a 2mb base 4mb weight.
i think you need to call your cries a 'block exaggeration'.. because its only you inflating the numbers of the real debate
wake up to reality and learn whats real.

..eh ?

You such a 'hater' lately - Frank.  

im a realist.
RBF CPFP CSV... learn it.

yes they take away malleability as a way to double spend.. but then open up and give the world atleast 3 NEW ways to double spend. meaning double spend is not solved.

much like someone changing the locks on the front door of your house to avoid you getting robbed but then taking away the lock on the back door.. leaving a window open that cant be locked and leaving the garage door without a lock. all of which used to be secure

no point circle jerking to people that already know bitcoin by using fake adverts that bitcoin is utopia.. when bitcoin still has issues. people should be aware of the issues so that they can do some proper checks on the data they handle. rather then stick head in the sand, ass in the air shouting thank you core now take me up the rear.

[Meuh6879]

i reject them, i never been a victim of malleability because i know what to look for.

Yes, good for you.
But in a network view ... this BUG is NOT acceptable.

network MUST refuse to transfer in mempool a wrongly connected transaction to "in-instant" other transaction in mempool.

lucky for all, SPV don't have mempool.
only miner ... and nodes.

that's why we MUST delete this BUG before open the SPV feature in the nodes (and miners).
that's why LN will be not deploy before SegWit.

LN don't work with malleability BUG in action.
LN must have access to mempool and be sure to not cross malleability transaction.

if you believe that you can emit double-spend in a (enforced) segwit network, you dream in color ... litterally.
https://bitcoincore.org/en/segwit_wallet_dev/

[Meuh6879]

i think you need to call your cries a 'block exaggeration'.. because its only you inflating the numbers of the real debate
wake up to reality and learn whats real.

I'm really award of a congestion scenario ... and Block Inflate is NOT a spam protection.
If you want block Inflate, run 100 nodes ... and deal with this after 3 months.

[franky1]

i think you need to call your cries a 'block exaggeration'.. because its only you inflating the numbers of the real debate
wake up to reality and learn whats real.

I'm really award of a congestion scenario ... and Block Inflate is NOT a spam protection.
If you want block Inflate, run 100 nodes ... and deal with this after 3 months.

lol you are really scraping the bottom of the barrel.
the funny thing is
2mb base 4mb weight.
or
1mb base 4mb weight.

amount to the SAME maximum bloat potential either way, for CONFIRMED BLOCKS (not in mempool anymore)

allowing more tx's into a block, does not actually cause mempools to get flooded. quite the opposite

this 4mb max is also on the contingent that EVERYONE uses segwit to achieve the 4mb max. or we will see a more realistic well under 2mb expectation within under 3 months time frame you gave.
after all when any scalability is activated. it takes time for nodes to use the feature and takes time for pools to test the water at 1.001mb for orphan risk and slowly grow once they get confident. so dont expect max bloat straight away

again learn reality and stop exaggerating.

as for running 100 nodes.. why would someone do that and why would running 100 nodes mean anything.
if your currently running 100 nodes then your shooting yourself in the foot with a sybil attempt that is only hurting yourself.

but if you are worried about mempool bottleneck . worry more about nlocktime of 1 hour 59 minutes. that can force mempools to fill up