Electrum's right-click freeze only excludes a given address from wallet's spending, funds from this address, if frozen, won't be used by the wallet when it searches for funds for payments.
This is a wallet function only, it does not actually freeze funds from this address on blockchain.
coinb.in does the actual blockchain freezing, only it is a bit harder to use - but this is just an opinion so may be subjective..
Topic: looking for advice/mentoring - wallet focusing on time-lock (Read 158 times)
Thanks for the hint with "advanced preview", still, this does not freeze bitcoin, it only post-dates the transaction.
Simple right click on Electrum wallet address can freeze or unfreeze any bitcoin address, that is not exactly the same as in your project but I don't find it very useful.I am not sure how much this is similar to your project but I also saw a video by Valentino Zertuche who created time locked addresses with coinb.in website, and coins would be unspendable until a set date and time has passed.
He used Electrum wallet public key in combination with coinb.in website:
https://www.youtube.com/watch?v=xXGuDkmEicM
I guess "raw" format in Electrum's LockTime can be used for entering Unix Epoch timestamp in a numeric form, as a long number, or to verify, which Epoch timestamp resulted from entering the date/time.
"raw" format does not help much with block height, but for date/time it can be useful.
Thanks for the hint with "advanced preview", still, this does not freeze bitcoin, it only post-dates the transaction.
"raw" format does not help much with block height, but for date/time it can be useful.
Thanks for the hint with "advanced preview", still, this does not freeze bitcoin, it only post-dates the transaction.
To be honest, I don't see much benefit in setting nLocktime just to send transaction later, other than to guarantee that it can't be sent earlier.
But for offline scenarios this is not needed.
My understanding is that CLTV method of freezing is agnostic to what addresses are used, only my particular implementation is limited, which I'd like to improve ASAP..
But for offline scenarios this is not needed.
My understanding is that CLTV method of freezing is agnostic to what addresses are used, only my particular implementation is limited, which I'd like to improve ASAP..
I looked at trezor suite, it does not seem like it supports actual time-locking of bitcoin.
It only allows post-dating transactions so that it is guaranteed that they won't be mined (or broadcast) until later date/time (or block height).
Yes, Trezor is not freezing any coins, it's like if I wanted to send you 1 bitcoin tomorrow but I can't have access to my wallet or internet, I will send it now with their Locktime option and it should be sent tomorrow at specific block or time.It only allows post-dating transactions so that it is guaranteed that they won't be mined (or broadcast) until later date/time (or block height).
I think that Taproot scripting will improve a lot what you want to do, and I find it very limiting in your approach of using old legacy addresses only.
I checked those Trezor wiki pages but it is related to their old web wallet, here is Trezor blog post describing same Locktime feature in Trezor Suite:
https://blog.trezor.io/trezor-suite-privacy-made-easy-f73771fb2037
I looked at trezor suite, it does not seem like it supports actual time-locking of bitcoin.
It only allows post-dating transactions so that it is guaranteed that they won't be mined (or broadcast) until later date/time (or block height).
Actual time locking involves transaction which sends funds into a P2SH address that can only be unlocked in the future.
Time-locking transaction in a sense of freezing funds is not postdated. It could be as any transaction can be, but it is not postdating that does the freezing.
Only the time-unlocking transaction is "by definition" postdated,
as the CLTV operation (which does the actual freezing) compares its time-lock with transaction's time-lock, and does not allow outputs to be spent
before the transaction's time-lock. CLTV also requires that both transaction's time-lock and it's operand time-lock are of the same type,
either both timestamps (above 500 million) or both block-heights (below 500 million).
What trezor suite does is: it "sets the earliest time a transaction can be mined into a block", but it is a "normal" transaction,
not a transaction whose output is frozen (i.e. its output is P2SH whose pre-image is a script which contains CLTV operation).
Pls. see: https://wiki.trezor.io/Locktime and https://wiki.trezor.io/User_manual:Using_locktime
It only allows post-dating transactions so that it is guaranteed that they won't be mined (or broadcast) until later date/time (or block height).
Actual time locking involves transaction which sends funds into a P2SH address that can only be unlocked in the future.
Time-locking transaction in a sense of freezing funds is not postdated. It could be as any transaction can be, but it is not postdating that does the freezing.
Only the time-unlocking transaction is "by definition" postdated,
as the CLTV operation (which does the actual freezing) compares its time-lock with transaction's time-lock, and does not allow outputs to be spent
before the transaction's time-lock. CLTV also requires that both transaction's time-lock and it's operand time-lock are of the same type,
either both timestamps (above 500 million) or both block-heights (below 500 million).
What trezor suite does is: it "sets the earliest time a transaction can be mined into a block", but it is a "normal" transaction,
not a transaction whose output is frozen (i.e. its output is P2SH whose pre-image is a script which contains CLTV operation).
Pls. see: https://wiki.trezor.io/Locktime and https://wiki.trezor.io/User_manual:Using_locktime
Thank you - I will look at Electrum plugins and will ask/make suggestion - issue is that my code is in C++ and Electrum plugins (probably still) need to be in Python.
That was the original reason I didn't go for a plugin implementation, as I wanted to stick to C++ as I used the libbitcoin library.
I didn't know that Trezor is supporting time locking transactions. This is very interesting, I need to try it out, thanks for this suggestion.
That was the original reason I didn't go for a plugin implementation, as I wanted to stick to C++ as I used the libbitcoin library.
I didn't know that Trezor is supporting time locking transactions. This is very interesting, I need to try it out, thanks for this suggestion.
This is cool feature to have in bitcoin wallet, and maybe you should consider making extension for Electrum or suggesting change in their github code so they can integrate it directly on their wallet (if possible).
There is no limitations for address type and Trezor Suite software is supporting this and it'is very easy to enable Locktime in settings and enter block height or time in unix timestamp format.
https://suite.trezor.io/
I am aware of the shortcomings, the biggest is that the wallet and library support legacy addresses only, the other is that there is only one way to create wallet - via seed.
I didn't test this feature myself but I think that time locking transactions also exist in Trezor hardware wallet and this is a nice way to detach IP from your address and send coins on specific time or block height.There is no limitations for address type and Trezor Suite software is supporting this and it'is very easy to enable Locktime in settings and enter block height or time in unix timestamp format.
https://suite.trezor.io/
Thank you for your feedback.
Bitcoin time-lock/unlock (both CLTV and transaction lock-time) works with both - either absolute time or block height.
If time-lock value is above 500 million, it is interpreted as Epoch time, otherwise as block height.
Currently, in the wallet, only absolute time is used, although it would be easy to add block height option as well.
I agree that coinb.in is not so friendly, especially from the point of view of bitcoin newbie.
Time-locking can be done manually, using for example bx tools from libbitcoin, but it is easy to make mistakes.
Also, storing data (or unlocking transaction) until unlock time for many years is problematic (at least for your confidence IMO),
so I was happy to have a method that requires only to remember lock date/time and nothing else
(as long as you can point your locking transaction in the wallet's history view).
Bitcoin time-lock/unlock (both CLTV and transaction lock-time) works with both - either absolute time or block height.
If time-lock value is above 500 million, it is interpreted as Epoch time, otherwise as block height.
Currently, in the wallet, only absolute time is used, although it would be easy to add block height option as well.
I agree that coinb.in is not so friendly, especially from the point of view of bitcoin newbie.
Time-locking can be done manually, using for example bx tools from libbitcoin, but it is easy to make mistakes.
Also, storing data (or unlocking transaction) until unlock time for many years is problematic (at least for your confidence IMO),
so I was happy to have a method that requires only to remember lock date/time and nothing else
(as long as you can point your locking transaction in the wallet's history view).
What is the way of bitcoin time-lock and unlock? Is it related to a specific time? A specific block or what?
Personally, AFAIK only coinb.in support time-lock feature and some other Core based solutions, which may not seem convenient, so getting a wallet that supports this feature will be exciting.
It is better to focus on several additional things rather than just this feature.
Personally, AFAIK only coinb.in support time-lock feature and some other Core based solutions, which may not seem convenient, so getting a wallet that supports this feature will be exciting.
It is better to focus on several additional things rather than just this feature.
Hi,
I created a C++ library focusing on bitcoin time-lock (also providing generic wallet operations), a set of command line utilities and a UI wallet on top of that library.
My goal was to make bitcoin time-lock and unlock so simple, that it can be done confidently by anyone, and that relatively large sum can be entrusted to it.
Also, I wanted to minimise and simplify data that needs to be stored or remembered between locking and unlocking (as the time between lock and unlock could be years).
The wallet uses Electrum server API and internally uses libbitcoin library.
All the info can be found in github repositories and youtube description.
The wallet can be seen in a youtube video: https://www.youtube.com/watch?v=eBqC2IIbnQA
The library is at: https://github.com/miloszm/binglib
Set of command line utilities is at: https://github.com/miloszm/bingdiyi
I am aware of the shortcomings, the biggest is that the wallet and library support legacy addresses only, the other is that there is only one way to create wallet - via seed.
My question is, could you advise, would there be interest in such a wallet? It does the job for me, but what could be the steps to make it public in a responsible way, if at all?
Thank you for any advice or feedback,
-MM
I created a C++ library focusing on bitcoin time-lock (also providing generic wallet operations), a set of command line utilities and a UI wallet on top of that library.
My goal was to make bitcoin time-lock and unlock so simple, that it can be done confidently by anyone, and that relatively large sum can be entrusted to it.
Also, I wanted to minimise and simplify data that needs to be stored or remembered between locking and unlocking (as the time between lock and unlock could be years).
The wallet uses Electrum server API and internally uses libbitcoin library.
All the info can be found in github repositories and youtube description.
The wallet can be seen in a youtube video: https://www.youtube.com/watch?v=eBqC2IIbnQA
The library is at: https://github.com/miloszm/binglib
Set of command line utilities is at: https://github.com/miloszm/bingdiyi
I am aware of the shortcomings, the biggest is that the wallet and library support legacy addresses only, the other is that there is only one way to create wallet - via seed.
My question is, could you advise, would there be interest in such a wallet? It does the job for me, but what could be the steps to make it public in a responsible way, if at all?
Thank you for any advice or feedback,
-MM
Jump to: