{"type":"rich","version":"1.0","author_name":"npub1w30zwgl8947760cd62fawy9hqmxnq24cga5c8s5j6j7m07w96dnqzjzhn2","author_url":"https://nostr.ae/npub1w30zwgl8947760cd62fawy9hqmxnq24cga5c8s5j6j7m07w96dnqzjzhn2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-13\n📝 Original message:Hi cndm1,\n\n\u003e Bitrefill already supports lightning, so for them it would be easy to\n\u003e solve by displaying the lightning transfer by default and only show\n\u003e the on-chain payment as a fallback. Currently the on-chain payment at\n\u003e Bitrefill and other similar providers is really a drop-down where you\n\u003e select your wallet and then they display a tutorial to you on how to\n\u003e create the on-chain transaction (fee rate, RBF flag, etc). I don't\n\u003e have insights into Bitrefill, but one might suspect that encouraging a\n\u003e lightning payment might be a win-win situation for them and their\n\u003e users.\n\nLightning is only used for 4% payments compared to 32% on-chain payments according to a [tweet][1] from Jan 2022 by Sergej Kotliar and stats are similar based on the slides shared in a [presentation][2] in Pizza Day Prague 2022.\n\nBy EUR:\n\nonchain - 30%\nlightning - 5%\n\nBy unique users:\n\nonchain - 40%\nlightning - 9%\n\n\u003e Relay of fullrbf transactions works reasonable well\n\u003e already, unless you get unlucky with your selected peers. The only\n\u003e missing piece is a few percent of hashrate that will accept fullrbf\n\u003e replacement transactions. \n\nI don't believe relay of fullrbf transactions works well right now. The missing piece you mentioned is important and a real need for all full node users to try fullrbf.\n\n\u003e While this will certainly happen if a\n\u003e Bitcoin Core release ships with the flag on by default, it still may\n\u003e happen at any time even if Bitcoin Core doesn't ship with the flag at\n\u003e all.\n\nChanging default at this moment does not make sense as v24.0 could give some insights about usage of fullrbf and we could wait for a few months before changing default for users that run latest version of bitcoin core.\n\nI will quote Antoine Riard's comment from PR [#25353][3]:\n\n\"_I know I've advocated in the past to turn RBF support by default in the past. Though after gathering a lot of feedbacks, this approach of offering the policy flexiblity to the interested users only and favoring a full-rbf gradual deployment sounds better to me. As a follow-up, if we add p2p logic to connect to few \"full-rbf\" service-bit signaling peers and recommend to the ~17000 LN nodes operators, likely (hopefully!) running bitcoind as a backend, that should be okay to guarantee a good propagation to miners (and yes reaching out to few mining pools ops to explain the income increase brought by full-rbf). Unless we observe a significant impact on compact blocks reconstruction, personally I'm really fine waiting another multi-years development cycle before to propose a default change, or even let opt-in forever the default as it is._\"\n\n\"_Once again, the proposed change is only targeting educated users aiming to deploy full RBF for their application specific needs. If the majority of Bitcoin users is not interested, that's okay. It's a policy rule, not a consensus one._\"\n\nAlthough Antoine has opened another [pull request][4] to make fullrbf default a few hours ago, so I am not sure what is the new motivation or discussion that I am missing.\n\n[1]: https://twitter.com/ziggamon/status/1481307334068641795\n[2]: https://youtu.be/bkjEcSmZKfc?t=463\n[3]: https://github.com/bitcoin/bitcoin/pull/25353\n[4]: https://github.com/bitcoin/bitcoin/pull/26305\n\n/dev/fd0\n\nSent with Proton Mail secure email.\n\n------- Original Message -------\nOn Thursday, October 13th, 2022 at 9:37 PM, linuxfoundation.cndm1--- via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\n\u003e \u003e - Bitrefill's on-chain payments for gift cards and phone top-ups\n\u003e \n\u003e \n\u003e Bitrefill already supports lightning, so for them it would be easy to\n\u003e solve by displaying the lightning transfer by default and only show\n\u003e the on-chain payment as a fallback. Currently the on-chain payment at\n\u003e Bitrefill and other similar providers is really a drop-down where you\n\u003e select your wallet and then they display a tutorial to you on how to\n\u003e create the on-chain transaction (fee rate, RBF flag, etc). I don't\n\u003e have insights into Bitrefill, but one might suspect that encouraging a\n\u003e lightning payment might be a win-win situation for them and their\n\u003e users.\n\u003e \n\u003e It would be interesting to know if there are any obstacles that\n\u003e Bitrefill and other services face, or if they don't agree that\n\u003e lightning is an improvement over accepting unconfirmed on-chain\n\u003e transactions from untrusted parties.\n\u003e \n\u003e \u003e - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at least\n\u003e \n\u003e \n\u003e I haven't tried them yet, but I suspect they could benefit in a\n\u003e similar by showing lightning transfers more prominently. Moreover, any\n\u003e UX improvement they can offer to users that intentionally or\n\u003e accidentally selected RBF opt-in, will also benefit users once fullrbf\n\u003e is widespread. To give an example, ATMs could immediately give out a\n\u003e voucher for the cash amount that can be redeemed as soon as the\n\u003e transaction is confirmed on-chain, to allow (untrusted) users to leave\n\u003e the ATM and go for a walk in the meantime.\n\u003e \n\u003e \u003e With full-RBF, wallets should make it extremely clear to users that unconfirmed\n\u003e \u003e funds are not theirs (yet). Otherwise, protocol-unaware users that are\n\u003e \u003e transacting on-chain with untrusted parties can be easily scammed if they don't\n\u003e \u003e know they have to wait for a confirmation. Eg. in Argentina, it's pretty common\n\u003e \u003e to meet someone in person to buy bitcoin P2P for cash, even for newcomers.\n\u003e \n\u003e \n\u003e This is easy to solve, because a wallet can simply display all\n\u003e unconfirmed transactions as if they signalled for RBF. Your suggested\n\u003e solution to \"activate\" fullrbf at a specific block height might be\n\u003e counter productive, because educating users that unconfirmed\n\u003e transactions are unsafe takes longer than a single block. So the\n\u003e earlier users are educated that unconfirmed transactions from\n\u003e untrusted parties are unsafe, the better.\n\u003e \n\u003e \u003e # Impact at Muun\n\u003e \u003e \n\u003e \u003e Work to transition Muun from using zero-conf submarine swaps to using payment\n\u003e \u003e channels is ongoing, but we are still several months away from being production\n\u003e \u003e ready. This means we would have to turn off outgoing lightning payments for\n\u003e \u003e +100k monthly active users, which is a good chunk of all users making\n\u003e \u003e non-custodial lightning payments today.\n\u003e \n\u003e \n\u003e It would be unfortunate for those users, but I think that the risk\n\u003e exists today. Relay of fullrbf transactions works reasonable well\n\u003e already, unless you get unlucky with your selected peers. The only\n\u003e missing piece is a few percent of hashrate that will accept fullrbf\n\u003e replacement transactions. While this will certainly happen if a\n\u003e Bitcoin Core release ships with the flag on by default, it still may\n\u003e happen at any time even if Bitcoin Core doesn't ship with the flag at\n\u003e all.\n\u003e \n\u003e Best,\n\u003e cndm1\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"}