On Sun, Nov 06, 2022 at 06:22:08PM -0500, Antoine Riard via bitcoin-dev wrote:
> Adding a few more thoughts here on what coinjoins/splicing/dual-funded
> folks can do to solve this DoS issue in an opt-in RBF world only.
>
> I'm converging that deploying a distributed monitoring of the network
> me
Hi Laolu,
Yeah, that is definitely the main downside, as Ruben also mentioned:
tokens are "burned" if they get sent to an already spent UTXO, and
there is no way to block those transfers.
And I do agree with your concern about losing the blockchain as the
main synchronization point, that seems in
On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev
wrote:
>
>AJ/Antoine et al
>
>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
>> solve that problem if they have only opt-in RBF available?
>
>Assuming Alice is a well funded advisory, with enough resources to spa
>
>
> With full-rbf, who saw what transaction first doesn't matter: the higher
> fee paying transaction will always(*) replace the lower fee one. With
> opt-in RBF, spamming the network can beat out the alternative.
>
incentivised predictability is critical when designing low level protocols,
like
tl;dr: We can remove the problem of Rule #5 pinning by ensuring that all
transactions in the mempool are always replaceable.
Currently Bitcoin Core implements rule #5 of BIP-125:
The number of original transactions to be replaced and their descendant
transactions which will be evicted fr
On Mon, Nov 07, 2022 at 03:17:29PM -0500, Peter Todd via bitcoin-dev wrote:
> tl;dr: We can remove the problem of Rule #5 pinning by ensuring that all
> transactions in the mempool are always replaceable.
With Rule #5 solved, let's look at the other pinning attack on multi-party
transactions: BIP-
Hello bitcoin-dev,
The description in the OP is completely broken for the simple reason that
Bitcoin transactions can have multiple inputs, and so a single transaction
can conflict with multiple in-mempool transactions. The proposal would
limit the number of descendants of each in-mempool transact
On Mon, Nov 07, 2022 at 04:21:11PM -0500, Suhas Daftuar via bitcoin-dev wrote:
> Hello bitcoin-dev,
>
> The description in the OP is completely broken for the simple reason that
> Bitcoin transactions can have multiple inputs, and so a single transaction
> can conflict with multiple in-mempool tra
Hi Peter,
> We can ensure with high probability that the transaction can be
> cancelled/mined
> at some point after N blocks by pre-signing a transaction, with nLockTime set
> sufficiently far into the future, spending one or more inputs of the
> transaction with a sufficiently high fee that it w
Funding channels on a lightning node can be a pain. First, I need to send funds
to my node on-chain. Then I need to make another transaction to open channels.
Instead, we can use the BIP 78 PayJoin P2EP protocol to fund and open channels
in a single transaction.
We do not communicate over the s
On Wed, Oct 26, 2022 at 04:39:02PM +, Pieter Wuille via bitcoin-dev wrote:
> However, it obviously raises the question of how the mapping table between the
> 1-byte IDs and the commands they represent should be maintained:
>
> 1. The most straightforward solution is using the BIP process as-is
11 matches
Mail list logo
