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

Ah, right. I forgot about that.

Changing witness data without invalidating transaction does not change txid

I have started studying SegWit more closely and I have several questions. One of the things it does is that it fixes malleability. The point of malleability is that a tx hash can change before it is commited to the block without changing the result of the transaction. The abandoned BIP62 list all(?) of the ways in which a transaction can be malleated. My first question is, would it be enough to just change the hashing algorithm (BIP143) to fix this instead of introducing the witness field?


Can this happen in P2WSH? If witness looks like That 1 is superflous and I think it is the malleability form described by the quote above. Or is this case covered by BIP141#Wintess Program "The script must not fail, and result in exactly a single TRUE on the stack."?


Is this covered by the new hashing algorithm described in BIP143?

Kano raised invalid concerns, just like the rest of your concerns, not valid.


It seems like a huge number of people are saying: "I don't understand the point of fixing signature malleability, or why quadratic sighash scaling is an issue, so, why?"

This is incredibly arrogant, and ignorant. And I don't normally listen to anything that people say who are too arrogant to fix their own ignorance. Do you?

I feel like I understand the technical details fairly well, and I'm confident that Segwit has been the largest change to the Bitcoin codebase in the past few years, both in terms of number of lines of code and the depth to which it reaches. Also it requires changes to the code in all wallets and utilities. Changes that are nowhere near complete, as people are waiting to see if Segwit is adopted. I'm not a "big-blocker" at all, I've been a vocal opponent of Classic, XT, Unlimited, etc.

I believe it's time to speak honestly about Segwit, which I do not support, for different reasons. No troll. Flame away. Kano is a legit developer of mining software who has also raised valid concerns about the code.

Achow101...

Great that you have a lot of patience answering apparent trolls.


Yeah, at first, maybe we can give them some benefit of the doubt, but when they keep insisting on the bigblocker talking points while claiming to not understand technicalities while at the same time suggesting that seg wit is "too complex" and suggesting that a hard fork is preferable to a soft fork... blah blah blah, we certainly can get the sense that they are disingenuous, just bringing over some big blocker nut job talking points.. and likely trolling.

Lightning is certainly possible without segwit, it is just a lot harder to implement and more complex. Segwit makes lightning easier to implement and less susceptible to failure.

As I said earlier, hard forks are neither simple nor clean. Even implementing segwit as a hard fork would not be simple nor cleaner. Either you break every single unconfirmed transaction, or you go through the pain of a hard fork for basically no reason as the things that would require hard forking can and are already done in a way to allow soft forks.

Because people are testing the software and upgrading custom software. Also a lot of pools seem to not support segwit for some reason.

We can't predict the future, no one knows.

adoption takes time, why? when we can expect >90%?

Thanks achow for your answer,
The others were saying if Lightning Network was possible without SegWit and it is true? or SegWit was becoming a responsibility for Lightning Network.


Why bitcoin core has opted the complex softfork  rather than be implemented into hardfork with more simply and cleaner.

Not upgrading to a segwit enabled wallet will not affect sending or receiving Bitcoin as you do now. The backwards compatibility of segwit means that you will be able to receive from someone with segwit (albeit after the transaction has confirmed a few times) and send to someone who wants to use segwit.

Hard forks are far from simple. Segwit also solves a lot of problems simultaneously, not just capacity. A "simple" block size increase hard fork ignores a lot of the nuance that comes from making such a change

Segwit does not need a block size increase hard fork.

Just a simple question from me,
1. If I won't upgrade into the supporting SegWit and Will it give any impact for me to sending or receiving such amount from the Supporting SegWit?  

2. Why SegWit is complex rather than a simple hardfork.

3. Are the implementing of SegWit will need blocksize hardfork?

The actual 'weight' limit is 4 MB. In other words, if Segwit is activated we will see blocks between 0 and 4 MB. However, it is expect that the 'maximum' block size will be around 2.1 MB (due to the current transaction type usage). If more people use n-of-m addresses, then the block size will likely be higher. Keep in mind that a higher block size does not necessarily imply more transactions.

Actually the transactions are slightly larger IIRC. However, what you're referring to is the witness segregation.

---

This isn't really a thread to get familiar with Segwit. There are 'more simplistic' explanations elsewhere IMO.

So after reading through the forums, I'm still trying to fully get my head around Segwit. It has a couple of large changes, like

 - A two (or is it four with a soft Cap of two) megabyte blocksize
 - A unique ID for a single transaction (removing the need to search for duplicate transactions with different IDs
 - Smaller transaction size by removing a large part of the transaction (I'm not sure what this is)

It looks like "blacklisting" might be an exaggeration here... nonetheless, the soft fork is a touchy subject and it's for reasons like this. Suddenly Segquit blocks are "higher quality" than non-Segquit ones.

I see that the Segwit adoption rate has flatlined at around 25%. I'm not running it, I'm running core 0.12. Reason being (sorry devs, I respect, but...), Segfault is a NERD SOLUTION: hugely overcomplicated, risky, and unnecessary. It's like going to get a car at a dealer and coming home with a portable automotive manufacturing plant!  Now before anybody buttrages on me, please understand that I've been a huge critic of the lame code forks like Classic, XT, and Unlimited, etc (heck, look at my username!). Those code forks were done with the worst of intentions by the worst devs. However, the blocksize needs to increase... I guess we're in a "stonewall period" right now where nobody wants to scream about blocksize anymore, all the cards are on the table, and everything that can be said has been said. Antonopolous says a compromise is near and I hope he's right...

Whoever is filling the mempool with sh*t will probably be able to do that even if the blocksize is 4MB, so that will be the next problem to solve. Ironically, if they are spamming, which is what I see, they're currently pricing themselves out of the market - fees are rising rapidly! I suspect it's "churn", people pumping the price... Thanks for listening.

Egads. I was saying the exact opposite of you can't connect to non-segwit nodes. In repeated loud text. You can and do.

But once segwit activates you cannot request blocks from them, because they don't provide the witness data that you need to verify the blocks.


95% is regard to hashpower. Hashpower is not listening node count.


Is in a perfectly fine state. They'll preferentially connect to other segwit capable nodes (about 40% of reachable peers), but if they can't find enough (or if addnoded/connected otherwise) they'll happily connect to what they can.


Bitcoin Classic dev scam would be more accurate, you should pay attention to who writes things. The author of that "proposal" (which has never even had a BIP written for it) is well known for behavior like that in my circles. Then again, it's absurd that you supported something that hardly gave a clear description of what it would do-- beyond hand more power to miners which I suppose served your "pocket financial requirements" well enough that you didn't even care about the details.


Segwit doesn't have much to do with lightning, but good job showing that you've been brainwashed by rbtc. AFAIK no regular contributors to the Bitcoin project stand to gain financially from lightning on Bitcoin, except by virtue of the Bitcoin currency itself becoming a lot more valuable because of more options for using it.

Is it non-standard today because of leaving two elements in stack after script execution instead of one?

Bitcoin Core 0.13 will not accept a P2SH transaction with a witness redeem script until segwit is activated (I've tried this and the transaction is rejected).  Earlier versions of Bitcoin Core should refuse to relay the transaction because it is non-standard (you need at least two input data elements for a standard P2SH transaction and a segwit transaction has a single input element with the signature and public key in the witness data).  If you can get the spending transaction into a block, then it should be accepted by all of the nodes.

I don't know how other node software would handle this.

Is it possible to redeem funded segwit p2sh address today before segwit is activated?

Yes. The "redeemscript" of a segwit p2sh address is smaller than that of a multisig p2sh address.

Great. A normal Tx takes more space if its input uses a multisig UTXO. So, this is not the case for a SegWit address. Right?