BUIP037: Hardfork SegWit

[bitPico]

Only a few people understand SegWit and it should not be used as a guide to coding Unlimited proposals IMO. Mailability is fixed in a few lines of code and can be forked in (see the topic). The other issues are not high priority issues IMO. I think this proposal should be revised and revisited at a later date.

 

[drwasho]

@deadalnix how will this proposal handle transactions that spend time-locked coins from an address where the private keys have been destroyed post-signing?

 

[Hyena]

SegWit as a hard fork? This has to be a joke. The only thing special about SegWit is the fact that it is a hack to achieve many things with a weird soft fork which puts us in enormous technical debt (something bitcoin classic tries to get rid off)

if we're going to do a proper protocol upgrade then let's do things the way they should be done in software development, okey? Fix quadratic hashing problem at first. TX malleability is not really a bug and should not really be fixed, ever. It allows easily testing applications against double spends because a TX malleability transaction is actually a double spend. Double spends can still happen you can't fix that, so why fix TX malleability? it will just make it harder for devs to spot bugs in their software if they can't do TX malleability attack against themselves on the testnet.

 

[drwasho]

SegWit as a hard fork? This has to be a joke.

Not a joke, and your 'tone' for lack of a better word isn't constructive... but I'll answer your points anyway.

The only thing special about SegWit is the fact that it is a hack to achieve many things with a weird soft fork which puts us in enormous technical debt

No arguments there.

Fix quadratic hashing problem at first.

The changes required to fix quadratic signature hashing and malleability both would require hard forks, so packaging them together makes sense.

TX malleability is not really a bug and should not really be fixed, ever. It allows easily testing applications against double spends because a TX malleability transaction is actually a double spend. Double spends can still happen you can't fix that, so why fix TX malleability?

AFAIU there are two kinds of malleability:

1. When the user creates two conflicting transactions using the same input that spends the same output(s)
2. When a third party alters a user's transaction that has been broadcast to the network

You are correct when you say segwit won't fix the first kind of malleability, and that isn't it's goal. Segwit/flextrans/BUIP37 attempts to fix the second kind: third party transaction malleability.

Segwit does this in a clever yet hackish way via soft fork, but doesn't prevent users from creating 'legacy' outputs that are vulnerable to third party malleability. It's a poor form of security and feature deployment.

Lastly, fixing third party transaction malleability makes the development of layer 2 transaction networks (i.e. lightning) easier, which may relieve on-chain volume and fee pressure for users.

 

[deadalnix]

@deadalnix how will this proposal handle transactions that spend time-locked coins from an address where the private keys have been destroyed post-signing?

We can support the old format for a while, but at some point we'll have to deprecate it. At this point, this tx won't be valid anymore.

This isn't a problem that is specific to this BUIP. All soft fork have this problem - they make some tx invalid, and removing the old tx format is a soft fork.
[doublepost=1490260300][/doublepost]

TX malleability is not really a bug and should not really be fixed, ever. It allows easily testing applications against double spends because a TX malleability transaction is actually a double spend. Double spends can still happen you can't fix that, so why fix TX malleability?

The good thing with people that have no idea what they are talking about is that they end up self contradicting in no time. For instance, you need X to test double spend, followed by double can still happen - and so you can test them.

 

[Hyena]

@drwasho
Delivering as many enhancements as possible with a single hard fork is indeed a good idea. However, calling it a SegWit hardfork is unnecessary. A hard fork allows a more clean implementation of all the aspects of the protocol upgrade.
Yes you can say there are 2 types of TX malleability but in essence there is not. It is dumb to babysit developers so that the "2nd" kind of TX malleability wouldn't be possible because the sender of the TX can still double spend using the same inputs and the same outputs. TX malleability will still exist it will be just less convenient to execute it. And the applications accepting 0 confirmation transactions will still have to be aware of the double spending possibility.

@deadalnix
Why so hostile? Just because someone has a different opinion on something does not mean they have no idea what they are talking about. I guess you're no better than the Core's community. Fixing the "2nd" kind of TX malleability is bad because it makes it less likely that developers deal with it and thus vulnerabilities are bound to happen.

Also I don't understand why LN requires so desperately that the 2nd kind of TX malleability is fixed? Users can still construct a TX with same inputs, same outputs but different TX hash. It will mess up LN then and the fix ends up not really being a fix.

 

[deadalnix]

If you don't understand, that's fine, but I suggest you ask more question and assert less positions.

By removing 3rd party malleability, you require both party to coordinate to maleate the transaction. This prevent attack on LN, but more generally make sure some 3rd party won't break your chained tx (Hi BitClub !).

 

[Hyena]

@deadalnix
makes sense. TX hash should be in sole control of the one who has control over the private keys of the TX inputs. Not because it pushes some double-spending possibilities under the carpet but because it is conceptually more beautiful design for the structure of a BTC TX.