You don't need the IN_CONFLICT feature to do what I said in my previous email. The IN_CONFLICT feature is just an alert system to detect double spends. In your case, you know you are double spending. You will see both txs in the PENDING state (as opposed to IN_CONFLICT) until the new tx gets into a block. Then the new tx will be BUILDING, the old one will be DEAD.
On Fri, Jun 24, 2016 at 3:24 PM, Manfred Karrer <[email protected]> wrote: > Thanks Oscar! Unfortunately my fork was before IN_CONFLICT was introduced. > but will have a look how to get that in. > > Am Freitag, 24. Juni 2016 18:33:20 UTC+2 schrieb Oscar Guindzberg: >> >> How to do it: >> - Create a SendRequest with an incomplete tx with the same inputs and >> the destination output the original tx has (change output is not >> required). You should create new objects or clone the original tx and >> make sure you remove the signature from the inputs. >> - Specify the SendRequest.feePerKb >> - Call wallet.complete(sr). If you removed the original change output, >> this will add a new change output. If you did not remove the original >> change output, this will add another input to cover the extra fee and >> a new output with the new change. tx will be signed. >> - call wallet.commitTx(sr.tx). This will add the tx to the wallet. >> Both new and original tx will be in the pending collection, the state >> for both of them will be IN_CONFLICT. >> - broadcast the new tx >> >> Also... implementing a replaceByFee method would be a good idea. Check >> https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki so it >> is compatible with RBF in bitcoin core. >> Something like Transaction newTx = wallet.replaceByFee(tx, newFeePerKB) >> >> >> >> On Thu, Jun 23, 2016 at 2:01 PM, Andreas Schildbach >> <[email protected]> wrote: >> > In theory you should be able to commit a double spend to the wallet, >> > putting both conflicting transactions into IN_CONFLICT state (a bitcoinj >> > 0.14). But I'm not sure if it works via the complete/commit API, because >> > the feature was designed to detect double spends received via the >> > network. >> > >> > >> > On 06/23/2016 06:13 PM, Manfred Karrer wrote: >> >> The title does not mean I want to scam people :-) but to fix issues >> >> with >> >> chains of transactions where an old tx never make it into the >> >> blockchain >> >> because not sufficient miner fee was paid, and to unlock the follow up >> >> transactions from being locked in with the old tx. >> >> I have a case where a user used 0.00000001 fee, so that tx will >> >> probably >> >> never get confirmed and all follow up txs are blocked as well. >> >> I need a feature to unlock those txs by double spending them. >> >> Is there support for that in BitcoinJ? Can anyone point me to the >> >> relevant code? If there is no support, are there suggestions how to >> >> implement that? >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups "bitcoinj" group. >> >> To unsubscribe from this group and stop receiving emails from it, send >> >> an email to [email protected] >> >> <mailto:[email protected]>. >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "bitcoinj" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an email to [email protected]. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Oscar Guindzberg > > -- > You received this message because you are subscribed to the Google Groups > "bitcoinj" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- Oscar Guindzberg -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
