rich1.0npub1xvnnyhz8e4eklaakjc9xgm5w8pzkuckt923uacz2cftqdqx23g7q3c5rqghttps://nostr.ae/npub1xvnnyhz8e4eklaakjc9xgm5w8pzkuckt923uacz2cftqdqx23g7q3c5rqgnjumphttps://nostr.ae📅 Original date posted:2014-02-19 📝 Original message: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 <natanael.l at 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-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 at gmail.com>: > > On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <gronager at 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 at 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 at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140219/42627c75/attachment.html>