An initial replace-by-fee implementation is now available

Summary:

In this email conversation, Adam Back is concerned about the possibility of having conflicting double-spends floating around with different payee and change addresses. Peter Todd responds, saying that the current defacto no replacement mechanism for Bitcoin is the best currently available. He also mentions that net-splits are possible but not trivial. Todd proposes to move the mechanism into spec (specification) which can cause a weakening of the attack on 1-confirmation. Todd goes on to discuss privacy management, saying that even if fees are increased, the client does not have coin management or privacy management of cross-linking coins. Therefore, he suggests that people who do not want to reveal which is the change address should put a big enough fee upfront based on a margin over prevailing fee statistics. Regarding the creation of more traffic revising fees due to experience, Todd suggests that it would be better to try to get the fee right the first time. However, he acknowledges the ability to revise the fee IFF (if and only if) the best effort fee doesn't work empirically after a couple of blocks, which seems like a good feature but not with revised recipient/change addresses. Finally, Todd raises a question about how to stop both bids from being processed if the bids are too flexibly different.In response to the discussion thread posted by Adam Back, Todd explains that the patch makes the concept of a 0-confirm double-spend obsolete. The model replaces the vague, insecure, easily broken, de-facto no-replacement rule with something very easy to reason about, wherein users bid for blockchain space and can adjust their bid after the fact. Todd argues that zero-conf double-spends are not that big of a problem because the vast majority of payments have other mechanisms they can use instead of relying on the de-facto behavior of dozens of major miners and nodes. He concludes by saying that we're better off if we don't give people a false sense of security.

Updated on: 2023-06-06T16:36:47.738169+00:00