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

[Eric Voskuil via bitcoin-dev]

> @Eric
> Auditability Fallacy
> 
> > A solvency audit requires simultaneous (atomic) proof of both the full 
> > amount of the asset held by a custodian and the securities issued against 
> > it.
> 
> > in the case where the security is issued on a distinct public chain the 
> > atomicity requirement is not satisfied.
> 
> I think what its saying is that you can't get atomicity of both the security 
> and the reserve. While this is true, what you can get is a system where the 
> order of events can be established to a degree of precision. Ie, you can know 
> that between reserve-snapshot A and B, the balances add up to X. Each user 
> can validate that their balance was indeed that value between A and B. With 
> reserve snapshots and balance snapshots frequent enough, this can allow 
> reasonably high accuracy of estimated solvency. However, it does seem clear 
> that perfect accuracy is not possible.

If perfect is not possible, it’s not possible. It reduces to trust, which is 
the status quo.

All “users” need to simultaneously share their individual and temporary audits 
with each other (ie publicly).

> > Historically it has not been difficult to detect such deviations. The 
> > difficulty arises in stopping them.
> 
> I disagree here that it has not been difficult to detect deviations 
> (insolvency).

It is not hard to spot price inflation. Stopping or avoiding it is the actual 
issue. No “proof” of reserve can do this. The federal reserve was clearly 
insolvent from its early days, as that was its purpose.

> I mean, "difficulty" isn't the right word. These things always become clear 
> eventually. But I think its important to detect insolvency quickly. 
> Historically insolvency has certainly not been detected quickly. Insolvency 
> is instead practically perpetual, and the question is only how insolvent and 
> when will it explode?

There is no “proof” that answers this question.

> I'm of the opinion that you can't prevent insolvency.

It’s not a matter of opinion. Lending implies risk. When you invest you are in 
fact the owner of the insolvency, not someone else.

> Places will have money troubles and will try to cover it up, since usually 
> there is no downside (admitting insolvency can lead to bankrupcy, and failure 
> to conceal insolvency has the same result - so why not try to conceal it and 
> hope you can shore it up). However, its important that people know the 
> institutions they have their money in are insolvent, or to what degree they 
> are. If that information were well tracked, it could become clear over time 
> that a 10% insolvent company rarely goes out of business, but a 20% insolvent 
> company usually does.

Nonsense, any business can fail, regardless of temporal cash reserves.

> Then people can have parameters where they're ok with a certain measurable 
> degree of insolvency, but react swiftly and strongly when a company is too 
> reckless. Currently the amount of recklessness any given company engages in 
> is basically a company secret that their clients don't have insight into. PoR 
> would greatly help this I think. You don't think so? 

Reckless is a subjective term. Proofs will not insure any investment.

e

>> On Mon, Jul 5, 2021 at 10:10 PM Eric Voskuil  wrote:
>> 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 

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

[Billy Tetrud via bitcoin-dev]

@ ZmnSCPxj, Good Evening

>  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.

>  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 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] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

[Billy Tetrud via bitcoin-dev]

>  when people are talking about enabling covenants, we are talking about
whether OP_CAT should be allowed or not

Are they? Are you implying that anything that enables covenants is
equivalent to enabling OP_CAT? Generally when I think about enabling
covenants, I'm thinking more about OP_CTV (or some similarly specific opcode

).

> OP_TWEAK

I wasn't able to find anything about what that is. Would you mind
clarifying what that concept is?

On Mon, Jul 5, 2021 at 10:20 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 

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

[Billy Tetrud via bitcoin-dev]

@ZmnSCPxj
>  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.

Sure, but anyone can easily see that transaction happen and can discount
that part of the attestation. The same isn't true on lightning.

> *knowledge* is easily copyable.

Knowledge isn't even really needed. Custodians could collude to sign each
other's balance attestations. However, if the network of proof of reserves
is cohesive, people could validate that addresses (and their balances)
aren't shared by anyone that's part of that PoR network.

> There is no way to prove that there is no alternate copy of the privkeys

Well there are only really 2 cases:

1. Only one entity has the keys
2. Two entities have the keys and trust each other

In case 1, the attestation is accurate. In case 2, its really another way
of saying case 1: you can view the two trusting entities as a single
entity. In the case there are 2 non-trusting entities, its very likely that
one would steal from the other, or that they would be very uncomfortable
with the situation such that it wouldn't last long.

But you can't prove that someone won't steal the reserves. You can't prove
cryptographically that the reserves aren't promised to someone else in a
legal contract (unless of course you make the proof of reserves system
legally binding). But this is why anyone that recommends PoR also
recommends independent audits to attest that the PoR actually matches
reality.

So yes, there are limitations, but I don't think that means that PoR isn't
worth doing. Is that what you're implying?

> we can show evidence that we live in a landlocked city far from any
lakes, seas, or rivers

I think that's the idea, if I understand you correctly.

@Eric
Auditability Fallacy


> A solvency audit requires simultaneous (atomic) proof of both the full
amount of the asset held by a custodian and the securities issued against
it.

> in the case where the security is issued on a distinct public chain the
atomicity requirement is not satisfied.

I think what its saying is that you can't get atomicity of both the
security and the reserve. While this is true, what you can get is a system
where the order of events can be established to a degree of precision. Ie,
you can know that between reserve-snapshot A and B, the balances add up to
X. Each user can validate that their balance was indeed that value between
A and B. With reserve snapshots and balance snapshots frequent enough, this
can allow reasonably high accuracy of estimated solvency. However, it does
seem clear that perfect accuracy is not possible.

> Historically it has not been difficult to detect such deviations. The
difficulty arises in stopping them.

I disagree here that it has not been difficult to detect deviations
(insolvency). I mean, "difficulty" isn't the right word. These things
always become clear eventually. But I think its important to detect
insolvency quickly. Historically insolvency has certainly not been detected
quickly. Insolvency is instead practically perpetual, and the question is
only how insolvent and when will it explode?

I'm of the opinion that you can't prevent insolvency. Places will have
money troubles and will try to cover it up, since usually there is no
downside (admitting insolvency can lead to bankrupcy, and failure to
conceal insolvency has the same result - so why not try to conceal it and
hope you can shore it up). However, its important that people know the
institutions they have their money in are insolvent, or to what degree they
are. If that information were well tracked, it could become clear over time
that a 10% insolvent company rarely goes out of business, but a 20%
insolvent company usually does. Then people can have parameters where
they're ok with a certain measurable degree of insolvency, but react
swiftly and strongly when a company is too reckless. Currently the amount
of recklessness any given company engages in is basically a company secret
that their clients don't have insight into. PoR would greatly help this I
think. You don't think so?

On Mon, Jul 5, 2021 at 10:10 PM Eric Voskuil  wrote:

> 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 cha

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

[Sanket Kanjalkar via bitcoin-dev]

After some brainstorming about the possible drawbacks of enabling
covenants, I have also slowly become more comfortable with the idea of
"unlimited" covenants. AJs example clearly shows that _all_ possible
"misuses" of covenants are already possible by Multi-Sig today, so it's not
a new vector that we are adding today.

>  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.

Many bitcoin upgrades, in particular, Segwit, and tapscript sigops budget
have been along with the same principle. And as mentioned before, none of
these go against enabling recursive covenants.

> Are they? Are you implying that anything that enables covenants is
equivalent to enabling OP_CAT?

No, it is not equivalent. Russell is referring to a way to do covenants by
only using `OP_CAT`(along with Schnorr sigs that we already have) as
mentioned by Andrew Poelstra here
 .

I also am in general support of the `OP_CHECKSIGFROMSTACK` opcode. We would
need to update the suggestion to BIP340, and add it to sigops budget. I
have no strong preference for splitting R and s values or variable-length
messages.


On Tue, Jul 6, 2021 at 1:36 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >  when people are talking about enabling covenants, we are talking about
> whether OP_CAT should be allowed or not
>
> Are they? Are you implying that anything that enables covenants is
> equivalent to enabling OP_CAT? Generally when I think about enabling
> covenants, I'm thinking more about OP_CTV (or some similarly specific
> opcode
> 
> ).
>
> > OP_TWEAK
>
> I wasn't able to find anything about what that is. Would you mind
> clarifying what that concept is?
>
> On Mon, Jul 5, 2021 at 10:20 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 

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

[Russell O'Connor via bitcoin-dev]

On Tue, Jul 6, 2021 at 2:26 AM Billy Tetrud  wrote:

> >  when people are talking about enabling covenants, we are talking about
> whether OP_CAT should be allowed or not
>
> Are they? Are you implying that anything that enables covenants is
> equivalent to enabling OP_CAT? Generally when I think about enabling
> covenants, I'm thinking more about OP_CTV (or some similarly specific
> opcode
> 
> ).
>
> > OP_TWEAK
>
> I wasn't able to find anything about what that is. Would you mind
> clarifying what that concept is?
>

In tapscript one can generally recover the current input's scriptPubkey
through sighash introspection via the usual covenant tricks.  This allows
you to make a recursive covenant by spending funds back to the same
identical scriptPubkey.  However, in order for a recursive covenant to be
actually interesting, there needs to be some sort of state update in each
transition.  If there is no state update then sending funds back to itself
is of very limited value.  It will reset the timer on relative locks, but
that is about all.

The "normal" way of writing useful recursive covenants is to modify the
scriptPubkey by changing a fragment of it that contains some sort of
state.  However in order to update a tapscript pubkey one needs to apply
not only hashing, to create a Merkel root, but also to create a tweaked
taproot pubkey that commits to this root.  While script currently comes
with a SHA-256 hashing opcode, there is no opcode that will let you perform
the necessary tweaking to create a taproot scriptPubkey.

But as I mentioned afterwards, there are other places in the UTXO that you
could put data in order to perform a state update.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

[Jeremy via bitcoin-dev]

Re-threading Sanket's comment on split R value:

I also am in general support of the `OP_CHECKSIGFROMSTACK` opcode. We would
> need to update the suggestion to BIP340, and add it to sigops budget. I
> have no strong preference for splitting R and s values or variable-length
> messages.
>

Back to my comment:


I see a few options:

1) Making a new 64 byte PK standard which is (R, PK)
2) Splitting (R,S)
3) Different opcodes
4) CAT

The drawback of option 1 is that it's designed to support only very
specific use cases. The main drawback of splitting via option 2 is that you
entail an extra push byte for every use. Option 3 wastes opcodes. CAT has
the general drawbacks of CAT, but worth noting that CAT will likely
eventually land making the splitting feature redundant.


Before getting too in the weeds, it might be worth listing out interesting
script fragments that people are aware of with split R/S so we can see how
useful it might be?

Use a specific R Value
-   ||  SWAP  CSFS

Reuse arbitrary R for a specific M (pay to leak key)
-  ||  DUP2 EQUAL NOT VERIFY 2 PICK SWAP  DUP TOALTSTACK
CSFSV FROMALTSTACK CSFS

Verify 2 different messages reuse the same R.
-  ||  2 PICK EQUAL NOT VERIFY 3 PICK  DUP
TOALTSTACK CSFSV FROMALTSTACK CSFS

Use a R Value signed by an oracle:
-  || DUP TOALTSTACK  CSFSV
FROMALTSTACK SWAP  CSFS
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

[Russell O'Connor via bitcoin-dev]

If the main outstanding issue is whether to split R or S, I think as far as
Elements goes, I am inclined to go with the CAT option regardless of
whether Bitcoin chooses to split R/S or not (not that I'm necessarily a
decision maker here).

The issue here is that (a) Elements already has CAT, and (b) updating
CHECKSIGFROMSTACK is effectively a blocking issue for deploying Taproot on
Elements.  I don't think we will be holding up CHECKSIGFROMSTACK for this
issue even if it risks being incompatible with an eventual Bitcoin
CHECKSIGFROMSTACK.

To be clear, I don't mean to prejudice this discussion by this statement.
This just happens to be what makes sense for the Elements project at this
time, and what makes sense for Elements may not necessarily make sense for
Bitcoin.

Of course, I think we should just go for CAT compatibility.  Otherwise we
are just going to have a proliferation of trusted CAT oracles paid for with
lightning by people wanting to perform CAT operations.

On Tue, Jul 6, 2021 at 1:55 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Re-threading Sanket's comment on split R value:
>
> I also am in general support of the `OP_CHECKSIGFROMSTACK` opcode. We
>> would need to update the suggestion to BIP340, and add it to sigops budget.
>> I have no strong preference for splitting R and s values or variable-length
>> messages.
>>
>
> Back to my comment:
>
>
> I see a few options:
>
> 1) Making a new 64 byte PK standard which is (R, PK)
> 2) Splitting (R,S)
> 3) Different opcodes
> 4) CAT
>
> The drawback of option 1 is that it's designed to support only very
> specific use cases. The main drawback of splitting via option 2 is that you
> entail an extra push byte for every use. Option 3 wastes opcodes. CAT has
> the general drawbacks of CAT, but worth noting that CAT will likely
> eventually land making the splitting feature redundant.
>
>
> Before getting too in the weeds, it might be worth listing out interesting
> script fragments that people are aware of with split R/S so we can see how
> useful it might be?
>
> Use a specific R Value
> -   ||  SWAP  CSFS
>
> Reuse arbitrary R for a specific M (pay to leak key)
> -  ||  DUP2 EQUAL NOT VERIFY 2 PICK SWAP  DUP TOALTSTACK
> CSFSV FROMALTSTACK CSFS
>
> Verify 2 different messages reuse the same R.
> -  ||  2 PICK EQUAL NOT VERIFY 3 PICK  DUP
> TOALTSTACK CSFSV FROMALTSTACK CSFS
>
> Use a R Value signed by an oracle:
> -  || DUP TOALTSTACK  CSFSV
> FROMALTSTACK SWAP  CSFS
>
> ___
> 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

[Erik Aronesty via bitcoin-dev]

you should check out some of the earlier work done here:

https://github.com/olalonde/proof-of-solvency#assets-proof

to be honest, if any exchange supported that proof, it would be more
than enough.

there's really no way to prevent a smash-and-grab, but this does
prevent a slow-leak


On Mon, Jul 5, 2021 at 5:10 PM Billy Tetrud via bitcoin-dev
 wrote:
>
> 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.linuxfou

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

[Jeremy via bitcoin-dev]

heh -- I pointed out these evil multisig covenants in 2015 :)
https://medium.com/@jeremyrubin/regulating-bitcoin-by-mining-the-regulator-miner-attack-c8fd51185b78
I'm relatively unconcerned by it except to the extent that mining
centralizes to the point of censoring other traffic.

Overall, I think this is a great conversation to be having.

However, I want to push back on David's claim that  "Respecting the
concerns of others doesn't require lobotomizing useful tools.".

CHECKSIGFROMSTACK is a primitive and the opcode is not being nerfed in any
way shape or form. The argument here is that doing CSFS and not CAT is
nerfing CSFS... but CSFS is an independently useful and cool opcode that
has many of it's own merits.

Further, as described in my [blog post](
https://rubin.io/blog/2021/07/02/covenants/), CSFS has very high "design
specificity"... that is there's not *that* many design choices that could
possibly go into it. It's checking a signature. From the stack. That's all
folks! There are no design compromises in it. No lobotomy.

OP_CAT is more or less completely unrelated to CSFS. As Andrew has
[demonstrated](
https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html),
*just* OP_CAT alone (no CSFS) gives you covenants (albeit in a hacky way)
with Schnorr.

I think roconnor agrees that CAT(+CSFS?) are not really a "fantastic" way
to do covenants, that there are more direct approaches that will be better
or neccessary such as TWEAK or UPDATETAPLEAF. Let's work on those! But
let's also not hold up progress on other useful things while those are
brewing.

Non-Redundancy should be a non-goal for script -- although we strive to be
minimal, redundancy is inevitable. For example, OP_SWAP has identical
semantics to <1> ROLL, but SWAP is a common enough use that it is pragmatic
to assign it an opcode and OP_ROLL does something distinctly enhanced.
Similarly, even if we add CAT we will surely come up with saner ways to
implement covenant logic than Andrew's Schnorr tricks.

CTV in particular is designed to be a part of that story -- enough
functionality w/o OP_CAT to work *today* and serve a purpose long into the
future, but with OP_CAT (or shastream preferably) enhances it's
functionality in a useful way and with introspection opcodes (perhaps like
those being developed by elements) further gains functionality. Perhaps the
functionality available today will be redundant with a future way of doing
things, but we can only see so far into the future. However, we can see
that there are good things to build with it today.

It's the inverse of a lobotomy. Independent components that can come
together for a newer greater purpose rather than parts being torn apart
irreparably.

In the future when we have specific use cases in mind that *aren't* served
well (either efficiently or at all) by the existing primitives, it's
completely acceptable to add something new even if it makes an existing
feature redundant. APO, for example, will be redundant (afaict) will Glen
Willen's [Bitmask SigHash Flags](
https://bc-2.jp/archive/season2/materials/0203_NewElementsFeaturesEn.pdf)
should we ever get those.

--
@JeremyRubin 

___
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]

> you should check out some of the earlier work done here:
> 
> https://github.com/olalonde/proof-of-solvency#assets-proofNothing in this 

Nothing here refutes what I have said. Furthermore it relies on the
assumption that all assets and liabilities are provable. This is clearly
prohibitive.

> more than enough.

Arbitrary and subjective.

A business raises money (investment) so that it can spend more than it
previously had. This is net "insolvency" until (and assuming) it produces
and earns over time an amount sufficient to cover its capitalization and
time value.

These sort of schemes are relevant only to what Rothbard calls a money
"warehouse" (a literal vault), which is explicitly not a "bank" (banks
lend). Warehousing Bitcoin is a strange idea to start with. And given that
they are so larded with trust and race conditions it's hardly an improvement
over holding your own keys.

e

> -Original Message-
> From: bitcoin-dev  On
> Behalf Of Erik Aronesty via bitcoin-dev
> Sent: Tuesday, July 6, 2021 9:40 AM
> To: Billy Tetrud ; Bitcoin Protocol Discussion
> 
> Subject: Re: [bitcoin-dev] Proof of reserves - recording
> 
> you should check out some of the earlier work done here:
> 
> https://github.com/olalonde/proof-of-solvency#assets-proof
> 
> to be honest, if any exchange supported that proof, it would be more than
> enough.
> 
> there's really no way to prevent a smash-and-grab, but this does prevent a
> slow-leak
> 
> 
> On Mon, Jul 5, 2021 at 5:10 PM Billy Tetrud via bitcoin-dev  d...@lists.linuxfoundation.org> wrote:
> >
> > 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 respo

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

[Jeremy via bitcoin-dev]

I don't think Elements engineering decisions or management timelines should
have any bearing on what Bitcoin adopts, beyond learning what
works/doesn't. Same as litecoin, dogecoin, or bitcoin cash :)

With my understanding of elements it makes sense that you wouldn't want to
break compatibility script version to script version, although that seems
inevitable that you will need to either hard fork or break compatibility if
you want to fix the CHECKSIGFROMSTACK has verify semantics bug. But perhaps
that's a smaller change than the # of stack elements popped? It makes sense
having CAT that adding a split CSFS wouldn't be a priority. However, I'd
suggest that as far as elements is concerned, if the bitcoin community
decides on something that is incompatible, elements can use up some
addition opcodes or a keytype to add CSFS_BITCOIN_COMPAT ops.
___
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

[ZmnSCPxj via bitcoin-dev]

Good morning Russell,

> Hi ZmnSCPxj,
>
> I don't believe we need to ban Turing completeness for the sake of banning 
> Turing completeness.

Well I believe we should ban partial Turing-completeness, but allow total 
Turing-completeness.

I just think that unlimited recursive covenants (with or without a convenient 
way to transform state at each iteration) are **not** partial Turing-complete, 
but *are* total Turing-complete. (^^)

(The rest of this writeup is mostly programming languages nerdery so anyone who 
is not interested in Haskell (or purely functional programming) and programming 
language nerdery can feel free to skip the rest of this post.
Basically, ZmnSCPxj thinks we should still ban Turing-completeness, but 
unbounded covenants get a pass because they are not, on a technicality, 
Turing-complete)

For now, let us first taboo the term "Turing-complete", and instead focus on 
what I think matters here, the distinction between partial and total,

In a total programming language we have a distinction between data and codata:

* Data is defined according to its constructors, i.e. an algebraic data type.
* Codata is defined according to its destructors, i.e. according to a 
"behavior" the codata has when a particular "action" is applied to it.

For example, a singly-linked list data type would be defined as follows:

data List a where
Cons :: a -> List a -> List a
Nil :: List a

On the other hand, an infinite codata stream of objects would be defined as 
follows:

codata Stream a where
head :: Stream a -> a
tail :: Stream a -> Stream a

For `data` types, the result type for each constructor listed in the definition 
*must* be the type being defined.
That is why `Cons` is declared as resulting in a `List a`.
We declare data according to its constructors.

For `codata` types, the *first argument* for each destructor listed in the 
definition *must* be the type being defined.
That is why `head` accepts as its first argument the `Stream a` type.

This is relevant because in a total function programming language, there exists 
some programming rule that restricts recursion.
The simplest such restriction is substructural recursion:

* If a function recurs:
  * Every self-call should pass in a substructure of an argument as that 
argument.

Every program that passes the above rule provably terminates.
Since every recursion passes in a smaller part of an argument, eventually we 
will reach an indivisible primitive object being passed in, and processing will 
stop recursing and can return some value.

Thus, a programing language that has substructural recursion rule check (and 
rejects programs that fail the substrucutral recursion check) are not 
"Turing-complete".
The reason is that Turing-complete languages cannot solve the Halting Problem.
But a language that includes the substructural recursion rule *does* have a 
Halting Problem solution: every program that passes the substructural recursion 
rule halts and the Halting Problem is decidable for all programs that pass the 
substructural recursion rule.
(i.e. we are deliberately restricting ourselves to a subset of programs that 
pass substructural recursion, and reject programs that do not pass this rule as 
"not really programs", so every program halts)

For example, the following definition of `mapList` is valid under substructural 
recursion:

mapList :: (a -> b) -> (List a -> List b)
mapList f Nil= Nil
mapList f (Cons a as)= Cons (f a) (mapList f as)

The second sub-definition has a recursive call `mapList f as`.
The second argument to that call, however, is a substructure of the second 
argument `Cons a as` on the LHS of the definition, thus it is a substructural 
recursive call, and accepted in a total programming language.
*Every* recursion in `mapList` should then be a substructural call on the 
second argument of `mapList`.

Now let us consider the following definition of `fibonacci`:

-- to use: fibonacci 1 1
fibonacci :: Integer -> Integer -> List Integer
fibonacci x y = Cons x (fibonacci y (x + y))

The above is not substructural recursive, neither argument in the recursive 
`fibonacci y (x + y)` call is a substructure of the arguments in the LHS of the 
`fibonacci` definition `fibonacci x y`.

Thus, we prevent certain unbounded computations like the above infinite 
sequence of fibonacci numbers.

Now, let us consider a definition of `mapStream`, the similar function on 
streams, using copattern matching rather than pattern matching:

mapStream :: (a -> b) -> (Stream a -> Stream b)
head (mapStream f as) = f (head as)
tail (mapStream f as) = mapStream f (tail as)

Now the interesting thing here is that in the substructural recursion check, 
what is being defined in the above stanza is ***not*** `mapStream`, but `head` 
and `tail`!
Thus, it ignores the `mapStream f (tail as)`, because it is **not** recursion 
--- what is being defined here is `tail`.

[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]

[Jeremy via bitcoin-dev]

Dear Bitcoin Devs,

As mentioned previously, OP_CAT (or similar operation) can be used to make
Bitcoin "quantum safe" by signing an EC signature. This should work in both
Segwit V0 and Tapscript, although you have to use HASH160 for it to fit in
Segwit V0.

See [my blog](https://rubin.io/blog/2021/07/06/quantum-bitcoin/) for the
specific construction, reproduced below.

Yet another entry to the "OP_CAT can do that too" list.

Best,

Jeremy
-


I recently published [a blog
post](https://rubin.io/blog/2021/07/02/signing-5-bytes/) about signing up
to a
5 byte value using Bitcoin script arithmetic and Lamport signatures.

By itself, this is neat, but a little limited. What if we could sign longer
messages? If we can sign up to 20 bytes, we could sign a HASH160 digest
which
is most likely quantum safe...

What would it mean if we signed the HASH160 digest of a signature? What the
what? Why would we do that?

Well, as it turns out, even if a quantum computer were able to crack ECDSA,
it
would yield revealing the private key but not the ability to malleate the
content of what was actually signed.  I asked my good friend and
cryptographer
[Madars Virza](https://madars.org/) if my intuition was correct, and he
confirmed that it should be sufficient, but it's definitely worth closer
analysis before relying on this. While the ECDSA signature can be malleated
to a
different, negative form, if the signature is otherwise made immalleable
there
should only be one value the commitment can be opened to.

If we required the ECDSA signature be signed with a quantum proof signature
algorithm, then we'd have a quantum proof Bitcoin! And the 5 byte signing
scheme
we discussed previously is a Lamport signature, which is quantum secure.
Unfortunately, we need at least 20 contiguous bytes... so we need some sort
of
OP\_CAT like operation.

OP\_CAT can't be directly soft forked to Segwit v0 because it modifies the
stack, so instead we'll (for simplicity) also show how to use a new opcode
that
uses verify semantics, OP\_SUBSTRINGEQUALVERIFY that checks a splice of a
string
for equality.

```
... FOR j in 0..=5
<0>
... FOR i in 0..=31
SWAP hash160 DUP  EQUAL IF DROP <2**i> ADD ELSE
 EQUALVERIFY ENDIF
... END FOR
TOALTSTACK
... END FOR

DUP HASH160

... IF CAT AVAILABLE
FROMALTSTACK
... FOR j in 0..=5
FROMALTSTACK
CAT
... END FOR
EQUALVERIFY
... ELSE SUBSTRINGEQUALVERIFY AVAILABLE
... FOR j in 0..=5
FROMALTSTACK <0+j*4> <4+j*4> SUBSTRINGEQUALVERIFY DROP DROP DROP
...  END FOR
DROP
... END IF

 CHECKSIG
```

That's a long script... but will it fit? We need to verify 20 bytes of
message
each bit takes around 10 bytes script, an average of 3.375 bytes per number
(counting pushes), and two 21 bytes keys = 55.375 bytes of program space
and 21
bytes of witness element per bit.

It fits! `20*8*55.375 = 8860`, which leaves 1140 bytes less than the limit
for
the rest of the logic, which is plenty (around 15-40 bytes required for the
rest
of the logic, leaving 1100 free for custom signature checking). The stack
size
is 160 elements for the hash gadget, 3360 bytes.

This can probably be made a bit more efficient by expanding to a ternary
representation.

```
SWAP hash160 DUP  EQUAL  IF DROP  ELSE <3**i> SWAP DUP
 EQUAL IF DROP SUB ELSE  EQUALVERIFY ADD  ENDIF
ENDIF
```

This should bring it up to roughly 85 bytes per trit, and there should be
101
trits (`log(2**160)/log(3) == 100.94`), so about 8560 bytes... a bit
cheaper!
But the witness stack is "only" `2121` bytes...

As a homework exercise, maybe someone can prove the optimal choice of radix
for
this protocol... My guess is that base 4 is optimal!

## Taproot?

What about Taproot? As far as I'm aware the commitment scheme (`Q = pG +
hash(pG
|| m)G`) can be securely opened to m even with a quantum computer (finding
`q`
such that `qG = Q` might be trivial, but suppose key path was disabled, then
finding m and p such that the taproot equation holds should be difficult
because
of the hash, but I'd need to certify that claim better).  Therefore this
script can nest inside of a Tapscript path -- Tapscript also does not
impose a
length limit, 32 byte hashes could be used as well.

Further, to make keys reusable, there could be many Lamport keys comitted
inside
a taproot tree so that an address could be used for thousands of times
before
expiring. This could be used as a measure to protect accidental use rather
than
to support it.

Lastly, Schnorr actually has a stronger non-malleability property than
ECDSA,
the signatures will be binding to the approved transaction and once Lamport
signed, even a quantum computer could not steal the funds.






--
@JeremyRubin 

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