Abstract Merged mining refers to the concept of mining more than one cryptocurrency without necessitating additional proof-of-work effort. Although merged mining has been adopted by a number of cryptocurrencies already, to this date little is known about the effects and implications. We shed light on this topic area by performing a comprehensive analysis of merged mining in practice. As part of this analysis, we present a block attribution scheme for mining pools to assist in the evaluation of mining centralization. Our findings disclose that mining pools in merge-mined cryptocurrencies have operated at the edge of, and even beyond, the security guarantees offered by the underlying Nakamoto consensus for extended periods. We discuss the implications and security considerations for these cryptocurrencies and the mining ecosystem as a whole, and link our findings to the intended effects of merged mining. References
M. Ali, J. Nelson, R. Shea, and M. J. Freedman. Blockstack: A global naming and storage system secured by blockchains. In 2016 USENIX Annual Technical Conference (USENIX ATC 16), pages 181–194, Denver, CO, 2016. USENIX Association.
L. Anderson, R. Holz, A. Ponomarev, P. Rimba, and I. Weber. New kids on the block: an analysis of modern blockchains. http://arxiv.org/pdf/1606.06530.pdf, 2016. Accessed: 2016-11-10.
E. Androulaki, S. Capkun, and G. O. Karame. Two bitcoins at the price of one? doublespending attacks on fast payments in bitcoin. In CCS, 2012.
I. Eyal. The miner’s dilemma. In Security and Privacy (SP), 2015 IEEE Symposium on, pages 89–103. IEEE, 2015.
I. Eyal and E. G. Sirer. Majority is not enough: Bitcoin mining is vulnerable. In Financial Cryptography and Data Security, pages 436–454. Springer, 2014.
P. Franco. Understanding Bitcoin: Cryptography, engineering and economics. John Wiley & Sons, 2014.
A. Gervais, G. O. Karame, K. Wust, V. Glykantzis, H. Ritzdorf, and S. Capkun. On the ¨ security and performance of proof of work blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS ’16, pages 3–16, New York, NY, USA, 2016. ACM.
E. Heilman, A. Kendler, A. Zohar, and S. Goldberg. Eclipse attacks on bitcoin’s peer-to-peer network. In 24th USENIX Security Symposium (USENIX Security 15), pages 129–144, 2015.
Y. Lewenberg, Y. Bachrach, Y. Sompolinsky, A. Zohar, and J. S. Rosenschein. Bitcoin mining pools: A cooperative game theoretic analysis. In Proceedings of the 2015 International Conference on Autonomous Agents and Multiagent Systems, pages 919–927. International Foundation for Autonomous Agents and Multiagent Systems, 2015.
O. Schrijvers, J. Bonneau, D. Boneh, and T. Roughgarden. Incentive compatibility of bitcoin mining pool reward functions. In FC ’16: Proceedings of the the 20th International Conference on Financial Cryptography, February 2016.
M. B. Taylor. Bitcoin and the age of bespoke silicon. In Proceedings of the 2013 International Conference on Compilers, Architectures and Synthesis for Embedded Systems, page 16. IEEE Press, 2013.
Abstract Merged mining refers to the concept of mining more than one cryptocurrency without necessitating additional proof-of-work effort. Merged mining was introduced in 2011 as a boostrapping mechanism for new cryptocurrencies and countermeasures against the fragmentation of mining power across competing systems. Although merged mining has already been adopted by a number of cryptocurrencies, to this date little is known about the effects and implications. In this thesis, we shed light on this topic area by performing a comprehensive analysis of merged mining in practice. As part of this analysis, we present a block attribution scheme for mining pools to assist in the evaluation of mining centralization. Our findings disclose that mining pools in merge-mined cryptocurrencies have operated at the edge of, and even beyond, the security guarantees offered by the underlying Nakamoto consensus for extended periods. We discuss the implications and security considerations for these cryptocurrencies and the mining ecosystem as a whole, and link our findings to the intended effects of merged mining. Bibliography  Coinmarketcap. http://coinmarketcap.com/. Accessed 2017-09-28.  P2pool. http://p2pool.org/. Accessed: 2017-05-10.  M. Ali, J. Nelson, R. Shea, and M. J. Freedman. Blockstack: Design and implementation of a global naming system with blockchains. http://www.the-blockchain.com/docs/BlockstackDesignandImplementationofaGlobalNamingSystem.pdf, 2016. Accessed: 2016-03-29.  G. Andersen. Comment in "faster blocks vs bigger blocks". https://bitcointalk.org/index.php?topic=673415.msg7658481#msg7658481, 2014. Accessed: 2017-05-10.  G. Andersen. [bitcoin-dev] weak block thoughts... https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe011157.html, 2015. Accessed: 2017-05-10.  L. Anderson, R. Holz, A. Ponomarev, P. Rimba, and I. Weber. New kids on the block: an analysis of modern blockchains. http://arxiv.org/pdf/1606.06530.pdf, 2016. Accessed: 2016-07-04.  E. Androulaki, S. Capkun, and G. O. Karame. Two bitcoins at the price of one? double-spending attacks on fast payments in bitcoin. In CCS, 2012.  A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra, J. Timón, and P. Wuille. Enabling blockchain innovations with pegged sidechains. http://newspaper23.com/ripped/2014/11/http-_____-___-_www___-blockstream___-com__-_sidechains.pdf, 2014. Accessed: 2017-09-28.  A. Back et al. Hashcash - a denial of service counter-measure. http://www.hashcash.org/papers/hashcash.pdf, 2002. Accessed: 2017-09-28.  S. Barber, X. Boyen, E. Shi, and E. Uzun. Bitter to better - how to make bitcoin a better currency. In Financial cryptography and data security, pages 399–414. Springer, 2012.  J. Becker, D. Breuker, T. Heide, J. Holler, H. P. Rauer, and R. Böhme. Can we afford integrity by proof-of-work? scenarios inspired by the bitcoin currency. In WEIS. Springer, 2012.  I. Bentov, R. Pass, and E. Shi. Snow white: Provably secure proofs of stake. https://eprint.iacr.org/2016/919.pdf, 2016. Accessed: 2017-09-28.  Bitcoin Community. Bitcoin developer guide- transaction data. https://bitcoin.org/en/developer-guide#term-merkle-tree. Accessed: 2017-06-05.  Bitcoin Community. Bitcoin protocol documentation - merkle trees. https://en.bitcoin.it/wiki/Protocol_documentation#Merkle_Trees. Accessed: 2017-06-05.  Bitcoin community. Bitcoin protocol rules. https://en.bitcoin.it/wiki/Protocol_rules. Accessed: 2017-08-22.  V. Buterin. Chain interoperability. Technical report, Tech. rep. 1. R3CEV, 2016.  W. Dai. bmoney. http://www.weidai.com/bmoney.txt, 1998. Accessed: 2017-09-28.  C. Decker and R. Wattenhofer. Information propagation in the bitcoin network. In Peer-to-Peer Computing (P2P), 2013 IEEE Thirteenth International Conference on, pages 1–10. IEEE, 2013.  C. Decker and R. Wattenhofer. Bitcoin transaction malleability and mtgox. In Computer Security-ESORICS 2014, pages 313–326. Springer, 2014.  Dogecoin community. Dogecoin reference implementation. https://github.com/dogecoin/  A. Gervais, G. Karame, S. Capkun, and V. Capkun. Is bitcoin a decentralized currency? volume 12, pages 54–60, 2014.  A. Gervais, G. O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf, and S. Capkun. On the security and performance of proof of work blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pages 3–16. ACM, 2016.  I. Giechaskiel, C. Cremers, and K. B. Rasmussen. On bitcoin security in the presence of broken cryptographic primitives. In European Symposium on Research in Computer Security (ESORICS), September 2016.  J. Göbel, H. P. Keeler, A. E. Krzesinski, and P. G. Taylor. Bitcoin blockchain dynamics: The selfish-mine strategy in the presence of propagation delay. Performance Evaluation, 104:23–41, 2016.  E. Heilman, A. Kendler, A. Zohar, and S. Goldberg. Eclipse attacks on bitcoin’s peer-to-peer network. In 24th USENIX Security Symposium (USENIX Security 15), pages 129–144, 2015.  Huntercoin developers. Huntercoin reference implementation. https://github.com/chronokings/huntercoin. Accessed: 2017-06-05.  B. Jakobsson and A. Juels. Proofs of work and bread pudding protocols, Apr. 8 2008. US Patent 7,356,696; Accessed: 2017-06-05.  M. Jakobsson and A. Juels. Proofs of work and bread pudding protocols. In Secure Information Networks, pages 258–272. Springer, 1999.  A. Judmayer, N. Stifter, K. Krombholz, and E. Weippl. Blocks and chains: Introduction to bitcoin, cryptocurrencies, and their consensus mechanisms. Synthesis Lectures on Information Security, Privacy, & Trust, 9(1):1–123, 2017.  A. Juels and J. G. Brainard. Client puzzles: A cryptographic countermeasure against connection depletion attacks. In NDSS, volume 99, pages 151–165, 1999.  A. Juels and B. S. Kaliski Jr. Pors: Proofs of retrievability for large files. In Proceedings of the 14th ACM conference on Computer and communications security, pages 584–597. Acm, 2007.  H. Kalodner, M. Carlsten, P. Ellenbogen, J. Bonneau, and A. Narayanan. An empirical study of namecoin and lessons for decentralized namespace design. In WEIS, 2015.  G. O. Karame, E. Androulaki, and S. Capkun. Double-spending fast payments in bitcoin. In Proceedings of the 2012 ACM conference on Computer and communications security, pages 906–917. ACM, 2012.  G. O. Karame, E. Androulaki, M. Roeschlin, A. Gervais, and S. Čapkun. Misbehavior in bitcoin: A study of double-spending and accountability. volume 18, page 2. ACM, 2015.  A. Kiayias, A. Russell, B. David, and R. Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Annual International Cryptology Conference, pages 357–388. Springer, 2017.  S. King. Primecoin: Cryptocurrency with prime number proof-of-work. July 7th, 2013.  T. Kluyver, B. Ragan-Kelley, F. Pérez, B. E. Granger, M. Bussonnier, J. Frederic, K. Kelley, J. B. Hamrick, J. Grout, S. Corlay, et al. Jupyter notebooks-a publishing format for reproducible computational workflows. In ELPUB, pages 87–90, 2016.  Lerner, Sergio D. Rootstock plattform. http://www.the-blockchain.com/docs/Rootstock-WhitePaper-Overview.pdf. Accessed: 2017-06-05.  Y. Lewenberg, Y. Bachrach, Y. Sompolinsky, A. Zohar, and J. S. Rosenschein. Bitcoin mining pools: A cooperative game theoretic analysis. In Proceedings of the 2015 International Conference on Autonomous Agents and Multiagent Systems, pages 919–927. International Foundation for Autonomous Agents and Multiagent Systems, 2015.  Litecoin community. Litecoin reference implementation. https://github.com/litecoin-project/litecoin. Accessed: 2017-09-28.  I. Maven. Apache maven project, 2011.  G. Maxwell. Comment in "[bitcoin-dev] weak block thoughts...". https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe011198.html, 2016. Accessed: 2017-05-10.  S. Meiklejohn, M. Pomarole, G. Jordan, K. Levchenko, D. McCoy, G. M. Voelker, and S. Savage. A fistful of bitcoins: characterizing payments among men with no names. In Proceedings of the 2013 conference on Internet measurement conference, pages 127–140. ACM, 2013.  S. Micali. Algorand: The efficient and democratic ledger. http://arxiv.org/abs/1607.01341, 2016. Accessed: 2017-02-09.  A. Miller, A. Juels, E. Shi, B. Parno, and J. Katz. Permacoin: Repurposing bitcoin work for data preservation. In Security and Privacy (SP), 2014 IEEE Symposium on, pages 475–490. IEEE, 2014.  A. Miller, A. Kosba, J. Katz, and E. Shi. Nonoutsourceable scratch-off puzzles to discourage bitcoin mining coalitions. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pages 680–691. ACM, 2015.  B. Momjian. PostgreSQL: introduction and concepts, volume 192. Addison-Wesley New York, 2001.  Myriad core developers. Myriadcoin reference implementation. https://github.com/myriadcoin/myriadcoin. Accessed: 2017-06-05.  S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf, Dec 2008. Accessed: 2017-09-28.  S. Nakamoto. Merged mining specification. https://en.bitcoin.it/wiki/Merged_mining_specification, Apr 2011. Accessed: 2017-09-28.  Namecoin Community. Merged mining. https://github.com/namecoin/wiki/blob/masteMerged-Mining.mediawiki#Goal_of_this_namecoin_change. Accessed: 2017-08-20.  Namecoin community. Namecoin reference implementation. https://github.com/namecoin/namecoin. Accessed: 2017-09-28.  A. Narayanan, J. Bonneau, E. Felten, A. Miller, and S. Goldfeder. Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. Princeton University Press, 2016.  K. Nayak, S. Kumar, A. Miller, and E. Shi. Stubborn mining: Generalizing selfish mining and combining with an eclipse attack. In 1st IEEE European Symposium on Security and Privacy, 2016. IEEE, 2016.  K. J. O’Dwyer and D. Malone. Bitcoin mining and its energy footprint. 2014.  R. Pass, L. Seeman, and A. Shelat. Analysis of the blockchain protocol in asynchronous networks. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 643–673. Springer, 2017.  D. Pointcheval and J. Stern. Security arguments for digital signatures and blind signatures. Journal of cryptology, 13(3):361–396, 2000.  Pseudonymous("TierNolan"). Decoupling transactions and pow. https://bitcointalk.org/index.php?topic=179598.0, 2013. Accessed: 2017-05-10.  P. R. Rizun. Subchains: A technique to scale bitcoin and improve the user experience. Ledger, 1:38–52, 2016.  K. Rosenbaum. Weak blocks - the good and the bad. http://popeller.io/index.php/2016/01/19/weak-blocks-the-good-and-the-bad/, 2016. Accessed: 2017-05-10.  K. Rosenbaum and R. Russell. Iblt and weak block propagation performance. Scaling Bitcoin Hong Kong (6 December 2015), 2015.  M. Rosenfeld. Analysis of bitcoin pooled mining reward systems. arXiv preprint arXiv:1112.4980, 2011.  M. Rosenfeld. Analysis of hashrate-based double spending. http://arxiv.org/abs/1402.2009, 2014. Accessed: 2016-03-09.  R. Russel. Weak block simulator for bitcoin. https://github.com/rustyrussell/weak-blocks, 2014. Accessed: 2017-05-10.  A. Sapirshtein, Y. Sompolinsky, and A. Zohar. Optimal selfish mining strategies in bitcoin. In International Conference on Financial Cryptography and Data Security, pages 515–532. Springer, 2016.  Sathoshi Nakamoto. Comment in "bitdns and generalizing bitcoin" bitcointalk thread. https://bitcointalk.org/index.php?topic=1790.msg28696#msg28696. Accessed: 2017-06-05.  O. Schrijvers, J. Bonneau, D. Boneh, and T. Roughgarden. Incentive compatibility of bitcoin mining pool reward functions. In FC ’16: Proceedings of the the 20th International Conference on Financial Cryptography, February 2016.  B. Sengupta, S. Bag, S. Ruj, and K. Sakurai. Retricoin: Bitcoin based on compact proofs of retrievability. In Proceedings of the 17th International Conference on Distributed Computing and Networking, page 14. ACM, 2016.  N. Szabo. Bit gold. http://unenumerated.blogspot.co.at/2005/12/bit-gold.html, 2005. Accessed: 2017-09-28.  M. B. Taylor. Bitcoin and the age of bespoke silicon. In Proceedings of the 2013 International Conference on Compilers, Architectures and Synthesis for Embedded Systems, page 16. IEEE Press, 2013.  Unitus developers. Unitus reference implementation. https://github.com/unitusdev/unitus. Accessed: 2017-08-22.  M. Vukolić. The quest for scalable blockchain fabric: Proof-of-work vs. bft replication. In International Workshop on Open Problems in Network Security, pages 112–125. Springer, 2015.  P. Webb, D. Syer, J. Long, S. Nicoll, R. Winch, A. Wilkinson, M. Overdijk, C. Dupuis, and S. Deleuze. Spring boot reference guide. Technical report, 2013-2016.  A. Zamyatin. Name-squatting in namecoin. (unpublished BSc thesis, Vienna University of Technology), 2015.
Technical: A Brief History of Payment Channels: from Satoshi to Lightning Network
Who cares about political tweets from some random country's president when payment channels are a much more interesting and are actually capable of carrying value? So let's have a short history of various payment channel techs!
Generation 0: Satoshi's Broken nSequence Channels
Because Satoshi's Vision included payment channels, except his implementation sucked so hard we had to go fix it and added RBF as a by-product. Originally, the plan for nSequence was that mempools would replace any transaction spending certain inputs with another transaction spending the same inputs, but only if the nSequence field of the replacement was larger. Since 0xFFFFFFFF was the highest value that nSequence could get, this would mark a transaction as "final" and not replaceable on the mempool anymore. In fact, this "nSequence channel" I will describe is the reason why we have this weird rule about nLockTime and nSequence. nLockTime actually only works if nSequence is not 0xFFFFFFFF i.e. final. If nSequence is 0xFFFFFFFF then nLockTime is ignored, because this if the "final" version of the transaction. So what you'd do would be something like this:
You go to a bar and promise the bartender to pay by the time the bar closes. Because this is the Bitcoin universe, time is measured in blockheight, so the closing time of the bar is indicated as some future blockheight.
For your first drink, you'd make a transaction paying to the bartender for that drink, paying from some coins you have. The transaction has an nLockTime equal to the closing time of the bar, and a starting nSequence of 0. You hand over the transaction and the bartender hands you your drink.
For your succeeding drink, you'd remake the same transaction, adding the payment for that drink to the transaction output that goes to the bartender (so that output keeps getting larger, by the amount of payment), and having an nSequence that is one higher than the previous one.
Eventually you have to stop drinking. It comes down to one of two possibilities:
You drink until the bar closes. Since it is now the nLockTime indicated in the transaction, the bartender is able to broadcast the latest transaction and tells the bouncers to kick you out of the bar.
You wisely consider the state of your liver. So you re-sign the last transaction with a "final" nSequence of 0xFFFFFFFF i.e. the maximum possible value it can have. This allows the bartender to get his or her funds immediately (nLockTime is ignored if nSequence is 0xFFFFFFFF), so he or she tells the bouncers to let you out of the bar.
Now that of course is a payment channel. Individual payments (purchases of alcohol, so I guess buying coffee is not in scope for payment channels). Closing is done by creating a "final" transaction that is the sum of the individual payments. Sure there's no routing and channels are unidirectional and channels have a maximum lifetime but give Satoshi a break, he was also busy inventing Bitcoin at the time. Now if you noticed I called this kind of payment channel "broken". This is because the mempool rules are not consensus rules, and cannot be validated (nothing about the mempool can be validated onchain: I sigh every time somebody proposes "let's make block size dependent on mempool size", mempool state cannot be validated by onchain data). Fullnodes can't see all of the transactions you signed, and then validate that the final one with the maximum nSequence is the one that actually is used onchain. So you can do the below:
Become friends with Jihan Wu, because he owns >51% of the mining hashrate (he totally reorged Bitcoin to reverse the Binance hack right?).
Slip Jihan Wu some of the more interesting drinks you're ordering as an incentive to cooperate with you. So say you end up ordering 100 drinks, you split it with Jihan Wu and give him 50 of the drinks.
When the bar closes, Jihan Wu quickly calls his mining rig and tells them to mine the version of your transaction with nSequence 0. You know, that first one where you pay for only one drink.
Because fullnodes cannot validate nSequence, they'll accept even the nSequence=0 version and confirm it, immutably adding you paying for a single alcoholic drink to the blockchain.
The bartender, pissed at being cheated, takes out a shotgun from under the bar and shoots at you and Jihan Wu.
Jihan Wu uses his mystical chi powers (actually the combined exhaust from all of his mining rigs) to slow down the shotgun pellets, making them hit you as softly as petals drifting in the wind.
The bartender mutters some words, clothes ripping apart as he or she (hard to believe it could be a she but hey) turns into a bear, ready to maul you for cheating him or her of the payment for all the 100 drinks you ordered from him or her.
Steely-eyed, you stand in front of the bartender-turned-bear, daring him to touch you. You've watched Revenant, you know Leonardo di Caprio could survive a bear mauling, and if some posh actor can survive that, you know you can too. You make a pose. "Drunken troll logic attack!"
I think I got sidetracked here.
Bears are bad news.
You can't reasonably invoke "Satoshi's Vision" and simultaneously reject the Lightning Network because it's not onchain. Satoshi's Vision included a half-assed implementation of payment channels with nSequence, where the onchain transaction represented multiple logical payments, exactly what modern offchain techniques do (except modern offchain techniques actually work). nSequence (the field, but not its modern meaning) has been in Bitcoin since BitCoin For Windows Alpha 0.1.0. And its original intent was payment channels. You can't get nearer to Satoshi's Vision than being a field that Satoshi personally added to transactions on the very first public release of the BitCoin software, like srsly.
Miners can totally bypass mempool rules. In fact, the reason why nSequence has been repurposed to indicate "optional" replace-by-fee is because miners are already incentivized by the nSequence system to always follow replace-by-fee anyway. I mean, what do you think those drinks you passed to Jihan Wu are, other than the fee you pay him to mine a specific version of your transaction?
Satoshi made mistakes. The original design for nSequence is one of them. Today, we no longer use nSequence in this way. So diverging from Satoshi's original design is part and parcel of Bitcoin development, because over time, we learn new lessons that Satoshi never knew about. Satoshi was an important landmark in this technology. He will not be the last, or most important, that we will remember in the future: he will only be the first.
Incentive-compatible time-limited unidirectional channel; or, Satoshi's Vision, Fixed (if transaction malleability hadn't been a problem, that is). Now, we know the bartender will turn into a bear and maul you if you try to cheat the payment channel, and now that we've revealed you're good friends with Jihan Wu, the bartender will no longer accept a payment channel scheme that lets one you cooperate with a miner to cheat the bartender. Fortunately, Jeremy Spilman proposed a better way that would not let you cheat the bartender. First, you and the bartender perform this ritual:
You get some funds and create a transaction that pays to a 2-of-2 multisig between you and the bartender. You don't broadcast this yet: you just sign it and get its txid.
You create another transaction that spends the above transaction. This transaction (the "backoff") has an nLockTime equal to the closing time of the bar, plus one block. You sign it and give this backoff transaction (but not the above transaction) to the bartender.
The bartender signs the backoff and gives it back to you. It is now valid since it's spending a 2-of-2 of you and the bartender, and both of you have signed the backoff transaction.
Now you broadcast the first transaction onchain. You and the bartender wait for it to be deeply confirmed, then you can start ordering.
The above is probably vaguely familiar to LN users. It's the funding process of payment channels! The first transaction, the one that pays to a 2-of-2 multisig, is the funding transaction that backs the payment channel funds. So now you start ordering in this way:
For your first drink, you create a transaction spending the funding transaction output and sending the price of the drink to the bartender, with the rest returning to you.
You sign the transaction and pass it to the bartender, who serves your first drink.
For your succeeding drinks, you recreate the same transaction, adding the price of the new drink to the sum that goes to the bartender and reducing the money returned to you. You sign the transaction and give it to the bartender, who serves you your next drink.
At the end:
If the bar closing time is reached, the bartender signs the latest transaction, completing the needed 2-of-2 signatures and broadcasting this to the Bitcoin network. Since the backoff transaction is the closing time + 1, it can't get used at closing time.
If you decide you want to leave early because your liver is crying, you just tell the bartender to go ahead and close the channel (which the bartender can do at any time by just signing and broadcasting the latest transaction: the bartender won't do that because he or she is hoping you'll stay and drink more).
If you ended up just hanging around the bar and never ordering, then at closing time + 1 you broadcast the backoff transaction and get your funds back in full.
Now, even if you pass 50 drinks to Jihan Wu, you can't give him the first transaction (the one which pays for only one drink) and ask him to mine it: it's spending a 2-of-2 and the copy you have only contains your own signature. You need the bartender's signature to make it valid, but he or she sure as hell isn't going to cooperate in something that would lose him or her money, so a signature from the bartender validating old state where he or she gets paid less isn't going to happen. So, problem solved, right? Right? Okay, let's try it. So you get your funds, put them in a funding tx, get the backoff tx, confirm the funding tx... Once the funding transaction confirms deeply, the bartender laughs uproariously. He or she summons the bouncers, who surround you menacingly. "I'm refusing service to you," the bartender says. "Fine," you say. "I was leaving anyway;" You smirk. "I'll get back my money with the backoff transaction, and posting about your poor service on reddit so you get negative karma, so there!" "Not so fast," the bartender says. His or her voice chills your bones. It looks like your exploitation of the Satoshi nSequence payment channel is still fresh in his or her mind. "Look at the txid of the funding transaction that got confirmed." "What about it?" you ask nonchalantly, as you flip open your desktop computer and open a reputable blockchain explorer. What you see shocks you. "What the --- the txid is different! You--- you changed my signature?? But how? I put the only copy of my private key in a sealed envelope in a cast-iron box inside a safe buried in the Gobi desert protected by a clan of nomads who have dedicated their lives and their childrens' lives to keeping my private key safe in perpetuity!" "Didn't you know?" the bartender asks. "The components of the signature are just very large numbers. The sign of one of the signature components can be changed, from positive to negative, or negative to positive, and the signature will remain valid. Anyone can do that, even if they don't know the private key. But because Bitcoin includes the signatures in the transaction when it's generating the txid, this little change also changes the txid." He or she chuckles. "They say they'll fix it by separating the signatures from the transaction body. They're saying that these kinds of signature malleability won't affect transaction ids anymore after they do this, but I bet I can get my good friend Jihan Wu to delay this 'SepSig' plan for a good while yet. Friendly guy, this Jihan Wu, it turns out all I had to do was slip him 51 drinks and he was willing to mine a tx with the signature signs flipped." His or her grin widens. "I'm afraid your backoff transaction won't work anymore, since it spends a txid that is not existent and will never be confirmed. So here's the deal. You pay me 99% of the funds in the funding transaction, in exchange for me signing the transaction that spends with the txid that you see onchain. Refuse, and you lose 100% of the funds and every other HODLer, including me, benefits from the reduction in coin supply. Accept, and you get to keep 1%. I lose nothing if you refuse, so I won't care if you do, but consider the difference of getting zilch vs. getting 1% of your funds." His or her eyes glow. "GENUFLECT RIGHT NOW." Lesson learned?
Payback's a bitch.
Transaction malleability is a bitchier bitch. It's why we needed to fix the bug in SegWit. Sure, MtGox claimed they were attacked this way because someone kept messing with their transaction signatures and thus they lost track of where their funds went, but really, the bigger impetus for fixing transaction malleability was to support payment channels.
Yes, including the signatures in the hash that ultimately defines the txid was a mistake. Satoshi made a lot of those. So we're just reiterating the lesson "Satoshi was not an infinite being of infinite wisdom" here. Satoshi just gets a pass because of how awesome Bitcoin is.
CLTV-protected Spilman Channels
Using CLTV for the backoff branch. This variation is simply Spilman channels, but with the backoff transaction replaced with a backoff branch in the SCRIPT you pay to. It only became possible after OP_CHECKLOCKTIMEVERIFY (CLTV) was enabled in 2015. Now as we saw in the Spilman Channels discussion, transaction malleability means that any pre-signed offchain transaction can easily be invalidated by flipping the sign of the signature of the funding transaction while the funding transaction is not yet confirmed. This can be avoided by simply putting any special requirements into an explicit branch of the Bitcoin SCRIPT. Now, the backoff branch is supposed to create a maximum lifetime for the payment channel, and prior to the introduction of OP_CHECKLOCKTIMEVERIFY this could only be done by having a pre-signed nLockTime transaction. With CLTV, however, we can now make the branches explicit in the SCRIPT that the funding transaction pays to. Instead of paying to a 2-of-2 in order to set up the funding transaction, you pay to a SCRIPT which is basically "2-of-2, OR this singlesig after a specified lock time". With this, there is no backoff transaction that is pre-signed and which refers to a specific txid. Instead, you can create the backoff transaction later, using whatever txid the funding transaction ends up being confirmed under. Since the funding transaction is immutable once confirmed, it is no longer possible to change the txid afterwards.
Todd Micropayment Networks
The old hub-spoke model (that isn't how LN today actually works). One of the more direct predecessors of the Lightning Network was the hub-spoke model discussed by Peter Todd. In this model, instead of payers directly having channels to payees, payers and payees connect to a central hub server. This allows any payer to pay any payee, using the same channel for every payee on the hub. Similarly, this allows any payee to receive from any payer, using the same channel. Remember from the above Spilman example? When you open a channel to the bartender, you have to wait around for the funding tx to confirm. This will take an hour at best. Now consider that you have to make channels for everyone you want to pay to. That's not very scalable. So the Todd hub-spoke model has a central "clearing house" that transport money from payers to payees. The "Moonbeam" project takes this model. Of course, this reveals to the hub who the payer and payee are, and thus the hub can potentially censor transactions. Generally, though, it was considered that a hub would more efficiently censor by just not maintaining a channel with the payer or payee that it wants to censor (since the money it owned in the channel would just be locked uselessly if the hub won't process payments to/from the censored user). In any case, the ability of the central hub to monitor payments means that it can surveill the payer and payee, and then sell this private transactional data to third parties. This loss of privacy would be intolerable today. Peter Todd also proposed that there might be multiple hubs that could transport funds to each other on behalf of their users, providing somewhat better privacy. Another point of note is that at the time such networks were proposed, only unidirectional (Spilman) channels were available. Thus, while one could be a payer, or payee, you would have to use separate channels for your income versus for your spending. Worse, if you wanted to transfer money from your income channel to your spending channel, you had to close both and reshuffle the money between them, both onchain activities.
Poon-Dryja Lightning Network
Bidirectional two-participant channels. The Poon-Dryja channel mechanism has two important properties:
No time limit.
Both the original Satoshi and the two Spilman variants are unidirectional: there is a payer and a payee, and if the payee wants to do a refund, or wants to pay for a different service or product the payer is providing, then they can't use the same unidirectional channel. The Poon-Dryjam mechanism allows channels, however, to be bidirectional instead: you are not a payer or a payee on the channel, you can receive or send at any time as long as both you and the channel counterparty are online. Further, unlike either of the Spilman variants, there is no time limit for the lifetime of a channel. Instead, you can keep the channel open for as long as you want. Both properties, together, form a very powerful scaling property that I believe most people have not appreciated. With unidirectional channels, as mentioned before, if you both earn and spend over the same network of payment channels, you would have separate channels for earning and spending. You would then need to perform onchain operations to "reverse" the directions of your channels periodically. Secondly, since Spilman channels have a fixed lifetime, even if you never used either channel, you would have to periodically "refresh" it by closing it and reopening. With bidirectional, indefinite-lifetime channels, you may instead open some channels when you first begin managing your own money, then close them only after your lawyers have executed your last will and testament on how the money in your channels get divided up to your heirs: that's just two onchain transactions in your entire lifetime. That is the potentially very powerful scaling property that bidirectional, indefinite-lifetime channels allow. I won't discuss the transaction structure needed for Poon-Dryja bidirectional channels --- it's complicated and you can easily get explanations with cute graphics elsewhere. There is a weakness of Poon-Dryja that people tend to gloss over (because it was fixed very well by RustyReddit):
You have to store all the revocation keys of a channel. This implies you are storing 1 revocation key for every channel update, so if you perform millions of updates over your entire lifetime, you'd be storing several megabytes of keys, for only a single channel. RustyReddit fixed this by requiring that the revocation keys be generated from a "Seed" revocation key, and every key is just the application of SHA256 on that key, repeatedly. For example, suppose I tell you that my first revocation key is SHA256(SHA256(seed)). You can store that in O(1) space. Then for the next revocation, I tell you SHA256(seed). From SHA256(key), you yourself can compute SHA256(SHA256(seed)) (i.e. the previous revocation key). So you can remember just the most recent revocation key, and from there you'd be able to compute every previous revocation key. When you start a channel, you perform SHA256 on your seed for several million times, then use the result as the first revocation key, removing one layer of SHA256 for every revocation key you need to generate. RustyReddit not only came up with this, but also suggested an efficient O(log n) storage structure, the shachain, so that you can quickly look up any revocation key in the past in case of a breach. People no longer really talk about this O(n) revocation storage problem anymore because it was solved very very well by this mechanism.
Another thing I want to emphasize is that while the Lightning Network paper and many of the earlier presentations developed from the old Peter Todd hub-and-spoke model, the modern Lightning Network takes the logical conclusion of removing a strict separation between "hubs" and "spokes". Any node on the Lightning Network can very well work as a hub for any other node. Thus, while you might operate as "mostly a payer", "mostly a forwarding node", "mostly a payee", you still end up being at least partially a forwarding node ("hub") on the network, at least part of the time. This greatly reduces the problems of privacy inherent in having only a few hub nodes: forwarding nodes cannot get significantly useful data from the payments passing through them, because the distance between the payer and the payee can be so large that it would be likely that the ultimate payer and the ultimate payee could be anyone on the Lightning Network. Lessons learned?
We can decentralize if we try hard enough!
"Hubs bad" can be made "hubs good" if everybody is a hub.
Smart people can solve problems. It's kinda why they're smart.
After LN, there's also the Decker-Wattenhofer Duplex Micropayment Channels (DMC). This post is long enough as-is, LOL. But for now, it uses a novel "decrementing nSequence channel", using the new relative-timelock semantics of nSequence (not the broken one originally by Satoshi). It actually uses multiple such "decrementing nSequence" constructs, terminating in a pair of Spilman channels, one in both directions (thus "duplex"). Maybe I'll discuss it some other time. The realization that channel constructions could actually hold more channel constructions inside them (the way the Decker-Wattenhofer puts a pair of Spilman channels inside a series of "decrementing nSequence channels") lead to the further thought behind Burchert-Decker-Wattenhofer channel factories. Basically, you could host multiple two-participant channel constructs inside a larger multiparticipant "channel" construct (i.e. host multiple channels inside a factory). Further, we have the Decker-Russell-Osuntokun or "eltoo" construction. I'd argue that this is "nSequence done right". I'll write more about this later, because this post is long enough. Lessons learned?
Bitcoin offchain scaling is more powerful than you ever thought.
Binance's deposit problems on 2019 arise from an known, age-old, property of cryptocurrencies, generally known as "malleability". On Feb 5, 2019, Binance was reported to credit, for a second time, some Nano user deposits that had already been credited months before. The presumed reason is that they were upgrading nodes and replaying the block chain, and didn't turn off the deposit engine for this replay. When the new blocks were replayed, they somehow generated new block identifiers on Binance's internal servers (that is, these blocks were not relayed to Binance from outside Binance). These new block identifiers (for old blocks) triggered the deposit processor to create new internal deposits for user accounts, causing these accounts to get unduly credited with extra funds. This general crypto issue has been known for ages and it is surprising that Binance was susceptible to it. For example, the standard bitcoin transaction ID can be changed in a variety of ways without invalidating the transaction. This is called transaction ID malleability. If an exchange considers transactions with new transaction IDs as new deposits, they are susceptible to double deposits. The reason exchanges don't get caught by transaction malleability is that they judge new deposits by the transaction details and not the transaction ID, which can be changed. They also don't credit a user until the transaction has been confirmed a few times. While going down, MtGox famously blamed their problems on bitcoin transaction malleability (even though no one could ever verify these claims). Even though exchanges have adopted workarounds, the general property is potentially problematic enough that bitcoin introduced a new type of transaction identifier with the segwit fork to address this general issue of malleability. The nano protocol doesn't include the concept of confirmations, so counting confirmations to validate deposits can't apply. However, this dissimilarity doesn't mean that the basic problem of transaction malleability isn't known. And it underscores that the general practice of checking transaction details is much better than relying on protocol identifiers (like block or transaction IDs). My understanding is that nano 17.1 fixed the underlying source of malleability that caught Binance, but in upgrading to the fix Binance's deposit processor was running the old protocol and processed a few second deposits.
The word malleability was picked and used intentionally. Why would you want transaction structure to be modified or adjusted or smudged like clay? You wouldn't right? You'd want to trust in the accuracy of the transaction structure and not let some second-layer or third party, or separate script, confirm trust in transaction validity. Right? Except that, despite the issue with signature hashes being slightly different being a minor thing, this inability to be malleable is what was targeted as the prime problem with Bitcoin, and that's what lead to segregated witness. Segregated Witness effectively breaks the existing transaction structure in order to create 2 transaction IDs instead of 1, and in order to run new signature scripts - scripts that aren't defined in the original Bitcoin protocol or whitepaper, in the name of expanding Bitcoin because, "Bitcoin doesn't work". "It can't scale" and "It has malleability issues". When people talk about "the malleability bug" they are referencing signature smudging, as in, when transactions are signed there may be some slight discrepancy regarding the hash before one of the transaction IDs gets cemented into the ledger, for an example as a metaphor: "a capital I might look like a lowercase l" but since it is the signature and not the output data it will still be verified by network nodes before getting added to blocks. What they don't mention is that this doesn't actually have any effect on the transaction output data though, it doesn't result in any problems unless you are reading the data incorrectly. Yep, no effect, money is still transferred just fine. There is no evidence of fraud due to this supposed issue (except for supposedly big one, MtGox). For the vast majority of cases there is no issue. As usual, there is only one transaction that gets cemented into blocks (no doublespends). Important to note here is that, there is no evidence that this is actually a problem with Bitcoin instead of a problem with second-layer or external services or exchanges such as the MtGox scenario where this "malleability bug" becomes a huge problem because they didn't account for the possibility that this slight variation of transaction ID might be entirely intentional. This possibly, seemingly intentional, "flaw" that Bitcoin had (before it was modified to have segregated witness) to "fix the bug" is what makes things like lightning network completely unnecessary as is demonstrated daily by Bitcoin Cash users, the transaction structure is important and signature data is important and neither should be modified or adjusted. It was made that way for a reason. In addition, it isn't an issue if some of the signature data can be slightly off, again, the way the system is designed is that only one record becomes cemented into the blockchain. (No doublespend). Of course, making transaction structure more modifiable was presented as making it easier to expand with future software (such as lightning and schnorr, etc) by Blockstream et al, because it apparently makes it so that there is only ever one definite data tied to one transaction ID, by instead creating TWO transaction IDs and tying them together with a segregated witness script..."A new data structure, witness, is defined. Each transaction will have 2 IDs. " source and the witness ID references the original like a mirror copy, but that also opens up some potentially huge problems later on, and the worst part about it is that these problems would be difficult to prove by a user after they've happened. Why is that? Because if you examine the transaction structure it would appear as though everything is in order even though there may have been an issue (or according to the specification: maybe locked, maybe in a segwit wallet, maybe not yet validated). While there is no proof that money could be stolen if you do not upgrade, there was alarming uncertainty regarding the future of your funds and the future of the network and it does feel like a threat if you do not upgrade. According to the specification of segwit (and segwit users here often deny) "signature data becomes optional". Signature data, the data that is required and described by Bitcoin as a fundamental building block as part of the process of verifying transaction data as it is propagated to the network. Bitcoin uses something called a Elliptical Curve Digital Signature Algorithm. https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm - with segwit the signature data is separated out from the transactions: "This BIP defines a new structure called a "witness" that is committed to blocks separately from the transaction merkle tree." See for yourself: with segwit, "signature data is no longer part of the transaction hash" source. Segwit is "removing this data from the transaction structure committed to the transaction merkle tree" source. In its own words: "how the transaction was signed are no longer relevant to transaction identification". "It allows creation of unconfirmed transaction dependency chains" [... in other words, chains that aren't really Bitcoin ...] "an important feature for offchain protocols such as the Lightning Network". "Segregated witness fixes the problem of transaction malleability fundamentally" the specification then goes on to basically describe Lightning - but is this really a good thing? Micro-transactions with extremely low fees are happening daily already with Bitcoin Cash with zero issues and Bitcoin Cash now has 32MB blocks (Instead of 1MB/2MB) without an unnecessary change to transaction data or signature scripts. "Since a version byte is pushed before a witness program, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork." - so essentially the old chain would be able to become deprecated ... is this really a good thing? was there really a problem to be fixed? do we want any new script system like segwit to define the new blockchain from now on? Actually this is exactly what this is all about, segregated witness is.... in reality... a covert takeover of the old chain signature scripts (or rules) with the new ones that don't actually disable the old methods and system but also don't allow any devs to go back and work with the old scripts anymore, they're considered completely irrelevant now. This effectively kills Bitcoin as you know it. It forces devs to work with the new segregated witness from now on, or be forgotten. Devs are now forced to use the new segregated witness protocol and any future scripts must run according to the segregated witness procotol that has the wtxid and 2 transaction ID format. Not long from now the original txid will likely be deprecated and everything will move over to just using wtxid... this is fairly obvious because, those old signature scripts are still being used today with no issues by Bitcoin Cash just fine.
MTGox seems to have no interest in tracking or talking about the 'missing' or 'stolen' coins
Unlike a pile of cash that is missing, or coins that are lost via theft of private keys, MTGox's Bitcoins were apparently stolen by known users, that is if they were stolen by transaction malleability. Simply to get an account on MTGox you need verification, and a LOT of it. Licences, notaries, apostilles, etc are some of the things required. To use transaction malleability you need to have a real account, and to make withdrawals. These withdrawals are IN THE BLOCK CHAIN and you search properly (and have standard information from inside of MTGOX) you can find each instance of theft and who did it. Why is MTGox not doing this or lettings us know what happened?
"Tokyo, Japan, February 17th, 2014 Dear MtGox Customers, We apologize for the inconvenience caused by the recent suspension of external bitcoin transfers. Fortunately, as we announced on Saturday we have now implemented a solution that should enable withdrawals and mitigate any issues caused by transaction malleability (please see our previous statements for details on this issue). Thanks to our friends at Blockchain.info, MtGox now has a workaround that will use a unique identifier created by Blockchain to show whether transactions have been modified or not. This will prevent any fraudulent use of the malleability issue and protect the assets of our customers. Resuming Withdrawals With this new system in place, MtGox should be able to resume withdrawals soon. At the beginning we will do so at a moderated pace and with new daily/ monthly limits in place to prevent any problems with the new system and to take into account current market conditions. In order to launch the new system, we are going through the following steps:
Re-indexing the entire Blockchain (approx. 32 million entries)
Fully deploying the new NTX ID
Implementing a new bitcoin withdrawal queue that needs to be tested
We will update everyone again by Thursday at the latest. Additionally, you may have noticed that we have added a new login system that sends you an email when you successfully access your account. This is an additional security layer, but as always we strongly encourage our customers to use the 2-step authorization options available in our Security Center. Thank you again for your support, and we look forward to resume bitcoin withdrawals as quickly as possible. Best regards, MtGox Team" edit: formatting
(I've seen a lot of people thinking Bitcoin Cash did nothing to remove transaction malleability, and asking whether that might hold us back. I'm posting this mostly so I can just link to it when someone asks this again, but feel free to pin it should it prove to be useful.) The DAA upgrade included the NULLFAIL and LOW_S BIPs, both of which remove sources of transaction malleability. According to this comment (https://www.reddit.com/btc/comments/6ow9bo/does_bitcoin_cashbitcoin_abc_fix_transaction/dkksson/) by Deadalnix (A Bitcoin ABC developer), this should ensure that p2pkh transactions (the simple kind used for nearly everything) aren't malleable anymore. You can read more about this upgrade at https://www.reddit.com/btc/comments/7cbt2i/bitcoin_unlimited_bitcoin_cash_edition_1120_has/. Some people wonder what transaction malleability even means, so I'll address that as well. When a transaction spends anything, it refers to the hash of a previous transaction. This hash is the output of an irreversible mathematical function, uniquely identifying that transaction. If the contents of the transaction change, the hash changes too. Crucially, this hash also covers the signature. There are a few ways to alter the signature data (even from transactions that aren't yours in the first place) to get an equally-valid transaction with a different hash. If this altered transaction makes it into the blockchain, rather than the original, that's what we consider to be malleation. This is never an issue to any well-written software, though MtGox blamed its problems on this for a short while. Lightning Network needs unmalleable transactions because it relies on unconfirmed transactions to work. It needs to make sure the transaction hashes for those transactions remain the same, despite them not being in blocks. This is why it needs SegWit. I hope this post has been informative. If anyone has something to add, please do! I'll edit in anything important that I missed.
TL/DR: A young man had a secret. To keep it hidden, he kept digging until the hole was a billion dollars deep. This is a speculative tale of a great bitcoin theft from MtGox in 2011 and the efforts that this man undertook to fix it. The tale explains the bitcoin bear market of 2011, the explosive rally of 2013, delayed fiat withdrawals, malled transactions, and a bot named Willy. “By the time you realize that real life has begun, you are already three moves in.”—Author unknown It was June 19, 2011. Mark, a 26 year-old young man—a boy really—was ecstatic. He had recently purchased MtGox—a small, online exchange for trading virtual tokens—and business was booming. These virtual tokens were called bitcoins and Mark loved them. Bitcoins were an obscure curiosity: a peer-to-peer electronic cash system that allowed users to store and exchange credits with any other user in the world, nearly instantly, and without the assistance of a third-party or the permission of an authority. All that was needed was a 78-digit secret number—a key if you will. In order for his customers to withdraw their bitcoins over the internet, MtGox stored some of these keys on its online server. The remaining keys were stored on USB drives and backed up on paper to prevent theft should the server be compromised. But theft was hardly a concern. In October of 2010, bitcoins were trading for $0.10 and the half a million bitcoins held by MtGox was worth only $50,000. But still Mark took precautions, diligently moving bitcoins to offline storage and leaving only what was necessary for customer withdrawals online. He truly wanted both his business and bitcoin to succeed. By April, the bitcoin price had risen to $1 and by June it had exploded to $30. Between June 1 and June 15, an additional one million bitcoins were sent to MtGox and immediately sold, crashing the price back to $10. It was a hectic time, with hundreds of customers needing help, visits from the FBI related to the Silk Road black market, and stress related to the recent market crash. Young Mark was becoming a victim of his own success: there simply wasn’t enough time to get everything done. On this very day in June 2011, the keys to the recently-deposited 1,000,000 BTC were still sitting on his server. Later this day, a group of hackers gained access to MtGox servers and executed fake trades that the world could see, driving the nominal price of bitcoin near $0. Mark was frantic. He quickly regained control of the servers and learned the dark truth: the million bitcoins that had recently flooded in earlier that month were gone. Mark admitted publically to the hack, rewound the false trades, but kept the truth of the missing coins a secret. How could this 26-year old explain to his customers that he had lost their bitcoins? And if the world found out, would this kill the thing he loved so dearly? Would he go to jail? Or worse yet, would someone kill him? Mark decided that he would do what he thought was right: he would slowly earn back the lost bitcoin with MtGox trading fee profits and eventually make his customers whole again. He still had over 500,000 BTC left—he moved 424242.42424242 BTC between bitcoin addresses and convinced the community that MtGox was solvent. As long as withdrawals didn’t exceed deposits over a long period of time, no one would ever find out the truth. Or so he thought. Meanwhile, the bitcoin thieves slowly mixed their coins with other coins, obfuscating the chain of ownership, and then re-selling these coins on MtGox using sock-puppet accounts. Mark tried to stop them, but there was no way he could know for sure which accounts were fraudulent—he even accused innocent people of bitcoin laundering. The constant selling of these stolen bitcoins drove the price down to $2 in November 2011. Mark faithfully used all of the MtGox profits to purchase coins back during this decline. But he would never use customer funds—that was a line he swore not to cross. The selling of these stolen bitcoins continued at a diminished rate over 2012, and Mark continually purchased coins using the MtGox trading fees. The bitcoin economy was growing and new exchanges were opening up across the world. His bitcoin reserves weren’t building fast enough but the price of bitcoin kept rising (along with the dollar value of the missing bitcoins). He was worried that other exchanges would suck coins out of Gox and reveal his secret. He decided he needed to take decisive action: for the first time, he used customer funds to purchase real bitcoins. These large purchases by Mark further increased demand and ignited the great rally of spring 2013 when the bitcoin price shot from $20 to $266. Mark had reduced his liability in bitcoins, but in dollar terms the coins that were still missing were worth more than ever before. On May 15, 2013 the US Department of Homeland Security seized millions of dollars from the MtGox Dwolla bank account. MtGox dollar reserves were already depleted at this point, and with the recent seizure, Mark could no longer make good on customer withdrawals in US dollars. Under the guise of “banking problems,” MtGox slowed US dollar withdrawals to a trickle in the summer of 2013. Customers became increasingly worried and began to bid up the price of bitcoin on MtGox, as this was the only way to escape with their funds. MtGox had little fiat and very little bitcoins, but it learned one thing: as the price differential between Gox and BitStamp grew, the outwards flow of bitcoin slowed dramatically. And so Willy was born. Willy was a bot, discovered by Wall Observers from bitcointalk.org and named by Opet on Bonavest's trading show, who would consistently purchased bitcoins at regular intervals between November 2013 and February 2014. Evidence that Willy belonged to Mark was revealed when both web and API trading at Gox was disabled for a brief period of time, exposing Willy as the only one left buying. Willy served two purposes: he drove the price of bitcoin on the MtGox exchange high, thereby slowing and sometimes reversing the outward flow of real BTC, and he reduced the number of GoxBTC held by clients. Of course, this meant that Willy eventually became the owner of a huge number of GoxBTC (that were of course no longer backed by real BTC). By December, the situation at MtGox was grim. In a desperate attempt to attract more funds, Mark offered reduced trading fees under the guise of celebrating their 1,000,000th customer. This partially worked, but Mark knew it was too late. If MtGox collapsed, it must appear that he didn’t know about the theft until now—for it was better to appear incompetent than criminal. It was time to cover his tracks. He purposely mixed immature coins into bitcoin withdrawals to delay the outward flow of coins, and later began malling his own transactions. He added the Gox malleability weakness not as a bug, but as a feature, so that it would seem plausible that outsiders had recently stolen the coins without his awareness. No coins were actually lost to malleability. The MtGox coin supply dwindled to 2,000 BTC and on February 7, 2014. He had no choice but to disable bitcoin withdrawals. The end was near. The problem Mark faced was that his customers had $150,000,000 credited to their accounts, yet the MtGox bank account only contained $38,000,000. He could blame the missing bitcoins on transaction malleability, but how could he explain where the fiat money went? He shifted Willy into reverse and cranked the throttle. Willy relentlessly dumped bitcoins into the open bids. The price fell further and further, eventually dropping well below the BitStamp price. But still not enough people were buying! He needed his customers to buy the GoxBTC. Willy kept dumping coins until finally the price dropped below $100. MtGox even acquired new USD bank wires from customers looking to purchase the cheap coins. By this time, the majority of Gox customers had converted their dollars into bitcoins. On February 28, 2014, Mt Gox filed for bankruptcy protection in Tokyo, reporting 6.5 billion yen in liabilities, 3.8 billion yen in assets, and 750,000 of customer bitcoins missing. Willy had failed to completely close the fiat solvency gap and Mark finally admitted to having lost the coins. Now we watch the rest of the story unfold. A story of how an oversight during a hectic period, an untimely theft, and an attempt to cover it up, lead to the greatest loss in the history of bitcoin. Cross-posted from: https://bitcointalk.org/index.php?topic=497289.0
My post went unoticed here so here is the topic: It has been widely said that Transaction Maleability (TM) issue couldn’t be the answer to the theft (http://arxiv.org/abs/1403.6676) however I finally have some doubt about it.
Firstly, even if that's questionable, MagicalTux himself proved the opposite by isolating 1000 BTC using malleability.
Secondly, if you have a look at wizsec report, it is known that part of the stolen BTC went back to MTGOX...why the hell would you do that? Maybe because if you want to use TM, you need to have some BTC to do that?
Finally, according to Wizsec, the way the BTC have been stolen is a logaritmic curve. The curve seems linear at the beginning and then a function depending of the time. I would explain it as follow: During first period, the theft was stoling a constant amount of BTC at each fraudulent transaction. After that, for some reason (the theft may started to have some doubt about the solvability of MTgox or when it started to be publicly known that MTGox was facing problems), the theft may have started to decrease the BTC quantity he was sending back to MTGox for TM purpose. The way he reduced that quantity gives the shape of the curve from 1st January 2012 until the end.
I tried to put that into equation: Q is the quantity of stolen BTC at each fraudulent transaction via TM (Q is constant during first period and then variable), S the total BTC at MTGox when the TM issue started, MAH and MEH respectively the MTGox Actual BTC Holding and MEH the MTGox Expected BTC Holdings. We assume that the thief would send back half the sum he stole (Q/2) to MTGOX to use it again for the next TM. The wizsec curve shows MAH- MEH First period: linear (constant stolen quantity)
- No TM : MAH=S , MEH=S - 1st TM : MAH=S-Q , MEH=S-Q/2+Q/2=S (MTGox expected only Q/2 less BTC but it actually had Q less BTC due to TM. - 2nd TM : MAH=S-2Q , MEH=S - nth TM : : MAH=S-nQ , MEH=S , n being the number of fraudulent transactions - Finally: MAH- MEH=-nQ
If we assume that, the amount of BTC stolen Q is constant, the final equation (-nQ) is a deacreasing line function of the number of fraudulent transaction n. This could fit the beginning of the wizsec plot (until January 2012). The constant amount of stolen BTC Q and the total amount of fraudulent transaction are tied to each other, thus one of them is chosen arbitrarily to match the curve. Why are they tied? With the hypothesis that fraudulent transaction went homogeneously trough time. We can then notice that the linear part of the plot represent 22% of the total length (of time or of transaction as it's homogenous) and 450 000 is about the number of BTC missing at that time. Thus by using the line equation determined above (-nQ), we got the following equation: 0.22.Q.N_fraudulent_transaction~450 000. This means that the number of fraudulent transaction is tied to the constant amount of stolen BTC with the following equation: N_fraudulent_transaction=450 000/(0.22.Q), see that plot. We can notice that only around 200 transactions were necessary if the theft was stoling 10k BTC/fraudulent transaction during linear period. Second period: variable stolen quantity Now if the theft starts to decrease the amount of BTC stolen , for example if Q become Q.0.90.026*n, see that plot: quantity of stolen BTC vs fraundulent transaction number,
we got the following curve that match the one from Wizsec. I know this is really simplified, but at first approximation if TM occured, what do you think about it? Edit: here is the script
clear all close all %% Parameters Q1=1000; % Constant amount of BTC stolen %% Script (do not edit) % ############ First period (linear) ############ n=1:round(450000/(0.22*Q1)); % Fraudulent transaction T1=-n*Q1; % Linear part equation % ############ Second period (varible) ############ Nl=floor(0.22*length(n)); Nn=length(n); % Tune parameter P1 in T2=-Q1*(((0.9.^(P1*n)-1)/(0.9^P1-1))-1) to match wizsec plot syms x eqn = -Q1*(((0.9.^(x*n(Nn-Nl))-1)/(0.9^x-1))-1)-n(floor(0.22*length(n)))*Q1==-800000; P1 = vpasolve(eqn,x); Q2=Q1*0.9.^(P1.*n); T2=-Q1*(((0.9.^(P1*n)-1)/(0.9^P1-1))-1); % ############ Mix linear & variable ############ Q3=[ones(1,floor(0.22*length(n)))*Q1 Q2(1:Nn-Nl)]; T3=[T1(1:floor(0.22*length(n))) T2(1:Nn-Nl)-- T1(Nl)]; %% Plot 1 Difference between actual and expected MTgox BTC holdings figure; plot(n,T1,'linewidth',2);hold on plot(n,T2,'linewidth',2);hold on plot(n,T3,'-.m','linewidth',2);hold on xlim([0 n(end)]) ylim([-1000000 100000]) grid on xlabel('n (fraudulent transation number)') ylabel('BTC') title('Difference between actual and expected MTgox BTC holdings') legend('Constant stolen quantity Q','Variable stolen quantity Q','Mix of constant and variable stolen quantity Q') set(gca,'fontsize',16') %% Plot 2 Bitcoin stolen at each fraudulent equation figure; plot(n,Q3,'linewidth',2);hold on title('Bitcoin stolen at each fraudulent transaction') grid on xlabel('n (fraudulent transation number)') ylabel('Q (bitcoin stolen at each fraudulent equation)') set(gca,'fontsize',16') xlim([0 n(end)]) %% Plot 3 Total number of fraudulent transaction Qp=10:10:1000; np=round(450000./(0.22*Qp)); figure; plot(Qp,np,'linewidth',2) title('Total number of fraudulent transaction') grid on xlabel('Constant nomber of BTC stolen during first period') ylabel('Total number of fraudulent transaction') set(gca,'fontsize',16') ylim([0 10000])
In the past, a Bitcoin "crash" could happen from something as simple as an exchange having a bit of lag or an underground marketplace being shutdown. These crashes were much more severe too, with Bitcoin losing up to as much as 90% of it's value from one small issue alone. This past week, Bitcoin seems to have been hit by just about everything, with little good news. Pretty much every type of issue that Bitcoin faces came up in the past couple weeks. First, rumors of Russia banning Bitcoin spread, causing a lot of fear. I'm not exactly sure what the state of this is now, but I know it caused a lot of concern. Next, Mtgox halts Bitcoin withdrawals, and makes the transaction malleability bug sound like the end of Bitcoin. This mild exploit caused enormous fear and the press made it sound like the Bitcoin protocol was hacked. Other exchanges and services turned out to be effected too, and it created further problems with the network. Fixes are in the works. Third, The new silk road was either hacked or the operator ran away with the coins. What exactly happened is controversial and I'd rather not take a stance on this, but what we do know is that someone ran off with lots of Bitcoins, and the illegal marketplace is in ruin. So in the past 2 weeks, we've had: -Exchange issues -Technical problems and fear -Major underground marketplace's Bitcoins being hacked/stolen. -Government interference Yet with all of these problems coming at once, Bitcoin's value dropped less than 20%($800->$650). In the past just one of these problems occurring could have caused a 50% or larger crash, yet all of them together had a much less powerful effect. Bitcoin will become even less volatile once more people start to use it, and as more people are willing to buy during a crash. If people stop panic selling as much and instead use crashes for cheap coins, the price instability thins out. We'll likely still have a bubble whenever Bitcoin's next growth spike occurs, and large fluctuations in value, but it shouldn't be nearly as severe as it has been in the past unless a massive bug occurs that destroys the network as a whole. Bitcoin is certainly Volatile now, but it should become better with time.
https://www.mtgox.com/press_release_20140210.html Original message from their website: Dear MtGox Customers and Bitcoiners, As you are aware, the MtGox team has been working hard to address an issue with the way that bitcoin withdrawals are processed. By "bitcoin withdrawal" we are referring to transactions from a MtGox bitcoin wallet to an external bitcoin address. Bitcoin transactions to any MtGox bitcoin address, and currency withdrawals (Yen, Euro, etc) are not affected by this issue. The problem we have identified is not limited to MtGox, and affects all transactions where Bitcoins are being sent to a third party. We believe that the changes required for addressing this issue will be positive over the long term for the whole community. As a result we took the necessary action of suspending bitcoin withdrawals until this technical issue has been resolved. Addressing Transaction Malleability MtGox has detected unusual activity on its Bitcoin wallets and performed investigations during the past weeks. This confirmed the presence of transactions which need to be examined more closely. Non-technical Explanation: A bug in the bitcoin software makes it possible for someone to use the Bitcoin network to alter transaction details to make it seem like a sending of bitcoins to a bitcoin wallet did not occur when in fact it did occur. Since the transaction appears as if it has not proceeded correctly, the bitcoins may be resent. MtGox is working with the Bitcoin core development team and others to mitigate this issue. Technical Explanation: Bitcoin transactions are subject to a design issue that has been largely ignored, while known to at least a part of the Bitcoin core developers and mentioned on the BitcoinTalk forums. This defect, known as "transaction malleability" makes it possible for a third party to alter the hash of any freshly issued transaction without invalidating the signature, hence resulting in a similar transaction under a different hash. Of course only one of the two transactions can be validated. However, if the party who altered the transaction is fast enough, for example with a direct connection to different mining pools, or has even a small amount of mining power, it can easily cause the transaction hash alteration to be committed to the blockchain. The bitcoin api "sendtoaddress" broadly used to send bitcoins to a given bitcoin address will return a transaction hash as a way to track the transaction's insertion in the blockchain. Most wallet and exchange services will keep a record of this said hash in order to be able to respond to users should they inquire about their transaction. It is likely that these services will assume the transaction was not sent if it doesn't appear in the blockchain with the original hash and have currently no means to recognize the alternative transactions as theirs in an efficient way. This means that an individual could request bitcoins from an exchange or wallet service, alter the resulting transaction's hash before inclusion in the blockchain, then contact the issuing service while claiming the transaction did not proceed. If the alteration fails, the user can simply send the bitcoins back and try again until successful. We believe this can be addressed by using a different hash for transaction tracking purposes. While the network will continue to use the current hash for the purpose of inclusion in each block's Merkle Tree, the new hash's purpose will be to track a given transaction and can be computed and indexed by hashing the exact signed string via SHA256 (in the same way transactions are currently hashed). This new transaction hash will allow signing parties to keep track of any transaction they have signed and can easily be computed, even for past transactions. We have discussed this solution with the Bitcoin core developers and will allow Bitcoin withdrawals again once it has been approved and standardized. In the meantime, exchanges and wallet services - and any service sending coins directly to third parties - should be extremely careful with anyone claiming their transaction did not go through. Note that this will also affect any other crypto-currency using the same transaction scheme as Bitcoin. Conclusion To put things in perspective, it's important to remember that Bitcoin is a very new technology and still very much in its early stages. What MtGox and the Bitcoin community have experienced in the past year has been an incredible and exciting challenge, and there is still much to do to further improve. MtGox will resume bitcoin withdrawals to outside wallets once the issue outlined above has been properly addressed in a manner that will best serve our customers. More information on the status of this issue will be released as soon as possible. We thank you for taking the time to read this, and especially for your patience. Best Regards, MtGox Team
Backstory: Recently, one of the largest Bitcoin exchanges said they weren't letting people withdraw Bitcoins due to technical issues (a process called "transaction malleability," which I can't really explain but has been known for awhile). This caused much consternation and a precipitous drop in the value of BTCs. This exchange also released a statement blaming Greg Maxwell, one of the original Bitcoin developers for the "technical issues" they were having. This has caused much drama. Keep calm, transaction malleability is not double spending. One of the big "selling points" of Bitcoin is that you can't double spend. As the name suggests, double spending is when you spend the same money twice. It's bad for business and good for thieves.
So Gox decided to take the Bitcoin ship down with them blaming their shortcomings on well known and documented protocol limitations. Shame!
so gox can buy cheat coins to make up for the loss.
That's right, folks, this exchange is crippling their business and reputation...so they can sink the cost of Bitcoins so they can buy them more on the cheap.
Mt Gox's incompetence once again puts BTC on sale? I'm not complaining.
Yep, my buttcoins just dropped in value 20%, but IDGAF because I'm gonna buy more.
You make it sound a lot less apocalyptic than the MT Gox press release did. To the top with you!
They just purposefully spread FUD throughout the bitcoin world for the sole purpose of diverting attention while they fix their shit. This transaction malleability thing has been known for a long time and has plenty of easy ways to work around it, like just look and see if there's a double spend attempt on outputs before auto-crediting your internal books. The fact that Gox's shitty coding didn't do that is entirely their fault, and instead of owning up to it, they're trying to cause an earthquake of FUD to divert attention and buy themselves time. That's not just sneaky, that's truly evil. Fuck them. Fuck them so much. /rant
FUCK THEM THIS PR MOVE IS LITERALLY EVIL. Now, I tend to save concepts of "good" and "evil" for actions that have a considerable moral weight, like when some piece of shit steals my parking spot, but this takes the cake. I speculated invested in a volatile commodity and my speculation investment has tanked, so I'm totes raging about it on Reddit.
Tin foil hat time. What if a bunch of BTC got stolen and MtGox knows this. So they make FUD that blames bitcoin protocol knowing it will crash the price. They then take USD and buy up cheap bitcoin to cover the BTC that got stolen. What if this new USD will actually drive the price to new HIGHS!
If your going to claim to be the representative entity for Bitcoin then act like it. Otherwise you are just as big of a joke as that incompitent twit Mr Krabapple bouncing around on his blue ball. I mean, Jesus H. tap dancing on a crispy truiscuit Christ, do something, anything, or gtfo. *Edit: Help us Obi-Wan Antonopoulos, you're our only hope.
He's literally tanking Bitcoin! Let's take a rash action in response to a rash action!
Karppoopels is on the BTC foundation board? fuuuuuuck thats bad.
Anyone else from The Bitcoin Foundation want to shit on Bitcoin some with more negative PR?. Drugs, money laundering, "bugs"…c'mon guys…gun running could be next? or something worse?????. I'm sure you've got plenty more from where Shrem and Krapeles came from.
Perfectly timed manipulation on the part of MTGox, this news comes as the 3 day MACD happens, (exponential average crosses the average bitcoin price), it hadn't crossed since early 2013, so big movement was to be expected. You can see it on the 3day chart on bitcoinwisdom, the blue line and brown line crossing, this is a BIG sign for automated trading bots to make a move, in this case the exponential average (indicating the latest movement trend) went below the average, this means the trend is downwards. So MTgox preps up their sells, sets a weekend climate of "some big news is about to come out on monday, everyone keep an eye on your coins" Then DROPS the bad news, and BOOM goes the dynamite. we have an epic crash. Meanwhile MTgox sets up its orders on BTC-E around 200.
Most people trust MtGox. It's the oldest exchange, was the most mentioned in the media. Their press release is pure bullshit but it's a subject that's way too technical anyway for most people to grasp. We need other big players to step up and reassure people, or this could be the death of Bitcoin.
And what will happen now?
Go on, sell your bitcoin, and bang your head into the wall when the price goes back up. In the mean time, I'm enjoying the cheap coins. Hmmm. If one were a Gox insider, today would've been a good day to buy bitcoins. Either for a personal account or for the company's, in order to cover past fuckups. Are you concerned about the price of your holdings? I appreciate that we just got cheap coins.
Plus the general hatejerk:
How I look forward to the day bitcoin won't be goxed anymore. Even those outside of gox managed to get goxxed today. Gox has done the greatest service & disservice to Bitcoin. Sounds like Mark is trying to raise more fear. He needs to step down from the Bitcoin Foundation. I guess most of the other players fear legal problems if they say anything bad about Gox...
This press release from Gox was incredibly shady and deceitful. The majority of Bitcoin market crashes are because of them. We need to step up. I'm willing to step up. Get ahold of me on here! I'm willing to invest $50,000 in a LEGIT U.S. Bitcoin exchange for 5% of the business. We can't stand for this, people. We can't let lies like this affect the Bitcoin community this much
Hi everyone, I know very few people will see this and that's okay. I decided after a week of severe depression, anxiety, self-loathing, and general fucked up thoughts that I needed to talk about what I did. On the scope of a confession, it isn't much to some people, but to me it is a huge and daunting fuck up that I'll be paying out the nose for. The reality is I might even be homeless due to this. I used a throwaway for this because a few people I know have my primary acct and I can't bear the shame of them knowing yet. To get to it, I made a huge mistake and lost all my money. ALL OF IT. If it isn't obvious already, I don't have a lot of money. I am not a all that familiar with bitcoin and only recently began taking part in the community. /Bitcoin has been my bible and go to source nearly every day for the last 6 months. But again, I don't have much money and I decided that I have a this tremendously good feeling about where bitcoin is going so I warily invested in a couple coins around January 2nd at about 809 a coin from coinbase. I was terrified of losing what I put in. Then the next day, the price jumped about $30! I was ecstatic! I was amazed! I couldn't believe that my investment had begun working for me after only a day! It was a great feeling. At the same time of all this, I had just finsihed up a huge ordeal with Bank of America over fradulent charges on my debit card that sent my account into the negative and had intitially accured almost $1000 in overdraft and other fees. It took months to get all my money back and in the end still lost out on about $200 dollars. Needless to say, I was more wary of my bank than bitcoin at this point and bitcoin was GIVING me money instead of giving it away. So I did the only logical thing I could think of at the time and put the rest of my savings into BTC. And guess what? It went up again! I was so happy with my decision that I started reading more and more about BTC. Then the fluctuations in the BTC market started happening. I started to get nervous because the only cash I had was losing value and fast. I knew that it had a habit of fluctuating like that but I never had any money invested before. The anxiety was real for me every day I'd hop on /Bitcoin and see the news about mtgox ( then after that the silkroad 2 hack.) So, about a week ago when coinbase's price was plummeting still due to gox's problems and bad press and so on I started getting nervous. More nervous than I had been before. My "investment" had lost almost 200 a coin and I was sick to my stomach watching and waiting for the price to come back up like it "always" does. I was posting around a few forums and asking questions about what I should do? What could I do in the mean time? Should I pull out and take my losses? I got to talking to this guy on one of the forums who seemed to know what he was talking about. He mentioned the dice site satoshi bones and how he was in the same spot as me, made one bet and came out 10BTC richer. Even sent the tx ids. It was awesome to see and was even more awesome to imagine. He went as far as to send me .05 btc (holy shit!) and said "Make a few bets and watch, some of the odds are great." So I did that. I sent a few bets of .001btc and made nearly .5 btc in 5 minutes. I was hooked. I was going to make my money back. I was going to make a few bets and get out with what I put in, no more. So I proceeded to make bigger bets. I was making money. I was getting good at watching and "considering the odds." It wasn't really the case, I was just geting lucky here and there. I had no idea what the fuck I was doing. Then the transaction malleability thing happened. Or, rather, it was probably happening the whole time. I don't know. I don't know what it did to my MultiBit account, but it was sending my coins and not updating my balance. I was losing more than I knew because the double spends ended up looking like I had more in my overall account than I did. At one point, it appeared that I had TRIPLED my initial BTC investment over all and I was nearly crying with joy. Then I couldn't access my funds. It said I had a "Balance" of 30btc, but "Spendable" was .05. I knew that it took a little while for the transactions to get through the system and clear but minutes turned into hours and hours into days. When the whole story about the transaction malleability broke into full swing I started tracing my tx IDs back. I was a nervous wreck at that point. I had so many double spends and unconfirmed transactions that there was no way to actually find out how much I truly had left. When I looked through multibit's logs, it had mulitples of the "wins" that I knew I had but numerous tx Ids. I couldn't keep track of it all. Attempting to "reset" the blockchain on Multibit would only cause it to crash (probably because I had sent and received sooooo many unconfirmed transactions back and forth between that game.) I decided to grab my private keys and attempt to use Bitcoin-QT to sort it all out to no avail. It too said I had a balance around 30 BTC unconfirmed (a mind blowing amount of money for me!!!!!) I relaxed and decided I would just have to wait it out to get my money and I'd hold off on grocery shopping until the weekend (today.) Even if I had half of that after it all cleared up, I'd have made a HUGE profit. About two days ago everything calmed down and my balance began fluctuating like mad on both the Multibit client and Bitcoin-qt. It went UP at one point to 40 BTC even! Then transactions started to disappear. Mostly, the transactions that disappeared were the "wins." I assume this is because all of the unconfirmed txs or double spends started being pushed out of the system? I have no idea. I'll take a second to mention that I've never had an interest in gambling whatsoever. I've been to vegas, played a few slots, sat in for some poker and blackjack, would lose and just walk away. However, the last couple days I was consumed by the dice game. I thought I was making incredible money, hand over fist. Yesterday, my balance completely cleared up. I'm broke. I have nothing left. I pissed away even my winnings (maybe 3btc) I had before the transaction malleability started fucking things up. I cried for the first time in 10 years yesterday. Today, I cried again. Over the last week I fell into a depression and was overcome by this urge to just stop existing. Not really suicide at first, but, more of a "I want to close my eyes and let it all blow over." Then, when that didn't happen, I did start considering suicide. I have no money left. I don't know what the fuck I'm going to do for rent, for food, for gas, for my fucking books next quarter. I moved to california on my own about 3 years ago and have zero family in the area. I don't have family to lean on finacially whatsoever (I come from a seriously bad luck/misfortune/poor family.) Monday I'll be heading to my university to find out what I can do and if I qualify for any loans. Or something. I don't know. But right now, I need to tell people and persevere and try to make it out of this. But, my point of posting here isn't a pity party or to draw out "sorry for the bad luck" responses. I did this to myself and this pales in comparison to the bad luck others have had. I want people to use my sincere and obvious FUCK UP as a lesson. I got caught up thinking I was making money. I wasn't fully aware of what was happening during the transaction malleability shit and made decisions without fully comprehending the situation (and it is NOT the fault of Mulitbit or the dice game even if I wanted something to blame.) Most of all, I was GAMBLING my money away. It was greed and poor decisions. But mostly greed. So, I fucked up. I don't want YOU to fuck up like I did. Please look at the story and realize that it can happen to anyone without fully thinking through your decisions and having a grasp on the situation. And SERIOUSLY consider when you're putting too much money at stake when gambling. You could regret it and be in a shitty spot like myself. Thanks for reading. TL;DR Holy shit I wrote a novel. Sorry. In short, I inadvertently gambled away my only $7000 during the transaction malleability crisis and it is no one's fault but myself. I am now broke and terrified and I don't want YOU to suffer like I did. Do not gamble and do research before you do anything with your money especially if it is all you have. EDIT: Though my intial reason for posting was NOT to focus on why my balance said one thing and the actual balance was another, here is what the balance looks like on my Multibit client right now. However if you look at the blockchain, that's clearly not the case and hasn't been for days and days. These are the addresses I used off and on. Not all of them but those were the most active I think. 17cHzgxRLumqfu6UAddUrJmTujd7goHLrx 1BAKHq37qj1xekitr7adXapLqFrVtAhm8A 1KLug6D1mXoyS12BZipyQ8WHAdNzDmQxMp. Also, when I opened the Client today it seemed to send or revieve "stuck" transactions? I don't know what to tell you all beyond that.
Who dumps 50K coins on the market WITHOUT any significant news?
50K coins dumped on the market in 5 hours WITHOUT any significant news! Blockchain detectives get to work. We need to know whats going on. This kind of shit used to happen over news like "china ban", "mtgox hacked", or karpeles comments that bitcoin was broken (transaction malleability). But there was no significant news today. And I don't think that a lot of longs were squeezed as the price only budged about $30. So someone dumped a large number of coins today. Why? Is it the MtGox thief (or insider) dumping the last of the stolen booty? Or the SR auctioned coins buyers getting out? What happened today is unprecedented. We deserve to know the truth, who was behind today's dumping?
In Bitcoin, transaction malleability describes the fact that the signatures that prove the ownership of bitcoins being transferred in a transaction do not provide any integrity guarantee for the signatures themselves. This allows an attacker to mount a malleability attack in which it intercepts, modifies, and rebroadcasts a transaction, causing the transaction issuer to believe that the ... In Bitcoin, transaction malleability describes the fact that the signatures that prove the ownership of bitcoins being transferred in a transaction do not provide any integrity guarantee for the signatures themselves. This allows an attacker to mount a malleability attack in which it intercepts, modifies, and rebroadcasts a transaction, causing the transaction issuer to believe that the ... Transaction malleability is a loophole in the bitcoin protocol that was most famously used in February 2014 to allegedly withdraw funds from Mt Gox.. The idea behind transaction malleability is that a user who is tracking transactions via their hash would not be able to trace the transaction if the hash was changed. In Bitcoin, transaction malleability describes the fact that the signatures that prove the ownership of bitcoins being transferred in a transaction do not provide any integrity guarantee for the signatures themselves. This allows an attacker to mount a malleability attack in which it intercepts, modifies, and rebroadcasts a transaction, causing the transaction issuer to believe that the ... Home → BitCoin → Transaction Malleability: MtGox’s Latest Woes. BTC World News – Ads. Donate to BTC World News. Donate Bitcoins. BTC World News Tweets. Tweets by @BTCWorldNews. Like BTCWorldNews. Transaction Malleability: MtGox’s Latest Woes. Monday 10th, February 2014 / 21:23. View all articles by Bitcoin Magazine . MtGox, a Bitcoin exchange that used to have over 90% market share ...
Sending bitcoins from Mtgox to your bitcoin wallet
-----2015 Update----- This video was made 7 months before the collapse of MTGOX. At that time, MTGOX was experi... What is transaction malleability? Can transaction IDs be changed? How does Segregated Witness make the Lightning Network easier to run? When will we have multi-party channel funding and channel ... This is a tutorial about how we can use the SIGHASH_NONE flag of a Bitcoin SV transaction in order to modify it with additional outputs after our service receives it from their users. Share, shill ... Bitcoin Transaction Malleability Theory in Practice - Duration: 48:02. Black Hat 2,031 views. 48:02. Bitcoin crash on mtgox exchange ( timelapse ) April 10 2013(music by Klute - Buy More Now!) ... A mysterious vulnerability from 2011 almost made the Bitcoin network collapse. Silk Road, MTGox, and potentially many more trading websites claim to be prone to "Transaction Malleability." We will ...