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

[Eric Voskuil via bitcoin-dev]

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 if both participants in the channel sign a correct statement 
>> of truth, one of the participants can send funds out in the next second, 
>> invalidating that truth. While proof of ownership of on-chain UTXOs can be 
>> seen publicly in real time if they are spent, LN transactions aren't public 
>> like that. So any balance attestation is at best only valid the instant its 
>> taken, and can't be used as verification the money is still owned by the 
>> same channel partner in the next second. 
> 
> The same problem really also exists onchain --- a thief (or "thief") who has 
> gotten a copy of the key can sign a transaction that spends it, one second 
> after the proof-of-reserves is made.
> 
> Really, though, the issue is that ownership of funds is conditional on 
> *knowledge* of keys.
> And *knowledge* is easily copyable.
> 
> Thus, it is possible that the funds that are "proven" to be the reserve of a 
> custodian is actually *also* owned by someone else who has gotten to the 
> privkeys (e.g. somebody threw a copy of it from a boating accident and a 
> fearless scuba diver rescued it), and thus can also move the funds outside of 
> the control of the custodian.
> This condition can remain for many months or years, as well, without 
> knowledge of the custodian clients, *or* of the custodian itself.
> 
> There is no way to prove that there is no alternate copy of the privkeys, 
> hence "if only one could prove that he won't get into a boating accident".
> 
> On the other hand, one could argue that at least the onchain proof requires 
> more conditions to occur, so we might plausibly live with "we cannot prove we 
> will never get into a boating accident but we can show evidence that we live 
> in a landlocked city far from any lakes, seas, or rivers".
> 
> Regards,
> ZmnSCPxj
> 
>> 
>>>   a custodian Lightning node is unable to "freeze" a snapshot of its 
>>> current state and make an atomic proof-of-reserves of *all* channels
>> 
>> That would be a neat trick. But yeah, I don't know how that would be 
>> possible. 
>> 
>>>   I believe it is one reason why custodian proof-of-reserves is not that 
>>> popular ... it does not prove that the key will not get lost
>> 
>> True, but at least if funds do get lost, it would be come clear far quicker. 
>> Today, an insolvent company could go many months without the public finding 
>> out. 
>> 
>> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj  wrote:
>> 
>>> 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 to unilaterally 
>>> close the channel, which reveals the exact amounts (though not necessarily 
>>> who owns which).
>>> If the other party then uses its funds in a new proof-of-reserves, then 
>>> obviously the other output of the unilateral close was the one lost in the 
>>> boating accident.
>>> 
>>> On the other hand, yes, custodians losing custodied funds in boating 
>>> accidents is much too common.
>>> I believe it is one reason why custodian proof-of-reserves is not that 
>>> popular --- it only proves that the funds were owned under a particular key 
>>> at some snapshot of the past, it does not prove that the key will not get 
>>> lost (or "lost and then salvaged by a scuba diver") later.
>>> 
>>> Regards,
>>> ZmnSCPxj
>>> 
 
 e
 
> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev 
> bitcoin-dev@lists.linuxfoundation.org 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 isn't 
>> generally possible.
> 
> Thinking about this in terms of economic logic:
> Every channel is anchored onchain, and that anchor (the funding txout) is 
> proof of the existence, and size, of the channel.
> The two participants in the channel can sign a plaintext containing their 
> node pubkeys and how much each owns.
> One of the participants should provably be the custodian.
> 
> -   If the counterparty is a true third party, it has no incentive to lie 
> about its money.
> -   Especially if the counterparty is another custodian who wants 
> proof-of-reserves, it has every incentive to overreport, but then the 
> first party will refuse to sign.
>  It has a disincentive to underreport, and would itself refuse to 
> sign a dishonest report that assigns more funds to the first party.
>  The 

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

[ZmnSCPxj via bitcoin-dev]

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, 
> invalidating that truth. While proof of ownership of on-chain UTXOs can be 
> seen publicly in real time if they are spent, LN transactions aren't public 
> like that. So any balance attestation is at best only valid the instant its 
> taken, and can't be used as verification the money is still owned by the same 
> channel partner in the next second. 

The same problem really also exists onchain --- a thief (or "thief") who has 
gotten a copy of the key can sign a transaction that spends it, one second 
after the proof-of-reserves is made.

Really, though, the issue is that ownership of funds is conditional on 
*knowledge* of keys.
And *knowledge* is easily copyable.

Thus, it is possible that the funds that are "proven" to be the reserve of a 
custodian is actually *also* owned by someone else who has gotten to the 
privkeys (e.g. somebody threw a copy of it from a boating accident and a 
fearless scuba diver rescued it), and thus can also move the funds outside of 
the control of the custodian.
This condition can remain for many months or years, as well, without knowledge 
of the custodian clients, *or* of the custodian itself.

There is no way to prove that there is no alternate copy of the privkeys, hence 
"if only one could prove that he won't get into a boating accident".

On the other hand, one could argue that at least the onchain proof requires 
more conditions to occur, so we might plausibly live with "we cannot prove we 
will never get into a boating accident but we can show evidence that we live in 
a landlocked city far from any lakes, seas, or rivers".

Regards,
ZmnSCPxj

>
> >  a custodian Lightning node is unable to "freeze" a snapshot of its current 
> >state and make an atomic proof-of-reserves of *all* channels
>
> That would be a neat trick. But yeah, I don't know how that would be 
> possible. 
>
> >  I believe it is one reason why custodian proof-of-reserves is not that 
> >popular ... it does not prove that the key will not get lost
>
> True, but at least if funds do get lost, it would be come clear far quicker. 
> Today, an insolvent company could go many months without the public finding 
> out. 
>
> On Mon, Jul 5, 2021 at 5:09 PM ZmnSCPxj  wrote:
>
> > 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 to unilaterally 
> > close the channel, which reveals the exact amounts (though not necessarily 
> > who owns which).
> > If the other party then uses its funds in a new proof-of-reserves, then 
> > obviously the other output of the unilateral close was the one lost in the 
> > boating accident.
> >
> > On the other hand, yes, custodians losing custodied funds in boating 
> > accidents is much too common.
> > I believe it is one reason why custodian proof-of-reserves is not that 
> > popular --- it only proves that the funds were owned under a particular key 
> > at some snapshot of the past, it does not prove that the key will not get 
> > lost (or "lost and then salvaged by a scuba diver") later.
> >
> > Regards,
> > ZmnSCPxj
> >
> > >
> > > e
> > >
> > > > On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev 
> > > > bitcoin-dev@lists.linuxfoundation.org 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 isn't 
> > > > > generally possible.
> > > >
> > > > Thinking about this in terms of economic logic:
> > > > Every channel is anchored onchain, and that anchor (the funding txout) 
> > > > is proof of the existence, and size, of the channel.
> > > > The two participants in the channel can sign a plaintext containing 
> > > > their node pubkeys and how much each owns.
> > > > One of the participants should provably be the custodian.
> > > >
> > > > -   If the counterparty is a true third party, it has no incentive to 
> > > > lie about its money.
> > > > -   Especially if the counterparty is another custodian who wants 
> > > > proof-of-reserves, it has every incentive to overreport, but then the 
> > > > first party will refuse to sign.
> > > >     It has a disincentive to underreport, and would itself refuse to 
> > > >sign a dishonest report that assigns more funds to the first party.
> > > >     The only case that would be acceptable to both custodians would be 
> > > >to honestly report their holdings in the Lightning channel.
> > > >
> > > > -   If the counterparty is a 

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

[ZmnSCPxj via bitcoin-dev]

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 to unilaterally close 
the channel, which reveals the exact amounts (though not necessarily who owns 
which).
If the other party then uses its funds in a new proof-of-reserves, then 
obviously the other output of the unilateral close was the one lost in the 
boating accident.

On the other hand, yes, custodians losing custodied funds in boating accidents 
is much too common.
I believe it is one reason why custodian proof-of-reserves is not that popular 
--- it only proves that the funds were owned under a particular key at some 
snapshot of the past, it does not prove that the key will not get lost (or 
"lost and then salvaged by a scuba diver") later.


Regards,
ZmnSCPxj

>
> e
>
> > On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev 
> > bitcoin-dev@lists.linuxfoundation.org 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 isn't 
> > > generally possible.
> >
> > Thinking about this in terms of economic logic:
> > Every channel is anchored onchain, and that anchor (the funding txout) is 
> > proof of the existence, and size, of the channel.
> > The two participants in the channel can sign a plaintext containing their 
> > node pubkeys and how much each owns.
> > One of the participants should provably be the custodian.
> >
> > -   If the counterparty is a true third party, it has no incentive to lie 
> > about its money.
> > -   Especially if the counterparty is another custodian who wants 
> > proof-of-reserves, it has every incentive to overreport, but then the first 
> > party will refuse to sign.
> > It has a disincentive to underreport, and would itself refuse to sign a 
> > dishonest report that assigns more funds to the first party.
> > The only case that would be acceptable to both custodians would be to 
> > honestly report their holdings in the Lightning channel.
> >
> > -   If the counterparty is a sockpuppet of the custodian, then the entire 
> > channel is owned by the custodian and it would be fairly dumb of he 
> > custodian to claim to have less funds than the entire channel.
> >
> > Perhaps a more practical problem is that Lightning channel states change 
> > fairly quickly, and there are possible race conditions, due to network 
> > latency (remember, both nodes need to sign, meaning both of them need to 
> > communicate with each other, thus hit by network latency and other race 
> > conditions) where a custodian Lightning node is unable to "freeze" a 
> > snapshot of its current state and make an atomic proof-of-reserves of all 
> > channels.
> > Regards,
> > ZmnSCPxj
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

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 isn't generally possible. 
> 
> Thinking about this in terms of economic logic:
> 
> Every channel is anchored onchain, and that anchor (the funding txout) is 
> proof of the existence, and size, of the channel.
> 
> The two participants in the channel can sign a plaintext containing their 
> node pubkeys and how much each owns.
> One of the participants should provably be the custodian.
> 
> * If the counterparty is a true third party, it has no incentive to lie about 
> its money.
>  * Especially if the counterparty is *another* custodian who wants 
> proof-of-reserves, it has every incentive to overreport, but then the first 
> party will refuse to sign.
>It has a disincentive to underreport, and would itself refuse to sign a 
> dishonest report that assigns more funds to the first party.
>The only case that would be acceptable to both custodians would be to 
> honestly report their holdings in the Lightning channel.
> * If the counterparty is a sockpuppet of the custodian, then the entire 
> channel is owned by the custodian and it would be fairly dumb of he custodian 
> to claim to have less funds than the entire channel.
> 
> Perhaps a more practical problem is that Lightning channel states change 
> fairly quickly, and there are possible race conditions, due to network 
> latency (remember, both nodes need to sign, meaning both of them need to 
> communicate with each other, thus hit by network latency and other race 
> conditions) where a custodian Lightning node is unable to "freeze" a snapshot 
> of its current state and make an atomic proof-of-reserves of *all* channels.
> 
> Regards,
> ZmnSCPxj
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[ZmnSCPxj via bitcoin-dev]

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) is proof 
of the existence, and size, of the channel.

The two participants in the channel can sign a plaintext containing their node 
pubkeys and how much each owns.
One of the participants should provably be the custodian.

* If the counterparty is a true third party, it has no incentive to lie about 
its money.
  * Especially if the counterparty is *another* custodian who wants 
proof-of-reserves, it has every incentive to overreport, but then the first 
party will refuse to sign.
It has a disincentive to underreport, and would itself refuse to sign a 
dishonest report that assigns more funds to the first party.
The only case that would be acceptable to both custodians would be to 
honestly report their holdings in the Lightning channel.
* If the counterparty is a sockpuppet of the custodian, then the entire channel 
is owned by the custodian and it would be fairly dumb of he custodian to claim 
to have less funds than the entire channel.

Perhaps a more practical problem is that Lightning channel states change fairly 
quickly, and there are possible race conditions, due to network latency 
(remember, both nodes need to sign, meaning both of them need to communicate 
with each other, thus hit by network latency and other race conditions) where a 
custodian Lightning node is unable to "freeze" a snapshot of its current state 
and make an atomic proof-of-reserves of *all* channels.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Proof of reserves - recording

[Billy Tetrud via bitcoin-dev]

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 create actual private keys using a seed in pretty
much the normal way. Users would generate a public key from this seed to
represent their account, and would give the public key to the custodian to
represent their account in a public record of account balances.

When a user's account is credited, the custodian would update a map of
addresses (created from the public key of each account) to balances - this
map could be structured into a merkle tree in the usual "merkle approach".
The custodian would also store funds on one or more HD wallets (each with
many addresses) and create a proof that they own each HD wallet. The proof
could be as simple as a single signature created with the xpub for the
wallet, which would be sufficient for proving ownership over the whole
list/tree of addresses.

These two structures (the map and the HD wallet) would be combined and
hashed, and the hash published in an on chain transaction (possibly along
with a URI where the full data can be found), on something like a daily
basis. Software for each user could continuously validate that their
account has a balance that matches what it's supposed to have, and could
also verify that owned addresses have funds that have at least as many
coins as promised to accounts. If these things aren't verifiable (either
because the balances total to more than the HD wallet contains, or because
of data unavailability), people can raise hell about it.

To give user's additional proving ability, a receipt system could be added.
Users could request a receipt for any balance update. Eg the user would
create a message with a timestamp, their custodial "address", and the new
balance. The user would sign this receipt and send it to the custodian, who
would also sign it and send it back. This way, if something goes wrong, a
user can use this signed receipt to show that the custodian did in fact
promise a new updated balance at a particular time (which would cover the
case that the custodian records the wrong value in their map). Conversely,
the receipt would be useful to honest custodians as well, since they could
show the user's signed receipt request in the case a user is trying to lie
about what balance they should have. There is still the case that the
custodian simply refuses to return a signed receipt, in which case the
user's only recourse is to yell about it immediately and demand a receipt
or a refund.

Why record it on chain? Doing that gives a clear record of proof of
reserves that can be verified later by anyone in the future. It prevents a
custodian from being able to change history when it suits them (by creating
a new records with false timestamps in the past). Many of these records
could be aggregated together and recorded in the same transaction (with a
single hash), so a single transaction per day could record the records of
all participating custodians. If all custodians are using a standard
system, one can cross verify that addresses claimed by one custodian aren't
also claimed by another custodian.

Even tho the user is responsible for their keys in order to properly
verify, losing the keys isn't that big of a deal, since they could simply
create a new seed and give a new public key to the custodian - who would
have other identifying information they could use to validate that they own
the account. So it places less responsibility on the user, while still
introducing people, in a light-weight way, to self custody of keys.

Having a record like this every day would reduce the possibility of
shenanigans like taking a short term loan of a large amount of
cryptocurrency. Sure, they could take a 10 minute loan once per day, but it
would also be possible to trace on-chain transactions so you could tell if
such a thing was going on. 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.

In any case, I'm curious what people think of this kind of thing, and if
systems with similar properties are already out there.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Russell O'Connor via bitcoin-dev]

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 needed to
execute it, preferably as a linear function of weight[1], and preferably
have it clear what the evaluation costs are going to be prior to
evaluation[2].  We also want to keep Script execution as a pure function of
the transaction data so that nodes do not need to reevaluate their mempool
on every new block.  For consensus purposes we prefer to have simple
primitive operations that have clear and precise semantics that are as
likely as possible to be reimplemented correctly if they are reimplemented
(or at least let us not make this problem worse than it already is).  In
particular, Script needs to be easy to parse to avoid weird parsing
machines that lead to security vulnerabilities within node software.

While the above design constraints imply a prohibition on Turing complete
computation within a single Script, they do not imply a prohibition on
arbitrary, covenant-enabled computations that spans across multiple
transactions.  Neither would these constraints prohibit some kind of STARK
or SNARK tapleaf version that was somehow capable of succinctly
representing arbitrary computations, so long as validation costs remain
bounded.

And while it is true that covenant-enabled computations could allow users
to put their funds at risk through weird machines that manipulate their
money on the blockchain, as longs as that weirdness stays at that level of
the abstract Bitcoin Script machine, then I suppose it is *caveat emptor*;
don't send your funds to random unverified Bitcoin Scripts, advice that is
already the case today.  We can keep that potential weirdness at bay by
keeping Script simple, and maintaining our understanding that the Script
programs (like the rest of the blockchain data) are untrusted inputs and
they need to be validated and scrutinized before interpretation.

[1] In tapscript I believe all operations are linear time with the
exception of OP_ROLL.  However OP_ROLL is still constrained by global
limits on stack size, etc.
[2] In Bitcoin Script, without loops of any kind, every opcode is evaluated
at most once, so counting opcodes is an easy way to put an upper bound on
your costs before evaluation.

On Sun, Jul 4, 2021 at 8:51 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Dave,
>
> > On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote:
> >
> > > However, I think the broader community is unconvinced by the cost
> benefit
> > > of arbitrary covenants. See
> > >
> https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6
> > > as a recent example. Therefore as a critical part of building
> consensus on
> > > various techniques I've worked to emphasize that specific additions do
> not
> > > entail risk of accidentally introducing more than was bargained for to
> > > respect the concerns of others.
> >
> > Respecting the concerns of others doesn't require lobotomizing useful
> > tools. Being respectful can also be accomplished by politely showing
> > that their concerns are unfounded (or at least less severe than they
> > thought). This is almost always the better course IMO---it takes much
> > more effort to satisfy additional engineering constraints (and prove to
> > reviewers that you've done so!) than it does to simply discuss those
> > concerns with reasonable stakeholders. As a demonstration, let's look
> > at the concerns from Shinobi's post linked above:
> >
> > They seem to be worried that some Bitcoin users will choose to accept
> > coins that can't subsequently be fungibily mixed with other bitcoins.
> > But that's already been the case for a decade: users can accept altcoins
> > that are non-fungible with bitcoins.
> >
> > They talk about covenants where spending is controlled by governments,
> > but that seems to me exactly like China's CBDC trial.
> >
> > They talk about exchanges depositing users' BTC into a covenant, but
> > that's just a variation on the classic not-your-keys-not-your-bitcoins
> > problem. For all you know, your local exchange is keeping most of its
> > BTC balance commitments in ETH or USDT.
> >
> > To me, it seems like the worst-case problems Shinobi describes with
> > covenants are some of the same problems that already exist with
> > altcoins. I don't see how recursive covenants could make any of those
> > problems worse, and so I don't see any point in limiting Bitcoin's
> > flexibility to avoid those problems when there are so many interesting
> > and useful things that unlimited covenants could do.
>
> The "altcoins are even worse" argument does seem quite convincing, and if
> Bitcoin can survive altcoins, surely it can survive covenants too?
>
> In before "turns out 

[bitcoin-dev] Fee estimation requirements

[Dave Scotese via bitcoin-dev]

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
software would be more useful if it were not true.  If it does seem
impossible to break this rule, perhaps some brainstorming is in order.  I
estimate fees quite often on my own, although I am trusting the block
explorers in their reporting of the fees for the most recent blocks.  The
software doesn't need to trust anything once it has been synced.

If this is simply a matter of priorities, it would be useful to point that
out.

Dave.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Greg Sanders via bitcoin-dev]

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.linuxfoundation.org> wrote:

> 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 importantly,
> AJ's point here neuters anti-covanent
> arguments rather strongly.
>
> Matt
>
> On 7/5/21 01:04, Anthony Towns via bitcoin-dev wrote:
> > On Sun, Jul 04, 2021 at 09:02:25PM -0400, Russell O'Connor via
> bitcoin-dev wrote:
> >> Bear in mind that when people are talking about enabling covenants, we
> are
> >> talking about whether OP_CAT should be allowed or not.
> >
> > In some sense multisig *alone* enables recursive covenants: a government
> > that wants to enforce KYC can require that funds be deposited into
> > a multisig of "2   2 CHECKMULTISIG", and that
> > "recipient" has gone through KYC. Once deposited to such an address,
> > the gov can refus to sign with gov_key unless the funds are being spent
> > to a new address that follows the same rules.
> >
> > (That's also more efficient than an explicit covenant since it's all
> > off-chain -- recipient/gov_key can jointly sign via taproot/MuSig at
> > that point, so that full nodes are only validating a single pubkey and
> > signature per spend, rather than having to do analysis of whatever the
> > underlying covenant is supposed to be [0])
> >
> > This is essentially what Liquid already does -- it locks bitcoins into
> > a multisig and enforces an "off-chain" covenant that those bitcoins can
> > only be redeemed after some valid set of signatures are entered into
> > the Liquid blockchain. Likewise for the various BTC-on-Ethereum tokens.
> > To some extent, likewise for coins held in exchanges/custodial wallets
> > where funds can be transferred between customers off-chain.
> >
> > You can "escape" from that recursive covenant by having the government
> > (or Liquid functionaries, or exchange admins) change their signing
> > policy of course; but you could equally escape any consensus-enforced
> > covenant by having a hard fork to stop doing consensus-enforcement (cf
> > ETH Classic?). To me, that looks more like a difference of procedure
> > and difficulty, rather than a fundamental difference in kind.
> >
> > Cheers,
> > aj
> >
> > [0] https://twitter.com/pwuille/status/1411533549224693762
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Matt Corallo via bitcoin-dev]

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 importantly, AJ's point here neuters anti-covanent 
arguments rather strongly.


Matt

On 7/5/21 01:04, Anthony Towns via bitcoin-dev wrote:

On Sun, Jul 04, 2021 at 09:02:25PM -0400, Russell O'Connor via bitcoin-dev 
wrote:

Bear in mind that when people are talking about enabling covenants, we are
talking about whether OP_CAT should be allowed or not.


In some sense multisig *alone* enables recursive covenants: a government
that wants to enforce KYC can require that funds be deposited into
a multisig of "2   2 CHECKMULTISIG", and that
"recipient" has gone through KYC. Once deposited to such an address,
the gov can refus to sign with gov_key unless the funds are being spent
to a new address that follows the same rules.

(That's also more efficient than an explicit covenant since it's all
off-chain -- recipient/gov_key can jointly sign via taproot/MuSig at
that point, so that full nodes are only validating a single pubkey and
signature per spend, rather than having to do analysis of whatever the
underlying covenant is supposed to be [0])

This is essentially what Liquid already does -- it locks bitcoins into
a multisig and enforces an "off-chain" covenant that those bitcoins can
only be redeemed after some valid set of signatures are entered into
the Liquid blockchain. Likewise for the various BTC-on-Ethereum tokens.
To some extent, likewise for coins held in exchanges/custodial wallets
where funds can be transferred between customers off-chain.

You can "escape" from that recursive covenant by having the government
(or Liquid functionaries, or exchange admins) change their signing
policy of course; but you could equally escape any consensus-enforced
covenant by having a hard fork to stop doing consensus-enforcement (cf
ETH Classic?). To me, that looks more like a difference of procedure
and difficulty, rather than a fundamental difference in kind.

Cheers,
aj

[0] https://twitter.com/pwuille/status/1411533549224693762

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev