Topic: Post your SegWit questions here - open discussion - big week for Bitcoin! - page 26. (Read 84849 times)

Sure the lightning network benefits from segwit, but it is not the only reason (if a reason at all) that segwit exists. If you look at the rest of the document, there are a whole lot more benefits than just LN. The rbtc taking point is that segwit is only for lightning, but it most certainly is not.

Hmm, I suspect actually a lot of people think that because on the Segwit FAQ, here: https://bitcoincore.org/en/2016/01/26/segwit-benefits/ it says:

You are showing an impressive level of ignorance here: N-s is _never_ negative, s is a field element.  

Malleability in Bitcoin goes far beyond just signature encoding malleability. Multistep multiparty protocols like coinswap require that the other signer in a 2 of 2 not be able to invalidate a chain (or extreme amount of additional protocol phases); this can never be accomplished with a DL signature since they inherently must have a random input, so long as the signature itself is part of the identifier. Segwit's approach to eliminating signature malleability gives a guaranteed solution to all forms that would potentially invalidate a chain of transactions.

There has only ever been one other proposal that provided an equally complete solution, but it had the downside of doubling the UTXO set size and roughly doubling the amount of transaction hashing work.


Clearly you don't-- because this statement makes no sense.


This is an rbtc talking point-- it has no basis in reality.   Segwit is largely orthogonal to lightning, and proposed long after it. The reason people keep claiming it is because segwit is above reproach and lightning is less well understood and easier to FUD.


You seem to be confused about what a txid is really used for.   From your comments it seems that you think that wallets are somehow distinguishing payments that way. That isn't the right way to distinguish a payment... Bitcoin Core doesn't, it tracks outpoints (either as inputs for conflict handling or outputs for payments).  No one cares much about the cosmetic implications of malleability, they're largely irrelevant.

Transaction IDs are an essential part of the Bitcoin consensus rules. A transaction selects the coins it will spend by specifying the transaction IDs of the transactions that created those coins.  These IDs are included under the subsequent transaction's signature.  If something happens to change a transaction's TXID then all subsequent descendant transactions are invalidated. This is what people care about.

No amount of module whatever can do anything to help that.  So what you propose would only ad a cosmetic issue that almost no one cares about ('I can't look up the txid I was expecting in a block explorer')-- and if anyone cared it would already be solved, as it's not a consensus change.

It is not hard. But you have to be responsible for you actions.
It is not good idea to do everything just because it is easy and somebody told you to do it.

Looks like I have much to read about it, I've read some articles about SegWit but not fully understand why some miners don't like it to implemented, is it make them work so hard or less fee, or what?
How many (percentage) of miners that approved SegWit upgrade? What the best site to determine the progress about it?
Thank you.

You are coming off as a bit crazy if you believe that gmaxwell's above response fits into the "ad hominem attack" category.  It appears to be that you, TransaDox, are engaging in an ad hominem attack of gmaxwell by asserting that his response was an ad hominem attack

gmaxwell seems to provide a historical perspective in order to attempt to clarify the order of events... in other words, he is asserting that bitcoin came up with an invention first that was stolen by some alt (ripple) and then promoted by that alt as if it were the invention of the alt..

If you believe that gmaxwell is misstating some facts or some historical events, then maybe, arguably, there could be some kind of ad hominem attack going on with gmaxwell's respone.,.,. but does not seem to be the case.

If you have some kind of basis for your assertion, TransaDox, maybe you could explain a bit more what you mean more by the term "ad hominem attack" in this context?

Are you referring to
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?

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.
 
I agree entirely. We only disagree that SegWit is the optimal solution.

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

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.

This has been done in Bitcoin, see BIP66: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki

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

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

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.

There is a huge amount of resources that explain what segwit is, it is nothing to do with the paranoid fantasies being spread about. Do some research.

Source. (My emphasis)

I knew there was more to this than a "malleability  fix".


OK. So the whole codebase has been modified to account for this one side-chain, the reason being that if affords confidentiality for LN and to no-one else. For this reason alone it is cancer.

Now. It is certainly desirable to fix malleability and even allow side-chains to use the BC for their own back end systems. The proper way would be to allow others to plug-in a module at run-time so that anyone could create their own plugin module and distribute it with their wallet software. Hell. You could even support an unlimited number of "variants" from Bitcoin Core. LN could then have created a specific plugin for their wallets. As it happens, I've wanted the reference software to go down the plugin path for quite some time (the address creation, hash used, the mining method etc) but it is clear that is just a pipe-dream.

It seems to me that should this go live, then LN will be the only side-chain worth using with guarantees of confidentiality and everyone else has to wash all their clothes in public. Is this the case?

Yes, the wtxid is malleable, but it is not actually used for anything so that does not matter.

Speaking of malleability, I assume that the wtxid doubleSHA256([nVersion][marker][flag][txins][txouts][witness][nLockTime]) is now malleable but that is handled appropriately? Not sure if BIP 147 was meant to address part of this issue.

The owner of private key can create several different valid signatures for the same data needed to sign.
This is also "malleability" and I told you about it ( ...by the person who knows the secret... )
The biggest advantage of segwit is that the txid would not change with different signatures
and can be calculated *before* signing the transaction

Of course. I have already said it was an "umbrella term" to which amacilin picked one and I specifically gave him a solution to that. I also mentioned  hashing the final stack which would fix:

• Superfluous scriptSig operations
• Inputs ignored by scripts
• Sighash flags based masking
• Non-push operations in scriptSig

The DER encoding is a consensus issue since OpenSSL accepts BER and DER (DER being a subset of BER). Pre-checking before passing to OpenSSL is trivial.

The point is that malleability is an edge case symptom that can be solved without adding a lot more complexity. There is a lot more to this SegWit proposal than we are being told.

This isn't the only source of malleability. The abandoned BIP62 lists ways in which a Bitcoin transaction is malleable:

• Non-DER encoded ECDSA signatures
• Non-push operations in scriptSig
• Push operations in scriptSig of non-standard size type
• Zero-padded number pushes
• Inherent ECDSA signature malleability
• Superfluous scriptSig operations
• Inputs ignored by scripts
• Sighash flags based masking

Do you know about the google? 

Here you go:

https://bitcoincore.org/en/2016/01/26/segwit-benefits/

What is Segwit?

Sure, because distinguishing between  σ = (r,s) and σ'= (r,N − s) is just too hard for bitcoin, eh?  
Ripple uses (r,s) < (r,N − s)?  (r,s):(r,N − s)

Sorry, too difficult for me to catch all nuances. My English is far from perfect.

First of all, ecdsa malleablity is the abliity to change the signature itself for the same
data without invalidating it by the person who knows the secret or by the "middle-man"

You need to re-read the post.

Of course. "Malleability" is an umbrella term for multiple issues that affect corner cases. For example. The script is hashed then signed causing a different hash if the instructions are changed but, never the less, yield the same result. The solution to this aspect, I believe, is to hash the final stack instead of the current method.