Quote from: waxwing on December 24, 2016, 10:25:45 PM

This has been done in Bitcoin,

Are you referring to

Quote

// Negative numbers are not allowed for R.
if (sig[4] & 0x80) return false;
.......
// Negative numbers are not allowed for S.
if (sig[lenR + 6] & 0x80) return false;

I would have gone for |r| and |s| personally so no explicit rejection would be required. I wasn't sure that N-s was negative for all values of N, though. However. If you are happy the solution then I am happy that both DER encoding and ECDSA malleability are already addressed and not usable as a "malleability fix" argument for SegWit.

Quote from: waxwing on December 24, 2016, 10:25:45 PM

> LN will be the only side-chain

LN is not a sidechain. The fact that you say this suggests you know very basically exactly zero about LN. You might want to educate yourself before offering an opinion on it.

I beg to differ. It would be a side-chain if the changes weren't being implemented. I do indeed know nothing about LN. I don't care how it uses SegWit in a similar way that I don't care how coloured coins use Bitcoin- I am only interested in bitcoin and its SegWit solution. The driver for SegWit seems to be purely LN so that is political rather than technical driver and that worries me. Are you going to go as far as saying LN is Bitcoin 2.0?

Quote from: waxwing on December 24, 2016, 10:25:45 PM

> The point is that malleability is an edge case symptom that can be solved without adding a lot more complexity

This is wrong on two counts: 1, no it cannot be solved in a different way without adding a lot more complexity, and 2, segwit, at least in general terms, is the architecturally correct and simple solution to the problem. See the bip62 doc that you were already linked to for details on the first point.

1. I disagree. I have already outlined (albeit vaguely) several solutions. You want a txID not fixed to a signature. This isn't rocket science.
2. It is the architecturally correct solution for outsourcing the txID generation-that's it. If you are going to do that, then make it a plugin module then it doesn't need to be in Bitcoin at all and anyone can use their own, including legacy (maybe a default module). It is a poor solution just for malleability and a straight-jacket for txID generation.

Quote from: waxwing on December 24, 2016, 10:25:45 PM

Bitcoin's existing design for this is just wrong (or at the very least, not the best one): the signatures authorizing the transaction are included inside the final txid hash, which is being used as a transaction identifier; but it doesn't identify the transaction. The authorising portion (signatures) should be outside the hashed data/transaction as they are not part of the semantic content of the transaction, they are only an authorisation of that semantic content.

I agree entirely. We only disagree that SegWit is the optimal solution.

Quote from: gmaxwell on December 24, 2016, 10:53:05 PM

Quote from: waxwing on December 24, 2016, 10:25:45 PM

This has been done in Bitcoin,

Not just done in Bitcoin, but we came up with that improvement; and ripple borrowed it long after-- including the code for it. I put him on ignore after that post: There is nothing worse to deal with in this subforum than a chest-thumping altcoin promoter bragging about an altcoin being superior on the basis of code or techniques they coped from Bitcoin Core.

Ad hominem response that adds nothing and addresses nothing. I expect better.