Is it possible to make a "bouty" time-locked wallet w/out knowing the receiver?

[CryptoCoinUser]

Use case: I'm shopping around for a good or service, and to prove I mean business, I put some BTC in a new wallet and
- prove that I'm the one who funded that wallet
- the balance cannot be spent for X amount of time OR until the good or service is provided to me, as adjudicated by a 3rd party
- we don't who will provide the good or service, so don't know the receiving wallet
- if no one provides the good or service before time X expires, I'm free to spend the balance as I please.

Is it possible to do all of the above with the existing Bitcoin protocol, with the 3rd never being able to run off with my money?

Will we have to know the receiving address first?

Without a receiving address,  will we have to wait for some kind of SmartContracts to implement the above?

Thanks.

[DannyHamilton]

Use case: I'm shopping around for a good or service, and to prove I mean business, I put some BTC in a new wallet and
- prove that I'm the one who funded that wallet
- the balance cannot be spent for X amount of time OR until the good or service is provided to me, as adjudicated by a 3rd party
- we don't who will provide the good or service, so don't know the receiving wallet
- if no one provides the good or service before time X expires, I'm free to spend the balance as I please.

Is it possible to do all of the above with the existing Bitcoin protocol, with the 3rd never being able to run off with my money?

Will we have to know the receiving address first?

Without a receiving address,  will we have to wait for some kind of SmartContracts to implement the above?

Thanks.

Due to your requirement of "the balance cannot be spent for X amount of time", I don't think this can be implemented unless nLockTime is supported.

Edit: As I think about it a bit more...

As far as I know, there isn't any way to "lock" an output until a given datetime or blockheight.  nLockTime will allow you to lock a transaction so that it can't be used until a given datetime or blockheight, but while waiting for that deadline, a replacement transaction could be broadcast that replaces it.

The only way I can think of to accomplish what you are looking for is if the 3rd party was trusted to have full control of the output.  The third party could then hold on to the output until the deadline, and then either forward the balance on to whomever is providing the goods or services. If nobody provides the goods or services by the deadline, then the 3rd party would need to be trusted to send the balance back to you.

[DannyHamilton]

If nLockTime was currently supported...

You could create a transaction that sends the balance to a 2-of-2 multisig address where you control one of the keys, and the other key is given to you by the 3rd party.  The 3rd party could then pre-sign a transaction that sends this balance back to you, but which is locked with nLockTime.

This should prevent you from accepting the returned balance (with the second transaction) until the nLockTime, and would prevent the 3rd party from controlling the balance (from the first transaction) until you provided the signature for that transaction.

If you found a provider of the desired goods/service, then the 3rd party could create a transaction that immediately spends the balance from the first transaction and sends it to the provider.  The 3rd party could then send you a copy of this transaction with their signature.

This is where the plan falls apart a bit.  If you sign the transaction and broadcast it, then the provider gets paid, and the nLockTime transaction becomes invalid (preventing you from taking the balance back).  Unfortunately, there is nothing that FORCES you to sign this immediate transaction to the provider.  You theoretically could simply refuse to sign the transaction, and wait until nLockTime expires. Then broadcast the nLockTime transaction, thereby getting your balance back.

I'll have to think about this a bit more.  There might be a way to accomplish it with multiple nLockTime transactions, but at the moment, it looks like either the 3rd party has to trust you to actually sign the transaction that pays the provider, or you have to trust the third party to handle the funds appropriately.

[CryptoCoinUser]

Thanks for replying.
Let's simplify and forget about time entirely for now.
Can I just prove that
A) I have the funds and
B) the 3rd party has the power to transfer the funds to a goods/service provider
but without
A) knowing who the provider will be,
B) giving the 3rd party an opportunity to run away with my funds.

Basically, can a Bitcoin escrow transaction be "proven" if you have the 1st and 3rd parties, but not yet the 2nd?

Hope that makes sense.

Thanks

[kolinko]

You can do it through distributed oracles:

https://github.com/orisi/wiki/wiki/Performing-a-Timelock-transaction
and
https://github.com/orisi/wiki/wiki/Orisi-White-Paper

The idea is that you have a set of 5 to 15 trusted arbiters who keep keys, and will unlock money only when over 50% of them decide the time has passed. Orisi is an example implementation - still in alpha, but you can pm me or the project (support@oracles.li), if you're interested.