Segregated Witness, Segwit - Discussion

Can anyone elaborate on the idea of Segwit.

I get the concept , I don’t get the usefulness (or for the lack of presented details in the lecture)

The whole point of signature is to validate the transaction , so , what’s the point of separating it from the transaction and ,I assume, still generating an identification hash so that the transaction part can be validated … and then how does it tie in to the separated signature ? Where is it stored meanwhile or how does it connected to the transaction ?

I get the idea of transaction malleability and it being the main reason for Segwit … but can’t wrap my head around the process of how it’s actually done.

Also , on the subject of transaction malleability;
Can anyone explain in plain language how is it possible to change the signature hash and still have the transaction be validated ? And in the world of p2p transactions , how would I do that
I.e wallet ? Code ? Being a Node ?

Huge thanks , I think it’s crucial information that’s just not entirely in the lecture , yet very important for core understanding !

The signature was actually moved to a different data structure that is limited to 4MB/block and every Segwit enabled node must store this information.

This was the way how soft fork was achieved (it was planed as a hard fork at first), by keeping the block size at 1MB old nodes can still function and see the blocks as valid, however they are not able to process Segwit transactions.

The reason why one could change the hash signature, before it gets mined is because one could change the unlocking script (the witness) that defines how the receiver can then spend this funds in the future. You can learn more about that in the Bitcoin programing course :slight_smile:

1 Like

ITs not clear to me how you could change the Tx ID without altering the blockchain … I think you didnt explain that quite well … and also, may I suggest you add a search engine within the forum? … its not so clear if I use the magnifying glass at the top of the page, I would be looking within this forum thread or in the whole forum

Transaction malleability can be exploited before the transaction is confirmed. :slight_smile:

What is wrong with the magnifying glass? It works fine for me. You can search the forum or the topic if you check the Search this topic

1 Like

How exactly does Bob change Alice’s signature in the tx? Im not clear on how someone is able to alter contents of a tx such as signature of another use?

The witness is part of the receivers data. So it can be changed by the receiver.

3 Likes

Hi block buddies!

Quick question, Because Segwit removes Sigs from Tx hash, How are they then later identified as belonging to each other?

Thanks in advance!

The signature hash is part of the tx data so the nodes can query the witness. If its not found, it means it doesn’t exist.

1 Like

Hi, I have a question regarding centralisation and block size.

I understand that an increase in block size results in increased miner centralisation because of the fact that there becomes increased barrier to entry with storing the blockchain (memory) and also with needing better hardware (which im not too sure as to why besides storage capabilities) and I also completely understand the issue with propagation speeds and the increase in forks and stale blocks which will also lead to slower confirmation times.

But my question is that in the future, using the logic of running a node of the bitcoin blockchain and needing enough storage space to have a full copy of the blockchain… is there any potential issue with miner centralisation in the future as the blockchain increases in size? as more blocks are appended to the chain and the blockchain becomes much larger to store in full in say 10, 50, 100, 200 years etc will the availability of storage space to people increase at a relative rate to the increase in storage capacity needed to be a miner? Or will the increase in the blockchain size be quicker than the increase in storage capabilities? - if this is the case I’d imagine that centralisation could increase over time for this reason?

Also following on from this idea of the blockchain constantly increasing in size, is there any sort of issue that could arise in the future from the time it takes for a wallet to traverse the blockchain and identify UTXO’s that are assigned to its private key? Lets say a transaction is made in 2010 and it is assigned to a particular private key, and 100 years in the future someone would like to spend that UTXO how long would the wallet need to traverse the blockchain? And would all wallets need to traverse that far back to see if there are any other UTXOs it could have assigned to its private key?

Depending on if this could be an issue in the future it could result in tx’s becoming slower or perhaps more correctly it would take longer for someone to make a transaction after a wallet is loaded up, due to the fact that it will take a much more significant amount of time for a wallet to build a transaction?

Would love an answer to both these questions! :slight_smile:

Given the current rate of storage sizes I don’t see this as a problem for quite a while, atm 20 TB hard drives are not to hard to get which would allow you to store the entire Bitcoin blockchain for years to come.
After 10 years the block size is about 300GB, for simplicity lets say we require 500GB/10 years for Bitcoin, that is 1TB of data for 20 years, this means a 20 TB HD would be able to store 400 years of blockchain data. I imagine in that time a LOT larger hard drives will be developed :slight_smile:

When you import keys into a new wallet the wallet scans the blockchain for UTXOs the wallet can spend. Depending on the HD speed this can take a while, but its only an issue the first time you initialize the wallet. Once you want to spend the UTXO, the wallet already knows where that UTXO is stored so the transaction can execute right away without needing to search for the required UTXO again, even if it is 100 years old :slight_smile:

3 Likes

Awesome thank you for the responses, definitely helps clear up the questions!

1 Like

I did not fully understand the concept of how signatures could be changed until I had watched the Andreas M. Antonopoulos video here https://youtu.be/Vux6o7gSnhE which was linked in the Popular links section. So if you are having difficulties in understanding the concept I suggest watching it.

Regards,

Phil.

2 Likes

Hi Filip,

I am a bit confused. How is it possible that Bob can change any piece of data from the transaction of Alice? Alice´s wallet creates a transaction and starts distributing it to the nodes. Every node, when it receives the transaction, adds it into their own mempool. How can bob in that process change the signature and propagate it so that all the nodes also have the change?

I think the main problem with the explanation in this video, at least in my opinion, is that I need more details and a structure of chronological events. Could you please explain step by step what happens in that process? For instance:

  1. Alice´s wallet creates the transaction with her signature.
  2. Bob receives the tx from alice and changes the signature.
  3. Bob propagates it to the nodes.
  4. Nodes add it to their mempool.
    etc.

Thank you in advance.

Hey @CarlosKoljonen
The reason why malleability can happen is because the witness data is related to the receiver, not the sender. So that part can be changed by Bob and thus it will change the txid. A good explanation was described in the video a student posted just above you by Andreas: https://www.youtube.com/watch?v=Vux6o7gSnhE
To learn how this happens in detail you can check out Bitcoin programing course :slight_smile:

2 Likes

@filip what are the live examples of hard forks and soft forks that has happened already ? i am bit confused about how updates gets into an action in a consensus , who proposed this updates and how miners and nodes reacts to it and mainly how decision are taken in bitcoin blockchain i read somewhere that the original version of bitcoin blockchain will be as it forever so how these updates could possibly takes place ?

Most well known example of a soft fork is of course the Segwit update. An example of a hard fork would be the BCH hard fork and the Ethereums DAO hack.
If you want an example of a blockchain that hash constant hard forks you can have a look at Monero, that utilizes these forks to change the mining algorithm to remain ASIC resistant.

There is a process how updates are handled, they are first proposed by the community on the bitcointalk forum, if they are well received they then get written as a design document called BIP. These are further discussed by the community and eventually get accepted and implemented in the protocol.

Once a BIP is implemented, there is a set time specified by a block height at which point the upgrade will take effect, so all blocks up to that point are treated by the old rules and after the said block the new rules apply. This keeps the blockchain immutable and avoids the need to remine these blocks by a new rule. :slight_smile:

1 Like

If SegWit removes the key element of a contract or transaction which is the proof that a specific party has authorised that particular transaction then it is not fool proof.

It does not provide any a way for signature data to be" attached or legally linked" lafterwith the transaction data.

Segwit doesn’t remove the signatures completely, but replace it in another datastructure that is not included in the hashing of the transaction

1 Like

How can you change a signiture, even a ‘little’ without invalidating it? Shouldn’t the valid signatures only be producable with Alice’s private key?
Or is Bob a Node owner and he tampers with the signature in his own node and than lies to the network about it checking out with Alice-s public key?


only possible if the victim’s node only communicates with the hacker’s node