191 sats \ 0 replies \ @Radentor 16h \ on: How to use Zeus LN node to migrate or disaster recovery bitcoin
Bro cooking we learningπ£οΈπ£οΈπ£οΈπ₯π₯π₯
So if you receive money on lightning and send it on-chain, they close a channel each time?
Loop out : no (preferred method to maintain channel)
Splicing : resizing (making it bigger or smaller)
Close : total sweep (avoid if possible)
How does a non-custodial lightning wallet work?
User owns a seed (BIP39 or Aezeed), this key is needed to spend the sats on LN. This key can also spend to onchain with following conditions :
- Loop out (swap LN to Onchain)
- Splice out (partially spend the underlying funding tx)
- Close channel (sweep all LN sats back to Onchain)
The main question is, if you don't manage the channel how are you connected to it and
Green Wallet : user can't manually manage the channel but can open & resize (only up) his/her channel
Phoenix : user can only open & close the channel against ACINQ. Channel openning are triggered whenever :
- User first time received Onchain sats
- User
Channel resize (splicing) are triggered whenever :
- User spends to Onchain
- User receive Onchain sats
Those are just few (simplified) examples, other automated wallets have different model of channel management
remain with full ownership of the funds.
TLDR : LN IS NOT FULLY TRUSTLESS
If no watchtower is used (which is almost expected today) you are effectively trusting your channel counterparty (LSP or random pleb) not to steal your sats by publishing malicious SCB. If the victim did not came back online in time to broadcast justice tx against this fraudulent close then, poof, sats gone forever
But this scenario can be prevented by using the wallet every day (at worst every 5 day?)
Deployed #527608
Yes, there are many techniques to increase Onchain privacy
Already there :
- PayNym
- Payjoin
- CoinJoin
- Ricochet
- Stonewall
- StonewallX2
- Stowaway
- Taproot (key aggregation)
Proposal/still concept :
- Stealth address
- Whisper address
- CoinSwap
- Silent payment
Degree | Type | Possible Spender | Authorizer |
---|---|---|---|
βοΈποΈ | Cosign n-of-n | User + Server | All |
βοΈπ | Cosign m-of-n | User or User + Server | User or Both |
βοΈποΈ | Multi Sig | User | User |
βοΈπ | Single Sig | User | User |
β‘π | Custodial | Custodian & User | Custodian |
β‘βοΈ | Cloud | Server Host & User | Cloud Server |
β‘π | Single Sig | User | User |
π§ποΈ | Cosign n-of-n | User + Server | All |
π§π | Single Sig | User | User |
πΏπ | Federated | LGP & User | LGP |
π₯π | Custodial | Mint & User | Mint |
Variant | Who Can Spend the Underlying Collateral ? |
---|---|
β‘ | User + Channel Counterparty 2-of-2 ποΈ (Splicing) |
β‘ | User or Channel Counterparty π (Channel close) |
π§ | 11-of-15 Liquid Federation Member |
π₯ | The Mint |
πΏ | The Lightning Gateway Provider |
πͺ | User, After The Timelock Expired |
π’ | A : User (after 24h) or User + ASP or ASP (after 4w) |
π’ | B : User (after 365d) or User + ASP |
What you're looking for is what i referred as "cosign n-of-n" (or just call it collaborative assisted wallet)
So, my conclusion is that this assisted wallet can't be categorized as "non-custodial" or "self-custodial".
I agree with this
Is there any difference between "non-custodial" or "self-custodial"?
Non-custodial : only 1 signature is needed to spend
Custodial : someone else can spend at will but hopefully they don't
Since the assisted wallet in this case cannot be considered "custodial" (as the provider cannot move the funds without the owner's permission), how should it be categorized?
My suggestion would be to actually call a wallet as specific as possible based on it's spending requirement.
For Onchain :
- Cosign n-of-n
- Cosign m-of-n
- Multisig
- Singlesig
LN :
- Custodial
- Cloud
- Singlesig
Liquid :
- Cosign n-of-n
- Singlesig
Fedimint : Federated
Cashu : Custodial
I made a complete (hopefully also correct) list of wallets with varying degree of custodianship here
- V4V or paid services (LSP, CoinJoin, P2P Coordinator, etc).
- Buy their products (HWW, Opendime, etc).
- Direct zaps > OpenSats, HRF
Took me longer than expected to write a post, it started out small until suddenly it's getting too complicated. Eventually i redo it from the beginning and split the post to several smaller scale posts
Probably this channel ? It has Video about Bitcoin & Video about mining
Informative reply indeed, thanks @DarthCoinπ«‘
Putting my post here since nobody replied with answer
Hey y'all, i'm currently learning on how to craft Onchain tx as efficient as possible while still getting my transaction confirmed (preferably in <10 minutes).I concluded that :
- Personally, P2TR address is the best address to use.
- Knowing the exact tx size before deciding feerate matters a lot.
- If i know the exact size, i can guess the best feerate by looking at several previously confirmed block.
- For several reasons, i can't avoid small UTXOs.
- Having as many inputs as possible per tx is better (as long as i can postpone Onchain spending)
I think i got the basics right, but some advanced questions like :
- Does transaction fee counted as output ?
- How does Onchain wallet determine the destination address type for change output ? (Specifically on Blixt, Zeus, Samourai & Green)
- What is the biggest amount of input or output possible in a single transaction ?
I can't seem to find answer anywhere and would be thankful to have my questions answered by others here. Suggestions (not LN) are also appreciated
so itβs prudent not to use this custodial wallet
It's 2-of-2 multisig wallet under the hood tho
Such an honorable mention, thanks @grayruby