Unfortunately Bitcoin Core is implementing sender controlled opt-in RBF. IMHO this is a bad idea and does not seem quite thought through. It might hurt acceptance by causing unexpected delays (vendors waiting for confirmations of RBF txs). As Namecoin is far from full blocks I suggest we disable this feature if we can do it in a way that is ok from a code management perspective (domob?).
https://www.reddit.com/r/Bitcoin/commen ... st_one_of/
Replace By Fee (RBF) in Namecoin Core
Re: Replace By Fee (RBF) in Namecoin Core
I don't think this should be hard to code if people want it - but my personal opinion is that RBF might not be as bad an idea as some try to depict it. Zero confirmation is simply zero confirmation, and RBF is the game-theoretic miner incentive. There's nothing we can do to "fix" that, except for "suggesting" miners to not follow these incentives out of good will.
I also think that this discussion is particularly irrelevant for Namecoin, since we do not strive to be a payment system and thus the "feature" of "seemingly secure" zero-confirmation transactions is not relevant.
I also think that this discussion is particularly irrelevant for Namecoin, since we do not strive to be a payment system and thus the "feature" of "seemingly secure" zero-confirmation transactions is not relevant.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
Re: Replace By Fee (RBF) in Namecoin Core
Well, zero confirmation with "race advantage" is quite different from "replacement supported by all pools". However, in theory the current implementation reflects that as RBF transactions are clearly distinguishable (what do I tell you ).domob wrote:I don't think this should be hard to code if people want it - but my personal opinion is that RBF might not be as bad an idea as some try to depict it. Zero confirmation is simply zero confirmation, and RBF is the game-theoretic miner incentive.
Default settings and developer recommendations ('mining codex') make a huge difference IMHO. E.g. miners can retract from pools breaking the social rules.There's nothing we can do to "fix" that, except for "suggesting" miners to not follow these incentives out of good will.
Yeah. Also most users are currently on SPV anyway.I also think that this discussion is particularly irrelevant for Namecoin, since we do not strive to be a payment system and thus the "feature" of "seemingly secure" zero-confirmation transactions is not relevant.
I don't oppose "opt-in" RBF in general but the implementation, user interface and introduction should be done in a way so that as few users as possible get scammed by it.
E.g. I am wondering if/how an unconfirmed RBF transaction is displayed (as it is way less trustworthy than a regular tx).
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Replace By Fee (RBF) in Namecoin Core
So, here's my take on it.
Namecoin is not intended to be a general-purpose payment system. Therefore, our design should be focused on naming applications first and foremost. Is RBF relevant to naming?
One attack that could be opened by RBF would be scamming people who are paying for a name with NMC, by double-spending either the payment or the name. This isn't really a big deal since we have atomic name/NMC trades.
A similar attack would be double spending when trading BTC for a name. This can be fixed by atomic cross-chain swaps, so again I don't think this is an issue.
Double spending when trading one name for another name would be an issue right now since multiple name_update ops can't exist in a single transaction. However, I think the solution is making such transactions legal; this is better anyway since it results in more flexible contracts (and also allows slightly better privacy via name CoinJoins).
The last issue I can see is a name owner double spending their own name. This isn't a security issue, and is actually a good thing since it allows instant name_update propagation.
So, generally, I don't see any problem with RBF as it applies to Namecoin. In fact, I think it improves security and reliability for us, since it allows name owners to revoke keys and fix misconfigurations faster. (Granted, this is a small benefit.)
Namecoin is not intended to be a general-purpose payment system. Therefore, our design should be focused on naming applications first and foremost. Is RBF relevant to naming?
One attack that could be opened by RBF would be scamming people who are paying for a name with NMC, by double-spending either the payment or the name. This isn't really a big deal since we have atomic name/NMC trades.
A similar attack would be double spending when trading BTC for a name. This can be fixed by atomic cross-chain swaps, so again I don't think this is an issue.
Double spending when trading one name for another name would be an issue right now since multiple name_update ops can't exist in a single transaction. However, I think the solution is making such transactions legal; this is better anyway since it results in more flexible contracts (and also allows slightly better privacy via name CoinJoins).
The last issue I can see is a name owner double spending their own name. This isn't a security issue, and is actually a good thing since it allows instant name_update propagation.
So, generally, I don't see any problem with RBF as it applies to Namecoin. In fact, I think it improves security and reliability for us, since it allows name owners to revoke keys and fix misconfigurations faster. (Granted, this is a small benefit.)