Hi aj,
I completely agree with your observation that there's an important trust/safety
vs. capital-efficiency tradeoff, and I almost completely agree with your
analysis.
> (There are probably ways around this with additional complexity: eg,
> you could peer with a dedicated node, and have the
Hi Rusty,
> I've read the start of the paper on my vacation, and am still
> digesting it. But even so far, it presents some delightful
> possibilities.
Great!
> As with some other proposals, it's worth noting that the cost of
> enforcement is dramatically increased. It's no longer one
Hi Antoine,
Thanks for your note. Responses are in-line below:
> Hi John,
> Thanks for the proposal, few feedback after a first look.
> > If Bitcoin and Lightning are to become widely-used, they will have to
> be adopted by casual users who want to send and receive bitcoin, but > who
> do not
On September 8, 2023 3:27:38 PM HST, ZmnSCPxj via bitcoin-dev
wrote:
>Now, suppose that participant A wants B to be assured that
>A will not double-spend the transaction.
>Then A solicits a single-spend signature from the actuary,
>getting a signature M:
>
>current state +
Good morning Dave,
Sent with Proton Mail secure email.
--- Original Message ---
On Monday, September 18th, 2023 at 12:12 AM, David A. Harding
wrote:
>
> On September 8, 2023 3:27:38 PM HST, ZmnSCPxj via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Now, suppo
Good morning John,
> On the other hand, if the consensus rules are changed to allow even simple
> covenants, this scaling bottleneck is eliminated.
> The key observation is that with covenants, a casual user can co-own an
> off-chain Lightning channel without having to sign all (or any) of the
