- Also it seems to me that in any case minisketch has nothing to do about that because the drop of the tx's due to not meeting the min relay criteria is a previous step in the protocol. Minisketch just adds an optional and more efficient (bandwidth wise) way of dealing with a preexistent situation.
You've got it.
The "re-relay" problem that he imagines isn't actually a thing, but even if it were, minisketch would just be an unrelated improvement: Nodes communicate their minfeerate to peers and don't get offered stuff they'll just drop due to fees. Existing things they do drop (due to being double spends, arriving while they're in the process of changing their fee filter, etc) they remember the txids so they won't fetch them again if a peer offers them, which itself doesn't happen much because txn are only offered when the peer initially accepts them.
Quote
allow more transactions without having to increase the block size just yet.
https://blockchair.com/bitcoin/block/544791
Size (bytes) 1,700,065
Last I checked 1700065 was greater than 1000000.
Segwit increased the blocksize, but didn't increase the size that lite clients have to deal with or break compatibility.Quote
facilitate the integration of L2
Not really, I mean that might have been why many people on the forum found it exciting, but separating out witnesses was proposed back in 2012 when no one was really thinking much about L2. Unintended malleability is just a source of 1001 awful corner cases that are really hard for wallets to handle except by refusing to spend your own unconfirmed outputs, or other similarly terrible and burdensome workarounds. We previously tried fixing these problems via BIP62 but it was just a finger in a failing dam, because the original design was flawed we kept finding more and more avenues and were forced to abandon that approach. Lightning was proposed before segwit was a thing and at least theoretically lightning can be done without it-- but in practice without the ability to control malleability it is just too awful and dangerous to write any automatic transaction processing software, so after segwit was proposed which completely solved that issue lightning developers decided to wait on its availability.Quote
Also, transaction malleability was a problem due to poor coding and lack of redundancy/cross checks on whatever exchange got affected (if any). A simple reconciliation of the balance of input addresses BEFORE doing any retry would have easily detected and stopped the exploit.
Not quite-- MTGox's claims were indeed just trying to cover up his insolvency cover-up, but even without that easily fixed accountability screwup malleability is a problem because of spending change output. There were several big attacks that really messed up and took down basically every big fund sender (e.g. bitstamp)-- we kept them under control by getting miners to blacklist various attack patterns, but that kind of workaround can be evaded by sufficiently motivated attackers. It actually was important to fix the general case for reasons unrelated to mtgox. Mtgox just seized on and exaggerated an existing problem that had given then a little trouble (and unlikely ~everyone else actually caused them some funds loss, rather than just a jammed wallet) ... but it still was actually an existing problem. It was strategic for mtgox to lie in this way, had they imagined some totally new fake problem to blame their insolvency on they would have instantly been called out.I really don't understand why FUDsters have had any success with the "malleability isn't fixed". The fact that it's possible to intentionally make a malleable transaction even exists as a useful and intentional feature: e.g. the ability to create anyonecanpay transactions where other people provide part of the funds after you sign. The malleability issue was always that it wasn't possible to spend an unconfirmed output (e.g. as your change, wallets have always refused to spend unconfirmed outputs by other people due to the risk of double spending) without those dependant spends (and their ancestors) being maliciously invalidated by someone else. -- it's not like intentional malleability is avoidable, after all you could also always double spend yourself.
I guess some people are just pathologically uncomfortable with anyone else having any choice at all in their life. The fact that you could choose to intentionally make a transaction that they allow other people to modify, and then have to deal with the consequences yourself just seems to drive some people wild. Similarly, the fact there is some buried command-line configuration option that virtually no one sets to increase the minimum feerate your node will accept-- with essentially no consequence for anyone but yourself-- causes the same people to melt down ... the idea that other people can make their own free choices seems to leave some unable to sleep and stuck obsessively posting about it. The fact that their choice harms no one and is fundamentally impossible to prevent is apparently just not relevant to these people.
Unfortunately, other people see the floods of posts and think that there must be some issue. But no: sadly, some people on the internet are just broken.
It's really frustrating that they'll say anything to sustain their obsessions ... like above "they introduce RBF to actually help malleators malleate" uh no, third part malleability always either lower feerates or keeps it the same, so if RBF mattered at all it would actually make malleability less sucessful by allowing the original to replace (in practice it doesn't because the mallated txn is only larger by one byte). Not only is the claim untrue, if anything it's the opposite of the truth. But the speaker will never suffer any negative consequence that he cares about for spreading this lie, and it might convince some ignorant party... so he'll do it every time.
