[Bitcoin-development] MtGox blames bitcoin
What is the official response from the Bitcoin Core developers about MtGox's assertion that their problems are due to a fault of bitcoin, as opposed to a fault of their own? The technical analysis preluding this mess, was that MtGox was at fault for their faulty wallet implementation. Drak -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
Hi, On Mon, Feb 10, 2014 at 12:28 PM, Drak d...@zikula.org wrote: What is the official response from the Bitcoin Core developers about MtGox's assertion that their problems are due to a fault of bitcoin, as opposed to a fault of their own? The technical analysis preluding this mess, was that MtGox was at fault for their faulty wallet implementation. this seems a fair explanation of what happened: http://www.reddit.com/r/Bitcoin/comments/1x93tf/some_irc_chatter_about_what_is_going_on_at_mtgox/cf99yac -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
On Mon, Feb 10, 2014 at 3:28 AM, Drak d...@zikula.org wrote: What is the official response from the Bitcoin Core developers about MtGox's assertion that their problems are due to a fault of bitcoin, as opposed to a fault of their own? The technical analysis preluding this mess, was that MtGox was at fault for their faulty wallet implementation. In the real world fault seldom falls in a single place. Bitcoin is at fault— in many places— for making it harder for implementers to get things right. MtGox is at fault for not implementing in a way that copes with behaviors in the Bitcoin protocol which have been known since at least 2011. (https://en.bitcoin.it/wiki/Transaction_Malleability). Not that Bitcoin-QT handles Malleability fantastically— but because it tracks inputs it will still detect the mutant transactions. An interesting point which I haven't pointed out elsewhere is that for the question of basic funds safety in re-issuing a transaction mallablity is basically irrelevant. Say you pay someone and it doesn't go through (or it does and you don't see it because its been mutated and your software can't detect that), and they ask you to reissue if you reissue without double-spending any of the original inputs you are at risk of getting robbed. This is true with or without malleability. Without the double-spend of at least one input the original transaction could just go through in addition to your reissue. Say that you do make sure to double spend at least one input— then the result is funds safe safe, regardless of if a mutation happened. Say you want to support _canceling_ a payment (send me the goat instead!) rather than reissue you still must double-spend the attempted payment to cancel it, since it still might go through if you don't. And the double spend works to protect this case regardless of if the transaction was mutated. For support and accounting purposes you absolutely do need tools to identify mutated transactions, so long as mutation exists... so we ought to provide some better tools there. But I can't think a case where mutation handling is necessary or sufficient for cancellation security, but— rather— input tracking appears to be both necessary and sufficient in all cancellation cases. This helps explain why Bitcoin-QT— whos mutation handling kinda stinks— doesn't ever end up in a really bad situation with mutants: it tracks inputs pretty well. In any case, I've always been happy to help out Mtgox with technical issues. Having some specs for a stable transaction ID would probably be helpful to many applications, even if it isn't the critical key you need for cancellation security. Removing mallability entirely has been a soft long term goal, and there were recently (as in today) some posts about it— look at the list archives... though it won't happen fast since all signers/wallets will need to be updated. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Malleability and MtGox's announcement
Hi all, I was a bit surprised to see MtGox's announcement. The malleability of transactions was known for years already (see for example the wiki article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it, or mails on this list from 2012 and 2013). I don't consider it a very big problem, but it does make it harder for infrastructure to interact with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to avoid it altogether to make life easier for everyone. But we can't just change all infrastructure that exists today. We're slowly working towards making malleability harder (and hopefully impossible someday), but this will take a long time. For example, 0.8 not supporting non-DER encoded signatures was a step in that direction (and ironically, the trigger that caused MtGox's initial problems here). In any case, this will take years, and nobody should wait for this. There seem to be two more direct problems here. * Wallets which deal badly with modified txids. * Services that use the transaction id to detect unconfirming transactions. The first is something that needs to be done correctly in software - it just needs to be aware of malleability. The second is something I was unaware of and would have advised against. If you plan on reissuing a transaction because on old version doesn't confirm, make sure to make it a double spend of the first one - so that not both can confirm. I certainly don't like press making this sound like a problem in the Bitcoin protocol or clients. I think this is an issue that needs to be solved at the layer above - the infrastructure building on the Bitcoin system. Despite that, I do think that we (as a community, not just developers) can benefit from defining a standard way to identify transactions unambiguously. This is something Mark Karpeles suggested a few days ago, and my proposal is this: We define the normalized transaction id as SHA256^2(normalized_tx + 0x0100), where normalized_tx is the transaction with all input scripts replaced by empty scripts. This is exactly what would be signed inside transaction signatures using SIGHASH_ALL (except not substituting the previous scriptPubKey to be signed, and not dealing with the input being signed specially). An implementation is here: https://github.com/sipa/bitcoin/commits/normtxid. Note that this is not a solution for all problems related to malleability, but maybe it can make people more aware of it, in tangible way. -- Pieter -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
What is the official response from the Bitcoin Core developers about MtGox's assertion that their problems are due to a fault of bitcoin, as opposed to a fault of their own? The technical analysis preluding this mess, was that MtGox was at fault for their faulty wallet implementation. I'm not a core developer, but I would certainly hope that those who have commit access to the Bitcoin repository don't let themselves be pressured by a company holding back user funds in order to get a patch included into the Bitcoin source code. I think this is less a matter of whose fault it is if a company running a custom wallet implementation has problems peering with a network mostly running another, community-based wallet implementation. It is a matter of common sense that it's just not practical to try to quickly apply an update to a distributed network, which may possibly cause problems with peering and consensus finding. When working with a protocol based on mutual agreement of a large user base, a single entity like MtGox would be better off trying to have their preferred changes implemented slowly if at all, while solving their immediate issues on their side. Problems with transactions being accepted can often be solved by changing the wallet client's way of peering with other nodes, without changing the protocol at all. Thinking this further, I am kind of surprised that something like this can even become an issue worth discussing. I never heard of a bank which would try to create pressure by suspending money withdrawals until the TCP/IP protocol is changed to match their preferences. Best regards, Isidor Zeuner -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Malleability and MtGox's announcement
Okay, why the everloving FUCK is there not someone on this list with a @mtgox.com address talking about this? I started using bitcoin because I could audit the code, and when the developer cabal does stuff 'off-list' what you do is hand over market manipulation power to the selected cabal of company insiders who are discussing things 'off-list'. The people having a 'private' discussion about how to solve this are TAKING MONEY from everyone else, by having access to insider information. I don't think any of the developers actually have a clue this is the result, because a good chunk of them are employed by for-profit companies funded by venture capital, and VC lawyers are very good at writing employment contracts that provide plausible deniability of insider trading. The press MAKES MONEY (okay, takes money) by manipulating markets, and venture capitalists pay lots of money to ensure the market is manipulated in ways they can profit from. Private market manipulation is one of the costs of anonymity and privacy, and I don't really like paying for some off-list discussion of what appears to be a serious scalability and usability problem. Bitcoin is such a powerful tool because it broadcasts transactions to the network for everyone to see. Can we please broadcast some more technical details to this mailing list, including exactly what MtGox is doing, and how they wish to resolve it? If you gave me the entire code stack that MtGox runs on under an AGPLv3 license, I'm pretty sure I, along with everyone else here could come up with a workable solution. I think a code release would be a huge win for MtGox as well, and would cement their position as market leader in transparent cryptocurrency trading. Otherwise we are just a bunch of dinghys getting capsized one by one in a sea of market-manipulating white whales. Isn't the closed door market manipulation of the big banks one of the reasons we all started using Bitcoin in the first place? Why do revolutions always put the same old bullshit back in power? What we need is some transparent code evolution. On Mon, Feb 10, 2014 at 01:28:42PM +0100, Pieter Wuille wrote: Hi all, I was a bit surprised to see MtGox's announcement. The malleability of transactions was known for years already (see for example the wiki article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it, or mails on this list from 2012 and 2013). I don't consider it a very big problem, but it does make it harder for infrastructure to interact with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to avoid it altogether to make life easier for everyone. But we can't just change all infrastructure that exists today. We're slowly working towards making malleability harder (and hopefully impossible someday), but this will take a long time. For example, 0.8 not supporting non-DER encoded signatures was a step in that direction (and ironically, the trigger that caused MtGox's initial problems here). In any case, this will take years, and nobody should wait for this. There seem to be two more direct problems here. * Wallets which deal badly with modified txids. * Services that use the transaction id to detect unconfirming transactions. The first is something that needs to be done correctly in software - it just needs to be aware of malleability. The second is something I was unaware of and would have advised against. If you plan on reissuing a transaction because on old version doesn't confirm, make sure to make it a double spend of the first one - so that not both can confirm. I certainly don't like press making this sound like a problem in the Bitcoin protocol or clients. I think this is an issue that needs to be solved at the layer above - the infrastructure building on the Bitcoin system. Despite that, I do think that we (as a community, not just developers) can benefit from defining a standard way to identify transactions unambiguously. This is something Mark Karpeles suggested a few days ago, and my proposal is this: We define the normalized transaction id as SHA256^2(normalized_tx + 0x0100), where normalized_tx is the transaction with all input scripts replaced by empty scripts. This is exactly what would be signed inside transaction signatures using SIGHASH_ALL (except not substituting the previous scriptPubKey to be signed, and not dealing with the input being signed specially). An implementation is here: https://github.com/sipa/bitcoin/commits/normtxid. Note that this is not a solution for all problems related to malleability, but maybe it can make people more aware of it, in tangible way. -- Pieter -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper.
Re: [Bitcoin-development] MtGox blames bitcoin
On Mon, Feb 10, 2014 at 03:40:03PM +0100, Isidor Zeuner wrote: What is the official response from the Bitcoin Core developers about MtGox's assertion that their problems are due to a fault of bitcoin, as opposed to a fault of their own? The technical analysis preluding this mess, was that MtGox was at fault for their faulty wallet implementation. I'm not a core developer, but I would certainly hope that those who have commit access to the Bitcoin repository don't let themselves be pressured by a company holding back user funds in order to get a patch included into the Bitcoin source code. This isn't about developers. This is about venture capitalists taking lots of money from unsuspecting investors, and MtGox is in a psy-ops PR-war with multiple other exchanges and lots of places that would like to take their market share and money. Why do you want the 'official' PR-spin-war response approved by the official bitcoin developer PR-firm, who's probably being paid by competitors to MtGox? Name me one single person with commit access to the bitcoin github repository who is *independent* of any venture capital or other 'investment' connections. Fortunately for the rest of us, any dumb farmer can create a copycatcoin Hell, if MtGox hosted their *own* fork of bitcoin I'd run that in a heartbeat. And for full disclosure, I am available for consulting if anyone would like assistance setting up and hosting an independent source code repository that includes good automated regression tests. -- Troy -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes ho...@hozed.org wrote: Name me one single person with commit access to the bitcoin github repository who is *independent* of any venture capital or other 'investment' connections. I am, unless you count the fact that I own some Bitcoin and some mining hardware as 'investment' connections (and that case your comments are worthless). (By not naming anyone else I don't mean to imply there are no others, but I don't want to speak for anyone else. Nor would I necessarily expect the other part(ies|y) to step forward, since this mostly appears to be an invitation to step up and be attacked.) -- Androidtrade; apps run on BlackBerryreg;10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
Well done Gavin for quickly setting the record straight[1] officially as project lead. MtGox tried to blame their issues by throwing Bitcoin under a bus and I am glad there has been a public rebuttal showing up their incompetence which is doing harm to the bitcoin eco system. Basically, yes there are issues, but MtGox should have worked around it. Also thanks to Gregory for also writing[2] about the matter. Drak [1] https://bitcoinfoundation.org/blog/?p=418 [2] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/ -- Androidtrade; apps run on BlackBerryreg;10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Malleability and MtGox's announcement
You must be new here. MtGox very rarely comments on things like this publicly, outside of irc or their website. Second, MtGox problem is a MtGox problem. You have no right to demand access to their private code. If you feel wronged as a customer, sue them. Otherwise, they have no obligation to you. I believe you are barking up the wrong tree. Respectfully, Nick On February 10, 2014 10:14:02 AM CST, Troy Benjegerdes ho...@hozed.org wrote: Okay, why the everloving FUCK is there not someone on this list with a @mtgox.com address talking about this? I started using bitcoin because I could audit the code, and when the developer cabal does stuff 'off-list' what you do is hand over market manipulation power to the selected cabal of company insiders who are discussing things 'off-list'. The people having a 'private' discussion about how to solve this are TAKING MONEY from everyone else, by having access to insider information. I don't think any of the developers actually have a clue this is the result, because a good chunk of them are employed by for-profit companies funded by venture capital, and VC lawyers are very good at writing employment contracts that provide plausible deniability of insider trading. The press MAKES MONEY (okay, takes money) by manipulating markets, and venture capitalists pay lots of money to ensure the market is manipulated in ways they can profit from. Private market manipulation is one of the costs of anonymity and privacy, and I don't really like paying for some off-list discussion of what appears to be a serious scalability and usability problem. Bitcoin is such a powerful tool because it broadcasts transactions to the network for everyone to see. Can we please broadcast some more technical details to this mailing list, including exactly what MtGox is doing, and how they wish to resolve it? If you gave me the entire code stack that MtGox runs on under an AGPLv3 license, I'm pretty sure I, along with everyone else here could come up with a workable solution. I think a code release would be a huge win for MtGox as well, and would cement their position as market leader in transparent cryptocurrency trading. Otherwise we are just a bunch of dinghys getting capsized one by one in a sea of market-manipulating white whales. Isn't the closed door market manipulation of the big banks one of the reasons we all started using Bitcoin in the first place? Why do revolutions always put the same old bullshit back in power? What we need is some transparent code evolution. On Mon, Feb 10, 2014 at 01:28:42PM +0100, Pieter Wuille wrote: Hi all, I was a bit surprised to see MtGox's announcement. The malleability of transactions was known for years already (see for example the wiki article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it, or mails on this list from 2012 and 2013). I don't consider it a very big problem, but it does make it harder for infrastructure to interact with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to avoid it altogether to make life easier for everyone. But we can't just change all infrastructure that exists today. We're slowly working towards making malleability harder (and hopefully impossible someday), but this will take a long time. For example, 0.8 not supporting non-DER encoded signatures was a step in that direction (and ironically, the trigger that caused MtGox's initial problems here). In any case, this will take years, and nobody should wait for this. There seem to be two more direct problems here. * Wallets which deal badly with modified txids. * Services that use the transaction id to detect unconfirming transactions. The first is something that needs to be done correctly in software - it just needs to be aware of malleability. The second is something I was unaware of and would have advised against. If you plan on reissuing a transaction because on old version doesn't confirm, make sure to make it a double spend of the first one - so that not both can confirm. I certainly don't like press making this sound like a problem in the Bitcoin protocol or clients. I think this is an issue that needs to be solved at the layer above - the infrastructure building on the Bitcoin system. Despite that, I do think that we (as a community, not just developers) can benefit from defining a standard way to identify transactions unambiguously. This is something Mark Karpeles suggested a few days ago, and my proposal is this: We define the normalized transaction id as SHA256^2(normalized_tx + 0x0100), where normalized_tx is the transaction with all input scripts replaced by empty scripts. This is exactly what would be signed inside transaction signatures using SIGHASH_ALL (except not substituting the previous scriptPubKey to be signed, and not dealing with the input being signed specially). An implementation is here: https://github.com/sipa/bitcoin/commits/normtxid. Note
Re: [Bitcoin-development] Malleability and MtGox's announcement
I cannot judge the competence of code I've never seen, so I have no position on that. What I HAVE seen quite clearly is both overt and covert market manipulation under cover of blame for 'the developers', or 'the exchange' You're doing it yourself with the phrase 'incompetence'. When you run an exchange of that volume, then maybe you might be in a position to say so, but if you were *invested* in a competitor to MtGox you'd make a lot of money calling them incompetent, wouldn't you? I'm looking to drum up some consulting business by making my observations about market manipulation public, and if I can't drum up any business, at least I can speak my mind free of any non-disclsosure agreements. What do you stand to gain from your statements on this list? On another note, is there any third-party archive of bitcointalk.org? I much prefer mailing lists because *I* have an archive. On Mon, Feb 10, 2014 at 11:39:19AM -0500, Christophe Biocca wrote: The bug MtGox is blaming has been documented on the wiki for years. Mark Karpeles was on IRC publicly discussing the topic https://bitcointalk.org/index.php?topic=458076.msg5052255#msg5052255 MtGox's incompetence has been on public display since day 1. I'm not sure what critical information you think secret cabals are keeping from you. On Mon, Feb 10, 2014 at 11:14 AM, Troy Benjegerdes ho...@hozed.org wrote: Okay, why the everloving FUCK is there not someone on this list with a @mtgox.com address talking about this? I started using bitcoin because I could audit the code, and when the developer cabal does stuff 'off-list' what you do is hand over market manipulation power to the selected cabal of company insiders who are discussing things 'off-list'. The people having a 'private' discussion about how to solve this are TAKING MONEY from everyone else, by having access to insider information. I don't think any of the developers actually have a clue this is the result, because a good chunk of them are employed by for-profit companies funded by venture capital, and VC lawyers are very good at writing employment contracts that provide plausible deniability of insider trading. The press MAKES MONEY (okay, takes money) by manipulating markets, and venture capitalists pay lots of money to ensure the market is manipulated in ways they can profit from. Private market manipulation is one of the costs of anonymity and privacy, and I don't really like paying for some off-list discussion of what appears to be a serious scalability and usability problem. Bitcoin is such a powerful tool because it broadcasts transactions to the network for everyone to see. Can we please broadcast some more technical details to this mailing list, including exactly what MtGox is doing, and how they wish to resolve it? If you gave me the entire code stack that MtGox runs on under an AGPLv3 license, I'm pretty sure I, along with everyone else here could come up with a workable solution. I think a code release would be a huge win for MtGox as well, and would cement their position as market leader in transparent cryptocurrency trading. Otherwise we are just a bunch of dinghys getting capsized one by one in a sea of market-manipulating white whales. Isn't the closed door market manipulation of the big banks one of the reasons we all started using Bitcoin in the first place? Why do revolutions always put the same old bullshit back in power? What we need is some transparent code evolution. On Mon, Feb 10, 2014 at 01:28:42PM +0100, Pieter Wuille wrote: Hi all, I was a bit surprised to see MtGox's announcement. The malleability of transactions was known for years already (see for example the wiki article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it, or mails on this list from 2012 and 2013). I don't consider it a very big problem, but it does make it harder for infrastructure to interact with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to avoid it altogether to make life easier for everyone. But we can't just change all infrastructure that exists today. We're slowly working towards making malleability harder (and hopefully impossible someday), but this will take a long time. For example, 0.8 not supporting non-DER encoded signatures was a step in that direction (and ironically, the trigger that caused MtGox's initial problems here). In any case, this will take years, and nobody should wait for this. There seem to be two more direct problems here. * Wallets which deal badly with modified txids. * Services that use the transaction id to detect unconfirming transactions. The first is something that needs to be done correctly in software - it just needs to be aware of malleability. The second is something I was unaware of and would have advised against. If you plan on reissuing a transaction because on old version
Re: [Bitcoin-development] Malleability and MtGox's announcement
A bitcoin problem is not really my problem, and if MtGox's investors can't seem to understand the value of publishing their code, I'll be happy to take their money as it leaves bitcoin for more distributed and transparent cryptocurrency ecosystems. I feel some sort of moral obligation to point out to this community when something stupid is going on, and if you think a MtGox problem is not a Bitcoin problem then I can't really help you, all I can do is point out my observations and facts as I see them, and then execute trades to relieve those who choose to ignore these facts of their money. Happy trading On Mon, Feb 10, 2014 at 10:57:03AM -0600, Nick Simpson wrote: You must be new here. MtGox very rarely comments on things like this publicly, outside of irc or their website. Second, MtGox problem is a MtGox problem. You have no right to demand access to their private code. If you feel wronged as a customer, sue them. Otherwise, they have no obligation to you. I believe you are barking up the wrong tree. Respectfully, Nick On February 10, 2014 10:14:02 AM CST, Troy Benjegerdes ho...@hozed.org wrote: Okay, why the everloving FUCK is there not someone on this list with a @mtgox.com address talking about this? I started using bitcoin because I could audit the code, and when the developer cabal does stuff 'off-list' what you do is hand over market manipulation power to the selected cabal of company insiders who are discussing things 'off-list'. The people having a 'private' discussion about how to solve this are TAKING MONEY from everyone else, by having access to insider information. I don't think any of the developers actually have a clue this is the result, because a good chunk of them are employed by for-profit companies funded by venture capital, and VC lawyers are very good at writing employment contracts that provide plausible deniability of insider trading. The press MAKES MONEY (okay, takes money) by manipulating markets, and venture capitalists pay lots of money to ensure the market is manipulated in ways they can profit from. Private market manipulation is one of the costs of anonymity and privacy, and I don't really like paying for some off-list discussion of what appears to be a serious scalability and usability problem. Bitcoin is such a powerful tool because it broadcasts transactions to the network for everyone to see. Can we please broadcast some more technical details to this mailing list, including exactly what MtGox is doing, and how they wish to resolve it? If you gave me the entire code stack that MtGox runs on under an AGPLv3 license, I'm pretty sure I, along with everyone else here could come up with a workable solution. I think a code release would be a huge win for MtGox as well, and would cement their position as market leader in transparent cryptocurrency trading. Otherwise we are just a bunch of dinghys getting capsized one by one in a sea of market-manipulating white whales. Isn't the closed door market manipulation of the big banks one of the reasons we all started using Bitcoin in the first place? Why do revolutions always put the same old bullshit back in power? What we need is some transparent code evolution. On Mon, Feb 10, 2014 at 01:28:42PM +0100, Pieter Wuille wrote: Hi all, I was a bit surprised to see MtGox's announcement. The malleability of transactions was known for years already (see for example the wiki article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it, or mails on this list from 2012 and 2013). I don't consider it a very big problem, but it does make it harder for infrastructure to interact with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to avoid it altogether to make life easier for everyone. But we can't just change all infrastructure that exists today. We're slowly working towards making malleability harder (and hopefully impossible someday), but this will take a long time. For example, 0.8 not supporting non-DER encoded signatures was a step in that direction (and ironically, the trigger that caused MtGox's initial problems here). In any case, this will take years, and nobody should wait for this. There seem to be two more direct problems here. * Wallets which deal badly with modified txids. * Services that use the transaction id to detect unconfirming transactions. The first is something that needs to be done correctly in software - it just needs to be aware of malleability. The second is something I was unaware of and would have advised against. If you plan on reissuing a transaction because on old version doesn't confirm, make sure to make it a double spend of the first one - so that not both can confirm. I certainly don't like press making this sound like a problem in the Bitcoin protocol or clients. I think this is an issue that needs to be
Re: [Bitcoin-development] MtGox blames bitcoin
On Mon, Feb 10, 2014 at 08:45:03AM -0800, Gregory Maxwell wrote: On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes ho...@hozed.org wrote: Name me one single person with commit access to the bitcoin github repository who is *independent* of any venture capital or other 'investment' connections. I am, unless you count the fact that I own some Bitcoin and some mining hardware as 'investment' connections (and that case your comments are worthless). (By not naming anyone else I don't mean to imply there are no others, but I don't want to speak for anyone else. Nor would I necessarily expect the other part(ies|y) to step forward, since this mostly appears to be an invitation to step up and be attacked.) Thank you. I also appreciate your commentary[1], and willingness to list your investment position. What I'm concerned about are people who have signed non-disclosure agreements or who's salary/equity/whatever depend on people who are experts at manipulating markets to take naive investors money. Independent is also a state of mind as much as it is about financial connections. What pisses me off here is that a huge amount of wealth just changed hands based on MtGox's press release, and it stinks of insider trading. I still maintain the best outcome would be for MtGox to AGPLv3 release their code, and then those of us that understand it would be able to have a public technical discussion about how to fix it, and MtGox would still maintain their intellectual property ownership position. This, however, cuts off a significant revenue stream for people who take money making market bets 5 minutes before the information goes public, so I expect the likelyhood of such an outbreak of sanity is quite low. [1] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/ DISCLAIMER: I have a significant emotional investment in copyleft/viral copyright development models, and I expect to take a lot of money charging people to write code I give away for free. I also occasionally make money from cryptocurrency mining, but only when I can sell it in functional and transparent markets. -- Androidtrade; apps run on BlackBerryreg;10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
You have plenty of good points, but they are not relevant to this mailing list. I suggest you take them elsewhere. -- Jameson Lopp Software Engineer Bronto Software, Inc On 02/10/2014 01:25 PM, Troy Benjegerdes wrote: On Mon, Feb 10, 2014 at 08:45:03AM -0800, Gregory Maxwell wrote: On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes ho...@hozed.org wrote: Name me one single person with commit access to the bitcoin github repository who is *independent* of any venture capital or other 'investment' connections. I am, unless you count the fact that I own some Bitcoin and some mining hardware as 'investment' connections (and that case your comments are worthless). (By not naming anyone else I don't mean to imply there are no others, but I don't want to speak for anyone else. Nor would I necessarily expect the other part(ies|y) to step forward, since this mostly appears to be an invitation to step up and be attacked.) Thank you. I also appreciate your commentary[1], and willingness to list your investment position. What I'm concerned about are people who have signed non-disclosure agreements or who's salary/equity/whatever depend on people who are experts at manipulating markets to take naive investors money. Independent is also a state of mind as much as it is about financial connections. What pisses me off here is that a huge amount of wealth just changed hands based on MtGox's press release, and it stinks of insider trading. I still maintain the best outcome would be for MtGox to AGPLv3 release their code, and then those of us that understand it would be able to have a public technical discussion about how to fix it, and MtGox would still maintain their intellectual property ownership position. This, however, cuts off a significant revenue stream for people who take money making market bets 5 minutes before the information goes public, so I expect the likelyhood of such an outbreak of sanity is quite low. [1] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/ DISCLAIMER: I have a significant emotional investment in copyleft/viral copyright development models, and I expect to take a lot of money charging people to write code I give away for free. I also occasionally make money from cryptocurrency mining, but only when I can sell it in functional and transparent markets. -- Androidtrade; apps run on BlackBerryreg;10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
RE: taking discussion elsewhere: Yes, please, the purpose of this mailing list is technical discussions to encourage interoperability of Bitcoin implementations, improve ease-of-use and security, etc. -- -- Gavin Andresen -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
If you've got any ideas for a better forum, let me know. MtGox is one of the largest public faces of the code being developed here. If the public perception is that this is a bitcoin protocol flaw, then we need some damned strong and compelling public arguments about why it ain't so. But after some thought, that's not the critical issue I want to raise on this list. If something about the implementation, the protocol, of bitcoin-qt or bitcoind makes it easy for an attacker to mutate transactions and hard for an 'end-user' such as MtGox to confirm payments, then we've got a fundamental user-interface flaw. We can get all indignant about RTFM or telling the users they are idiots, but that's not really going to be good for long-term adoption and use. My opinion is part of the development process should be to react to public perceptions of how the code is being used (and mis-used), and how the market is being manipulated, and try to improve it so the whole system is stable, predictable, and friendly to users. On Mon, Feb 10, 2014 at 01:45:58PM -0500, Jameson Lopp wrote: You have plenty of good points, but they are not relevant to this mailing list. I suggest you take them elsewhere. -- Jameson Lopp Software Engineer Bronto Software, Inc On 02/10/2014 01:25 PM, Troy Benjegerdes wrote: On Mon, Feb 10, 2014 at 08:45:03AM -0800, Gregory Maxwell wrote: On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes ho...@hozed.org wrote: Name me one single person with commit access to the bitcoin github repository who is *independent* of any venture capital or other 'investment' connections. I am, unless you count the fact that I own some Bitcoin and some mining hardware as 'investment' connections (and that case your comments are worthless). (By not naming anyone else I don't mean to imply there are no others, but I don't want to speak for anyone else. Nor would I necessarily expect the other part(ies|y) to step forward, since this mostly appears to be an invitation to step up and be attacked.) Thank you. I also appreciate your commentary[1], and willingness to list your investment position. What I'm concerned about are people who have signed non-disclosure agreements or who's salary/equity/whatever depend on people who are experts at manipulating markets to take naive investors money. Independent is also a state of mind as much as it is about financial connections. What pisses me off here is that a huge amount of wealth just changed hands based on MtGox's press release, and it stinks of insider trading. I still maintain the best outcome would be for MtGox to AGPLv3 release their code, and then those of us that understand it would be able to have a public technical discussion about how to fix it, and MtGox would still maintain their intellectual property ownership position. This, however, cuts off a significant revenue stream for people who take money making market bets 5 minutes before the information goes public, so I expect the likelyhood of such an outbreak of sanity is quite low. [1] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/ DISCLAIMER: I have a significant emotional investment in copyleft/viral copyright development models, and I expect to take a lot of money charging people to write code I give away for free. I also occasionally make money from cryptocurrency mining, but only when I can sell it in functional and transparent markets. -- Androidtrade; apps run on BlackBerryreg;10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth,
Re: [Bitcoin-development] MtGox blames bitcoin
On Mon, Feb 10, 2014 at 01:07:03PM -0600, Troy Benjegerdes wrote: If you've got any ideas for a better forum, let me know. Your political conversations would be welcome at unsys...@lists.dyne.org See you there. -- 'peter'[:-1]@petertodd.org 77ddbd0b6faa6d6fe50cdc7808dea5db5b538f85b736ede8515c54c7 signature.asc Description: Digital signature -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
Hi guys, Please check this thread https://bitcointalk.org/index.php?topic=458608.0for a possible attack scenario. Already mailed Gavin, Mike Hearn and Adam about this : See if it makes sense. On Tue, Feb 11, 2014 at 12:53 AM, Peter Todd p...@petertodd.org wrote: On Mon, Feb 10, 2014 at 01:07:03PM -0600, Troy Benjegerdes wrote: If you've got any ideas for a better forum, let me know. Your political conversations would be welcome at unsys...@lists.dyne.org See you there. -- 'peter'[:-1]@petertodd.org 77ddbd0b6faa6d6fe50cdc7808dea5db5b538f85b736ede8515c54c7 -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
On Sun, Feb 09, 2014 at 03:44:34PM -0500, Peter Todd wrote: On Sun, Feb 09, 2014 at 01:04:58PM -0500, Peter Todd wrote: Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE that allows colored coins and similar embedded consensus system assets to be securely transferred to another party in exchange for Bitcoins atomically. In summary his p2p 2-step-trade mechanism operates as follows: I'm told there's probably at least one if not more earlier attributions/reinventions for the 2-step-trade protocol using SIGHASH_SINGLE. Please reply with them if you have them so we can give credit where credit is due. Got this: Message-ID: 52418eba.3080...@monetize.io Date: Tue, 24 Sep 2013 06:08:10 -0700 From: Mark Friedenbach m...@monetize.io Organization: Monetize.io Inc. To: Meni Rosenfeld m...@bitcoil.co.il Subject: Re: Freimarkets and investment If assets were tagged you could do a very limited form of pre-signed offers: in: 10 btc SINGLE|ANYONECANPAY out: 1 AAA These are composable, in that you can append the inputs and outputs of multiple offers together and result in a valid transaction. However this is pretty much the limit of what is possible without adding new SIGHASH modes, and if you're going to hard-fork to add tagging, then you might as well go the whole distance with explicit hierarchical sub-transactions as we did with Freimarkets. Cheers, Mark On 9/24/13 5:44 AM, Meni Rosenfeld wrote: Hi Jorge, The video was sent to me by Amos Meiri, I think eToro funded its production. Maybe I don't understand SIGHASH_ANYONECANPAY very well. In the transaction, there will be an output of 1 my stock to an initially unknown address. Can I provide a signature for my input of 1 my stock that will be valid even with the output details provided later? In any case, I think that's out of scope for the presentation. Meni On 24/09/2013 13:10, Jorge Timón wrote: Yes, it's a nice presentation. I love the video with the chameleons that you link at the end !! As a little sugestion, I think the biggest advantage of tagging is not inflatable assets, it's open binding orders. Even without granular subtransactions as freimarket has, you could sign your input (say, representing 1 My stock) and only the output you're interested in (say 100 bitstampUSD to myAddress) with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. Without tagging, you need to know where the inputs come from to check they're really bitstampUSD, because the network won't enforce the 100 bistampUSD in your output, any uncolored coins filling the btc quantity you wanted to represent those 100 usd will be ok, for miners. Goog luck with the talk, I'm eager to hear it. By the way, Mark, the explanation of the blockchain image sounds a little bit like hashcasttle, no? well, just merged mining every new asset, sounds like jaromil's freecoin too. On 9/24/13, Meni Rosenfeld m...@bitcoil.co.il wrote: Hi Mark, We currently have a more general mathematical framework for the concept of colored coins - a color is a combination of initial state and a kernel function that maps input colors to output colors. Order-based coloring is one such kernel function, tagging is another. As long as you can point at an output and say what its color is, we call it a colored coin system. The blockchain image is a stand-in for using a new block chain for each asset. Meni On 24/09/2013 00:42, Mark Friedenbach wrote: Hi Meni, I did call Freimarkets colored coins in the early days, but the term colored coin itself within the community seems to have become identified with the specific proposal of assigning value to specific satoshis, and running an order based coloring algorithm to determine asset flow, e.g. Bitcoin-X. Freimarkets allows issuance of entirely new assets and has explicit tagging of outputs, so we decided to avoid the phrase colored coin so as to keep from confusing people. But as an academic, yes you are correct. You presentation looks great. BTW, what's the first logo for the Alternative token systems slide? Or is that just a stand-in for the block chain? Mark On 9/23/13 12:24 PM, Meni Rosenfeld wrote: Hi, As you might know I'm giving a talk about Colored Coins in Amsterdam. My presentation is available at https://bitcoil.co.il/files/Colored Coins.pptx (I'm not posting this link publicly until after the talk). I'll be happy for any feedback. I'm listing Freimarkets as an implementation of Colored Coins. It doesn't look like you're identifying with the term, but it does fit the definition (and though it does obviously do much more than just implement colored coins.) Thanks, Meni -- 'peter'[:-1]@petertodd.org 76654614e7bf72ac80d47c57bca12503989f4d602538d3cd7892ca7d signature.asc Description: Digital signature -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry
Re: [Bitcoin-development] MtGox blames bitcoin
On Tue, Feb 11, 2014 at 01:00:21AM +0530, naman naman wrote: Hi guys, Please check this thread https://bitcointalk.org/index.php?topic=458608.0for a possible attack scenario. Already mailed Gavin, Mike Hearn and Adam about this : See if it makes sense. That's basically what appears to have happened with Mt. Gox. Preventing the attack is as simple as training your customer service people to ask the customer if their wallet software shows a payment to a specific address of a specific amount at some approximate time. Making exact payment amounts unique - add a few satoshis - is a trivial if slightly ugly way of making sure payments can be identified uniquely over the phone. That the procedure at Mt. Gox let front-line customer service reps manually send funds to customers without a proper investigation of why the funds didn't arrive was a serious mistake on their part. Ultimately this is more of a social engineering attack than a technical one, and a good example of why well-thought-out payment protocols are helpful. Though the BIP70 payment protocol doesn't yet handle busines to individual, or individual to indivudal, payments a future iteration can and this kind of problem will be less of an issue. Similarly stealth addresses have an inherent per-tx unique identifier, the derived pubkey, which a UI might be able to take advantage of. -- 'peter'[:-1]@petertodd.org 76654614e7bf72ac80d47c57bca12503989f4d602538d3cd7892ca7d signature.asc Description: Digital signature -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Malleability and MtGox's announcement
Am 10.02.2014 13:28, schrieb Pieter Wuille: Hi all, I was a bit surprised to see MtGox's announcement. The malleability of transactions was known for years already (see for example the wiki article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it, or mails on this list from 2012 and 2013). I don't consider it a very big problem, but it does make it harder for infrastructure to interact with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to avoid it altogether to make life easier for everyone. Sorry, I'm not a developer, but I have got a question. It's a little bit off-topic and can't maybe answered easy. As I understand this attack someone renames the transaction ID before being confirmed in the blockchain. Not easy but if he is fast enough it should be possible. With a bit of luck for the attacker the new transaction is added to the block chain and the original transaction is discarded as double-spend. Right? Up to this point the attacker has nothing gained. But next the attacker stressed the Gox support and refers to the original transaction ID. Gox was then probably fooled in such cases and has refunded already paid Bitcoins to the attackers (virtual) Gox-wallet. So far everything is clear. But what I do not understand: Why apparently had so many customers of Gox payment defaults or severely delayed payments? I would imagine that the attacker may have doubled not only his own transaction (maybe for obfuscating the fraud). But then all transfers would still have go through anyway. And a normal customers would have been satisfied. Most people observe only their wallets, I think. What am I missing here? Sorry, is perhaps a silly question. But maybe you can put me on the right track. regards Oliver -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Malleability and MtGox's announcement
On Mon, Feb 10, 2014 at 11:47 AM, Oliver Egginger bitc...@olivere.de wrote: As I understand this attack someone renames the transaction ID before being confirmed in the blockchain. Not easy but if he is fast enough it should be possible. With a bit of luck for the attacker the new transaction is added to the block chain and the original transaction is discarded as double-spend. Right? Up to this point the attacker has nothing gained. But next the attacker stressed the Gox support and refers to the original transaction ID. Gox was then probably fooled in such cases and has refunded already paid Bitcoins to the attackers (virtual) Gox-wallet. At this point the attack should fail. Before crediting the funds back Gox should form a new transaction moving at least one of the coins the prior transaction was spending and wait for that transaction to confirm. Without performing this step— even if there were no malleability at all you'd have the risk that someone would go resurrect the old transaction and get a miner to mine it. Then it goes through. With performing it, even if they missed the mutated transaction in the chain their cancellation transaction could not confirm (because its a double spend). So far everything is clear. But what I do not understand: Why apparently had so many customers of Gox payment defaults or severely delayed payments? Back in September a lot of people were having stuck transactions and when I looked it was because Mtgox was spending immature coins: newly generated coins which cannot be spent for 100 blocks since their creation. (A rule since Bitcoin's started) Then later it was noticed that they were producing transactions with invalid DER encodings (excessively padded signatures). The Bitcoin network used to accept these transactions, but in order to more towards eliminating malleability Bitcoin 0.8 and later will not relay and mine them. Then after people started using mutation to fix those excessively padded transactions and/or someone was exploiting Gox's behavior— it seems that Gox's wallet may have been in a state where it thought a lot of coins weren't spent that were and was reusing them in new transansactions... this one is harder to tell externally— I saw it appeared to be producing a LOT of double spends with different destinations, but I'm guessing as to the exact cause. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Malleability and MtGox's announcement
On Mon, Feb 10, 2014 at 7:47 PM, Oliver Egginger bitc...@olivere.de wrote: As I understand this attack someone renames the transaction ID before being confirmed in the blockchain. Not easy but if he is fast enough it should be possible. With a bit of luck for the attacker the new transaction is added to the block chain and the original transaction is discarded as double-spend. Right? No, the problem was that the transaction MtGox produced was poorly formatted. It wouldn't cause a block containing the transaction to be rejected, but the default client wouldn't relay the transaction or add it into a block. This means that transaction stalls. If the attacker has a direct connection to MtGox, they can receive the transaction directly. The attacker would fix the formatting (which changes the transaction id, but doesn't change the signature) and then forward it to the network, as normal. The old transaction never propagates correctly. Up to this point the attacker has nothing gained. But next the attacker stressed the Gox support and refers to the original transaction ID. Gox was then probably fooled in such cases and has refunded already paid Bitcoins to the attackers (virtual) Gox-wallet. They sent out the transaction a second time. The right solution is that the new transaction should re-spend at least one of the coins that the first transaction spent. That way only one can possibly be accepted. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Malleability and MtGox's announcement
On Mon, Feb 10, 2014 at 12:47 PM, Tier Nolan tier.no...@gmail.com wrote: If the attacker has a direct connection to MtGox, they can receive the transaction directly. MtGox had a php script that returned base64 data for all their stalled transactions. Not just attackers used that, some people trying to unstick their transactions tried manually fixing them with honest intent and no idea it would potentially confuse mtgox's software. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Framework for modular input selection policy for Bitcoin wallets
One of the areas that isn't as well developed as it could be in terms of wallet design is fine-grained control over input selection policy. Coin control is great when a human is manually crafting transactions, but that's not really a very scalable solution. The attached image is a possible way to stack different independent selection algorithms. If wallets implemented something like this, it would be easy for other programs to implement new application-specific algorithms that would not need to completely reinvent the wheel. As an example, voting pools in Open-Transactions will implement cold storage in a FIFO manner, meaning that UTXOs will be clustered into groups which should be consumed in a specific sequence. Within that constraint, however, they still want to minimize transaction size. If wallets were designed to make selection policy modular, they'd only need to implement their FIFO algorithm and stack it in before the default algorithm. Surely this capability would be useful to other projects as well. It would also allow people who want to prioritize privacy over transaction cost to easily modify the behavior of their clients and would make it easier to incorporate new tx construction algorithms like CoinJoin. Link to the image in case attachment is stripped: http://i.imgur.com/Fkkq7pI.png -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k 0x1B438BF4.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
