<<  >> (p.5)
    Author Topic: Using Locktime for inheritance planning, backups or gifts  (Read 3507 times)
    This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic. (11 posts by 1+ user deleted.)

    • LoyceV (OP)
    Legendary
    *
    Offline Offline

    Activity: 3864
    Merit: 20458


    Thick-Skinned Gang Leader and Golden Feather 2021


    View Profile WWW
    May 01, 2025, 05:41:00 AM
    Merited by JayJuanGee (1)
     #61
    Quote from: Etiquette.exe on May 01, 2025, 04:00:50 AM
    When I choose a LockTime that is in five years from now and I sign the transaction and broadcast it right now, it gets rejected and I have to do it again in five years?
    Yes. Bitcoin nodes aren't going to keep your transaction for 5 years.

    Quote
    The goal is to predefine a transaction and in case I get hit by a bus in four years from now, will my transaction still be facilitated at the set date?  Because if I still have to take action again, how am I safe from the hit by a bus issue?
    You'll need to find someone to broadcast your transaction, or setup a server that keeps running all those years and does it for you.
    This is probably something you should discuss with whoever you're sending your funds to. If they have your signed transaction, they can broadcast it. But: that also means they know which addresses you're sending from, and how much money they get when they kill you you die.

    Quote
    I thought I can sign it now, broadcast it now and if I don't spend the UTXO before that set date, it will be processed.
    Nope. It needs to be broadcasted when it's valid.
    I've been thinking of setting up a service for doing this, but that moves the bus-risk to me so there's no point.
    You could pay someone to do it: create a LockTime transaction that sends a tiny fraction of your fortune to the address of the person who's going to broadcast it. You could even create different transactions that pay to different people: first one to broadcast your transaction, get their payment. That encourages people to keep their word, but there's never a guarantee. Just like what happens if the receiver of your money is in the same bus with  you.
    ¡uʍop ǝpᴉsdn pɐǝɥ ɹnoʎ ɥʇᴉʍ ʎuunɟ ʞool no⅄

  • Etiquette.exe
    Jr. Member
    *
    Offline Offline

    Activity: 54
    Merit: 52


    View Profile
    May 01, 2025, 11:16:30 AM
    Merited by JayJuanGee (1)
     #62
    Ok this makes sense now. I thought this LockTime option is much more flexible than that, but technically I think I now understand where the bottleneck is.

    I read that transactions remain in the mempool for 14 days typically. Does this mean that I could sign and broadcast transaction that has a set execution date within this timeframe or as hosemary said, nodes will instantly reject any transaction that has a set date in the future?

    What size does a mempool have? It says that every node maintains its own mempool and my I idea now is that these mempools could be flooded with countless future transactions if they were not to reject transactions with dates set to be executed in the future. Can node setups be chosen individually by every node provider and would it in theory be possible for someone to run a node that accepts future transactions into its own mempool?

    I thought normally a node would be able to have LockTime as one rule in place to order its priority list. Like IF current time => LockTime AND fee (LockTime UTXO) => min threshold for execution, then execute.

    But when I now do some calculations, I found that the most common transactions are around 0.25 KB. That is four transactions per 1 KB. 4,000 transactions per 1 MB. 4,000,000 transactions per 1 GB. I think this shows that the mempool would get clogged if millions of people around the world would broadcast transactions supposed to be executed in the future. 4,000,000 transactions sounds a lot, but if more and more people used the function, it would inevitably lead to chaos if several GB of future transactions would have to be queued?

    If I missed something or got something wrong, please correct LoyceV, thank you!
    Chris

  • LoyceV (OP)
    Legendary
    *
    Offline Offline

    Activity: 3864
    Merit: 20458


    Thick-Skinned Gang Leader and Golden Feather 2021


    View Profile WWW
    May 02, 2025, 08:37:03 AM
     #63
    Quote from: Etiquette.exe on May 01, 2025, 11:16:30 AM
    I read that transactions remain in the mempool for 14 days typically.
    This can vary per node, and when fees go up, transactions with low fee are dropped first. But on the other hand, it is still possible for anyone to keep your transaction much longer, and broadcast it later. As long as the inputs exist, once broadcasted there's always a chance that it gets confirmed.

    Quote
    Does this mean that I could sign and broadcast transaction that has a set execution date within this timeframe or as hosemary said, nodes will instantly reject any transaction that has a set date in the future?
    As far as I know: yes.

    Quote
    What size does a mempool have?
    The default is 300 MB, but it can really be anything.

    Quote
    would it in theory be possible for someone to run a node that accepts future transactions into its own mempool?
    I'm no expert on Bitcoin Core, but I don't think this is possible. Mempool is for transactions that are currently valid.

    Quote
    I thought normally a node would be able to have LockTime as one rule in place to order its priority list. Like IF current time => LockTime AND fee (LockTime UTXO) => min threshold for execution, then execute.
    You're looking for a solution for something that isn't a problem. Bitcoin Core nodes do only the basics, anything that can be built on top of that, isn't included in Bitcoin Core. So you can have an external service broadcast your transaction when it's valid.
    ¡uʍop ǝpᴉsdn pɐǝɥ ɹnoʎ ɥʇᴉʍ ʎuunɟ ʞool no⅄
    Pages: « 1 2 3 [4]  All
      Print  
Page 4
Viewing Page: 5

IRLBTC™ © 2025 IRLBTC.com