Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WGIRu-0004Vw-VJ for bitcoin-development@lists.sourceforge.net; Thu, 20 Feb 2014 01:29:14 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.177 as permitted sender) client-ip=209.85.212.177; envelope-from=allen.piscitello@gmail.com; helo=mail-wi0-f177.google.com; Received: from mail-wi0-f177.google.com ([209.85.212.177]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WGIRr-0001mZ-DK for bitcoin-development@lists.sourceforge.net; Thu, 20 Feb 2014 01:29:14 +0000 Received: by mail-wi0-f177.google.com with SMTP id e4so1273766wiv.10 for ; Wed, 19 Feb 2014 17:29:05 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.179.69 with SMTP id de5mr31451893wjc.4.1392859745240; Wed, 19 Feb 2014 17:29:05 -0800 (PST) Received: by 10.194.76.135 with HTTP; Wed, 19 Feb 2014 17:29:05 -0800 (PST) In-Reply-To: References: <52FBD948.906@monetize.io> <201402122252.31060.luke@dashjr.org> <601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com> Date: Wed, 19 Feb 2014 19:29:05 -0600 Message-ID: From: Allen Piscitello To: Natanael Content-Type: multipart/alternative; boundary=089e01493cae564ae204f2cc6ea1 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (allen.piscitello[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WGIRr-0001mZ-DK Cc: Bitcoin Development Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:29:15 -0000 --089e01493cae564ae204f2cc6ea1 Content-Type: text/plain; charset=ISO-8859-1 This is somewhat problematic in my use case since some parts need to be in the chain earlier than others and have the same ID as expected. https://bitcointalk.org/index.php?topic=260898.10 I haven't gone back to see if there are any ways around it, but the main problem here is I need the Contract TX to be in the chain much earlier than redeeming, but I need the refund transaction to be in the chain much earlier. Perhaps there are some tricks to pull off to get it to work, but I haven't been working on this for a while so I'm a bit rusty in that area. This might be helpful enough to help a lot of use cases, but shouldn't be final. -Allen On Wed, Feb 19, 2014 at 6:22 PM, Natanael wrote: > 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" : > > On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager >> 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 >> > > > ------------------------------------------------------------------------------ > 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 > > --089e01493cae564ae204f2cc6ea1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is somewhat problematic in= my use case since some parts need to be in the chain earlier than others a= nd have the same ID as expected.

=
https://bit= cointalk.org/index.php?topic=3D260898.10

I haven't gone back to see if th= ere are any ways around it, but the main problem here is I need the Contrac= t TX to be in the chain much earlier than redeeming, but I need the refund = transaction to be in the chain much earlier. =A0Perhaps there are some tric= ks to pull off to get it to work, but I haven't been working on this fo= r a while so I'm a bit rusty in that area.

This might = be helpful enough to help a lot of use cases, but shouldn't be final.

-Allen<= br>
On Wed, Feb 19, 2014 at 6:22 PM, Natanael <n= atanael.l@gmail.com> wrote:

Regarding chains of transactions intended to be published at= once together, wouldn't it be easier to add a "only-mine-with-chi= ld flag"?

That way the parent transactions aren't actually valid u= nless 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 cha= ins 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 sub= chains 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&= quot; <piet= er.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 tr= ansactions unmalleable and then optionally introduce a version 3 that suppo= rted the malleability feature. That way most existing problematic implement= ations would be fixed and no doors were closed for people experimenting wit= h other stuff - tx v 3 would probably then be called experimental transacti= ons.

Just to be clear: this change is not directly intended to avoid
"incidents". It will take way too long to deploy this. Software s= hould
deal with malleability. This is a longer-term solution intended to
provide non-malleability guarantees for clients that a) are upgraded
to use them =A0b) 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/gam= pad/clk?id=3D121054471&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

-----------------------------------------------------------------------= -------
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/gam= pad/clk?id=3D121054471&iu=3D/4140/ostg.clktrk
__________________= _____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e01493cae564ae204f2cc6ea1--