public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Emin Gün Sirer" <el33th4x0r@gmail.com>
To: Peter Todd <pete@petertodd.org>
Cc: "Emin Gün Sirer via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] How to preserve the value of coins after a fork.
Date: Wed, 30 Dec 2015 15:22:43 -0500	[thread overview]
Message-ID: <CAPkFh0usGPFQ4Tpn4v9FNmAL=Z8vZYm-VU50aFDnTEWMrAr5eA@mail.gmail.com> (raw)
In-Reply-To: <6741032F-757F-4D9E-A722-3A62271B6BFD@petertodd.org>

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

On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd <pete@petertodd.org> wrote:

> Note how transaction malleability can quickly sabotage naive notions of
> this idea.
>

Bitcoin-United relies on a notion of transaction equivalence that doesn't
involve the transaction hash at all, so it should be immune to malleability
issues and compatible with segwit.

From the post, two transactions are equal if they "consume the same inputs
and result in the same outputs, not counting the miner fee. Simple
pay-to-pubkey-hash and pay-to-script-hash transactions are straightforward.
Multikey transactions are evaluated for equivalency by their inputs and
outputs, so it is allowable for a 2-out-of-3 payment to be signed by one
set of two keys on Dum and another set of two keys on Dee, as long as the
transaction consumes the same coins and produces the same outputs. Not that
we'll ever encounter such a case, but making this point helps pedagogically
with getting across the notion of transaction equivalence. What counts are
the consumed inputs and the destination and amounts of the outputs."

But you're right, if a naive implementation were to just use the
transaction hash, the result would be a mess.

- egs

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

  reply	other threads:[~2015-12-30 20:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-30 20:08 [bitcoin-dev] How to preserve the value of coins after a fork Emin Gün Sirer
2015-12-30 20:16 ` Peter Todd
2015-12-30 20:22   ` Emin Gün Sirer [this message]
2015-12-30 20:32     ` Peter Todd
2015-12-30 23:13       ` Nick ODell

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='CAPkFh0usGPFQ4Tpn4v9FNmAL=Z8vZYm-VU50aFDnTEWMrAr5eA@mail.gmail.com' \
    --to=el33th4x0r@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pete@petertodd.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