diff options
| author | Gregory Maxwell <gmaxwell@gmail.com> | 2014-02-10 04:25:34 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-02-10 12:25:42 +0000 |
| commit | 5d236dd989ae3289c32240675a94aa66c826bf7e (patch) | |
| tree | 0dab082e09d8d33697c144f8c10ba62c20e6481f | |
| parent | fa3818c8c2257a8cdf6422144aa75e6ec6d777ee (diff) | |
| download | pi-bitcoindev-5d236dd989ae3289c32240675a94aa66c826bf7e.tar.gz pi-bitcoindev-5d236dd989ae3289c32240675a94aa66c826bf7e.zip | |
Re: [Bitcoin-development] MtGox blames bitcoin
| -rw-r--r-- | 48/ec2357eb7ff14bcf9e6b200ed6b3cebbc9f107 | 125 |
1 files changed, 125 insertions, 0 deletions
diff --git a/48/ec2357eb7ff14bcf9e6b200ed6b3cebbc9f107 b/48/ec2357eb7ff14bcf9e6b200ed6b3cebbc9f107 new file mode 100644 index 000000000..d8bc812b5 --- /dev/null +++ b/48/ec2357eb7ff14bcf9e6b200ed6b3cebbc9f107 @@ -0,0 +1,125 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <gmaxwell@gmail.com>) id 1WCpvi-0002ug-P9 + for bitcoin-development@lists.sourceforge.net; + Mon, 10 Feb 2014 12:25:42 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.215.50 as permitted sender) + client-ip=209.85.215.50; envelope-from=gmaxwell@gmail.com; + helo=mail-la0-f50.google.com; +Received: from mail-la0-f50.google.com ([209.85.215.50]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1WCpvh-0007s0-MC + for bitcoin-development@lists.sourceforge.net; + Mon, 10 Feb 2014 12:25:42 +0000 +Received: by mail-la0-f50.google.com with SMTP id ec20so4621429lab.23 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 10 Feb 2014 04:25:35 -0800 (PST) +MIME-Version: 1.0 +X-Received: by 10.152.229.225 with SMTP id st1mr22014393lac.2.1392035135087; + Mon, 10 Feb 2014 04:25:35 -0800 (PST) +Received: by 10.112.198.34 with HTTP; Mon, 10 Feb 2014 04:25:34 -0800 (PST) +In-Reply-To: <CANAnSg1LgpHGf-vTV0to1Z7sogf1ic6WTbogEsrQy1wh4C5zfw@mail.gmail.com> +References: <CANAnSg1LgpHGf-vTV0to1Z7sogf1ic6WTbogEsrQy1wh4C5zfw@mail.gmail.com> +Date: Mon, 10 Feb 2014 04:25:34 -0800 +Message-ID: <CAAS2fgTx8UzQiocyNMfMNkt2uUZRTmhagb2BY9TPuAupVjVa2g@mail.gmail.com> +From: Gregory Maxwell <gmaxwell@gmail.com> +To: Drak <drak@zikula.org> +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Score: -1.6 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (gmaxwell[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1WCpvh-0007s0-MC +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] MtGox blames bitcoin +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Mon, 10 Feb 2014 12:25:42 -0000 + +On Mon, Feb 10, 2014 at 3:28 AM, Drak <drak@zikula.org> wrote: +> What is the official response from the Bitcoin Core developers about MtGo= +x's +> assertion that their problems are due to a fault of bitcoin, as opposed t= +o a +> fault of their own? +> +> The technical analysis preluding this mess, was that MtGox was at fault f= +or +> their faulty wallet implementation. + +In the real world fault seldom falls in a single place. Bitcoin is at +fault=E2=80=94 in many places=E2=80=94 for making it harder for implementer= +s 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=E2=80=94 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=E2=80=94 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=E2=80=94 rather=E2=80=94 input tracking appears to be both ne= +cessary and +sufficient in all cancellation cases. + +This helps explain why Bitcoin-QT=E2=80=94 whos mutation handling kinda +stinks=E2=80=94 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=E2=80=94 look at the list archives... though it won't happen +fast since all signers/wallets will need to be updated. + + |