The problem with using ALL|ANYONECANPAY is that you cannot verify beforehand
that the other inputs are the inputs you want added to the transaction.
Some examples of bad things that could happen:
* Coordinator adds its own inputs, you still get your outputs but
effectively paid fees for
Hi Michael,
> Now that's not to say you may not have a point about better documentation and
> guidance on what should go through the vulnerability reporting process and
> what shouldn't.
Yes, this can be improved.
> Or even that this particular issue could ultimately end up being classed a
>
Hi Bitcoin Developers,
I recently experimented with different sighash flags, PSBTs and realized
ALL|ANYONECANPAY could be used to reduce some steps in coinjoin.
Steps:
- Register outputs.
- One user creates a signed PSBT with 1 input, all registered outputs and
ALL|ANYONECANPAY sighash flag.
Good morning Burak,
I have not gone through the deep dive fully yet, but I find myself confused
about this particular claim:
> A pool transaction can be double-spent by the Ark service provider while it
> remains in the mempool. However, in the meantime, the recipient can pay a
> lightning
Hi list,
I'm excited to publicly publish a new second-layer protocol design I've been
working on over the past few months called Ark.
Ark is an alternative second-layer scaling approach that allows the protocol
users to send and receive funds without introducing liquidity constraints. This
Hi Lorban,
The RFC is very clear and consistent on presenting payments pools in
the context of non-custodial mining pools, congrats to the authoring
team.
Few feedbacks, on the technical definition of a payment pool, the
common idea between all payment pools ideas presented so far
(Joinpool,
