Topic: Segregated Witlessness (Read 822 times)

That might be true, but i'm interested to see how to prioritize which transactions get into a block since micro-payment can be misidentified as spam transaction
Also, only spammer with lots of money that can send transaction with moderate fees that could get confirmed by miners.

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.

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.   

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/

stop trying to be clever with language.

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.


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

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.






 

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.

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


Lie. They do not ban non-segwit nodes.


Lie.


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.


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.)


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.


Another lie.


Repeated lie.


Repeated lie.


Another lie.


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

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.

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

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

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.

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.

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.

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.