Oleg Andreev
Month
Blockchain is a wallet service named after the Bitcoin ledger of all transactions called “the blockchain”. Their website blockchain.info nicely visualizes the blockchain, but since it also provides other services like web wallet, its name causes some confusion among newcomers: “is it the Bitcoin company”?
Bitcoin-Central is a EU-based Bitcoin exchange. Its name sounds like it’s the Bitcoin company. Some newcomers are getting confused.
Bitcoin Foundation is a non-profit organization that promotes Bitcoin among humans and politicians. Its name sounds like it’s the Bitcoin organization. California even sent a Cease and Desist letter to Bitcoin Foundation in July 2013 thinking they were the people behind Bitcoin.
Coinbase is a US-based web wallet and exchange service named after “coinbase transaction”, a technical name for a special kind of transaction that creates new bitcoins. Such transactions can only be created by miners, but Coinbase does not run a mining service.
Kraken is a EU-based Bitcoin exchange. Its name just does not sound serious at all while it is being one of the few exchanges positioned for professional traders.
MtGox (pronounced empty gox) was a Japan-based Bitcoin exchange, before mid-2013 the largest in the world. The name originally meant Magic The Gathering Online Exchange. However, even that name was unfortunate as MtGox never actually traded MtG cards and launched as a Bitcoin exchange from the start. Ironically, the name was appropriate for the level of their communication skills (poor), customer support (poor) and multiple technical issues that haunted the exchange over the years. Nevertheless, MtGox allowed the Bitcoin market to develop dramatically throughout 2010-2013 by being the single more or less stable marketplace. That made MtGox being associated closely with Bitcoin itself and its unfortunate name (among other things) was making a lot of people not to take Bitcoin seriously.
Zerocoin is a Bitcoin-like decentralized currency project that enables completely anonymous transactions: unlike Bitcoin, there is no observable link between one transaction and another. The name stems from a cryptographical term “zero-knowledge proof”, but sounds like a “worthless coin”.
After signing an anti-homosexuality bill into law, Ugandan President Yoweri Museveni was called “disgusting” in an exclusive interview with Oleg Andreev.
Oleg Andreev told Yoweri on Monday that, in his view, being Ugandan President is “unnatural” and not a human right.
“They’re disgusting. What sort of people are they?” he said. “I never knew what they were doing. I’ve been told recently that what they do is terrible. Disgusting. But I was ready to ignore that if there was proof that that’s how he is born, abnormal. But now the proof is not there.”
Oleg had commissioned a group of scientists to study whether government presidents are “created,” concluding that it is a matter of choice. “I was regarding it as an inborn problem,” he said. “Genetic distortion – that was my argument. But now our scientists have knocked this one out.”
It turned out, presidents freely decide to rule nations, take people’s money and then teach them how they should live. They also decide when people should be kidnapped, tortured or even killed.
Original article: http://edition.cnn.com/2014/02/24/world/africa/uganda-homosexuality-interview/index.html?hpt=hp_c1
I’m happy to publish a draft of my innovative scheme that enables blind signatures compatible with Bitcoin transactions. Primary motivation is secure storage for bitcoins. You can lock your funds with multiple friends/custodians (in a M-of-N multisignature transaction) and ask them to unlock your funds later. If done naïvely, custodians will be able to see which transaction they signed and how much money you have. Blind signatures allow you to completely hide your transactions from custodians who sign them. The scheme differs from existing blind signature proposals in two important aspects: 1) it is compatible with ECDSA while others are not and 2) it completely unlinks resulting signature and public keys from the signing parties, providing absolute privacy.
Paper describes motivation, core protocol and provides a practical way to generate and keep track of all secret and public parameters used in it. Use of this scheme enables the ultimate solution to secure Bitcoin storage. While your personal hardware and software wallets can be compromised, money can be much safer locked with independent semi-trusted parties, yet absolutely privately. You and your friends can use conventional personal computers to lock your personal pension funds among each other without ever exposing sensitive financial information.
Download the paper here: http://oleganza.com/blind-ecdsa-draft-v2.pdf
Demo app: https://github.com/oleganza/blindsignaturedemo
I timestamped SHA256 of the second draft on June, 16 2014. Used SHA256 of the PDF as a private key and sent 0.0002 BTC to corresponding address 1FM9JtztQKwUVshxVJnEv8JEGKPZkCu7qk.
SHA256: 85e0a79b80f75f88790135214564847d2de46062414f08e799e5f701fddbfddc
Tx ID: https://blockchain.info/tx/ee0c7527de579d7ab2732be49a8b57fe13af940caff2c429464cd659e23281a6
Address: https://blockchain.info/address/1FM9JtztQKwUVshxVJnEv8JEGKPZkCu7qk
To verify:
1) Compute SHA256: $ openssl dgst -sha256 blind-ecdsa-draft-v2.pdf
2) Paste it as a “secret exponent” on brainwallet.org and get the address.
3) Find the earliest transaction on the blockchain for this address.
After conversation in #bitcoin-dev with Luke-Jr, we may have a soft-fork change (only super-majority of miners need to support it) to support non-malleable transactions.
Like with P2SH, we will take an innocent script OP_HASH160 <…> OP_EQUAL and interpret it as P2SHv2. To remain compatible with current P2SH, that script will use PUSHDATA1 (2-byte length prefix) instead of 1-byte PUSHDATA prefix (which encodes the length of data in itself).
The entire input script for P2SHv2 output will be interpreted differently.
Voting process can be identical to P2SH. Miners will put string “/P2SHv2/” in their coinbase to support the change. Once super-majority of miners support it, it will be safe for people to issue P2SH-version2 transactions. Old style transactions will still be malleable. Regular payments will be softly protected against malleability by isStandard check. Complex contracts like rapidly-adjusted micropayments would need to use P2SHv2 in order to rely on chains of unconfirmed transactions.
This change does not require regular users to upgrade their software.
We can introduce another version of transactions (2) that will change how signatures are verified and stored within the transaction.
The malleability of transactions stems from the fact that we store signatures in the input scripts and for purposes of signing and verifying the signature, all input scripts are completely stripped. This allows anyone to introduce non-breaking changes to the input scripts that keep signatures correct, but change the whole transaction hash.
To fix that, we add a level of indirection. All signatures will be stored in a separate location in the transaction, ordered. Input scripts will only reference the index of the signature and never be stripped for the purposes of signing.
Input scripts are not stripped during SignatureHash phase.
CHECKSIG and CHECKMULTISIG expect not a signature, but a “signature index”, as PUSHDATA (does not need to be normalized).
Signatures are listed in an array in the tail of the transaction (after lock time). All length prefixes must be normalized in that array (including length prefix of the array itself).
All signatures must be canonical.
When signing an input, its script is appended with the output script (today output script replaces the input script).
When verifying the signature, storage of signatures is stripped off completely (“signatures cannot sign themselves”).
Transaction ID remains the same: a double-SHA256 of the entire transaction, so no changes in the transaction inputs or merkle trees is needed.
Old versions of transactions are still malleable and can be created by older clients and will always be valid. New versions will be accepted by the network if network decides so with a majority vote. There will be an announced block height starting with which version 2 transactions will be valid.
How to vote?
Miners may express their support by mentioning “/CTv2/” (“Canonical transactions AKA version 2”) in their coinbase.
But before that, miners must see that most used software is upgraded to support validation of “version 2” transactions. I.e. bitcoind, libbitcoin, bitcoin-ruby, Multibit, Electrum, mobile apps if needed.
If after block height N, more than 95% of blocks in the past 10000 blocks are supporting the change, network starts accepting transactions with version 2 and new signature check rules in those transactions.
Then, if your special scheme (like rapidly-adjusted micropayments) requires reference to an unconfirmed transaction, you would simply require using a version 2 transaction and have guarantee that its ID can’t be changed.
EDIT: as Luke-Jr suggested, in the future we may want some other data to be stripped for signing purposes (e.g. if we implement other signature schemes with new or existing opcodes). To support that, we may allow any “pushdata” to be “indirect” or “strippable”. Maybe with some extra opcode acting as a prefix before pushdata. E.g. OP_NOP1 will be used as OP_STRIP and mean “for signature hash”, strip the following piece of data.
MtGox issued a statement that due to a “design issue” in Bitcoin protocol, they were having problems with withdrawing BTC and so they had to halt all withdrawals until the problem is fixed. https://www.mtgox.com/press_release_20140210.html
If you need a quick answer: there’s no bug in the Bitcoin itself. You may go to Bitstamp/Coinbase/BTC-E/Bitcoin-Central and buy more BTC with a huge discount before it gets back to $800-$900.
Long answer:
Unconfirmed Bitcoin transactions were always “malleable”, that is you can slightly change a transaction that “floats around” (not yet in the blockchain) and you wouldn’t break its signatures. You can’t change something important about it, like source transactions, amounts, order of inputs and outputs or other important metadata. What you can do is to add some bogus data or flip a sign on a signature that doesn’t change the meaning of the transaction, but changes its binary representation. (More info here: https://en.bitcoin.it/wiki/Transaction_Malleability)
What does it mean in practice? You may send a transaction ABC123, then someone may see it on the network, change slightly to ABC124 and send it too. If he gets lucky, ABC124 will be included first and ABC123 will never be included (because it’d be a double-spend). There’s no problem for the recipient of the transaction: they will still get all their money on the address they expect. But if they were watching the blockchain specifically for transaction ABC123, they will never find it there.
MtGox claims to be fooled this way:
Is it a design issue in Bitcoin to allow slight changes in unconfirmed transactions? Yes, probably is. But it’s not entirely clear how it can be prevented at all. An immediate fix would disallow potentially useful more complex transactions and require a global network consensus to enforce new behavior. Zero-confirmation transactions were always known to be malleable and methods to limit their malleability were already discussed and deployed (e.g. transactions with non-canonical signatures may not be relayed by all nodes). But for all practical purposes, it’s a known feature, just like many other weird facets of Bitcoin. Those who build Bitcoin wallets, exchanges or payment processors must be aware of this and act accordingly.
MtGox had this problem because they didn’t know about this Bitcoin property. And usually transactions were not deliberately modified by anyone, so it was okay for the most of the time.
It’s not rocket science to fix the problem. For instance, MtGox may fix the problem this way: instead of watching blockchain for appearance of the specific hash of a specific transaction, they should instead watch if the address X (specified by user) got amount N (specified by user) from outputs Y, Z and W (owned by MtGox). This would guarantee that even if transaction is modified, they will see for sure if the users actually got the money sent to them, or not.