Quote from: larry_vw_1955 on Today at 02:11:43 AM

Quote from: ETFbitcoin on December 12, 2023, 09:31:16 AM

But i guess even developer don't expect witness data would be used to store arbitrary data.

yeah that's the problematic thing. something like bitcoin shouldn't be the result of unintended and unexpected consequences.

yawn.. "unexpected",, pfft note the dates of these quotes.. yep pre segwit, talking about how segwit opens up the exploit

Quote from: franky1 on November 24, 2016, 01:54:38 AM

secondly. legacy(old) nodes wont benefit from it. also old nodes will have more issues to contend with. such as seeing 'funky' transactions. aswell as still not being able to trust unconfirmed transactions due to RBF and CPFP.

thirdly new nodes wont benefit from malleability. because malleabilities main headache was double spending.. and guess what.. RBF CPFP still make double spends a risk.

fifthly, the 4mb weight. is only going to be filled with 1.8mb tx +witness data. leaving 2.2mb unused. but guess what. people will use it by filling it with arbitrary data. such as writing messages, adverts, even writing a book into the blockchain. what should have been done was allow 2mb base thus needing ~3.6mb weight.. and also adding a rule that 'messages' could not be added. thus keeping the blockchain lean and utilised just for transactions and not novels/adverts/messages. afterall if a communication tool like twitter or SMS can limit how much someone writes.. then so should bitcoin.
we will definetly see people purposefully bloating up the blockchain with passages of mobydick or over nonsense. and core have done nothing to stop it but done everything to allow it.

Quote from: franky1 on April 05, 2016, 07:41:40 AM

Quote from: knightdk on April 04, 2016, 10:18:54 PM

Yes, but only for spending from an output of the type OP_0 <20 bytes> or anything similar. The witness data must still be in the transaction when you are spending from an output that has anything like OP_CHECKSIG in the output script.

old clients wont check whats after 0x00(op_0).. they automatically treat the transaction as valid.

again the signatures are not in the same expected area. segwit abuses 0x00 to achieve this. thats the whole point of how segwit can work as a softfork!
because the signatures are not where they are expected. old clients treat it as just a valid funky tx.

the 20 bytes after 0x00 (op_0) are not going to be what old clients expect to see. yet they would automatically look passed it, without care.

i think you are blindly trusting the dev's to make pretty code with zero bugs. instead of thinking with a critical mind that things can break and to think that its better to have a things might break mindset rather then a devoted faith that it will elegantly work. because blind faith is the mindset of people who wont bug check/hack it to its limits. they will just do a couple standard transactions and praise their lord that funds move.. rather than trying to break it

come on.. the code is not even released and ur already thinking its perfect..

real that last line 5 times. let it settle in your head. and think about the mindset you have.
even scientists who spend years developing space rockets, still end up with them blowing up.