Segregated Witlessness

[Blinken]

Trying to soft fork Bitcoin with "segregated witness" is a stupid idea that solves nothing and just creates a lot of unnecessary uncertainty.

Seriously, the sum total objective of this chaos is to increase the effective size of a block by 4x or whatever? That solves NOTHING. Making incremental increases to the block size is not a solution to the scaling problem. Hello??? Anybody home???? We have tumblers, spammers, people encoding porn into the block chain, and an endless stream of other worthless transactions. Trying to accommodate all those crazies by increasing the block size is NOT a solution. I have news for you: spammers do not have to limit themselves to increasing the number of transactions they can do by four measly times. They can multiply their transactions by 10x or 100x or 1000x or whatever crazy multiple they want. I can sit at my computer and send a billion transactions into the pool if I want to spend my afternoon doing that. Segregated witlessness is not going to solve that problem. It will only increase the complexity and uncertainty of the protocol while raising the specter of a soft fork hell.

We do not need to try increase the block size. We only need to prioritize which transactions get into a block.

The design of Bitcoin already has a mechanism to prioritize transactions and that mechanism is the fee. That mechanism works. Let it do its job.

[1714801406]

1714801406

[1714801406]

1714801406

[1714801406]

1714801406

[Quantus]

I personally believe that 80% of the transactions in the mem-pool are generated by the mining pools themselves to prop up the transaction fees.
However segregated witness dose fix some issues unrelated to the block size debate.
I personally believe if we did't have mining pools we would only be using 20% of the bocks.

[Karartma1]

Math works very well when there's little to none human intervention. Flowers, waters, trees don't need us if they follow Nature.

I supposed Bitcoin was like that: give math control and forget about the rest. I was wrong.

There is no math in bitcoin anymore, no more nature only f****** politics pollution.

[K128kevin2]

SegWit isn't the final solution to scaling Bitcoin. It's a small one time capacity increase, but it also fixes a bug that will allow for easier scaling in the future.

[franky1]

SegWit isn't the final solution to scaling Bitcoin. It's a small one time capacity increase, but it also fixes a bug that will allow for easier scaling in the future.

i see you have read the failed script.
i dare you to actually explain the fix lol

hint: you have to explain how it cannot be countermanded or used as a new attack method itself

... i expect silence or lack of knowledge and just another paste of a salespitch of empty promise

[Vaccinus]

SegWit isn't the final solution to scaling Bitcoin. It's a small one time capacity increase, but it also fixes a bug that will allow for easier scaling in the future.

i see you have read the failed script.
i dare you to actually explain the fix lol

hint: you have to explain how it cannot be countermanded or used as a new attack method itself

... i expect silence or lack of knowledge and just another paste of a salespitch of empty promise

but BU have also its bad side, it's not about what part has no problems, it's about what part has the less bad problems, and BU is worse than segwit, and with i'm not saying that seg wit has no flaw, but BU has more, i think this what he mean

[franky1]

but BU have also its bad side, it's not about what part has no problems, it's about what part has the less bad problems, and BU is worse than segwit, and with i'm not saying that seg wit has no flaw, but BU has more, i think this what he mean

lol.
you do know why something deemed "backward compatible" is not simply activated instantly.
after all if really backward compatible. its just as valid now as ever right... (but read the small print and you see the holes)

you do know even when activated core wont have a walet enabled release for people straight away...

you do know why segwit needs to be upstream filters and actively ban other non-segwit nodes from being upstream. this includes banning pools and their non segwit blocks from being added on after.

you do know why segwit will not relay segwit unconfirmed tx's to non-segwit nodes.

not only that but the sigop quadratic spamming is not solved due to it not stopping native tx's
the malleability is not solved because it does not stop native tx's

the tx count wont reach expectations because it does not stop native tx's

once you look passed the scripted half promises. and look at how it works.. you see the promises are empty.
you also start to see new attack methods aswell as the old ones that still exist.

also.
litecoin transactions have been fully running and used for 6 years. all tested by thousands of people..
.. but introduce them onto bitcoins mainnet. no one knows what will happen.

and segwit transactions are the same 'many tests and been running on alternative networks for x month' but never on bitcoins mainnet..

(some attacks have been highlighted. even i highlighted the main one last year, which led to the whole ordeal of not releasing the segwit key wallet until way after activation. but even then there are still attack vectors that can and will happen with segwit tx's and native nodes after activation).
hint: though segwit nodes mess with ban lists and not auto relaying unconfirms to native nodes.. some script kiddie can manually copy the segwit mempool and push segwit unconfirms into their native nodes mempool and have a nice play around.

[gmaxwell]

you do know even when activated core wont have a walet enabled release for people straight away...

The wallet in Bitcoin Core supports segwit (it's what most people use for testing!), it just doesn't use it by default.

you do know why segwit needs to be upstream filters and actively ban other non-segwit nodes from being upstream. this includes banning pools and their non segwit blocks from being added on after.

Lie. They do not ban non-segwit nodes.

you do know why segwit will not relay segwit unconfirmed tx's to non-segwit nodes.

Lie.

not only that but the sigop quadratic spamming is not solved due to it not stopping native tx's

Misleading: you can't cause much problems with tx limited to 1MB, esp due to other optimizations. Which is why nothing other than optimize was done about it before.

Segwit fixes it where it was critical to do so... and it can't be 'fixed' for old transactions without confiscating funds.

the malleability is not solved because it does not stop native tx's

Lie. You can choose you make your transactions completely immune to third party malleability with segwit. (Malleability is a feature which you can _choose_ to use, explicitly supported-- it's only the unwanted, unpreventable, third party malleability which is an issue, and segwit eliminates that.)

the tx count wont reach expectations because it does not stop native tx's

Native? you mean the older kind.  Well duh people can make needlessly big transactions and pay more to do so-- that is true for any block size change.

(some attacks have been highlighted. even i highlighted the main one last year, which led to the whole ordeal of not releasing the segwit key wallet until way after activation. but even then there are still attack vectors that can and will happen with segwit tx's and native nodes after activation).

Another lie.

hint: though segwit nodes mess with ban lists

Repeated lie.

and not auto relaying unconfirms to native nodes..

Repeated lie.

some script kiddie can manually copy the segwit mempool and push segwit unconfirms into their native nodes mempool and have a nice play around.

Another lie.


Gee, franky1 do you get paid by the lie, or what?

[jonald_fyookball]

Trying to soft fork Bitcoin with "segregated witness" is a stupid idea that solves nothing and just creates a lot of unnecessary uncertainty.

Seriously, the sum total objective of this chaos is to increase the effective size of a block by 4x or whatever? That solves NOTHING. Making incremental increases to the block size is not a solution to the scaling problem. Hello??? Anybody home? We have tumblers, spammers, people encoding porn into the block chain, and an endless stream of other worthless transactions. Trying to accommodate all those crazies by increasing the block size is NOT a solution. I have news for you: spammers do not have to limit themselves to increasing the number of transactions they can do by four measly times. They can multiply their transactions by 10x or 100x or 1000x or whatever crazy multiple they want. I can sit at my computer and send a billion transactions into the pool if I want to spend my afternoon doing that. Segregated witlessness is not going to solve that problem. It will only increase the complexity and uncertainty of the protocol while raising the specter of a soft fork hell.

We do not need to try increase the block size. We only need to prioritize which transactions get into a block.

The design of Bitcoin already has a mechanism to prioritize transactions and that mechanism is the fee. That mechanism works. Let it do its job.

Based on this logic there is no need to have ANY maximum blocksize try and act as a spam filter, which I happen to agree with.

[kiklo]

Gee, franky1 do you get paid by the lie, or what?

No,

He believes what he is saying.

He is not on Blockstream's Payroll like you are.

You saying someone else is lying, is like the Pot calling the Kettle black.






 

[franky1]

you do know even when activated core wont have a walet enabled release for people straight away...

The wallet in Bitcoin Core supports segwit (it's what most people use for testing!), it just doesn't use it by default.

USED on TESTNET, not mainnet

even the segwit guide says the wallet is not and will not be publicly available to be USED on mainnet until after activation
https://bitcoincore.org/en/segwit_wallet_dev/

Upgrade Safety

End users MUST NOT be allowed to generate any P2SH-P2WPKH or other segwit addresses before segwit is fully activated on the network. Before activation, using P2SH-P2WPKH or other segwit addresses may lead to permanent fund loss
Similarly, change MUST NOT be sent to a segwit output before activation

you do know why segwit needs to be upstream filters and actively ban other non-segwit nodes from being upstream. this includes banning pools and their non segwit blocks from being added on after.

Lie. They do not ban non-segwit nodes.

stop trying to be clever with language.

It's not acceptable for the network topology to suddenly change when segwit activates--  can you imagine that? drop all your current connections and then form new ones hoping that the network can make a non-partitioned graph?-- that would be irresponsible.  Instead, it changes its connection preference at install time, so if there were any issues they could be addressed while the user is paying attention.

let me guess instead of the word "ban".. if i said at setup the segwit node has already chosen to not prefer to let a non-segwit node be the upstream, this its not a ban. its just an avoidance from even making the connection in the first place to not require banning later.

you do know why segwit will not relay segwit unconfirmed tx's to non-segwit nodes.

Lie.

let me guess due to the 'preferencial' connection at set up, the segwit node is already not connected to non-sgwit nodes to not need to worry about sending unconfirmed segwit tx's to native nodes.

...

oh and gmaxwell if all things are fine and dandy and everything is fully compatible. how about you send a segwit tx to BTCC to force into a block.. knowing that old nodes will be fine receiving the block..
show the network that evrything is backward compatible.

at worse BTCC block gets rejected and you/dcg can easily repay them $13k out of the millions of investment..for a test to thank them for wasting their time if it rejects.
atleast it will show confidence in the "backward compatibility" claims and the "nothing needs to change" claims

[Quickseller]

I have news for you: spammers do not have to limit themselves to increasing the number of transactions they can do by four measly times. They can multiply their transactions by 10x or 100x or 1000x or whatever crazy multiple they want. I can sit at my computer and send a billion transactions into the pool if I want to spend my afternoon doing that.

Increasing the max block size will make it exponentially more expensive for spammers to continue spamming the network. Also as long as the max block size is sufficiently higher than the natural amount of transactions, spamming the network with transactions will be unprofitable to a small miner.   

[spin]

Gee, franky1 do you get paid by the lie, or what?

No,

He believes what he is saying.

He can believe what he says, but it doesn't mean it's right. Also whether he is right or wrong is unaffected by who pays anyone or not.