Idea: Holding wallet

[ThomasDB]

The most important thing moving forward is without a doubt theft prevention, although theft itself is not that common, the "fear of theft" is almost an epidemic.

Its just a scary thing to have a large amount of coins on a computer, even though its offline and all precautions have been taken, especially for novice/new users this is a turnoff. Many new users wants to join not as an active user but just to store wealth/invest.

So what if we did this:

The bitcoin devs create a function that enables users to create a "holding wallet". This wallet permanently make it so that the wallet can just send a transaction to a set of addresses which users enters upon wallet creation.

Then the day the user wants to use some coins, he initiates a transfer to one of the saved wallets and he is free to spend the coins.

It think this would open many opportunities and improve safety a lot and perhaps make third-party sites like blockchain.info a safe "middle man" alternative. The coins would not be there until the owner of the coins decides to spend them and the attacker would have to have both the original "Holding wallet" and one of the destination wallets/accounts.

What you guys think? Would love to hear other ideas, everyone should put some thought into this

[alp]

The most important thing moving forward is without a doubt theft prevention, although theft itself is not that common, the "fear of theft" is almost an epidemic.

Its just a scary thing to have a large amount of coins on a computer, even though its offline and all precautions have been taken, especially for novice/new users this is a turnoff. Many new users wants to join not as an active user but just to store wealth/invest.

So what if we did this:

The bitcoin devs create a function that enables users to create a "holding wallet". This wallet permanently make it so that the wallet can just send a transaction to a set of addresses which users enters upon wallet creation.

Then the day the user wants to use some coins, he initiates a transfer to one of the saved wallets and he is free to spend the coins.

It think this would open many opportunities and improve safety a lot and perhaps make third-party sites like blockchain.info a safe "middle man" alternative. The coins would not be there until the owner of the coins decides to spend them and the attacker would have to have both the original "Holding wallet" and one of the destination wallets/accounts.

What you guys think? Would love to hear other ideas, everyone should put some thought into this

This is a decent idea where you have a white list of addresses.  Now how do you update/create that list?  This does just push the problem to needing to compromise two wallets to get to your address.

[ThomasDB]

The most important thing moving forward is without a doubt theft prevention, although theft itself is not that common, the "fear of theft" is almost an epidemic.

Its just a scary thing to have a large amount of coins on a computer, even though its offline and all precautions have been taken, especially for novice/new users this is a turnoff. Many new users wants to join not as an active user but just to store wealth/invest.

So what if we did this:

The bitcoin devs create a function that enables users to create a "holding wallet". This wallet permanently make it so that the wallet can just send a transaction to a set of addresses which users enters upon wallet creation.

Then the day the user wants to use some coins, he initiates a transfer to one of the saved wallets and he is free to spend the coins.

It think this would open many opportunities and improve safety a lot and perhaps make third-party sites like blockchain.info a safe "middle man" alternative. The coins would not be there until the owner of the coins decides to spend them and the attacker would have to have both the original "Holding wallet" and one of the destination wallets/accounts.

What you guys think? Would love to hear other ideas, everyone should put some thought into this

This is a decent idea where you have a white list of addresses.  Now how do you update/create that list?  This does just push the problem to needing to compromise two wallets to get to your address.

I have no idea if this is feasible or not, however I wish there where more discussion on this topic as the current way limits the growth substantially, although one could argue that is a good thing for now.

you're correct, but what that means is that the user gets a type of TFA in a way, since the attacker would need access to both wallets.

If this was possible, what I would do is to set up this wallet on another computer that whitlists 3 addresses  (on Blockchain.info, Gox and Bitstamp) and enable TFA on those. I just don't see any way for an attacker to get hold of the coins then and for a novice/new person this will feel safe and be easy to set up.

[kjj]

There is no mechanism to restrict what address you can send to, and such a "feature" will almost certainly never be added.  Note that this would require a protocol change.  You could modify your client easily enough, but that doesn't really help you at all.

Even if such a thing were made, and the network was willing to enforce it, it would just move the problem to the recipient wallet.

[justusranvier]

There is no mechanism to restrict what address you can send to, and such a "feature" will almost certainly never be added.  Note that this would require a protocol change.  You could modify your client easily enough, but that doesn't really help you at all.

Even if such a thing were made, and the network was willing to enforce it, it would just move the problem to the recipient wallet.

Is there no way to construct a smart contract that accomplishes this using the existing opcodes?

[kjj]

There is no mechanism to restrict what address you can send to, and such a "feature" will almost certainly never be added.  Note that this would require a protocol change.  You could modify your client easily enough, but that doesn't really help you at all.

Even if such a thing were made, and the network was willing to enforce it, it would just move the problem to the recipient wallet.

Is there no way to construct a smart contract that accomplishes this using the existing opcodes?

Nope.  The script system is extremely limited in inputs.  It doesn't know anything about the output (or much else, for that matter).

[justusranvier]

There is no mechanism to restrict what address you can send to, and such a "feature" will almost certainly never be added.  Note that this would require a protocol change.  You could modify your client easily enough, but that doesn't really help you at all.

Even if such a thing were made, and the network was willing to enforce it, it would just move the problem to the recipient wallet.

Is there no way to construct a smart contract that accomplishes this using the existing opcodes?

Nope.  The script system is extremely limited in inputs.  It doesn't know anything about the output (or much else, for that matter).

It seems like you'd just need to add an opcode that reads an integer from the stack and returns the hash of the output script at that index position.

Then you combine those with an OR to create an input script that is only spendable via specific predetermined outputs.

[kjj]

Yes, there are lots of simple things we could do to make script processing stateful.  The hard part is going to be convincing everyone that stateful scripts are a good thing.  That is going to be rough going, since pretty much everyone prefers stateless.

This particular scheme doesn't actually add any security at all, and could actually cause people to lose coins.  It is actually an argument against state, not for.

[justusranvier]

The hard part is going to be convincing everyone that stateful scripts are a good thing.  That is going to be rough going, since pretty much everyone prefers stateless.

I have a plan for that: Build some very useful apps on OpenTransactions to show the use cases for those kinds of scripts and to grow demand for doing those things on the blockchain instead of requiring users to trust transaction servers.

[gmaxwell]

I have a plan for that: Build some very useful apps on OpenTransactions to show the use cases for those kinds of scripts and to grow demand for doing those things on the blockchain instead of requiring users to trust transaction servers.

There are tons of things that are already possible. No one uses them.  Armory, Multibit, Bc.i, and android wallet can't even send to a P2SH address, so _other_ people who want to do fancy things with script can't choose to do so on their own.

Almost seems like a waste of time to think about anything advanced at all.

[jedunnigan]

I have a plan for that: Build some very useful apps on OpenTransactions to show the use cases for those kinds of scripts and to grow demand for doing those things on the blockchain instead of requiring users to trust transaction servers.

There are tons of things that are already possible. No one uses them.  Armory, Multibit, Bc.i, and android wallet can't even send to a P2SH address, so _other_ people who want to do fancy things with script can't choose to do so on their own.

Almost seems like a waste of time to think about anything advanced at all.

IME there needs to be a proliferation of these ideas. Right now there is 0 traction because people 1) don't know about them or 2) if they do know about them they don't know how they would even go about building a tx with a complex script or 3) they know how to build them but they will never be accepted in a block.

The wiki is a bit confusing and not the most helpful on this subject. I was thinking of gathering some info myself and adding it to demystify the entire process.

Regardless, the the fact of the matter is that miners simply won't accept them without some incentive. Perhaps creators of custom scripted txs should append a higher tx fee or something. At the very least we need some wallet implementations that make it easier to send/recieve these types of txs.

All it would take is one hit app to use some cool scripts or something and everyone would jump on the bandwagon. But it's one of those chicken and egg problems...