Expiration date

[idlecore]

Would it be possible to put an expiration data on 'coins'? So that if some 'coins' weren't seen online for a few years, they would be forfeited to a pool of currency that could then be redistributed on top of fees. Could this solve the problem of lost currency, not only on bitcoin, but on other currencies, even using other forms of proof? If it was possible, how long should 'coins' last? A year seems too little, two, maybe, but ideally more than that, maybe 4-8 years would be right.

edit: wallet -> address -> 'coins'

[1715370308]

1715370308

[1715370308]

1715370308

[1715370308]

1715370308

[1715370308]

1715370308

[dserrano5]

Would it be possible to put an expiration data on wallets? So that if a wallet wasn't seen online for a few years, it's contents would be forfeited to a pool of currency that could then be redistributed on top of fees.

There are no "wallets" in the protocol. I can make a paper wallet and keep it unspent for years, and to the protocol it would be no different than any other regular address.

[idlecore]

Would it be possible to put an expiration data on wallets? So that if a wallet wasn't seen online for a few years, it's contents would be forfeited to a pool of currency that could then be redistributed on top of fees.

There are no "wallets" in the protocol. I can make a paper wallet and keep it unspent for years, and to the protocol it would be no different than any other regular address.

Does my post make sense if I switch 'wallet' for 'address'?

[DannyHamilton]

Would it be possible to put an expiration data on wallets? So that if a wallet wasn't seen online for a few years, it's contents would be forfeited to a pool of currency that could then be redistributed on top of fees.

There are no "wallets" in the protocol. I can make a paper wallet and keep it unspent for years, and to the protocol it would be no different than any other regular address.

Does my post make sense if I switch 'wallet' for 'address'?

Honestly? No.  There aren't actually any addresses at the technical level either.  Addresses are something we humans use to make it easier to talk about a particular kind of redeem script.

In the actual transactions, all that exist are values and redeem scripts.  If you can satisfy the conditions of a redeem script, then you can re-assign the value to new redeem scripts.

When we use a "Bitcoin address", what actually happens in the transaction is that a script is created that essentially says: "Provide an ECDSA digital signature from a private key such that the hash of the public key matches a specific value".

Anyone that can provide the required signature can re-assign the value to new redeem scripts.  If you can't provide the required signature, then you cannot re-assign the value.

There is a concept of a "locktime" where a transaction cannot be redeemed until after that amount of time, but I don't think this is supported right now.  Even if it was, you'd have to choose to add the locktime on the transaction when you created it.  Essentially you'd have to choose create a new transaction that has a redeem script that ANYBODY could redeem, and place a locktime on it that prevents people from redeeming it too soon.  Then you'd have to somehow publish this transaction publicly.  If you hadn't redeemed the outputs yet by the time the locktime expired, then people who knew about your public posting of the transaction would be able to race to get their redeem in first to take your bitcoins.  Would you voluntarily create such a "locktime" transaction, knowing that it would potentially give others access to your bitcoins?

[cr1776]

It sounds to me like you are saying: if "coins" (abstracting away the underlying details of scripts, inputs, outputs etc) are dormant for a period of time, then the "coins" are redistributed to someone else.  E.g. miners or people with transactions in the block.  So if the "coins" hadn't been moved in say, 210,000 blocks (roughly 4 years although somewhat less in practice), the coins would be redistributed on top of the fees for the following block.

The concept has been discussed before, and if you implemented such a scheme (however you did it from a technical level), you would be forking bitcoin, both the software and the blockchain itself. You'd end up with an alt-coin of some type.  If you were implementing it with bitcoin everyone would have coins on both sides of the fork.

Some people might like this alt-coin and switch completely to it selling their original coins on the bitcoin side, some people might not care and keep their coins in bitcoin and the new alt-coin, and some people might hate the alt-coin and sell all the coins on the new alt-coin and trade them for bitcoins.  Some would not doubt be a mixture.

You have to ask yourself: which coin would I want if it were me?  Would you want a coin that if I forgot to move the coins every 4 years (or 8 or 2 or ...) would take them or would you want a coin that kept them safe until you wanted them?   Obviously for the technically minded, it would be easy to set up something to just move your coins every year and avoid the issue, so who would be impacted?  The non-technically minded people most likely who would think, "oh, I'll move the coins every year or so" and then forget and have their alt-coin taken. 

So from a policy standpoint, it seems unlikely that people would switch to this coin.  There is a possibility they might use it for some purpose, but I think that many people would not use it in practice.

You could always implement the idea and put it to the test to see what happens in reality with adoption.  It would be an interesting experiment to see in practice. 

[idlecore]

It sounds to me like you are saying: if "coins" (abstracting away the underlying details of scripts, inputs, outputs etc) are dormant for a period of time, then the "coins" are redistributed to someone else.  E.g. miners or people with transactions in the block.  So if the "coins" hadn't been moved in say, 210,000 blocks (roughly 4 years although somewhat less in practice), the coins would be redistributed on top of the fees for the following block.

The concept has been discussed before, and if you implemented such a scheme (however you did it from a technical level), you would be forking bitcoin, both the software and the blockchain itself. You'd end up with an alt-coin of some type.  If you were implementing it with bitcoin everyone would have coins on both sides of the fork.

Some people might like this alt-coin and switch completely to it selling their original coins on the bitcoin side, some people might not care and keep their coins in bitcoin and the new alt-coin, and some people might hate the alt-coin and sell all the coins on the new alt-coin and trade them for bitcoins.  Some would not doubt be a mixture.

You have to ask yourself: which coin would I want if it were me?  Would you want a coin that if I forgot to move the coins every 4 years (or 8 or 2 or ...) would take them or would you want a coin that kept them safe until you wanted them?   Obviously for the technically minded, it would be easy to set up something to just move your coins every year and avoid the issue, so who would be impacted?  The non-technically minded people most likely who would think, "oh, I'll move the coins every year or so" and then forget and have their alt-coin taken. 

So from a policy standpoint, it seems unlikely that people would switch to this coin.  There is a possibility they might use it for some purpose, but I think that many people would not use it in practice.

You could always implement the idea and put it to the test to see what happens in reality with adoption.  It would be an interesting experiment to see in practice. 

That's about what I was thinking. Initially I thought the non-technically minded people would have a harder time with it, as you suggested, but then I thought, these people, particularly these people, would need to use a GUI manager of some sort, and implementing an expiration warning, client side, would be simple. There would still be the problem with someone not even opening the manager for a few years and then coming back to a nasty surprise.

[DannyHamilton]

Could this solve the problem of lost currency

Fortunately, lost currency isn't a problem for anyone except the person that lost it.  Stealing money from people who don't move their money seems like a really bad way to help people that permanently lose access to their money (especially since it does nothing to help those people get their lost coins back).

[cech4204a]

I'm not sure why you would want that to be done, since you know that some people store money in their safe for 20 years without opening them. Some people might even die and their kids might not even know that they had BTC, so after 10 year when they find out, they are Expired ? Not a good idea, sorry.

[cr1776]

Lost coins aren't a problem and they never will be.

qft.

"Redistributing"/taking/stealing coins from someone who hasn't touched them is the problem with this idea. All these ideas like blocking the FBI coins, ruining fungibility, taking dormant coins and the like need to have the people who suggest them implement them so we can put the ideas to bed once and for all.

[amaclin]

Would it be possible to put an expiration data on 'coins'? So that if some 'coins' weren't seen online for a few years, they would be forfeited to a pool of currency that could then be redistributed on top of fees. Could this solve the problem of lost currency, not only on bitcoin, but on other currencies, even using other forms of proof? If it was possible, how long should 'coins' last? A year seems too little, two, maybe, but ideally more than that, maybe 4-8 years would be right.

edit: wallet -> address -> 'coins'

The answer is: yes, it is possible.
It can be made by (1) bitcoin hard-fork or (2) new crypto-coin with two simple rules:
1) coinbase transaction gains all unspent outputs from all transactions X blocks before it ( where X = 6 * 24 * 365 * YEARS )
2) all unspent outputs with the age of X blocks can not be spent

You can do these patches in core yourself. Or ask somebody to do this.
I think it is not too hard to make such changes. May be even I can do it. (Not for free)
You can create several forks with the constant YEARS set to 1, 2, 4, 42 and 999
The main problem - who will use this crypto-currency? How many people will switch to it?

Upd: Bitcoin network is ~5 years old now. So, you can set the constant YEARS to 6+ and create your client. After a while we will see the results - the network will split to the 2 forks - "classic" and "yours". I do not know which part will be bigger.

[luv2drnkbr]

hell no.  just because you fucked up a send doesn't mean you get to raid my savings.  gtfo.