public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace.org>
To: Luke Dashjr <luke@dashjr.org>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Date: Thu, 5 Nov 2015 23:29:46 +0100	[thread overview]
Message-ID: <CALqxMTGA-SHOgmNDfwTSFS5kwh8wCwJwmGKDNWg3F191SWBBTw@mail.gmail.com> (raw)
In-Reply-To: <201511051936.09500.luke@dashjr.org>

About the conflicting spends by the private key holder (self signature
malleability) that is in principle kind of fixable.

You make a new pub key type which is r,Q (where r is the DSA signature
component but chosen at key gen time, Q=xG is the pub key, r is point
compressed R = (r,f(r)) = kG ), r is the pre-computable part of an
ECDSA signature (unrelated to the message which can be decided later).

You make a new address type which is a = H(r,Q).

Then you make a new signature type which requires that the r from
sig=(r,s) matches the r committed to in the address.

As the ECDSA signature is s=(H(m)+r*x)/k mod n, if they sign two
different messages with the same r value they reveal the private key
via simultaneous equation, as s=(H(m)+r*x)/k and s'=(H(m')+r*x)/k and
solving k=(H(m)-H(m'))/(s-s') and x=(sk-H(m))/r allowing anyone who
sees both double spends to spend as they can replace the signature
with their own one.  That converts double signatures into miner can
spend.

It doesnt necessarily enforce no pubkey reuse (Q), as a=H(r,Q) and
a'=H(r',Q) are different addresses, though it does enforce no
extended-address reuse (H=(r,Q)).
Binary failure address reuse could be an issue.  Puts pressure on
transactional storage on wallets.

Adam

On 5 November 2015 at 20:36, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thursday, November 05, 2015 3:27:37 PM Jorge Timón wrote:
>> On Tue, Nov 3, 2015 at 11:01 PM, Luke Dashjr via bitcoin-dev
>>
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote:
>> >> So this is indeed a form of desired malleability we will likely not be
>> >> able to fix. I'd argue that this goes more into the direction of
>> >> double-spending than a form of malleability, and is mostly out of scope
>> >> for this BIP. As the abstract mentions this BIP attempts to eliminate
>> >> damage incurred by malleability in the third party modification
>> >> scenario and in the multisig scenario, with the added benefit of
>> >> enabling transaction templating. If we can get the segregated witnesses
>> >> approach working all the better, we don't even have the penalty of
>> >> increased UTXO size. The problem of singlesig users doublespending
>> >> their outputs to update transactions remains a problem even then.
>> >
>> > I don't know what you're trying to say here. Double spending to the same
>> > destination(s) and malleability are literally the same thing. Things
>> > affected by malleability are still just as broken even with this BIP -
>> > whether it is triggered by a third-party or not is not very relevant.
>>
>> I think this is just a terminology confusion.
>> There's conflicting spends of the same outputs (aka unconfirmed
>> double-spends), and there's signature malleability which Segregated
>> Witnesses solves.
>> If we want to define malleability as signature malleability +
>> conflicting spends, then that's fine.
>> But it seems Christian is mostly interested in signature malleability,
>> which is what SW can solve.
>> In fact, creating conflicting spends is sometimes useful for some
>> contracts (ie to cancel the contract when that's supposed to be
>> allowed).
>> Maybe it is "incorrect" that people use "malleability" when they're
>> specifically talking about "signature malleability", but I think that
>> in this case it's clear that we're talking about transactions having
>> an id that cannot be changed just by signing with a different nonce
>> (what SW provides).
>
> Ok, then my point is that "signature malleability" is not particularly
> problematic or interesting alone, and the only way to get a practically-useful
> solution, is to address all kinds of malleability.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


  parent reply	other threads:[~2015-11-05 22:29 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-19 14:01 [bitcoin-dev] [BIP] Normalized transaction IDs Christian Decker
2015-10-19 15:23 ` Tier Nolan
2015-10-19 19:28   ` Christian Decker
2015-10-19 22:22   ` s7r
2015-10-20 10:30     ` Christian Decker
2015-10-21  6:18 ` Luke Dashjr
2015-10-21  7:39   ` Christian Decker
2015-10-21  7:52     ` Luke Dashjr
2015-10-21  8:31       ` Christian Decker
2015-10-21  8:39         ` Luke Dashjr
2015-10-21  8:44           ` Christian Decker
2015-10-21  8:46             ` Luke Dashjr
2015-10-21 18:22               ` Danny Thorpe
2015-10-21 19:27                 ` Gregory Maxwell
2015-10-21 23:20                 ` Luke Dashjr
2015-10-22  8:26                   ` Christian Decker
2015-10-22  8:57                     ` Gregory Maxwell
2015-10-22 11:54                       ` Christian Decker
2015-10-22  9:05                     ` Luke Dashjr
2015-11-03 20:37                       ` Christian Decker
2015-11-03 20:48                         ` Luke Dashjr
2015-11-03 21:44                           ` Christian Decker
2015-11-03 22:01                             ` Luke Dashjr
2015-11-05 15:27                               ` Jorge Timón
2015-11-05 19:36                                 ` Luke Dashjr
2015-11-05 20:25                                   ` Jorge Timón
2015-11-05 22:46                                     ` s7r
2015-11-05 22:29                                   ` Adam Back [this message]
2015-11-06 14:52                                 ` Christian Decker
2015-11-04  4:00                             ` Peter Todd
2015-11-05  9:38                               ` Christian Decker
2015-10-21  7:48   ` Gregory Maxwell
2015-10-21  8:26     ` Gregory Maxwell
2015-10-21  8:49       ` Christian Decker
2015-10-21  8:50         ` Christian Decker
2015-10-21 10:14         ` Gregory Maxwell

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=CALqxMTGA-SHOgmNDfwTSFS5kwh8wCwJwmGKDNWg3F191SWBBTw@mail.gmail.com \
    --to=adam@cypherspace.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luke@dashjr.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