best way to "instant send back"

[flower1024]

hi,

i am developing a service where - at some times - i need to send back btc to its origin immediatly (because they are not inside min or max)

atm i want to do this: construct a tx which uses the wrong input as an output, sign and publish it.
there is no need for a change address as i need to send back ALL of the input.

^^ this should also solve the confirmation problem (because if his transactions gets invalidated my "sendback" transaction will also - so we are fine)

but what about transactions fees and what happens if my sendback transaction (which is lowprio - even if its guaranteed to be small) does not get into a block?

is it possible to do this which bitcoind-0.7?

thanks

[1714164057]

1714164057

[1714164057]

1714164057

[1714164057]

1714164057

[Stephen Gornick]

i am developing a service where - at some times - i need to send back btc to its origin

Gettransaction is an API call that gives this info, for a transaction received to an address in your wallet.

The upcoming release of Version 0.7 of the bitcoin.org client has getrawtransaction and that will give you that information for any address, regardless of whether or not it was one in your wallet.

As far as fees, if you don't pay a fee it may (will, most likely) take time (possibly a long time, like a day) to get included in a block.

[flower1024]

i am developing a service where - at some times - i need to send back btc to its origin

Gettransaction is an API call that gives this info, for a transaction received to an address in your wallet.

The upcoming release of Version 0.7 of the bitcoin.org client has getrawtransaction and that will give you that information for any address, regardless of whether or not it was one in your wallet.

As far as fees, if you don't pay a fee it may (will, most likely) take time (possibly a long time, like a day) to get included in a block.

is it guaranteed that it will end up in a block?
(means: will bitcoin0.7 resend it forever if needed? - even if its restarted?)

and - sorry my english is not that good - am i able to construct a tx which uses the "sendback" output as an input? <-- with this i hope to elimate the need to wait for 6confs on this transactions and may i send it through bitcoind?

thanks.

[Stephen Gornick]

is it guaranteed that it will end up in a block?
(means: will bitcoin0.7 resend it forever if needed? - even if its restarted?)

Once a transaction has been broadcasted the client generally doesn't need to do anything else.  The exception is where there were communications issued and the message never got received by any nodes, or the transaction was invalid or too spammy and nodes didn't relay it.

But the client will see that it hasn't been included and before a half hour is up will re-broadcast it (and continue to do so forever until it is included in a block).

am i able to construct a tx which uses the "sendback" output as an input?

You can create a new transaction that happens to be a transaction that send the funds back, but there is no relationship between the two other than that one was relayed to you first before you created a new one in response.

<-- with this i hope to elimate the need to wait for 6confs on this transactions and may i send it through bitcoind?

Bitcoin-qt will not let you create a transaction that doesn't have at least one confirmation.  I think bitcoind allows a transaction on 0/unconfirmed.  If not, others that do this must be patching bitcoind to support it.

So you are creating a blockchain based gambling site?

[flower1024]

is it guaranteed that it will end up in a block?
(means: will bitcoin0.7 resend it forever if needed? - even if its restarted?)

Once a transaction has been broadcasted the client generally doesn't need to do anything else.  The exception is where there were communications issued and the message never got received by any nodes, or the transaction was invalid or too spammy and nodes didn't relay it.

But the client will see that it hasn't been included and before a half hour is up will re-broadcast it (and continue to do so forever until it is included in a block).

even if its restarted?

am i able to construct a tx which uses the "sendback" output as an input?

You can create a new transaction that happens to be a transaction that send the funds back, but there is no relationship between the two other than that one was relayed to you first before you created a new one in response.

<-- with this i hope to elimate the need to wait for 6confs on this transactions and may i send it through bitcoind?

Bitcoin-qt will not let you create a transaction that doesn't have at least one confirmation.  I think bitcoind allows a transaction on 0/unconfirmed.  If not, others that do this must be patching bitcoind to support it.

as i want to use createrawtx and signrawtx for this. i dont think i'll have a problem with 0conf then

So you are creating a blockchain based gambling site?

no
it will work like satoshidice - but no gambling...

stay tuned until december

thanks for your input!

[Stephen Gornick]

But the client will see that it hasn't been included and before a half hour is up will re-broadcast it (and continue to do so forever until it is included in a block).

even if its restarted?

Yes.  It won't be immediately on startup, but within a half hour the client will rebroadcast it.

[byronbb]

I believe you can figure this out using blockchain.info for now. http://blockchain.info/rawtx/$tx_hash

[chrisrico]

To what address will you send this refund transaction? I think I saw in another thread you were assuming that the previous output's script is acceptable for this, but it is not the case.

I would recommend that you keep a "refund address" on file for your customers, and send all refunds to that address. It also makes it less confusing for them, because they can have that address labeled as "refunds from flower1024", instead of your refund showing up as "payment from Bob for widgets".

[flower1024]

To what address will you send this refund transaction? I think I saw in another thread you were assuming that the previous output's script is acceptable for this, but it is not the case.

I would recommend that you keep a "refund address" on file for your customers, and send all refunds to that address. It also makes it less confusing for them, because they can have that address labeled as "refunds from flower1024", instead of your refund showing up as "payment from Bob for widgets".

i dont want to have any account or registration.

i could imagine someone registers a "widthdraw" address by signing a message with his sending address. but i dont like that idea as it does not work forever (after some time there a new change addresses generated which could be used for new sends - but this time i dont have any signed message for this address)

at launch our service will just send funds back to the first input. i hope from an answer from magicaltux about an api call where i provide a txn-hash and he sends me the real deposit address back.

maybe rev2 will have user accounts.

[Gavin Andresen]

i hope from an answer from magicaltux about an api call where i provide a txn-hash and he sends me the real deposit address back.

That would violate his users' privacy; maybe I don't want you (or the rest of the world) to know that I have a Gox account.

You don't need accounts or registration, you just need a two-step process:

1) User tells you their refund address
2) You give the user a unique deposit address, and link the refund and deposit addresses in your database.

To avoid creating a gazillion deposit addresses or bothering the user to give you a refund address every time, you might want to store the "user already got a deposit address" flag in a session cookie.  But if the user will remember the deposit address then even that isn't necessary.

[flower1024]

i hope from an answer from magicaltux about an api call where i provide a txn-hash and he sends me the real deposit address back.

That would violate his users' privacy; maybe I don't want you (or the rest of the world) to know that I have a Gox account.

You don't need accounts or registration, you just need a two-step process:

1) User tells you their refund address
2) You give the user a unique deposit address, and link the refund and deposit addresses in your database.

To avoid creating a gazillion deposit addresses or bothering the user to give you a refund address every time, you might want to store the "user already got a deposit address" flag in a session cookie.  But if the user will remember the deposit address then even that isn't necessary.

yes, that will do the trick.
thanks