Oh, no, sorry, it also covers bip62. On Fri, Apr 24, 2015 at 10:55 AM, Jorge Timón <jti...@jtimon.cc> wrote: > s7r you may be interested in this video explaining several aspects of > malleability: https://www.youtube.com/watch?v=jyDE-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 <s...@sky-ip.org> 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 can >>>> 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 transaction >>>> (tx1) and broadcast it, you can alter its txid at your will, without any >>>> 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 systems >>>> 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 course. >>> >>> After BIP62, you will, as a sender, optionally be able to protect others >>> 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 exercises >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development