public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <greg@xiph.org>
To: Rusty Russell <rusty@rustcorp.com.au>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: Russell O'Connor <roconnor@blockstream.com>,
	Kalle Alm <kalle.alm@gmail.com>
Subject: Re: [bitcoin-dev] BIP 117 Feedback
Date: Tue, 16 Jan 2018 03:27:26 +0000	[thread overview]
Message-ID: <CAAS2fgTPjAeSK_EeVabtsnBFZe6OEG=2wb+FKeAzaXYWsCHVxw@mail.gmail.com> (raw)
In-Reply-To: <87zi5ehat5.fsf@rustcorp.com.au>

On Tue, Jan 16, 2018 at 1:06 AM, Rusty Russell via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> The rule AFAICT is "standard transactions must still work".  This was
> violated with low-S, but the transformation was arguably trivial.

That is my view, generally.  Like any other principle, its
applicability is modulated by the specific facts.

For low-s the most critical mitigating specific facts were (in order
of importance):  Any third party could malleate non-conforming
transactions to make them conform and that code to do this was written
and run,  that S-value malleation was being actively attacked at the
time, and that the intention to eventually enforce lowS had been made
clear a long time ahead and the vast majority of transactions were
already conforming.

In particular these facts meant that the change could not result in
the confiscation of funds except in the case of a key-destroyed
unconfirmed chain of timelock transactions which was already highly
vulnerable due to the malleation attacks -- and even there, the
non-standardness step itself wouldn't destroy the funds esp. given the
malleation risk redemption of that sort of chain would probably be
best accomplished with the collaboration of a miner.


  reply	other threads:[~2018-01-16  3:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 11:22 [bitcoin-dev] BIP 117 Feedback Rusty Russell
2018-01-09 12:40 ` Mark Friedenbach
2018-01-09 14:21   ` Pieter Wuille
2018-01-09 22:57     ` Mark Friedenbach
2018-01-12 10:48     ` Russell O'Connor
2018-01-16  1:06       ` Rusty Russell
2018-01-16  3:27         ` Gregory Maxwell [this message]
2018-01-16  4:15         ` Luke Dashjr
2018-01-16  8:39           ` Russell O'Connor
2018-03-05 15:28 ` Johnson Lau

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='CAAS2fgTPjAeSK_EeVabtsnBFZe6OEG=2wb+FKeAzaXYWsCHVxw@mail.gmail.com' \
    --to=greg@xiph.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=kalle.alm@gmail.com \
    --cc=roconnor@blockstream.com \
    --cc=rusty@rustcorp.com.au \
    /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