Thank you. With regards to version, I was definitely aiming at and implementing version 1.4 of the server API,
and that is what I give back to Electrum wallet when it asks for version.

Have a constant in code:
val SERVER_VERSION           = "1.4"

Some APIs from 1.4 specs may be missing as they are also missing in the original EPS implementation.
As for Wallet version which I used for testing, I used 3.3.8, I was planning to test with 4.x but didn't get around to do it.
Also, I used Bitcoin Core 0.20.0.

Hi,
I developed code for a Scala version of Chris Belcher's Electrum Personal Server (which is originally written in Python).

The project may be useful in the following ways:
- you are curious how Electrum Personal Server (EPS) works but it is easier for you to read Scala than Python
- you want to develop your own version of EPS but you prefer Scala

The project is mature enough so that I could run Electrum against it and perform transactions, yet it is not
hardened yet, and usability details are missing, so I treat it as advanced but still WIP.
It does not support TOR, and is based on (now) bit older EPS 0.2.1 (June 2020).

I won't work on it at the moment so I thought that if anyone is interested, she or he could take over and continue.

Project has a lot of tests, and there is some word documentation (WIP).

Having EPS which works and runs on top of your own node gives you privacy you can't get from public Electrum servers.

Repo address is: https://github.com/miloszm/epsmi
Repo of the original Chris Belcher's code is: https://github.com/chris-belcher/electrum-personal-server

Thank you
-- MM

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..

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.

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..

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

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.

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).

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