<p dir="ltr"><br>
Den 22 feb 2015 13:36 skrev "Peter Todd" <<a href="mailto:pete@petertodd.org">pete@petertodd.org</a>>:<br>
> Implementing it as a general purpose scripting language improvement has<br>
> a lot of advantages, not least of which is that you no longer need to<br>
> rely entirely on inherently unreliable P2P networking: Promise to never<br>
> create two signatures for a specific BIP32 root pubkey and make<br>
> violating that promise destroy and/or reallocate a fidelity bond whose<br>
> value is locked until some time into the future. Since the fidelity bond<br>
> is a separate pool of funds, detection of the double-spend can happen<br>
> later.</p>
<p dir="ltr">Somebody sent me a zero-confirmation transaction, or one that got orphaned after one block. I created a transaction spending that UTXO, and another. </p>
<p dir="ltr">So at that point I have UTXO_orphaned based on the sender's UTXO_origin and my UTXO_old (because I've had it unspent for a long time), both in one transaction, creating UTXO_new. </p>
<p dir="ltr">Now he doublespend UTXO_origin to create a UTXO_doublespend (which conflicts with UTXO_orphaned). He conspires with a miner to get it into a block. </p>
<p dir="ltr">Now what? Can my UTXO_old effectively be tainted forever because UTXO_new got invalidated together with UTXO_orphaned? Will that transaction be a valid proof of doublespend against a new UTXO_replacement I created? </p>
<p dir="ltr">Or otherwise, if only transactions where all UTXO's are currently valid works as doublespend proofs, aren't you still just left without protection against any one miner that conspires with doublespend attempting thieves? </p>
<p dir="ltr">In other words, you are unprotected and potentially at greater risk if you create a transaction depending on another zero-confirmation transaction. </p>