Segregated Witness Sotf fork (Segwit) Pros and Cons

[Lee Adams]

If signature data is removed, there is no way to calculate the TXID for each transaction

OK, I've done the reading as @johnyj suggested, as I now understand it: a non-segwit transaction includes the signature to create the txid. A segwit transaction does not include the signature. That's why the signature can be safely trimmed and why it is a fix for transaction malleability.
[doublepost=1459420364][/doublepost]Also my understanding is now that when a segwit transaction has been sent to a non-upgraded wallet's address, that wallet cannot see it and it will not show up unconfirmed (as a non-segwit transaction would do). Once that segwit transaction is included in a block, it will show up in the wallet and can then be spent.

i.e. non-upgraded wallets WILL be able to spend segwit transacted coins.

 

[jbreher]

That does not quite match my understanding, to wit:

SegWit transactions still include signature. However, the signature is not counted as being included in the 'size' of the transaction (even though it still is there). In SegWit, the signature is also not part of the data which is hashed in order to generate the transaction ID. It is this latter bit that fixes transaction malleability, and also is completely independent of the first aspect (i.e. they could be deployed independently).

While the signature data could be trimmed, all signature data for all eternity back to the Genesis Block is required to validate the blockchain upon first booting a fully-validating node. For any transaction without a signature cannot by definition be validated. Only after fully validating all back data can a node trust that data. Only after this validation can the sigs be pruned - lest the node need to trust unverified data.

As to your second chunk, a meaningful question to ask might be 'Why would a fully validating node (i.e. non-upgraded wallet) trust a blockchain containing a transaction that it is unable to verify (i.e. a transaction that has no discernible signature data - or a SegWit transaction)?'. The simple answer is that it cannot, as that would by definition be a non-validating node.

Hmm.

 

[adamstgbit]

why dont they just leave everything as is and simply change the way they compute TX_ID and incress block size limit.

changing the way we count block size to omit the sigs which is part of the block, is just dirty!

it feels like they trolled the block size!

 

[Dusty]

While the signature data could be trimmed, all signature data for all eternity back to the Genesis Block is required to validate the blockchain upon first booting a fully-validating node

That's true in principle, but in reality no recent (core or classic) client does it, because there is no point in validating signatures when you know there are thousands of more recent blocks that already did that.
So they just compute block headers and validate the PoW up to a certain point and then they start validating signatures.
While Core is doing that up to a point hard-coded in the source (a so-called checkpoint), Classic and Unlimited are proposing to it dynamically, for example "up to the block of 24h ago".
Another equally valid proposal could be for example "up to 1000 blocks ago".

In my opinion both techniques could be combined:

• starting to validate signatures (a very expensive process) only after a recent block chosen dynamically

• using hardcoded checkpoints (for example one every 100K blocks) to be sure that we are fed the real bitcoin chain and not an entirely new one

[doublepost=1459952941][/doublepost]

segwit has cool tech, it allows many new usecases, it just shouldnt be stealth released onto mainnet under the guise of scalability. The problems with segwit are not its tech, but the marketing, the process abuse and other aspects.

+1

 

[jbreher]

So we have effectively abandoned the principle that Bitcoin is trustless? I find that rather disturbing.

I guess I can understand a motivation for this, but I thought had understood that the reference client was always to be trust-free.

If all implementations take the checkpoint approach, then eventually nobody will be able to claim definitively that they have an honest and complete record of all transactions. For such would be a lie.

The approach you describe for Classic or Unlimited seems especially dangerous. How is the network to reboot itself following a world-wide blackout caused by mass coronal ejection or similar? It seems that, if all nodes go down simultaneously, there would be no way to re-establish an honest checkpoint.

 

[Lee Adams]

@jbreher

If all implementations take the checkpoint approach, then eventually nobody will be able to claim definitively that they have an honest and complete record of all transactions. For such would be a lie.

The difference is that no node can prove 1000% that all transactions were valid, but that sort of becomes irrelevant; history has been written. On the issue of trust, I'm happy to trust in this system. The likelyhood of my transaction being stolen like this is infinitesimal.

Finally, this is how it has [nearly?] always been. This is how bitcoin worked since the early days (possibly from the start, but I'm too lazy to look it up). Nothing to do with seg wit.

 

[Dusty]

I guess I can understand a motivation for this, but I thought had understood that the reference client was always to be trust-free.

If all implementations take the checkpoint approach, then eventually nobody will be able to claim definitively that they have an honest and complete record of all transactions. For such would be a lie.

Well: you can keep witnesses if you want (actually new full nodes will have to do it to relay last blocks to other peers), and if you really want, you an always modify the client to re-validate all the signatures.

But what's the point? We know what is the correct chain right now, and we can be quite sure it will not be orphaned up to a certain point: surely not until (for example) 1000 blocks ago.

Yes, it would be technically possible to create a whole new chain orphaning 1000 valid blocks but that would break havoc on bitcoin and it could possibly means his end.

So, if you now know the correct blockchain because you validated from the beginning, you can save a safe checkpoint (for example 1000 blocks ago) not only to avoid rechecking all the signatures you already have validated, but even more importantly to be sure that a new client will get to the right chain and not fell prey of a sybil attack.

 

[jbreher]

You claim that 'we' know the correct chain. In this case 'we' is undefined. How does any single party (the only entity worth speaking of) know the correct chain?

I get that such a trust-requiring system can work. Mostly. The problem is that it will work only until it doesn't.

How is the network to reboot itself following a world-wide blackout caused by mass coronal ejection or similar?

 

[Dusty]

You claim that 'we' know the correct chain. In this case 'we' is undefined. How does any single party (the only entity worth speaking of) know the correct chain?

connect to your bitcoind and ask for the hash of last block.
To be sure, ask the hash of the block of 1000 blocks ago, write it down, and possibly write it in the bitcoin source you will use next time: that will help you to not fell prey of a sybil attack, while skipping all signature validations because that hash means your node (the one you asked the hash), has already done all the work.

How is the network to reboot itself following a world-wide blackout caused by mass coronal ejection or similar?

Not differently from now: skip validation up to a know good block, and then verify all the rest.