Re: [bitcoin-dev] CheckSigFromStack for Arithmetic Values

[ZmnSCPxj via bitcoin-dev]

Good morning Erik and Jeremy,

> The "for" arithmetic here is largely to mean that this cleverness allows an 
> implementation of `OP_CHECKSIGFROMSTACK`, using arithmetic operation `OP_ADD`.
>
> To my mind this cleverness is more of an argument against ever enabling 
> `OP_ADD` and friends, LOL.
> This is more of a "bad but ridiculously clever thing" post than a "Bitcoin 
> should totally use this thing" post.

Turns out `OP_ADD` is actually still enabled in Bitcoin, LOL, I thought it was 
hit in the same banhammer that hit `OP_CAT` and `OP_MUL`.
Limited to 32 bits, but that simply means that you just validate longer 
bitvectors (e.g. the `s` in the "lamport-sign the EC signature") in sections of 
32 bits.

In any case, the point still mostly stands, I think this is more of a "overall 
bad but still ridiculously clever" idea; the script and witness sizes are 
fairly awful.
Mostly just worth discussing just in case it triggers somebody else to think of 
a related idea that takes some of the cleverness but is overall better.

On the other hand if we can actually implement the "Lamport-sign the EC sig" 
idea (I imagine the 32-bit limit requires some kind of `OP_CAT` or similar, or 
other bit or vector slicing operetion), that does mean Bitcoin is already 
quantum-safe (but has a fairly lousy quantum-safe signing scheme, I really do 
not know the characteristics of better ones though).

Regards,
ZmnSCPxj
___
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]

I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound
to the txdata? When might you use this?

And yes -- "Add OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY to
follow the semantics from bip340-342 when witness program is v1." is a bit
light on detail for what the BIP would end up looking like. If you're able
to open up the design process a bit more on that it would be good as I
think there are some topics worth discussing at large before things proceed
with Elements (assuming feature compatibility remains a goal).

The non-prehashed argument seems OK (at the cost of an extra byte...) but
are there specific applications for !=32 arguments? I can't think of a
particular one beyond perhaps efficiency. Can we safely use 0-520 byte
arguments?

Also do you have thoughts on the other questions i posed above? E.g.
splitting R/S could be helpful w/o CAT.

--
@JeremyRubin 



On Sat, Jul 3, 2021 at 1:13 PM Russell O'Connor 
wrote:

> There is one line written at
> https://github.com/ElementsProject/elements/pull/949/files#r660130155.
>
___
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]

>
> Do you have concerns about sophisticated covenants, and if so, would you
> mind describing them?


Personally, not in particular worried about arbitrary covenants as I think
that: 1 validation costs can be kept in check; 2 you're free to burn your
coins it you want to.

I *do* care that when we enable covenants we don't make people jump through
too many hoops, but I also respect Russel's points that we can enable
functionality and then later figure out how to make it more efficient or
useful guided by use cases.


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.


>
> I'm a fan of CSFS, even mentioning it on zndtoshi's recent survey[2],
> but it seems artificially limited without OP_CAT.  (I also stand by my
> answer on that survey of believing there's a deep lack of developer
> interest in CSFS at the moment.  But, if you'd like to tilt at that
> windmill, I won't stop you.)


Well if you're a fan of it, I'm a fan of it, Russel's a fan of it, and
Sanket's a fan of it that sounds like a good amount of dev interest :) I
know Olaoluwa is also a fan of it too and has some cool L2 protocols using
it.

I think it might not be *hype* because it's been around a while and has
always been bundled with cat so been a non starter for the reasons above. I
think as an independent non-bundle it's exciting and acceptable to a number
of devs. I also believe upgrades can be developed and tracked in parallel
so I'm taking on the windmill tilting personally to spearhead that -- on
the shoulders of Giants who have been creating specs for this already of
course.

Best,

Jeremy

P.s. icymi https://rubin.io/blog/2021/07/02/covenants/ covers my current
thinking about how to proceed w.r.t. deploying and developing covenant
systems for bitcoin
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors

[Daniel Bayerdorffer via bitcoin-dev]

Hello, 

I just wanted to put my two cents in, on the metal backup aspect. We make the 
Bitcoin Recovery Tag for a similar purpose. We use a fixed font, so using ' 
(apostrophe) or H/h are both acceptable. Most metal stamping tools are fixed 
width fonts. 

You can see a picture here... 
[ https://cyphersafe.io/product/bitcoin-recovery-tag/ | 
https://cyphersafe.io/product/bitcoin-recovery-tag/ ] 

Thanks, 
Daniel 

-- 
Daniel Bayerdorffer, VP dani...@numberall.com 
Numberall Stamp & Tool Co., Inc. www.numberall.com 
Reuleaux Models www.reuleauxmodels.com 
CypherSafe www.cyphersafe.io 
PO BOX 187, Sangerville, ME 04479 USA 
TEL: 207-876-3541 FAX: 207-876-3566 


From: "Craig Raw via bitcoin-dev"  
To: "David A. Harding"  
Cc: "Bitcoin Protocol Discussion"  
Sent: Saturday, July 3, 2021 10:00:51 AM 
Subject: Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors 

It's a consideration, not a serious concern. 
When I made the point around alphanumeric characters being similar to the path 
numbers, I was actually thinking of the output descriptor appearing in a fixed 
character width font, which I prefer as more appropriate for displaying 
hexidecimal values. In this case, the apostrophe provides more whitespace which 
makes the path easier to parse visually. It's difficult to reduce this to a 
mathematical argument, as is true for many UX considerations. Your example in 
fixed width here: [ 
https://gist.github.com/craigraw/fc98b9031a7e01e1bc5d75a77bdb72e5 | 
https://gist.github.com/craigraw/fc98b9031a7e01e1bc5d75a77bdb72e5 ] 

That said you make good arguments around the shell quoting and stamps for metal 
backups, and therefore I agree it is preferable to use the lowercase "h". 
Thanks for the detailed reply. 

Craig 

On Sat, Jul 3, 2021 at 12:11 PM David A. Harding < [ mailto:d...@dtrt.org | 
d...@dtrt.org ] > wrote: 


On Sat, Jul 03, 2021 at 10:35:48AM +0200, Craig Raw wrote: 
> There is a downside to using "h"/"H" from a UX perspective - taking up more 
> space 

Is this a serious concern of yours? An apostrophe is 1/2 en; an "h" is 
1 en; the following descriptor contains three hardened derivations in 149 
characters; assuming the average non-'/h character width is 1.5 en, the 
difference between 207 en and 208.5 en is barely more than half a 
percent. 

pkh([d34db33f/44h/0h/0h]xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*)#ml40v0wf
 

Here's a direct visual comparison: [ 
https://gist.github.com/harding/2fbbf2bfdce04c3e4110082f03ae3c80 | 
https://gist.github.com/harding/2fbbf2bfdce04c3e4110082f03ae3c80 ] 

> appearing as alphanumeric characters similar to the path numbers 

First, I think you'd have to be using an awful font to confuse "h" with 
any arabic numeral. Second, avoiding transcription errors is exactly 
why descriptors now have checksums. 

> they make derivation paths and descriptors more difficult to read. 

The example descriptor pasted above looks equally (un)readable to me 
whether it uses ' or h. 

> Also, although not as important, less efficient when making metal 
> backups. 

I think many metal backup schemes are using stamps or punch grids that 
are fixed-width in nature, so there's no difference either way. (And 
you can argue that h is better since it's part of both the base58check 
and bech32 character sets, so you already need a stamp or a grid row for 
it---but ' is otherwise unused, so a stamp or grid row for it would be 
special). 

But even if people are manually etching descriptors into metal, we're 
back to the original point where we're looking at something like a 0.7% 
difference in "efficiency". 

By comparison, the Bitcoin Core issue I cited in my earlier post 
contains several examples of actual users needing technical support 
because they tried to use '-containing descriptors in a bourne-style 
shell. (And I've personally lost time to that class of problems.) In 
the worst case, a shell-quoting accident can cause loss of money by 
sending bitcoins to the descriptor for a key your hardware signing 
device won't sign for. I think these problems are much more serious 
than using a tiny bit of extra space in a GUI or on a physical backup 
medium. 

-Dave 




___ 
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] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

[Russell O'Connor via bitcoin-dev]

On Sun, Jul 4, 2021 at 1:30 PM Jeremy  wrote:

> I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound
> to the txdata? When might you use this?
>

I don't feel strongly about *ADD.  I just figured it might be useful to do
a 2-of-3 between Alice, Bob and an Oracle signed value.  But I don't have
any particular use case in mind.  Either way the *ADD functionality can be
replicated by various SWAPs and ADDs etc, so we could just leave it out
until it is wanted.


> And yes -- "Add OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY to
> follow the semantics from bip340-342 when witness program is v1." is a bit
> light on detail for what the BIP would end up looking like. If you're able
> to open up the design process a bit more on that it would be good as I
> think there are some topics worth discussing at large before things proceed
> with Elements (assuming feature compatibility remains a goal).
>

I'm certainly open to a wider design process.  We can open a specific issue
on the Elements repo.  That said, I don't see a particularly wide design
space on this front.


> The non-prehashed argument seems OK (at the cost of an extra byte...) but
> are there specific applications for !=32 arguments? I can't think of a
> particular one beyond perhaps efficiency. Can we safely use 0-520 byte
> arguments?
>

One of the reasons given in the issue (yes, the thread there is very long)
was that hashing the message requires the hash to be collision resistant
while if you give the message directly it only requires the hash to be
"random-prefix" collision / preimage resistant.  For example SHA-1 is
clearly not collision resistant but it appears to still be random-prefix
collision resistant AFAIU.  Another reason is that it allows for extremely
fast signing oracles because and R value and the midstate of the hash can
be precomputed all the way upto the application prefix, and if the message
being signed is less than 55 bytes or so, the signing cost can be as low as
one compression function and a little bit of non-EC modular arithmetic to
compute S.  If the message were required to be prehashed, then it would
take a minimum of 2 compression function calls to sign, nearly doubling the
signing time needed for the fast oracle.

Even if BIP-0340 kept its requirements that the message be exactly 32
bytes, I would still be inclined to design CHECKSIGFROMSTACK for tapscript
to take the 32-byte message from the stack instead of hashing a message
itself (BIP-0340 does it's own hashing, so prehashing the message isn't a
security concern in the same way it is for ECDSA.)  This would keep the
message off the blockchain, saving space and adding some amount of privacy
and making the operation compatible with rolling SHA256 opcodes.  But given
that BIP-0340 is going to be extended to support non-32 byte messages, then
there is no reason to impose a message length restriction on
CHECKSIGFROMSTACK.  Yes the operation will still be subject to stack item
length restrictions.  This is something script writers will have to be
aware of, but I see little reason to support messages split across multiple
stack items when we expect, by far, most messages to be 32-bytes, and I
expect those rare non-32 byte messages are expected to be reasonably short.


> Also do you have thoughts on the other questions i posed above? E.g.
> splitting R/S could be helpful w/o CAT.
>

Regarding  internal pubkeys and invalid pubkeys, I see no reason to deviate
from whatever tapscript CHECKSIG* do.

Regarding splitting R/S, This is harder because Elements does have CAT and
I think we should add CAT to Bitcoin too.  This game of trying to prevent
covenants by restricting script to the point where we are not even allowed
to have a CAT operation is a losing game.  It's just a matter of time
before we accidently introduce some way to enable covenants anyways, and it
is not worth cutting off vast amounts of functionality in pursuit of this
questionable goal.  And I say this as someone who was originally of the
opinion that we should be very very cautious before enabling new
expressivity such as covenants.  All the scary scenarios of covenants that
I am aware of can be more easily, cheaply, and flexibility implemented by
just having a counterparty in a multi-party signature that enforces their
own policy that they only sign transactions that pay to outputs that they
remain a party to.  And even if scary covenants were scarier than what can
already be done by multisig and policy, I still don't think they are scary
enough to warrant keeping CAT disabled.

So I don't think we should get fancy with CHECKSIGFROMSTACK.  Just take a
normal 64-byte signature value as a stack item.  But I don't feel strongly
about this, and I wouldn't oppose splitting R and S in Bitcoin if that is
where consensus lies.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bi

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

[David A. Harding via bitcoin-dev]

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.

-Dave


signature.asc
Description: PGP signature
___
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]

I agree with you David. I think rather unconstrained covenants are
incredibly useful and important. Yes you can burn coins with them, you can
also permanently limit the usability of certain coins (which is less
destructive than burning them). But as Jeremy said, people are free to burn
their coins. People would also be free (in general) to reject coins
encumbered by weird government provisions or unknown provisions in hidden
scripts. A person/wallet shouldn't accept coins encumbered by scripts it
doesn't recognize.

Even if 99% of bitcoins became permanently encumbered by weird covenants,
the other 1% could still be plenty of bitcoins to run the economy, because
of its potentially infinite divisibility. Losing these coins, or someone
basically turning them into altcoin-like bitcoins shouldn't be a concern
really. What's the risk exactly? That people will be forced to take these
encumbered coins? A government can already force people to take whatever
altcoin they want to force on people - covenants don't make this worse.

Shinobi asks: "What if you extorted users with your 51% attack to move into
those?"

Well, you could do this anyway even without covenants existing already. The
51% attack could simply extort people to use whatever rules they want just
as easily (which isn't to say that easily - most users would probably
refuse to be extorted in either case). So I don't really think this is very
valid.

On Sun, Jul 4, 2021 at 1:33 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

[ZmnSCPxj via bitcoin-dev]

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 covenants are the next ICO".
i.e. ICOs are just colored coins, which are useful for keeping track of various 
stuff, but have then been used as a vehicle to scam people.
But I suppose that is a problem that humans will always have: limited 
cognition, so that *good* popular things that are outside your specific field 
of study are indistinguishable from *bad* popular things.
So perhaps it should not be a concern on a technical level.
Maybe we should instead make articles about covenants so boring nobody will 
hype about it (^^;)v.

Increased functionality implies increased processing, and hopefully computation 
devices are getting cheap enough that the increased processing implied by new 
features should not be too onerous.



To my mind, an "inescapable" covenant (i.e. one that requires the output to be 
paid to the same covenant) is basically a Turing machine, and equivalent to a 
`while (true);` loop.
In a `while (true);` loop, the state of the machine reverts back to the same 
state, and it repeats again.
In an inescpable covenant, the control of some amount of funds reverts back to 
the same controlling SCRIPT, and it repeats again.
Yes, you can certainly add more functionality on top of that loop, just think 
of program main loops for games or daemons, which are, in essence, "just" 
`while (true) ...`.
But basically, such unbounded infinite loops are possible only under Turing 
machines, thus I consider covenants to be Turing-complete.
Principle of Least Power should make us wonder if we need full Turing machines 
for the functionality.

On the other hand --- codata processing *does* allow for unbounded loops, 
without requiring full Turing-completeness; they just require total 
functionality, not partial (and Turing-completeness is partial, not total).
Basically, data structures are unbounded storage, while codata structures are 
unbounded processing.
Perhaps covenants can encode an upper bound on the number of recursions, which 
prevents full Turing-completeness while allowing for a large number of 
use-cases.

(if the above paragraph makes no sense to you, hopefully this Wikipedia article 
will help: https://en.wikipedia.org/wiki/Total_functional_programming )
(basically my argument here is based on academic programming stuff, and might 
not actually matter in real life)

Regards,
ZmnSCPxj
___
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]

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

That said, recursive covenants, the type that are most worrying, seems to
require some kind of OP_TWEAK operation, and I haven't yet seen any
evidence that this can be simulated with CHECKSIG(FROMSTACK).  So maybe we
should leave such worries for the OP_TWEAK operation.

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 covenants are the next ICO".
> i.e. ICOs are just colored coins, which are useful for keeping track of
> various stuff, but have then been used as a vehicle to scam people.
> But I suppose that is a problem that humans will always have: limited
> cognition, so that *good* popular things that are outside your specific
> field of study are indistinguishable from *bad* popular things.
> So perhaps it should not be a concern on a technical level.
> Maybe we should instead make articles about covenants so boring nobody
> will hype about it (^^;)v.
>
> Increased functionality implies increased processing, and hopefully
> computation devices are getting cheap enough that the increased processing
> implied by new features should not be too onerous.
>
>
>
> To my mind, an "inescapable" covenant (i.e. one that requires the output
> to be paid to the same covenant) is basically a Turing machine, and
> equivalent to a `while (true);` loop.
> In a `while (true);` loop, the state of the machine reverts back to the
> same state, and it repeats again.
> In an inescpable covenant, the control of some amount of funds reverts
> back to the same controlling SCRIPT, and it repeats again.
> Yes, you can certainly add more functionality on top of that loop, just
> think of program main loops for games or daemons, which are, in essence,
> "just" `while (true) ...`.
> But basically, such unbounded infinite loops are possible only under
> Turing machines, thus I consider covenants to be Turing-complete.
> Principle of Least Power should make us wonder if we need full Turing
> machines for the functionality.
>
> On the other hand --- codata processing *does* allow for unbounded loops,
> without requiring full Turing-completeness; they just require total
> functionality, not partial (and Turing-completeness is partial, not total).
> Basically, data structures are unbounded storage, while codata structures
> are unbounded processing.
> Perhaps covenants can encode an upper bound on the number of recursions,
> which prevents full Turing-completeness wh

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

[Russell O'Connor via bitcoin-dev]

On Sun, Jul 4, 2021 at 9:02 PM Russell O'Connor 
wrote:

> Bear in mind that when people are talking about enabling covenants, we are
> talking about whether OP_CAT should be allowed or not.
>
> That said, recursive covenants, the type that are most worrying, seems to
> require some kind of OP_TWEAK operation, and I haven't yet seen any
> evidence that this can be simulated with CHECKSIG(FROMSTACK).  So maybe we
> should leave such worries for the OP_TWEAK operation.
>

Upon further thought, you can probably make recursive covenants even with a
fixed scritpubkey by sneaking the state into a few bits of the UTXO's
amount.  Or if you try really hard, you may be able to stash your state
into a sibling output that is accessed via the txid embedded in the
prevoutpoint.
___
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,


> On Sun, Jul 4, 2021 at 9:02 PM Russell O'Connor  
> wrote:
>
> > Bear in mind that when people are talking about enabling covenants, we are 
> > talking about whether OP_CAT should be allowed or not.
> >
> > That said, recursive covenants, the type that are most worrying, seems to 
> > require some kind of OP_TWEAK operation, and I haven't yet seen any 
> > evidence that this can be simulated with CHECKSIG(FROMSTACK).  So maybe we 
> > should leave such worries for the OP_TWEAK operation.
>
> Upon further thought, you can probably make recursive covenants even with a 
> fixed scritpubkey by sneaking the state into a few bits of the UTXO's amount. 
>  Or if you try really hard, you may be able to stash your state into a 
> sibling output that is accessed via the txid embedded in the prevoutpoint.

Which is kind of the point of avoiding giving too much power, because people 
can be very clever and start doing unexpected things from what you think is 
already a limited subset.
"Give an inch and they will take a mile".

Still, as pointed out, altcoins already exist and are substantially worse, and 
altcoin implementations are all going to run on Turing machines anyway (which 
are powerful enough to offer Turing-machine functionality), so maybe this is 
not really giving too much power, people can already fork Bitcoin and add full 
EVM support on it.

Regards,
ZmnSCPxj

___
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

[Anthony Towns via bitcoin-dev]

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