-----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://bitcointalk.org/index.php?topic=471352.0

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-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pieter Wuille proposed a "normative transaction ID" (ntxid)[1] -- a hash covering the same data which is signed in the standard transaction types. A transaction cannot be changed in such a way as to alter this ntxid without also invalidating a the SIGHASH_ALL signatures typically used by wallet software in the standard transaction types.

Having some experience in running a front-line customer service helpdesk, I know that a significant amount of time and therefore money can be wasted transmitting long strings of information over the phone (e.g. a 64-character hash string), or from handwriting which can be worse. Also since we already have a notion of a 32-byte transaction hash encoded as a 64-digit hex string, it could be very confusing for users who do not understand the difference.

I proposed and have implemented[2] an alternative encoding format for these normative transaction identifiers. It is also available as a patch against bitcoind itself[3] (I wasn't sure if I should open a separate pull request from sipa's). It differs from the presumptive default 64-character hex encoding in the following ways:

1. Always starts with the two characters: "tx".
2. 64-digit base32 instead of base16, and therefore is visually distinctive in that it includes the full range of alphanumeric digits.
3. Automatic correction of up to 2-characters of input data, and highly probable detection of further non-recoverable errors (approximately 1:1,000,000 chance of a false positive).
4. Uses Phil Zimmermann's z-base-32 encoding alphabet[4], which provides better resistance to transcriptive errors than the RFC 3548 standard.

The encoding format is in fact entirely general. It is able to transform any power-of-two sized string (>= 16 bytes in length) into a base32 string a multiple of 31 digits in length, with each 31 digit grouping containing error correcting codes capable of recovering from a single-digit error in the base32 input. It uses CRC polynomials for the error correction capability[5], which requires 5 error correction digits per 26 digits of input, instead of the theoretically optimal 4, but is much, much easier to implement correctly then available non-patented error correction codes.

The encoding format should be applicable to other uses as well, such as exporting private keys. It has additional features to support this sort of application: the encoding of a few extra bits of information in the padding structure, such as whether the private key is encrypted, and whether the public-key should be compressed.

Aside: if you like this work, please consider donating a few coins to 1DeZqzJ2f472VaGG6qAVzw5FNq5v4eL7pb. I work full-time on core bitcoin improvements, funding myself entirely through community donations. Any donations received to this address will be used to further address malleability concerns, such as an eventual soft-fork to eliminate known forms of malleability entirely.

[1] https://github.com/bitcoin/bitcoin/pull/3656
[2] https://gist.github.com/maaku/8996338
[3] https://github.com/maaku/bitcoin/tree/normtxid
[4] http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt
[5] http://www.drdobbs.com/article/print?articleId=184401662&siteSectionName=
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJTAlzpAAoJECsa1YSJj/UD2EMP/RXBPu9hTaWKBi2Lg3YQ8WIv
IdonshPAFq6YDx/dREPJZqIK/DXTORxcc0sNkmL7wfHSssz8A6cXzlQne+kqX2sf
g5+6W7Vn0WOTAbWYKNufnktbcm/5teH0yvXBfNoVpei76Z5NIjWbE9HVS0Ib8tys
Xr8d69+ufKB2TdM5NLRVmxtdyVXvSlo7706m1lNbTEDVZ5qM/Biv8YZsLqXVJN4j
pPdTxQ4jQrOOklUEWLGQ18EnGj5fAggSG0+ijdkxdFFYmmjlq/D3ucmSmRlBTeJE
aCdokV8ZFqmalvHMfjmawLB0faGtYDRnDIcKwlNHAES1XCRS4vVWGPHmXP12SjjA
PItuirf7G14UHEcKzFLqaF3j/XP4y0BZd9/J38VbvTEumwsMw6+UVMSFIytTkKIL
raS1zRVLf+r/Xkq7X4NFSIQx+N9Svzs03/iIxCF8eafC4vEQNZaSqwkXqmbLWmrQ
byRlE459BaPM0Bh+aykxMTfFcguZbK/7t0NuXawcJBJCrBvApvzCQfyDQXOM4LDr
8T7uvRcoFnOOnLr5zjXKREmVhtEKgl3Zl5rRbGW0EfJbiyX03U6OmDxwsw4EIh72
ToHEBNSAsq6lDvMT/bTitA5+yqx8k0E3ztYsgn6DkfFGXr2m8dKBYTDF5jh6HAS1
Fu+7gMV5ZfQ+3T/MLGvb
=xmVG
-----END PGP SIGNATURE-----

DT, it is possible for a txn to be valid on two forks simultaneously...

Clients do not vote on protocol rules... They rigidly enforce them.

Carlton Banks, nothing you've posted so far indicates an error. Those three lines are in fact telling you that it was successfully built. Try "make clean && make all" and pastebin the *entire* result.

Not all developers are working for the foundation or these companies.

Do not delete files.

Look up "pywallet" in the forum search. There are other people who have had this problem and dealt with it.

What do you mean by double-spend?

I'm not sure you understand how bitcoin works. The problem which precipitated this is not about different users requesting different transactions. It is about the same transaction being "helpfully" modified to be standards compliant, but in the process changing the txid. However it is still the same transaction. The same funds going from the same inputs (albeit with modified scriptSigs) to the same outputs. It is easy to check whether a similar mutated transaction got on the chain or not.

It is not even clear that the malleability problem is solvable. Besides the problem that there is innumerable ways to transform a transaction to give it a different hash without affecting scriptSig validity, it is simply unknown whether it is possible to algebraically transform an elliptic curve signature without invalidating it. If so, then no matter what you do to cover up the other holes, that gaping one is left open.

Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.

TFerby, you know that without paying fees, eventually your transactions will never confirm? (they may now, but don't expect that to last long. certainly don't build a business assuming free or cheap transactions.)

protoc is part of Google's protocol buffers. You need it for the payment protocol which is part of 0.9.

I've also been hired to do some work on pruning, but this is wholly dependent on sipa's headers-first branch getting finished & tested.

The "accounts" feature of bitcoind is a single-entry ledger that really has nothing to do with the block chain at all, or even the generally accepted principles of accounting. It is an unfortunately named feature meant for a particular use case that is now somewhat anachronistic.

But anyway, your "" account has a negative balance because you moved funds out of it, or tagged some transaction moving funds out of your wallet.

This is a horrible idea, as has already been explained in detail in this very thread. Please don't do this: you will have customers lose money.

When you call "bitcoind <command>", it's actually using JSON-RPC to communicate with the already running bitcoind instance. This just separates the commands "bitcoind" (to launch the daemon) and "bitcoin-cli" (to interact with it over JSON-RPC). Because the old way of doing things was confusing, as you just demonstrated.

Kraken is U.S. based.

No worries. People pounced on you because it is vitally important that nobody take these sorts of proposals seriously. Otherwise regulators might think that this sort of change is a viable option (it is not), or politicians outlaw currencies which do not include such provisions, making life insanely difficult for everyone here.

The vote would have to be on the chain, in a format that all clients understand. In other words the mechanism of voting will have to be set in stone, forever (any change to that mechanism would be a hard fork). And I would be very wary of anyone claiming to have a distributed voting protocol that is secure and with correct, safe incentives and which itself can't be subject to DoS or withholding attacks. This is complicated frontier stuff people are still working out.

But again, there's no reason Etherium has to be structured that way. Include execution counts in the transactions, and base fees off that explicit amount. During validation check that the execution counts are correct (and invalidate the transaction & block otherwise). Delay script execution until transaction is included in a block, and black list outputs of transactions that fail this validation check so as to provide an economic cost to DoS attempts. Problem solved.

If you control which addresses are allowed and/or selectively withhold approving signatures, then you control which transactions may be processed. If you control which transactions may be processed, how can it not be said that you control the bitcoin economy? You get the set the rules because no one else can do business without making transactions. (This is not to mention all the other things which would break. Bitcoin does not use addresses internally.)

It's like, I don't know, a space station where one company controls the air. Yeah, controlling the air doesn't mean you control what goes on inside the station. But if you have the ability to turn off someone's air...

This proposal would destroy bitcoin entirely, handing over the reigns of the entire bitcoin economy to one or more trusted (ha!) authorities. @justusranvier's response is totally appropriate: fuck off.