Running without wallet

[nelisky]

Could this be done?

Ok, maybe that's not enough information there Here's my line of thought:

- I have a wallet, it has some funds. I create an address and send a few coins to it.
- I'm on another client altogether now. I want to collect these coins, but the address isn't mine. What do I need, which keys does it take to create a transaction from the sender address to a private address of mine?

In other words, what do I need to own the result of a transaction and where does bitcoin client store that (in code, I know its in the wallet )

[LZ]

I don't follow you.

[nelisky]

Say you generate a new address on your client, its 1abc...
Now on another client you transfer to that address, so when the 1st client sees that transaction in a block, and checks it using its priv key, it knows the transaction belongs to it.

If you add that key to another client you can grab the transaction elsewhere, right? Spending it will only happen once, but multiple wallets can have that address.

What I want to do is to have the address+key so I can, without ever adding that key to my wallet.dat, create a transaction spending the value in that address+key, effectively sending it to my real address.

This would make for a proxy address schema, where you could send money to the network and then provide the key information to anyone to collect, but without actually holding the proxy key, it would be use and throw away.

Is that any clearer?

[theymos]

You just need the private key.

1. I send coins to an address.
2. I transmit the private key for that address to you.
3. You can now spend anything owned by that address. You could send the entire balance to a new address and then discard the key.

[BioMike]

Export/import function for private keys?

[nelisky]

Export/import function for private keys?

On steroids... I want to be able to tell the client:
bitcoind collectfromkey privkey amount

And it would create the transaction with the privkey as sender, amount as, well, amount, and my own address (may provide it on cli too, of course) as recipient. It may be actually importing the private key, sure, although I don't think that would be needed technically, so as long as I can construct the transfer pdu.

[nimnul]

Say you generate a new address on your client, its 1abc...
Now on another client you transfer to that address, so when the 1st client sees that transaction in a block, and checks it using its priv key, it knows the transaction belongs to it.

If you add that key to another client you can grab the transaction elsewhere, right? Spending it will only happen once, but multiple wallets can have that address.

What I want to do is to have the address+key so I can, without ever adding that key to my wallet.dat, create a transaction spending the value in that address+key, effectively sending it to my real address.

This would make for a proxy address schema, where you could send money to the network and then provide the key information to anyone to collect, but without actually holding the proxy key, it would be use and throw away.

Is that any clearer?

It won't work because a malicious person can give private key and then spend those money himself effectively taken the given money back.

Current scheme when destination client provides his public key is designed to protect against that.

You may also see a related discussion at http://bitcointalk.org/index.php?topic=939.0

That scheme proposed by me allows to run generating nodes without a wallet, but without the above flaw.

Why do you want to run without a wallet at the first place?

[nelisky]

Current scheme when destination client provides his public key is designed to protect against that.

You may also see a related discussion at http://bitcointalk.org/index.php?topic=939.0

That scheme proposed by me allows to run generating nodes without a wallet, but without the above flaw.

Why do you want to run without a wallet at the first place?

I don't. I want to accept a transaction using a provided key and immediately transfer that out to some address. Running without a wallet is kind of an eufemism.

So basically I send a transaction to an address that I own, but no client has, not even mine. That transaction gets into the next block and will be confirmed, but never collected.
Time passes, I provide that key to someone (QR code, email, smoke signals, morse code, whatever) and they want to collect. Notice I didn't transfer to that person, neither did I use a 3rd party payment processor.
Of couse, after providing the private key to that person I can still use it myself, but then that person has the option to, be it by a new feature in the client or by some service provided in the web, say "here's a key, transfer all that it has to my bc address". After that is done, I no longer hold any value in that priv key.

The reasons why I think this is useful are, for now, only mildly disclosed, but can we, technically, do it?

[MoonShadow]

So basically I send a transaction to an address that I own, but no client has, not even mine. That transaction gets into the next block and will be confirmed, but never collected.
Time passes, I provide that key to someone (QR code, email, smoke signals, morse code, whatever) and they want to collect. Notice I didn't transfer to that person, neither did I use a 3rd party payment processor.
The reasons why I think this is useful are, for now, only mildly disclosed, but can we, technically, do it?

I'm guessing that you want to run a client upon a machine that you don't consider secure, and don't want any of your private keys exposed if said machine were compromised with/without your knowledge.  If this is what you want, I don't think that it's possible.  I'm pretty sure that the private key is neccessary for signing the special transaction at the top of a new block that creates those 50 new bitcoins, forever exposing the keypair used on your non-secure machine to potential theft.  There are certainly ways to make that more difficult via software, such as an encrypted wallet, but there probably isn't any way to be absolute.

[nelisky]

So basically I send a transaction to an address that I own, but no client has, not even mine. That transaction gets into the next block and will be confirmed, but never collected.
Time passes, I provide that key to someone (QR code, email, smoke signals, morse code, whatever) and they want to collect. Notice I didn't transfer to that person, neither did I use a 3rd party payment processor.
The reasons why I think this is useful are, for now, only mildly disclosed, but can we, technically, do it?

I'm guessing that you want to run a client upon a machine that you don't consider secure, and don't want any of your private keys exposed if said machine were compromised with/without your knowledge.  If this is what you want, I don't think that it's possible.  I'm pretty sure that the private key is neccessary for signing the special transaction at the top of a new block that creates those 50 new bitcoins, forever exposing the keypair used on your non-secure machine to potential theft.  There are certainly ways to make that more difficult via software, such as an encrypted wallet, but there probably isn't any way to be absolute.

That use case has never crossed my mind

I really want to throw a transaction into the bitcoin ether, and then be able to provide the information to someone else so they can collect that transaction. Who that someone else is I don't know at the time of the transfer.

[semyazza]

It's an interesting idea. What you're after is a bitcheck?  Once the check is "cashed" it is no longer good?

[Anonymous]

So basically I send a transaction to an address that I own, but no client has, not even mine. That transaction gets into the next block and will be confirmed, but never collected.
Time passes, I provide that key to someone (QR code, email, smoke signals, morse code, whatever) and they want to collect. Notice I didn't transfer to that person, neither did I use a 3rd party payment processor.
The reasons why I think this is useful are, for now, only mildly disclosed, but can we, technically, do it?

I'm guessing that you want to run a client upon a machine that you don't consider secure, and don't want any of your private keys exposed if said machine were compromised with/without your knowledge.  If this is what you want, I don't think that it's possible.  I'm pretty sure that the private key is neccessary for signing the special transaction at the top of a new block that creates those 50 new bitcoins, forever exposing the keypair used on your non-secure machine to potential theft.  There are certainly ways to make that more difficult via software, such as an encrypted wallet, but there probably isn't any way to be absolute.

That use case has never crossed my mind

I really want to throw a transaction into the bitcoin ether, and then be able to provide the information to someone else so they can collect that transaction. Who that someone else is I don't know at the time of the transfer.

I want to hide a bitcoin in a geocache and give people hints on the hiding spot 

[nelisky]

It's an interesting idea. What you're after is a bitcheck?  Once the check is "cashed" it is no longer good?

Yeah, that's kind of what I want. Not the exact thing but a great use for it

[nelisky]

I want to hide a bitcoin in a geocache and give people hints on the hiding spot 

I like that idea, I like it a lot! I'll try and give this a go, and we can all do a global geocaching hunt!

[lfm]

Export/import function for private keys?

On steroids... I want to be able to tell the client:
bitcoind collectfromkey privkey amount

And it would create the transaction with the privkey as sender, amount as, well, amount, and my own address (may provide it on cli too, of course) as recipient. It may be actually importing the private key, sure, although I don't think that would be needed technically, so as long as I can construct the transfer pdu.

If you wanted to do this without any need to change the current software at all, you would :

1: create a new wallet directory
2: create a new receive address for that wallet.
3: send your amount to that wallet
4: publish the whole wallet.dat file as an attached file or whatever.

the person who wanted to try to recover the amount would then put that wallet in a new .bitcoin directory and send the amount wanted from it to a new bitcoin address in their regular wallet. (if they were first they would then own the whole amount  and if they didn't want the whole amount they would have to republish the new resultant wallet file with the "change" left over in it.)

[nelisky]

If you wanted to do this without any need to change the current software at all, you would :

1: create a new wallet directory
2: create a new receive address for that wallet.
3: send your amount to that wallet
4: publish the whole wallet.dat file as an attached file or whatever.

the person who wanted to try to recover the amount would then put that wallet in a new .bitcoin directory and send the amount wanted from it to a new bitcoin address in their regular wallet. (if they were first they would then own the whole amount  and if they didn't want the whole amount they would have to republish the new resultant wallet file with the "change" left over in it.)

Almost, but not quite the same thing. A wallet includes the needed information, i.e. the private key, but its format may not be supported by future clients. It is not user friendly, can't do the 'here's a printed QRCode' or 'just open this file in the bitcoin client'

Also, the end recipient would have to, as you say, open the new wallet and transfer. This is very non-trivial, especially on GUI clients, and all non technical users would get up and scream in one voice: "Huh?"

[lfm]

If you wanted to do this without any need to change the current software at all, you would :

1: create a new wallet directory
2: create a new receive address for that wallet.
3: send your amount to that wallet
4: publish the whole wallet.dat file as an attached file or whatever.

the person who wanted to try to recover the amount would then put that wallet in a new .bitcoin directory and send the amount wanted from it to a new bitcoin address in their regular wallet. (if they were first they would then own the whole amount  and if they didn't want the whole amount they would have to republish the new resultant wallet file with the "change" left over in it.)

Almost, but not quite the same thing. A wallet includes the needed information, i.e. the private key, but its format may not be supported by future clients. It is not user friendly, can't do the 'here's a printed QRCode' or 'just open this file in the bitcoin client'

Also, the end recipient would have to, as you say, open the new wallet and transfer. This is very non-trivial, especially on GUI clients, and all non technical users would get up and scream in one voice: "Huh?"

I think most of your objections could be overcome with a simple shell that handled the "just open this file" case and could simplify the command line for stupid^h^h^h^h^h^h non technical users who can't be bothered to figure out a shell command.

[nelisky]

Almost, but not quite the same thing. A wallet includes the needed information, i.e. the private key, but its format may not be supported by future clients. It is not user friendly, can't do the 'here's a printed QRCode' or 'just open this file in the bitcoin client'

Also, the end recipient would have to, as you say, open the new wallet and transfer. This is very non-trivial, especially on GUI clients, and all non technical users would get up and scream in one voice: "Huh?"

I think most of your objections could be overcome with a simple shell that handled the "just open this file" case and could simplify the command line for stupid^h^h^h^h^h^h non technical users who can't be bothered to figure out a shell command.

Could be, but it's the 'non techs' I am aiming at, and more so the ones using Windows GUI, so shell is not even in their glossary. But even though you may object, humour me. Can this be done?