Re: [bitcoin-dev] Proof of reserves - recording

https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy > On Jul 5, 2021, at 21:54, ZmnSCPxj wrote: > > Good morning Billy, > > >> >>> The two participants in the channel can sign a plaintext containing their >>> node pubkeys and how much each owns >> >> Sure, but even

Re: [bitcoin-dev] Proof of reserves - recording

Good morning Billy, > > >  The two participants in the channel can sign a plaintext containing their > >node pubkeys and how much each owns > > Sure, but even if both participants in the channel sign a correct statement > of truth, one of the participants can send funds out in the next second,

Re: [bitcoin-dev] Proof of reserves - recording

Good morning e, > If only one could prove that he won’t get into a boating accident. At least in the context of Lightning channels, if one party in the channel loses its key in a boating accident, the other party (assuming it is a true separate person and not a sockpuppet) has every incentive

Re: [bitcoin-dev] Proof of reserves - recording

If only one could prove that he won’t get into a boating accident. e > On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev > wrote: > > Good morning Billy, > >> I wonder if there would be some way to include the ability to prove balances >> held on the lightning network, but I suspect that i

Re: [bitcoin-dev] Proof of reserves - recording

Good morning Billy, > I wonder if there would be some way to include the ability to prove balances > held on the lightning network, but I suspect that isn't generally possible.  Thinking about this in terms of economic logic: Every channel is anchored onchain, and that anchor (the funding txout

[bitcoin-dev] Proof of reserves - recording

I had the idea recently for proof of reserves done in a way that can be used to verify reserves are sufficient on an ongoing basis. I'm curious if there are any current approaches out there to proof of reserves that are similar. The idea is to have users

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

Hi ZmnSCPxj, I don't believe we need to ban Turing completeness for the sake of banning Turing completeness. My concerns have always been around ensuring that transaction and block validation is not unduly burdensome for nodes. So for Bitcoin Script, we want to bound the amount of resources need

[bitcoin-dev] Fee estimation requirements

At https://github.com/bitcoin/bitcoin/issues/22404#issuecomment-874168305 no explanation is given for a peculiar rule about estimating fees, that "you have to wait around for a couple of blocks *after* being synced before fee estimation will work." The rule is true, but it needn't be true, and the

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

Funny AJ mentions the multisig idea, because I know for a fact it's being used in certain permissioned systems in this exact way. Regulators will dream up these ideas with or without more useful covenants! On Mon, Jul 5, 2021 at 9:46 PM Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundat

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

I find this point to be incredibly important. Indeed I, like several others, have historically been concerned with covenants in the unbounded form. However, as more and more research has been done in what they can accomplish, the weighting of such arguments naturally has to be reduced. More impor