Topic: Paying additional fees for third party transaction, possible ? (Read 814 times)

Note that it isn't entirely clear to me which mining pools and mining farms support CPFP.  Only those that include support for CPFP will take into consideration your new transaction when determining whether or not to confirm the previous transaction.  You'll have to wait for one of those to solve a block, and then your fee will have to be high enough for them to decide that it is worth it to confirm both transactions in the same block.

Another option, would be to attempt to contact some very large mining pools and/or mining farms directly and ask if they would be willing to accept a transaction paying them directly in exchange for confirming the existing transaction for you.

Super, now I get it. Thanks for taking the time to explain !

The hash is a hash of the transaction with some modifications. Those modifications are: the input scripts areblanked out (replaced with 0x00), the input that is currently being signed is given an input script of the output script the transaction refers to, and the sighash code is appended to the end. Then that is hashed and that hash is signed. The signature produced is then placed into its corresponding input's scriptsig.

This link might help: https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx

Yeah well, that's the part I'm not getting at all 

The hash of the transaction is AFAIK the hash of all data contained in the transaction,
including the input sigs. It's like a snail biting its own tail. Or are the sigs somehow
signing a version of the TX with the sigs omitted or left blank? I must confessed to
being a bit confused.

It is a little complicated. I think that (I'm not quite sure) if you enable coin control you should be able to select unconfirmed inputs to spend from. Otherwise you will have to use the RPC console to craft a transaction by hand with the raw transaction RPCs and broadcast that.
[/quote]

Yeah, was expecting that coin control was the answer. I need to go experiment with that on testnet.

Thanks !

The signature is the signature of the hash of the transaction. The hash is computed on the fly and if the signature does not validate to the specified public key with the hash as the input, then the signature, and thus transaction, is invalid.

It is a little complicated. I think that (I'm not quite sure) if you enable coin control you should be able to select unconfirmed inputs to spend from. Otherwise you will have to use the RPC console to craft a transaction by hand with the raw transaction RPCs and broadcast that.

OK, didn't realize the signature of each input was somehow
bound to the TX itself. I wonder how that works. Gotta read
up on this.


Indeed. Good point.


Cool. And will the satoshi client be able to do this (as in : spend from
an unconfirmed TX with large fees) ?

If so, I guess that solves my problem.

Thanks for the explanation.

What you are proposing is entirely impossible. It is not possible to "dissect and reassemble" an already broadcasted transaction without having the private keys that spend the inputs. You cannot add inputs or outputs to the transaction because the signatures for each input ensure that the transaction has not been modified in any way. Otherwise anyone would be able to steal other people's Bitcoin.

The solution to your problem is called Child Pays For Parent (CPFP). A CPFP transaction is a transaction that has some inputs that spend from unconfirmed transactions. It may also have other inputs from confirmed transactions. The idea is that that transaction will have a significantly higher fee than a normal transaction. This high fee would cover the fee of the unconfirmed transaction and the CPFP transaction itself, hence the Child Pays For Parent. Then, any miner with CPFP enabled will pick up the CPFP transaction and the unconfirmed one and confirm them both at the same time.

Hello,

I have a question that I think is becoming more and more relevant in these
days of systematically full blocks and where getting transactions confirmed
is increasingly becoming a total crapshoot.

Say someone sends me bitcoins. I discover this because coins are sent to
an addie I control and therefore my wallet latches on to it and displays it
in my transaction ledger.

However, upon close examination of the transaction, it becomes clear that
the cheapskate who sent it included way too little fees and the TX will take
ages to confirm, if ever.

At that point, if it's essential enough for me to get the funds that were sent,
I would not mind actually paying the fees *myself* to lubricate the confirmation
of this TX.

Three questions:

    - is this theoretically even possible ? Can I somehow dissect the already broadcasted TX
      to reassemble it into a larger one with addt'l inputs (say an input from an addie *I*
      control) so as to pay higher fees ? And once that is done, broadcast this newly
      constructed TX, which would hopefully get prioritized before the old one and make
      it a double spend.

    - if possible, is there a tool / wallet out there that would let me do this, or, barring that,
      is there a way to pull it off via the satoshi client RPC interface.

     - also, if possible, in the scenario where:
           - old TX is stuck
           - I construct new, higher prio version
           - I broadcast new version
           - old TX gets included in a block, making the new one a double spend
       then what happens to the "extra" input I added ? Can that signed input somehow
       be reclaimed by someone ?

Any wisdom on the topic is welcome