From: Natanael <natanael.l@gmail•com>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
Date: Thu, 20 Feb 2014 01:22:15 +0100 [thread overview]
Message-ID: <CAAt2M1-YC8Bv=11AuT=0ATpX60R=g-PhhK+mBK=VHfEO3xLvxQ@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBg9=XK=PGSW8DcU1LR85oeTDmpS4U-vYUXbraZQpU+edg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3356 bytes --]
Regarding chains of transactions intended to be published at once together,
wouldn't it be easier to add a "only-mine-with-child flag"?
That way the parent transactions aren't actually valid unless spent
together with the transaction that depends on it, and only the original
will have a child referencing it.
Then malleability is not an issue at all for transaction chains if you only
need to broadcast your full transaction chain once, and don't need to
extend it in two or more occasions, *after* broadcasting subchains to the
network, from the same set of pregenerated transactions.
If you need to broadcast pregenerated subchains separately, then you need
the last child in the chain to be non-malleable.
This would require all miners to start to respect it at once in order to
avoid forking the network.
- Sent from my phone
Den 19 feb 2014 22:13 skrev "Pieter Wuille" <pieter.wuille@gmail•com>:
> On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <gronager@mac•com>
> wrote:
> > I think that we could guarantee fewer incidents by making version 1
> transactions unmalleable and then optionally introduce a version 3 that
> supported the malleability feature. That way most existing problematic
> implementations would be fixed and no doors were closed for people
> experimenting with other stuff - tx v 3 would probably then be called
> experimental transactions.
>
> Just to be clear: this change is not directly intended to avoid
> "incidents". It will take way too long to deploy this. Software should
> deal with malleability. This is a longer-term solution intended to
> provide non-malleability guarantees for clients that a) are upgraded
> to use them b) willing to restrict their functionality. As there are
> several intended use cases for malleable transactions (the sighash
> flags pretty directly are a way to signify what malleabilities are
> *wanted*), this is not about outlawing malleability.
>
> While we could right now make all these rules non-standard, and
> schedule a soft fork in a year or so to make them illegal, it would
> mean removing potential functionality that can only be re-enabled
> through a hard fork. This is significantly harder, so we should think
> about it very well in advance.
>
> About new transaction and block versions: this allows implementing and
> automatically scheduling a softfork without waiting for wallets to
> upgrade. The non-DER signature change was discussed for over two
> years, and implemented almost a year ago, and we still notice wallets
> that don't support it. We can't expect every wallet to be instantly
> modified (what about hardware wallets like the Trezor, for example?
> they may not just be able to be upgraded). Nor is it necessary: if
> your software only spends confirmed change, and tracks all debits
> correctly, there is no need.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 4165 bytes --]
next prev parent reply other threads:[~2014-02-20 0:22 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-09 23:33 Pieter Wuille
2014-02-10 3:00 ` Peter Todd
2014-02-12 15:12 ` Rune Kjær Svendsen
2014-02-12 16:22 ` Alan Reiner
2014-02-12 16:38 ` Allen Piscitello
2014-02-12 16:44 ` Alan Reiner
2014-02-12 20:27 ` Mark Friedenbach
2014-02-12 22:52 ` Luke-Jr
2014-02-13 0:39 ` Alex Morcos
2014-02-13 0:47 ` Gregory Maxwell
2014-02-19 14:11 ` Michael Gronager
2014-02-19 14:38 ` Pieter Wuille
2014-02-19 20:28 ` Michael Gronager
2014-02-19 20:39 ` Gregory Maxwell
2014-02-19 20:49 ` Peter Todd
2014-02-19 21:05 ` Gregory Maxwell
2014-02-19 21:11 ` Pieter Wuille
2014-02-20 0:22 ` Natanael [this message]
2014-02-20 1:29 ` Allen Piscitello
2014-02-20 7:50 ` Natanael
2014-02-20 10:59 ` Michael Gronager
2014-02-20 14:08 ` Mike Hearn
2014-02-20 14:15 ` Gregory Maxwell
2014-02-20 14:29 ` Gavin Andresen
2014-02-20 14:36 ` Gregory Maxwell
2014-02-20 14:58 ` Gavin Andresen
2014-02-20 15:11 ` Pieter Wuille
2014-02-20 15:24 ` Gregory Maxwell
2014-02-21 6:07 ` Mike Hearn
2014-02-21 6:30 ` Gregory Maxwell
2014-02-19 19:15 ` Jeremy Spilman
2014-02-12 17:13 ` Jeff Garzik
2014-02-12 17:21 ` Pieter Wuille
2014-02-12 18:03 ` Gregory Maxwell
[not found] ` <CALf2ePyQeOxL3d+QoaWSYy_cCKaF9qq1StBwXFms9NyedUg3eg@mail.gmail.com>
2014-02-12 18:21 ` Alan Reiner
2014-02-10 4:39 ` Luke-Jr
2014-02-12 16:56 ` Pavol Rusnak
2014-02-12 17:22 ` Pieter Wuille
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='CAAt2M1-YC8Bv=11AuT=0ATpX60R=g-PhhK+mBK=VHfEO3xLvxQ@mail.gmail.com' \
--to=natanael.l@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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