Hi Greg,
> The security of LN and other related systems are something like: "given
> proper fees offered, can a transaction be mined within N blocks?" You're
> simply not allowed to out-bid your attacker in certain circumstances due to
> today's miner incentive-incompatible relay policies.
It is not possible to guarantee that a transaction will be mined within N
blocks irrespective of fees. It is vulnerable if a project's security relies on
it,and should fix it by changing the security assumptions. Miners can try
full-rbf or other policy without core so I won't consider opt-in as
incentive-incompatible.
>> ... arguments about how many people RBF being sufficient or not ...
>
> The idea that we should only build robust systems after the broken ones are
> attacked is not a serious argument.
Its true and was even mentioned in PR #16171 that a policy is only useful if
enough nodes and miners follow it. We should build robust systems but I don't
think this change will help in doing it.
> This is a strawman.
>
> Full-RBF is a simple, obvious, incentive-compatible step to getting closer to
> more robust layer two systems.Fixing the rest of the holes is for future
> proposals which are a bit more involved and definitely less mature.
I do not have issues with multiple RBF policies being tried out and full-rbf
being one of them. My disagreements are with rationale, lack of basic options
in Bitcoin Core to employ/disable different RBF policies and a few arguments
made in support for full-rbf. Whether it appears strawman or offtopic on
github, there should be a place to share these disagreements.
> If Knots has these knobs, just use Knots rather than lobby all
> implementations to have miner incentive incompatible knobs?
Everyone can share options that would help users in the bitcoin implementation
used by 90% nodes. I don't think this is reserved only for a few developers. I
would personally use Knots and others are free to try the suggestion or
continue using Bitcoin Core.
/dev/fd0
Sent with [Proton Mail](https://proton.me/) secure email.
------- Original Message -------
On Thursday, June 16th, 2022 at 6:32 AM, Greg Sanders <gsander...@gmail.com>
wrote:
>> If something relies on a policy which can be changed without breaking
>> consensus rules, how is it secure in any case with or without full rbf?
>
> The security of LN and other related systems are something like: "given
> proper fees offered, can a transaction be mined within N blocks?" You're
> simply not allowed to out-bid your attacker in certain circumstances due to
> today's miner incentive-incompatible relay policies.
>
> There is also a time-value dimension to this with other simpler systems where
> your funds can be locked up for potentially weeks for similar reasons.
>
>> ... arguments about how many people RBF being sufficient or not ...
>
> The idea that we should only build robust systems after the broken ones are
> attacked is not a serious argument.
>
>> I am not opposed to full-rbf; rather, I am opposed to the notion that
>> full-rbf will solve all problems
>
> This is a strawman.
>
> Full-RBF is a simple, obvious, incentive-compatible step to getting closer to
> more robust layer two systems. Fixing the rest of the holes is for future
> proposals which are a bit more involved and definitely less mature.
>
>> would suggest users to try Bitcoin Knots instead
>> Developers should provide basic RBF policy options rather than attempting to
>> define what constitutes a good policy and removing the ability to disable
>> something when necessary.
>
> If Knots has these knobs, just use Knots rather than lobby all
> implementations to have miner incentive incompatible knobs?
>
> Cheers,
> Greg
>
> On Wed, Jun 15, 2022 at 8:27 PM alicexbt via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Antoine,
>>
>> Thanks for opening the pull request to add support for full-rbf in Bitcoin
>> Core. I have a few disagreements with the approach and questions.
>>
>>> Recent discussions among LN devs have brought back on the surface concerns
>>> about the security of multi-party funded transactions (coinjoins,
>>> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
>>> low-fruit, naive DoS vector playable against the funding flow of any such
>>> construction due to the lack of existent full-rbf transaction-relay
>>> topology on today's p2p network [0] [1].
>>
>> 1)If something relies on a policy which can be changed without breaking
>> consensus rules, how is it secure in any case with or without full rbf? If I
>> write a python script that expects user to enter char 'a' or 'b' but user
>> can enter 'c' and there is no code to handle exceptions or other chars, will
>> it be secure?
>>
>> 2)full-rbf is not default in the 2 open pull requests, so this experiment
>> still relies on users changing RBF policies manually. If majority of nodes
>> use default opt-in policy, how would this affect vulnerable projects?
>>
>>> If you're a mining operator looking to increase your income, you might be
>>> interested to experiment with full-rbf as a policy.
>>
>> Miners can only increase their income if users replace transactions. 2-3%
>> transactions are replaced with opt-in RBF, if someone did not replace
>> earlier why would they do it with full RBF? Or even if we add some users in
>> it who could not signal for some reasons, do you think it would be anything
>> above 5%?
>>
>>> If you're a Bitcoin user or business and you don't like full-rbf, please
>>> express an opinion on how it might affect your software/operations. I'm
>>> always interested to learn more about mempool and transaction-relay
>>> interactions with upper-layers and applications and to listen to feedback
>>> in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
>>> know there have been a lot of concerns about full-rbf in the past, however
>>> I believe the Bitcoin ecosystem has matured a lot since then.
>>
>> I am not opposed to full-rbf; rather, I am opposed to the notion that
>> full-rbf will solve all problems and the lack of basic options in Bitcoin
>> Core to employ/disable different RBF policies. There is also a speculation
>> about making full RBF default in an year which isn't relevant to discuss at
>> this point without trying different RBF policies.
>>
>> I would suggest users to try Bitcoin Knots instead which already has an
>> option to disable all RBF policies if required, opt-in and full RBF policy.
>> This can also be done using GUI if not familiar with config
>> optionmempoolreplacement​.
>>
>> The rationale in PR #16171 was insufficient to justify removing it in the
>> first place, had 2 NACKs and was reopened to merge it. Why bother with a few
>> lines of code that may allow someone disable it if required in local mempool
>> since it's only useful when a big percentage of miners utilize it and
>> essentially underused according to the PR author? Developers should provide
>> basic RBF policy options rather than attempting to define what constitutes a
>> good policy and removing the ability to disable something when necessary.
>>
>> /dev/fd0
>>
>> Sent with [Proton Mail](https://proton.me/) secure email.
>>
>> ------- Original Message -------
>> On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi list,
>>>
>>> Recent discussions among LN devs have brought back on the surface concerns
>>> about the security of multi-party funded transactions (coinjoins,
>>> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
>>> low-fruit, naive DoS vector playable against the funding flow of any such
>>> construction due to the lack of existent full-rbf transaction-relay
>>> topology on today's p2p network [0] [1]. While it does not consist in a
>>> direct loss of funds, if exploited well I think it's annoying enough to
>>> inflict significant timevalue loss or fee-bumping waste
>>> to the future providers or distributed swarm of users doing multi-party
>>> funded transactions. Of course, it can be fixed one layer above by
>>> introducing either fidelity bonds or a reliable centralized coordinator,
>>> though at the price of an overhead per-participant ressources cost and loss
>>> in system openness [1].
>>>
>>> For that reason, I believe it would be beneficial to the flourishing of
>>> multi-party funded transactions to fix the Dos vector by seeing a subset of
>>> the network running full-rbf and enabling propagation of honest multi-party
>>> transactions to the interested miners, replacing potential non-signaling
>>> double-spend from a malicious counterparty. Moving towards that direction,
>>> I've submitted a small patch against Bitcoin Core enabling it to turn on
>>> full-rbf as a policy, still under review [3]. The default setting stays
>>> **false**, i.e keeping opt-in RBF as a default replacement policy. I've
>>> started to run the patch on a public node at 146.190.224.15.
>>>
>>> If you're a node operator curious to play with full-rbf, feel free to
>>> connect to this node or spawn up a toy, public node yourself. There is a
>>> ##uafrbf libera chat if you would like information on the settings or
>>> looking for full-rbf friends (though that step could be automated in the
>>> future by setting up a dedicated network bit and reserving a few outbound
>>> slots for them).
>>>
>>> If you're a mining operator looking to increase your income, you might be
>>> interested to experiment with full-rbf as a policy. Indeed, in the future I
>>> believe the multi-party transactions issuers who need full-rbf to secure
>>> their funding flow should connect by default to full-rbf peers. One can
>>> conjecture that their transactions are likely to be more compelling in
>>> their feerate as their liquidity needs are higher than the simple
>>> transaction. For today, I think we have really few standards and bitcoin
>>> softwares relying on multi-party funded transactions [4].
>>>
>>> If you're a Bitcoin user or business and you don't like full-rbf, please
>>> express an opinion on how it might affect your software/operations. I'm
>>> always interested to learn more about mempool and transaction-relay
>>> interactions with upper-layers and applications and to listen to feedback
>>> in those areas, and I guess a lot of other Bitcoin researchers/devs too. I
>>> know there have been a lot of concerns about full-rbf in the past, however
>>> I believe the Bitcoin ecosystem has matured a lot since then.
>>>
>>> Any mistakes or missing context is my own.
>>>
>>> Cheers,
>>> Antoine
>>>
>>> [0] For more info about replace-by-fee, see
>>> https://bitcoinops.org/en/topics/replace-by-fee/
>>>
>>> [1] For more details about the DoS vector, see
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>>>
>>> [2] E.g I think it does not affect the Lightning Pool service, as there is
>>> a preliminary step where the participant funds are locked first in a 2-of-2
>>> with the coordinator before being committed in the multi-party batch
>>> transaction.
>>>
>>> [3] https://github.com/bitcoin/bitcoin/pull/25353
>>>
>>> [4] E.g DLCs :
>>> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md
>>> ; Lightning dual-funded channel :
>>> https://github.com/lightning/bolts/pull/851
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
