📅 Original date posted:2015-11-05
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Right. Wallets are covering malleability in acceptable ways. Normal
user to user payments aren't (or at least shouldn't be) affected by
malleability.
Problems appear in second level and third level malleability, when
Alice sends txB to Bob which spends from txA which is unconfirmed. If
txA changes txid, txB becomes useless and invalidates Alice's payment.
Looking at scriptPubKeys instead of transaction IDs doesn't help in
this context.
This is the reason why some type of contracts are not workable or not
100% safe. One can't pre-sign a refund transaction with an nLockTime
in the future: the payer will provide the funding transaction ID from
which the refund tx will spend, but if the transaction ID of the
funding transaction is affected by malleability (third party
malleability, since the signer doesn't have interest to do so) the
refund tx becomes useless.
On 11/5/2015 10:25 PM, Jorge Timón via bitcoin-dev wrote:
> On Thu, Nov 5, 2015 at 8:36 PM, Luke Dashjr <luke at dashjr.org>
> wrote:
>> Ok, then my point is that "signature malleability" is not
>> particularly problematic or interesting alone, and the only way
>> to get a practically-useful solution, is to address all kinds of
>> malleability.
>
> I disagree. Segregated witnesses, for example, doesn't solve all
> kinds of malleability and is very useful in some practical cases by
> solving all signature malleability. As said, we don't want to
> eliminate all forms of malleability (for example, replace by fee),
> although we may want to "address them" at some level. As you have
> said, wallets should be looking at scriptPubKeys, not transaction
> ID, but that is orthogonal to SW, a normalized tx ID and signature
> malleability.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJWO9w7AAoJEIN/pSyBJlsR2BsH+gMwxJ/isiWfJF12LJ9s4wat
Bd/K2Ld+Lyk5BRs+6rQzv5NeeYjYC3FtNFV+z1Z1dMDd752cUfEZqQA9dt9nl0E7
BEia3RSFii1k2L/4xwiIWKZM20qoiykou41J56GZrJa9SoP+9kg8iLq8CokahakP
PLjfBrTylJBsgq34foPPaOH9ckOa/RJpx3WHrRFTPhxbTCm1Ezv6jAZmYr9tTi1h
afzU0YayzLUIb9xH8vfODY2qMJ91uguTUZYCGuopDYhom5GMw8zss0kG5FdEZrEQ
Z7srQmKQ0SRMtiSlg6lg3d8TS5Mv1gIp1HcL+gtMFroi38pJS8dXT65nGjg0Epc=
=ZhVA
-----END PGP SIGNATURE-----
s7r [ARCHIVE] /
npub1j3…cwg9h
2023-06-07 17:44:08
in reply to nevent1q…h6fv
Author Public Key
npub1j3u42vq63qzs2nyddgkf4s4t7pa85x855vas54e6yauxsvpf2wcsacwg9hPublished at
2023-06-07 17:44:08Event JSON
{
"id": "cba2b3268af2cbc747b21da815d244e20806568883bdd20146fa12db7dee8980",
"pubkey": "947955301a8805054c8d6a2c9ac2abf07a7a18f4a33b0a573a277868302953b1",
"created_at": 1686159848,
"kind": 1,
"tags": [
[
"e",
"59e25977e31b6de547dc99825f6bc9fc8d0d57f8dc5978611471ad70444e93b2",
"",
"root"
],
[
"e",
"554b4b8951e9dd74ab966ec1671b7a97acc4a22a7ea73cd0d4b5ac00477ef604",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-11-05\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nRight. Wallets are covering malleability in acceptable ways. Normal\nuser to user payments aren't (or at least shouldn't be) affected by\nmalleability.\n\nProblems appear in second level and third level malleability, when\nAlice sends txB to Bob which spends from txA which is unconfirmed. If\ntxA changes txid, txB becomes useless and invalidates Alice's payment.\nLooking at scriptPubKeys instead of transaction IDs doesn't help in\nthis context.\n\nThis is the reason why some type of contracts are not workable or not\n100% safe. One can't pre-sign a refund transaction with an nLockTime\nin the future: the payer will provide the funding transaction ID from\nwhich the refund tx will spend, but if the transaction ID of the\nfunding transaction is affected by malleability (third party\nmalleability, since the signer doesn't have interest to do so) the\nrefund tx becomes useless.\n\nOn 11/5/2015 10:25 PM, Jorge Timón via bitcoin-dev wrote:\n\u003e On Thu, Nov 5, 2015 at 8:36 PM, Luke Dashjr \u003cluke at dashjr.org\u003e\n\u003e wrote:\n\u003e\u003e Ok, then my point is that \"signature malleability\" is not\n\u003e\u003e particularly problematic or interesting alone, and the only way\n\u003e\u003e to get a practically-useful solution, is to address all kinds of\n\u003e\u003e malleability.\n\u003e \n\u003e I disagree. Segregated witnesses, for example, doesn't solve all\n\u003e kinds of malleability and is very useful in some practical cases by\n\u003e solving all signature malleability. As said, we don't want to\n\u003e eliminate all forms of malleability (for example, replace by fee),\n\u003e although we may want to \"address them\" at some level. As you have\n\u003e said, wallets should be looking at scriptPubKeys, not transaction\n\u003e ID, but that is orthogonal to SW, a normalized tx ID and signature\n\u003e malleability.\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v2.0.22 (MingW32)\n\niQEcBAEBCAAGBQJWO9w7AAoJEIN/pSyBJlsR2BsH+gMwxJ/isiWfJF12LJ9s4wat\nBd/K2Ld+Lyk5BRs+6rQzv5NeeYjYC3FtNFV+z1Z1dMDd752cUfEZqQA9dt9nl0E7\nBEia3RSFii1k2L/4xwiIWKZM20qoiykou41J56GZrJa9SoP+9kg8iLq8CokahakP\nPLjfBrTylJBsgq34foPPaOH9ckOa/RJpx3WHrRFTPhxbTCm1Ezv6jAZmYr9tTi1h\nafzU0YayzLUIb9xH8vfODY2qMJ91uguTUZYCGuopDYhom5GMw8zss0kG5FdEZrEQ\nZ7srQmKQ0SRMtiSlg6lg3d8TS5Mv1gIp1HcL+gtMFroi38pJS8dXT65nGjg0Epc=\n=ZhVA\n-----END PGP SIGNATURE-----",
"sig": "55f6e065ef1de5c0af09bbcee14866abf1705a51da163e7228b44a405319c57fe65b6816f6dc484cca9f5a90355d0a550fd8c2f3d1f84cc61ab710f8bbf18f5f"
}