> I'd suggest doing that right now, without waiting for the patch to get
merged,
> as it improves the politics of getting the patch merged. Miners tend to
run
> customized bitcoind's anyway.
Philosophically, I think we're better off arguing code patches free from a
political framework and rather
> Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
> failing to complete the round. In fact, the double-spend DoS attack
requires
> more resources, because for a double-spend to be succesful, BTC has to be
spent
> on fees.
I think I agree that effectively a
Hi Peter,
> Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
> failing to complete the round. In fact, the double-spend DoS attack requires
> more resources, because for a double-spend to be succesful, BTC has to be
> spent
> on fees.
>
> It's just a fact of life that a
The attacker isn't guaranteed to spend *any* funds to disrupt the protocol
indefinitely, that's the issue here. In this scenario, her input double
spend is at an impractical feerate, and is never included in a block,
sitting at the bottom of the mempool.
The other users' only practical choice is
On Tue, Jul 05, 2022 at 08:46:51PM +, alicexbt wrote:
> Hi Peter,
>
> > Note that Wasabi already has a DoS attack vector in that a participant can
> > stop
> > participating after the first phase of the round, with the result that the
> > coinjoin fails. Wasabi mitigates that by punishing
Hi Peter,
> Note that Wasabi already has a DoS attack vector in that a participant can
> stop
> participating after the first phase of the round, with the result that the
> coinjoin fails. Wasabi mitigates that by punishing participating in future
> rounds. Double-spends only create additional
On June 27, 2022 8:03:38 AM EDT, Greg Sanders wrote:
>One key difference seems to be that properly punishing someone based on
>mempool behavior seems much more difficult. As we all know there is no "the
>mempool".
No, that's not relevant here: the DoS condition is the existence of a (mined)
One key difference seems to be that properly punishing someone based on
mempool behavior seems much more difficult. As we all know there is no "the
mempool".
On Sun, Jun 26, 2022, 8:43 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sun, Jun 26, 2022 at
On Sun, Jun 26, 2022 at 04:40:24PM +, alicexbt via bitcoin-dev wrote:
> Hi Antoine,
>
> Thanks for sharing the DoS attack example with alternatives.
>
> > - Caroll broadcasts a double-spend of her own input C, the double-spend is
> > attached with a low-fee (1sat/vb) and it does _not_
Hi Antoine,
Thanks for sharing the DoS attack example with alternatives.
> - Caroll broadcasts a double-spend of her own input C, the double-spend is
> attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
> - Alice broadcasts the multi-party transaction, it is rejected by the
On Tue, Jun 21, 2022 at 07:45:48PM -0400, Antoine Riard wrote:
> > BTW I changed one of my OTS calendars to issue fee-bumping txs without the
> > opt-in RBF flag set as an experiment. I also made sure txs would
> propagate to
> > the above node. As of right now, it's up to 32 replacements (once
> BTW I changed one of my OTS calendars to issue fee-bumping txs without the
> opt-in RBF flag set as an experiment. I also made sure txs would
propagate to
> the above node. As of right now, it's up to 32 replacements (once per
block),
> without any of them mined; the calendars use the strategy
HI alicexbt,
> Lets consider there are 2 users with name Bob (normal LN user) and Carol
(attacker running LN node) which I will use in this email for examples. In
this case Bob and Carol can manage security of their OS and it is not
affected by others using vulnerable systems or OS.
Yes, I
On Mon, Jun 13, 2022 at 08:25:11PM -0400, Antoine Riard via bitcoin-dev wrote:
> 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
On Fri, Jun 17, 2022 at 04:54:11AM +, alicexbt via bitcoin-dev wrote:
> > If they'reparties interested in implementing more RBF policy options in
> > Bitcoin Core, I think they're free to propose suchchanges and invest the
> > engineering effort to do so. If you're interested in advancing
Hi Antoine,
> One could list the operating system on which is running your Lightning
> process or the compiler toolchain turning outyour Lightning source code in a
> binary artifact. Some weird kernel's memory mapping change could allow access
> toyour channel funding keys, _without_ breaking
Hi alicexbt,
Thanks for taking time to review the pull request,
> 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?
Your Lightning node software relies on far more software and hardware
components
> 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
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
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
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
> 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
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
On Wed, Jun 15, 2022 at 02:53:58AM +, Luke Dashjr wrote:
> Bitcoin Knots still uses this service bit, FWIW (though due to a bug in some
> older versions, it wasn't signalled by default). There are probably at least
> 100 nodes with full RBF already.
Right. However it looks like you do not
Bitcoin Knots still uses this service bit, FWIW (though due to a bug in some
older versions, it wasn't signalled by default). There are probably at least
100 nodes with full RBF already.
On Wednesday 15 June 2022 02:27:20 Peter Todd via bitcoin-dev wrote:
> On Mon, Jun 13, 2022 at 08:25:11PM
On Mon, Jun 13, 2022 at 08:25:11PM -0400, Antoine Riard via bitcoin-dev wrote:
> 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
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
27 matches
Mail list logo
