Hi James,
Thanks to bringing to awareness the atomic mining pool thing, it's
interesting.
> I'm not a mining expert and so I can't speak to the efficacy of the
> paper as a whole, but direct-from-coinbase payouts seem like a
> desirable feature which avoids some trust in pools. One limitation is
Good morning Greg,
> Hi James,
> Could you elaborate on a L2 contract where speedy
> settlement of the "first part" can be done, while having the rest
> take their time? I'm more thinking about time-out based protocols.
>
> Naturally my mind drifts to LN, where getting the proper commitment
>
Presigned transactions have to use a N-of-N (2-2 for ln, more for pools)
multisignature which is computed over the network whereas in-script
commitments can be done 1 key that is a non-secret point (e.g., just the
generator I think works).
For large protocol trees (e.g., of size N) the savings can
On 2022-08-19 06:33, James O'Beirne via bitcoin-dev wrote:
Multiple parties could
trustlessly collaborate to settle into a single CTV output using
SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction
similar to coinjoins.
Just to make sure I understand, is the reason for SH_ALL|SH_A
Hi James,
Could you elaborate on a L2 contract where speedy
settlement of the "first part" can be done, while having the rest
take their time? I'm more thinking about time-out based protocols.
Naturally my mind drifts to LN, where getting the proper commitment
transaction confirmed in a timely fa
Over the past few months there have been a few potential uses of
OP_CHECKTEMPLATEVERIFY (BIP-119)
(https://github.com/bitcoin/bitcoin/pull/21702) that I've found
interesting.
# Congestion control redux
When I first heard of CTV, a presentation Jeremy did at Chaincode back
in 2018 or '19, he cited
