Thread | Plain Text Nostr

thread · root a40b674e…89c1 · depth 3 · · selected 911e391e…f96a

thread

root a40b674e…89c1 · depth 3 · · selected 911e391e…f96a

4f4f82846698 -- 212d

I’m really stoked about new nostr:npub1cvqlzvmjercdn0ypsmv8f7j9lge6ahsnueh5rparh53wuswftv4q49yjt3 Walletenabling core miniscript functionality.I have one important suggestion regarding UI that will go a long way to assist users with restoring from backup:wallet identifier should be visible from within the application. I can see the wallet id if I email myself acopy of the descriptor, but as best I can tell it’s not in the app.You have to assume there will be users who do a decaying or expanding multisig and all they have are the 3 seedphrases, time info, and m of n for each time segment but not the descriptor…it take surprisingly little info torestore such a wallet, far far less data than a descriptor contains…

4f4f82846698 -- 212d

I would also put keys in “numerical” order before putting them in a miniscript and making a wallet. Having onlyone order keys can be loaded reduces number of variables for restoring wallet with imperfect descriptor info.But as it is now, if I change the order of the 3 of 3 on my decaying multisig I get a different wallet ID.

nunchuk_io -- 210d

Right, Miniscript currently doesn’t support sortedmulti descriptor.

4f4f82846698 -- 212d [parent] 
|    I would also put keys in “numerical” order before putting them in a miniscript and making a wallet. Having only
|    one order keys can be loaded reduces number of variables for restoring wallet with imperfect descriptor info.
|    But as it is now, if I change the order of the 3 of 3 on my decaying multisig I get a different wallet ID.
|    reply [1 reply]

nunchuk_io -- 210d
Right, Miniscript currently doesn’t support sortedmulti descriptor.
reply [1 reply]

idsera -- 210d [parent] 
     Hi nostr:npub1cvqlzvmjercdn0ypsmv8f7j9lge6ahsnueh5rparh53wuswftv4q49yjt3, something like this is possible on
     Bitcoin? Thanks
     
     A smart contract feature I'd like to see in Bitcoin:
     
     People would agree to lock up any amount of Bitcoins for a specific period, for example, 5 years. If someone in
     the group decides to redeem before the 5-year period, it would be possible, but to do so, they would have to
     pay, for example, 10% of the amount they deposited to everyone else in the group who are still following the
     5-year contract term.
     
     This would allow us to determine who truly has skin in the game and who would be holding Bitcoin for the long
     term. It would also reduce the supply of Bitcoins in the market, forcing a potential appreciation.
     reply