Topic: [Fundraise] Fixes for transaction malleability (Read 926 times)
I've pushed a hopefully final version of the error correction coded normative transaction ID branch to my public repository:
https://github.com/maaku/bitcoin/tree/normtxid
This version breaks behavior from what is described in this pull-request by using the regular (not SignatureHash) transaction ID for coinbase transactions. At this time I cannot imagine why you would need a normalized transaction ID for a coinbase transaction. But just because I can't imagine a use doesn't mean there isn't one, and services indexing the block chain need to make a decision about this edge case. The patch in this pull request has the potential to result in duplicate ntxid's for coinbase transactions since the coinbase string which contains the BIP-34 block height is a scriptSig and therefore stripped from the normative data structure.
Additionally, the code now provides error correction coding for arbitrary length base32 strings, and complete coverage with a suite of unit tests. It also corrects two bugs that were found in the encoding algorithm, which were uncovered in the process of writing the tests. All that remains to be done is to write a BIP documenting its inner workings.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
While MtGox's problems are of their own making, the current situation has nevertheless thrown the spotlight on malleability issues which do need fixing. Malleable transactions are a significant pain point for many wallet implementations. And malleability precludes use of interesting advanced protocols which involve the construction of a series of off-chain transactions, which is not safe to do.
You may know me as the guy working on authenticated validation and address indiceas, a peer-to-peer CoinJoin implementation, and various other protocol extensions. Since Monday the 10th of February I've put that work on hold as I help address the most pressing malleability issues. I've implemented an improved serialization format for Pieter Wuille's "normative transaction ID" (ntxid), which is visually distinctive from hex identifiers, includes error correction codes, and is specially tailored to over-the-phone or handwritten usage. It can also be more generally applied to protection of encrypted private keys in paper wallets, and other cases where humans interact with long serialization strings. You can read more about my work here:
https://bitcointalksearch.org/topic/normalized-canonical-transaction-id-for-helpdesk-usage-a-new-base32-encoding-471352
I also would like to work on making mutant transactions are non-standard (and therefore not relayed), and eventually encoding these rules as a soft-fork protocol rule. There's a good skeleton of a BIP describing the necessary changes here:
https://gist.github.com/sipa/8907691
This will require a bit of time, however, to implement, test, push through the standardization process, and get 3rd party wallets to support before deployment. So far I've worked on malleability issues without pay, but I can't afford to do that much longer. If you think these issues are important, please consider making a donation. Funds sent to this address will be used specifically for work on malleability fixes:
1DeZqzJ2f472VaGG6qAVzw5FNq5v4eL7pb
If you have questions or there is another pressing malleability issue you think needs to be address, please post here.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJTAmwGAAoJECsa1YSJj/UDSPIP/RMHh5/GEZyBvhy9LtALicxK
uvbTPUj0c4IsbiQYgB7vc88iPUtgfgytvsMtbq2LHg3j5f0blij46UWHcuydKid6
sDakrcu6k3XxlHArG57cOQQ7GFlPeOi4HQOkiHjSpnkx+yEUThHc/hFJAeDd0WIW
V6HR7NPYr+OAEfj5+moYv7pwdAMGh6M91/mgwzuiAUWpPQJqbvH3rovUStOpdjy0
xIqiGHSgDHYXMX580umNi8CZ8QDvujdjo2MUo18p2caMoV7srMmm4EUm4XbdQTXD
zhiY1CIOd947UF13xmRvG+wrkRK+1mmJkQv9C+5SJSPErXknyZYEvWR0mtNG4/mb
Xnxo26pF9Oma4lZ30C0B2/t/rMV6zBkg2NQ9lZSP03/jrllpTwbdM2Mw7n69HINQ
MG9jFvyoFKNSyRAL9rJfMeai8VOwnjayqQASJniOR0oen+WMtrkXyQYWRZvcEwac
5Cn0fwK8K45+WM5DhdHfArvC9iUMuE/6PTt5b+PJwZn+3HVc+FFfAmdISMteKr9S
8MJbu4hYYY6NHz2/xbNk+Swq8JzxZDD5Dc1G8vCJ86N4cTUZ/pADJCuyOhI1tro3
fy/ar+jMzfCXLCZvcn3pQea+0CSmRaL633QJUSNInaJ+Cv+7NT6HGneODDgwCz6m
xivKJdhS9squJ3SKynl1
=WTsU
-----END PGP SIGNATURE-----
Hash: SHA1
While MtGox's problems are of their own making, the current situation has nevertheless thrown the spotlight on malleability issues which do need fixing. Malleable transactions are a significant pain point for many wallet implementations. And malleability precludes use of interesting advanced protocols which involve the construction of a series of off-chain transactions, which is not safe to do.
You may know me as the guy working on authenticated validation and address indiceas, a peer-to-peer CoinJoin implementation, and various other protocol extensions. Since Monday the 10th of February I've put that work on hold as I help address the most pressing malleability issues. I've implemented an improved serialization format for Pieter Wuille's "normative transaction ID" (ntxid), which is visually distinctive from hex identifiers, includes error correction codes, and is specially tailored to over-the-phone or handwritten usage. It can also be more generally applied to protection of encrypted private keys in paper wallets, and other cases where humans interact with long serialization strings. You can read more about my work here:
https://bitcointalksearch.org/topic/normalized-canonical-transaction-id-for-helpdesk-usage-a-new-base32-encoding-471352
I also would like to work on making mutant transactions are non-standard (and therefore not relayed), and eventually encoding these rules as a soft-fork protocol rule. There's a good skeleton of a BIP describing the necessary changes here:
https://gist.github.com/sipa/8907691
This will require a bit of time, however, to implement, test, push through the standardization process, and get 3rd party wallets to support before deployment. So far I've worked on malleability issues without pay, but I can't afford to do that much longer. If you think these issues are important, please consider making a donation. Funds sent to this address will be used specifically for work on malleability fixes:
1DeZqzJ2f472VaGG6qAVzw5FNq5v4eL7pb
If you have questions or there is another pressing malleability issue you think needs to be address, please post here.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJTAmwGAAoJECsa1YSJj/UDSPIP/RMHh5/GEZyBvhy9LtALicxK
uvbTPUj0c4IsbiQYgB7vc88iPUtgfgytvsMtbq2LHg3j5f0blij46UWHcuydKid6
sDakrcu6k3XxlHArG57cOQQ7GFlPeOi4HQOkiHjSpnkx+yEUThHc/hFJAeDd0WIW
V6HR7NPYr+OAEfj5+moYv7pwdAMGh6M91/mgwzuiAUWpPQJqbvH3rovUStOpdjy0
xIqiGHSgDHYXMX580umNi8CZ8QDvujdjo2MUo18p2caMoV7srMmm4EUm4XbdQTXD
zhiY1CIOd947UF13xmRvG+wrkRK+1mmJkQv9C+5SJSPErXknyZYEvWR0mtNG4/mb
Xnxo26pF9Oma4lZ30C0B2/t/rMV6zBkg2NQ9lZSP03/jrllpTwbdM2Mw7n69HINQ
MG9jFvyoFKNSyRAL9rJfMeai8VOwnjayqQASJniOR0oen+WMtrkXyQYWRZvcEwac
5Cn0fwK8K45+WM5DhdHfArvC9iUMuE/6PTt5b+PJwZn+3HVc+FFfAmdISMteKr9S
8MJbu4hYYY6NHz2/xbNk+Swq8JzxZDD5Dc1G8vCJ86N4cTUZ/pADJCuyOhI1tro3
fy/ar+jMzfCXLCZvcn3pQea+0CSmRaL633QJUSNInaJ+Cv+7NT6HGneODDgwCz6m
xivKJdhS9squJ3SKynl1
=WTsU
-----END PGP SIGNATURE-----
Jump to: