Topic: Full RBF - page 6. (Read 3080 times)

If my old man memory is correct they used to give you a bit more. Not a lot more but a bit. Could have been fold, really not sure but I do remember getting a better discount someplace when using lightning for giftcards.

What they COULD do is keep smaller lightning channels open to them. I have opened a few and they auto close them after a while even while being balanced with a decent amount. Don't know why, and finally gave up caring sometime over the summer. Just stopped trying.

Back OT, did spend some time reading since my last post. I still think we should wait, but I do see the other sides view a bit more.

Beating a dead horse, it's going to happen.....

-Dave

Right. I'm buying gift cards frequently from that place.  

Ouch! People, justifiably, don't use lightning often yet. Either because it's responsibly tough to run your own lightning node, or because just using bitcoin without custodians is already too confident for the average Joe to make him get involved further.

They need to understand they can't have that unconfirmed option forever though. To increase that 15% they could provide greater rewards for purchases with lightning.

---

---

Edit:

It's reasonable to assume that such attacker is a miner.

They already support Lightning. But as per their CEO's post here, Lightning transactions only make up around 15% of their business, while zero confirmation transactions make up 60%. This is a huge disparity. It's not enough to simply say "Use Lightning", when probably the majority of those 60% either have no experience with Lightning or aren't even holding their own coins at all.

Yes, but that doesn't matter if the miner in question is running their own node(s) which have full RBF disabled. Their nodes will reject such a transaction, and so the miner won't include it.

Yes, indeed. I was referring to smaller businesses, which are more in number. Bitrefill, as a successful business, ought to switch to lightning.

More nodes that have Full RBF means more chances for everyone to establish connection with nodes that have Full RBF. Therefore, more chances for an attacker to take a user's transaction and hand it over to the miner.

I don't see the big deal with Bitrefill. I use them on almost a daily basis now that they have bill payments too. Waiting for a confirm for a GC is not a big deal, and payments seem to go out overnight anyway.
RBF / no RBF I don't see why they would be caring that much either way anyway. Have to go read what they have said.

I understand what they are trying to do and why they are trying to do it, I just think as do some others that we would be better off drawing a line in the sand and saying as of THIS DATE (or block number) it is happening. That one last warning so to speak.

-Dave

Sure, but you also have to consider entities such as Muun wallet or Bitrefill which have tens or even hundreds of thousands of users. Impossible for them to build a relationship with each one. (I named these two specifically since they were involved in the above linked discussions on GitHub and the mailing list.)

Sure, but it wouldn't really achieve much if almost every other node continues to run opt in RBF and rejects all the replacement transactions you broadcast. Or more to the point, unless major miners update their nodes to start accepting full RBF replacements.

Exactly, but that's not bad. Merchants and customers should rather rely on the good will of their between relation, not on the Bitcoin network. If a customer is malicious, it doesn't matter much if most nodes choose to not propagate transactions that double spend an RBF-disabled transaction; he's surely discouraged to try, but there are alternatives such as miner bribing.

On the other hand, if there's a good relation between the merchant and the customer, regardless of whether the transaction opts-in for RBF or not, there won't be double-spends. And I don't know about you, but I mostly have good relations with those I transact with.

---

---

Question: how hard is it to full the network with nodes that have Full RBF? Could you setup multiple full nodes in one machine without anybody knowing one person is running all?

Well now they have at least another year to decommission their zero-conf transaction scanning, and move to Lightning Network instead. All the major payment gateways support it, so I see no reason why an in-house solution shouldn't be able to do the same.

True, but in this case, Knots has supported full RBF for a long time now, and if a Core node really wanted to run full RBF they could do that too with very minimal code changes. Relying on zero confirmation transactions has always had an associated risk, and was always dependent on nodes not implementing full RBF, which they could have done at any time.

I agree, but as I said above, it is obvious that many entities and businesses which depend on risk assessed zero confirmation transactions for much of their functioning were caught unaware by this change. Now you can argue that is their own fault, since this has been discussed for years, but I don't think it would be wrong to give them more time to adjust their inner workings to be compatible with this change.

Having said all that, though, it isn't going to happen. 24.0 has already been finalized and will be released with mempoolfullrbf as planned, and yet another pull request to revert it has been fairly widely NACKed.

My 2c:

Full RBF is the only option that makes sense.

The RBF behaviour is not part of Bitcoin, it's just a node implementation detail.
Anything prior to consensus is not sacred. As long as a block follows consensus rules, it is valid, regardless of what transactions it includes from the mempool.

This is a key difference between Bitcoin and the shitcoins.
Bitcoin doesn't try to get fancy implementing all kind of "social consensus" rules and other such stupid non-deterministic things.

Users expect determinism and reliability out of the Bitcoin network. There should be no features which rely on the goodwill of node operators.
This would be akin to building an extension to your stone fortress out of paddlepop sticks.

The same goes for any feature which attempts to treat the mempool as sacred.
The mempool is a resource to be plundered in the greediest way possible. It is a Herbalife salesperson's phonebook.
Any implementation details which try to get nodes to treat mempool txns in a particular fashion is foolish.

Miners ought to order transactions by fee revenue and nothing else, otherwise they are in the wrong industry.
If there are 50 pending blocks, and I submit a transaction with a higher sats/vb than the rest, rational miners should include my transaction first before all the others even though my transaction is the newest.

I also think the majority of non-mining node operators probably won't bother to change the default, but that is different for mining node operators. All it takes is one large miner to start enabling the setting on all their nodes and start claiming the additional rewards for other miners to want in on that too. And with the success of things like transaction accelerators, a miner could offer their services out to the community and invite people to broadcast RBF transactions directly to them so they know they are getting seen.

It will be a bit haphazard to begin with, but I suspect that prior to the setting being changed to true by default in future version that we will effectively be running a full RBF system across the network already.

I don't expect node operator bother change default option. It's already proved with lack of node which accept transaction with fee lower than 1 sat/vbyte or non-standard transaction.


Starting from $100/block? It's rather generous considering coming from an individual.

So looks like all the pull requests linked to previously have now been closed, meaning that 24.0 will ship as originally planned with the mempoolfullrbf option present but default set to false. And with 24.0 being bumped to rc4, we are probably only a few days away from release.

Will be interesting to see what the general mempool policy turns out to be and how quickly nodes and miners start enabling the option. There is already some financial incentive for miners to start adopting full RBF, not just from people attempting to replace non-RBF flagged transactions but also from this: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021143.html

I suspect we will pretty quickly start to see services which offer zero confirmation deposits or payments stop doing so. I suspect there will also be a handful of services which are unaware of this change being scammed.

Absolutely, but I think it is the right thing to do for two reasons. I understand the points that this is only a setting which is defaulted to off, and actually any node or miner who wants to run a full RBF policy can do so at any time even without this setting. However, I don't think it is right to release a feature which has divided opinion so strongly without spending a bit of time working things out, and it would also give the developers and services which seem to have been caught off guard by this change some more time to react. Although this has been discussed for years, and the developers in question really should have done a better job of keeping up to speed with ongoing developments, I don't think it's a good look for the community to now say "Well, sucks to be you" and release a feature which some developers are saying will completely break their app/software/business model.

Now, as I said above, full RBF is the natural state of the system, not to mention the necessary benefits it brings to allow further development of Lightning and other projects, and so I fully expect it to arrive in v25.0 if not in v24.0. But I don't think delaying it from v24.0 is necessarily a bad thing, and if we did, then hopefully by the time v25.0 comes round many of these issues would have been discussed and resolved.

I have a feeling that the services relying on non-RBF transactions may have a small edge / advantage over the competition (since 0 conf is a good advertising and attracts users) hence they're not eager to change.

So while it could be a nice gesture to postpone the full RBF a little, we may have the exact same problem on the next release too.

Marco Falke noted that in his pull request here: https://github.com/bitcoin/bitcoin/pull/26287. Full RBF has been discussed for years. It's pretty surprising that developers of projects which accept/depend on zero confirmation transactions are only learning about it now.

Lots more discussion on this pull request in the last couple of days, and now another new one from Andrew Chow - https://github.com/bitcoin/bitcoin/pull/26456.
This one removes the setting from 24.0 entirely simply to allow 24.0 to be released and to allow ongoing discussion regarding full RBF to happen, but even that seems to be contentious.

As noted in the mailing list discussion, this is the natural state of the system, and as the block subsidy falls and fees make up a larger and larger proportion of miners' income, then they are more and more likely to start accepting higher paying replacement transactions even if the original is opted out of RBF.

The problem with disabled RBF is that it relies on Bitcoin users' sincerity for transaction settlement, oppositely to RBF, which relies on miners' profit. Running a full node does grant you an opinion, because you're enforcing both consensus and non-consensus rules, but you should not rely to the latter. Miners can, and should, dump non-RBF double-spends, but I hold no sway to the way they'll choose to do business. Ultimately, they decide if they'll put profit above this pseudo-rule.

Disabled-RBF Is fundamentally flawed, because the system is designed to work trustlessly, and transactions that pay the most ought to, naturally, have advantage.

IMO, part of the issue is that if we take this forum as a small microcosm of bitcoin enthusiasts this post about Full RBF in 4 months got a whopping 44 replies.
People are not paying attention to it, and the people who are using software that is going to be effected by it seem to be taking their time in dealing with it.
Should they have been more proactive? Probably. Is it important that we start Full RBF now, nope not really (at least in my view).

I am on the side that would like to see them deal with this a different way, but my way would probably cause more issues for non tech users and generate about eleventy billion lines of spaghetti code so there is that.....

-Dave

v24.0 is about to be released and is almost off the assembly line so I don't see them making a last-miniute change to that release considering the kind of peer-review process PRs get and the deterministic building procedure for each release. Any change will likely affect v25.0 at the earliest.