Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

[Greg Sanders via bitcoin-dev]

> 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.

It's not possible to guarantee that any funds can be moved ever. But we
still build an entire system assuming we can via an interesting mix of
cryptography and incentives.

On Wed, Jun 15, 2022 at 9:45 PM alicexbt  wrote:

> 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  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 

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

[alicexbt via bitcoin-dev]

Hi cndm1,

> If you see a "lack of basic options" and no one has opened a pull request for 
> it, it may be for two reasons.

The basic option to disable all RBF policies in a node's mempool if required 
was removed in [PR #16171][1]. No one has opened a pull request to revert this 
because most of the maintainers and a few reviewers agreed with this change. It 
wasn't required, PR had weak rationale, 2 NACKS and was reopened to merge 
because some reviewers/maintainers believe its a policy that cannot be 
maintained. One of the reviewers who NACKed it already maintains the config 
option to disable all RBF policies in Bitcoin Knots which is a derivative of 
Bitcoin Core.

> However, repeatedly demanding others to do it for you is not helpful in open 
> source software development.

I am not demanding anyone to add a few lines of code and open a pull request. I 
am _reviewing_ a pull request in an open source project and sharing my 
feedback. Even Antoine and Luke agreed to add it if other reviewers have no 
issues or I can do it. This option in context with another being added for a 
new RBF policy was being discussed in [PR #25353][2] and my earlier emails in 
this thread.

Other 'basic options' will be easier to accommodate with `-mempoolreplacement` 
used in [PR #25373] which is unlikely to be merged.

[1]: https://github.com/bitcoin/bitcoin/pull/16171
[2]: https://github.com/bitcoin/bitcoin/pull/25353
[3]: https://github.com/bitcoin/bitcoin/pull/25373


/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, June 16th, 2022 at 11:13 AM, linuxfoundation.cndm1--- via 
bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:



> alicexbt wrote:
>
> > 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.
>
> Bitcoin Core is open source software, where developers open pull
> requests to try to get them merged after review. If you see a "lack of
> basic options" and no one has opened a pull request for it, it may be
> for two reasons. First, it could be that it just doesn't make sense,
> so no one sees a point in implementing it. Secondly, it may be that it
> isn't on anyone's list of priorities. In the second case, you are
> welcome to share your preference once. Moreover, no one is holding you
> back to implement it yourself and suggest a pull request. However,
> repeatedly demanding others to do it for you is not helpful in open
> source software development.
>
> cndm1
>
> ___
> 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

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

[linuxfoundation.cndm1--- via bitcoin-dev]

alicexbt wrote:
> 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.

Bitcoin Core is open source software, where developers open pull
requests to try to get them merged after review. If you see a "lack of
basic options" and no one has opened a pull request for it, it may be
for two reasons. First, it could be that it just doesn't make sense,
so no one sees a point in implementing it. Secondly, it may be that it
isn't on anyone's list of priorities. In the second case, you are
welcome to share your preference once. Moreover, no one is holding you
back to implement it yourself and suggest a pull request. However,
repeatedly demanding others to do it for you is not helpful in open
source software development.

cndm1

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev