Topic: Bitcoin Improvement Proposal (Read 400 times)

Yep. I think currently this problem is not solvable with on chain transactions, we would need SIGHASH_ANYPREVOUT for that, and even then there are some possible complications, for example the amount you chose could actually not be available anymore.

As a side note, in some altcoins the method may be already possible if they're not using UTXOs but an "account model", and thus working very similar to SIGHASH_ANYPREVOUT already now. So in the case this opcode never makes it into the code, in a sidechain such a flexible mechanism would be actually possible.

This is true for the original method which uses CSV but not for the adapted method where the timelock is set with CLTV to a fixed block height or time in the future, which would fit the OP's use case better. It would work almost exactly like in pooya87's example.

Thanks @littlemouse for your reference.

Actually that thread clearly mentions how difficult it would be to set up the timelock feature with the less to no knowledge about codes.

Checkout the solution from @Coin_trader. You can set up the same in Electrum wallet itself and have that “inheritance” bitcoin machine set up for your daughter.

Good to see that whatever we imagine in the crypto thee days is already thought by someone and surprisingly some solution pre exists. 

If someone has already tried, then share the thoughts.

This could also become the best way to “HODL” the coins as long term investment for specific period of time through above system.

Ahh, I do remember reading that now that you've linked it (and actually merited it at the time, heh).

I think the biggest drawback to this is the same as the drawback we are discussing above: As soon as Alice spends any of her bitcoin, then the transactions she has given to Bob are invalid and she has to generate new ones and give them to him. This method also requires Alice to keep a constant watch for the transactions she has given Bob showing up in a block. By using timelock as I suggested above, Alice can know for sure that there is zero chance the coins can be spent before the timelock expires. Using this method, Alice has to constantly check to see if Bob is trying to steal from her so she can sweep the coins before he can.

@o_e_l_e_o: Yep, with the coins on different utxos it works, but that wasn't that clear in your post; I think as the OP is not very experienced with contracts it's good if this detail is clarified. You're actually right that the method with various transactions, as the OP wrote, has also advantages.

---

I've found the "advanced approach" I wrote about in the last post, it was developed by user Andriian in 2019.
It was created for the case of a person who wants to ensure that after his death a family member has access to the funds, but can also be adapted to the use case "give the coins to my daughter at a certain day, regardless if I'm alive or dead." In this case CSV has to be replaced with CLTV.

The script would look exactly the same like in pooya87's approach in #8, but it has one difference: the transaction with the timelock is not broadcast, but given to the beneficiary (daughter, heir etc.).

The differences to the method storing it on the blockchain are minimal, but you save fees (the beneficiary/heir has to pay them), and there are privacy advantages (nobody sees that the daughter has access to the coins). In the original use case, however, when you want to transfer the coins only when you're already dead, Andriian's method has the big advantage that you don't have to renew this transaction regularly.

If I'm sure I want the coins for my daughter, and the probability I need them myself or change my mind is very low, I would perhaps prefer pooya87's method, because it's simpler to spend for the daughter/heir/beneficiary when the coins are already accessible for her public key "on the blockchain".

Not at all. I was simply assuming that OP was using coins in his own cold storage which will rarely, if ever, be moved. The coins for each transaction should already be separate UTXOs, so if he needs to spend one of the UTXOs it will only invalidate a single timelocked transaction, and not all of them.

I think it would be a reasonable approach to exclude some of OP's coins from this inheritance plan for the sake of ease. If he had, say, 10 BTC in these timelocked transactions, he could have 0.5 BTC in a different wallet for his own personal use. This could simply be passed on to his daughter by the way of a seed phrase which she will inherit after his death.

He actually only needs to move a single UTXO and it will invalidate the entire transaction. So if he has a timelocked transaction sending 100 UTXOs to his daughter, he can just move a single one of those UTXOs and the whole transaction is invalid.

I think there is a problem with this approach. You would need SIGHASH_ANYPREVOUT (BIP 118) for this, and it's currently still not included in the code.

Otherwise, any time you move your coins because you're still alive, you will invalidate all of the transactions to your daughter. Because when you move the coins, you'll spend the UTXO which is included in all timelocked transactions.

You could hold the coins for each transaction on a different address, then it would work. I think however it's an over-complicated approach, because you will have to move coins each year anyway. (It may make sense in some very special cases, for example, if you want to order coins by priority, "which ones could I need still in my lifetime and which ones not", etc.)

The simplest approach is instead what you (o_e_l_e_o) wrote here:

1) send a timelocked transaction to your daughter with all coins you want your daughter to receive, 1 year in the future. (You can send it even per (encrypted) email or messenger, if you're sure that she's storing it safely, or give her the transaction code on paper, etc.)
2) every 6 months, and every time you move your coins or even part of them, you send a new timelocked transaction, again 1 year in the future, and again with all coins.

And yes @OP, you can cancel even this simple plan any time: simply moving all coins to another address.

pooya87's method also works and has the advantage that your daughter will not have to store the transaction as she's able to move the coins with her key. But you pay fees one time more.

There was a more advanced method I'd read and which has already been implemented in a mobile test wallet, but I currently don't remember where it was.

I understand that there are sincere efforts to made bitcoin user friendly and also scalable. And many things have actually changed, but there is this feeling of technicalities in people's head while approaching bitcoin from higher angle other than send and recieve bitcoin. I am not an exception to this . But now I appreciate my decision to learn and my presence in this forum.
I am going to try this transaction timelock out, maybe for few weeks and I'll be glad to get bisq, SegWit and Timelock

LN was not introduced to handle increased number of transactions. The idea is to create an off chain channel that supports frequent and small amount of bitcoin transactions as coffee and tea transactions and at the end, the channel closed and collapse back to blockchain. The emphasis is rather on transaction fees.

My bad, my bad, it was a typo, it has been changed since 2017.

When bitcoin was first launched, if you wanted to use it you had to run your own node, which was interacted with via the command line. Far too technical for the average user. Now you can simply download an app on your phone and you are good to go.

Using various scripts manually is perhaps too technical for the average use, but that doesn't mean there is no solution to that problem. In fact, the average user can create timelocked transactions right now using Electrum and by simply typing in a block number they don't want the transaction to be spent before in the relevant box in the GUI.

It's actually 4MB.

I don't understand what you mean a computer geek may be capable to do but everything written above doesn't require technical knowledge at all, it's easy. If you talk about implementations that you wish to happen, I think non computer geek will be able to do some of them because of the nature of technologies at the moment.

By the way, bitcoin was not designed for massive global usage. 2017 year made it necessary for bitcoin to come up with a new solution in the form of Lighting Network to handle increased number of transactions. It's block size is very small, 4MB. I think if time comes when bitcoin becomes massive, we will have a need of Fork and some other solutions.

What did I just read?
Wow in bitcoin everything is possible, but one concern is that most of these things are technical such that an average man that is not a computer geek may not be able to understand and implement these things.
This will be a problem in the future when bitcoin hits global adoption because people will have to pay people (it could be centralized platforms) to help them handle these things and which is not the right thing.

You can make transaction offline anytime and broadcast it later, you can always cancel this transaction until you broadcast them. If you don't have internet connection by the time you want to spend 1 BTC to your daughter, it won't be possible for her to receive it.

You shouldn't share your private keys as long as you are alive. And if you die, your bitcoins will be lost because you haven't shared your keys with someone else. Another option to prevent this is, for example, 2/3 multisig wallet but you have to trust these two people. In 2/3 multisig wallet case, if you die but these two persons are alive, they will be able to make a transaction and get funds. In 2/3 multisig wallet, at least two sign is necessary to make a transaction, so, you can always prevent damage from one scammer.

That's not true.
The code for the initial release can be found on github[1] and the script part of the code is almost identical to what we have today. OP codes such as OP_CAT that were removed weren't providing any kind of "transaction execution programming" that you claim. Their removal also had nothing to do with "making network faster" they were removed because they made no sense and were buggy.

[1] https://github.com/Maguines/Bitcoin-v0.1

original bitcoin version had fully working smart contract protocol that allowed transaction execution programming 
although it was not included in newer release, to make network faster
anyways some of the early bitcoin clones and hard forks still have it in place, text me for code examples

Yes I agree! I don't have a daughter actually. I was simply inspired by the OP's thread and it got me very interested, that's why I asked.

There may be, but it's not worth the time and the potential drawbacks. You should rely on your daughter to do this individually, and not to some third party or local computer.

Also, I'd teach her some security basics before handing over anything. Unless she practices software engineering and knows from malicious factors, I'd tell her how to setup an air-gapped computer (or give her hardware wallet instructions for the sake of simplicity), tell her a few obvious things about Bitcoin wallets etc. It'd really be a pity to lose much money, and I'd be responsible for that.

Yeah most probably he/she meant what you said. Do you think there may be a way to broadcast a transaction automatically though? Generally speaking.


Obviously! I did it both in testnet and with real money however Great post btw, I will check it.

No, I don't think he meant that. You can broadcast the signed transaction individually. You make it, set a certain block height as the requirement, sign it, and once the height is such, it can be broadcasted and mined. All this time, the signed transaction can be kept somewhere safely.

Don't test with real money. That's why we have the testnet. Also, read this if you haven't already: https://bitcointalksearch.org/topic/using-locktime-for-inheritance-planning-backups-or-gifts-5180850

So is there an automatic broadcast option? It doesn't really make sense to be able to set it up automatically, considering the technical aspects behind it.

I will try to manually cancel a timelocked transaction following the process you mentioned.

The person receiving the coins.

This is why I said above that after you have created the timelocked transaction, you should give a copy to your heir for safe keeping. This is so they can broadcast it after the timelock has expired. You can also keep a copy yourself, such as in a safe at home or a safe deposit box at a bank or somewhere else your heir will gain access to after you die.

If you are still alive, then before the timelock expires you move one of the inputs in the timelocked transaction to a new address, therefore rendering the timelocked transaction invalid and unable to be used. You then create a new timelocked transaction and give this to your heir. Rinse and repeat.