Post your SegWit questions here - open discussion - big week for Bitcoin!

[cypherblock]

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.

[achow101]

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.

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

[TransaDox]

Segwit started as an element in elements alpha. It allows for safe chaining of pre-signed transactions, which is important for payment channels and lightning network. The version in elements just changed how we defined txids, which we can't do in bitcoin. It's hard to imagine doing hard-forks in bitcoin just for this. Non-security hard-forks are going to be very hard to get consensus on.

As deployed, there's this key insight that you deploy a type of extension block and you can enforce inside of this extension some new rules. Some things that look like hard-forks turn into soft-forks. So we can sneak in confidential transactions as a soft-fork. So you have the base block and then you commit to something, and in this other block you reveal the real data that shows you own this bitcoin. As a highly desired extension, it kind of fits this model.

Source. (My emphasis)

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

It's one of the largest changes to bitcoin ever. It has touched nearly all areas of the bitcoin code base, like p2p, wallet, consensus, every layer.

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?

[waxwing]

Of course. "Malleability" is an umbrella term

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"

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)

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.

[gmaxwell]

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.

[TransaDox]

This has been done in Bitcoin,

Are you referring to

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

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

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

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.

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.

[JayJuanGee]

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.

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?

[error08]

How many have now updated to 0.13.1, they need at least 95% don't they?
Do we know if all the wallet providers are supporting the upgrade?

SegWit needs 95% of the miners to upgrade.  You can look at the block version to see if the miner has updated (version is x'2000002' for SegWit).  So far, I'm seeing around 1 block in 10 that has the SegWit version.  So there is a long ways to go yet.  I already have a SegWit transaction in the blockchain just waiting for the support to be locked in (you can create a P2SH-P2WPKH transaction but you can't spend it yet).

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.

[amaclin]

is it make them work so hard

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.

How many (percentage) of miners that approved SegWit upgrade? What the best site to determine the progress about it?

[gmaxwell]

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,

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

both DER encoding and ECDSA malleability are already addressed and not usable as a "malleability fix" argument for SegWit.

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.

It would be a side-chain if the changes weren't being implemented. I do indeed know nothing about LN.

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

The driver for SegWit seems to be purely LN

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.

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.

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.

[tertius993]

The driver for SegWit seems to be purely LN

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.

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:

Who benefits?
...
...
The Lightning Network
...

[achow101]

The driver for SegWit seems to be purely LN

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.

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:

Who benefits?
...
...
The Lightning Network
...

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.

[TransaDox]

The driver for SegWit seems to be purely LN

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.

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:

Who benefits?
...
...
The Lightning Network
...

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.

Since GMaxwells ignore system doesn't seem to be functioning, I may address that when I have more time but in the meantime....

I have no idea what "rbtc" is. Searches yield mainly bible groups, so I've really no idea what is being referenced.

The linked document by tertius993 gives 4 benefits.

1. Wallet authors tracking spent bitcoins
According to GMaxwell no one cares, apparently.

2. Anyone spending unconfirmed transactions
This was never a good idea and has always been stated that 6 confirmations is the bare minimum and use zero at your own risk. It is an obvious area for improvement but segwit just offloads the risk to a third party like any side-chain as was intended in the original design.

3. The Lightning Network
Of course.

4. Anyone using the block chain
This is just a sales pitch. At best it is a corollary of #1 without explicit definition.

#1 & #4, if we take these as read, are saying that having an immutable txID has benefits (IMO, malleable TxID was a bug).
#3 was a design decision and the usual retort to things like that from the eminent legendaries is "go make your own alt-coin".

None of them are peculiar to SegWit but #3 requires it.

[gmaxwell]

2. Anyone spending unconfirmed transactions
This was never a good idea and has always been stated that 6 confirmations is the bare minimum and use zero at your own risk. It is an obvious area for improvement

Again, you are showing profound confusion.  If you do not spend _your own_ unconfirmed coins you can be restricted to make only a _single_ transaction until you receive a confirmation... meaning you might easily be waiting an hour before you can make a second payment after making a first while waiting on a block.

Without the ability to spend unconfirmed transactions you cannot engage in many useful protocols like cross chain atomic swaps or coinswaps.

1. Wallet authors tracking spent bitcoins
According to GMaxwell no one cares, apparently.

A bit of a wrinkle there. Tracking if a payment has been made is what I was referring to above, but that text is referring to needing code to _unfuck_ a wallet after a chain of transactions has been disrupted with malleability. I'm not aware of any wallet that does this today, not even core. It too hard to do right, compared to just fixing the malleability. The distinction is that no amount of "modular" cosmetic ID can help that, because once the transaction chain is broken, it's broken.  Previously I was responding above the kind of cosmetic issues you were discussing when you suggested that a non-normative ID could help.

but segwit just offloads the risk to a third party like any side-chain as was intended in the original design.

You are just spouting nonsense here. Who is the third party? What risk is offloaded?  I think at this point you are literally just making things up and not even earnestly expressing your own confused views.

None of them are peculiar to SegWit but #3 requires it.

Lightning does not require segwit. Simply repeating it over and over again will not make it true.

[stdset]

Lightning does not require segwit. Simply repeating it over and over again will not make it true.

Maybe that's because nobody understands how a permanent LN channel could be opened without malleability fix?
How about the following protocol? Is it how it is supposed to work with CSV but without malleability fix?

This is a protocol for opening a permanent lightning channel even if malleability is not fixed.  It only requires check locktime and check sequence verify.

Both sides put down a deposit to eliminate the hold-out risk.  If either of the parties refuses to proceed either the other party is compensated or both get a full refund.

Step 1

Alice picks A1 and sends HA1, Hash(A1), to Bob.
Bob picks B1 and sends HB1, Hash(B1), to Alice.

They can both create this transaction.

Code:

TX1:
0) Pays 3x: (Alice + HA1 after T1) or (Bob after T1 + T2) or (2 of 2 Alice + Bob) 
1) Pays x: (HB1 + Alice) or (2 of 2 Alice + Bob)
2) Pays x: (HA1 + Bob) or (2 of 2 Alice + Bob)
3) Pays 3x: (Bob + HB1 after T1) or (Alice after T1 + T2) or (2 of 2 Alice + Bob)
4) Pays Alice's change: (Alice)
5) Pays Bob's change: (Bob)

Alice and Bob create the transaction and sign and broadcast it.

Abort during step 1

If one party signs the transaction and then the other refuses, then the signer should send at least one of the inputs to another address.  This invalidates the transaction.

Abort after step 1

Alice can wait T1 and then reclaim output 0.  This automatically gives Bob HA1, which allows him claim output 2.

Likewise, Bob can wait T1 and then reclaim output 3.  This automatically gives Alice HB1, which allows her claim output 1.

This is a full refund all parties.

If Alice refuses to claim output 0, then Bob can claim it after [T1 + T2] (and output 3), which gives him 6x and Alice nothing.  

Likewise, if Bob refuses to claim output 3, then Alice gets 6x and Bob nothing.

Both parties are incentivized to comply with the abort at this stage.

Step 2

Alice and Bob create the initial channel state transaction.  This supports a channel close that gives x to Alice and x to Bob and spends outputs 1 and 2.

The initial state transaction is different for Bob and Alice due to the way Lightning works.  Only Alice has both signatures for her version and only Bob has both signatures for his version.

Step 2a

Alice signs Bob's version of the transaction and sends the signature to Bob.

Abort after step 2a

If Bob broadcasts his initial state transaction, then that counts as him closing the channel.  Alice gets her x refund and then can reclaim output 0 (after T1).

If he doesn't broadcast it, then she can just follow the same abort procedure from step 1.

Bob can abort using the procedure from step 1 or broadcasting the initial state transaction.

In all cases, Alice and Bob get their money back.

Step 2b

Bob signs Alice's version of the transaction and sends the signature to Alice.

Abort after step 2b

Alice (or Bob) can simply close the channel so that both get x each from outputs 1 and 2.

Once the channel is closed, she can then claim output 0 safely (after 1 week).

Likewise, Bob gets x when the channel is closed (he can close it himself too) and then claims output 3 safely.

This gives both parties a full refund.

Step 3

Alice and Bob create a transaction which sends outputs 0 and 3 back to them.  This requires both outputs to be 2 of 2 signed (so 2 signatures each).

This transaction is broadcast.  If either party refuses to sign, then it counts as an abort after step 2b.

Once step 3 is finished, they now have established an initial lightning channel state with unlimited duration.

It is important that neither reveal their hash lock as that allows the other to spend the funding output.

[Yogafan00000]

Why was 95% adoption rate selected for activation as oppossed to 80% or 50% or even 5%?

[achow101]

Why was 95% adoption rate selected for activation as oppossed to 80% or 50% or even 5%?

So that the soft fork deploys with supermajority. It will essentially have consensus when it deploys. This ensures that the new rules will be deployed and enforced by the miners. The 95% rule has been used for all previous soft forks, no reason to change that now.

[X7]

2. Anyone spending unconfirmed transactions
This was never a good idea and has always been stated that 6 confirmations is the bare minimum and use zero at your own risk. It is an obvious area for improvement

Again, you are showing profound confusion.  If you do not spend _your own_ unconfirmed coins you can be restricted to make only a _single_ transaction until you receive a confirmation... meaning you might easily be waiting an hour before you can make a second payment after making a first while waiting on a block.

Without the ability to spend unconfirmed transactions you cannot engage in many useful protocols like cross chain atomic swaps or coinswaps.

1. Wallet authors tracking spent bitcoins
According to GMaxwell no one cares, apparently.

A bit of a wrinkle there. Tracking if a payment has been made is what I was referring to above, but that text is referring to needing code to _unfuck_ a wallet after a chain of transactions has been disrupted with malleability. I'm not aware of any wallet that does this today, not even core. It too hard to do right, compared to just fixing the malleability. The distinction is that no amount of "modular" cosmetic ID can help that, because once the transaction chain is broken, it's broken.  Previously I was responding above the kind of cosmetic issues you were discussing when you suggested that a non-normative ID could help.

but segwit just offloads the risk to a third party like any side-chain as was intended in the original design.

You are just spouting nonsense here. Who is the third party? What risk is offloaded?  I think at this point you are literally just making things up and not even earnestly expressing your own confused views.

None of them are peculiar to SegWit but #3 requires it.

Lightning does not require segwit. Simply repeating it over and over again will not make it true.

I'm pretty sure 70% of these people are paid to just frustrate you and waste your time on responses, you're a brilliant coder. Ignore the nonsensical banter with people who have clear motivations of just battling your position without engaging in logical rebuttals.

And do what you shine at, code 

[gmaxwell]

Why was 95% adoption rate selected for activation as oppossed to 80% or 50% or even 5%?

So that the soft fork deploys with supermajority. It will essentially have consensus when it deploys. This ensures that the new rules will be deployed and enforced by the miners. The 95% rule has been used for all previous soft forks, no reason to change that now.

Not all-- we've increased it over time in response to prior instability and as we all learned better the implications.  BIP30 just used a 'past this time' decree. BIP16 was based on 55% and just used a time for the actual activation, and resulted in months of low levels of orphaned blocks being produced.  Satoshi used several hard cut softforks that were just triggered on blockheights.  BIP34 was the first to use 95% but it actually started enforcing the rules for a subset of blocks at 75%.

BIP9 changed to a new quorum sensing approach that is MUCH less vulnerable to false triggering, so 95% under it is more like 99.9% under the old approach.  But we saw no reason to lower the criteria:  basically when it activates the 95% will have to be willing to potentially orphan the blocks of the 5% that remain if they happen to mine invalid blocks.   If there is some reason when the users of Bitcoin would rather have it activate at 90%  (e.g. lets just imagine some altcoin publicly raised money to block an important improvement to Bitcoin) then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.

So basically setting the criteria high protects the stability of the network in the common case, but never ties anyone's hands against something not activating. By default the safest thing happens, but no one can exploit this in an attack.

Because of this, the trade-offs favor a high threshold.

[blacksmithtm]

Thank you everyone for an interesting thread. And thank you to the people who took the time to patiently answer the questions from users. You guys are the best. I wish you all a happy new year. Sorry no questions for now.