public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pieter Wuille <pieter.wuille@gmail.com>
To: s7r@sky-ip.org
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Date: Fri, 17 Apr 2015 02:02:19 -0700	[thread overview]
Message-ID: <CAPg+sBi3QgJK7-PuV-1vbur0AMUeXddUdv_-Mcjwgbefqj3rFg@mail.gmail.com> (raw)
In-Reply-To: <55304321.3030300@sky-ip.org>

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

> 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

[-- Attachment #2: Type: text/html, Size: 1639 bytes --]

  reply	other threads:[~2015-04-17  9:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-15 23:43 [Bitcoin-development] 75%/95% threshold for transaction versions s7r
2015-04-16  2:04 ` Allen Piscitello
2015-04-16  5:22 ` Pieter Wuille
2015-04-16 16:12   ` s7r
2015-04-16 17:34     ` Mark Friedenbach
2015-04-16 23:17       ` s7r
2015-04-17  9:02         ` Pieter Wuille [this message]
2015-04-18 14:49           ` s7r
2015-04-24  8:55             ` Jorge Timón
2015-04-24  8:58               ` Jorge Timón
2015-04-24 19:58     ` William Swanson
2015-04-24 20:16       ` Gregory Maxwell
2015-04-25 15:40         ` Stephen Morse
2015-04-26  0:01           ` s7r
2015-04-26  6:51             ` Joseph Poon
2015-04-26 16:48               ` Joseph Poon
2015-04-25 14:32       ` Stephen Morse
2015-04-27 19:21         ` Peter Todd
2015-04-28 10:17           ` Oleg Andreev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPg+sBi3QgJK7-PuV-1vbur0AMUeXddUdv_-Mcjwgbefqj3rFg@mail.gmail.com \
    --to=pieter.wuille@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=s7r@sky-ip.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox