From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YlZRJ-0006pK-24 for bitcoin-development@lists.sourceforge.net; Fri, 24 Apr 2015 08:58:25 +0000 Received: from mail-wi0-f175.google.com ([209.85.212.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YlZRC-0006NG-7O for bitcoin-development@lists.sourceforge.net; Fri, 24 Apr 2015 08:58:25 +0000 Received: by wiax7 with SMTP id x7so30172422wia.0 for ; Fri, 24 Apr 2015 01:58:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5WjJKVujI2sErrjH2lB4OvXeW0thZ0+CiwVShnpotSA=; b=hUCni+tNR02FLstV9gfN1cGO7G4he+Pvtta7h4T0bapE+7ih9Tyc/hyfI+BtNkL3C8 IigseWOoT1S8O+oT06/v5z0FKSxFyko5I3w2yrZl4xtnnVfPXWeZ6YkAh2S0lEYkK5Ir TQTcPsAo5xdWQFXM9GtJFyeBhiv7vuxpIpVRpqHinEr69RMvB6ze+rjRoIGgmtaoJRyg NH8hfij9CH/ZH1wIyw5YDxQmFTLbmcGM6Wg8Fgq6LsHbPFvxsiMAvN4JwZKazcxyAkYb xXswQv01VdqM3qqPNZKr1sPy/T2hXrTr81+4SDzjI+Ol6ttd7eI1aObScGyv5Z364AN+ GKXw== X-Gm-Message-State: ALoCoQkObqeZWHmX7unYVUwsCPjdEfiNxswN7HdojT6ls0qGQoeeQujO2W13W0zVdPUqItGCSqua MIME-Version: 1.0 X-Received: by 10.180.105.193 with SMTP id go1mr1834089wib.92.1429865892005; Fri, 24 Apr 2015 01:58:12 -0700 (PDT) Received: by 10.194.124.2 with HTTP; Fri, 24 Apr 2015 01:58:11 -0700 (PDT) In-Reply-To: References: <552EF785.7000207@sky-ip.org> <552FDF73.6010104@sky-ip.org> <55304321.3030300@sky-ip.org> <55326F11.1010605@sky-ip.org> Date: Fri, 24 Apr 2015 10:58:11 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: s7r@sky-ip.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1YlZRC-0006NG-7O Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 08:58:25 -0000 Oh, no, sorry, it also covers bip62. On Fri, Apr 24, 2015 at 10:55 AM, Jorge Tim=C3=B3n wrote= : > s7r you may be interested in this video explaining several aspects of > malleability: https://www.youtube.com/watch?v=3DjyDE-aFqJTs > It is pre BIP62, but I believe it is very relevant and will hopefully > clear some of your doubts. > The signer of TX1 will always be able to change the signature and thus > the tx ID. > > On Sat, Apr 18, 2015 at 4:49 PM, s7r wrote: >> Understood. That is unfortunate, but not the end of the world. If you >> could please give feedback also to these last comments / questions: >> >> How far are we at this moment from BIP62? Can an user send a >> non-malleable tx now, if enforces some additional rules? >> >> As for the security of the system, it does not fully rely on txids being >> non malleable, but see this quote from my previous email: >> >> [QUOTE] >> I am trying to build a bitcoin contract which will relay on 3 things: >> - coinjoin / txes with inputs from multiple users which are signed by >> all users after they are merged together (every user is sure his coins >> will not be spent without the other users to spend anything, as per >> agreed contract); >> - pre-signed txes with nLockTime 'n' weeks. These txes will be signed >> before the inputs being spent are broadcasted/confirmed, using the txid >> provided by the user before broadcasting it. Malleability hurts here. >> - P2SH >> >> Another thing I would like to confirm, the 3 pieces of the bitcoin >> protocol mentioned above will be supported in _any_ future transaction >> version or block version, regardless what changes are made or features >> added to bitcoin core? The contract needs to be built and left unchanged >> for a very very long period of time... >> [/END QUOTE] >> >> Can you comment on the quote please? >> >> So, basically transaction malleability could affect the system in the >> way that a pre-signed tx which offers the insurance and which is sent to >> the user before the user sends the coins (spending user's coins back to >> him after a certain period of time) could be invalidated. The insurance >> tx signature will still be good, but invalid overall since the input >> (txid) being spent does not exist (was altered / modified). The coins >> won't be stolen or lost, but a new tx needs to be signed with the >> altered (new) txid, for the system to work. >> >> So, an user creates a transaction TX1 sending the coins to the server >> but does not broadcast it. Instead, he provides the txid of TX1 to the >> server. Server generates another transaction TX2 which spends TX1 back >> to the user, with an nLockTime. User checks and if everything ok >> broadcasts TX1. In case the txid of TX1 will be altered/modified, TX2 >> will become invalid (since it will be spending an inexistent input), and >> the server will need to re-create and sign TX2 with the new >> (altered/modified) txid of TX1, as per agreed contract. Should the >> server disappear after user broadcasts TX1 and before the >> altered/modified txid of TX1 gets confirmed, user's coins are forever >> locked. It is true that no third party can benefit from this type of >> attack, only the user will result with coins locked, but it is something >> which could be used by competition to make a service useless / annoying >> / too complicated or less safe to use. >> >> How could I mitigate this? >> >> Thanks you for your time and help. >> >> On 4/17/2015 12:02 PM, Pieter Wuille wrote: >>>> Anyone can alter the txid - more details needed. The number of altered >>>> txids in practice is not so high in order to make us believe anyone ca= n >>>> do it easily. It is obvious that all current bitcoin transactions are >>>> malleable, but not by anyone and not that easy. At least I like to >>> think so. >>> >>> Don't assume that because it does not (frequently) happen, that it >>> cannot happen. Large amounts of malleated transactions have happened in >>> the past. Especially if you build a system depends on non-malleability >>> for its security, you may at some point have an attacker who has >>> financial gain from malleation. >>> >>>> >From your answer I understand that right now if I create a transactio= n >>>> (tx1) and broadcast it, you can alter its txid at your will, without a= ny >>>> mining power and/or access to my private keys so I would end up not >>>> recognizing my own transaction and probably my change too (if my syste= ms >>>> rely hardly on txid)? >>> >>> In theory, yes, anyone can alter the txid without invalidating it, >>> without mining power and without access to the sender's private keys. >>> >>> All it requires is seeing a transaction on the network, doing a trivial >>> modification to it, and rebroadcasting it quickly. If the modifies >>> version gets mined, you're out of luck. Having mining power helps of co= urse. >>> >>> After BIP62, you will, as a sender, optionally be able to protect other= s >>> from malleating. You're always able to re-sign yourself. >>> >>> -- >>> Pieter >>> >> >> ------------------------------------------------------------------------= ------ >> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >> Develop your own process in accordance with the BPMN 2 standard >> Learn Process modeling best practices with Bonita BPM through live exerc= ises >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?u= tm_ >> source=3DSourceforge_BPM_Camp_5_6_15&utm_medium=3Demail&utm_campaign=3DV= A_SF >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development