Hello sir, check the post above your last one, i explain that on it, at the end you will have a PDF for a more graphic example.
Could be possible to apply on every cryptocurrency that use the same UTXO as bitcoin that does not have the SegWit update, on Ethereum is not possible since it use the Account model.
Hope this gives you a clear view of the subject, keep learning! 
If you have any doubt, please let us know so we can help you!
Carlos Z.
@filip what I donât understand in the concept of Transaction Malleability is this:
How can the receiver (Bob) of the transaction change the signature of the sender (Alice) of this transaction? Isnât the whole point of the tx signature that only Alice can sign this transaction? How can it still be valid after alteration from Bob?
Hereâs how the transaction malleability attack works. Alice creates a Bitcoin payment transaction, and sends it to her peers. The original Bitcoin implementation was underspecified with respect to how txids were actually calculated. Therefore, itâs possible for Aliceâs peers to slightly modify the transaction. Suppose Bob is a peer of Alice, and wants to initiate a transaction malleability attack against Alice. The inputs, outputs, and payment amount are all cryptographically signed, so Bob canât steal money or make any semantic changes to the transaction. However, Bob can make some changes that donât change the transaction semantics, but do change the computed txid. At this point Bob will broadcast the transaction with a new txid to the rest of the network. At this point itâs a race to see which transaction will actually be accepted by the network: the original transaction created by Alice and relayed by her good peers, or the modified version created by Bob. The attack is called âtransaction malleabilityâ because Bob was able to modify the transaction, even though the transaction was supposed to be immutable.
The signatures just need to be valid.
An analogy for changing the signature in a transaction: (for example the signature needs to be 10)
Sig: 5+5=10 but 3+7 is also 10.
This modification will alter the transaction ID Because if 1 slight change is made, the Hash of the transaction will be completely different.
Each node can choose how long they keep them in their mempool.
-mempoolexpiry= n (default is 2 weeks)
Transaction malleability was only possible with unconfirmed transactions. So miners have no problem with it
By using a different way to calculate size and Removing the signitures next to the transaction. The transaction section without signatures are still physically 1 MB max, so old non segwit nodes still accept those blocks (but without signatures) old nodes donât get the signatures.
After reading the SegWit course, Iâm wondering whether SegWit and the Blockheader use for the Merkel tree proof are correlated or layered in some way, since I donât see yet what was changed in the structure of the block by the SegWit update. Am I yet guessing ignoring what was the structure before the SegWit Update?
Thanks a lot. Before I go and correct my self-understanding.
Hi,
Whatâs the difference between SegWit compatible and SegWit native?
It seems like this malleability is not really a technical vulnerability but rather a confusing property which allows uninformed users to be manipulated?
@filip isnât it a problem if the non-Segwit nodes interpret Segwit transaction outputs as âanyone can spendâ? It seems like they may then accept a transaction from a random person spending those coins. Obviously this is wrong so I must be missing something
Hi! I would like to leave my feedback about the final quiz.
The way the first question (âWhat are some of the issues that Segwit tried to solve?â) was formulated made me answer incorrectly, as the verb used is âtriedâ instead of âmanaged toâ or âaccomplished toâ.
I was aware that segwit has solved âfull blocksâ, âtransaction malleabilityâ and âexpensive on chain transactionsâ. However, during the course only the first 2 issues have been presented as the main reasons why the softfork was introduced, while the third has been presented more as an additional benefit. Therefore, since the question used the verb âtriedâ I have deliberately excluded the third issue; I would have selected all the three answers if the phrase had any verb implying the final achievement.
I hope it helps!
Sending coins from Native SegWit account will give you the smallest transaction sizes, which will get you the lowest fees, but it uses the new Bech32 address format. Not all wallets/exchanges support sending to Bech32 addresses.
Legacy SegWit works by basically nesting a SegWit transaction in a Script Hash (P2SH) transaction, so it uses the Script Hash address format used by multisig wallets. Any Bitcoin wallet can send to a multisig address, so this is the more compatible version, but since itâs a wrapped transaction itâs a bit bigger than a native SegWit transaction, so the fees arenât quite as low.
Segwit native addresses (bech32) start with bc1âŚ
Segwit compatible (using P2SH) start with 3âŚ
Yes, but still. Itâs hard to rely on unconfirmed transactions if the transaction ID can change. The Lightning network also needs to rely on the txidâs of unconfirmed transactions.
But not anyone can actually spend it. Old nodes get a stripped down version of the blockchain without the signatures. So the physical size of blocks are never more than 1MB. So old nodes are becoming basically like a light client without having all detailed information.
I donât understand. Old nodes (i.e. non-Segwit) are unable to check if a transaction is correct? If so, how come this did not break the network?
This chart was already posted back in Nov 19, but my question addresses a different matter: According to the chart segwit adoption has increased up until aprox March this year when it hit close to 60% but since then it has decreased - what are the reasons for this recent decrease? And how can adoption of a new rule actually go backwards? Can nodes reject a rule after accepting it?
https://charts.woobull.com/bitcoin-segwit-adoption/
Filip,
You said in the video that the elimination of the signature from the transaction reduces the size of the transaction and thereby solves the 1-mB-limit crowding-problem. In the previous video you said that an increase to 2 mB would not solve the crowding problem for very long because of the steepness of the slope of the block-size curve. But it seems to me that the elimnation of the signature is also just a temporary relief as far as the crowding-problem as well as the attendant fee-problem is concerned. So once you have a new wave of adoption, the fees will once again go up. Moreover, as long as the overall transaction capacity is limited by the block sizes and the 10 minute wait-time, you necessarily have a problemâor so it seems to meâwith exchanges trading virtual coins (like paper gold in the stock market) because there simply is no way to accommodate high-speed trading on the actual blockchain. Is that correct?
They still can validate and check every transaction from non-segwit blocks. But because itâs been 3 years already, Most nodes have updated segwit. Old nodes are basically becoming a light client for the segwit blocks since most blocks are now segwit blocks. Every bitcoiner will agree that segwit is just necessary to make bitcoin better. Would you update your internet connection if it was cheaper and better? Or would you prefer to keep using old dial up modems with terrible bandwidth.
So most nodes have segwit, but not every user needs to use segwit native addresses. In a soft fork, everybody has more time to upgrade if they want.
The hard-coded consensus rules are still valid. It was a gradual backwards compatible update.
Check out my own node status:
In 2017 BTC hit all time height 19k plus and could break above 20k. It is because the programmed block size are filled up? or this only affect transaction fees which will decrease mass adoption?
I actually thought demand and supply determine the price of bitcoin.
