> - Bitrefill's on-chain payments for gift cards and phone top-ups Bitrefill already supports lightning, so for them it would be easy to solve by displaying the lightning transfer by default and only show the on-chain payment as a fallback. Currently the on-chain payment at Bitrefill and other similar providers is really a drop-down where you select your wallet and then they display a tutorial to you on how to create the on-chain transaction (fee rate, RBF flag, etc). I don't have insights into Bitrefill, but one might suspect that encouraging a lightning payment might be a win-win situation for them and their users.
It would be interesting to know if there are any obstacles that Bitrefill and other services face, or if they don't agree that lightning is an improvement over accepting unconfirmed on-chain transactions from untrusted parties. > - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at least I haven't tried them yet, but I suspect they could benefit in a similar by showing lightning transfers more prominently. Moreover, any UX improvement they can offer to users that intentionally or accidentally selected RBF opt-in, will also benefit users once fullrbf is widespread. To give an example, ATMs could immediately give out a voucher for the cash amount that can be redeemed as soon as the transaction is confirmed on-chain, to allow (untrusted) users to leave the ATM and go for a walk in the meantime. > With full-RBF, wallets should make it extremely clear to users that > unconfirmed > funds are not theirs (yet). Otherwise, protocol-unaware users that are > transacting on-chain with untrusted parties can be easily scammed if they > don't > know they have to wait for a confirmation. Eg. in Argentina, it's pretty > common > to meet someone in person to buy bitcoin P2P for cash, even for newcomers. This is easy to solve, because a wallet can simply display all unconfirmed transactions as if they signalled for RBF. Your suggested solution to "activate" fullrbf at a specific block height might be counter productive, because educating users that unconfirmed transactions are unsafe takes longer than a single block. So the earlier users are educated that unconfirmed transactions from untrusted parties are unsafe, the better. > # Impact at Muun > > Work to transition Muun from using zero-conf submarine swaps to using payment > channels is ongoing, but we are still several months away from being > production > ready. This means we would have to turn off outgoing lightning payments for > +100k monthly active users, which is a good chunk of all users making > non-custodial lightning payments today. It would be unfortunate for those users, but I think that the risk exists today. Relay of fullrbf transactions works reasonable well already, unless you get unlucky with your selected peers. The only missing piece is a few percent of hashrate that will accept fullrbf replacement transactions. While this will certainly happen if a Bitcoin Core release ships with the flag *on* by default, it still may happen at any time even if Bitcoin Core doesn't ship with the flag at all. Best, cndm1 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
