{"type":"rich","version":"1.0","author_name":"npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjt","author_url":"https://nostr.ae/npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjt","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-02-20\n📝 Original message:You could pregenerate entire \"trees\" of alternative outcomes where you pick\none branch / chain to broadcast based on the real world events as they\nhappen.\n\nBut I see another problem regarding use of oracles, if you have a P2SH\naddress with 2-of-3 signatures or similar in the chain, amd some\ntransactions following it, then the oracle needs to pregenerate both\ntransactions for both outcomes in advance. But the oracle probably don't\nwant to actually share it in advance to any third party before the event\nhappened.\n\nThis can be solved if the oracle only shares the transaction hash in\nadvance and then hands out a Zero-knowledge proof of that transaction with\nthe given hash is following the agreed upon rules, so you can trust the\ntransaction chain anyway and still being able to pregenerate a full tree of\ntransactions.\n\nAnd then the oracle will release one of the possible transactions after the\nevent in question has happened, so you can broadcast the chain of choice.\n\nThis unfortunately breaks down if the number of possible outcomes becomes\ntoo many as you would need to both generate and store a tree of possible\noutcomes that is massive.\n\n- Sent from my phone\nDen 20 feb 2014 02:29 skrev \"Allen Piscitello\" \u003callen.piscitello at gmail.com\u003e:\n\n\u003e This is somewhat problematic in my use case since some parts need to be in\n\u003e the chain earlier than others and have the same ID as expected.\n\u003e\n\u003e https://bitcointalk.org/index.php?topic=260898.10\n\u003e\n\u003e I haven't gone back to see if there are any ways around it, but the main\n\u003e problem here is I need the Contract TX to be in the chain much earlier than\n\u003e redeeming, but I need the refund transaction to be in the chain much\n\u003e earlier.  Perhaps there are some tricks to pull off to get it to work, but\n\u003e I haven't been working on this for a while so I'm a bit rusty in that area.\n\u003e\n\u003e This might be helpful enough to help a lot of use cases, but shouldn't be\n\u003e final.\n\u003e\n\u003e -Allen\n\u003e\n\u003e On Wed, Feb 19, 2014 at 6:22 PM, Natanael \u003cnatanael.l at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e Regarding chains of transactions intended to be published at once\n\u003e\u003e together, wouldn't it be easier to add a \"only-mine-with-child flag\"?\n\u003e\u003e\n\u003e\u003e That way the parent transactions aren't actually valid unless spent\n\u003e\u003e together with the transaction that depends on it, and only the original\n\u003e\u003e will have a child referencing it.\n\u003e\u003e\n\u003e\u003e Then malleability is not an issue at all for transaction chains if you\n\u003e\u003e only need to broadcast your full transaction chain once, and don't need to\n\u003e\u003e extend it in two or more occasions, *after* broadcasting subchains to the\n\u003e\u003e network, from the same set of pregenerated transactions.\n\u003e\u003e\n\u003e\u003e If you need to broadcast pregenerated subchains separately, then you need\n\u003e\u003e the last child in the chain to be non-malleable.\n\u003e\u003e\n\u003e\u003e This would require all miners to start to respect it at once in order to\n\u003e\u003e avoid forking the network.\n\u003e\u003e\n\u003e\u003e - Sent from my phone\n\u003e\u003e Den 19 feb 2014 22:13 skrev \"Pieter Wuille\" \u003cpieter.wuille at gmail.com\u003e:\n\u003e\u003e\n\u003e\u003e On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager \u003cgronager at mac.com\u003e\n\u003e\u003e\u003e wrote:\n\u003e\u003e\u003e \u003e I think that we could guarantee fewer incidents by making version 1\n\u003e\u003e\u003e transactions unmalleable and then optionally introduce a version 3 that\n\u003e\u003e\u003e supported the malleability feature. That way most existing problematic\n\u003e\u003e\u003e implementations would be fixed and no doors were closed for people\n\u003e\u003e\u003e experimenting with other stuff - tx v 3 would probably then be called\n\u003e\u003e\u003e experimental transactions.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Just to be clear: this change is not directly intended to avoid\n\u003e\u003e\u003e \"incidents\". It will take way too long to deploy this. Software should\n\u003e\u003e\u003e deal with malleability. This is a longer-term solution intended to\n\u003e\u003e\u003e provide non-malleability guarantees for clients that a) are upgraded\n\u003e\u003e\u003e to use them  b) willing to restrict their functionality. As there are\n\u003e\u003e\u003e several intended use cases for malleable transactions (the sighash\n\u003e\u003e\u003e flags pretty directly are a way to signify what malleabilities are\n\u003e\u003e\u003e *wanted*), this is not about outlawing malleability.\n\u003e\u003e\u003e\n\u003e\u003e\u003e While we could right now make all these rules non-standard, and\n\u003e\u003e\u003e schedule a soft fork in a year or so to make them illegal, it would\n\u003e\u003e\u003e mean removing potential functionality that can only be re-enabled\n\u003e\u003e\u003e through a hard fork. This is significantly harder, so we should think\n\u003e\u003e\u003e about it very well in advance.\n\u003e\u003e\u003e\n\u003e\u003e\u003e About new transaction and block versions: this allows implementing and\n\u003e\u003e\u003e automatically scheduling a softfork without waiting for wallets to\n\u003e\u003e\u003e upgrade. The non-DER signature change was discussed for over two\n\u003e\u003e\u003e years, and implemented almost a year ago, and we still notice wallets\n\u003e\u003e\u003e that don't support it. We can't expect every wallet to be instantly\n\u003e\u003e\u003e modified (what about hardware wallets like the Trezor, for example?\n\u003e\u003e\u003e they may not just be able to be upgraded). Nor is it necessary: if\n\u003e\u003e\u003e your software only spends confirmed change, and tracks all debits\n\u003e\u003e\u003e correctly, there is no need.\n\u003e\u003e\u003e\n\u003e\u003e\u003e --\n\u003e\u003e\u003e Pieter\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\u003e Managing the Performance of Cloud-Based Applications\n\u003e\u003e\u003e Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.\n\u003e\u003e\u003e Read the Whitepaper.\n\u003e\u003e\u003e\n\u003e\u003e\u003e http://pubads.g.doubleclick.net/gampad/clk?id=121054471\u0026iu=/4140/ostg.clktrk\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Managing the Performance of Cloud-Based Applications\n\u003e\u003e Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.\n\u003e\u003e Read the Whitepaper.\n\u003e\u003e\n\u003e\u003e http://pubads.g.doubleclick.net/gampad/clk?id=121054471\u0026iu=/4140/ostg.clktrk\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140220/00054c41/attachment.html\u003e"}