post on segwit features #67
Conversation
| segregating that witness so that changes to the witness does not affect | ||
| calculation of the transaction's hash. | ||
|
|
||
| Previous attempts to reduce malleability have included BIP66 (strict |
There was a problem hiding this comment.
BIP66 was never really intended to fix malleability. There have been other proposals that did, though, like BIP62 (which you mention), sighash_noinput, and normalized txids.
|
Very nice! Just added a few suggestions in comments. |
|
How about: bandwidth reduction for SPV wallets, and for historical sync of pruning full nodes? |
| Avoiding transaction malleability is helpful for anyone monitoring a | ||
| transaction to determine when it is confirmed. Transaction malleability | ||
| also causes problems for spending unconfirmed transactions, or when | ||
| building smart contracts between mutually untrusting users. The lightning |
|
Concept ACK on the post. |
| * [Bitcoin Magazine article on 2015 Malleability attack](https://bitcoinmagazine.com/articles/the-who-what-why-and-how-of-the-ongoing-transaction-malleability-attack-1444253640) | ||
| * [BIP 62](https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki) | ||
| * [BIP 140](https://github.com/bitcoin/bips/blob/master/bip-0140.mediawiki) | ||
|
|
There was a problem hiding this comment.
ajtowns
force-pushed
the
segwit-features
branch
2 times, most recently
from
05b87c8
to
d3ce8c0
Compare
|
Nice - ACK |
|
Awesome post ACK |
|
ACK |
|
concept ACK |
|
Sent some proposed edits to AJ here: ajtowns#1 Tested ACK with or without the edits as long as the YAML "excerpt" field from the proposed edits is included in the final merged pull (without that, it doesn't render well on the main page). |
| version: 1 | ||
| --- | ||
| 1. toc | ||
| {:toc} |
There was a problem hiding this comment.
you can also use {% include _toc.html %} for TOC style at https://bitcoincore.org/en/faq/optin_rbf/
There was a problem hiding this comment.
That's done in the proposed edits. :-) BTW, that really is a nice TOC style.
|
ACK from me. |
|
@harding merged your changes, but reverted/rewrote some of the bits on malleability. segwit fixes signer malleability as well as third-party malleability; tadge tells me it's actually possible to implement lightning without 3rd party malleability fixes, and its signer malleability that's need for the full lightning stuff. would you mind looking over what i've written, and checking it reads okay? |
|
@ajtowns segwit only fixes signer malleability for m-of-n multisig where at least one of the original signatures is included in the replacement transaction. Signer malleability for single-signature transactions or where an entirely new set of m signatures is used in multisig is still a possible form of malleability. This is easy to prove: the necessary set of signers can change the vouts, the nSequence, the locktime, or the the version number, thus changing the txid even when segwit is used for every scriptSig. I've had the same conversation with Tadge and Joseph. In that case you have 2-of-2 and one of the parties would never change its signature (because they'd lose funds), so there's no true signer malleability. We could probably explain all this in the doc, but I think there will likely be very few readers who care about that level of detail. I'll take a look over the other changes now. |
| the hash 683f...8bfa | ||
| instead. | ||
|
|
||
| Segwit prevents third-party and signer malleability by allowing Bitcoin users to move the |
There was a problem hiding this comment.
Segwit cannot prevent signer malleability, only third-party. The signer can always change the inputs and/or outputs.
There was a problem hiding this comment.
It prevents malleability by generating a new signature without changing inputs or outputs; and that in turn is what's needed for the cited benefits for lightning. I don't think "third-party malleability" covers that, but if "signer malleability" isn't the right term, I don't know what is.
There was a problem hiding this comment.
Partial-signer malleability, maybe.
There was a problem hiding this comment.
How about "scriptSig malleability" -- would that be accurate ? https://en.bitcoin.it/wiki/Transaction_Malleability
There was a problem hiding this comment.
Technically true, but it leaves a lot to be desired from a descriptive point of view. Maybe "unauthorized malleability"?
There was a problem hiding this comment.
Technically correct is the best kind of correct! I've redrafted, let me push an update.
|
3c3b5b5 LGTM. Thanks! |
- Add excerpt - Use fancy table of contents - Use h3 for sub-subheads instead of h4 - Add image illustrating linear versus quadratic scaling - A bunch of edits that I think improve the flow
…ers for lightning
…transactions improves
ajtowns
force-pushed
the
segwit-features
branch
from
e7151f4
to
46fd88f
Compare
|
rebased on top of 194a282 and reworded "discarding sigs" section to address luke-jr's concern. should be good to go now (unless the date needs to be bumped to 2016-01-26...) |
|
Without having re-reviewed at this time, I think it is higher priority to publish an initial version of this, than to continue making it perfect on this PR. Further changes, if necessary, can be made after this is merged. |
|
I am very glad to see this, and hope to see more posts like this of a similar quality in the future. I would like to see a section on 'weaknesses' and 'risks'. Weaknesses would include things like what sorts of changes need to be made to existing infrastructure and SPV clients, and 'risks' would include things like the general risks associated with soft-forking. (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html) I think a big step for improving communication is to openly state all risks and shortcomings. When that part gets neglected, people tend to point them out in ways that are either incorrect, overblown, or otherwise misleading. |
|
will SW fix other non-signer forms of malleability? |
|
@ajtowns and everyone: I came here to express my appreciation and gratitude for all the work on this. I'm loving the new website and all the posts you're putting up. I think this is already going a long way to form a strong communication bridge with the wider community. @btcdrak pinged me about the site and various posts and I'm looking forward to helping out with other site content in the future. |
Here's a post on the features of segregated witness other than the blocksize. Does it seem interesting for the new website?
It's a bit one-sided, in that it only lists benefits. I think maybe it would be better to include costs (and a corresponding "Who loses?") too? Thoughts?