Topic: A smart self-custodial wallet for bitcoin (Read 316 times)

If I've sent transaction A, and I want to cancel subscription, I only have to spend transaction B's coins and invalidate the subscription-tx-chain.

The software needn't to be so intelligent, because even if that would be the case, you wouldn't want from the software to select inputs and create locktime transactions the moment you receive some additional money. You would want it to do that with only coins you approve of. I may not want to use the money a friend owed me to immediately create a transaction paying subscription for an additional month; only when I approve it. So, you could just use a separate account from your derivation path, specifically for subscription-based services.

No problem. Spend the subscription coins if you need them now, but take into consideration that you have to either fill the subscription account (from your wallet) soon or you will get less months automatically paid.

Quick solution: create several transactions paying various fees, each of which comes with a tree of its future transactions. If you wanted to pay a subscription of 12 months, you would create TX A1, TX A2, TX A3 (with low, medium, high fee respectively). Your wallet software will check the mempool at the time of TX broadcasting, and will select which transaction fits best. If A2 is selected, for example, then it does the same for TX B2,1, B2,2, B2,3. Then for C the same, it goes on and on.

You'd need to have signed 3^1 (A-s) + 3^2 (B-s) + 3^3 (C-s) + ... + 3^12 (L-s) = 797160 transactions though. 

Well that's not exactly what I had in mind. You said locktime can be used on the transactions to force a delay of it being included into a block until a particular time, but what if you change your mind and decide not to continue paying for the service?

Example: suppose Twitter Verified (or whatever it's called now) has this futuristic infrastructure you can use to make these kind of bitcoin transactions with, so you make some locktimed transactions, but then mid-way through your subscription, you learn that the site is going to make a change you don't like, so you want to cancel the locktime and get a refund.

Now that I think about it, I guess that the refunds could be effected by moving the funds to one of your other addresses before the locktime expires, thus invalidating the locktime transaction. Doesn't sound like a bad idea after all.

Although another challenge that would be faced with any subscription strategy is where you would like to subscribe for multiple months in advance so that you don't have to remember to make a transaction every month, but you only have funds for let's say 2 months or something. The software would have to be intelligent enough to create more locktime transactions on top of those, when additional funds come, if you want it to allocate the money there.

Third challenge is similar to the second, you have multiple months paid in advance but you have not left any more UTXOs unlocked for you to make other transactions to unrelated stuff, so making any transaction means the entire subscription chain needs to be invalidated and re-constructed. So I guess its as easy to solve as the other challenges.

Fourth challenge and I think this is the most concerning one is, what if you create the subscription chain, and everything is fine except one month later, fees have shot up and your fee is too low to get it confirmed quickly. This will require user intervention to recreate another transaction manually, and to be honest, this is the kind of scenario where users should not have to intervene or do anything to make the subscription "just work". Maybe it can be solved by using higher-than-normal fees by default such as 50 sats/vbyte or maybe even 100 sats/vbyte - dynamically calculated by a decentralized network of servers as basically the "high" feerate x5 is a good setting - but that might be taxing for very small microtransactions.

But in the case of microtransactions I feel as though only Lightning Network is suitable for sending those. Not on-chain.

What's the problem with contacting your merchant and requesting a refund?

That will work, but what if you want to cancel and get a refund?

How about this: locktime. You sign transaction A to be valid in September 19th, transaction B to be valid in October 19th etc. Transaction B uses outputs from transaction A, so A must be already confirmed. All transactions can't be broadcasted at once, unless we've reached the last transaction (Z) and none is broadcasted yet (which couldn't happen either, as the person would report to the merchant that they didn't receive money in September 19th).

For Bitcoin, unless some soft fork allows this kind of behavior in the future, its automation is only possible if you are continuously able to sign and broadcast transactions every period. This requires your wallet password to be available somewhere for the computer to access without your supervision, which is a huge security risk.

The alternative is signing a bunch of future transactions using future, unconfirmed inputs and starting from a single, large enough confirmed input, which has its own set of problems e.g. what happens if they are broadcasted all at once, by accident?

You mean you can't do it automatically? It pretty much sounds plausible to do it manually, and it sounds easy to automate it in a wallet software either.

The problem with making this work with crypto in general is that in fiat, the process is automated but there is a STOP button to halt the monthly payments in case something happens. For example: Employee quits, or salary has to be delayed or advanced by a week, or the invoicing software isn't working and is spitting wrong amounts, or the payment increases or decreases, or the schedule changes.

Smart contracts do not have a STOP button (well in Ethereum they do, it's called selfdestruct() and destroys the entire contract - but not in Bitcoin), so if you need to halt the schedule for any reason, you can't do that currently using any of the available Bitcoin infrastructure.

They may feel similar from a price perspective but with a very weak link. Lost coins will never move whereas idle coins can move at any time and locked coins will move after their locktime expires.

When the specific amount gets locked. Will that gets added to the circulation or it gets to the list of addresses that hold good sum of bitcoin that are idle for long term. Something similar to that of the lost wallets where we don't have control.

We have good number of wallets and most of them were much user friendly. Beyond that, it is the proper education and having a demonstration tab that helps with anyone use the features easy.

People strive to work smarter these days, yet what we truly lack is not "wallet flexibility." Bitcoin software is just awesome, kudos to the developers. Look at some software like Sparrow. It's the best in terms of user-friendliness and features. It lets you import wallets from various sources, gives proper warnings, includes coinjoin option without additional add-on installation, easy mempool access, transactions showed as if you're in a block explorer. It's extremely difficult to make a mistake with Sparrow, if you're keen on using Bitcoin (and have a brain).

And that's just one example. There's Electrum which is even more simple than that. What we need isn't smart software. What we need is informed, educated people. No matter how smart the program is, an uneducated, uninformed user will just mess things up.

Not everything needs to be dumbed down and be grandma friendly. Certain advanced features should require some technical knowledge to minimize user error that can lead to loss of funds. There are already some wallets that have encrypted cloud backups. This is intended to be user friendly but this can result in carelessness by giving users the impression that the cloud is a safe place for storing your seed phrase.

Your math is off, 52704 blocks appear in one year (or so). You could check it yourself 808139-52704=755435, which happened on 24th September last year.

If we set 210000 blocks per four years, then three years would be 157500 blocks. Indeed block 808139-157500=650639 was mined on 2020-09-30.

First of all this feature isn’t a must to use if you don’t want to lose control of that particular funds. It is only recommended when you wish to inherit or gift a certain amount of bitcoin to someone but don’t want it spent till your specified time or probably you yourself don’t want to spend it till that time, other than that there is no need to use the feature.

Talking about a reputable wallet to use aside the coinb.in then bitcoin core and electrum will be better, since both of the wallets have proven to be the most reliable and trustworthy ones out there.

First thing is to create an address that would recieve the transaction and keep its keys or seeds save and then initiate the transaction.

On using electrum you need to specify the block height. You look at the current block and calculate it to the date you want like maybe 3 years from now. With like 808139 block already mined you need to add to the number of blocks to be confirmed in that 3 years. It is reported that 144 blocks is mined a day with an average Time of 10 minutes (although this can vary due to the time of mining blocks which differs). So for three years now with approximately 366 days then the block need for 3 years will be 52704 by 3=158112 blocks. 808139+158112=966251

Set the time lock to 966251 for lock time of 3 years from now.

I don't know if it's just a typo or if you use the wrong names for some things, but before you publish a post, I would recommend you to use the "preview" button and check the content of the post

As for the whole idea of wallets becoming friendly even for grandmothers, I think we have to be realistic with the fact that Bitcoin will be used mostly by people who have a solid level of education and are interested in new technologies. All these stories about mass adaptation are for me just one big fantasy that has little to do with reality, although some persistently push it as something that must happen at any cost.

In addition, the whole idea of the already famous Ledger recovery project was allegedly born from the fact that some geniuses within the company thought that this would bring "crypto" closer to their mothers and grandmothers.


If by some chance we manage to simplify Bitcoin to the point where it's as easy as using a bank card at an ATM, I'll just ask question - would that mean the average Joe would start using Bitcoin because of it? I am of the opinion that the reason why so few people use Bitcoin is not that it is too complicated, but that the general attitude promoted by the media is still negative, and people still believe in what they fill their brains with all the time.

You have mentioned some good topics, but after doing some research, I found out that this should not be practiced or our first priority to lock funds for like 5o r 10 years. specifically with this coinb.in website. You should read the following theads:
1:
2:

---

You have shared some best topics to read about time-lock and thanks for them as I was unaware of these topics. Plus I think, what Op is asking here is to use some application that can do this work (of course a wallet app). And of course that should be open-source and etc. etc.

I have one question (as newbie) why we will trust those new smart apps and why we even trust this coinb.in website as what metrices make them our first priority. To be honest I little afraid to lock my BTC for like 5 or 10 years. And I hope only inheritance related cases needed these types of functions. And I also doubt if anyone really have used these feature provided by any of the platform for inheritance purposes.

If not, then I think currently the market for such apps will be less as their are less people (young people) who are not married and not looking for solutions like these ( of locking transactions for 10 years). But if some smart wallet comes now and by time that wallet will get some decent trust by the Legendries.

I think they already have this kind of features in bitcoin. It's called signed transaction. Basically It's a kind of transaction which have a lock period. This kind of transaction is only valid after a certain amount of time. You can check the post below from LoyceV about this.

A decade is 10 years, bitcoin has been around for 14 #nitpicking

I agree with the general idea in your post.
Some of your cases could be summarized as a wallet that has a user friendly way of working with Bitcoin scripts. Maybe have at least a dozen different pre-defined scripts that the user can just fill in the blanks to set up. Like the case with locking coins where all it needs is a timespan, the rest like the key to send the coins to is set by the wallet behind the scene.

Technically they should "log in" as companies do this normally, maybe someone was fired or new employee came along. There is also changes in price that changes the payment in BTC and things like overtime, etc.

Whether a transaction is mined or not is not up to the wallet/receiver. What the wallet can do is to filter out unwanted transactions like dust spams.

I'd say if writing down a set of words on paper is hard for someone then maybe bitcoin is not suitable for them.

Coinb.in support time lock. There are also other wallets that supports it. On desktop Electrum, you can use time lock with the normal time we use or the Unix time, you can also use block height. I think I saw time lock on Sparrow as well. If need be, I will check it anytime I am with my laptop.

@DVlog
For you other questions.
If you need a wallet that can pay workers salary the way you have just posted about it, you can get a developer to create you a bot that can do that. That is not the work of bitcoin developers if they decided not to something like that.

Your second question, about seed phrase backup. It is the simplest thing to do. I expect no one to complain about it.

This has been simplified by transaction time lock you can read how to set up using this method by TryNinja




LoyceV has dedicated thread for using time lock for inheritance purposes you can read through the thread here  https://bitcointalksearch.org/topic/using-locktime-for-inheritance-planning-backups-or-gifts-5180850 on how to back it up properly and also to redeem it